[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/index.html.
---------------------------------------------------------------------------

    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 
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 third-party 
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

[[Page 25517]]

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\
---------------------------------------------------------------------------

    \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.
    \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-the-individuals-right/index.html.
---------------------------------------------------------------------------

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

    \14\ See also cases where this authority was used, such as 2012 
FTC action against Facebook (see https://www.ftc.gov/enforcement/cases-proceedings/092-3184/facebook-inc) and 2012 FTC action against 
MySpace (see https://www.ftc.gov/enforcement/cases-proceedings/102-3058/myspace-llc-matter).
    \15\ See 16 CFR part 318; see also https://www.healthit.gov/sites/default/files/non-covered_entities_report_june_17_2016.pdf.
---------------------------------------------------------------------------

    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 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/index.html 
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. 18-cv-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 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.
---------------------------------------------------------------------------

    \16\ See, https://ecf.dcd.uscourts.gov/cgi-bin/show_public_doc?2018cv0040-51.
    \17\ See, https://hds.sharecare.com/wp-content/uploads/2020/01/CiOX-Health-v.-HHS-Court-Order-3-24-2020.pdf.
---------------------------------------------------------------------------

    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 
third-party applications. Here, we summarize the public comments we 
received on general issues and concerns around privacy and security of 
a standards-based 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

[[Page 25518]]

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

    \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/index.html.
---------------------------------------------------------------------------

    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 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 third-
party 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 third-party 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 third-party 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.

[[Page 25519]]

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-and-Guidance/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 third-party. 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 third-party 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, 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 patient-centered 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 Sec.  
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-to-understand, non-
technical, consumer-friendly 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-and-Guidance/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 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 re-document 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,

[[Page 25520]]

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

[[Page 25521]]

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 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 consensus-based. 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 standards-based 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 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[supreg] 
(HL7) \19\ Fast Healthcare Interoperability Resources[supreg] (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.
---------------------------------------------------------------------------

    \19\ Health Level Seven International[supreg] (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.
---------------------------------------------------------------------------

    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

[[Page 25522]]

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

    \21\ For more information on the USCDI, see https://www.healthit.gov/USCDI.
    \22\ For more information on FHIR, see https://www.hl7.org/fhir/overview.html.
---------------------------------------------------------------------------

III. Provisions of Patient Access Through APIs, and Analysis of and 
Responses to Public Comments

A. Background on Medicare Blue Button

    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[supreg] 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

[[Page 25523]]

just some of the ways Blue Button 2.0 is using a standards-based, FHIR-
enabled API to lead the charge and unleash the power of health data.
---------------------------------------------------------------------------

    \23\ To review a list of apps currently available to Blue Button 
2.0 users, visit https://www.medicare.gov/manage-your-health/medicares-blue-button-blue-button-20/blue-button-apps.
---------------------------------------------------------------------------

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 
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 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\
---------------------------------------------------------------------------

    \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/index.html.
---------------------------------------------------------------------------

    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.

[[Page 25524]]

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 Sec.  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 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 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 standards-based 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 
standards-based 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

[[Page 25525]]

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

[[Page 25526]]

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, low-income 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 
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 
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), Sec.  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

[[Page 25527]]

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 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 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 standards-based 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.

[[Page 25528]]

    Response: We appreciate the commenters' suggestions. The proposed 
rule did not specify a historical look-back 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 Sec.  438.62(b)(1)(vi) (made applicable to CHIP managed 
care entities through incorporation in Sec.  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-to-payer 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 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\
---------------------------------------------------------------------------

    \28\ Pew Research Center. (2019, June 12). Retrieved from 
https://www.pewinternet.org/fact-sheet/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.
---------------------------------------------------------------------------

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

[[Page 25529]]

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-and-Guidance/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, 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-and-Guidance/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 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

[[Page 25530]]

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

[[Page 25531]]

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 standards-based 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 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, 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-and-Guidance/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

[[Page 25532]]

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

[[Page 25533]]

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 cost-sharing 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 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-and-Guidance/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 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

[[Page 25534]]

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 
Medicaid-covered 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 Sec.  
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 long-term 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 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-to-understand 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, 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

[[Page 25535]]

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 tri-agency 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 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 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 non-
inpatient 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.
---------------------------------------------------------------------------

    \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-2785aa50-7bd1b244-0cc47a6d17cc-590a0fb580f6d595&u=http://www2.ccwdata.org/documents/10280/19002256/medicare-claims-maturity.pdf.
---------------------------------------------------------------------------

    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

[[Page 25536]]

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 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 Sec.  
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 Sec.  438.242(b)(6) in this final rule; see 
section IV. of this final rule) and Sec.  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 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 machine-readable 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

[[Page 25537]]

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

[[Page 25538]]

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 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 payer-to-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 payer-to-payer data exchange via the Patient Access 
API if the data were received from another payer via a standards-based 
API. As required at 42 CFR 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 payer-to-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 FHIR-based 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

[[Page 25539]]

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 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.
    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 http://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

[[Page 25540]]

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 http://www.healthit.gov/USCDI and available guidance at https://www.cms.gov/Regulations-and-Guidance/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 http://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 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 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 Sec.  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

[[Page 25541]]

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).
    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-and-Guidance/Guidance/Interoperability/index. We are finalizing these 
requirements for the API to include formulary information for MA 
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.

[[Page 25542]]

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

[[Page 25543]]

Commenters believed third parties should be charged a fee to maintain 
the API. One commenter expressed concern that the business model of the 
third-party 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.
---------------------------------------------------------------------------

    \31\ See also cases where this authority was used, such as 2012 
FTC action against Facebook (see https://www.ftc.gov/enforcement/cases-proceedings/092-3184/facebook-inc), the 2012 FTC action 
against MySpace (see https://www.ftc.gov/enforcement/cases-proceedings/102-3058/myspace-llc-matter), and the 2017 FTC action 
against VIZIO (see https://www.ftc.gov/enforcement/cases-proceedings/162-3024/vizio-inc-vizio-inscape-services-llc).
---------------------------------------------------------------------------

    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 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, `click-through' 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 cross-reference 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 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 standards-based 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.
---------------------------------------------------------------------------

    \32\ HL7 International. (n.d.). FHIR Overview. Retrieved from 
https://www.hl7.org/fhir/overview.html.
---------------------------------------------------------------------------

    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

[[Page 25544]]

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

[[Page 25545]]

    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://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/model-privacy-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 non-repudiation 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.
    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 
http://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,

[[Page 25546]]

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

    \33\ For information on adoption levels for technical 
specifications related to data segmentation, see the 
Interoperability Standards Advisory at https://www.healthit.gov/isa/data-segmentation-sensitive-information.
---------------------------------------------------------------------------

    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 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 
http://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

[[Page 25547]]

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

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), Sec.  431.60(e), 438.242(b)(6) (redesignated 
as Sec.  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 
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 non-
published 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

[[Page 25548]]

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\
---------------------------------------------------------------------------

    \35\ 45 CFR 164.308(a)1)(ii)(A).
    \36\ For 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.
---------------------------------------------------------------------------

    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, 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 third-party 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 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,

[[Page 25549]]

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

    \38\ See 45 CFR 164.103 Definitions, regarding functions of 
business associate.
---------------------------------------------------------------------------

    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 pre-approve 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 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 third-parties 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 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 patient-friendly, 
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,

[[Page 25550]]

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

    \39\ Plain Language Action and Information Network. (2011, May). 
Federal Plain Language Guidelines. Retrieved from https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf.
---------------------------------------------------------------------------

     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 Notice\41\ 
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 
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.
---------------------------------------------------------------------------

    \40\ See https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/.
    \41\ See https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.
---------------------------------------------------------------------------

    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 
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 Sec.  438.242(b)(5) in this final rule; see section VI. 
of this final rule) and Sec.  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-to-understand 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-to-consumer 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

[[Page 25551]]

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 consumer-friendly 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 non-covered 
third-party app or how an app may use their health information.
    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, non-transactional 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 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

[[Page 25552]]

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 and security of patient data: https://www.cms.gov/Regulations-and-Guidance/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 
standards-based 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 standards-based 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 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 standards-based 
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 non-compliance 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 standards-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. 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

[[Page 25553]]

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

[[Page 25554]]

care plans at 42 CFR 438.242(b)(6) (finalized as Sec.  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 
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 value-based 
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 
value-based 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 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

[[Page 25555]]

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 one-off and as-needed basis. To the extent a 
HIPAA covered entity offers patients access to their records via a 
standards-based 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, 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 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

[[Page 25556]]

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

[[Page 25557]]

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 Sec.  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 Sec.  431.60 apply; that is, 
the state is responsible for providing the specified data elements in 
Sec.  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 Sec.  438.242(b)(5) (proposed as Sec.  
438.242(b)(6); see section VI.) apply; that is, the managed care plan 
is responsible for providing the specified data elements in Sec.  
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 Sec.  457.730 apply; that is, the state is responsible 
for providing the specified data elements in Sec.  457.730(b) through 
an API. If the beneficiary is enrolled in a managed care plan, the 
requirements in Sec.  457.1233(d) apply; that is, the managed care plan 
is responsible for providing the specified data elements in Sec.  
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 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-
to-understand 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

[[Page 25558]]

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[hyphen]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 Medicaid-
covered 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 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 requirement, available 
here: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. We also note that impacted payers are allowed 
to request that third-party 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

[[Page 25559]]

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 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 public-facing 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 public-facing 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 public-facing 
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 
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.

[[Page 25560]]

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, 
machine-readable 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.
---------------------------------------------------------------------------

    \42\ Available at http://cmsgov.github.io/QHP-provider-formulary-APIs/developer/index.html.
---------------------------------------------------------------------------

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

[[Page 25561]]

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 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 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 Sec.  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 Sec.  438.10(h)(3) for 
Medicaid managed care plans, which applies to CHIP managed care 
entities under Sec.  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

[[Page 25562]]

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 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 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 FHIR-based 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

[[Page 25563]]

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

[[Page 25564]]

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

    \43\ 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-disclosures-for-care-coordination-and-continuity-of-care/index.html.
---------------------------------------------------------------------------

    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 cross-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

[[Page 25565]]

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

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

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

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

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

[[Page 25566]]

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

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

    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-to-
payer 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 USCDI-
defined 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 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 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.

[[Page 25567]]

    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 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 
cross-reference 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 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

[[Page 25568]]

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-to-payer 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 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 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 cross-reference 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

[[Page 25569]]

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), Sec.  438.242(b)(5), and Sec.  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 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, Sec.  438.242(b)(5) for Medicaid 
managed care plans, Sec.  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 networks that are 
operating successfully be leveraged in further advancing 
interoperability; thus, we considered a possible future approach to 
payer-to-payer 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.
---------------------------------------------------------------------------

    \48\ See https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf. For additional information 
about TEFCA, see https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement.
---------------------------------------------------------------------------

    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

[[Page 25570]]

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

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 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 federal-state 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 buy-in 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 buy-in 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 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 Buy-in 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.
---------------------------------------------------------------------------

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

    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

[[Page 25571]]

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 buy-in 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 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 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

[[Page 25572]]

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 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 full-benefit 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 partial-benefit 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 
risk-adjusting 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 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.
---------------------------------------------------------------------------

    \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_6-15-17.pdf. (Last accessed June 24, 2019).
---------------------------------------------------------------------------

    Ensuring information on dual eligibility status is accurate and up-
to-date 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

[[Page 25573]]

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.
    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 Medicare-Medicaid 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 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.

[[Page 25574]]

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

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

    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

[[Page 25575]]

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 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 (http://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-patient-assessment-instruments/physician-compare-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 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

[[Page 25576]]

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-cm-prod-content.s3.amazonaws.com/uploads/282/2019%20PI%20Information%20Blocking%20Fact%20Sheet.pdf for more 
information about the attestation statements.
    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-Patient-Assessment-Instruments/physician-compare-initiative/Downloads/Physician-Compare-TEP-Summary-2018.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 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

[[Page 25577]]

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 
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 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''

[[Page 25578]]

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 
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 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 non-enforcement (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

[[Page 25579]]

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

[[Page 25580]]

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

    \52\ The NPPES website at https://nppes.cms.hhs.gov/.
---------------------------------------------------------------------------

    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.

[[Page 25581]]

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

[[Page 25582]]

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 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 hospital-based 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 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

[[Page 25583]]

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, hospital-based 
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 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 60-day 
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-and-Guidance/Administrative-Simplification/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%20EXCHANGE.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 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

[[Page 25584]]

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%20INFORMATION%20EXCHANGE.html.
    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 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 post-discharge 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

[[Page 25585]]

discharge from the hospital or post-acute 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 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 
patient-centered 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 
authors identified a number of studies demonstrating positive effects 
on outcomes associated with better care coordination, such as 
reductions in 30-day readmissions,54 55 56 and improved 
medication reconciliation.\57\
---------------------------------------------------------------------------

    \53\ Menachemi, N., Rahurkar, S., Harle, C.A., & Vest, J.R. 
(2018). The benefits of health information exchange: An updated 
systematic review. Journal of 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-for-service 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.
---------------------------------------------------------------------------

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

    \58\ Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest, J.R. (2017). 
Hospitalization event notifications and reductions in readmissions 
of Medicare fee-for-service beneficiaries in the Bronx, New York. 
Journal of the American Medical Informatics Association, 24(e1), 
e150-e156. doi: 10.1093/jamia/ocw139.
---------------------------------------------------------------------------

    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, post-
acute 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),

[[Page 25586]]

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 http://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-patients-admission-discharge-andor-transfer-status-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 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 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 Medicaid-participating 
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\
---------------------------------------------------------------------------

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

    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

[[Page 25587]]

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 
post-acute 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.
---------------------------------------------------------------------------

    \60\ Office of the National Coordinator. (n.d.). Admission, 
Discharge, and Transfer. Retrieved from https://www.healthit.gov/isa/admission-discharge-and-transfer.
---------------------------------------------------------------------------

    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 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 post-discharge 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, 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 post-
discharge 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.
---------------------------------------------------------------------------

    \61\ For more information about obtaining a Direct addresses, 
see https://www.healthit.gov/sites/default/files/directbasicsforprovidersqa_05092014.pdf.
---------------------------------------------------------------------------

    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

[[Page 25588]]

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: (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 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.

[[Page 25589]]

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

[[Page 25590]]

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

[[Page 25591]]

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

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

    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 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 
over-pricing 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

[[Page 25592]]

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 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[supreg]) 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 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

[[Page 25593]]

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, 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), 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 post-discharge 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

[[Page 25594]]

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 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 Medicare-
participating 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 
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 
post-discharge follow-up rates for patients most at risk for avoidable 
readmissions.
---------------------------------------------------------------------------

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

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

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

    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)

[[Page 25595]]

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\
---------------------------------------------------------------------------

    \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/.
---------------------------------------------------------------------------

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

[[Page 25596]]

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 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 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[supreg]-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

[[Page 25597]]

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 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.
    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/admission-discharge-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

[[Page 25598]]

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

[[Page 25599]]

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 
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 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-and-Guidance/Legislation/EHRIncentivePrograms/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

[[Page 25600]]

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

[[Page 25601]]

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

[[Page 25602]]

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

[[Page 25603]]

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

[[Page 25604]]

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 public-facing digital endpoint on their website to 
ensure public discovery and access.
    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 30-day 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.
     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.

[[Page 25605]]



                                    Table 1--Occupation Titles and Wage Rates
----------------------------------------------------------------------------------------------------------------
                                                                                      Fringe         Adjusted
                Occupation title                    Occupation     Mean  hourly    benefit  ($/    hourly  wage
                                                       code        wage  ($/hr)         hr)           ($/hr)
----------------------------------------------------------------------------------------------------------------
Administrators and Network Architects...........         15-1140          $45.09          $45.09          $90.18
Security Engineer...............................         17-2199           47.80           47.80           95.60
Computer and Information Analysts...............         15-1120           45.67           45.67           91.34
General Operations Manager......................         11-1021           59.56           59.56          119.12
Operations Research Analysts....................         15-2031           42.48           42.48           84.96
Software Developers, Applications...............         15-1132           51.96           51.96          103.92
Computer and Information Systems Managers.......         11-3021           73.49           73.49          146.98
Designers.......................................         27-1020           24.05           24.05           48.10
Technical Writer................................         27-3042           36.30           36.30           72.60
Computer Systems Analysts.......................         15-1121           45.01           45.01           90.02
Network and Computer Systems Administrators.....         15-1142           41.86           41.86           83.72
Medical Records and Health Information                   29-2071           21.16           21.16           42.32
 Technician.....................................
Medical and Health Service Managers.............         11-9111           54.68           54.68          109.36
----------------------------------------------------------------------------------------------------------------

    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 cost-sharing). 
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-
to-date 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 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 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 standards-
based 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

[[Page 25606]]

estimations of the required labor categories and number of hours 
required to implement the API provisions (84 FR 7659). We originally 
estimated a one-time 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.
---------------------------------------------------------------------------

    \66\ Health Level Seven International (HL7[supreg]) 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.
---------------------------------------------------------------------------

    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 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 payer-to-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 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 FHIR-based APIs, and 
whether an impacted payer will develop this technology in-house 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

[[Page 25607]]

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

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

     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.

[[Page 25608]]



                                             Table 2--First Year and Maintenance Cost of the API Provisions
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                         Mean                  Adjusted                     First year
                                          Occupation    hourly      Fringe      hourly      First year         hours        First year      Maintenance
            Occupation title                  code     wage  ($/    benefit    wage  ($/    hours  (low      (primary      hours  (high        hours
                                                          hr)       ($/hr)        hr)        estimate)       estimate)       estimate)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Administrators and Network Architects...     15-1140      $45.09      $45.09      $90.18            1440            2880            4320             180
Security Engineer.......................     17-2199       47.80       47.80       95.60             960            1920            2880             240
Computer and Information Analysts.......     15-1120       45.67       45.67       91.34             480             960            1440              60
General Operations Manager..............     11-1021       59.56       59.56      119.12             720            1440            2160              90
Operations Research Analysts............     15-2031       42.48       42.48       84.96             960            1920            2880             120
Software Developers, Applications.......     15-1132       51.96       51.96      103.92             960            1920            2880             240
Computer and Information Systems             11-3021       73.49       73.49      146.98             720            1440            2160              90
 Managers...............................
Designers...............................     27-1020       24.05       24.05       48.10             960            1920            2880             120
Technical Writer........................     27-3042       36.30       36.30       72.60             240             480             720              30
Computer Systems Analysts...............     15-1121       45.01       45.01       90.02             960            1920            2880             120
Network and Computer Systems                 15-1142       41.86       41.86       83.72  ..............               0               0             420
 Administrators.........................
    Total Hours per System..............  ..........  ..........  ..........  ..........           8,400          16,800          25,200           1,710
    Total Cost per system (Dollars)       ..........  ..........  ..........  ..........         788,414       1,576,829       2,365,243         157,657
     (millions).........................
    Total hours for 345 Organizations     ..........  ..........  ..........  ..........       2,898,000       5,796,000       8,694,000         589,950
     (hours)............................
    Total Cost for 345 Organizations      ..........  ..........  ..........  ..........     272,002,968     544,005,936     816,008,904      54,391,527
     (millions $).......................
--------------------------------------------------------------------------------------------------------------------------------------------------------

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 
Medicaid-participating 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 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 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

[[Page 25609]]

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 post-acute 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 
http://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-a-patients-admission-discharge-andor-transfer-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, 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.
---------------------------------------------------------------------------

    \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/FIG-Hospital-Routine-Electronic-Notification.php.
---------------------------------------------------------------------------

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

[[Page 25610]]



                                       Table 3--Summary of Hour and Dollar Burden by Number of Affected Providers
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                       Hospitals and psychiatric                     CAHs
---------------------------------------------------------------------------------              hospitals             -----------------------------------
                                                                                 ------------------------------------
                                                                                       Year 1       Subsequent years       Year 1       Subsequent years
--------------------------------------------------------------------------------------------------------------------------------------------------------
Lower Bound...................................  Affected Providers..............                 1,392
                                                                        394
                                               ---------------------------------------------------------------------------------------------------------
                                                Total Burden (hours)............            48,720            11,136            13,790             3,152
                                                Total Cost......................     $2,341,789.44       $471,275.52       $662,834.08       $133,392.64
                                               ---------------------------------------------------------------------------------------------------------
Primary Estimate..............................  Affected Providers..............                 2,400
                                                                        679
                                               ---------------------------------------------------------------------------------------------------------
                                                Total Burden (hours)............            84,000            19,200            23,765             5,432
                                                Total Cost......................     $4,037,568.00       $812,544.00     $1,142,295.28       $229,882.24
                                               ---------------------------------------------------------------------------------------------------------
Upper Bound...................................  Affected Providers..............                 3,407
                                                                        964
                                               ---------------------------------------------------------------------------------------------------------
                                                Total Burden (hours)............           119,245            27,256            33,740             7,712
                                                Total Cost......................     $5,731,664.24     $1,153,473.92     $1,621,756.48       $326,371.84
--------------------------------------------------------------------------------------------------------------------------------------------------------

4. Summary of Information Collection Burdens

                                               Table 4--Summary of Primary Information Collection Burdens
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                                                      Hourly
                                                                                          Burden per     Total      labor cost  Total labor  Total labor
       Regulation  section(s)             OMB control No.       Number of    Number of     response      annual         of        cost 1st       cost
                                                               respondents   responses     (hours)       burden     reporting     year ($)    subsequent
                                                                                                        (hours)        ($)                    years ($)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Sec.   423.910......................  0938-0958 *............           36           36          960       34,560       $90.02    3,111,091    3,111,091
Sec.   422.119, Sec.   431.60, Sec.   0938-New...............          345          345       16,800    5,796,000       Varies  544,005,936            0
  457.730, Sec.   438.242, Sec.
 457.1233 and Sec.   156.221.
Sec.   422.119, Sec.   431.60, Sec.   0938-New...............          345          345        1,710      589,950       Varies  ...........   54,391,527
  457.730, Sec.   438.242, Sec.
 457.1233, and Sec.   156.221.
Sec.   482.24(d) and Sec.             0938-New...............        2,400        2,400           35       84,000       Varies    4,037,568  ...........
 482.61(f).
Sec.   482.24(d) and Sec.             0938-New...............        2,400        2,400            8       19,200       Varies  ...........      812,544
 482.61(f).
Sec.   485.638(d)...................  0938-New...............          679          679           35       23,765       Varies    1,142,295  ...........
Sec.   485.638(d)...................  0938-New...............          679          679            8        5,432       Varies  ...........   229,882.24
                                     -------------------------------------------------------------------------------------------------------------------
    Total...........................  .......................  ...........        6,884       Varies    6,552,907       Varies  552,296,890   58,545,044
--------------------------------------------------------------------------------------------------------------------------------------------------------
* 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 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 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

[[Page 25611]]

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 full-benefit 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 then-new 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-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. 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 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 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.

[[Page 25612]]



                                             Table 5--Estimated Costs (millions) of Final Rule by Provision
--------------------------------------------------------------------------------------------------------------------------------------------------------
             Provision                  Dual        Patient
-----------------------------------   eligible     access API
                                        care          (low
                                    coordination   estimate)
                                   ---------------------------
                                                      Sec.                                                                                    Percent of
                                                    422.119,                                                                     Months in     25 month
                                                      Sec.       Patient      Patient     Total cost   Total cost   Total cost    year for    window for
                                        Sec.        431.60,     access API   access API      (low       (primary      (high      compliance   compliance
          Regulatory text           406.26, Sec.      Sec.       (primary      (high      estimate)    estimate)    estimate)     for dual    with dual
                                        407.40,     438.242,    estimate)    estimate)                                            eligible     eligible
                                        Sec.          Sec.                                                                       provisions   provisions
                                       423.910      457.730,
                                                      Sec.
                                                    457.123,
                                                      Sec.
                                                    156.221
--------------------------------------------------------------------------------------------------------------------------------------------------------
2020..............................           2.8        272.0        544.0        816.0        274.8        546.8        818.8           10           40
2021..............................           3.4         54.4         54.4         54.4         57.8         57.8         57.8           12           48
2022..............................           0.8         54.4         54.4         54.4         55.2         55.2         55.2            3           12
2023..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2024..............................             0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2025..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2026..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2027..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2028..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2029..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
                                   ---------------------------------------------------------------------------------------------------------------------
    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 non-federal 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        Costs are fully
                               provision (API,       developed in the
                               Dual).                Collection of
                                                     Information section
                                                     of this final rule
                                                     (section XII. of
                                                     this final rule).
7...........................  Proportion of         There is no
                               premiums by program   straightforward way
                               (2016-2018) used,     to directly assess
                               in later tables, as   parent organization
                               a proxy for           cost by payer.
                               proportion of cost    Therefore, for each
                               by program.           payer we develop
                                                     approximate
                                                     percentages of cost
                                                     per payer.
8...........................  API costs total cost  We obtain the total
                               by year and Program   API costs for this
                               (Medicare,            final rule per
                               Medicaid,             program by
                               Individual market     multiplying the API
                               plans, and CHIP).     costs (for all
                               This total cost is    programs) of this
                               divided by cost to    final rule (Table
                               the federal           5) by the
                               government (Table     proportion of
                               9) and non-federal    premiums presented
                               costs to plans and    in Table 7.
                               enrollees (Table
                               10).

[[Page 25613]]

 
9...........................  Total costs incurred  Based on how federal
                               by the federal        payments are
                               government by         calculated in
                               program and year.     Medicare and
                                                     Medicaid, we have
                                                     projected federal
                                                     proportions of the
                                                     total cost and
                                                     these are applied
                                                     to Table 8 to
                                                     obtain Table 9.
10..........................  Non-federal total     Table 9 = Table 8-
                               costs for API by      Table 10--non-
                               program by year.      federal costs are
                                                     obtained by
                                                     subtracting federal
                                                     costs (Table 9)
                                                     from total costs
                                                     (Table 8).
11..........................  Average non-federal   Tables 11 and 10
                               cost per enrollee     present the same
                               per year by program   data in different
                               for plans.            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.
12..........................  Average federal cost  Tables 12 and 9
                               per enrollee per      present the same
                               year by program for   data in different
                               the federal           forms. Table 9
                               government.           presents total cost
                                                     to the federal
                                                     government (due to
                                                     matching programs),
                                                     while Table 12
                                                     presents average
                                                     cost per enrollee
                                                     to the federal
                                                     government.
13..........................  How payers would      This table lists
                               defray the            potential means for
                               remaining costs.      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.
---------------------------------------------------------------------------

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

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

    \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/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf.
---------------------------------------------------------------------------

    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 omit state 
agencies, we believe that the 70 percent of Medicaid enrollees enrolled 
in Medicaid managed care provides a good approximation.
---------------------------------------------------------------------------

    \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/cms-proposes-changes-streamline-and-strengthen-medicaid-and-chip-managed-care-regulations.
---------------------------------------------------------------------------

    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 employer-sponsored 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

[[Page 25614]]

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
----------------------------------------------------------------------------------------------------------------
                                                                     Medicare       Individual
                      Year                           Medicaid        Advantage     market plans       Totals
----------------------------------------------------------------------------------------------------------------
2016 Premium (billions).........................             113             157              77             347
2017 Premium (billions).........................           119.5           170.3              86             376
2018 Premium (billions).........................             127             184              91             402
2016 Percentage (used in this RIA in all                  32.56%          45.24%          22.19%         100.00%
 estimates) of total costs by program...........
2017 Percentage.................................          31.78%          45.29%          22.93%         100.00%
2018 Percentage.................................          31.62%          45.81%          22.56%         100.00%
----------------------------------------------------------------------------------------------------------------

    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 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     Individual                           Medicare
                  Year                    costs (millions)    market plans      Medicaid and        Advantage
                                           (from Table 5)       (22.19%)        CHIP (32.56%)       (45.24%)
                                               for API
                                              provision
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).....................             272.0              60.4              88.6             123.1
2020 (Primary estimate).................             544.0             120.7             177.2             246.1
2020 (High Estimate)....................             816.0             181.1             265.7             369.2
2021....................................              54.4              12.1              17.7              24.6
2022....................................              54.4              12.1              17.7              24.6

[[Page 25615]]

 
2023....................................              54.4              12.1              17.7              24.6
2024....................................              54.4              12.1              17.7              24.6
2025....................................              54.4              12.1              17.7              24.6
2026....................................              54.4              12.1              17.7              24.6
2027....................................              54.4              12.1              17.7              24.6
2028....................................              54.4              12.1              17.7              24.6
2029....................................              54.4              12.1              17.7              24.6
                                         -----------------------------------------------------------------------
    Total (Low Estimate)................             761.5             169.0             248.0             344.6
    Total (Primary Estimate)............            1033.5             229.3             336.6             467.6
    Total (High Estimate)...............            1305.5             289.7             425.1             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 non-Exchange plans, and some issuers have only non-
Exchange plans. We reflected these assumptions with global adjustments, 
so we believe the estimates are reasonable in aggregate.
    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 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 standards-based 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\
---------------------------------------------------------------------------

    \72\ Allen, K. (2019, April 18). Medicaid Managed Care Spending 
in 2018. Retrieved from https://www.healthmanagement.com/blog/medicaid-managed-care-spending-in-2018/.
---------------------------------------------------------------------------

    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

[[Page 25616]]

(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 non-
federal 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   For Medicaid    For Medicare
                              Year                                 market plans        CHIP          Advantage
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).............................................             0.0            65.2             0.0
2020 (Primary estimate).........................................             0.0           130.4             0.0
2020 (High Estimate)............................................             0.0           195.5             0.0
2021 (Low estimate).............................................             6.1            11.8            50.2
2021 (Primary Estimate).........................................             6.1            11.8            92.1
2022 (High Estimate)............................................             6.1            11.8           133.9
2022............................................................             6.2            11.8             8.4
2023............................................................             6.2            11.8             8.4
2024............................................................             6.3            11.8             8.4
2025............................................................             6.3            11.8             8.4
2026............................................................             6.3            11.8             8.4
2027............................................................             6.3            11.8             8.4
2028............................................................             6.3            11.8             8.4
2029............................................................             6.4            11.8             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   For Medicaid/   For Medicare
                              Year                                  market plans       CHIP          Advantage
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).............................................            61.0            24.3           124.3
2020 (Primary estimate).........................................           121.3            47.7           247.4
2020 (High Estimate)............................................           181.7            71.1           370.1
2021 (Low estimate).............................................            12.8             7.0           -24.1
2021(Primary Estimate)..........................................            12.8             7.0           -65.9
2021 (High Estimate)............................................            12.8             7.0          -107.8
2022............................................................            12.3             6.2            16.6
2023............................................................            12.1             6.0            16.2
2024............................................................            12.1             6.0            16.2
2025............................................................            12.1             6.0            16.2
2026............................................................            12.1             6.0            16.2
2027............................................................            12.1             6.0            16.2
2028............................................................            12.1             6.0            16.2

[[Page 25617]]

 
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\
---------------------------------------------------------------------------

    \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-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/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 Supplementary Medical 
Insurance Trust Funds. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2019.pdf.
---------------------------------------------------------------------------

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

    \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/report-highlights/index.html.
    \76\ Centers for Medicare and Medicaid Services. (n.d.). Monthly 
Contract Summary Report--August 2018. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/MCRAdvPartDEnrolData/Monthly-Contract-and-Enrollment-Summary-Report-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/report-highlights/index.html.
---------------------------------------------------------------------------

    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                       Medicare
             Current enrollment by payer (millions)                market plans      Medicaid        Advantage
                                                                      (17.5)        plans (73)      plans (20)
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).............................................            3.48            0.33            6.22
2020 (Primary estimate).........................................            6.93            0.65           12.37
2020 (High Estimate)............................................           10.38            0.97           18.51
2021 (Low estimate).............................................            0.73            0.10           -1.20
2021(Primary Estimate)..........................................            0.73            0.10           -3.30
2021 (High Estimate)............................................            0.73            0.10           -5.39
2022............................................................            0.70            0.09            0.83
2023............................................................            0.69            0.08            0.81
2024............................................................            0.69            0.08            0.81
2025............................................................            0.69            0.08            0.81

[[Page 25618]]

 
2026............................................................            0.69            0.08            0.81
2027............................................................            0.69            0.08            0.81
2028............................................................            0.69            0.08            0.81
    2029........................................................            0.69            0.08            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                       Medicare
             Current enrollment by payer (millions)                market plans      Medicaid        Advantage
                                                                      (17.5)        plans (73)      plans (20)
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).............................................            0.00            0.89            0.00
2020 (Primary estimate).........................................            0.00            1.79            0.00
2020 (High Estimate)............................................            0.00            2.68            0.00
2021 (Low estimate).............................................            0.35            0.16            2.51
2021(Primary Estimate)..........................................            0.35            0.16            4.60
2021 (High Estimate)............................................            0.35            0.16            6.69
2022............................................................            0.35            0.16            0.42
2023............................................................            0.35            0.16            0.42
2024............................................................            0.36            0.16            0.42
2025............................................................            0.36            0.16            0.42
2026............................................................            0.36            0.16            0.42
2027............................................................            0.36            0.16            0.42
2028............................................................            0.36            0.16            0.42
2029............................................................            0.37            0.16            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 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 
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.

[[Page 25619]]



            Table 13--How Payers Would Defray Remaining Costs
------------------------------------------------------------------------
 
------------------------------------------------------------------------
Individual Market Plans...........  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.
Medicaid/CHIP.....................  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.
Medicare Advantage (MA)...........  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.
------------------------------------------------------------------------

    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 non-Exchange 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 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. 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

[[Page 25620]]

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 non-quantified 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 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\
---------------------------------------------------------------------------

    \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-it-certification-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/Regulations-and-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-to-catch-fhir-in-2019.
---------------------------------------------------------------------------

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

[[Page 25621]]

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

    \81\ 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.
---------------------------------------------------------------------------

    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 standards-

[[Page 25622]]

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 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 x $139.14). 
Therefore, we estimate that the total cost of reviewing this regulation 
is $288,020 ($834.84 x 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 standards-based APIs for making certain data 
available to current enrollees. The Patient Access API will permit 
third-party applications to retrieve data concerning adjudicated 
claims, encounters with capitated providers, provider remittances, 
patient cost-sharing, 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 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

[[Page 25623]]

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-to-payer 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-Data-and-Systems/Statistics-Trends-and-Reports/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 
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 x 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 x 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 x 
345 parent organizations) high estimate. For a detailed discussion of 
the one-time costs associated with implementing the API requirements we 
refer readers to section XII.C.3. of this 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 third-party 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 x $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

[[Page 25624]]

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

    \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.
    \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/MediaReleaseDatabase/Press-releases/2018-Press-releases-items/2018-03-06.html.
---------------------------------------------------------------------------

    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 standards-based 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 Federal-State 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 Buy-in 
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 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 buy-in 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 buy-in 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 buy-in 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 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 25-month 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 6-month 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.

[[Page 25625]]

    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 
Medicaid-participating 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 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\
---------------------------------------------------------------------------

    \85\ Unruh, M. A., Jung, H., Kaushal, R., & Vest, J. R. (2017). 
Hospitalization event notifications and reductions in readmissions 
of Medicare fee-for-service beneficiaries in the Bronx, New York. 
Journal of the American Medical Informatics Association, 24(e1), 
e150-e156. doi: 10.1093/jamia/ocw139.
---------------------------------------------------------------------------

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

    \86\ Centers for Medicare and Medicaid Services. (2019, December 
6). State Innovation Models Initiative: General Information. 
Retrieved from https://innovation.cms.gov/initiatives/State-Innovations/.
---------------------------------------------------------------------------

    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

[[Page 25626]]

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

    \87\ Medicare Payment Advisory Commission. (2019, July 19). A 
Data Book: Health Care Spending and the Medicare Program--June 2019. 
Retrieved from http://www.medpac.gov/docs/default-source/data-book/jun19_databook_entirereport_sec.pdf?sfvrsn=0.
---------------------------------------------------------------------------

    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 re-examination 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. 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.
---------------------------------------------------------------------------

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

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

[[Page 25627]]

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 pro-competitive 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 Merit-
based Incentive Payment System (MIPS) eligible clinicians that use 
certified 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\
---------------------------------------------------------------------------

    \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/handout-219_FINAL.pdf. See also https://azure.microsoft.com/en-us/services/azure-api-for-fhir/ and https://www.apple.com/healthcare/health-records/.
    \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-to-catch-fhir-in-2019.
---------------------------------------------------------------------------

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

    \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-Consumer-Data-Brief-3.21.18.pdf.
---------------------------------------------------------------------------

    Other alternatives that we considered were how broadly or narrowly 
to apply the policies and requirements. For example, we could have 
required health 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

[[Page 25628]]

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

[[Page 25629]]



                                         Table 14--Accounting Statement
----------------------------------------------------------------------------------------------------------------
                                                                                       Units
                                                      Primary    -----------------------------------------------
                    Category                         estimate                      Discount rate      Period
                                                                   Year dollars      (percent)        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                   85.2            2019               7       2020-2029
 estimate)......................................            80.8            2019               3       2020-2029
Annualized Monetized $ millions/year (primary              122.0            2019               7       2020-2029
 estimate)......................................           112.4            2019               3       2020-2029
Annualized Monetized $ millions/year (high                 158.8            2019               7       2020-2029
 estimate)......................................           144.0            2019               3       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.................             5.4            2019               7       2020-2029
Annualized Monetized $ millions.................             5.5            2018               3       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.
    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 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.

[[Page 25630]]

    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 off-Exchange) 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 x $4 
billion premium from issuers below the applicable MLR threshold).
     Increased premiums = Up to $17.8 million (0.0244 percent x 
($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                Amount             Source                Comments
----------------------------------------------------------------------------------------------------------------
(A)....................  First year cost of                  272.0  Estimated in this     In millions.
                          interoperability (Low                      proposed rule.
                          estimate).

[[Page 25631]]

 
(B)....................  First year cost amortized            30.2  (A) / 9.............  In millions.
                          over 9 years.
(C)....................  Continuation year cost of            54.4  Estimated in this     In millions.
                          interoperability.                          proposed rule.
(D)....................  Level interoperability               84.6  (B) + (C)...........  In millions.
                          cost per year.
----------------------------------------------------------------------------------------------------------------
                                     Commercial Percent of Premium Revenues
----------------------------------------------------------------------------------------------------------------
(E)....................  Total premium revenues in             347  Table 7.............  In billions.
                          Individual market,
                          Medicaid and Medicare.
(F)....................  Individual market plans                77  22.19%..............  Table 7.
                          premium revenues (dollar
                          amount and percent).
(G)....................  Medicare Advantage                    157  45.24%..............  Table 7.
                          premium revenues (Dollar
                          amount and percent).
(H)....................  Medicaid premium revenues             113  32.56%..............  Table 7.
                          (Dollar amount and
                          percent).
----------------------------------------------------------------------------------------------------------------
   Annual interoperability cost as a percent of commercial individual market health insurance premium revenues
----------------------------------------------------------------------------------------------------------------
(I)....................  Annual Level                         84.6  (D).................  In millions.
                          interoperability cost.
(J)....................  Percent of total                   22.19%  (F).................
                          individual market plans
                          revenues.
(K)....................  Interoperability cost for            18.8  (I) x (J)...........  In millions.
                          individual market plans.
(L)....................  Commercial premium                 77,000  (E).................  2016 data in millions.
                          revenues for individual
                          market plans.
(M)....................  Interoperability cost as          0.0244%  (K) / (L)...........
                          a percent of total
                          commercial revenue for
                          individual market plans.
----------------------------------------------------------------------------------------------------------------
      Individual market plans revenue broken out by whether above or below MLR threshold (requiring rebate)
----------------------------------------------------------------------------------------------------------------
(N)....................  Total individual market            77,000  (E).................  In millions.
                          plan revenue.
(O)....................  Revenues of individual              4,037  2016 CMS MLR Data in  In millions.
                          market health plans                        millions.
                          whose MLR is below
                          regulatory threshold.
(P)....................  Revenues of individual             72,963  (N)-(O).............  In millions.
                          market plans whose MLR
                          is below regulatory
                          threshold.
----------------------------------------------------------------------------------------------------------------
                 Transfer to enrollee per enrollee from decreased rebates and increased premium
----------------------------------------------------------------------------------------------------------------
(Q)....................  Reduction in rebates from             1.0  (N) x (O)...........  In millions.
                          interoperability in
                          those plans paying
                          rebates.
(R)....................  Premium increase from                17.8  (N) x (P)...........
                          interoperability in
                          those plans not paying
                          rebates.
(S)....................  Total increase to                    18.8  (Q) + (R)...........  In millions.
                          commercial individual
                          market plans enrollees
                          from interoperability.
(T)....................  Number commercial                    17.5  From 2016 MLR files,  In millions.
                          enrollees in individual                    in millions.
                          market plans.
(U)....................  Dollar increase in                  $1.07  (S) / (T)...........
                          premium per enrollee
                          (Low estimate).
(V)....................  Dollar increase in                  $1.46  Obtained by
                          premium per enrollee                       replacing 272
                          (Medium Estimate).                         million in row (A)
                                                                     with $544 million.
(W)....................  Dollar increase in                  $1.84  Obtained by
                          premium per enrollee                       replacing 272
                          (High Estimate).                           million in row (A)
                                                                     with $816 million.
----------------------------------------------------------------------------------------------------------------

F. Regulatory Reform Analysis Under E.O. 13771

    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 
on the estimated costs of this final rule can be found in the preceding 
analysis.

G. Conclusion

    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 407

    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.

[[Page 25632]]

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.

42 CFR Part 457

    Administrative practice and procedure, Grant programs--health, 
Health insurance, Reporting and recordkeeping requirements.

42 CFR Part 482

    Grant programs--health, Hospitals, Medicaid, Medicare, Reporting 
and recordkeeping requirements.

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

0
1. The authority citation for part 406 is revised to read as follows:

    Authority:  42 U.S.C 1302 and 1395hh.


0
2. Section 406.26 is amended by adding paragraph (a)(1)(i) and adding 
and reserving paragraph (a)(1)(ii) to read as follows:


Sec.  406.26  Enrollment under State buy-in.

    (a) * * *
    (1) * * *
    (i) Any State that has a buy-in agreement in effect must 
participate in daily exchanges of enrollment data with CMS.
    (ii) [Reserved]
* * * * *

PART 407--SUPPLEMENTARY MEDICAL INSURANCE (SMI) ENROLLMENT AND 
ENTITLEMENT

0
3. The authority citation for part 407 is revised to read as follows:

    Authority:  42 U.S.C 1302 and 1395hh.


0
4. Section 407.40 is amended by adding paragraph (c)(4) to read as 
follows:


Sec.  407.40  Enrollment under a State buy-in agreement.

* * * * *
    (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

0
5. The authority citation for part 422 continues to read as follows:

    Authority:  42 U.S.C 1302 and 1395hh.


0
6. Section 422.119 is added to read as follows:


Sec.  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;
    (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 Sec.  
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

[[Page 25633]]

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

0
7. Section 422.120 is added to read as follows:


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

[[Page 25634]]


0
8. Section 422.504 is amended by adding paragraph (a)(18) to read as 
follows:


Sec.  422.504  Contract provisions.

* * * * *
    (a) * * *
    (18) To comply with the requirements for access to health data and 
plan information under Sec. Sec.  422.119 and 422.120 of this chapter.
* * * * *

PART 423--VOLUNTARY MEDICARE PERSCRIPTION DRUG BENEFIT

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


0
10. Section 423.910 is amended--
0
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'';
0
b. In paragraph (d) by revising the paragraph heading and by 
redesignating the text of paragraph (d) introductory text as paragraph 
(d)(1).
0
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
0
d. By adding paragraph (d)(2).
    The revision and addition read as follows:


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

0
11. The authority citation for part 431 is revised to read as follows:

    Authority:  42 U.S.C. 1302.


0
12. Section 431.60 is added to subpart B to read as follows:


Sec.  431.60  Beneficiary access to and exchange of data.

    (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;
    (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 Sec.  
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

[[Page 25635]]

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

0
13. Section 431.70 is added to subpart B to read as follows:


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

0
14. The authority citation for part 438 is revised to read as follows:

    Authority:  42 U.S.C. 1302.


0
15. Section 438.62 is amended by adding paragraphs (b)(1)(vi) and (vii) 
to read as follows:


Sec.  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 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]
* * * * *

0
16. Section 438.242 is amended by adding paragraphs (b)(5) and (6) to 
read as follows:


Sec.  438.242  Health information systems.

* * * * *
    (b) * * *
    (5) Implement an Application Programming Interface (API) as 
specified in Sec.  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 Sec.  431.70, which must 
include all information specified in Sec.  438.10(h)(1) and (2) of this 
chapter.
* * * * *

PART 457--ALLOTMENTS AND GRANTS TO STATES

0
17. The authority citation for part 457 is revised to read as follows:

    Authority:  42 U.S.C. 1302.


0
18. Section 457.700 is amended by--
0
a. Redesignating paragraphs (a)(1) and (2) as paragraphs (a)(2) and 
(3), respectively;
0
b. Adding paragraph (a)(1); and
0
c. Revising paragraph (c).
    The addition and revision reads as follows:

[[Page 25636]]

Sec.  457.700   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 Sec.  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 Sec.  
457.730 by requiring the managed care organizations to meet the 
requirements of Sec.  457.1233(d)(2).

0
19. Section 457.730 is added to read as follows:


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

[[Page 25637]]

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]

0
20. Section 457.760 is added to subpart G to read as follows:


Sec.  457.760  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 Sec.  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 Sec.  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.

0
21. Section 457.1233 is amended by revising paragraph (d) to read as 
follows:


Sec.  457.1233  Structure and operations standards.

* * * * *
    (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 Sec.  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 Sec.  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 Sec.  457.760, which must 
include all information specified in Sec.  438.10(h)(1) and (2) of this 
chapter.
* * * * *

PART 482--CONDITIONS OF PARTICIPATION: HOSPITALS

0
22. The authority citation for part 482 is revised to read as follows:

    Authority:  42 U.S.C. 1302, 1395hh, and 1395rr, unless otherwise 
noted.


0
23. Section 482.24 is amended by adding paragraph (d) to read as 
follows:


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

0
24. Section 482.61 is amended by adding paragraph (f) to read as 
follows:


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

[[Page 25638]]

    (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

0
25. The authority citation for part 485 is revised to read as follows:

    Authority:  42 U.S.C. 1302 and 1395hh.


0
26. Section 485.638 is amended by adding paragraph (d) to read as 
follows:


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

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

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


0
28. Section 156.221 is added to read as follows:


Sec.  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;

[[Page 25639]]

    (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 
Federally-Facilitated 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 
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 Federally-Facilitated 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 Sec.  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 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-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).
    (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 
non-compliance upon enrollees, the current or proposed means of 
providing health information to enrollees, and solutions and a timeline 
to achieve compliance with the requirements of this section.

[[Page 25640]]

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

    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