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 in the Federally-Facilitated Exchanges and Health Care Providers, 7610-7680 [2019-02200]

Agencies

• Centers for Medicare & Medicaid Services
• DEPARTMENT OF HEALTH AND HUMAN SERVICES
• Office of the Secretary

[Federal Register Volume 84, Number 42 (Monday, March 4, 2019)]
[Proposed Rules]
[Pages 7610-7680]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2019-02200]



Federal Register / Vol. 84 , No. 42 / Monday, March 4, 2019 / 
Proposed Rules
-----------------------------------------------------------------------

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-P]
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 in the Federally-Facilitated Exchanges and Health Care 
Providers

AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS.

ACTION: Proposed rule.

-----------------------------------------------------------------------

SUMMARY: This proposed 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 access to, and the quality 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 plans, health care providers, or payers.

DATES: To be assured consideration, comments must be received at one of 
the addresses provided below, no later than 5 p.m. on May 3, 2019.

ADDRESSES: In commenting, please refer to file code CMS-9115-P. Because 
of staff and resource limitations, we cannot accept comments by 
facsimile (FAX) transmission.
    Comments, including mass comment submissions, must be submitted in 
one of the following three ways (please choose only one of the ways 
listed):
    1. Electronically. You may submit electronic comments on this 
regulation to https://www.regulations.gov. Follow the ``Submit a 
comment'' instructions.
    2. By regular mail. You may mail written comments to the following 
address ONLY: Centers for Medicare & Medicaid Services, Department of 
Health and Human Services, Attention: CMS-9115-P, P.O. Box 8016, 
Baltimore, MD 21244-8016.
    Please allow sufficient time for mailed comments to be received 
before the close of the comment period.
    3. By express or overnight mail. You may send written comments to 
the following address ONLY: Centers for Medicare & Medicaid Services, 
Department of Health and Human Services, Attention: CMS-9115-P, Mail 
Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.
    For information on viewing public comments, see the beginning of 
the SUPPLEMENTARY INFORMATION section.

FOR FURTHER INFORMATION CONTACT: 
    Alexandra Mugge, (410) 786-4457, for issues related to 
interoperability, CMS health IT strategy, technical standards and 
patient matching.
    Natalie Albright, (410) 786-1671, for issues related to Medicare 
Advantage.
    John Giles, (410) 786-1255, for issues related to Medicaid.
    Emily Pedneau, (301) 492-4448, 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.
    Lisa Bari, (410) 786-0087, for issues related to advancing 
interoperability in innovative models.
    Russell Hendel, (410) 786-0329, for issues related to the 
Collection of Information or the Regulation Impact Analysis sections.

SUPPLEMENTARY INFORMATION: 
    Inspection of Public Comments: All comments received before the 
close of the comment period are available for viewing by the public, 
including any personally identifiable or confidential business 
information that is included in a comment. We post all comments 
received before the close of the comment period on the following 
website as soon as possible after they have been received: https://www.regulations.gov. Follow the search instructions on that website to 
view public comments.

[[Page 7611]]

I. Background and Summary of Provisions

A. Purpose

    This proposed rule is the first phase of proposed 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 solving the issue of interoperability 
and achieving complete access to health information for patients in the 
United States (U.S.) health care system, and 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 proposing and adopting policies for the Medicare and 
Medicaid programs, the Children's Health Insurance Program (CHIP), and 
issuers of qualified health plans (QHPs).
    Throughout this proposed rule, we refer to terms such as patient, 
consumer, beneficiary, enrollee, and individual. We note that every 
reader of this proposed rule is a patient and has or will receive 
medical care at some point in their life. In this proposed rule, we use 
the term ``patient'' as an inclusive term, but because we have 
historically referred to patients using other terms in our regulations, 
we use specific terms as applicable in sections of this proposed rule 
to refer to individuals covered under the health care programs that CMS 
administers and regulates. We also use terms such as payer, plan, and 
issuer in this proposed rule. Certain portions of this proposed 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 in Federally-facilitated Exchanges (FFEs). We 
use the term ``payer'' as an inclusive term, but we use specific terms 
as applicable in sections of this proposed 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 complete 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.
    We believe patients should have the ability to move from health 
plan to health plan, 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 complete 
record of their health information should be readily available to that 
care provider, regardless of where or by who 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 
health plans or ages into Medicare, the enrollee should be able to have 
their claims history and encounter data follow so that information is 
not lost.
    For providers in clinical settings, health information technology 
(health IT) should be a resource, designed to make it faster and easier 
for providers to deliver high quality care, creating efficiencies and 
allowing them to access all available data for their patients. 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, and other health care professionals. Through 
standards-based interoperability and exchange, health IT has the 
potential to be a resource and facilitator for efficient, safe, high-
quality care for individuals and populations.
    All payers, including health plans, should have the ability to 
exchange data seamlessly with other payers for timely benefits 
coordination or transitions, and with providers to facilitate more 
coordinated and efficient care. Health plans 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. 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 solving 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 prices and outcomes, while minimizing 
reporting burdens on affected plans, providers, and payers.
    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 full 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 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. To accomplish this, 
we have launched several initiatives related to data sharing and 
interoperability to empower patients and encourage plan and provider 
competition. In this proposed rule, we continue to advance the policies 
and goals of the MyHealthEData initiative through various proposals as 
outlined in the following sections.
    Our proposals are wide-reaching and would have an impact on all 
facets of the health care system. Several key

[[Page 7612]]

touch points of the proposals in this rule include:
     Patients: Enabling patients to access their health 
information electronically without special effort by requiring the 
payers subject to this proposed rule to make the data available through 
an application programming interface (API) to which third party 
software applications connect to make the data available to patients. 
This encourages them 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 proposing 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: Proposing requirements to ensure that payers (that 
is, entities and organizations that pay for health care), such as MA 
plans and Medicaid and CHIP programs, make enrollee electronic health 
information held by the plan available through an API such that, with 
use of software we expect payers and third parties to develop, the 
information becomes easily accessible to the enrollee, and that the 
data flows seamlessly with the enrollee as they change providers, 
plans, and issuers. Additionally, our proposals would 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.
    Under our proposals 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 plans and 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 objective to improve patient access 
and care, alleviate provider burden, and reduce overall health care 
costs.

D. Past Efforts

    The Department of Health and Human Services (HHS) has been working 
to advance the interoperability of electronic health information since 
2004, when the ONC was initially created via Executive Order 13335. 
From 2004 to 2009, ONC worked with a variety of federal and private 
sector stakeholders to coordinate private and public actions, began 
harmonizing data standards, and worked to advance nationwide health 
information exchange. In 2009, the National Coordinator position, 
office, and statutory duties were codified by the Health Information 
Technology for Economic and Clinical Health Act (HITECH Act), enacted 
as part of the American Recovery and Reinvestment Act of 2009 (Pub. L. 
111-5, enacted February 17, 2009), at Title 42--Health Information 
Technology and Quality (42 U.S.C. 300jj et seq.) of the Public Health 
Service Act (PHSA). Under section 3001(c)(5) of the PHSA, ONC 
established a voluntary certification program to certify that health IT 
met standards, implementation specifications, and certification 
criteria adopted by the Secretary. ONC is organizationally located 
within HHS' Office of the Secretary and is the principal federal entity 
charged with coordination of nationwide efforts to implement and use 
the most advanced health IT and the electronic exchange of health 
information.
    The HITECH Act provided the opportunity to move interoperability 
forward in many additional meaningful ways. A few are particularly 
worth noting in relation to this proposed rule. For instance, HITECH 
also amended the Social Security Act (the Act), authorizing CMS to make 
incentive payments (and in later years, make downward adjustments to 
Medicare payments) to eligible professionals, eligible hospitals and 
critical access hospitals (CAHs), and MA organizations to promote the 
adoption and meaningful use of certified electronic health record 
technology (CEHRT). In 2010, through rulemaking, we established 
criteria for the Medicare and Medicaid Electronic Health Record (EHR) 
Incentive Programs to encourage eligible professionals, eligible 
hospitals, and CAHs to adopt, implement, upgrade, and demonstrate the 
meaningful use of CEHRT. The programs were implemented in three stages:

     Stage 1 set the foundation for the EHR Incentive 
Programs by establishing requirements for the electronic capture of 
clinical data, including providing patients with electronic copies 
of health information.
     Stage 2 expanded upon the Stage 1 criteria with a focus 
on advancing clinical processes and ensuring that the meaningful use 
of EHRs supported the aims and priorities of the National Quality 
Strategy. Stage 2 criteria encouraged the use of CEHRT for 
continuous quality improvement at the point of care and the exchange 
of information in the most structured format possible.
     Stage 3 focuses on using CEHRT to improve health 
outcomes.

    The federal government has spent over $35 billion under the EHR 
Incentive Programs to incentivize the adoption and meaningful use of 
EHR systems by eligible professionals, eligible hospitals, and CAHs; 
however, despite the fact that 78 percent of physicians \1\ and 96 
percent of hospitals \2\ now use a certified EHR system, progress on 
system-wide data sharing has been limited.
---------------------------------------------------------------------------

    \1\ ONC, Health IT Dashboard, ``Office-based Physician Health IT 
Adoption: State rates of physician EHR adoption, health information 
exchange & interoperability, and patient engagement (2015),'' 
https://dashboard.healthit.gov/apps/physician-health-it-adoption.php 
(last accessed July 9, 2018).
    \2\ ONC, Health IT Dashboard, ``Non-federal Acute Care Hospital 
Health IT Adoption and Use: State rates of non-federal acute care 
hospital EHR adoption, health information exchange and 
interoperability, and patient engagement (2015),'' https://dashboard.healthit.gov/apps/hospital-health-it-adoption.php (last 
accessed July 9, 2018).
---------------------------------------------------------------------------

    In 2010, under the HITECH Act, ONC adopted an initial set of 
standards, implementation specifications, and certification criteria, 
and established the Temporary Certification Program for Health 
Information Technology, under which health IT developers could begin to 
obtain certification of the EHR technology that eligible professionals, 
eligible hospitals, and CAHs would need to adopt and use to satisfy CMS 
Stage 1 requirements for demonstration of meaningful use of CEHRT. In 
January 2011, ONC replaced the Temporary Certification Program with the 
Permanent Certification Program for Health Information Technology (45 
CFR part 170). The Secretary has adopted iterative editions of the set 
of standards, implementation specifications, and certification criteria 
included in the Programs to keep pace with advances in standards, 
health information exchange, and the health IT market. In addition, 
this helps to maintain alignment with the needs of health care 
providers seeking to succeed within health IT-linked federal programs.
    In April 2015, Congress passed the Medicare Access and CHIP 
Reauthorization Act of 2015 (MACRA) (Pub. L. 114-10, enacted April 16, 
2015), which declared it a national

[[Page 7613]]

objective to achieve widespread exchange of health information through 
interoperable CEHRT nationwide. Section 106(b)(1)(B)(ii) of MACRA 
defines ``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 as to provide access to longitudinal information for 
health care providers in order to facilitate coordinated care and 
improved patient outcomes. The MACRA charges the Secretary to establish 
metrics to be used to determine if widespread interoperability had been 
achieved, and the heading of section 106(b)(2) of the MACRA refers to 
``preventing blocking the sharing of information.'' Specifically, 
section 106(b)(2) of the MACRA amended section 1848(o)(2)(A)(ii) of the 
Act for eligible professionals and section 1886(n)(3)(A)(ii) of the Act 
for eligible hospitals and CAHs to require that the professional or 
hospital demonstrate that they have not knowingly and willfully taken 
action to limit or restrict the compatibility or interoperability of 
CEHRT. For a discussion of the attestation requirements that we 
established and codified to support the prevention of information 
blocking, we refer readers to the CY 2017 Quality Payment Program final 
rule (81 FR 77028 through 77035).
    In April 2018, we renamed the EHR Incentive Programs and the MIPS 
Advancing Care Information performance category to the Promoting 
Interoperability (PI) Programs and Promoting Interoperability 
performance category, respectively (83 FR 41635). This refocusing and 
rebranding of the initiatives is just one part of the CMS strategic 
shift in focus to advancing health IT and interoperability.
    CMS appreciates the pathways Congress opened for action on 
interoperability, as will be discussed in more detail throughout this 
proposed rule and has been working diligently with ONC to support 
implementation. In addition, in order to make sure we have as much 
stakeholder feedback on all the options CMS specifically has available 
to best take advantage of this new opportunity to promote 
interoperability, over a span of several months in 2018, we released 
interoperability Requests for Information (RFIs) in several Medicare 
payment rules, including in the FY 2019 Inpatient Prospective Payment 
System (IPPS) proposed rule (83 FR 20164). While the Interoperability 
RFI in the FY 2019 IPPS proposed rule was focused primarily on how and 
whether changes to Hospital Conditions of Participation and other like 
program requirements could impact or contribute to advancing 
interoperability, stakeholders provided additional input that we are 
taking under advisement for the purposes of advancing interoperability 
generally in this proposed rule. For example, some commenters 
recommended aligning existing standards and adopting common standards 
and/or data elements across the health care industry as a whole (not 
just focusing on providers), incentivizing the use of standards, and 
removing barriers as possible ways to address gaps in interoperability. 
Commenters also expressed support for the use of open APIs but 
cautioned CMS to consider the need to ensure health information 
security. Support was also expressed for enhancing applications that 
are designed for patient, or consumer use, such as Blue Button 2.0 
(CMS' Medicare FFS open API for patient access to health information), 
and the development of patient-facing consumer applications that 
aggregate various longitudinal health information for the patient into 
one location. We plan to continue to review the public comments we 
receive to help identify opportunities for CMS to advance 
interoperability in future rulemaking and subregulatory guidance.
    CMS is also working with partners in the private sector to promote 
interoperability. In 2018, CMS began participating in the Da Vinci 
project, a private-sector initiative led by Health Level 7 (HL7), a 
standards development organization. For one of the use cases under this 
project--called ``Coverage Requirements and Documentation Rules 
Discovery''--the Da Vinci project developed a draft Fast Healthcare 
Interoperability Resources (FHIR) standard during the summer and fall 
of 2018. In June 2018, in support of the Da Vinci project, the CMS 
Medicare FFS program began: (1) Developing a prototype Documentation 
Requirement Lookup Service for the Medicare FFS program; (2) populating 
it with the list of items/services for which prior authorization is 
required by the Medicare FFS program; and (3) populating it with the 
documentation rules for oxygen and Continuous Positive Airway Pressure 
(CPAP) devices. More information about the FFS Medicare program's 
efforts to support these Da Vinci use cases are available at 
go.cms.gov/MedicareRequirementsLookup.
    We encourage all payers, including but not limited to MA 
organizations, Medicaid managed care plans and CHIP managed care 
entities, and QHP issuers in FFEs to follow CMS's example and align 
with the Da Vinci Project to: (1) Develop a similar lookup service; (2) 
populate it with their list of items/services for which prior 
authorization is required; and (3) populate it with the documentation 
rules for at least oxygen and CPAP. By taking this step, health plans 
can join CMS in helping to build an ecosystem that will allow providers 
to connect their EHRs or practice management systems and efficient work 
flows with up-to-date information on which items and services require 
prior authorization and what the documentation requirements are for 
various items and services under that patient's current plan 
enrollment.
    In the 8 years since the first HHS rulemakings to implement HITECH, 
significant progress has been made in the adoption of EHRs by hospitals 
and clinicians; however, progress on interoperability needs to be 
accelerated.
    In section 106(b) of MACRA, Congress declared it a national 
objective to achieve widespread exchange of health information through 
interoperable certified EHR technology nationwide by December 31, 2018. 
Not later than July 1, 2016, the Secretary was to establish metrics to 
be used to determine if and to the extent this objective was achieved. 
If the objective is not achieved by December 31, 2018, the Secretary 
must submit a report not later than December 31, 2019, that identifies 
barriers to the objective and recommends actions that the federal 
government can take to achieve the objective. In April 2016, ONC 
published the ``Office of the National Coordinator for Health 
Information Technology; Medicare Access and CHIP Reauthorization Act of 
2015; Request for Information Regarding Assessing Interoperability for 
MACRA'' RFI (81 FR 20651). Based on stakeholder input received in 
response to the RFI, ONC subsequently identified the following two 
metrics for interoperability (see https://www.healthit.gov/sites/default/files/fulfilling_section_106b1c_of_the_medicare_access_and_chip_reauthorization_act_of_2015_06.30.16.pdf):
     Measure #1: Proportion of health care providers who are 
electronically engaging in the following core domains of interoperable 
exchange of health information: sending, receiving, finding (querying), 
and integrating information received from outside sources.
     Measure #2: Proportion of health care providers who report 
using the information they electronically receive from outside 
providers and sources for clinical decision-making.
    ONC recently provided an update on these metrics in its 2018 Report 
to

[[Page 7614]]

Congress--Annual Update on the Adoption of a Nationwide System for the 
Electronic Use and Exchange of Health Information (see https://www.healthit.gov/sites/default/files/page/2018-12/2018-HITECH-report-to-congress.pdf). ONC will continue to evaluate nationwide performance 
according to the identified metrics, and believes current developments, 
such as policy changes being implemented under the 21st Century Cures 
Act (Cures Act) (Pub. L. 114-255, enacted December 13, 2016) will 
contribute to increasingly improved performance under these metrics.
    In addition, the Cures Act included provisions to advance 
interoperability and health information exchange, including, for 
example, enhancements to ONC's Health IT certification program and a 
definition of ``information blocking'' (as discussed further in section 
VIII. of this proposed rule). These provisions have been addressed in 
depth in ONC's proposed rule ``21st Century Cures Act: 
Interoperability, Information Blocking, and the ONC Health IT 
Certification Program'' (published elsewhere in this issue of the 
Federal Register).
    Section 4003 of the Cures Act added a definition of 
``interoperability'' as paragraph 10 of section 3000 of the PHSA (42 
U.S.C. 300jj (9)) (as amended). Under section 3000 of the PHSA, 
`interoperability', with respect to health IT, means technology 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. It also 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.
    This definition aligns with the definition under MACRA and the HHS 
vision and strategy for achieving a health information ecosystem within 
which all individuals and their health care providers 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, as 
well as through patient choice of health plans and providers. 
Accordingly, except where we further or otherwise specify for a 
specific policy or purpose, when we use the term ``interoperability'' 
within this proposed rule we are referring to the definition in section 
3000 of the PHSA.

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 has contributed to 
our proposals in this proposed rule. Some of the main barriers shared 
with us are addressed in the following sections. While we have made 
efforts to address some of these barriers in this proposed rule and 
through prior rules and actions, we believe there is still considerable 
work to be done to overcome some of these considerable challenges 
toward achieving interoperability.
1. Patient Identifier and Interoperability
    In the Interoperability RFI in the FY 2019 IPPS proposed rule (83 
FR 20550), we solicited feedback on positive solutions to better 
achieve interoperability or the sharing of health care information 
between providers. A number of commenters noted that the lack of a 
unique patient identifier (UPI) inhibited interoperability efforts 
because, without a unique identifier for each patient, the safe and 
secure electronic exchange of health information is constrained because 
it is difficult to ensure that the relevant records are all for the 
same patient.
    As part of efforts to reduce the administrative costs of providing 
and paying for health care, the Health Insurance Portability and 
Accountability Act of 1996 (HIPAA) (Pub. L. 104-191, enacted August 21, 
1996) required the adoption of a ``unique individual identifier for 
healthcare purposes,'' commonly referred to as a UPI. At the time HIPAA 
was enacted, HHS began to consider what information would be needed to 
develop a rule to adopt a UPI standard. An initial Notice of Intent to 
issue a proposed rule on requirements for a unique health identifier 
for individuals was published in the November 2, 1998 Federal Register 
(63 FR 61773-61774).
    Such an identifier has the potential to facilitate the accurate 
portability of health information by allowing correct patient matching 
because the universal identifier allows for accurate and timely patient 
record linking between providers across the care continuum and it 
allows a patient's complete record to easily move with them from 
provider to provider. However, stakeholders immediately raised 
significant concerns regarding the impact of this UPI on health 
information security and privacy. Stakeholders were concerned that if 
there was a single identifier used across systems, it would be easier 
for that information to be compromised, exposing protected health 
information (PHI) more easily than in the current medical record 
environment that generally requires linking several pieces of 
personally identifying information to link health records.
    The National Committee on Vital Health Statistics (NCVHS), the 
statutory public advisory body to the Secretary of Health and Human 
Services (the Secretary) for health data, statistics, privacy, and 
national health information policy and HIPAA, conducted extensive 
hearings in the first year after HIPAA was enacted to evaluate this and 
other HIPAA-related implementation issues. The NCVHS First Annual 
Report to the Congress on the Implementation of the Administrative 
Simplification Provisions of the Health Insurance Portability and 
Accountability Act, February 3, 1998, outlines the NCVHS' efforts to 
obtain feedback on the UPI (https://ncvhs.hhs.gov/wp-content/uploads/2018/03/yr1-rpt-508.pdf). Through this process, NCVHS found a lack of 
consensus on how best to define a UPI and controversy around the use of 
a UPI due to privacy and data security concerns. Those in favor of 
adopting a UPI believe a UPI is the most efficient way to foster 
information sharing and accurate patient record linking, where those 
against it are concerned about patient privacy and data security. NCVHS 
found these privacy and data security concerns outweighed the benefits 
of a UPI.
    The NCVHS recommended that the Secretary not move forward with a 
proposed rule on a patient identifier until further discussions could 
be had to fully understand the privacy and data security concerns, as 
well as the full breadth of options beyond a single identifier. NCVHS 
suggested the Secretary work to maximize public participation in 
soliciting a variety of options for establishing an identifier or an 
alternative approach for identifying individuals and linking health 
information of individuals for health purposes.
    Appreciating the significant concerns raised by stakeholders 
regarding implementing a UPI, Congress included language in the Omnibus 
Consolidated and Emergency Supplemental Appropriations Act of 1999 
(Pub. L. 105-277, enacted October 21, 1998) and in each subsequent 
Appropriations bill, stating ``None of the funds made available in this 
Act may be used to

[[Page 7615]]

promulgate or adopt any final standard under section 1173(b) of the Act 
(42 U.S.C. 1320d-2(b)) providing for, or providing for the assignment 
of, a unique health identifier for an individual (except in an 
individual's capacity as an employer or a health care provider), until 
legislation is enacted specifically approving the standard.'' This 
language has effectively prohibited HHS from engaging in rulemaking to 
adopt a UPI standard. Consequently, the Secretary withdrew the Notice 
of Intent to pursue rulemaking on this issue on August 9, 2000 (https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=200010&RIN=0938-AI91).
    In recent years, concerns regarding the privacy and security of 
information have only increased. For example, in the first quarter 
through third quarter of FY 2018 (October 1, 2017 through June 30, 
2018), 276 breach incidents were reported to the HHS Office of Civil 
Rights (OCR) affecting 4,341,595 individuals (https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf).
    Although the appropriations language regarding the UPI standard has 
remained unchanged, in the report accompanying the 2017 appropriations 
bill, Congress additionally stated, ``Although the Committee continues 
to carry a prohibition against HHS using funds to promulgate or adopt 
any final standard providing for the assignment of a unique health 
identifier for an individual until such activity is authorized, the 
Committee notes that this limitation does not prohibit HHS from 
examining the issues around patient matching. Accordingly, the 
Committee encouraged the Secretary, acting through ONC and CMS, to 
provide technical assistance to private-sector led initiatives to 
develop a coordinated national strategy that will promote patient 
safety by accurately identifying patients to their health 
information.'' (H.R. Rep. No. 114-699, p. 110, https://www.gpo.gov/fdsys/pkg/CRPT-114hrpt699/pdf/CRPT-114hrpt699.pdf). Congress has 
repeated this guidance for 2018 and 2019. This guidance directed HHS to 
focus on examining issues around patient matching and to provide 
technical assistance to private sector-led initiatives focusing on a 
patient matching solution.
    Unlike a UPI, which assigns a unique identifier--either numerical 
or otherwise--to each patient, patient matching is a process by which 
health information from multiple sources is compared to identify common 
elements, with the goal of identifying records representing a single 
patient. This is generally done by using multiple demographic data 
fields such as name, birth date, gender, and address. The goal of 
patient matching is to link one patient's data across multiple 
databases within and across health care providers in order to obtain a 
comprehensive view of that patient's health care information.
    ONC has stated that patient matching is critically important to 
interoperability and the nation's health IT infrastructure as health 
care providers must be able to share patient health information and 
accurately match a patient to his or her data from a different provider 
in order for many anticipated interoperability benefits to be realized.
    Patient matching can be less precise than a UPI due to the reliance 
on demographic attributes (such as name and date of birth) which are 
not unique traits to a particular patient; further, patient matching is 
often dependent on manual data entry and data maintained in varying 
formats. Matching mistakes can contribute to adverse events, 
compromised safety and privacy, and increased health care costs (see 
https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf). However, a 
wide range of strategies and best practices currently being deployed 
across the industry have been shown to improve patient matching rates, 
suggesting that patient matching approaches can be an effective 
solution when appropriately implemented (see https://www.healthit.gov/sites/default/files/patient_identification_matching_final_report.pdf).
    Many stakeholders commenting on the interoperability RFIs included 
in the 2019 proposed payment rules indicated that patient matching is a 
``core functionality'' of patient identification and necessary to 
ensure care coordination and the best patient outcomes. Commenters also 
noted that a consistently used matching strategy could accomplish the 
original goals of a UPI with a diminished risk to individual privacy 
and health information security.
    Several commenters noted that the lack of a UPI impacted 
interoperability, but finding a suitable and consistent matching 
strategy could address this issue. These commenters often specifically 
supported Congress' guidance to have ONC and CMS provide technical 
assistance to the private sector to identify this strategy. To help 
jump start the process of finding a solution to patient matching, ONC 
launched the Patient Matching Algorithm Challenge in 2017, awarding six 
winners $75,000 in grants in late 2017 (https://www.patientmatchingchallenge.com/challenge-information/challenge-details). The goal of the Patient Matching Algorithm Challenge was to 
bring about greater transparency and data on the performance of 
existing patient matching algorithms, spur the adoption of performance 
metrics for patient data matching algorithm vendors, and positively 
impact other aspects of patient matching such as deduplication and 
linking to clinical data.
    We continue to support ONC's work promoting the development of 
patient matching initiatives. Per Congress' guidance, ONC is looking at 
innovative ways to provide technical assistance to private sector-led 
initiatives to further develop accurate patient matching solutions in 
order to promote interoperability without requiring a UPI.
    We understand the significant health information privacy and 
security concerns raised around the development of a UPI standard and 
the current prohibition against using HHS funds to adopt a UPI 
standard. Recognizing Congress' statement regarding patient matching 
and stakeholder comments stating that a patient matching solution would 
accomplish the goals of a UPI, we seek comment for future consideration 
on ways for ONC and CMS to continue to facilitate private sector 
efforts on a workable and scalable patient matching strategy so that 
the lack of a specific UPI does not impede the free flow of 
information. We also seek comment on how we may leverage our program 
authority to provide support to those working to improve patient 
matching. In addition, we intend to use comments for the development of 
policy and future rulemaking.
2. Lack of Standardization
    Lack of standardization inhibits the successful exchange of health 
information without additional effort on the part of the end user. To 
achieve secure exchange of health information across health IT products 
and systems that can be readily used without special effort by the 
user, both the interface technology and the underlying data must be 
standardized, so all systems are ``speaking the same language.'' 
Consistent use of modern computing standards and applicable content 
standards (such as clinical vocabularies) are fundamental to achieving 
full-scale technical interoperability (systems can connect and exchange 
data unaltered) and semantic interoperability (systems can interpret 
and use the information that has been exchanged). Lack of such 
standards creates a barrier to

[[Page 7616]]

interoperability. Where specific standards are not consistently used, 
particularly to structure exchange interfaces such as APIs, the 
exchange is more difficult and expensive than it needs to be and the 
recipient of exchanged data must often undertake substantial special 
effort to make sense of the information.
    In this proposed rule, similar to CMS' Blue Button 2.0 approach for 
Medicare FFS,\3\ we propose to require that all MA organizations, 
Medicaid managed care plans, CHIP managed care entities, Medicaid state 
agencies, CHIP agencies that operate FFS systems, and issuers of QHPs 
in the FFEs, deploy standardized, open APIs to make certain information 
available to enrollees as discussed in section III. of this proposed 
rule.
---------------------------------------------------------------------------

    \3\ We refer readers to https://bluebutton.cms.gov for more 
information related to the CMS Blue Button initiative.
---------------------------------------------------------------------------

    The lack of a sufficiently mature API functionality technical 
standard has posed a challenge and impediment to advancing 
interoperability. In 2015, ONC finalized an API functionality 
certification criterion in the ``2015 Edition Health Information 
Technology (Health IT) Certification Criteria, 2015 Edition Base 
Electronic Health Record (EHR) Definition, and ONC Health IT 
Certification Program Modifications'' Final Rule (2015 Edition final 
rule) (80 FR 62602). However, while a consensus technical standard 
specific to the API technical functionality was in development, it had 
not yet matured enough for inclusion in the 2015 Edition final rule, 
which does not identify a specific standard for API functionality.
    As discussed in greater detail in section II of this proposed rule, 
we believe that a specific foundational standard for API functionality 
has matured sufficiently enough for ONC to propose it for HHS adoption 
(published elsewhere in this issue of the Federal Register). To take 
full advantage of this proposed standard, as well as already adopted 
standards applicable to content exchanged via APIs, we propose in 
sections II. and III. of this proposed rule to require that MA 
organizations, Medicaid managed care plans, Medicaid state agencies, 
CHIP managed care entities, CHIP agencies that operate FFS systems, and 
QHP issuers in FFEs comply with the ONC-proposed regulations for this 
standard. Those proposed regulations would require deployment of API 
technologies conformant with the API technical standard proposed by ONC 
for HHS adoption at 45 CFR 170.215 and other applicable standards such 
as content and vocabulary standards adopted at 45 CFR part 162 and 42 
CFR 423.160, and proposed by ONC for HHS adoption at 45 CFR 170.213 
(published elsewhere in this issue of the Federal Register). 
Furthermore, we note that we intend to continue to work with 
stakeholders to develop standards that will advance interoperability.
3. Information Blocking
    As explained above, information blocking is defined in section 
3022(a) of the PHSA. Understanding this definition, information 
blocking could be considered to include the practice of withholding 
data, or intentionally taking action to limit or restrict the 
compatibility or interoperability of health IT. Through stakeholder 
outreach, roundtables, and letters we have received, we understand that 
health care providers may limit or prevent data exchange in an effort 
to retain patients. By withholding a patient's health information from 
competing health care providers, a health care provider can effectively 
inhibit a patient from freely moving within the health care market 
because that patient would not otherwise have access to their complete 
health information.
    We additionally understand from stakeholder feedback that in 
certain cases a health IT vendor has prohibited the movement of data 
from one health IT system to another in an effort to maintain their 
customer base.
    Information blocking is a significant threat to interoperability 
and can limit the ability for providers to coordinate care and treat a 
patient based on the most comprehensive information available. In 
sections VIII.B. and C. of this proposed rule we propose to publicly 
report the names of clinicians and hospitals who submit a ``no'' 
response to certain attestation statements related to the prevention of 
information blocking in order to deter health care providers from 
engaging in conduct that could be considered information blocking.
    Preventing and avoiding information blocking is important to 
advancing interoperability. We believe this proposal would help 
discourage health care providers from information blocking and clearly 
indicates CMS's commitment to preventing such practices.
4. Lack of Adoption/Use of Certified Health IT Among Post-Acute Care 
(PAC) Providers
    PAC facilities are critical in the care of patients' post-hospital 
discharge, and can be a determining step in the health progress for 
those patients.\4\ Interoperable health IT can improve the ability of 
these facilities to coordinate and provide care; however, long-term 
care and PAC providers, such as nursing homes, home health agencies 
(HHAs), long-term care providers, and others, were not eligible for the 
EHR Incentive Programs under the HITECH Act. Based on the information 
we have, we understand that this was a contributing factor to these 
providers not adopting CEHRT at the same rate as eligible hospitals and 
physicians, who were able to adopt CEHRT using the financial incentives 
provided under the programs.5 6
---------------------------------------------------------------------------

    \4\ https://www.healthit.gov/sites/default/files/electronic-health-record-adoption-and-interoperability-among-u.s.-skilled-nursing-facilities-in-2016.pdf.
    \5\ https://aspe.hhs.gov/report/opportunities-engaging-long-term-and-post-acute-care-providers-health-information-exchange-activities-exchanging-interoperable-patient-assessment-information/hit-and-ehr-certification-ltpac.
    \6\ https://www.healthit.gov/sites/default/files/pdf/HIT_LTPAC_IssueBrief031513.pdf.
---------------------------------------------------------------------------

    While a majority of skilled nursing facilities (SNFs) used an EHR 
in 2016 (64 percent), there is considerable work to be done to increase 
adoption and the exchange of data in this provider population. In that 
same year, only three out of 10 SNFs electronically exchanged (that is, 
sent or received) key clinical health information, and only 7 percent 
had the ability to electronically send, receive, find, and integrate 
patient health information. In 2017, an ONC survey found that more HHA) 
(78 percent) adopted EHRs than SNFs (66 percent), but integration of 
received information continued to lag behind for both HHAs (36 percent) 
and SNFs (18 percent). While both ONC surveys focused on SNFs, it is 
important to note the large provider overlap between SNFs and other 
nursing facilities. In 2014, 14,409 out of 15,640 (92 percent) of 
nursing homes were certified for both Medicare and Medicaid.\7\
---------------------------------------------------------------------------

    \7\ https://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/CertificationandComplianc/Downloads/nursinghomedatacompendium_508-2015.pdf.
---------------------------------------------------------------------------

    Long-term hospitals, inpatient rehabilitation facilities (IRFs), 
SNFs, and HHAs are required to submit to CMS standardized patient 
assessment data described in section 1899B(b)(1) of the Act (as added 
by section 2(a) of the Improving Medicare Post-Acute Care 
Transformation Act of 2014 (IMPACT Act) (Pub. L. 113-185, enacted 
October 6, 2014)). We have defined the term ``standardized patient 
assessment data'' (or ``standardized resident assessment data'' for 
purposes of SNFs) as patient or resident assessment questions and

[[Page 7617]]

response options that are identical in all four PAC assessment 
instruments, and to which identical standards and definitions apply. 
Section 1899B(b)(1)(B) of the Act states that the categories for which 
standardized patient or resident assessment data must be submitted 
include, at a minimum, functional status; cognitive function; medical 
conditions and co-morbidities; special services, treatments and 
interventions; and impairments. Section 1899B(b)(1)(A) of the Act 
requires that such data must be submitted through the applicable 
reporting provision that applies to each PAC provider type using the 
PAC assessment instrument that applies to the PAC provider. Section 
1899B(a)(1)(B) of the Act additionally requires that these data be 
standardized and interoperable so as to allow for their exchange among 
health care providers, including PAC providers, to ensure coordinated 
care and improved Medicare beneficiary outcomes as these patients 
transition throughout the care continuum. To enable the interoperable 
exchange of such information, we have adopted certain patient 
assessment data elements as standardized patient or resident assessment 
data and mapped them to appropriate health IT standards which can 
support the exchange of this information. For more information, we 
refer the reader to the CMS website at https://del.cms.gov/DELWeb/pubHome.
5. Privacy Concerns and HIPAA
    The Privacy, Security, and Breach Notification Rules under HIPAA 
(45 CFR parts 160 and 164) support interoperability by providing 
assurance to the public that PHI as defined in 45 CFR 160.103 is 
maintained securely and shared only for appropriate purposes or with 
express authorization of the individual. For more than a decade, the 
HIPAA Rules have provided a strong privacy and security foundation for 
the health care system. However, we have heard that lack of 
harmonization between federal and state privacy and security standards 
can create uncertainty or confusion for HIPAA covered entities that 
want to exchange health information. Resources about how the HIPAA Rule 
permits health care providers and health plans to share health 
information using health IT for purposes like treatment or care 
coordination is available on the HHS OCR website. See https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/permitted-uses/.
    Although barriers to interoperability do exist, HHS and private 
industry are actively working to address them. On June 6, 2018, the HHS 
Deputy Secretary initiated the Regulatory Sprint to Coordinated Care 
(RS2CC). In support of this effort, the HHS Office of Inspector General 
(OIG) released an RFI on barriers to coordinated care or value-based 
care, which was out for public comment through October 26, 2018 (83 FR 
43607). Together, CMS and ONC are working to address information 
blocking via rulemaking. We are actively working to improve data 
standardization, particularly through the use of APIs. And, we are 
using available policy levers to encourage greater adoption of EHR 
technology and interoperability among PAC providers. We provide 
resources to help providers see how HIPAA and interoperability work 
together. And, we are leveraging private sector relationships to find 
patient matching solutions in lieu of a patient identifier.

F. Summary of Major Provisions

    To empower beneficiaries of Medicaid and CHIP FFS programs and 
enrollees in MA organizations, Medicaid and CHIP managed care entities, 
and QHP issuers in the FFEs (when mentioned throughout this proposed 
rule, this includes QHPs certified by FFEs regardless of whether 
enrollees enroll through the FFE or off the FFE), we are proposing 
several initiatives to break down the barriers that impede patients' 
ease of access to their electronic health care information; we propose 
to create and implement new mechanisms for them to access to their own 
health care information, as well as the ability to decide how, when, 
and with whom to share their information. We are proposing to require 
that a variety of information be made accessible to these impacted 
patients via ``openly published'' (or simply ``open'') APIs- that is, 
APIs for which the technical and other information required for a 
third-party application to connect to them is publicly available. This 
will provide these patients with convenient access to their health care 
information in accordance with the HIPAA Privacy Rule access standard 
at 45 CFR 164.524, and an increase in their choice of applications with 
which to access and use their own electronic health information, as 
discussed above, and other information relevant to managing their 
health, enabling open APIs to improve competition and choice as they 
have in other industries. We propose to require MA organizations, 
Medicaid state agencies, state CHIP agencies, Medicaid managed care 
plans, CHIP managed care entities, and QHP issuers in FFEs (by 
requiring them to comply with the proposed ONC standard) to implement 
open APIs consistent with the API technical standards proposed by ONC 
for adoption by HHS and to use content and vocabulary standards adopted 
by HHS at 45 CFR part 162 and 42 CFR 423.160, and proposed by ONC for 
adoption by HHS at 45 CFR 170.213 (published elsewhere in this issue of 
the Federal Register).
    Effective coordination and appropriate sharing of enrollee 
information between health plans can reduce the need for providers to 
write duplicative letters of medical necessity, or it could reduce 
instances of subjecting beneficiaries to unnecessary repetition of step 
therapy, or repeated utilization reviews, risk screenings and 
assessments. It could also help to streamline prior authorization 
procedures or reduce instances where the clinician might need to 
intervene personally with a payer to ensure his or her patient received 
the treatment necessary. We are proposing to require payers to support 
beneficiaries in coordinating their own care via payer to payer care 
coordination. In addition to existing care coordination efforts between 
plans, we propose that a plan must, if asked by the beneficiary, 
forward his or her information to a new plan or other entity designated 
by the beneficiary for up to 5 years after the beneficiary has 
disenrolled with the plan. Such transactions would be made in 
compliance with applicable laws. We are proposing a requirement for MA 
Plans, Medicaid and CHIP Managed Care entities (MCOs, PIHPs, PAHPs), 
and QHP issuers in FFEs to coordinate care between plans by exchanging, 
at a minimum, the data elements in the United States Core Data for 
Interoperability (USCDI) standard \8\ at enrollee request at specified 
times.
---------------------------------------------------------------------------

    \8\ For more information on the USCDI, see https://www.healthit.gov/USCDI.
---------------------------------------------------------------------------

    We believe that payers' ability to share enrollee claims, encounter 
data, utilization history, and clinical health information they may 
have for their enrollees with one another, as well as their ability to 
share that information with patients and health care providers, when 
approved by the patient and appropriate under applicable law, using 
interoperable electronic means will considerably improve patient access 
to information, reduce provider burden, and reduce redundant and 
otherwise unnecessary data-related policies and procedures. We are 
proposing to require that all MA organizations, Medicaid and CHIP 
Managed Care entities (MCOs, PIHPs, and PAHPs), and QHP issuers in FFEs 
(with the exception of stand-alone dental plans (SADPs)) must 
participate in a trusted health information exchange network meeting 
criteria for

[[Page 7618]]

interoperability. Further, we discuss an approach to payer-to-payer and 
payer-to-provider interoperability which leverages such existing trusts 
networks.
    States and CMS routinely exchange data to support the 
administration of benefits to Medicare-Medicaid dually eligible 
beneficiaries. This includes ``buy-in'' data on who is enrolled in 
Medicare, and who is liable for paying the dual eligible beneficiary's 
Part A and B premiums. Buy-in data exchanges support state, CMS, and 
Social Security Administration (SSA) premium accounting, collections, 
and enrollment functions. This also includes ``MMA'' data on dual 
eligibility status (called the ``MMA file'' after the Medicare 
Prescription Drug, Improvement and Modernization Act of 2003 (MMA) 
(Pub. L. 108-173, enacted December 8, 2003)), which are used in all 
four Parts of Medicare. We are proposing to establish frequency 
requirements to require all states to participate in daily exchange of 
buy-in data with CMS by April 1, 2022, and to update frequency 
requirements to require all states to submit MMA file data to CMS daily 
by April 1, 2022.
    We are actively working with our partners throughout HHS to deter 
the practice of information blocking. We believe it would benefit 
patients to know if their health care providers attested negatively to 
any of the prevention of information blocking attestation statements 
under the Quality Payment Program (QPP) or the Medicare FFS Promoting 
Interoperability Program. In previous testing with patients and 
caregivers, we have learned that effective use of CEHRT is important to 
them when making informed health care decisions. To address this issue, 
we are proposing to publicly post information about negative 
attestations on appropriate CMS websites.
    Section 4003 of the Cures Act recognized the importance of making 
provider digital contact information available through a common 
directory. To facilitate this, CMS has updated the National Plan and 
Provider Enumeration System (NPPES) to be able to capture this digital 
contact information. Now that the systems are in place, we seek to 
increase the number of clinicians with valid and current digital 
contact information available through NPPES. We are proposing to 
publicly identify those clinicians who have not submitted digital 
contact information in NPPES. Further, we are proposing to align 
program requirements for MA organizations, Medicaid state agencies, 
Medicaid managed care plans, CHIP agencies that operate FFS systems, 
CHIP managed care entities, and QHP issuers in FFEs (with the exception 
of issuers of SADPs) such that each payer/plan issuer would make 
provider directory information publicly available via an API.
    Electronic patient event notifications from hospitals, or clinical 
event notifications, are widely recognized as an effective tool for 
improving care coordination across settings, especially for patients at 
admission, discharge, and transfer. We are proposing to revise the 
conditions of participation for hospitals (including short-term acute 
care hospitals, long-term care hospitals (LTCHs), rehabilitation 
hospitals, psychiatric hospitals, children's hospitals, and cancer 
hospitals) and CAHs to require that these entities send patient event 
notifications to another health care facility or to another community 
provider. We propose to limit this requirement to only those Medicare- 
and Medicaid-participating hospitals and CAHs that possess EHRs systems 
with the technical capacity to generate information for electronic 
patient event notifications.
    We also plan to test ways to promote interoperability across the 
health care spectrum through models tested by the Center for Medicare 
and Medicaid Innovation (``Innovation Center''). Innovation Center 
models offer a unique opportunity to engage with health care providers 
and other entities in innovative ways and to test concepts that have 
the ability to accelerate change in the U.S. health care system, 
including to promote interoperability. As such, we are soliciting 
public comment on general principles around interoperability within 
Innovation Center models for integration into new models, through 
provisions in model participation agreements or other governing 
documents. In applying these general principles, we intend to be 
sensitive to the details of individual model design, and the 
characteristics and capacities of the participants in each specific 
model.
    One of the many proposals we considered but did not include in this 
proposed rule was a proposal to make updates to the Promoting 
Interoperability Program (formerly the Medicare and Medicaid EHR 
Incentive Programs) to encourage eligible hospitals and CAHs to engage 
in certain activities focused on interoperability. This concept was 
initially introduced in a request for public comment in the FY 2019 
IPPS/LTCH PPS proposed rule (83 FR 20537 through 20538). We discussed a 
possible future strategy in which we would create a set of priority 
health IT or ``interoperability'' activities that would serve as 
alternatives to measures in the Promoting Interoperability Program. We 
discussed creating a set of priority health IT activities with a focus 
on interoperability and simplification to reduce health care provider 
burden while allowing flexibility to pursue innovative applications of 
health IT to improve care delivery. We offered three different examples 
of activities which might be included under such an approach, 
including:
     Participation in, or serving as, a health information 
network which is part of the Trusted Exchange Framework and Common 
Agreement (TEFCA);
     Maintaining an open API which allows persistent access to 
third parties which enables patients to access their health 
information; and
     Participating in piloting and testing of new standards 
that support emerging interoperability use cases.
    While we are not proposing this here, we expect to introduce a 
proposal for establishing ``interoperability activities'' in the FY 
2020 IPPS/LTCH PPS rulemaking in conjunction with other updates to the 
Promoting Interoperability Program. To help inform future rulemaking, 
we invite comments on the concepts discussed above, as well as other 
ideas for ``interoperability activities'' for which eligible hospitals 
and CAHs could receive credit in lieu of reporting on program measures.
    Finally, we include two RFIs. 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.

II. Technical Standards Related to Interoperability

A. Technical Approach and Standards

1. Use of FHIR for APIs
    The MACRA defines 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 such as 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 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

[[Page 7619]]

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. As noted at the outset of this proposed rule, for the 
purposes of this proposed rule and this specific section, we will use 
the PHSA definition.
    We believe the PHSA definition of interoperability is useful as a 
foundational reference for our approach to advancing 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 plan issuers and 
administrators need to efficiently exchange multiple types of relevant 
data. We note the PHSA definition of interoperability is not applied 
only to a specific program or initiative but to all activities under 
the title of the PHSA that establishes ONC's responsibilities to 
support and shape the health information ecosystem, including exchange 
infrastructure for the United States health care system as a whole. The 
PHSA definition of interoperability is also consistent with HHS's 
vision and strategies for achieving a health information ecosystem 
within which all individuals, their families, and health care providers 
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,\9\ as well as to support consumer choice of health 
plans and providers.
---------------------------------------------------------------------------

    \9\ See, for example, ONC ``Connecting Health and Care for the 
Nation: A Shared Nationwide Interoperability Roadmap'' Final Version 
1.0 (2015): https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1Nor.0.pdf.
---------------------------------------------------------------------------

    A core policy principle we aim to support across all proposals in 
this proposed 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. This includes two types of information: Information 
specifically about the individual that requires appropriate diligence 
to protect the individual's privacy, such as their current and past 
medical conditions and care received, as well as information that is of 
general interest and should be widely available, such as plan provider 
networks, the plan's formulary, and coverage policies.
    While many consumers today can often access their own electronic 
health information through patient/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.
    In contrast, consider the ease with which consumers can choose and 
use a navigation application which integrates information on their 
current location, preferences, and real-time traffic conditions to 
choose the best route to a chosen destination. Consumers do not have to 
log into a different ``location'' portal to learn their current 
geographic coordinates, write them down, and then log into a separate 
``map'' portal to enter their current coordinates to request directions 
to their destination.
    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. 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\
---------------------------------------------------------------------------

    \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 are 
proposing in this rule to use our programmatic authority in Medicare, 
Medicaid, CHIP, and over QHPs in FFEs to advance these goals. 
Therefore, we are proposing to require that a variety of data be made 
accessible to MA enrollees, Medicaid beneficiaries, CHIP enrollees, and 
enrollees in QHPs in FFEs, by requiring that MA organizations, Medicaid 
state agencies, Medicaid managed care plans, CHIP agencies, CHIP 
managed care entities, and QHPs in FFEs, adopt and implement ``openly 
published'' (or simply ``open'') APIs. Having certain data available 
through open APIs would allow these enrollees to use the application of 
their choice to access and use their own electronic health information 
and other information relevant to managing their health.
    Much like our efforts under the Medicare Blue Button 2.0 and 
MyHealthEData initiatives, which made Parts A, B, and D claims data 
available to Medicare beneficiaries, our proposal would result in 
claims and coverage information being accessible for the vast majority 
of Medicare beneficiaries by requiring MA organizations to take new 
steps--by implementing the API described in this proposed rule--to make 
claims data available to their enrollees. We expect that our proposal 
would also benefit all Medicaid beneficiaries because our proposal 
applies to Medicaid state agencies (which administer Medicaid FFS 
programs), and all types of Medicaid managed care plans (MCOs, PIHPs, 
and PAHPs), and CHIP agencies (which administer CHIP FFS) and CHIP 
managed care entities (MCOs, PIHPs, and PAHPs). Finally, while our 
proposal is only applicable to QHPs in FFEs, we hope that states 
operating Exchanges might consider adopting similar requirements for 
QHPs in State-Based Exchanges (SBEs), and that other payers in the 
private sector might consider voluntarily offering data accessibility 
of the type included in this proposal 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. We hope that the example being set by CMS will raise consumers' 
expectations and encourage other payers in the market to take similar 
steps to advance patient access and empowerment outside the scope of 
our proposed requirements.
    An ``open API,'' for purposes of this proposed rule, is simply one 
for which the technical and other information required for a third-
party application to connect to it is openly published. Open API does 
not imply any and all applications or application developers would have 
unfettered access to people's personal or sensitive information. 
Rather, an open API's published technical and other information 
specifically includes what an application developer would need to

[[Page 7620]]

know to connect to and obtain data available through the API.
    We recommend reviewing the discussion of the standardized API 
criterion and associated policy principles and technical standards 
included in ONC's proposed rule ``21st Century Cures Act: 
Interoperability, Information Blocking, and the ONC Health IT 
Certification Program'' (published elsewhere in this issue of the 
Federal Register) for those seeking more detailed information on API 
functionality and interoperability standards relevant to electronic 
health information. While that discussion is specific to health IT 
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 includes 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 open API. However, it is important to reiterate that we are not 
proposing to require health plan issuers 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.
    In developing this proposed rule, we considered how to advance the 
sort of interoperability and innovation in the health system supported 
by open APIs in other industries. We have also collaborated with ONC to 
align with and leverage relevant API policies ONC has proposed to 
implement Cures Act requirements. In general, we believe three 
attributes of open APIs are particularly important to achieve the goal 
of offering individuals convenient access, through applications they 
choose, to available and relevant electronic health information. The 
three API attributes are:
     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 this section, we discuss these concepts generally and how they 
are applicable in the health care context for all payers, as well as 
explain how these are relevant to our specific proposals, which are 
discussed in detail in section III. of this proposed rule.
a. Standardized
    Technical consistency and implementation predictability are 
fundamental to scale API-enabled interoperability and reduce the level 
and costs of custom development otherwise necessary to access, 
exchange, and use health information. From an industry standpoint, a 
consistent and predictable set of API functions, as well as content and 
formatting standards, provide the health IT ecosystem with known 
technical requirements against which application developers can build 
applications (including but not limited to ``mobile apps'') and other 
innovative services which users can select to access and manage the 
data they need. Therefore, to achieve interoperability consistent with 
the PHSA definition, the proposals in section III. of this proposed 
rule would effectively require that API technologies deployed by health 
plans subject to this rule use modern computing standards (such as 
RESTful interfaces \11\ and XML/JSON), and present the requested 
information using widely recognized content standards (such as 
standardized vocabularies of clinical terms), where applicable.
---------------------------------------------------------------------------

    \11\ ``RESTful interfaces'' are those that are consistent with 
Representational State Transfer (REST) architectural style and 
communications approaches to web services development.
---------------------------------------------------------------------------

b. Transparent
    Transparency and openness around API documentation is commonplace 
in many other industries and has fueled innovation, growth, and 
competition. Documentation associated with APIs deployed by health care 
providers, health plans, and other entities engaged in exchanging 
electronic health information typically addresses the information that 
would be material to persons and entities that use or create software 
applications that interact with the API (API users). Information 
material to API users includes, but is not necessarily limited to, all 
terms and conditions for use of the API, including terms of service, 
restrictions, limitations, obligations, registration process 
requirements, or other similar requirements that would be needed to:
     Develop software applications to interact with the API;
     Connect software applications to the API to access 
electronic health information through the API;
     Use any electronic health information obtained by means of 
the API technology; and
     Register software applications to connect with the API.
    As discussed in section III. of this proposed rule, we are 
proposing that certain entities (MA organizations, State Medicaid 
agencies, Medicaid managed care plan, State CHIP agencies, CHIP managed 
care entities, and QHPs in FFEs), supported by the suppliers of their 
API technology, and for the API technology they use to comply with the 
requirements we propose in this proposed rule, be required to make 
freely and publicly accessible the specific business and technical 
documentation necessary to interact with these APIs. Thus, we propose 
to require that these entities comply with the requirements that ONC 
has proposed that the Secretary adopt for developers and users of 
health IT certified to the API criteria at 45 CFR 170.315 (published 
elsewhere in this issue of the Federal Register).
c. Pro-Competitive
    Pro-competitive practices in selecting, configuring, and 
maintaining APIs are those business practices that promote the 
efficient access to, exchange of, and use of electronic health 
information to support a competitive marketplace that enhances consumer 
value and choice of direct-to-consumer technology, health coverage, and 
care. We believe that an ultimate goal of all participants in the 
health care ecosystem is that individuals should be able to use an 
application they choose to connect and access, without special effort, 
their electronic health information held by health care providers, 
health plans, or any health information networks, within practical and 
prudent limits that do not needlessly hinder their ability to connect 
to the API in a persistent manner.
    Such acceptable limits include technical compatibility and ensuring 
the application does not pose an unacceptable level of risk to a system 
when connecting to an API offered by that system, consistent with the 
HIPAA Privacy and Security Rules and guidance issued by the HHS 
OCR,\12\ to which the Secretary delegated the authority to enforce 
HIPAA privacy and security requirements. Organizational policies and 
procedures needed to comply with any additional requirements under 
state laws that would apply in a given situation would also be viewed 
as necessary and not anti-competitive. Examples of practices

[[Page 7621]]

we would view as pro-competitive might include proactively advising 
enrollees they are not required to use only the organization's own or 
preferred applications to access, use, and share their health 
information. Such advice would be publicly available and include 
information relevant to the enrollee about how they could request 
access to their information through a third-party application of their 
choosing.
---------------------------------------------------------------------------

    \12\ OCR enforces federal civil rights laws, conscience and 
religious freedom laws, the Health Insurance Portability and 
Accountability Act of 1996 (HIPAA) Privacy, Security, and Breach 
Notification Rules, and provisions of the Patient Safety and Quality 
Improvement Act of 2005 (PSQIA) and the Patient Safety Rule 
(codified at 42 CFR part 3 (73 FR 70732)) protecting the 
confidentiality and privilege of patient safety work product as 
defined in PSQIA and 42 CFR part 3. Thus, within HHS, OCR has lead 
responsibility for interpreting, administering, and enforcing HIPAA 
regulations and developing guidance.
---------------------------------------------------------------------------

    We recognize that organizations subject to the open API 
requirements proposed in section III. of this proposed rule need to 
take reasonable and necessary steps to fulfill the organizations' 
duties under all applicable laws and regulations to protect the privacy 
and security of personally identifiable information (PII), including 
but not limited to PHI under HIPAA as defined at 45 CFR 160.103; those 
privacy and security protection obligations remain applicable even in 
the context of complying with our proposal. However, we do not believe 
it is appropriate to use security and privacy concerns as an 
opportunity to engage in anti-competitive practices. Anti-competitive 
practices might include declining to assess the technical compatibility 
or security risk of an application provided to prospective enrollees by 
a competing plan, despite an enrollee request to disclose their PHI to 
that application through the API.
2. Privacy and Security Concerns in the Context of APIs
    We have received a wide range of stakeholder feedback on privacy 
and security issues in response to prior proposals \13\ about policies 
related to APIs that would allow consumers to use any app of their 
choosing to access PHI held by a HIPAA covered entity. This feedback 
includes concerns about potential security risks to PHI created by an 
API connecting to third-party applications.
---------------------------------------------------------------------------

    \13\ For instance, see discussion of stakeholder comments in the 
2015 Edition final rule at 80 FR 62676.
---------------------------------------------------------------------------

    We appreciate these concerns. Deploying API technology that offers 
consumers the opportunity to access their electronic health information 
that is held by a covered entity (which includes but is not limited to 
MA organizations, the Medicare Part A and B programs, the Medicaid 
program, CHIP, QHP issuers on the FFE, and other health plan issuers) 
does not lessen the covered entity's duties under HIPAA and other law 
to protect the privacy and security of information it holds, 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.
    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 state repeatedly throughout this 
proposed rule, nothing in this proposed rule is intended to alter or 
should be construed as altering existing responsibilities to protect 
PHI under the HIPAA Rules and requirements.
    However, we note that a number of stakeholders may believe that 
they are responsible for determining whether an application to which an 
individual directs their PHI be disclosed applies appropriate 
safeguards for the information it receives. Based on the OCR guidance 
discussed below, 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.
    Under the HIPAA Privacy Rule,\14\ individuals have the right of 
access to inspect and receive a copy of a defined set of their PHI as 
detailed at 45 CFR 164.501. Specifically, as OCR has indicated in 
regulations and guidance, an individual can exercise their right of 
access to direct a covered entity to send their information to a third 
party. When responding to an access request, ``the same requirements 
for providing the PHI to the individual, such as the timeliness 
requirements, fee limitations, prohibition on imposing unreasonable 
measures, and form and format requirements, apply when an individual 
directs that the PHI be sent to another person or entity.'' \15\ 
Moreover, a covered entity may not impose unreasonable measures on an 
individual requesting access that serve as barriers to or unreasonably 
delay the individual from obtaining access to their PHI.\16\
---------------------------------------------------------------------------

    \14\ 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/.
    \15\ See Sec.  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/, 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/.
    \16\ See, generally, the ``unreasonable measures'' heading of 
OCR HIPAA for professionals information web page at https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/. See also FAQ 2039--https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/; FAQ 2060: https://www.hhs.gov/hipaa/for-professionals/faq/2060/do-individuals-have-the-right-under-hipaa-to-have/; FAQ 2040: https://www.hhs.gov/hipaa/for-professionals/faq/2040/what-is-a-covered-entitys-obligation-under/.
---------------------------------------------------------------------------

    We refer readers to further OCR guidance on related issues, 
including: The liability of a covered entity in responding to an 
individual's access request to send the individual's PHI to a third 
party (FAQ 2039); \17\ individuals' rights under HIPAA to have copies 
of their PHI transferred or transmitted to them in the manner they 
request, even if the requested mode of transfer or transmission is 
unsecure (FAQ 2060); \18\ and, a covered entity's obligation under the 
HIPAA Breach Notification Rule if it transmits an individual's PHI to a 
third party designated by the individual in an access request, and the 
entity discovers the information was breached in transit (FAQ 
2040).\19\ Under the HIPAA Privacy Rule, as explained in OCR's 
interpretive guidance, ``individuals have the right under HIPAA to have 
copies of their PHI transferred or transmitted to them in the manner 
they request . . . as long as the PHI is `readily producible' in the 
manner requested, based on the capabilities of the covered entity and 
transmission or transfer in such a manner would not present an 
unacceptable level of security risk to the PHI on the covered entity's 
systems, such as risks that may be presented by connecting an outside 
system, application, or device directly to a covered entity's systems 
(as opposed to security risks to PHI once it has left the systems)'' 
(HIPAA FAQ 2060).\20\
---------------------------------------------------------------------------

    \17\ https://www.hhs.gov/hipaa/for-professionals/faq/2039/what-is-the-liability-of-a-covered-entity-in-responding/.
    \18\ https://www.hhs.gov/hipaa/for-professionals/faq/2060/do-individuals-have-the-right-under-hipaa-to-have/.
    \19\ https://www.hhs.gov/hipaa/for-professionals/faq/2040/what-is-a-covered-entitys-obligation-under/.
    \20\ https://www.hhs.gov/hipaa/for-professionals/faq/2060/do-individuals-have-the-right-under-hipaa-to-have/.
---------------------------------------------------------------------------

    We have also noted stakeholder concerns about protections which 
apply to non-covered entities such as direct-

[[Page 7622]]

to-consumer applications. Stakeholders, as well as covered entities who 
may be required to send PHI to these applications, have noted concerns 
that unscrupulous actors could deploy direct-to-consumer applications 
specifically in order to profit from obtaining, using, or disclosing 
individuals' PHI (and potentially other information) in ways the 
individual either did not authorize or to which the individual would 
not knowingly consent.
    When a non-HIPAA-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 the FTC Act to investigate and take 
action against unfair or deceptive trade practices. The FTC has applied 
this authority to a wide variety of entities. The FTC also enforces the 
FTC Health Breach Notification Rule, which applies to certain types of 
entities that fall outside of the scope of HIPAA, and therefore, are 
not subject to the HIPAA Breach Notification Rule.\21\
---------------------------------------------------------------------------

    \21\ https://www.healthit.gov/sites/default/files/non-covered_entities_report_june_17_2016.pdf.
---------------------------------------------------------------------------

    We recognize 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 propose in section 
III. of this proposed rule specific requirements on the payers subject 
to these proposed regulations 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 
lodge a complaint if they believe a HIPAA covered entity or business 
associate may have breached their duties under HIPAA or if they believe 
they have been subjected to unfair or deceptive actions or practices 
related to a direct-to-consumer application's privacy practices or 
terms of use.
    In some circumstances, information that would be required to be 
made available through an API per an enrollee's information request 
under this proposed rule--which we view as consistent with the 
enrollee's right of access from a covered entity under the Privacy 
Rule--may not be readily transferable through the API. For instance, 
the covered entity may not hold certain information electronically. 
However, such a scenario would in no way limit or alter 
responsibilities and requirements under other law (including though not 
limited to HIPAA Privacy, Security, and Breach Notification Rules) that 
apply to the organizations that would be subject to our proposed 
regulations. Even if the open API access requirements proposed in 
section III.C. of this proposed rule were to be finalized and 
implemented, 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 
encourage HIPAA covered entities or business associates to review the 
OCR website for resources on the individual access standard at https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/ 
to ensure they understand their responsibilities.
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 specific proposals within this rule as described in section 
III.C.2. would impose new requirements on MA organizations, state 
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP 
managed care entities, and QHP issuers in FFEs (excluding issuers of 
SADPs) to implement standardized, transparent APIs. Using the API, 
these entities would be required to provide current and former 
enrollees with certain claims and encounter data and certain specific 
clinical information. These entities would also be required to make 
available through the API information already required to be widely 
available, such as provider directory and plan coverage information. In 
developing our proposal delineating the information that must be 
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 
plan in electronic format that is compatible with the API or that can, 
through automated means, be accurately rendered compatible with 
representation through the API. We were also guided by an intent to 
make available through standardized, transparent API technology all of 
the provider directory and plan coverage information that is held in 
formats readily compatible with the API.
    Both the API technology itself and the data it makes available must 
be standardized to support true interoperability. Therefore, we propose 
in section III.C.2.b. of this proposed rule to require compliance with 
both (1) ONC's 21st Century Cures Act proposed regulations regarding 
content and vocabulary standards for representing electronic health 
information and (2) technical standards for an API by which the 
electronic health information must be made available. For the proposals 
described in section III.C.2.b. of this proposed rule (which include 
purposes other than a HIPAA transaction, which is required to comply 
with standards adopted at 45 CFR part 162), we are proposing these 
requirements to comply with interoperability standards proposed for HHS 
adoption in ONC's 21st Century Cures Act proposed rule (published 
elsewhere in this issue of the Federal Register).
    In proposing to require that regulated entities comply with ONC-
proposed regulations (published elsewhere in this issue of the Federal 
Register), and therefore, use specified standards, we intend to 
preclude regulated entities from implementing API technology using 
alternative technical standards to those ONC proposes for HHS adoption 
at 45 CFR 170.215, including but not limited to those not widely used 
to exchange electronic health information in the U.S. health system. We 
further intend 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. Likewise, by proposing to require use of the content 
and vocabulary standards by requiring compliance with 42 CFR 423.160 
and 45 CFR part 162, and proposed at 45 CFR 170.213, we intend to 
prohibit use of alternative technical 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

[[Page 7623]]

423.160, 45 CFR part 162 and proposed at 45 CFR 170.213.
    While we intend 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 170.215, we recognize 
there may be circumstances which render the use of other content and 
vocabulary alternatives necessary. As discussed below, we propose to 
allow the use of other alternatives in two circumstances. First, where 
other content or vocabulary standards are expressly mandated by 
applicable law, we would allow for 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 would allow for use of any suitable gap-filling 
options, as may be applicable to the specific situation.
    We are using two separate rulemakings because ONC's 21st Century 
Cures Act proposed rule, which includes API interoperability standards 
proposed for HHS adoption, would have broader reach than the scope of 
this proposed rule. At the same time, we wish 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 in FFEs under this 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.
    Requiring that regulated entities comply with the regulations 
regarding standards in ONC's 21st Century Cures Act proposed rule will 
support greater interoperability across the health care system, as 
health IT products and applications that will 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. We welcome public comment on the proposed required 
compliance with regulations regarding standards in this proposed rule 
to those proposed for adoption by HHS through ONC' 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 we believe that the proposed required compliance 
with regulations regarding standards requirements in this proposed rule 
to those proposed by ONC for HHS adoption is the best approach, we seek 
public comment on an alternative by which CMS would separately adopt 
the proposed ONC standards identified throughout this proposed rule, as 
well as future interoperability, content and vocabulary standards. We 
anticipate that any such alternative would include incorporating by 
reference the FHIR and OAuth technical standards and the USCDI content 
and vocabulary standard (described in sections II.A.3.b. and II.A.3.a. 
of this proposed rule, respectively) in CMS regulation, and replacing 
references to ONC regulations at 45 CFR 170.215, 170.213, and 170.205, 
respectively. However, we specifically seek 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 seek 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 factors 
related to the technical aspect of implementing these requirements.

B. Content and Vocabulary Standards

    The HHS-adopted content and vocabulary standards applicable to the 
data provided through the API will 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, state Medicaid and CHIP FFS programs, Medicaid managed 
care plans, CHIP managed care entities, and QHP's in FFEs have 
available electronically. Where another law does not require use of a 
specific standard, we are proposing 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.
    We propose in section III.C.2.b. of this proposed rule that the 
applicable entity must comply with regulations regarding certain 
content and vocabulary standards for data available through the API, 
where applicable to the data type or data element, unless an alternate 
standard is required by other applicable law. Specifically, we propose 
the applicable entity must use:
     Content and vocabulary standard ONC proposes for HHS 
adoption at 45 CFR 170.213 (USCDI Version 1) where such standards are 
the only available standards for the data type or element;
     HIPAA Administrative Simplification transaction standards 
under 45 CFR part 162 or the Part D e-prescribing transaction standards 
at 42 CFR 423.160 where required by other applicable law, or where such 
standards are the only available standards for the data type or 
element; or
     Where a specific data type or element might be encoded or 
formatted using either a 45 CFR part 162 or 42 CFR 423.160 standard or 
the USCDI Version 1 standard at 45 CFR 170.213, the applicable entity 
may use any of these content and vocabulary standards as determined 
appropriate for the data type or element. We describe these proposals 
in more detail below.
    First, we propose in section III.C.2.b. of this proposed rule to 
require compliance with the ONC-proposed regulations regarding the 
content and vocabulary standard at 45 CFR 170.213 as applicable to the 
data type or data element. This is the USCDI Version 1 set of data 
classes that can be supported by commonly used standards, and 
establishes a minimum set of data classes that would be required to be 
interoperable nationwide.\22\ The USCDI is designed to be expanded in 
an iterative and predictable way over time. On behalf of HHS, ONC has 
proposed to adopt the USCDI as a standard in its 21st Century Cures Act 
proposed rule (published elsewhere in this issue of the Federal 
Register). The USCDI Version 1 data sets proposed by ONC for HHS 
adoption at 45 CFR 170.213 also includes the standards that are 
referenced by certification criteria that are also adopted in 45 CFR 
part 170, to which health IT, such as Health IT Modules presented for 
certification under ONC's Health IT Certification Program, must 
conform. Developers of applications are already familiar with and 
commonly using these standards in products that interact with ONC-
certified health IT. The payer and purchaser communities are also aware 
of and commonly using the 45 CFR part 170 standards, and many members 
of these communities actively participate in health-data-focused 
standards development organizations responsible for the creation of 
these standards. As a result, we believe that compliance with 
regulations requiring these standards for

[[Page 7624]]

CMS' programs should not add new burdens to the industry. All standards 
adopted within 45 CFR part 170, including the USCDI standard ONC 
proposes for HHS adoption at 45 CFR 170.213, are, or are proposed by 
ONC to be incorporated by reference by HHS, at 45 CFR 170.299 
(published elsewhere in this issue of the Federal Register).
---------------------------------------------------------------------------

    \22\ For more information on the USCDI, see https://www.healthit.gov/USCDI.
---------------------------------------------------------------------------

    Second, we propose to require that entities use standards specified 
at 45 CFR part 162 for HIPAA transactions as required by applicable 
law, as well as the standards specified at 42 CFR 423.160 for Part D e-
prescribing transactions, as required by applicable law. We reiterate 
that this proposed rule would not alter these other regulations, and 
should not be construed as altering any organization's compliance 
requirements for these other regulations. The standards proposed in 
this regulation are intended for instances where other statutes and 
regulations do not dictate the standard by which regulated parties are 
to convey or otherwise make available electronic information.
    Where there is no legally mandated standard applicable to a 
specific data type or data element in a particular exchange context, 
and the HIPAA Administrative Simplification transaction standards under 
45 CFR part 162 or the Part D e-prescribing transaction standards at 42 
CFR 423.160 are the only standards available for a specific data 
element or type, we propose to require entities subject to these 
proposals to use these HIPAA standards when making data available 
through the API. We further clarify that, for purposes of formatting, 
making available, and sending electronic data under this proposed rule, 
we would require compliance with: (1) The content and vocabulary 
standards identified in 45 CFR part 162 regardless of whether the 
entities are covered entities, and (2) the Part D e-prescribing 
standards in 42 CFR 423.160 to exchange e-prescribing and related data 
(such as drug formulary and preferred drug list data) regardless of 
whether they are conducting a Part D e-prescribing transaction.
    Third, in information exchanges where applicable law does not 
mandate a certain standard and where a specific data type or element 
might be encoded or formatted using the 45 CFR part 162 or 42 CFR 
423.160 standard, or the USCDI Version 1 standard at 45 CFR 170.213, we 
propose in section III.C.2.b. of this proposed rule that the regulated 
entities subject to our proposal would have the freedom to provide data 
through the API that complies with any of these format or encoding 
standards. Specifically, we believe payers should use standards that 
are most efficient and effective based on their existing systems, data 
mapping considerations, or those standards that best meets enrollees' 
needs, while remaining technically practicable for use in conjunction 
with API technology conformant to the 45 CFR 170.215 proposed standards 
(published elsewhere in this issue of the Federal Register), and so 
long as such action is in accordance with applicable laws. For example, 
for data types for which 45 CFR part 162 standards are the only ones 
widely used throughout the payer community, and for specific content 
that payers typically only receive according to these HIPAA standards, 
we believe use of the 45 CFR part 162 content standards to represent 
the information is appropriate and efficient at this juncture. We note 
that for data made available through the API, entities subject to this 
proposal would be required to use the standards identified in this 
proposal even if the exact information to be exchanged through the API 
is also required to be available through other mechanisms.
    Finally, we encourage payers or plans to implement additional, 
widely used, consensus-based standards identified by other means--such 
as by HHS for other purposes or through a consensus standards 
development organization--for additional data in their information 
systems for which no standard is adopted at 45 CFR part 162, 42 CFR 
423.160, or 45 CFR 170.213 to the extent feasible, while maintaining 
compatibility with the required API technical standards. We also 
encourage entities to pilot emerging standards identified by HHS, or by 
a consensus standards development organization through development or 
approval for trial use, where such a pilot maintains compatibility with 
the proposed API technical standards. However, MA organizations, state 
Medicaid and CHIP agencies, Medicaid managed care plans, CHIP managed 
care entities, and QHPs in FFEs that choose to make non-standardized 
data available through their APIs would be required to ensure that 
their API documentation provides sufficient information to an 
application developer for their applications to handle this information 
accurately and automatically. We welcome public comment on these 
proposals.

C. API Standard

    In section III.C.2.b. of this proposed rule, we propose to require 
compliance with the API technical standard proposed by ONC for HHS 
adoption at 45 CFR 170.215 (published elsewhere in this issue of the 
Federal Register). By requiring compliance with 45 CFR 170.215, we are 
proposing in section III.C.2.b. of this proposed rule to require use of 
the foundational Health Level 7 (HL7[supreg]) \23\ Fast Healthcare 
Interoperability Resources (FHIR[supreg]) standard,\24\ several 
implementation specifications specific to FHIR, and complementary 
security and app registration protocols (OAuth 2.0 and OpenID Connect 
Core).
---------------------------------------------------------------------------

    \23\ 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 06/27/2018.)
    \24\ https://www.hl7.org/fhir/overview.html.
---------------------------------------------------------------------------

    The FHIR standard holds great potential for supporting 
interoperability and enabling new entrants and competition throughout 
the health care industry. FHIR leverages modern computing techniques to 
enable users to access health care ``resources'' over the internet via 
a standardized RESTful API. Developers can create tools that interact 
with FHIR APIs to provide actionable data to their stakeholders. In the 
short time since FHIR was first created, the health care industry has 
rapidly embraced the standard through substantial investments in 
industry pilots, specification development, and the deployment of FHIR 
APIs supporting a variety of business needs. With the exception of the 
API Resource Collection in Health (ARCH) (proposed by ONC for HHS 
adoption at 45 CFR 170.215(a)(2)), the API technology standards and 
implementation specifications proposed at 45 CFR 170.215 (published 
elsewhere in this issue of the Federal Register) are consensus 
technical standards that, under the National Technology Transfer & 
Advancement Act of 1995 (Pub. L. 104-113, enacted March 7, 1996) and 
OMB Circular No. A-119, are, where available and their use not 
impracticable, preferred for use in government programs over both 
government-unique standards and standards developed using less rigorous 
consensus processes.
    We note that while all APIs that would be used by software 
applications to provide consumers access to their electronic health 
information would be required to adhere to the foundational FHIR 
standard, and other essential standards such as security protocols 
applicable to the data exchanged, we do not anticipate that all of the 
standards, implementation specifications, and

[[Page 7625]]

protocols proposed at 45 CFR 170.215 will be directly relevant to every 
use case reflected within the policies proposed in this rule. For 
example, authenticating end users' identities may not be needed where 
the information requested and released to an application through the 
API is limited to information otherwise published, such as provider 
directory information otherwise required by the programs' regulations 
to be made widely available.
    We note that an API implemented by regulated entities described in 
section III.C. of this proposed rule is not required to be certified by 
ONC under the ONC Health IT Certification Program for the related 
certification criteria. Furthermore, because the data required to be 
made available by an API as proposed in section III.C. of this proposed 
rule includes information beyond the USCDI Version 1 data set (proposed 
by ONC for HHS adoption at 45 CFR 170.213), certification to the ONC 
certification criteria at 45 CFR 170.215 would not alone be sufficient 
to ensure the API's capacity to support the full range of data elements 
required under the proposal in section III.C. of this proposed rule.
    Finally, we are aware that the implementation specifications 
currently proposed by ONC for HHS adoption at 45 CFR 170.215 (published 
elsewhere in this issue of the Federal Register), in complement to the 
base FHIR foundational standards, leave substantial work to be done by 
health IT developers and their customers to build and deploy technology 
to support the proposals described in section III.C.2.b. of this 
proposed rule. Supplemental technical resources to support efficient 
and successful implementation of the foundational FHIR standard can be 
developed by a variety of organizations. However, we recognize that 
there may be fewer applicable resources to support the development 
required under this rule. Thus, HHS expects to provide organizations 
subject to the policies proposed in this proposed rule with technical 
assistance and subregulatory guidance that incorporates feedback from 
industry. We recommend readers review ONC's 21st Century Cures Act 
proposed rule to fully understand the scope and detail of the API 
standard and content and vocabulary standards proposed by ONC for HHS 
adoption which apply to the proposals included in this proposed rule. 
We further recommend readers review the publicly available resources 
available on the HL7 FHIR standard (https://www.hl7.org/fhir/overview.html) and the USCDI Version 1 standard (https://www.healthit.gov/USCDI), respectively. These publicly available 
materials will inform readers understanding of the requirements under 
this proposed rule and, we expect, will also assist stakeholders in 
drafting comments submitted within this rulemaking proceeding.
    As noted in our proposal in section III.C.2.b. of this proposed 
rule, we have determined to align our proposal to the types of data, 
technology use, and available standards that are consistent with an 
overall HHS approach to support interoperability while mitigating 
provider and developer burden by requiring compliance with applicable 
HHS regulations. We hope to see continued innovation and advancement in 
standards development for identified gaps in health information data 
classes and data elements, as well as improved bi-directional patient 
engagement functionalities. For example, we are not proposing to 
require that organizations subject to the requirements proposed in 
section III.C. of this proposed rule offer patients or providers the 
ability through the API to write information directly to patient 
records held by the organization. However, we hope that organizations 
and their health IT developers build on the API technology we do 
propose to require and accelerate innovation responsive to providers' 
and patients' calls for API write functionality at the fastest pace 
practicable given the maturity of needed standards. We believe this 
innovation may be fostered by the concrete steps forward in data 
exchange and API capabilities we are proposing to require across the 
significant segment of payers subject to this proposed rule.

D. Updates to Standards

    In addition to our efforts to align standards across HHS, we 
recognize 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. In 
order to address how standards development can outpace our rulemaking 
schedule, we propose in section III.C.2.b. of this proposed rule 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 propose to allow use 
of an updated version of a standard if the standard is not prohibited 
under other applicable law. Where a single standard is updated more 
than once in a brief period of time and upon review of the standard HHS 
determines that--to reduce fragmentation and preserve efficacy--only 
the latest of the updated versions should be used. We will publish 
subregulatory guidance to that effect.
    For content and vocabulary standards at 45 CFR part 162 or 42 CFR 
423.160, we propose to allow the use of an updated version of the 
content or vocabulary standard adopted under this 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, or 
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.
    For the content and vocabulary standards proposed by ONC for HHS 
adoption at 45 CFR 170.213 (USCDI Version 1),\25\ as well as for API 
interoperability standards proposed by ONC for HHS adoption at 45 CFR 
170.215 (including HL7 FHIR and other standards discussed above),\26\ 
we propose 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 ONC's 21st Century Cures Act proposed rule (published elsewhere in 
this issue of the Federal Register).
---------------------------------------------------------------------------

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

    As described in the ONC 21st Century Cures Act proposed rule, under 
the proposed ONC Standards Version Advancement Process, ONC would allow 
health IT developers participating in the ONC Health IT certification 
program to voluntarily use updated versions of adopted standards in 
their certified Health IT Modules, so long as certain conditions are 
met. The proposed Standards Version Advancement Process flexibility 
gives health IT developers the option to avoid unnecessary costs and is 
expected to help reduce market confusion by enabling certified Health 
IT Modules to keep pace with standards advancement and market needs. 
Once a standard has been adopted for use in ONC's Health IT 
Certification Program through notice and comment rulemaking, ONC would 
undertake an annual, open and transparent process, including 
opportunity for public comment, to timely ascertain whether a more 
recent version of that standard or implementation specification should 
be approved for developers' voluntary use. ONC expects to use an 
expanded section

[[Page 7626]]

of the Interoperability Standards Advisory (ISA) web platform to 
facilitate the public transparency and engagement process, and to 
publish each year's final list of National Coordinator-approved 
advanced versions that health IT developers could elect to use 
consistent with the Standards Version Advancement Process. (For more 
detail, please see section VIII.B.5. of ONC's 21st Century Cures Act 
proposed rule (published elsewhere in this issue of the Federal 
Register).) We believe that permitting the use of updates to standards 
at 45 CFR 170.213 and 170.215 consistent with the ONC Standards Version 
Advancement Process will enhance alignment and foster improved 
interoperability across the health system.
    In providing flexibility to the plans and payers that will be 
required to implement APIs that use the content and vocabulary 
standards identified in this proposed rule, we also believe it is 
important to maintain compatibility and avoid a disruption or reduction 
in data availability to the end user. Entities subject to the proposed 
regulations seeking to use an updated version of a standard must 
consider factors such as the impact of differences between standards 
versions and the potential burden on developers and end users to 
support transitioning between versions. We expect that these practical 
considerations to maintain compatibility and avoid disruption will 
discourage premature use of new versions of a standard.
    Therefore, we propose in section III.C.2.b. of this proposed rule 
that an entity may use an updated version of a required standard so 
long as use of the updated version does not disrupt an end user's 
ability to access the data available through the API proposed in 
section III. of this proposed rule. Entities that would be required to 
implement an open API under this rulemaking would be free to upgrade to 
newer versions of the required standards, subject only to those 
limiting conditions noted here, at any pace they wish. However, they 
must continue to support connectivity, and make the same data 
available, for end users using applications that have been built to 
support only the HHS-adopted version(s) of the API standards.
    We welcome public comment on this proposed approach to allow 
voluntary use of updated versions of these standards.

III. Patient Access Through APIs

A. Background on Medicare Blue Button

    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 data through MyMedicare.gov in either 
PDF or text format. While the original Blue Button effort was a first 
step towards liberating patient health information, we recognize 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 format limits the utility and sharing of 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 data and share that electronic health 
information through an Application Program Interface (API) with 
applications, services, and research programs they select. As discussed 
in more detail in section II.A. of this proposed rule, 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.
    Medicare Blue Button 2.0 is expected to foster increased 
competition among technology innovators who serve Medicare patients and 
their caregivers, such as through finding better ways to use claims 
data to address their health needs. Patients should have the ability to 
access their health information, in a format of their choosing, to 
receive a full picture of their health records. API technology can be 
an effective way to share data because health information from various 
sources can be retrieved through these secure interfaces and 
consolidated by a single tool, such as a third-party application chosen 
by, in the case of Medicare, the beneficiary or their caregiver.
    The Medicare Blue Button 2.0 API is also expected to improve the 
Medicare beneficiary experience by providing beneficiaries secure 
access to their claims data in a standardized, computable format. We 
recognize that data security is of the utmost importance and are 
dedicated to safeguarding patient health information so that only the 
beneficiary and their authorized personal representative would have the 
ability to authorize release of their health information through 
Medicare Blue Button 2.0 to a third-party software application.
    Medicare Blue Button 2.0 will provide beneficiaries with a 
longitudinal view of their Medicare claims data, which can then be 
combined with other health information within third party applications. 
One benefit of making records available via an API is that it enables a 
beneficiary to pull Medicare health information along with other heath 
information into a single application not dictated by any specific 
health plan, provider, or portal. APIs allow health information to move 
through the health ecosystem with the patient and ensure comprehensive 
and timely information is accessible even if the patient changes health 
plans, providers, or both over time, facilitating continuity of care.

B. Expanding the Availability of Health Information

1. Benefits of Information Access
    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. 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. For example, inconsistent benefit 
utilization patterns in an individual's claims data, such as a failure 
to fill a prescription or receive recommended therapies, can indicate 
that the individual has had difficulty adhering to 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

[[Page 7627]]

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 the open 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, for example, in the event of an 
event that generates a large and sudden demand for health services, 
when access to such information may help to inform patient triage, 
transfer, and care decisions.
    Further, consumers 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. In many cases, claims and 
encounter data can provide a more holistic and comprehensive view of a 
patient's care history than EHR data alone. Whereas EHR data is 
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. 
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 in 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 
managed care entities, and QHP issuers in FFEs to do the same to 
encourage competition, innovation, and value. Further, we believe that 
beneficiaries in Medicaid FFS programs administered by state Medicaid 
agencies and CHIP enrollees in both FFS and managed care should benefit 
from similar advances and the benefits of innovation and value.
    CMS has programmatic authority over MA organizations, Medicaid 
programs (both FFS and managed care), CHIP (including FFS and managed 
care), and QHP issuers in FFEs. This proposed rule seeks to leverage 
that CMS authority to make claims and encounter data available to 
patients in these programs along with other plan data (such as provider 
directory data) as detailed in sections III.C. and IV. of this proposed 
rule. We propose that regulated entities make this data available in a 
standardized format and through a specific technological means so that 
third parties can develop and make available applications that make the 
data available for patient use in a convenient and timely manner. Our 
proposal would require compliance with specific regulations regarding 
interoperability standards adopted by the Secretary in implementing and 
complying with the proposed requirement to use an API to make this data 
available. We are proposing to require compliance with 45 CFR 170.215 
to require the API technical standards that ONC is proposing for HHS 
adoption in its 21st Century Cures Act proposed rule (published 
elsewhere in this issue of the Federal Register). We are also proposing 
to require that the data elements made available through the proposed 
API technology must be formatted and presented in accordance with 
applicable content and vocabulary standards as described in section II. 
of this proposed rule. This means that the software receiving and using 
the data can readily consume the data to support consumer-friendly 
display and other functionalities.
    Ultimately, the goal of this proposal is to require that patient 
data be made available in a standardized format through an API, so that 
third parties can develop and offer applications that make the data 
available in a convenient and timely manner for enrollees and 
beneficiaries in MA plans, Medicaid and CHIP FFS and managed care 
delivery systems, and FFEs that are specified in our proposal as 
detailed below.
2. Alignment With the HIPAA Right of Access
    The HIPAA Privacy Rule, at 45 CFR 164.524, provides that 
individuals have a right of access to inspect and obtain a copy of PHI, 
defined at 45 CFR 160.103, about them that is maintained by a health 
plan or covered health care provider in a designated record set, 
defined at 45 CFR 164.501. The right of access also provides 
individuals with the right to initiate disclosures to third parties.
    Software applications using the API proposed in 42 CFR 422.119, 
431.60, 438.242(b)(6), 457.730, 457.1233(d)(2), and 45 CFR 156.221 
would provide an additional mechanism through which the individuals in 
that coverage who so choose can exercise the HIPAA right of access to 
their PHI, by giving them a simple and easy electronic way to request, 
receive, and share data that they want and need, including with a 
designated third party. However, as discussed in section II of this 
proposed rule, due to limitations in current availability of 
interoperability standards for some types of data and patient's rights 
to be granted access in the form and manner of their own choosing, the 
API requirement may not be sufficient to support access to all of the 
health information subject to the HIPAA right of access because it may 
not all be transferable through the API.

C. Open API Proposal for MA, Medicaid, CHIP, and QHP Issuers in FFEs

1. Introduction
    We are proposing to add new provisions at 42 CFR 422.119, 431.60, 
438.242(b)(6), 457.730, 457.1233(d) and 45 CFR 156.221, that would, 
respectively, require MA organizations, state Medicaid FFS programs, 
Medicaid managed care plans, CHIP FFS programs, CHIP managed care 
entities, and QHP issuers in FFEs (excluding issuers of SADPs) to 
implement, test, and monitor an openly-published API that is accessible 
to third-party applications and developers. We note that states with 
CHIPs are not required to operate FFS systems and that some states' 
CHIPs are exclusively operated by managed care entities. We do not 
intend to require CHIPs that do not operate a FFS program to establish 
an API; rather, these states may rely on their contracted plans, 
referred to throughout this proposed rule as CHIP managed care 
entities, to set up such a system.
    The API would allow enrollees and beneficiaries of MA 
organizations, Medicaid and CHIP FFS programs, Medicaid managed care 
plans, CHIP

[[Page 7628]]

managed care entities, and QHP issuers in FFEs to exercise 
electronically their HIPAA right of access to certain health 
information specific to their plan, through the use of common 
technologies and without special effort. Common technologies, for 
purposes of our proposal, are those that are widely used and readily 
available, such as computers, smartphones or tablets.
    We are proposing that the API would be required to meet certain 
interoperability standards, consistent with the API technical standards 
proposed by ONC for HHS adoption in its proposed rule (published 
elsewhere in this issue of the Federal Register), as well as to require 
the use of content and vocabulary standards adopted by HHS and that the 
use of these standards would be applicable across the specific entities 
subject to proposed 42 CFR 422.119, 431.60, 438.242(b)(6), 457.730, and 
457.1233(d), and 45 CFR 156.221. In this context, these standards are 
critical to ensure that enrollees of those plans and programs have 
electronic access to their health information in interoperable form and 
that access to their health information and information about their 
coverage are not obstructed by, or confined to, certain propriety 
systems.
    Under our proposal, the scope and volume of the information to be 
provided or made accessible through the open API would include: 
Adjudicated claims (including cost); encounters with capitated 
providers; provider remittances; enrollee cost-sharing; and clinical 
data, including laboratory results (where available). We propose that 
these programs and organizations, with the exception of the QHP issuers 
in FFEs, would also be required to make information regarding provider 
directories and formularies available through the open API. Sections 
1852(c), 1932(a)(5), and 2103(f)(3) of the Act require that MA 
organizations and Medicaid MCOs, and CHIP managed care entities provide 
basic information to their enrollees on how to get covered benefits in 
the plan and to facilitate decision making about plan choice, 
providers, and benefits. These statutory provisions indicate 
information enrollees could use to make decisions about their health 
care. The API proposals at 42 CFR 422.119(a), 438.242(b)(6), and 
457.1233(d) support and complement existing implementation of these 
provisions in a robust and modern way. We believe the health 
information that would be available through the proposed API would 
greatly supplement the benefit, provider directory, and, if applicable, 
formulary information from states and managed care plans by providing 
important details and context, thus enabling enrollees to make more 
informed, proactive decisions.
    Additionally, we believe that since most of the information 
required to be provided by these statutory sections of the Act, such as 
the provider directory, is currently accessible to enrollees and 
potential enrollees electronically online, making such standardized 
health information available through the proposed API could allow easy 
integration for use by more enrollees. Further, the proposal would 
enable these enrollees to more easily share their information with 
providers, family, caregivers, and others. As a general matter, 
providing important details and context to patients gives them more 
visibility into their treatment record through adjudicated claims, 
allowing them to be true partners in their health care. This goal is 
related to the disclosure requirements in sections 1852, 1932 and 2103 
of the Act and our proposal furthers each.
    We also believe the proposed API allows for the administration of 
more efficient and effective Medicaid and CHIP programs by taking 
advantage of commonly used methods of information sharing and data 
standardization. Consumers routinely perform many daily tasks on their 
mobile phones--banking, shopping, paying bills, scheduling--using 
secure applications. We believe that obtaining their health information 
should be just as easy, convenient, and user-friendly. Our proposal is 
a step toward that vision for enrollees in MA plans, Medicaid FFS and 
managed care programs, CHIP FFS programs and managed care entities, and 
QHPs in FFEs. Finally, our proposal includes a number of parameters and 
standards for the API and for adopting, implementing, testing, and 
monitoring the API; the specific pieces of our proposal are addressed 
in turn in sections III.C.2 of this proposed rule.
2. The Open API Proposal
    This section outlines the components of the open API proposal. 
Specifically, this section will discuss:
     Authority to require implementation of an open API;
     The API technical standard and content and vocabulary 
standards;
     Data Required To Be Available Through the Open API & 
Timeframes for Data Availability;
     Documentation Requirements for APIs;
     Routine Testing and Monitoring of Open 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;
     Applicability and Timing; and
     Request for Information on Information Sharing Between 
Payers and Providers Through APIs.
    We are proposing nearly identical language for the regulations 
requiring open 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 QHPs in FFEs; Medicaid managed care plans would be 
required at 42 CFR 438.242(b)(6), 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 this proposed rule, we are proposing similar if 
not identical requirements for these various entities to establish and 
maintain an open API, make specified data available through that API, 
disclose API documentation, provide access to the API, and make 
resources available to enrollees. We believe that such nearly identical 
text is appropriate here as the reasons and need for the proposal and 
the associated requirements are the same across these programs. Except 
as noted below with regard to specific proposals, we intend to 
interpret and apply the regulations proposed in this section, III.C. of 
this 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.
    In paragraph (a) of each of the proposed regulations, we propose 
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 in an FFE, as applicable) would be 
required to implement and maintain an open API that permits third-party 
applications to retrieve, with the approval and at the direction of the 
individual beneficiary, 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 mean 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 open API technology. By ``without special 
effort,'' we codify our expectation that third-

[[Page 7629]]

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 our proposed regulations, we 
address 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 each program, discussed 
in sections IV. and V. of this proposed rule, are also included in some 
of the regulations that address the API.
    We solicit comment on our use of virtually identical language in 
these regulations and our overall proposal to require implementation 
and maintenance of an open API.
a. Authority To Require Implementation of an Open API
    Our proposal would apply to MA organizations, Medicaid state 
agencies and managed care plans, state CHIP agencies and managed care 
entities, and QHP issuers in FFEs. We note that our proposal for 
Medicaid managed care plans, at 42 CFR 438.242(b)(6), would require 
MCOs, PIHPs, and PAHPs to comply with the regulation that we are 
proposing for Medicaid state agencies at 42 CFR 431.60 as if that 
regulation applied to the Medicaid managed care plan. Similarly, we 
intend for CHIP managed care entities to comply with the requirements 
we propose at 42 CFR 457.730 via the regulations proposed at 42 CFR 
457.1233(d)(2). We propose to structure the regulations this way to 
avoid ambiguity and to ensure that this 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. CHIP 
currently adopts the Medicaid requirements at 42 CFR 438.242 in whole. 
We propose 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 proposing 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 would add 42 CFR 
438.242(b)(6). In our discussion of the specifics of this proposal and 
how we propose to codify it at 42 CFR 422.119, 431.60, 457.730, and 45 
CFR 156.221, we refer only generally to 42 CFR 438.242(b)(6) and 
457.1233(d)(2) for this reason.
(1) Medicare Advantage
    Sections 1856(b) and 1857(e) of 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; 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. As technology evolves to allow 
for faster, more efficient methods of information transfer, so do 
expectations as to what is generally considered ``timely.'' Currently, 
consumers across public and private sectors have become increasingly 
accustomed to accessing a broad range of personal records, such as bank 
statements, credit scores, and voter registrations, immediately through 
electronic means and with updates received in near real time. Thus, we 
believe that in order to align our standards with 21st century demands, 
we must take steps for MA enrollees to have immediate, electronic 
access to their health information and plan information. The proposed 
requirements in this rule are intended to achieve this goal.
    We believe that the scope of the information that would be made 
available through an API under this proposal (described in section III. 
of this proposed rule) is consistent with the access and disclosure 
requirements in section 1852 of the Act, and we rely 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, to 
require MA organizations to make specific types of information, at 
minimum, accessible through an open API and require timeframes for 
update cycles. Throughout this section III.C. of this proposed rule, we 
explain how and why the open API proposal is necessary and appropriate 
for MA organizations and the MA program; 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 this proposed rule serves to provide 
further explanation as to how an open API proposal is necessary and 
appropriate in the MA program. Further, 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 program.
    To the extent necessary, we also rely on section 1860D-12(b)(3) of 
the Act to add provisions specific to the Part D benefit offered by 
certain MA organizations. For MA organizations that offer MA 
Prescription Drug plans, we are proposing requirements in 42 CFR 
422.119(b)(2) regarding electronic health information for Part D 
coverage. That aspect of our proposal is also supported by the 
disclosure requirements imposed under section 1860D-4(a) of the Act, 
which requires Part D claims information, pharmacy directory 
information, and formulary information to be disclosed to enrollees.
(2) Medicaid and CHIP
    We are proposing new provisions at 42 CFR 431.60(a), 457.730, 
438.242(b)(6), 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 an open API that permits 
third-party applications authorized by the beneficiary or enrollee to 
retrieve certain standardized data. This 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 are proposing these new requirements under the 
authority in section 1902(a)(4) of the Act, which requires that a state 
Medicaid plan for medical assistance provide such methods of 
administration as are found by the Secretary to be necessary for the 
proper and efficient 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 propose 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 these provide us with authority (in 
conjunction with our

[[Page 7630]]

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 believe 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 will 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, as noted in this proposed rule, there are 
independent statutory provisions that require the disclosure and 
delivery of information to Medicaid beneficiaries and CHIP enrollees; 
this proposal assists in the implementation of those requirements in a 
way that is appropriate and necessary in the 21st century. We believe 
making this information available in this format would 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 would also facilitate beneficiaries' ability to detect and 
report fraud, waste, and abuse--a critical component of an effective 
program.
    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. This 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 through the exchange of electronic health 
information by easily monitoring and sharing their data. By requiring 
that certain information be available in and through standardized 
formats and technologies, our proposal moves these programs toward 
interoperability, which is key for data sharing and access, and 
ultimately, improved health outcomes. As an additional note, 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.
(3) Qualified Health Plan Issuers in Federally-Facilitated Exchanges
    We propose a new QHP minimum certification standard at 45 CFR 
156.221(a) that would require QHP issuers in FFEs, not including SADPs, 
to implement an open API that permits third-party applications, with 
the approval and at the direction of the individual enrollee, to 
retrieve standardized data concerning adjudicated claims (including 
cost), encounters with capitated providers, and provider remittances, 
enrollee cost-sharing, and clinical data, including laboratory results 
(where available). We are also proposing 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 are proposing these 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 affords 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 authorizes Exchanges to certify QHPs that meet the 
QHP certification standards established by the Secretary, and if the 
Exchange determines that making available such health plan through such 
Exchange is in the interests of qualified individuals and qualified 
employers in the state or states in which such Exchange operates.
    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 enrollees 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, the 
plan enrollee can ensure their providers know what services have 
already been received, avoid receiving duplicate services; and verify 
when prescriptions were filled. We believe these types of activities 
would result in better health outcomes and enrollee 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 
enrollees' ability to detect and report fraud, waste, and abuse--a 
critical component of an effective program. 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. Therefore, 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 encourage SBEs to 
consider whether a similar requirement should be applicable to QHP 
issuers participating in their Exchange.
b. API Technical Standard and Content and Vocabulary Standards
    We propose to require compliance with proposed 45 CFR 170.215 at 42 
CFR 422.119(a) and (c), 431.60(a) and (c) and 457.730(a) and (c), 
438.242(b)(6) and 457.1233(d)(2), and 45 CFR 156.221(a) and (c), so 
that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed 
care plans, CHIP managed care entities, and QHP issuers in FFEs 
implement open API technology conformant with the proposed API 
technical standards (published elsewhere in this issue of the Federal 
Register) (see also section II.A.3. of this proposed rule). We further 
propose to require compliance with the regulations regarding the 
following content and vocabulary standards for data available through 
the API, 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 proposed 
by ONC for adoption by HHS at 45 CFR 170.213 (USCDI Version 1). See 
section II.A.3. of this proposed rule for further information about our 
proposals regarding how entities subject to this rule would be required 
to utilize these standards. We are proposing 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 in FFEs (not including issuers of SADPs).
    Further, with the new proposed requirements to implement and 
maintain an API at 42 CFR 422.119(a), 431.60(a), and 457.730(a), we are 
proposing corresponding requirements at proposed 42 CFR 422.119(c) for 
MA

[[Page 7631]]

plans, 431.60(c) for Medicaid FFS programs, and 457.730(c) for CHIP FFS 
programs implementing the proposed API technology. In proposed 
paragraphs 42 CFR 422.119(c), 431.60(c), 457.730(c), MA plans and the 
state Medicaid or CHIP (for CHIP agencies that operate FFS systems) 
agency would be required to implement API technology conformant with 
the standards proposed by ONC for HHS adoption 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 proposed for 
adoption at 45 CFR 170.213; and to maintain and use the technology in 
compliance with applicable law, including but not limited to 45 CFR 
parts 162, 42 CFR part 2, and the HIPAA Privacy and Security Rules.
    We similarly propose at 45 CFR 156.221(c) that QHP issuers in FFEs 
must implement API technology conformant with the API technical 
standards proposed by ONC for HHS adoption 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 proposed for adoption at 45 
CFR 170.213; and maintain and use the technology in compliance with 
applicable law, including but not limited to 45 CFR part 162, 42 CFR 
part 2, and the HIPAA Privacy and Security Rules.
    We believe that 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 these proposals, clinicians would be able to review 
information on their patient's current prescriptions and services 
received by the enrollee on the enrollee's smartphone. Also, the 
enrollee could 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 enrollee receives it or by 
authorizing release of the data through the API directly to the 
clinician's EHR system.
    We also encourage payers to consider using the proposed API 
infrastructure as a means to exchange PHI for other health care 
purposes, such as to health care providers for treatment purposes. 
Sharing interoperable information directly with the enrollee's health 
care provider's EHR 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 believe that 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 also believe that these proposals are 
designed to empower patients to have simple and easy access to their 
data in a usable digital format, and therefore, can empower them to 
decide how their health information is going to be used. However, we 
remind payers that this proposed regulation regarding the API would not 
lower or change their obligations as HIPAA covered entities to comply 
with regulations regarding standard transactions in 45 CFR part 162.
    As discussed in section II.A.3. of this proposed rule, we recognize 
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 offer 
several proposals. We propose that regulated entities may use an 
updated version of a standard where required by other applicable law. 
We also propose that regulated entities may use an updated version of 
the standard where not prohibited by other applicable law, under 
certain circumstances. First, we propose to allow the use of an updated 
version of content or vocabulary standards adopted at 45 CFR part 162 
or 42 CFR 423.160, 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, is prohibited for use in ONC's Health IT 
Certification Program, or is prohibited by other applicable law.
    Second, for the content and vocabulary standards proposed by ONC 
for HHS adoption at 45 CFR 170.213 (USCDI Version 1), as well as for 
API interoperability standards proposed by ONC for HHS adoption at 45 
CFR 170.215 (including HL7 FHIR and other standards discussed above), 
we propose to allow the use of an updated version, provided such 
updated version has been approved by the National Coordinator through 
the Standards Version Advancement Process described in ONC's 21st 
Century Cures Act proposed rule (published elsewhere in this issue of 
the Federal Register).
    Finally, we propose that use of an updated standard by a payer that 
is subject to these proposed regulations must not disrupt an end user's 
ability to access the data available through the API proposed in 
section III. of this proposed rule using an application that was 
designed to work with an API that conforms to the API standard proposed 
under ONC's 21st Century Cures Act proposed rule (published elsewhere 
in this issue of the Federal Register). Entities that would be required 
to implement an open API under this rulemaking would be free to upgrade 
to newer versions of the required standards, subject only to those 
limiting conditions noted here, and at any pace they wish. However, 
they must continue to support connectivity and make the same data 
available to applications that have been built to support only the 
adopted version(s) of the API standards. For further discussion of 
these proposals, see section II.A.3.D. of this proposed rule.
c. Data Required To Be Available Through the Open API & Timeframes for 
Data Availability
    We propose the content that must be accessible for each enrollee of 
an entity subject to our open API proposal as set out at 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 propose for Medicaid and CHIP programs. We note that the types of 
content proposed here 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 in FFEs would have the option to use the API 
required by this proposed rule to make additional types of health 
information or plan information available, exceeding these minimum 
requirements.
    We request comment on the data proposed to be made available as 
detailed in the subsections below, the appropriateness of the proposed 
timeframes, and suggestions for alternative timeframes that consider 
the utility to the beneficiary, as well as challenges that the proposed 
timeframe may create for the entities that would have to comply.

[[Page 7632]]

(1) Patient Claims and Encounter Data
    We propose that MA organizations, Medicaid and CHIP FFS programs, 
Medicaid managed care plans, CHIP managed care entities, and QHP 
issuers in FFEs, permit third-party applications to retrieve, with the 
approval of an enrollee, certain specific data: adjudicated claims 
data, including provider remittances and beneficiary or enrollee cost-
sharing data; encounters from capitated providers; and clinical data, 
including laboratory results (but only if managed by the payer). 
Adjudicated claims data would include on approved and denied claims; 
under this 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 reconsideration 
decision. We specifically request comments from plans regarding the 
feasibility of including such claims data, including any possible 
timing issues. In addition, the open APIs required for these entities 
must make available formulary information (for MA-PD plans) or 
information about covered outpatient drugs and preferred drug lists 
(for state Medicaid and CHIP agencies, Medicaid managed care plans and 
CHIP managed care entities).
    Our proposal includes timeframe requirements for making these 
various categories of data available through the open API. For MA 
organizations, proposed 42 CFR 422.119(b)(1)(i), (1)(ii), and (2)(i) 
would require open API access to all claims activity pertaining to 
adjudicated claims (including cost) and 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 adjudicated or the encounter data is received by the MA 
organization. For clinical data, including laboratory results, MA 
organizations that manage such data would be required under 42 CFR 
422.119(b)(1)(iv) to provide access through the open API to that data 
no later than one business day after it is received by the MA plan. For 
Medicaid state agencies and managed care plans, claims data, encounter 
data, and clinical data, including laboratory results (if available) 
would be required (specifically at 42 CFR 431.60(b)(1),(2), and (4)) 
through the API no later than one business day after the claim is 
processed or the data is received. For State Medicaid agencies in 
connection with the FFS program, the API would have to include all 
claims data concerning adjudicated claims and standardized 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 at 42 CFR 
438.242(b)(6)(i); encounter data 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 of Medicaid managed care plans would have to include 
all claims and encounter data would be included regardless if it is 
adjudicated or generated by the managed care plan itself, 
subcontractor, or 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.
    For CHIP agencies and managed care entities, claims data, encounter 
data, and reports of lab test results (if available) would be required 
(specifically at 42 CFR 457.730(b)(1),(2), and (4)) through the API as 
soon as possible but no later than one business day. 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 in FFEs, our proposed regulation at 45 CFR 156.221(b) would 
require claims, encounter, and lab data to be available within one 
business day of adjudication and receipt, respectively.
    These proposed timeframes would ensure that data provided through 
the API would be the most current data available, which may be critical 
if the data is provided by an enrollee to his or her health care 
provider to use in making clinical decisions. Under our proposal, the 
claims and encounter data to be disclosed should include information 
such as enrollee identifiers, dates of service, payment information 
(provider remittance if applicable and available), and enrollee cost-
sharing. The ability for enrollees--created and facilitated by the API 
required under our 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 standardized encounter data through the 
API within one (1) business day of the receiving the data, we note that 
this 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 recommend that MA 
organizations, Medicaid managed care plans, CHIP managed care entities, 
and QHP issuers in FFEs that would need this information in order to 
meet the proposed API requirements 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. For Medicaid and CHIP FFS programs, 
we encourage states to consider other means to ensure that necessary 
encounter data from providers is also provided on a timely basis.
    We note that the data for claims and remittances that would be 
available through the API is much of the same data that is required for 
the ASC X12 837, ASC X12 835, and ASC X12 863 standards which are 
required for certain transactions between certain entities under 45 CFR 
162.1102, 162.1602 and 162.1603, as well as the Part D eRx transaction 
standards that use for conveying prescription and prescription-related 
information between Part D plans, providers, and pharmacies as 
specified in 42 CFR 423.160. As most claims are submitted to payers 
electronically utilizing these industry standard transaction types, we 
believe this maximizes efficiency and reduces programming burden. As 
noted previously, our proposed regulation for Medicaid managed care 
plans at 42 CFR 438.242(b)(6) and for CHIP managed care entities at 42 
CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with 
the same standard transaction types.
    Specifically regarding QHP issuers in FFEs, in 45 CFR 
156.221(b)(1)(i) and (ii), we propose to require that QHP issuers 
participating in an FFE make available through the API standardized 
data concerning adjudicated claims (including cost) and encounters with 
capitated providers. Under proposed paragraph (b)(1)(i), QHP issuers in 
FFEs would be required to make available standardized 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), QHP issuers in FFEs would be required to 
provide standardized encounter data through the API within one (1) 
business day of the issuer receiving the data.

[[Page 7633]]

    We are also considering requiring the encounter data to be 
available through the API within a certain period after the encounter, 
within one (1) business day after the encounter data is received. We 
seek comment on what a reasonable period from the encounter date would 
be for us to consider as part of future rulemaking. In addition, we 
solicit comment on our authority to require MA organizations, States 
(for FFS Medicaid programs and CHIP), Medicaid and CHIP managed care 
plans, and QHPs in the FFEs to require submission of such data on a 
particular timeframe.
(2) Provider Directory Data
    We are also proposing 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 API make available provider directory data, including updates 
to such data. Our 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 QHPs in FFEs.
    For MA organizations, at proposed 42 CFR 422.119(b)(1)(iii), we 
propose to specify that MA organizations make specific provider 
directory information for their network of contracted providers 
accessible through their 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). MA organizations would be required to ensure the 
availability of this information through their APIs for all MA plans. 
Including this information in an open API allows non- MA third-party 
applications to consume, aggregate, and display plan data in different 
contexts, allowing patients to understand and compare plan information 
in a way that can best serve their individual needs. MA plans would be 
required to update provider directory information available through the 
API no later than 30 calendar days after changes to the provider 
directory are made. In addition, we are adding 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.
    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 API, including 
updated provider information no later than 30 calendar days after the 
state receives updated provider information. As noted previously, our 
proposed regulation for Medicaid managed care plans at 42 CFR 
438.242(b)(6) and for CHIP managed care entities at 42 CFR 
457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the 
same standard, 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, the provider directory information available through the 
API must include all information that is specified in 42 CFR 
438.10(h)(1) for disclosure to managed care enrollees. We note that we 
have proposed that the 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) and 457.1233(d)(2)) to be consistent with existing 
Medicaid managed care rules at 42 CFR 438.10(h)(3). We propose 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 propose in 42 CFR 438.242(b)(6)(ii) that the 
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 have also 
proposed 30 calendar days.
    We are not proposing a similar requirement for QHP issuers in FFEs. 
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 do not believe the 
benefits of making it also available through an open API outweigh the 
burden for QHP issuers in FFEs. However, we seek comment as to whether 
this same requirement should apply to QHP issuers, or if such a 
requirement would be overly burdensome for them.
    We request comment on these proposals.
(3) Clinical Data Including Laboratory Results
    Regarding the provision of clinical data, including laboratory 
results, we propose 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 manages such data. Because we propose in 
paragraph (c) that the USCDI standard, proposed by ONC for HHS adoption 
at 45 CFR 170.213, be used as the content and vocabulary standard for 
this clinical data as provided in the API, we intend our 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. In 
effect, we are proposing any clinical data included in the USCDI 
standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be 
available through the API if such data is managed by the MA 
organization. We recognize 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, this 
proposed requirement applies 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 data 
as a part of its normal operations. This proposed requirement aligns 
with existing regulations at 42 CFR 422.118, which require 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 propose that this data be available 
in the API no later than 1 business day from its receipt by the MA 
organization.
    Similarly, the proposed regulations for Medicaid and CHIP FFS 
programs and managed care plans (proposed 42 CFR 431.60(b)(4) and 
457.730(b)(4)), require provision of standardized data for clinical 
data, including laboratory results, through the API, if available, no 
later than one (1) business day after a claim is adjudicated or the 
data is received (by the state or the managed care plan/entity). This 
would ensure that data provided through the API would be the most 
current data available, which may be critical if the data is being 
shared by an enrollee with a health care provider who is basing 
clinical decisions on the data. Like proposed 42 CFR 422.119(c), these 
Medicaid and CHIP regulations propose 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 API; therefore, we are, in

[[Page 7634]]

effect, proposing any clinical data included in the USCDI standard, 
proposed by ONC for HHS adoption at 45 CFR 170.213, be available 
through the API. For state agencies managing Medicaid or CHIP FFS 
programs, such data must be included through the API under our proposal 
only if the state manages clinical data. Our proposed regulation for 
Medicaid managed care plans at 42 CFR 438.242(b)(6) 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 API; the 
limitation about the availability of clinical data through the API 
would carry through to managed care plans and entities under our 
proposal.
    Proposed 45 CFR 156.221(b)(3) requires QHP issuers in FFEs to also 
make available, with the approval of the enrollee, clinical data, 
including laboratory results, if the QHP maintains such data.
    We recognize not all of the entities subject to this requirement 
have uniform access to this type of data and seek comment on what 
barriers exist that would discourage them from obtaining, maintaining, 
and sharing this data. We request comment on these proposals.
(4) Drug Benefit Data, Including Pharmacy Directory, and Formulary Data
    We are also proposing that drug benefit data, including pharmacy 
directory information and formulary or preferred drug list data, also 
be available through the API at proposed 42 CFR 422.119(b)(2)(ii) and 
(iii), 431.60(b)(5), and 457.730(b)(5). As previously discussed, 
Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) 
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 propose at 42 CFR 422.119(b)(2)(ii) and (iii) that MA 
organizations offering MA-PD plans make available pharmacy directory 
data, including the number, mix, and addresses of pharmacies in the 
plan network, as well as 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 
API no later than 1 business day of the MA-PD plan's receipt of that 
information, we are not proposing a specific timeframe for pharmacy 
directory or formulary information to be available (or updated) through 
the API. We intend that the requirements in 42 CFR part 423 requiring 
when and how information related to pharmacy directories be updated 
will apply to the provision of this information through the API; we 
solicit comment specifically whether we should address this in the 
regulation text or otherwise impose a time-frame for this information 
to be made available through the API.
    At proposed 42 CFR 431.60(b)(5), for Medicaid FFS programs, and at 
42 CFR 457.730(b)(5) for CHIP FFS programs, states would be required to 
include and update covered outpatient drug lists (including, where 
applicable, preferred drug lists) through the API no later than one (1) 
business day after the effective date of the information or any 
changes. We are proposing to set this timeframe at one (1) business day 
because we believe that it is critical 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. Having timely data is 
particularly important during urgent or emergency situations. Medicaid 
managed care plans and CHIP managed care entities would be required to 
comply with these requirements as well under proposed 42 CFR 
438.242(b)(6) and 457.1233(d)(2). We also note that adjudicated claims 
and encounter data referenced in 42 CFR 431.60(b)(1) and (2), 
438.242(b)(6), and 457.730(b)(1) and (2) include claims and encounter 
data for covered outpatient drugs. To the extent that a state or 
managed care plan utilizes a pharmacy benefit manager (PBM), we 
anticipate that, as a practical matter, the state or managed care plan 
would need to obtain the data from the PBM in a timely manner to comply 
with these proposed requirements.
    We request comment on these proposals.
d. Documentation Requirements for APIs
    We are proposing 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 this 
proposed rule, we believe 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, including by satisfying any 
requirements the organization may establish for verification of 
developers' identity and their applications' authenticity, consistent 
with its security risk analysis and related organizational policies and 
procedures to ensure it maintains an appropriate level of privacy and 
security protection for data on its systems.
    Specifically, at 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 
CFR 156.221(d), we propose virtually identical text to require 
publication of complete accompanying documentation regarding the API 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) 
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 is ``publicly accessible,'' we expect 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. This is 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 mean 
``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 specifically 
solicit comments on these points.
    We propose that the publicly accessible documentation would be 
required to include, at a minimum, the following information:
     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.
     The software components and configurations an application 
must use

[[Page 7635]]

in order to successfully interact with the API (for example, to connect 
and receive data through the API) and process its response(s).
     All applicable technical requirements and attributes 
necessary for an application to be registered with any authorization 
server(s) deployed in conjunction with the API.
    We note that these information requirements are similar to those 
ONC has proposed for adoption by HHS for developers and users of health 
IT certified to the API criteria proposed at 45 CFR 170.315 (published 
elsewhere in this issue of the Federal Register), but are proposed here 
to apply specifically to the API technology deployed by organizations 
subject to the API requirements proposed in section III. of this 
proposed rule. We request comments on this proposal.
e. Routine Testing and Monitoring of Open 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 in FFEs, respectively, we are proposing that 
the API 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 minimally required to comply with the HIPAA privacy 
and security requirements in 45 CFR part 164, 42 CFR parts 2 and 3, and 
other applicable law protecting privacy and security of individually 
identifiable health information. Medicaid managed care plans would be 
required by 42 CFR 438.242(b)(6) 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 note 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 are not specific to health insurance may also 
apply to MA organizations and MA plans in the context of our proposal. 
For the other entities regulated under our proposals in these various 
programs, we also intend the phrase ``other applicable law'' to include 
federal, state, tribal or local laws that apply to the entity.
    We propose this requirement to establish and maintain processes to 
routinely test and monitor the open APIs to ensure they are functioning 
properly, especially with respect to their privacy and security 
features. Under our proposal, MA organizations, Medicaid and CHIP FFS 
programs, Medicaid managed care plans, CHIP managed care entities, and 
QHP issuers in 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, compliance with our 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 requirements, where an enrollee is also a properly 
designated personal representative of another enrollee, the HIPAA 
covered entity must provide for appropriate access to the information 
of the enrollee that has designated the personal representative, just 
as they would if the personal representative were an enrollee of the 
same plan.
    Similarly, at proposed 45 CFR 156.221(c)(2), QHP issuers in FFEs 
would be required to routinely test and monitor their API to confirm 
that it is functioning properly.
    We request comment on these proposals.
f. Compliance With Existing Privacy and Security Requirements
    In the hands of a HIPAA covered entity or its business associate, 
individually identifiable patient claims, encounter data, and other 
health information are PHI as defined at 45 CFR 160.103. Ensuring the 
privacy and security of the claims, encounter, and other health 
information when it is transmitted through the API is of critical 
importance. Therefore, we remind MA organizations, state Medicaid and 
CHIP FFS programs, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers in 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 HIPAA privacy and security regulations at 45 
CFR part 164 and other law (whether federal, state, tribal or local) 
that may apply based on the specific circumstances. Under this 
proposal, 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 request 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 this proposal.
g. Issues Related to Denial or Discontinuation of Access to the API
    As discussed in section II.A of this proposed rule, HIPAA covered 
entities must comply with patients' requests to receive their data 
under the HIPAA Right of Access, including having to transmit patient 
data to a third party. As noted in guidance from OCR, disagreement with 
the individual about the worthiness of the third party as a recipient 
of PHI, or even concerns about what the third party might do with the 
PHI, are not grounds for denying a request.\27\ 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.\28\ 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 or otherwise violates the 
terms of use of the API technology.
---------------------------------------------------------------------------

    \27\ https://www.hhs.gov/hipaa/for-professionals/faq/2037/are-there-any-limits-or-exceptions-to-the-individuals-right/.
    \28\ 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/, 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/ (FAQs last accessed at these 
URLs July 30, 2018).
---------------------------------------------------------------------------

    At 42 CFR 422.119(e), 431.60(e), 438.242(b)(6), 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 in FFEs, we are proposing 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 our proposed requirement to offer patients access 
through open APIs. We intend for this

[[Page 7636]]

proposal to be consistent with the HIPAA rules, and we note that these 
circumstances apply to specific applications, rather than the third 
party itself. For instance, were the individual to request that the 
HIPAA covered entity provide the individual's information through other 
means than through an API to the same third party that would have 
received it on the individual's behalf through an application which has 
been denied access, the covered entity would be required to approach 
that request as if the application's API request or connection had not 
occurred.
    Specifically, we propose that an MA organization, state Medicaid 
and CHIP FFS program, Medicaid managed care plan, CHIP managed care 
entity, or QHP issuer in an FFE, may, in accordance with HIPAA, deny 
access to the API if the entity reasonably determines 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 
organization's systems. We further propose that this determination must 
be based on objective, verifiable criteria that are 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 propose to require access through open APIs to otherwise 
publicly available information, such as provider directories, the 
entities subject to our 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 PII.
    We also anticipate 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 re-connect 
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 request comment on these proposals.
h. Enrollee and Beneficiary Resources Regarding Privacy and Security
    As discussed in section II.A. of this proposed rule, we are 
committed to maximizing enrollees' access to and control over their 
health information. We believe this calls for providing enrollees that 
would access data under our 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 propose to require MA organizations, state Medicaid and 
CHIP FFS programs, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers in 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. These proposed 
obligations are proposed to apply to Medicaid managed care plans and 
CHIP managed care entities through cross-references proposed in 42 CFR 
438.242(b)(6) and 457.1233(d)(2).
    The general information about the steps individuals can take to 
help protect the privacy and security of their health information 
should not be limited to, but should specifically include and emphasize 
the importance of understanding the privacy and security practices of 
any application to which they entrust their data. Information about 
submitting complaints should include both specific contact information 
for the OCR and FTC complaints processes and a brief overview, in 
simple and easy-to-understand language, of: What organizations are 
HIPAA covered entities, OCR's responsibility to oversee compliance with 
HIPAA, and FTC's complementary responsibility to oversee unfair and 
deceptive practices, including by non-covered entities that may offer 
direct-to-consumer health information management applications.
    We propose that this information must be made available on the 
website of the organization subject to this proposed requirement, and 
through other appropriate mechanisms through which the organization 
ordinarily communicates with enrollees. 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 organization's API. We are also proposing that the entity must make 
this information available in non-technical, consumer-friendly 
language.
    We anticipate that organizations 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 (for example, content and materials such as those 
available at https://www.hhs.gov/hipaa/for-individuals/right-to-access/) and FTC website (for example, content and materials such as 
those available at https://www.consumer.ftc.gov/topics/online-security). However, we note that whether the organization chooses to 
draft its own resource materials to provide the required information or 
to rely on governmental or other sources for such materials, the 
organization will be responsible for ensuring that the content of the 
materials remains current as relevant law and policy may evolve over 
time. We seek comment on this proposal, and we invite 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 anticipate 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 this proposal.
i. Exceptions or Provisions Specific to Certain Programs or Sub-
Programs
    We are proposing certain exceptions or specific additional 
provisions as part of this proposed rule for certain QHPs in FFEs and 
certain types of MA plans, respectively. Under sections 1856, 1857, and 
1860D-12(b)(3) of the Act, we proposed at 42 CFR 422.119(b)(2) to 
include additional requirements that would apply specifically to MA 
organizations that offer Medicare Advantage-Prescription Drug (MA-PD) 
plans. The organizations offering these MA-PD plans must comply with MA 
requirements in 42 CFR part 422 for Part A, Part B and non-drug 
supplemental benefits; they must comply with Part D requirements in 42 
CFR part 423 for the Part D prescription drug benefit. These additional 
requirements would ensure that enrollees of MA-PD plans can easily 
access the information they need in order to adhere to their care 
plans. Including this information in an open API allows non- MA third-
party applications to properly use, aggregate, and display plan data in 
different

[[Page 7637]]

contexts, enabling another means of accessing information for patients 
and more options for comparing and understanding plan information in a 
way that can best serve their individual needs.
    Specifically, at 42 CFR 422.119 (b)(2)(i), we propose to require MA 
organizations make standardized data concerning adjudicated Part D 
claims, including remittances and enrollee cost-sharing, available 
through the API to enrollees covered under a MA-PD plan. We propose to 
require that this information be made available no later than one (1) 
business day after a claim is adjudicated. This would ensure that data 
provided through the API would be the most current data available, 
which may be critical if the data is being used by a provider who is 
basing clinical decisions on the data. To the extent that an MA 
organization offering MA-PD plans utilizes a PBM, the MA organization 
would be required to obtain the data from the PBM in order to comply 
with these requirements.
    Related to QHP issuers, we propose two exceptions to this proposed 
rule. First, we propose that the requirements proposed in 45 CFR 
156.221(a) not apply to issuers of SADPs in the FFEs. In contrast to 
QHP issuers of medical plans, issuers of SADPs offer enrollees access 
to a unique and specialized form of medical care. We believe 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 believe 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 open API 
technology that conforms to standards proposed by ONC for HHS adoption 
at 45 CFR 170.215 (published elsewhere in this issue of the Federal 
Register) 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. 
Through our proposals in this section to require implementation of open 
API technology in the Medicare, Medicaid and CHIP programs, as well as 
by QHP issuers in FFEs, we would anticipate significantly expanding the 
implementation of open APIs by medical plans. However, we do not 
anticipate similar widespread usage with respect to SADPs. Therefore, 
we believe that the utility of access to issuers' data is less 
applicable to dental coverage, and do not believe it would be in the 
interest of qualified individuals and qualified employers in the state 
in which an FFE operates to not certify SADPs because they do not 
provide patient access to their data through an openly-published API. 
We seek comment on whether we should apply this policy to SADP issuers 
in the future.
    We also propose to provide an exceptions process through which an 
FFE may certify health plans that do not provide patient access through 
an openly-published API, but otherwise meet the requirements for QHP 
certification. We propose in 45 CFR 156.221(h)(1) that if a plan 
applying for QHP certification to be offered through an FFE does not 
provide patient access to their data through an open 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 propose 
that an FFE may grant an exception to the requirement to provide 
enrollees access to data through open API technology if the FFE 
determines that making available such health plan is in the interest of 
qualified individuals and qualified employers in the state in which the 
FFE operates. We anticipate 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 market who demonstrate that deploying open 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 seek 
comment on other circumstances in which the FFE should consider 
providing an exception.
j. Applicability and Timing
    At 42 CFR 422.119(h) and 45 CFR 156.221(i), we are proposing 
specific provisions regarding applicability and timing for MA 
organizations and QHP issuers in FFEs that would be subject to our 
proposal. We are not proposing specific regulation text for 42 CFR 
431.60 or 438.242 because we intend to make the regulation text 
effective on the applicable date discussed below. We expect that state 
Medicaid and CHIP agencies will be aware of upcoming new regulations 
and planning for compliance with them when they are effective and 
applicable, even if the new regulation is not yet codified in the CFR; 
we similarly expect 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 in 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 order to ensure that these requirements for MA organizations and QHP 
issuers in 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 propose to codify the actual compliance 
and applicability dates of these requirements. We solicit comment on 
this approach.
    For MA organizations, under 42 CFR 422.119(h), we are proposing 
that the requirements would be effective beginning January 1, 2020. 
Under this proposal, the requirements we propose for 42 CFR 422.119 
would be applicable for all MA organizations with contracts to offer 
any MA plan on that date and thereafter. We request feedback about this 
proposed timing from the industry. In particular, we are interested in 
information and request comment from MA organizations about their 
current capability to implement an API consistent with this 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 care plans at 42 CFR 
438.242(b)(6), and CHIP managed care entities at 42 CFR 457.1233(d)(2), 
we are proposing that the API requirements would be effective beginning 
July 1, 2020, regardless of when the managed care contract started. 
Given the expected date of publication of this proposed rule and 
potential final rule, we believe 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 solicit comment on this

[[Page 7638]]

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 are aware that some states do not provide any benefits 
on a FFS basis, and we do not intend for those states to implement an 
API outside their managed care plans. Therefore, we also propose 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 in FFEs, we propose in 45 CFR 156.221(i) that these 
requirements would be applicable for plan years beginning on or after 
January 1, 2020. We seek 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 believe 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. We believe that 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.
    These proposals are 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 support 
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, patients need to understand and be 
actively involved in their care under a value-based framework. We are 
committed to supporting requirements that focus on these goals, and we 
believe that these specific proposals in this proposed rule support 
these efforts.
k. Request for Information on Information Sharing Between Payers and 
Providers Through APIs
    This proposed rule requires the implementation of open 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 an open 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 a 
third party 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 uses a third party 
application to offer patients access to their records, 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, 
if it could do so in accordance with HIPAA without need of an 
individual's authorization. (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 do 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 specify 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.
    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 plan's patient/insured overlapping population(s) in 
one transaction. Effective care coordination between plans and 
providers can inform health care providers about where their patients 
are receiving care to better understand the totality of their 
healthcare needs and manage their care. We have heard that being aware 
of urgent care or emergency department visits allows clinicians to 
arrange appropriate follow-up, modify treatments, and update records if 
services are provided (for example, tetanus boosters given with a 
laceration treated in urgent care). The accompanying proposals in 
Section X. of this proposed rule, to amend the conditions of 
participation regarding notification of patient discharge, further 
support the ability of clinicians to arrange and affirm such 
appropriate follow-up care. Having a complete record of tests done at 
specialists' offices can reduce duplicate testing. Having a complete 
list of clinicians caring for a patient facilitates appropriate 
notification if treatments are changed or procedures are planned that 
may impact the other clinicians' treatment plan. We have heard from 
participants in our accountable care programs and models that 
organizations taking risk for their patient populations need to have a 
complete picture of the patients' needs to better budget for 
appropriate resources. This may be particularly relevant during 
disasters or public health emergencies when patients are not able to 
access their normal sources of care and/or health care facilities are 
overwhelmed due to patient surge.
    We believe there are a variety of transmission solutions that may 
be employed to share data regarding a provider's and plan's overlapping 
patient populations. For instance, some geographic areas might have 
regional health information exchanges that could coordinate such 
transmissions. Elsewhere, direct provider-to-provider and plan-to-plan 
exchange might be more appropriate. Plans could participate in direct 
exchange through existing trusted networks, or beneficiary-facing third 
party

[[Page 7639]]

applications could meet this potential future requirement.
    We seek comment for possible consideration in future rulemaking on 
the feasibility of providers being able to request a download on a 
shared patient population, and whether such a process could leverage 
the APIs described in sections II.A.3. and III.C. of this proposed 
rule. We seek comment on requirements for patient notice and consent, 
and applicable legal and regulatory requirements, and whether or how 
this data transfer could be cumulative over time and between various 
providers. We seek input on the utility to providers of obtaining all 
of their patients' utilization history in a timely and comprehensive 
fashion. We also seek input on potential unintended consequences that 
could result from allowing a provider to access or download information 
about a shared patient population from payers through an open API. 
Finally, we seek comment on the associated burden on plans to exchange 
this data, as well as the identification other potential statutory or 
regulatory barriers to exchanging this data.

IV. API Access to Published Provider Directory Data

A. Interoperability Background and Use Cases

    The proposals described in section III of this proposed rule 
primarily focus on patient access to their data through a standardized, 
transparent API; however, we have also proposed that entities subject 
to these proposals make available certain plan-level data through the 
API. In this section, we provide additional context for the proposal 
related to making provider directory information available through the 
API, including ways in which this proposal may differ from our other 
proposals related to accessibility of patient data.
    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, 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.
    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) 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 QHPs in FFEs (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 
directing 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 in FFEs make the information available.
    Making this required provider directory information available to 
enrollees and prospective enrollees through an API could support 
development of applications (whether standalone or integrated with 
providers' EHR technology) that would pull in current information about 
available providers to meet enrollees' current needs. For instance, as 
part of a referral lookup use case, API access to a provider directory 
could allow for a referring provider's health IT to enable either the 
enrollee or the provider to easily identify up-to-date contact 
information obtained from the directory through an API, and securely 
send the receiving health care provider the patient information needed 
to provide safe, high-quality care sensitive to the patient's 
preferences. 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, a 
consistent, FHIR-based API-driven approach to making provider directory 
data accessible could reduce provider burden by enabling payers/plans 
to share more widely basic information about the providers in their 
networks, such as provider type, specialty, contact information, and 
whether or not they are accepting new patients.

B. Broad API Access to Provider Directory Data

    In sections II.A.3. and III.C. of this proposed rule, we propose to 
require 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, so that third party software could access and 
publish that information. Such availability would be for current 
enrollees, prospective enrollees and possibly the general public to the 
extent existing regulations require that information to be disclosed 
beyond current enrollees. We propose to require that the API technology 
conform to the API standards proposed by ONC for HHS adoption at 45 CFR 
170.215 (published elsewhere in this issue of the Federal Register). At 
this time, because QHP issuers in FFEs are already required to make 
provider directory information available in a specified, machine-
readable format,\29\ we do not propose these as requirements for QHP 
issuers. However, we seek comment as to whether this same requirement 
should apply to QHP issuers, or if such a requirement would be overly 
burdensome for them.
---------------------------------------------------------------------------

    \29\ Available at https://github.com/CMSgov/QHP-provider-formulary-APIs/blob/master/README.md.
---------------------------------------------------------------------------

    We note that, since the provider directory information we are 
proposing to require be available through the API is already available 
and accessible to enrollees without cost to them, this information 
should be as accessible through the API as it is required to be when 
posted on the organization's websites. Therefore, the security 
protocols proposed at 45 CFR 170.215 that are specific to 
authenticating users and confirming individuals' authorization or 
request to disclose their personal information to a specific 
application would not apply to public access to provider directory 
information through APIs. While we are 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 emphasize 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. Those wishing to access this 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 this proposed rule, we 
intend to develop additional guidance, incorporating feedback from 
industry that provides implementation best practices relevant to FHIR-
conformant open APIs to help organizations subject to the requirements 
proposed in this rulemaking. To that end, we solicit

[[Page 7640]]

comment on what specific resources would be most helpful to 
organizations implementing APIs under requirements proposed in this 
proposed rule.

V. Health Information Exchange and Care Coordination Across Payers: 
Establishing a Coordination of Care Transaction To Communicate Between 
Plans

    We are proposing a new requirement for Medicare Advantage (MA) 
plans, Medicaid managed care plans, CHIP managed care entities, and 
QHPs in the FFEs to require these plans to maintain a process to 
coordinate care between plans by exchanging, at a minimum, the USCDI at 
enrollee request at the specific times specified in the proposed 
regulation text. Understanding that this information could already be 
available for exchange between plans, this proposal is specifically 
requiring this information sharing not only occur when initiated by an 
enrollee request, but that the information requested, in the form of 
the USCDI data set, would then be incorporated into the recipient 
plan's systems. The USCDI (Version 1) data set would have to be sent to 
another plan that covers the enrollee or a recipient identified by the 
enrollee at any time during coverage or up to 5 years after coverage 
ends, and the plan would have to receive the USCDI (version 1) data set 
from any health plan that covered the enrollee within the preceding 5 
years. Under our proposal we are supporting patient directed 
coordination of care and each of the plans subject to the requirement 
would, upon an enrollee's request: (1) Accept the data set from another 
plan 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 plan 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.
    As we discussed in section III.C.2. of this proposed rule, 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 ACA for QHP issuers in an FFE (not including SADP issuers). We 
believe that our proposal will help to reduce provider burden and 
improve patient access to their health information through coordination 
of care between health plans. We also note 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 above will also apply to CHIP managed care entities 
without new regulation text in part 457. We are proposing that this new 
requirement would be effective starting January 1, 2020 for MA plans, 
Medicaid managed care plans, CHIP managed care entities, and QHP 
issuers in FFEs. Among other topics related to this proposal, we 
solicit comments on this proposed effective date.
    We propose to codify this new requirement at 42 CFR 422.119(f)(1) 
for MA organizations; at 42 CFR 438.62(b)(1)(vi) for Medicaid managed 
care plans (and by extension under existing rules in part 457, to CHIP 
managed care entities); and at 45 CFR 156.221(c) for QHPs in FFEs. This 
proposed new requirement is virtually identical for MA plans, Medicaid 
managed care plans, CHIP managed care entities, and QHP issuers in 
FFEs, with modifications in the proposal necessary for specific plans 
types to account for the program needs of the MA program, Medicaid and 
CHIP managed care programs, and QHP program. Our proposed regulation 
text references the content standard adopted at 45 CFR 170.213, which 
ONC is proposing as the USCDI Version 1 data set (published elsewhere 
in this issue of the Federal Register). We believe that exchanging this 
minimum data would help both plan enrollees and health care providers 
coordinate care and reduce administrative burden 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. We believe that use of the USCDI to exchange 
information furthers care coordination. 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. It can also streamline prior authorization processes 
and reduce instances where an enrollee's health care provider needs to 
intervene personally with the enrollee's MA plan, Medicaid managed care 
plan, CHIP managed care entity, or QHP in the FFE to ensure his or her 
patient received the necessary treatment. This addresses concerns 
stakeholders have previously raised with CMS and ONC regarding such 
administrative burdens, as the USCDI standard contains many of the data 
points required to more effectively coordinate care.
    In addition to the benefits for care coordination at the plan level 
and reduced provider burden, we note that once the combined health 
information, specified by the USCDI standard, from a prior plan is 
available to the patient's current plan, the enrollee would also have 
access to multiple years of their health information through the 
proposed patient access API discussed in section III of this proposed 
rule. The USCDI (Version 1) data set includes laboratory results and 
tests, medications, health concerns, assessment and plan of treatment, 
care teams, clinical notes, and other data points essential for care 
coordination. This would provide the patient with a more comprehensive 
history of their medical care, helping them to make better informed 
health care decisions. We seek comments on how plans might combine 
records and address error reconciliation or other factors in 
establishing a more longitudinal record for each patient.
    We propose to allow multiple methods for electronic exchange of the 
information, including use of the APIs proposed in section III. of this 
proposed rule, 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 laws. We considered 
requiring the use of the FHIR-based API discussed in section III. of 
this proposed rule for the information exchange; however, we understand 
that some geographic areas might have a regional health information 
exchange that could coordinate such transitions for the MA plans, 
Medicaid managed care plans, CHIP managed care entities, and QHPs in 
the FFEs that are subject to this proposal. We seek comment on whether 
it would be beneficial to interoperability and patient care 
coordination for us to require the use of the FHIR-based API discussed 
in section III. of this proposed rule, and whether this should be the 
only mechanism allowed for this exchange, or whether

[[Page 7641]]

multiple methods for electronic exchange of the information should be 
allowed under this proposed policy.
    We also propose that a patient should be able to request his or her 
information from their prior plan up to 5 years after dis-enrollment, 
which is considerably less than existing data retention policies for 
some of the plans.\30\ Further, if a plan has access to multiple years 
of health information for a patient, either due to the fact that the 
patient has been enrolled with the plan for multiple years, or because 
the enrollee has requested transfer of the health information from 
prior plans which previously covered the enrollee, we propose that the 
health information would be incorporated into the IT and data systems 
of each plan that receives the USCDI data set under this 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 our proposal is 
to require compliance (and thus exchange of these data sets) only by MA 
plans, Medicaid managed care plans, CHIP managed care entities, and 
QHPs in the FFEs, we hope that compliance by these plans could be the 
first step toward adoption and implementation of these standards on a 
voluntary basis by other health plans and health issuers throughout the 
health care system.
---------------------------------------------------------------------------

    \30\ 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) QHPs in 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.\31\ 
Our proposal here for MA plans, Medicaid managed care plans, CHIP 
managed care entities, and QHPs in the FFEs to exchange a minimum 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. The USCDI (Version 1) data set would have 
to be sent to another plan that covers the enrollee or a recipient 
identified by the enrollee at any time during coverage or up to 5 years 
after coverage ends and the plan would have to receive the USCDI 
(version 1) data set from any health plan that covered the enrollee 
within the preceding 5 years.
---------------------------------------------------------------------------

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

    We propose that the plans subject to this new requirement would be 
required to exchange, at a minimum, the USCDI Version 1 data set. On 
behalf of HHS, ONC has proposed to adopt the USCDI as a standard 
(published elsewhere in this issue of the Federal Register), to be 
codified at 45 CFR 170.213, and our proposed regulation text cross-
references this regulation. These data exchanges would provide the 
enrollee's new plan with a core set of data that can 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 this proposed rule) but 
we understand that ingesting data and reconciling errors has challenges 
and proposed this more limited data set to address those concerns. We 
are seeking comment on whether the USCDI data set is comprehensive 
enough to facilitate the type of care coordination and patient access 
described in this proposal, or whether additional data fields and data 
elements that would be available under our API proposal in section III 
of this proposed rule, should also be required.
    Many key attributes of the USCDI make it suitable for the purpose 
outlined in our proposal. The USCDI includes data classes that can be 
supported by commonly used standards, including the Health Level Seven 
(HL7[supreg]) Consolidated Clinical Data Architecture (C-CDA) Version 
2.1 and the Fast Healthcare Interoperability Resources (FHIR[supreg]) 
standards for essential patient health information like vital signs, 
lab results, medications and medication allergies. The USCDI 
establishes a minimum set of data elements that would be required to be 
interoperable nationwide and is designed to be expanded in an iterative 
and predictable way over time. The USCDI, at a minimum, transferred for 
each enrollee moving among the plans subject to our proposal would 
greatly improve each plan's coordination of care efforts and spotlight 
areas of urgent need. Having this information would allow the new MA 
plan, Medicaid managed care plan, CHIP managed care entity or a QHP in 
the FFE to evaluate and review an enrollee's utilization history in a 
timely and comprehensive fashion and thus assist each enrollee to 
transition to the new plan with minimal disruption to care. By being 
able to perform timely outreach to enrollees based on past and current 
utilization, these plans could take steps to prevent unnecessary 
emergency room visits and lapses in medication and ongoing care; 
further, they could proactively address any network deficiencies that 
may impact the enrollee. We believe that having an enrollee's 
utilization history in a timely and comprehensive fashion would 
facilitate outreach and coordination efforts in ways heretofore 
unavailable on a broad basis. In all, this ability would mean that 
these plans could help new enrollees transition to new coverage rules 
and a new network with minimal disruptions to care.
    While our proposal is to require, at a minimum, exchange of the 
USCDI Version 1 data set, we reiterate that we do not propose to 
specify the means of exchanging this data at this time. While we 
anticipate that plans may opt to use APIs (such as those described in 
section III of this proposed rule) as the means to exchange this data, 
we intend to not be overly prescriptive as to how USCDI data set 
information for applicable enrollees is exchanged as we expect there 
are a variety of transmission solutions that may be employed. For 
instance, some geographic areas might have a regional health 
information exchange that could coordinate such transitions for the MA 
plans, Medicaid managed care plans, CHIP managed care entities, and 
QHPs in the FFEs that are subject to this proposal. Elsewhere, direct 
plan-to-plan exchange might be more appropriate, or beneficiary-facing 
third party applications could be used by MA plans, Medicaid managed 
care plans, CHIP managed care entities, and QHPs in the FFEs to meet 
this proposed requirement. We also expect there may be instances where 
these plans may leverage their connections to Health Information 
Exchanges to engage in the information exchanges necessary to comply 
with this proposed rule. We expect enrolled beneficiaries to have 
constant access to requesting an exchange of data as our 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 request comments on other means that the applicable 
plans may prefer to use for meeting this requirement and whether CMS 
might be able to leverage its program authority to facilitate the data 
exchanges contemplated by this proposal. We acknowledge that in some 
cases plans subject to this proposed requirement may be exchanging 
patient health information with other plans that are not similarly 
required to exchange

[[Page 7642]]

USCDI data sets for enrollees, and we request comment on how to support 
patients and providers in those situations.
    We believe that this proposed requirement would also support dual 
eligible individuals who are concurrently enrolled in MA plans and 
Medicaid managed care plans. Under our proposal, both of the dual 
eligible individual's plans would be subject to the requirement to 
exchange that individual's data in the USCDI Version 1, which should 
improve the ability of both plans to coordinate care based on that 
data. For example, when an enrollee is initially eligible for only one 
program (that is, only for Medicare and enrolled in a MA plan, or only 
for Medicaid and enrolled in a Medicaid MCO) and then becomes dually 
eligible for a second program, the sharing of data between the existing 
plan and the new plan reduces the burden on the new plan, on the 
enrollee, and on health care providers in the new plan regarding 
collecting information about prior utilization or health information. 
Rather than completing a lengthy health assessment, the enrollee in 
this example would benefit from having similar (or possibly the same) 
information transferred directly between the MA plan and the Medicaid 
managed care plan under our proposal. We seek comment on how plans 
should coordinate care and exchange information in those situations. We 
also seek comment on the associated burden on plans to exchange the 
USCDI data set under our proposal. In addition, we are interested in 
comments about potential legal barriers to exchanging the USCDI data 
set as would be required under our proposal; for example, are there 
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 raise additional considerations we should 
address in this regulation or guidance.
    We believe that activities related to this proposal may qualify as 
a quality improvement activity (QIA) meeting the criteria described in 
section 2718(a)(2) of the PHSA for purposes of the Medical Loss Ratio 
(MLR) requirements for QHP issuers in an FFE (excluding SADP 
issuers),\32\ 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. We request comments related to this assumption and its 
implications.
---------------------------------------------------------------------------

    \32\ While this rulemaking is specific to QHP issuers 
participating in 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.
---------------------------------------------------------------------------

VI. Care Coordination Through Trusted Exchange Networks: Trust Exchange 
Network Requirements for MA Plans, Medicaid Managed Care Plans, CHIP 
Managed Care Entities, and QHPs in the FFEs

    We are proposing to require MA plans, Medicaid managed care plans, 
CHIP managed care entities, and QHPs in the FFEs (excluding SADP 
issuers) to participate in trust networks in order to improve 
interoperability in these programs. We would codify this requirement 
in, respectively, 42 CFR 422.119(f)(2), 438.242(b)(5), and 457.1233(d) 
(which cross-references the requirements in 42 CFR 438.242(b)(5)) and 
45 CFR 156.221. 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, patients, and providers. 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, as 
discussed in more detail in section I.D. of this proposed rule. A 
trusted exchange framework allows for 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. 
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. While we cannot 
require widespread payer participation in trust networks, we are 
proposing here 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 benefits of such participation to those programs.
    We are proposing to require, effective beginning January 1, 2020, 
that MA plans, Medicaid managed care plans, CHIP managed care entities 
and QHPs in the FFEs (excluding not stand alone SADPs) participate in a 
trusted exchange network. 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 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 Public Health 
Service Act and section 1311(e)(1)(B) of the Affordable Care Act for 
QHP issuers in an FFE. Under our proposal, participation would be 
required in a trusted exchange framework that meets the following 
criteria:
    (1) The trusted exchange network must be able to exchange PHI, 
defined in 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 propose to codify these requirements for these plans at 42 CFR 
422.119(f)(2) for MA organizations, 438.242(b)(5) for Medicaid managed 
care plans, 457.1233(d)(2) for CHIP managed care entities, and 45 CFR 
156.221(d) for QHPs in the FFEs.
    On January 5, 2018, ONC released the draft Trusted Exchange 
Framework for public comment. Commenters to the draft framework, 
particularly payers providing comments, requested that existing trust 
networks operating successfully be leveraged in further advancing 
interoperability; thus, we are considering proposing in the future an 
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 request comments on this 
approach and how it might be aligned in the future with section 4003(b) 
of the Cures Act. We also request comments on the effective date we 
have proposed for this requirement and what benefits and challenges the 
plans (MA organization, Medicare managed care plans, CHIP managed care 
entities and QHPs in the FFE) may face meeting this requirement for 
additional consideration in future rulemaking.

[[Page 7643]]

    We believe that activities related to this proposal may qualify as 
a QIA meeting the criteria described in section 2718(a)(2) of the PHSA 
for purposes of the MLR requirements for QHP issuers in an FFE 
(excluding SADP issuers),\33\ 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. We request comments related to this assumption and its 
implications.
---------------------------------------------------------------------------

    \33\ As noted above, to the extent other commercial market 
issuers incur similar costs for coverage sold in the individual or 
group markets outside of an FFE, those expenses may similarly 
qualify as QIA.
---------------------------------------------------------------------------

VII. Improving the Medicare-Medicaid Dually Eligible Experience by 
Increasing the Frequency of Federal-State Data Exchanges

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, and the programs 
have operated as separate and distinct systems despite a growing number 
of people who depend on both programs 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 beneficiaries, while reducing 
administrative burden for providers, health plans, and states. The 
interoperability of state and CMS eligibility systems is a critical 
part of modernizing the programs and improving beneficiary and provider 
experiences. Improving the accuracy of data on dual eligibility status 
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 which parties are liable for paying that beneficiary's 
Parts A and B premiums. These data exchanges support state, CMS, and 
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,\34\ 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 31 states and the District of 
Columbia are now submitting buy-in data to CMS daily; 28 states and the 
District of Columbia are now receiving buy-in response files from CMS 
daily.
---------------------------------------------------------------------------

    \34\ CMS, ``State Buy-In Manual Chapter 3--Data Exchange,'' 
https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/downloads/buyin_c03.pdf. (last accessed September 26, 2018).
---------------------------------------------------------------------------

    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 who 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. Based on our experience with the states currently 
exchanging buy-in data daily, we have found:
     States can terminate buy-in coverage sooner and lower the 
risk of paying Part A or Part B premiums for individuals once they no 
longer qualify. Enrollees for whom the buy-in is ending have less risk 
of a retroactive deduction from their Social Security check due to 
delayed Part B buy-in terminations (while 42 CFR 407.48(c) limits 
retroactive recoupments to a maximum of 2 months, an unexpected 
deduction of up to $268 [2 months of Part B premiums in 2018] is 
significant for those with incomes low enough to be dually eligible);
     States can detect and fix errors sooner, limiting the 
impact of such errors;
     State staff can spread the workload of resolving rejected 
records across the whole month rather than a spike when they receive 
the monthly CMS response file;
     States can effectuate an earlier shift to Medicare as 
primary payer for many health care services, for those already covered 
by Medicaid;
     Beneficiaries newly eligible for buy-in who had been 
paying premiums themselves can stop having the Part B

[[Page 7644]]

premium deducted from their Social Security check sooner; and,
     Beneficiaries newly eligible for buy-in who could not 
afford Medicare premiums can access Medicare Parts A and B services and 
providers can be assured of coverage sooner.
    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. We are proposing 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 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. We believe these requirements will 
improve the economy and efficiency of operation of the ``buy-in'' 
process. We propose that states would be required to begin 
participating in daily exchange of buy-in data with CMS by April 1, 
2022. We believe this effective date will allow states to phase in any 
necessary operational changes or bundle this required change with any 
new systems implementation. There are 19 states that we anticipate will 
need to make a system change to send buy-in data to CMS daily, and 22 
states that we anticipate will need to make a system change to receive 
buy-in data from CMS daily. We estimate the one-time cost to be a 
little less than $80,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 under $160,000. We 
seek comment on these proposals.
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 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.'' 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. 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 beneficiaries into Medicare prescription drug 
plans (with regulations further establishing facilitated enrollment 
into prescription drug plans for partial-benefit dually eligible 
beneficiaries), provided that dually eligible beneficiaries 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 beneficiaries; and required 
risk-adjusting capitation payments for low-income subsidy (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 beneficiaries have accurate 
information on beneficiary cost-sharing obligations.
    It is required at 42 CFR 423.910 that 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; however, only 13 states submit MMA data 
files daily. 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, beneficiaries, and 
providers, in a number of ways including:
     Enabling an earlier transition to Medicare coverage for 
prescription drugs, which reduces the number of claims the state pays 
erroneously and has to recoup from pharmacists (that then have the 
burden of reaching out to reconcile with the new Part D plan);
     Effectuating an earlier shift to Medicare as primary payer 
for many health care services;
     Aiding timely error identification and resolution, 
mitigating the payment and other implications of the error;
     Supporting states that promote enrollment in integrated 
care by expediting the enrollment into Medicare, since beneficiaries 
must have Medicare Parts A and B, as well as Medicaid to be eligible 
for integrated products such as Dual-eligible Special Needs Plans, 
Medicare-Medicaid Plans, and the Programs for All-inclusive Care for 
the Elderly (PACE);
     Supporting beneficiaries to obtain access to Medicare Part 
D benefits and related subsidies sooner, as dual eligibility status on 
the MMA file prompts CMS to deem individuals automatically eligible for 
the Medicare Part D LIS and make changes to LIS status (for example, 
reducing copayments to $0 when data indicate a move to a nursing 
facility or use of home and community based long term care services) 
and auto-enroll them into Medicare prescription drug coverage back to 
the start of dual eligibility status; and,
     Promoting protections for QMBs by improving the accuracy 
of data for providers and QMBs on zero cost-sharing liability for 
services under Medicare Parts A and B.
    As noted, current regulation requires that the MMA files be 
submitted 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 beneficiaries with no Part 
D plan enrollment in a given month (see Medicare Prescription Drug 
Benefit Manual, Chapter 3, Section 40.1.4).\35\ While these work-
arounds provide needed protections, more frequent data

[[Page 7645]]

exchanges would mitigate the need for them.
---------------------------------------------------------------------------

    \35\ CMS, ``Medicare Prescription Drug Benefit Manual: Chapter 
3--Eligibility, Enrollment and Disenrollment (2017),'' https://www.cms.gov/Medicare/Eligibility-and-Enrollment/MedicarePresDrugEligEnrol/Downloads/CY_2018_PDP_Enrollment_and_Disenrollment_Guidance_6-15-17.pdf (last 
accessed September 26, 2018).
---------------------------------------------------------------------------

    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 are 
proposing 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 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 propose that states will be 
required to begin submitting these data daily to CMS by April 1, 2022, 
because we believe this effective date will allow states to phase in 
any necessary operational changes or bundle this required change with 
any new systems implementation. There are 37 states and the District of 
Columbia that we anticipate will need to make a system change to send 
MMA data to CMS daily. We estimate the one-time cost for a state to be 
a little less than $80,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 this proposed rule. We seek comment on 
these proposals.

B. Request for Stakeholder Input

    In addition to the proposals recommended above, we seek public 
comment for consideration in future rulemaking on how we can achieve 
greater interoperability of federal-state data for dually eligible 
beneficiaries, 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. Specifically, we seek comment on:
     Whether existing regulations, as well as those proposed 
here, sufficiently support interoperability among those serving dually 
eligible beneficiaries, and if not, what additional steps would advance 
interoperability.
     How to enhance the interoperability of existing CMS 
processes to share Medicare data with states for care coordination and 
program integrity.
     How to improve the CMS and state data infrastructure to 
support interoperability (for example, more frequent data exchanges, 
common data environment, etc.).
     For eligibility, how interoperability can provide timely, 
integrated eligibility and enrollment status across Medicare, Medicaid, 
and related agencies (for example, SSA), and reduce the need for 
persons to provide, and states to collect/process, the same demographic 
information (for example, address, income).
     For provider enrollment in both Medicaid and Medicare, how 
interoperability can streamline provider enrollment and reduce provider 
and state burden to increase systems accuracy and beneficiary 
utilization of provider enrollment data (for example, disability 
competence, hours of service, types of insurance accepted, etc.).
     For coordination of benefits, including crossover claims, 
the underlying changes that would need to be made to support 
interoperability (for example, coding, file formats, provider/
beneficiary identifier, and encounter versus FFS data).
    Please include specific examples when possible while avoiding the 
transmission of protected information. Please also include a point of 
contact who can provide additional information upon request.

VIII. Information Blocking Background and Public Reporting

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 \36\ (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 regarding practices 
which may constitute information blocking 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. 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.
---------------------------------------------------------------------------

    \36\ ONC, Report to Congress on Health Information Blocking 
(Apr. 2015), 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 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. 
In a national survey of health information organizations, half of 
respondents reported that EHR developers routinely engage in 
information blocking, and a quarter of respondents reported that 
hospitals and health systems routinely do so.\37\ Perceived motivations 
for

[[Page 7646]]

information blocking described by respondents included, for EHR 
vendors, maximizing short term revenue and competing for new clients, 
and for hospitals and health systems, strengthening their competitive 
position relative to other hospitals and health systems. Other research 
suggests that these practices weaken competition among health care 
providers by limiting patient mobility, encouraging consolidation, and 
creating barriers to entry for developers of new and innovative 
applications and technologies that enable more effective uses of 
clinical data to improve population health and the patient 
experience.\38\
---------------------------------------------------------------------------

    \37\ See, for example, Julia Adler-Milstein and Eric Pfeifer, 
Information Blocking: Is It Occurring And What Policy Strategies Can 
Address It?, 95 Milbank Quarterly 117, 124-25 (Mar. 2017), available 
at https://onlinelibrary.wiley.com/doi/10.1111/1468-0009.12247/full.
    \38\ See, for example, Martin Gaynor, Farzad Mostashari, and 
Paul B. Ginsberg, Making Health Care Markets Work: Competition 
Policy for Health Care, 16-17 (Apr. 2017), available at https://heinz.cmu.edu/news/news-detail/index.aspx?nid=3930; see also Diego 
A. Martinez et al., A Strategic Gaming Model For Health Information 
Exchange Markets, Health Care Mgmt. Science (Sept. 2016). Niam 
Yaraghi, A Sustainable Business Model for Health Information 
Exchange Platforms: The Solution to Interoperability in Healthcare 
IT (2015), available at https://www.brookings.edu/research/papers/2015/01/30-sustainable-business-model-health-information-exchange-yaraghi; Thomas C. Tsai & Ashish K. Jha, Hospital Consolidation, 
Competition, and Quality: Is Bigger Necessarily Better?, 312 J. AM. 
MED. ASSOC. 29, 29 (2014).
---------------------------------------------------------------------------

    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 (published elsewhere in this issue 
of the Federal Register)). 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 added to PHSA 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 
added to PHSA by the Cures Act 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 has taken the lead 
on this rulemaking effort, and 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 (published elsewhere in this issue of the 
Federal Register).
    We propose to publicly report certain information about eligible 
clinicians' attestations under the QPP on Physician Compare and 
eligible hospitals' and CAHs' attestations under the Medicare FFS 
Promoting Interoperability Program (previously known as the Medicare 
EHR Incentive Program) on a CMS website. As discussed below, although 
we have already implemented what is required by sections 106(b)(2)(A) 
and (B) of MACRA through the attestation requirements we have 
established in prior rulemaking (81 FR 77028 through 77035), we believe 
publishing information on which eligible clinicians, eligible 
hospitals, and CAHs have negatively attested that they have not 
knowingly and willfully taken action to limit or restrict the 
compatibility or interoperability of certified EHR technology would 
serve to discourage knowing and willful behavior that limits 
interoperability and prevents the sharing of information discussed in 
both MACRA and the Cures Act.

B. Public Reporting and Prevention of Information Blocking on Physician 
Compare

    Physician Compare (https://www.medicare.gov/physiciancompare) draws 
its operating authority from section 10331(a)(1) of the Affordable Care 
Act. Consistent with section 10331(a)(2) of the Affordable Care Act, 
Physician Compare initiated a phased approach to publicly reporting 
performance scores that provide comparable information on quality and 
patient experience measures. A complete history of public reporting on 
Physician Compare is detailed in the CY 2016 Physician Fee Schedule 
(PFS) final rule with comment period (80 FR 71117 through 71122). More 
information about Physician Compare, including the history of public 
reporting and regular updates about what information is currently 
available, can also be accessed on the Physician Compare Initiative 
website at https://www.cms.gov/medicare/quality-initiatives-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. Specifically, subparagraphs (A) and (D) of section 
1848(q)(9) of the Act facilitate the continuation of the phased 
approach to public reporting by requiring the Secretary to make 
available on the Physician Compare website, in an easily understandable 
format, individual MIPS eligible clinician and group performance 
information, including: The MIPS eligible clinician's final score; the 
MIPS eligible clinician's performance under each MIPS performance 
category (quality, cost, improvement activities, and Promoting 
Interoperability); names of eligible clinicians in Advanced APMs and, 
to the extent feasible, the names of such Advanced APMs and the 
performance of such models; and, aggregate information on the MIPS, 
posted periodically, including the range of final scores for all MIPS 
eligible clinicians and the range of the performance of all MIPS 
eligible clinicians for each performance category.
    In the CY 2018 Quality Payment Program final rule (82 FR 53827), we 
finalized a policy to include an indicator on Physician Compare, as 
technically feasible, for any eligible clinician or group who 
successfully meets the Promoting Interoperability performance category. 
We also finalized a policy to include, as technically feasible, 
additional information on Physician Compare, either on the profile 
pages or in the downloadable database, including, but not limited to 
objectives, activities, or measures specified in the CY 2018 Quality 
Payment Program final rule (82 FR 53827; see 82 FR 53663 through 53688) 
with respect to the Promoting Interoperability performance category.
    Generally, all data available for public reporting on Physician 
Compare must meet our established public reporting standards under 42 
CFR 414.1395(b). In addition, for each program year, CMS provides a 30-
day preview period for any clinician or group with QPP data being 
publicly reported on Physician Compare under 42 CFR 414.1395(d). All 
data available for public reporting--

[[Page 7647]]

such as final scores--are available for review and correction during 
the targeted review process as finalized in the CY 2017 Quality Payment 
Program final rule (81 FR 77392).
    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 
propose to make certain data about the attestation statements on the 
prevention of information blocking referenced earlier in section 
VIII.A. of this proposed rule available for public reporting on 
Physician Compare, drawing upon our authority under section 10331(a)(2) 
of Affordable Care Act, which requires 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 provides 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 believe 
section 10331(a)(2) of the Affordable Care Act provides 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.
    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 in the CY 2017 Quality Payment Program final rule (81 FR 
77028 through 81 FR 77035).
    We believe 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 are proposing 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 propose 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.
    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 
have learned that effective use of CEHRT is important to them when 
making informed health care decisions. 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 note this proposal is 
contingent upon the availability of and technical feasibility to use 
these data for public reporting. We request comment on this proposal.

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 
believe 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 are referring 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 refer readers to the preamble discussion in 
the CY 2017 Quality Payment Program final rule (81 FR 77028 through 81 
FR 77035).
    We believe 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 believe 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 propose to post 
information on a CMS website available to the public indicating that an 
eligible hospital or CAH attesting under the Medicare FFS Promoting

[[Page 7648]]

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, the attestations would be considered 
incomplete, and we would not post any information related to these 
attestation statements for that hospital or CAH. We propose to post 
this information starting with the attestations for the EHR reporting 
period in 2019, and we expect the information would be posted in late 
2020. In accordance with section 1886(n)(4)(B) of the Act, we propose 
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 propose 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 propose 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 will be 
provided outside of the rulemaking process through the usual 
communication channels for the program. We invite comments on this 
proposal.

IX. Provider Digital Contact Information

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 have updated the NPPES \39\ to be able to capture digital contact 
information for both individuals and facilities. 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.\40\ 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.
---------------------------------------------------------------------------

    \39\ The NPPES website is available at https://nppes.cms.hhs.gov/.
    \40\ See https://nppes.cms.hhs.gov/.
---------------------------------------------------------------------------

    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)). CMS reviews 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.
    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.
    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, NPPES has also 
added a public API which can be used to obtain 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 urge all providers to take 
advantage of this resource to implement Congress' requirement that

[[Page 7649]]

the Secretary establish a digital contact information index.

B. Proposed 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 propose 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 have digital 
contact information included in the NPPES system. We propose 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 are also 
requesting 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 believe would be helpful.
    We believe this information is extremely valuable to facilitate 
interoperability, and we appreciate Congress' leadership in requiring 
the establishment of this directory. We are interested in stakeholder 
comment on additional possible enforcement authorities to ensure that 
individuals and facilities make their digital contact information 
publicly available through NPPES. For example, should Medicare 
reporting programs, such as MIPS, 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 
will review comments for possible consideration in future rulemaking on 
these questions.

X. Revisions to the Conditions of Participation for Hospitals and 
Critical Access Hospitals (CAHs)

A. Background

    As noted earlier in this proposed rule, CMS appreciates the 
pathways Congress has created for action on interoperability and has 
been working diligently with ONC to implement them. In order to ensure 
broad stakeholder input to inform our proposals, we published a Request 
for Information (RFI) on interoperability in several recently published 
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 Participation (RfPs) 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 asked for 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. On November 3, 2015, 
we published a proposed rule, ``Medicare and Medicaid Programs; 
Revisions to Requirements for Discharge Planning for Hospitals, 
Critical Access Hospitals, and Home Health Agencies'' (80 FR 68126), to 
implement the discharge planning requirements of the IMPACT Act and to 
revise the discharge planning CoP requirements that hospitals 
(including short-term acute care hospitals, LTCHs, rehabilitation 
hospitals, psychiatric hospitals, children's hospitals, and cancer 
hospitals), CAHs, and HHAs must meet in order to participate in the 
Medicare and Medicaid programs. The final rule in response to public 
comment on our proposed new requirements for discharge planning for 
hospitals, CAHs, and HHAs is under development while we review and 
respond to public comments (our deadline to finalize this rule is 
November 3, 2019). Several of the proposed requirements from the 2015 
Discharge Planning proposed rule directly addressed the issue of 
communication between providers and between providers and patients, as 
well as the issue of interoperability:

     Hospitals and CAHs would be required to transfer 
certain necessary medical information and a copy of the discharge 
instructions and discharge summary to the patient's practitioner, if 
the practitioner is known and has been clearly identified;
     Hospitals and CAHs would be required to send certain 
necessary medical information to the receiving facility/PAC 
providers, at the time of discharge; and,
     Hospitals, CAHs, and HHAs would need to comply with the 
IMPACT Act requirements that would require hospitals, CAHs, and 
certain PAC providers to use data on quality measures and data on 
resource use measures to assist patients during the discharge 
planning process, while taking into account the patient's goals of 
care and treatment preferences.

    We also published the ``Medicare and Medicaid Programs; Hospital 
and Critical Access Hospital Changes to Promote Innovation, Flexibility 
and Improvement in Patient Care'' proposed rule (81 FR 39448) on June 
16, 2016, which is under development while we review and respond to 
public comments (our deadline to finalize this rule is June 15, 2019). 
In that rule, we proposed updating a number of CoP requirements that 
hospitals and CAHs would have to meet to participate in the Medicare 
and Medicaid programs. One of the proposed hospital CoP revisions 
directly addressed the issues of communication between providers and 
patients, patient access to their medical records, and 
interoperability. We proposed that patients have the right to access 
their medical records, including current medical records, upon an oral 
or written request, in the form and format requested by such patients, 
if the information is readily producible in

[[Page 7650]]

such form and format (including in an electronic form or format when 
such medical records are maintained electronically); or, if not, in a 
readable hard copy form or such other form and format as agreed to by 
the facility and the individual, and within a reasonable timeframe. 
Under the proposal, a hospital could not frustrate the legitimate 
efforts of individuals to gain access to their own medical records and 
would be required to meet these patient requests as quickly as record 
keeping systems permit.
    In response to the recent 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. At the same time, many stakeholders expressed concerns 
about implementing policy changes within the CoPs, which may increase 
the compliance burden on hospitals.
    Given responses to the recent RFI, as well as previous rulemaking 
activities, we are seeking to further expand CMS requirements for 
interoperability within the hospital and CAH CoPs as part of this 
proposed rulemaking by focusing on electronic patient event 
notifications. In addition, we are 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. We expect that this will be required through 
rulemaking at a future point in time, with one option being alignment 
with the TEFCA described in section 4003 of the Cures Act. We will also 
continue to consider the RFI responses as we pursue this goal in future 
rulemaking.
    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 effect 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.\41\ The 
authors identified a number of studies demonstrating positive effects 
on outcomes associated with better care coordination, such as 
reductions in 30-day readmissions,42 43 44  and medication 
reconciliation.\45\
---------------------------------------------------------------------------

    \41\ Menachemi N, Rahurkar S, Harle CA, Vest JR, The benefits of 
health information exchange: An updated systematic review, J Am Med 
Inform Assoc. 2018 Apr 28, accessed at https://www.ncbi.nlm.nih.gov/pubmed/29718258.
    \42\ Yeaman B, Ko KJ, Alvarez del Castillo R. Care ransitions in 
long-term care and acute care: Health information exchange and 
readmission rates. Online J Issues Nurs 2015;20(3):5. Accessed at 
https://www.ncbi.nlm.nih.gov/pubmed/26882514.
    \43\ Vest JR, Kern LM, Silver MD, Kaushal R, investigators H. 
The potential for community-based health information exchange 
systems to reduce hospital readmissions. J Am Med Inform Assoc, 2015 
March, accessed at https://www.ncbi.nlm.nih.gov/pubmed/25100447.
    \44\ Unruh MA, Jung HY, Kaushal R, Vest JR, Hospitalization 
event notifications and reductions in readmissions of Medicare FFS 
beneficiaries in the Bronx, New York. J AM Med Inform Assoc, 2017 
Apr 1, accessed at https://www.ncbi.nlm.nih.gov/pubmed/28395059.
    \45\ Boockvar KS, Ho W, Pruskowski J, et al. Effect of health 
information exchange on recognition of medication discrepancies is 
interrupted when data charges are introduced: Results of a cluster-
randomized controlled trial. J Am Med Inform Assoc 2017, accessed at 
https://www.ncbi.nlm.nih.gov/pubmed/28505367.
---------------------------------------------------------------------------

    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.\46\ We note 
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 are proposing to 
require in this rule, can be applied to various types of hospitals, 
including psychiatric hospitals, as well as to CAHs, as discussed 
below.
---------------------------------------------------------------------------

    \46\ Unruh MA, Jung HY, Kaushal R, Vest JR, Hospitalization 
event notifications and reductions in readmissions of Medicare FFS 
beneficiaries in the Bronx, New York. J AM Med Inform Assoc, 2017 
Apr 1, accessed at https://www.ncbi.nlm.nih.gov/pubmed/28395059.
---------------------------------------------------------------------------

    Patient event notifications are automated, electronic 
communications from the discharging provider to another facility, or to 
another community provider as identified by the patient, 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. Regardless 
of the information included, these notifications can help ensure that a 
receiving provider is aware that the patient has received care 
elsewhere. The notification triggers a receiving provider to reach out 
to the patient and deliver appropriate follow-up care in a timely 
manner. By notifying the physician, care manager, or care management 
team, the notification can help to improve post-discharge transitions 
and reduce the likelihood that a patient would face complications from 
inadequate follow-up care.
    In addition to their effectiveness in supporting care coordination, 
virtually all EHR systems generate the basic messages commonly used to 
support electronic patient event notifications. These notifications are 
based on admission, discharge, and transfer (ADT) messages, a standard 
message used within an EHR as the vehicle for communicating information 
about key changes in a patient's status as they are tracked by the 
system (more information about the current standard supporting these 
messages is available at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=144). As noted in the 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. Proposal for Hospitals (Proposed 42 CFR 482.24(d))

    We propose 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. As noted in the

[[Page 7651]]

discussion above, we would 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, diagnosis. We would also encourage 
hospitals, as their systems and those of the receiving providers allow, 
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 (ADT) notifications, 
compliance with this proposed standard within the Medical records 
services CoP (42 CFR 482.24) would be determined by the hospital 
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.299(f)(2); (3) sends notifications that must include the 
minimum patient health information (which must be 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 
recognize that some existing ADT messages might not include diagnosis 
and therefore seek comment on the technical feasibility of including 
this information 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 propose 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. Our goal with this proposed requirement is 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 believe 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 propose that the system utilize the ADT Messaging 
standard incorporated by reference at 45 CFR 170.299(f)(2).\47\
---------------------------------------------------------------------------

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

    While there is no criterion under the ONC Health IT Certification 
Program which certifies health IT to create and send electronic patient 
event notifications, this 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 note 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 recognize that there is currently significant variation in how 
hospitals have utilized the ADT messages to support implementation of 
patient event notifications. We also recognize 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 
\48\ for more information about standards under consideration). 
However, at this time, we do 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 are requiring that 
hospitals subject to this proposal possess a system utilizing this 
standard, hospitals may utilize other standards or features to support 
their notification systems. We request comment on this proposal, and 
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.
---------------------------------------------------------------------------

    \48\ https://www.healthit.gov/isa/admission-discharge-and-transfer.
---------------------------------------------------------------------------

    We further propose that the hospital would need to demonstrate that 
the system's notification capacity is fully operational, that it 
operates in accordance with all state and federal statutes and 
regulations regarding the exchange of patient health information. We 
intend for these notifications to be required, at minimum, for 
inpatients admitted to, and discharged and/or transferred from the 
hospital. However, we also note 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 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. While we encourage hospitals to extend the coverage 
of their notification systems to serve additional patients, outside of 
those admitted and seen as inpatients, we also seek 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 are proposing that the hospital must demonstrate 
that its system sends notifications that must include the minimum 
patient health information (which must be patient name, treating 
practitioner name, sending institution name, and, if not prohibited by 
other applicable law, patient diagnosis). The hospital would also need 
to demonstrate that the system 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, to licensed and 
qualified practitioners, other patient care team members, and

[[Page 7652]]

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) for whom the hospital has a reasonable certainty 
of receipt of notifications. Similarly, we are also proposing that the 
hospital would need to demonstrate the transmission of these 
notifications either directly, or through an intermediary that 
facilitates the exchange of health information, and either immediately 
prior to or at the time of the patient's discharge or transfer from the 
hospital, 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) for whom the hospital 
has a reasonable certainty of receipt of notifications. We believe this 
proposal will allow for a diverse set of strategies that hospitals 
might use when implementing patient event notifications.
    Through these provisions, we are seeking 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 are proposing 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. We recognize 
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 expect 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, 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 would expect hospitals, psychiatric hospitals, and 
CAHs to comply with the Health Insurance Portability and Accountability 
Act (HIPAA) privacy rules set out at 45 CFR parts 160 and 164 when 
these proposed CoP requirements for patient event notifications are 
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 Rule. The patient event notifications and other exchanges of 
patient information would be permitted as disclosures for treatment 
purposes under 45 CFR part 164.
    We also recognize that factors outside of the hospital's control 
may determine whether or not a notification is successfully received 
and utilized by a practitioner. Accordingly, we have proposed that a 
hospital would only need to send notifications to those practitioners 
for whom the hospital has reasonable certainty of receipt. While we 
expect hospitals will, to the best of their ability, seek to ensure 
that notification recipients are able to receive notifications (for 
instance, by obtaining a recipient's Direct address), we understand 
that technical issues beyond the hospital's control may prevent 
successful receipt and use of a notification.
    Finally, we note 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 wish to emphasize that our proposal regarding patient event 
notifications would be separate from the requirement regarding 
necessary medical information at 42 CFR 482.43(d). We recognize that 
processes to implement this proposal, if finalized, may intersect with 
the hospital's discharge planning process. We note that nothing in this 
proposal would affect the hospital's responsibilities under 42 CFR 
482.43(d). However, if this proposal is finalized, hospitals may 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 may seek 
to include required necessary medical information within the same 
message as a patient event notification.
    As previously stated, we are committed to continuing to identify 
further steps we can take to ensure that facilities that are 
electronically capturing information are exchanging that information 
electronically with providers that have the capacity to accept it. We 
expect that this will be required through rulemaking at a future point 
in time with one option being alignment with the TEFCA described in the 
Cures Act.

C. Proposal for Psychiatric Hospitals (Proposed 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 our regulations at 42 CFR 482.24, we are 
proposing a new electronic notification standard at 42 CFR 482.61(f) 
within the special provisions for psychiatric hospitals in this 
section.
    Similar to our proposal for hospitals at 42 CFR 482.24(d), we are 
proposing 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 have proposed for hospitals, we propose 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.299(f)(2). We propose that for a psychiatric hospital that 
currently possesses an EHR system with the capacity to generate the 
basic patient personal or demographic information for electronic 
patient event (ADT) notifications, compliance with this 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 operates in accordance with all State and Federal statutes and 
regulations regarding the exchange of patient health

[[Page 7653]]

information; (2) utilizes the content exchange standard incorporated by 
reference at 45 CFR 170.299(f)(2); (3) sends notifications that must 
include the minimum patient health information (which must be 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. 
Please note that we are requesting comment on this policy as part of 
this hospital proposal in section X.B. of this proposed rule above. 
Please see additional discussion in the proposal for hospitals above.
    Additionally, we are proposing that the hospital would need to 
demonstrate that the system 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, 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) for whom the hospital has a reasonable certainty of 
receipt of notifications. Similarly, we are also proposing that the 
hospital would need to demonstrate the transmission of these 
notifications either directly, or through an intermediary that 
facilitates the exchange of health information, and either immediately 
prior to or at the time of the patient's discharge or transfer from the 
hospital, 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) for whom the hospital 
has a reasonable certainty of receipt of notifications.
    We refer readers to the extended discussion of these proposals in 
sections X.A. and B. of this proposed rule. We seek comment on these 
proposals.

D. Proposal for CAHs

    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 our proposals for the hospital and psychiatric hospital medical 
records requirements as discussed in the preceding sections, we would 
revise 42 CFR 485.638, by adding a new standard to the CAH Clinical 
records CoP at paragraph (d), ``Electronic Notifications.'' This 
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 propose 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.299(f)(2). We propose that for a CAH that 
currently possesses an EHR system with the capacity to generate the 
basic patient personal or demographic information for electronic 
patient event (ADT) notifications, compliance with this 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.299(f)(2); (3) sends 
notifications that must include the minimum patient health information 
(which must be 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. Please note that we are requesting comment on this policy as 
part of the hospital proposal above in section X.B. of this proposed 
rule. Please see additional discussion in the proposal for hospitals 
above.
    Additionally, we are proposing that the CAH would need to 
demonstrate that the system 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, 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) for whom the CAH has a reasonable certainty of 
receipt of notifications. Similarly, we are also proposing that the CAH 
would need to demonstrate the transmission of these notifications 
either directly, or through an intermediary that facilitates the 
exchange of health information, and either immediately prior to or at 
the time of the patient's discharge or transfer from the CAH, 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) for whom the CAH has a reasonable 
certainty of receipt of notifications.
    We request comments on all of these proposals. We are especially 
interested in stakeholder feedback about how these proposals should be 
operationalized. Additionally, we seek 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 are 
also interested in stakeholder input about a reasonable timeframe for 
implementation of these proposals for hospitals, psychiatric hospitals, 
and CAHs, respectively.

XI. Request for Information on Advancing Interoperability Across the 
Care Continuum

A. Background

    Transitions across care settings have been characterized as common, 
complicated, costly, and potentially hazardous for individuals with 
complex health needs. Yet despite the need for functionality to support 
better care coordination, discharge planning, and timely transfer of 
essential health information, interoperability by certain health care 
providers such as long term and PAC, behavioral health, and home and 
community-based services continues to lag behind acute care providers. 
Research from the Assistant Secretary for Planning and Evaluation 
(ASPE) and CMS, showed that in 2014, 44 percent of patients discharged 
from an acute care hospitalization received post-acute services, such 
as an admission to a SNFs, an IRF or a LTCH, or received HHA services. 
Specifically, of the 1,260,958 patients that received

[[Page 7654]]

post-acute services following an acute care hospitalization, ``. . . 
47.8 percent were discharged to a HHA, 42.1 percent to a SNF, 8.4 
percent to an IRF, 1.0 percent to a LTCH and .7 percent to LTCH-Site 
Neutral.'' \49\ In addition to the frequency of patients discharged 
from acute care to PAC, a remarkable number of patients discharged from 
PAC services receive subsequent care by another PAC provider. For 
instance, while more current analysis is being finalized, we note that 
2012 data from the Post-Acute Care Reform Demonstration (PAC PRD) 
found, ``67 percent of those discharged to SNFs continued on to 
additional services. Almost a quarter of them were readmitted to the 
acute hospital (23.1 percent). Another third (32.7 percent) were 
discharged from the SNF to a HHA.
---------------------------------------------------------------------------

    \49\ Ongoing work under contract: HHSP23320095651WC with RTI 
International.
---------------------------------------------------------------------------

    In patients with the Acute-SNF-HHA pattern, almost 20 percent (19.9 
percent) returned to the acute care hospital within 30 days of 
discharge from the HHA. Hospital patients discharged to LTCHs and IRFs 
were also likely to use multiple types of PAC services and a 
substantial share of these cases were readmitted within 30 days of 
discharge, ranging from 15.9 percent (LTCH-to-IRF cases) to 42.8 
percent (LTCH to SNF cases).'' \50\ In examining the home health 
patterns, it is important to keep in mind that a significant number of 
the home health population does not come through an acute admission or 
as part of a post-acute trajectory of care but instead are directly 
admitted to the HHA from the community. The percentages of PAC use and 
patterns of multiple transitions reinforce the need for safeguards 
around transitions of care. These findings also speak to the importance 
of the interoperable exchange of information necessary to ensure 
continuity of care, and mitigate the risks of unintended events, such 
as those associated with medication errors, that can result from 
inadequate and untimely exchange of information.
---------------------------------------------------------------------------

    \50\ Gage BJ, Morley MA, Smith LM, Ingber MJ, Deutsch A, Kline 
TL, Dever JA, Abbate JH, Miller RD, Lyda-McDonald B, Kelleher CA, 
Garfinkel DB, Manning JR, Murtaugh CM, Stineman MG, Mallinson T. 
(March, 2012). Post-Acute Care Payment Reform Demonstration: Final 
Report Volume 2. Prepared for the Centers for Medicare and Medicaid 
Services. Available at https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/Reports/Downloads/PAC-PRD_FinalRpt_Vol2of4.pdf.
---------------------------------------------------------------------------

    Poor patient outcomes, resulting from poor communication and lack 
of information, have been found to contribute to hospital readmissions, 
emergency department (ED) visits, and adverse outcomes. A well-
documented contributor to this problem is incomplete and missing 
information for patients with frequent transitions across care 
settings. While interoperable, bidirectional exchange of essential 
health information can improve these transitions, many long-term and 
PAC, behavioral health, and home and community-based service providers 
have not adopted health IT at the same rate as acute care hospitals. 
One major contributing factor to this difference in adoption rates can 
be attributed to the fact that PAC providers were not eligible for the 
Medicare and Medicaid EHR Incentive Programs (now known as the 
Promoting Interoperability Programs), which slowed adoption of EHRs and 
other forms of interoperable health IT for these providers.
    National data on EHR adoption and interoperability by these 
providers is limited. For PAC facilities that do possess EHRs, vendor 
adoption of interoperable functionality has been slow and uneven. A 
national survey of SNFs found that 64 percent of facilities used an EHR 
in 2016, 29 percent of SNFs could send or receive health information, 
but only 7 percent could send, find, receive, and integrate such 
information.\51\ According to the 2015 National Electronic Health 
Records Survey (NEHRS), 61.3 percent of psychiatrists were using an 
EHR, of which 40.8 percent were certified systems.\52\ A CDC survey 
found that 26 percent of residential care communities used EHRs in 
2016.\53\
---------------------------------------------------------------------------

    \51\ Alvarado C, Zook K, Henry J. Electronic Health Record 
Adoption and Interoperability among U.S. Skilled Nursing Facilities 
in 2016, Washington, DC, Office of the National Coordinator for 
Health Information Technology, U.S. Department of Health and Human 
Services, September 2017. Accessed at https://www.healthit.gov/sites/default/files/electronic-health-record-adoption-and-interoperability-among-u.s.-skilled-nursing-facilities-in-2016.pdf.
    \52\ Yang N, Hing E. Table of Electronic Health Record Adoption 
and Use among Office-based Physicians in the U.S., by Specialty: 
2015 National Electronic Health Records Survey. 2017. Accessed at 
https://www.cdc.gov/nchs/data/ahcd/nehrs/2015_nehrs_ehr_by_specialty.pdf.
    \53\ QuickStats: Percentage of Residential Care Communities That 
Use Electronic Health Records, by Community Bed Size--United States, 
2016. MMWR Morb Mortal Wkly Rep 2018;67:138. DOI: https://www.cdc.gov/mmwr/volumes/67/wr/mm6704a8.htm?s_cid=mm6704a8_w.
---------------------------------------------------------------------------

B. Solicitation of Comments

    We are soliciting comment on several potential strategies for 
advancing interoperability across care settings to inform future 
rulemaking activity in this area.
    As discussed above, health IT adoption has lagged in care settings 
that were not part of the EHR Incentive Programs. We are seeking input 
on how HHS can more broadly incentivize the adoption of interoperable 
health IT systems and use of interoperable data across settings such as 
long-term and PAC, behavioral health, and those settings serving 
individuals who are dually eligible for Medicare and Medicaid and/or 
receiving home and community-based services. We invite comment on 
specific policy strategies HHS could adopt to deliver financial support 
for technology adoption and use in these settings.
    We also recognize that an ongoing challenge to advancing and 
incentivizing interoperability is the lack of agreed-upon measure 
concepts with which to gauge how well providers are routinely and 
effectively engaging in exchange of information across settings. To 
date, the measurement of interoperability has largely focused on the 
use of certified technology and the percentage of information 
exchanged. Expanding the scope of interoperability measurement beyond 
settings that were eligible for the EHR Incentive Programs is critical 
as efforts are being made to enable health IT and exchange capabilities 
across a broader range of care settings. In light of the interest by 
the stakeholder community to enable interoperability across all 
providers, HHS is seeking public comment on measure concepts that 
assess interoperability, including measure concepts that address PAC, 
behavioral health, home and community-based services, and other 
provider settings.
    A National Quality Forum report on Quality in Home and Community-
Based Services to Support Community Living: Addressing Gaps in 
Performance Measurement suggested that new types of measure concepts 
that assess quality across the continuum of care are needed. 
Specifically, NQF cited the domain of ``service delivery and 
effectiveness,'' which encompasses the level to which individuals who 
use Home and Community Based Services (HCBS) receive services and 
supports sufficient to meet their needs, as well as the domain of 
``person-centered planning and coordination,'' which includes a focus 
on the level to which services and supports across the health and 
social service systems are coordinated for individuals who receive 
HCBS. We seek comment on needed measure development work and quality 
improvement efforts focused on assuring individuals receive sufficient 
needed services across the care continuum and that their services are

[[Page 7655]]

coordinated.\54\ We are also interested in comments on the 
applicability and feasibility of measure concepts for PAC, behavioral 
health, home and community-based services as identified in previous 
ASPE reports \55\ \56\ and the report, A Measurement Framework to 
Assess Nationwide Progress Related to Interoperable Health Information 
Exchange to Support the National Quality Strategy, published by the 
National Quality Forum.\57\
---------------------------------------------------------------------------

    \54\ Quality in Home and Community-Based Services to Support 
Community Living: https://www.qualityforum.org/Publications/2016/09/Quality_in_Home_and_Community-Based_Services_to_Support_Community_Living__Addressing_Gaps_in_Performance_Measurement.aspx.
    \55\ Measurement of Interoperable Electronic Health Care Records 
Utilization Final Report: https://aspe.hhs.gov/system/files/pdf/255526/EHRUtilizationReport.pdf.
    \56\ Analyzing the Public Benefit Attributable to Interoperable 
Health Information Exchange: https://aspe.hhs.gov/system/files/pdf/258851/AnalyzingthePublicBenefitAttributabletoInteroperableHealth.pdf.
    \57\ A Measurement Framework to Assess Nationwide Progress 
Related to Interoperable Health Information Exchange to Support the 
National Quality Strategy: https://www.qualityforum.org/Projects/i-m/Interoperability_2016-2017/Final_Report.aspx.
---------------------------------------------------------------------------

    As part of its work under the IMPACT Act, which requires, in part, 
that certain patient assessment data be standardized and interoperable 
to allow for exchange of the data among PAC providers and other 
providers, CMS has defined certain standardized patient assessment data 
elements \58\ and their associated health IT vocabularies across PAC 
settings. Implementation of these standardized data elements is 
designed to support more seamless and effective assessment of quality 
across PAC settings, while also presenting a significant improvement in 
the ability of these settings to potentially share structured 
electronic data with other providers across the care continuum.
---------------------------------------------------------------------------

    \58\ For more information on the Data Element Library see 
https://del.cms.gov/DELWeb/pubHome, as well as the Data Element 
Library Training and FAQ at https://del.cms.gov/DELWeb/pubTrainFAQ. 
CMS also provides information and training on the various assessment 
instruments through which post-acute care providers must submit 
data. Training on the OASIS instrument can be found on the HH QRP 
website at https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/HomeHealthQualityInits/Home-Health-Quality-Reporting-Training.html; information related to the training on the 
IRF PAI is available on the IRF QRP website at https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/IRF-Quality-Reporting/IRF-Quality-Reporting-Training.html; information 
related to the training on the LTCH CARE Data Set is available on 
the LTCH QRP website at https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/LTCH-Quality-Reporting/LTCH-Quality-Reporting-Training.html; and information related to the 
training on the MDS is available on the SNF QRP website at https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/NursingHomeQualityInits/Skilled-Nursing-Facility-Quality-Reporting-Program/SNF-Quality-Reporting-Program-Training.html.
---------------------------------------------------------------------------

    To enable the bidirectional exchange of this health information, we 
are seeking public comment on whether hospitals and physicians should 
adopt the capability to collect and electronically exchange a subset of 
the same PAC standardized patient assessment data elements (for 
example, functional status, pressure ulcers/injuries) in their EHRs. As 
these health care providers have generally been eligible for the EHR 
Incentive Programs (now known as Promoting Interoperability Programs), 
many of them would have adopted certified EHR technology and health IT 
systems, which are required to capture and exchange certain data 
elements under the ONC Health IT certification program. The set of data 
which systems must include under the certification program is set to 
expand in coming years under the USCDI Version 1 ONC has proposed for 
HHS adoption at 45 CFR 170.213, which would establish a minimum set of 
data classes that would be required to be interoperable nationwide (see 
the ONC proposed rule published elsewhere in this issue of the Federal 
Register). The USCDI is designed to be expanded in an iterative and 
predictable way over time.
    We are seeking comment on whether to move toward the adoption of 
PAC standardized data elements through the expansion of the USCDI 
process. We are interested in whether the standardized patient 
assessment data elements that are implemented in CMS PAC assessment 
instruments in satisfaction of the IMPACT Act would be appropriate. If 
the full set of such standardized patient assessment data elements is 
not appropriate, we are seeking comment on whether a subset of these 
standardized items would be appropriate, and input on which data 
elements should be prioritized as part of a subset. We are also seeking 
information on what implementation timeline would be most appropriate 
for requiring adoption of these data elements in provider and hospital 
systems under the ONC Health IT Certification Program. We are also 
seeking comment on the administrative, development, and implementation 
burden that may be associated with adopting these data elements.

XII. Advancing Interoperability in Innovative Models

A. Promoting Interoperability

    CMS plans to utilize Center for Medicare and Medicaid Innovation 
(``Innovation Center'') authority under section 1115A of the Act to 
test ways to promote interoperability across the health care spectrum. 
Section 1115A of the Act authorizes the Innovation Center to test 
innovative payment and service delivery models expected to reduce 
program expenditures, while preserving or enhancing the quality of care 
furnished to Medicare and Medicaid beneficiaries and CHIP enrollees. 
Interoperability and health data sharing are critical to the success of 
new payment and service delivery models that incentivize high quality, 
efficient care.
    Innovation Center models can include multiple types of health care 
providers and other entities such as physician group practices, 
hospitals, PAC facilities, community-based organizations providing 
community-based long-term care services and supports or non-medical 
services, and dialysis centers. These types of health care providers 
furnish care to patients in different care settings, have different 
health IT systems, and have varied levels of experience with, and 
access to, EHR technology. The historically disparate and inadequate 
use of health IT among these providers and other entities has posed 
challenges to interoperability. Additionally, many of these types of 
health care providers are not eligible for the Promoting 
Interoperability Programs (previously known as the Medicare and 
Medicaid EHR Incentive Programs) and the associated financial 
incentives for EHR adoption and meaningful use.
    We believe Innovation Center models (https://innovation.cms.gov/) 
provide an important lever to advance progress toward interoperability. 
These models offer unique opportunities to engage with health care 
providers and other entities in innovative ways and to test concepts 
that have the ability to accelerate change in the U.S. health care 
system, including to promote interoperability. One example of CMS's use 
of Innovation Center Models to promote interoperability is found in the 
Innovation Center's State Innovation Models (SIM) initiative (https://innovation.cms.gov/initiatives/state-innovations/), under which several 
awards to states are focused on health information exchanges and health 
IT investment. Another example of this work is found in the 
Comprehensive Primary Care Plus (CPC+) model

[[Page 7656]]

(https://innovation.cms.gov/initiatives/comprehensive-primary-care-plus), in which primary care practices use health IT to strengthen 
their ability to deliver care, with some practices partnering with 
health IT vendors to implement advanced health IT functionality in 
their practices, including functionality that promotes interoperability 
and sharing of electronic health information.

B. Examples of Interoperability-Related Areas of Focus for New Model 
Development

    Examples of how we may focus on interoperability related-issues in 
future model development may include: Models that incorporate piloting 
emerging standards; models leveraging non-traditional data in model 
design (for example, data from schools, data regarding housing and data 
on food insecurity); and models leveraging technology-enabled patient 
engagement platforms. The Innovation Center has incorporated non-
clinical data in prior models, but anticipates addressing additional 
uses and types of non-clinical data in future models.
    We are now requesting public comment on the following general 
principles around interoperability within Innovation Center models for 
integration into new models, through provisions in model participation 
agreements or other governing documents. In applying these general 
principles, we intend to be sensitive to the details of individual 
model design, and the characteristics and capacities of the 
participants in each specific model.

C. Establishing Principles for Promoting Interoperability in Innovative 
Model Tests

1. Provide Patients Access to Their Own Electronic Health Information
    The MyHealthEData and Medicare Blue Button 2.0 initiatives aim to 
empower patients by ensuring that they have access to their health care 
data and can decide how their data is going to be used, all while 
keeping their data safe and secure. Certain Innovation Center models 
already require that participants with direct patient interactions 
provide their patients with electronic access to their health 
information within 24 hours of any encounter. New Innovation Center 
models may also require that providers and other health care entities 
with direct patient interactions provide patients access to their own 
electronic health information and, upon the patient's authorization, to 
third party developers via APIs.
2. Promote Trusted Health Information Exchange
    Innovation Center model participants may, where appropriate, be 
required to participate in a trusted exchange network that meets the 
following criteria:
     The trusted exchange network must be able to exchange PHI 
in compliance with all applicable state and federal laws across 
jurisdictions.
     The trusted exchange network must connect both inpatient 
EHRs and ambulatory EHRs.
     The trusted exchange network must support secure messaging 
or electronic querying by and between patients, providers and payers.
    Additionally, model participants may be required to participate in 
electronic alerting via one of the standards described in the ISA, II-
A: Admission, Discharge, and Transfer published and updated by ONC.
3. Adopt Leading Health IT Standards and Pilot Emerging Standards
    Emerging health data standards present new opportunities to 
exchange more types of health care data between health care providers. 
Innovation Center model participants, along with their health IT 
vendors, may pilot new FHIR standards and advance adoption of new data 
classes in USCDI (for example, psychosocial data) to improve 
interoperability for care management, quality reporting or other 
priority use cases. As part of the design and testing of innovative 
payment and service delivery models, the Innovation Center anticipates 
taking on a leadership role in developing new or less mature FHIR and 
supporting more innovative interventions undertaken by states, whenever 
possible.

D. Request for Stakeholder Input

    The Innovation Center seeks public comment on the principles for 
promoting interoperability in innovative payment and service delivery 
models described above. Additionally, the Innovation Center is 
requesting public comment on other ways in which the Innovation Center 
may further promote interoperability among model participants and other 
health care providers as part of the design and testing of innovative 
payment and service delivery models.

XIII. Request for Information on Policies To Improve Patient Matching

A. Background

    Through stakeholder feedback such as roundtables, stakeholder 
meetings, and rulemaking, we have received considerable feedback that 
the lack of a UPI inhibits interoperability efforts because, without a 
unique identifier for each patient, the safe and secure electronic 
exchange of health information is constrained as it is difficult to 
ensure that the relevant records are all for the same patient. HIPAA 
required the adoption of a ``unique individual identifier for 
healthcare purposes,'' commonly referred to as a UPI. At the time HIPAA 
was enacted, HHS began to consider what information would be needed to 
develop a rule to adopt a UPI standard. An initial Notice of Intent to 
issue a proposed rule on requirements for a unique health identifier 
for individuals was published in the November 2, 1998 Federal Register 
(63 FR 61773 through 61774).
    Appreciating the significant privacy and security concerns raised 
by stakeholders regarding implementing a UPI, Congress included 
language in the Omnibus Consolidated and Emergency Supplemental 
Appropriations Act of 1999 (Pub. L. 105-277, enacted October 21, 1998) 
and in each subsequent Appropriations bill, stating none of the funds 
made available in this Act may be used to promulgate or adopt any final 
standard under section 1173(b) of the Act (42 U.S.C. 1320d-2(b)) 
providing for, or providing for the assignment of, a unique health 
identifier for an individual (except in an individual's capacity as an 
employer or a health care provider), until legislation is enacted 
specifically approving the standard. This language has effectively 
prohibited HHS from engaging in rulemaking to adopt a UPI standard. 
Consequently, the Secretary withdrew the Notice of Intent to pursue 
rulemaking on this issue on August 9, 2000 (https://www.reginfo.gov/public/do/eAgendaViewRule?pubId=200010&RIN=0938-AI91).
    Although the appropriations language regarding the UPI standard has 
remained unchanged, in the report accompanying the 2017 appropriations 
bill, Congress additionally stated, although the Committee continues to 
carry a prohibition against HHS using funds to promulgate or adopt any 
final standard providing for the assignment of a unique health 
identifier for an individual until such activity is authorized, the 
Committee notes that this limitation does not prohibit HHS from 
examining the issues around patient matching. Accordingly, the 
Committee encouraged the Secretary, acting through ONC and CMS, to 
provide technical assistance to private-sector led initiatives to 
develop a coordinated national strategy that will

[[Page 7657]]

promote patient safety by accurately identifying patients to their 
health information. (H.R. Rep. No. 114-699, p. 110, https://www.gpo.gov/fdsys/pkg/CRPT-114hrpt699/pdf/CRPT-114hrpt699.pdf). 
Congress has repeated this guidance for 2018 and 2019. This guidance 
directed HHS to focus on examining issues around patient matching and 
to provide technical assistance to private sector-led initiatives 
focusing on a patient matching solution.
    In conjunction with ONC, we are posing a request for information 
regarding how CMS could leverage our program authority to improve 
patient identification to facilitate improved patient safety, enable 
better care coordination, and advance interoperability. Inaccurate 
patient matching can lead to adverse events, compromised safety and 
privacy, inappropriate and unnecessary care, increased health care 
costs, and poor oversight of fraud and abuse. We consider this a 
quality of care and patient safety issue and seek stakeholder input on 
ways we can incent improvements.
    In section 4007 of the 21st Century Cures Act, the Government 
Accountability Office (GAO) was directed to conduct a study to 
determine whether ONC and other stakeholders could improve patient 
matching through various mechanisms, to survey ongoing efforts related 
to the policies and activities and the effectiveness of such efforts 
occurring in the private sector, and to evaluate current methods used 
in certified EHRs for patient matching. The GAO was also tasked with 
submitting to Congress a report concerning the findings of the study. 
This report was released in January 2019.\59\
---------------------------------------------------------------------------

    \59\ https://www.gao.gov/assets/700/696426.pdf.
---------------------------------------------------------------------------

    In section I of this proposed rule, we discuss further how patient 
identification and matching pose challenges to interoperability. We 
look forward to working with ONC as we review the responses to this RFI 
in concert with the GAO report to help inform potential appropriate 
methods to scale best practices and leverage program authority to 
improve patient matching.

B. Solicitation of Comments

    We are soliciting comment on potential strategies to address 
patient matching. Many stakeholders commenting on the interoperability 
RFIs included in the various 2019 proposed payment rules, including the 
FY 2019 IPPS proposed rule (83 FR 20550), indicated that patient 
matching is a ``core functionality'' of patient identification and 
necessary to ensure care coordination and the best patient outcomes. 
Commenters also noted that a consistently used matching strategy could 
accomplish the original goals of a UPI with a diminished risk to 
individual privacy and health information security. We solicit comment 
on how and in what way patient matching does or does not present the 
same security and privacy risks as a UPI.
    We understand the significant health information privacy and 
security concerns raised around the development of a UPI standard and 
the current prohibition against using HHS funds to adopt a UPI 
standard. Recognizing Congress' statement regarding patient matching 
and stakeholder comments stating that a patient matching solution would 
accomplish the goals of a UPI, we seek comment on ways for us to 
continue to facilitate private sector work on a workable and scalable 
patient matching strategy so that the lack of a specific UPI does not 
impede the free flow of information for future consideration.
    We are also seeking comment on how we may leverage our program 
authority to provide support to those working to improve patient 
matching. We specifically seek input on the following questions and the 
potential authority for the requirement:
    1. Should CMS require Medicare FFS, MA Plans, Medicaid FFS, 
Medicaid managed care plans (MCOs, PIHPs, and PAHPs), CHIP FFS, CHIP 
managed care entities, and QHP issuers in FFEs (not including SADP 
issuers), use a patient matching algorithm with a proven success rate 
of a certain percentage where the algorithm and real world processes 
associated with the algorithm used are validated by HHS or a 3rd party?
    2. Should CMS require Medicare FFS, the MA Plans, Medicaid FFS, 
Medicaid managed care plans, CHIP FFS, CHIP managed care entities, and 
QHP issuers in FFEs to use a particular patient matching software 
solution with a proven success rate of a certain percentage validated 
by HHS or a 3rd party?
    3. Should CMS expand the recent Medicare ID card efforts by 
requiring a CMS-wide identifier which is used for all beneficiaries and 
enrollees in health care programs under CMS administration and 
authority, specifically by requiring any or all of the following:
     That MA organizations, Part D prescription drug plan 
sponsors, entities offering cost plans under section 1876 of the Act, 
and other Medicare health plans use the Medicare ID in their plan 
administration.
     That State Medicaid and CHIP agencies in their FFS or 
managed care programs use the Medicare ID for dual eligible individuals 
when feasible.
     That QHP issuers in FFEs use the Medicare ID for their 
enrollees in the administration of their plans.
    4. Should CMS advance more standardized data elements across all 
appropriate programs for matching purposes, perhaps leveraging the 
USCDI proposed by ONC for HHS adoption at 45 CFR 170.213.
    5. Should CMS complement CMS data and plan data in Medicaid managed 
care plans (MCOs, PIHPs, and PAHPs), CHIP managed care entities, MA 
Plans, and QHP issuers in an FFE (not including SADP issuers) with one 
or more verifying data sources for identity proofing? What potential 
data source should be considered? What are possible restrictions or 
limitations to accessing such information?
    6. Should CMS support connecting EHRs to other complementary 
verifying data sources for identity proofing? What potential data 
source should be considered? What are possible restrictions or 
limitations to accessing such information?
    7. To what extent should patient-generated data complement the 
patient-matching efforts?

XIV. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995, we are required to 
provide 60-day notice in the Federal Register and solicit public 
comment before a collection of information requirement is submitted to 
the 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 are soliciting public comment on each of these issues for the 
following sections of this document that contain information collection 
requirements (ICRs):

[[Page 7658]]

A. Background

    Health plans 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. Health plans 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. To 
advance our commitment to interoperability, we are proposing new 
requirements to implement APIs 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, CHIP managed care at 42 CFR 
457.1233(d), and QHP issuers in FFEs, excluding SADPs at 45 CFR 
156.221. These openly published APIs will permit third-party 
applications to retrieve standardized data for adjudicated claims, 
encounters with capitated and subcapitated providers, provider 
remittances, beneficiary cost-sharing, reports of lab test results 
(depending on whether the plan manages such data), provider 
directories, and, as applicable, preferred drug lists. We believe that 
these proposals are designed to empower patients by making sure that 
they can access their healthcare data, through the use of common 
technologies, without special effort and in an easily usable digital 
format. We also expect our API proposals to enable the enrollees in the 
plans that are subject to our proposal to share their healthcare data. 
By making claims data readily available and portable to the patient, 
these initiatives support moving our healthcare 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 provider visits; 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' May 2017 National Occupational Employment and Wage 
Estimates for Direct Health and Medical Insurance Carriers (NAICS 
524114) (https://www.bls.gov/oes/current/naics5_524114.htm). Table 1 
presents the mean hourly wage, the cost of fringe benefits (calculated 
at 100 percent of salary), and the adjusted hourly wage.

                                    Table 1--Occupation Titles and Wage Rates
----------------------------------------------------------------------------------------------------------------
                                                                                                     Adjusted
                Occupation title                    Occupation      Mean hourly   Fringe benefit  hourly wage (/
                                                       code         wage (/hr)         (/hr)            hr)
----------------------------------------------------------------------------------------------------------------
Administrators and Network Architects...........         15-1140          $46.35          $46.35          $92.70
Security Engineer...............................         17-2199           50.66           50.66          101.32
Computer and Information Analysts...............         15-1120           41.98           41.98           83.96
General Operations Mgr..........................         11-1021           72.51           72.51          145.02
Operations Research Analysts....................         15-2031           37.33           37.33           74.66
Software Developers, Applications...............         15-1132           45.57           45.57           91.14
Computer and Information Systems Managers.......         11-3021           71.10           71.10          142.20
General and Operations Mgr......................         11-1021           72.51           72.51          145.02
Designers.......................................         27-1020           29.32           29.32           58.64
Technical Writer................................         27-3042           32.68           32.68           65.36
Computer Systems Analysts.......................         15-1121           41.59           41.59           83.18
Network and Computer Systems Administrators.....         15-1142           43.64           43.64           87.28
----------------------------------------------------------------------------------------------------------------

    As indicated, we are adjusting our 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 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 file is called 
the MMA file, but is occasionally referred to as the ``State Phasedown 
file.'' Section 423.910(d) requires 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 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 are 
proposing 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 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 estimate it would take a computer 
systems analyst about 6 months (approximately 960 hours) to complete 
the systems updates necessary to process and submit the MMA data daily. 
As only 13 states currently submit MMA data daily, we estimate a one-
time burden for 37 states and the District of Columbia complying with 
submission of daily MMA data at 3,034,406 (38 states (and DC) x 960 
hours x 83.18 per hour for a computer system analyst). 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, 431.60, and 438.242, 
and 45 CFR 156.221)
    To promote our commitment to interoperability, we are proposing new 
requirements for APIs 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, CHIP managed care at 42 CFR 457.1233(d), and QHP 
issuers in FFEs at 45 CFR

[[Page 7659]]

156.221. These openly published APIs will permit third-party 
applications to retrieve standardized data for adjudicated claims, 
encounters with capitated and subcapitated providers, provider 
remittances, beneficiary cost-sharing, reports of lab test results, 
provider directories, and preferred drug lists. To implement the new 
requirements for APIs, 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 initial design phase, we believe 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 believe plans and 
states would need to conduct the following: Map existing data to FHIR, 
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 is populated on the FHIR server; build connections 
between the databases and FHIR server; perform capability and security 
testing; and vetting third-party applications.
    After the completion of the API development, we believe that plans 
and states would need to conduct the following on an annual basis: 
Allocate resources to maintain the FHIR server, and perform capability 
and security testing.
    The burden estimate related to the new requirements for APIs 
reflects the time and effort needed to collect the information 
described above and disclose this information. We estimate an initial 
set one-time costs associated with the implementing the API 
requirements. We presume that it will take administrators and network 
architects 1440 hours (at 92.70 an hour), security engineers 960 hours 
(at 101.32 an hour), computer and information analysts 480 hours (at 
83.96 an hour), operations research analysts 960 hours (at 74.66 an 
hour), software developers 960 hours (at 91.14 an hour), computer and 
information systems managers 720 hours (at 142.20 an hour), general and 
operations managers 720 hours (at 145.02 an hour), designers 960 hours 
(at 58.64 an hour), technical writers 240 hours (at 65.36 an hour), and 
computer systems analysts 960 hours (at 83.18 an hour). We estimate a 
one-time burden assessment of 8,400 (1440hrs + 960hrs + 480hrs + 960hrs 
+ 960hrs + 720hrs + 720hrs + 960hrs + 240hrs + 960hrs) hours per 
organization or state and a total of 3,898,000 (8,400hrs x 345 
organizations) hours across all organizations or states. The one-time 
cost to implement API requirements is 789,356.00 per organization or 
state per implementation and 275,432,820 across all organizations or 
states to complete the task described above.
    Once the API is established, we believe that there would be an 
annual cost for performing necessary capability and security testing, 
performing necessary upgrades and vetting of third-party applications. 
We presume that it would take administrators and network architects 180 
hours (at 92.70 an hour), network and computer systems administrators 
420 hours (at 87.28 an hour), security engineers 240 hours (at 101.32 
an hour), computer and information analysts 60 hours (at 83.96 an 
hour), operations research analysts 120 hours (at 74.66 an hour), 
software developers 240 hours (at 91.14 an hour), computer and 
information systems managers 90 hours (at 142.20 an hour), general and 
operations managers 90 hours (at 145.02 an hour), designers 120 hours 
(at 58.64 an hour), technical writers 30 hours (at 65.36 an hour), and 
computer systems analysts 120 hours (at 83.96 an hour). We estimate the 
total annual burden to be 1,710 hours (180hrs + 420hrs + 60hrs + 120hrs 
+ 240hrs + 90hrs + 120hrs + 30hrs + 120hrs) per organization or state, 
and 589,950 hours (1,710hrs x 345 organizations) across all 
organizations and states. Thus, the total annual cost to maintain the 
API requirements is 158,359.80 per organization or state and 54,634,131 
across all organizations and states.
3. Summary of Information Collection Burdens

                                                   Table 2--Summary of Information Collection Burdens
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                                          Hourly
                                                                                    Burden     Total      labor    Total labor     Total
       Regulation Section(s)         OMB Control Number    Number of   Number of     per       annual    cost of     cost of      capital/    Total cost
                                                          respondents  responses   response    burden   reporting   reporting   maintenance      ($)
                                                                                   (hours)    (hours)      ($)         ($)       costs ($)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Sec.   423.910....................  0938-0958 *.........          38          38         20        960      83.18    3,034,406           0     3,034,406
Sec.   422.119, Sec.   431.60,      0938-New............         345         345        840  2,889,600  .........  275,432,820           0   275,432,820
 Sec.   457.730, Sec.   438.242,
 Sec.   457.1233 and Sec.
 156.221.
Sec.   422.119, Sec.   431.60,      0938-New............         345         345      1,710    588,240  .........   54,634,131           0    54,634,131
 Sec.   457.730, Sec.   438.242,
 Sec.   457.1233, and Sec.
 156.221.
                                   ---------------------------------------------------------------------------------------------------------------------
    Total.........................  ....................         344         344      2,570  3,478,800  .........  333,101,357  ...........  333,101,357
--------------------------------------------------------------------------------------------------------------------------------------------------------
* This currently approved ICR will be revised to include the burden discussed in this rule.

    If you comment on these information collections, that is, 
reporting, recordkeeping or third-party disclosure requirements, please 
submit your comments electronically as specified in the ADDRESSES 
section of this proposed rule.
    Comments must be received on/by May 3, 2019.

D. Exempt ICRs

1. Usual and Customary Business Practices
    While the requirements under 42 CFR 482.24(d), 482.61(f) and 
485.638 are subject to the PRA, we believe the burden associated with 
those requirements is exempt from the PRA in accordance with 5 CFR 
1320.3(b)(2). We believe that the time, effort, and financial resources 
necessary to comply with these requirements would be incurred by 
persons during the normal course of their activities, and therefore, 
should be considered usual and customary business practices.
    We are proposing to further expand CMS requirements for 
interoperability within the hospital, psychiatric hospital, and CAH 
CoPs by focusing on electronic patient event notifications.

[[Page 7660]]

For hospitals, psychiatric hospitals, and CAHs, we are proposing 
similar requirements to revise the CoPs for Medicare- and Medicaid-
participating hospitals, psychiatric hospitals, and CAHs by adding a 
new standard, ``Electronic Notifications,'' that would require 
hospitals, 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. We propose to limit this requirement to only those hospitals, 
psychiatric hospitals, and CAHs which currently possess EHR systems 
with the technical capacity to generate information for electronic 
patient event notifications, recognizing that not all Medicare- and 
Medicaid-participating hospitals and psychiatric hospitals have been 
eligible for past programs promoting adoption of EHR systems. We intend 
for these notifications to be required, at minimum, for inpatients 
admitted to, and discharged and/or transferred from the hospital, 
psychiatric hospital, or CAH. These requirements would help support 
coordination of a patient's care between settings or with services 
received through different care settings. These sections would require 
updates to discharge planning processes, which has been a long-standing 
industry practice. 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 
a receiving facility or to another community provider that alert the 
receiving provider that a patient is receiving, or has received, care 
at a different setting.
    These notifications are based on ``admission, discharge, and 
transfer'' (ADT) messages, a standard message used within an EHR as the 
vehicle for communicating information about key changes in a patient's 
status as they are tracked by the system (more information about the 
current standard supporting these messages is available at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=144). As 
noted in the 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 note 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 
wish to emphasize that the proposal in this proposed rule around 
patient event notifications is independent of the requirement regarding 
necessary medical information at 42 CFR 482.43(d). As these processes 
are already required, and as many EHR systems already have an 
electronic notification system in place, we do not anticipate a 
significant increase in burden on hospitals, psychiatric hospitals, and 
CAHs with the adoption of this proposal. However, we recognize that 
processes to implement this proposal, if finalized, might intersect 
with the hospital's discharge planning process. We note that nothing in 
this proposal would affect the hospital's responsibilities under 42 CFR 
482.43(d). However, if this proposal is finalized, hospitals might wish 
to consider ways to fulfill these requirements in ways that reduce 
redundancy while still fully meeting the provisions of each. For 
instance, where appropriate, hospitals might seek to include required 
necessary medical information within the same message as a patient 
event notification.

XV. Response to Comments

    Because of the large number of public comments we normally receive 
on Federal Register documents, we are not able to acknowledge or 
respond to them individually. We will consider all comments we receive 
by the date and time specified in the DATES section of this preamble, 
and, when we proceed with a subsequent document, we will respond to the 
comments in the preamble to that document.

XVI. Regulatory Impact Analysis

A. Statement of Need

    As described in detail in section III. of this proposed 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 the data. Moving to 
a system in which patients have access of 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. Our proposals here are designed to 
move the Medicare, MA, Medicaid, CHIP and QHP programs further to that 
ultimate goal of empowering their enrollees. 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; these proposals would 
enable beneficiaries and enrollees 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 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 would reduce this administrative burden. As 
described in detail in section VII. of this proposed 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.
    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-

[[Page 7661]]

new Medicare Part D prescription drug benefit. Over time, we used 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.

B. Overall Impact

    We have examined the impacts of this proposed 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 3 summarizes the estimated costs presented in the 
Collection of Information section of this proposed rule. 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 for future years do not take into account ordinary 
inflation.

                                        Table 3--Estimated Aggregate Costs to the Health Care Sector by Provision
                                                                 [CYs 2020 through 2024]
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                                                   Calendar year ($ in millions)                          Total CY 2020-
             Provision                   Regulation      --------------------------------------------------------------------------------   2024 ($ in
                                         section(s)            2020            2021            2022            2023            2024         millions) *
--------------------------------------------------------------------------------------------------------------------------------------------------------
Requirements to Patient Access      Sec.   422.119, Sec.           275.4            54.7            54.7            54.7            54.7           494.0
 Through APIs.                         431.60, Sec.
                                     438.242, Sec.
                                     457.730, Sec.
                                     457.1233, Sec.
                                     156.221.
Dual Eligible Care Coordination...  Sec.   406.26, Sec.              0.7             2.2             2.2             1.2               0             6.3
                                      407.40, Sec.
                                     423.910.
                                   ---------------------------------------------------------------------------------------------------------------------
    Total Cost....................  ....................           276.1            56.9            56.9            55.9            54.7           500.3
--------------------------------------------------------------------------------------------------------------------------------------------------------
* Total may not equal sum of parts due to rounding.

    Allocation of Cost Impact by Program: As stated in the Collection 
of Information Section of this proposed rule, cost estimates have been 
aggregated at the parent organization level because we believe that an 
organization that offers commercial, Medicare, Medicaid, and CHIP 
products would create one system that would be used by all ``plans'' it 
offers. 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 program.
    Preliminary Estimates: Later in this RIA section, we provide 
several detailed estimates of cost by program where we account for 
Federal matching for Medicaid and payments by the Trust Fund for 
Medicare Advantage Organizations. However, these estimates are 
approximate as explained in detail below. Therefore, the purpose of 
this preliminary estimate section, is to observe that the costs of this 
proposed rule are negligible relative to the costs of the various 
programs it impacts.
    For purposes of clarification we use the metric of ``costs per 
enrollee.'' The ``costs per enrollee'' whether for Medicaid or 
Medicare, does not refer to actual costs paid by the enrollee but 
rather is a metric, it is the quotient of total program expenditures 
divided by total enrollees. The cost per enrollee metric facilitates 
comparison of costs. Since program expenditures for both Medicaid and 
MA are typically

[[Page 7662]]

hundreds of millions (or billions) of dollars, concepts like 
negligibility do not have intuitive meaning. Contrastively, the costs 
per enrollee are more manageable and understandable. The 2018 Medicare 
Trust Fund \60\ 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. We estimate 169 million enrollees will be affected by 
these provisions since. Currently there are 76, 66,\61\ 20,\62\ and 
7\2\ million enrollees in the commercial, Medicaid, MA and separate 
CHIP programs respectively.
---------------------------------------------------------------------------

    \60\ https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf.
    \61\ https://www.medicaid.gov/medicaid/program-information/medicaid-and-chip-enrollment-data/report-highlights/.
    \62\ 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.
---------------------------------------------------------------------------

    The total first year (implementation) cost per enrollee is $1.63 
($276.1 million cost (Table 3) divided by 169 million enrollees); 
maintenance cost per enrollee in the following years are 34 cents 
($56.9 million total cost (Table 3) divided by 169 million enrollees). 
The assertion that $1.63 and $0.34 is negligible compared to the 
$12,000-$14,000 cost per enrollee for the MA program or the several 
thousand-dollar cost per enrollee for the Medicaid program has 
intuitive appeal. However, these are very rough preliminary estimates. 
In the remainder of this RIA, we provide, subject to the limitations 
noted, more detailed impact by program.
    Data Sources for Cost by Program: To obtain allocation of cost by 
program we used the CMS public use files for MLR data, for 
2016.63 64 The MLR data sets are for private insurance plans 
but the issuers of that private (commercial) 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 
commercial MLR reporting form.
---------------------------------------------------------------------------

    \63\ https://www.cms.gov/CCIIO/Resources/Data-Resources/mlr.html.
    \64\ Although the 2017 MLR data recently became available, using 
them would not change the bottom line of the analysis. The 2016 data 
gives $113 billion, $157 billion and $370 billion enrollees for 
commercial, MA, and Medicaid plans respectively resulting in revenue 
proportions of 57.81 percent, 24.53 percent, 17.68 percent. The 2017 
data gives $119.5, $170.3 and $381.5 billion for commercial MA, and 
Medicaid plans resulting in proportions of 56.8 percent, 25.36 
percent, and 17.79 percent. The 76 million commercial enrollees from 
the 2016 data decreased to 73.5 million in 2017. Using these 
alternate proportions and numbers would not change significantly our 
dollar-per-enrollee estimates of impacts.
---------------------------------------------------------------------------

    Thus, these MLR data sets omit organizations that only have 
Medicare or Medicaid. The data from the CMS MLR files also omits: (1) 
The CHIP program; and (2) Medicaid State Agencies. We now discuss these 
omissions to assess the accuracy of using these MLR files.
    CHIP: 85 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 would be used both by 
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.\65\ 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.
---------------------------------------------------------------------------

    \65\ https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf 
Table IV.C2.
---------------------------------------------------------------------------

    Medicaid: For the year for which these MLR files provide data, 
2016, about 70 percent of Medicaid enrollees were enrolled in Medicaid 
Managed Care.\66\ Thus although the MLR files omit State Agencies, we 
believe that the 70 percent Medicaid enrollees enrolled in Medicaid 
Managed Care provides a good approximation.
---------------------------------------------------------------------------

    \66\ https://www.cms.gov/newsroom/press-releases/cms-proposes-changes-streamline-and-strengthen-medicaid-and-chip-managed-care-regulations.
---------------------------------------------------------------------------

    Finally, as noted in the section ``Preliminary Estimates'', 
independent of these omissions, the average cost per enrollee is capped 
at $1.63 and $0.34 in first and follow up years.
    Best Estimates of Impact per Program: We present two methods to 
obtain an estimate of cost by program both for purposes of assessing 
impact on small entities, as well as for purposes of assessing impacts 
of the provision on the Federal government, programs, and 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, programs, 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).
    Among issuers with products in both Commercial and MA or Commercial 
and Medicaid, the 2016 CMS MLR files show $370 billion reported in 
premium for commercial plans, $157 billion reported for MA, and $113 
billion reported for Medicaid. Consequently, the proportion of 
interoperability cost for each of the programs is 57.81 percent (370/
(370+157+113)), 24.53 percent (157/(370+157+113)), and 17.66 percent 
(113/(370+157+113)) for Commercial, MA, and Medicaid respectively.
    Using these proportions, Table 4 breaks out the top row in Table 3, 
the total cost by year of implementing and maintaining the API, by 
program.

                                                  Table 4--API Costs (in Millions) by Year and Program
--------------------------------------------------------------------------------------------------------------------------------------------------------
                          Year                                 2020            2021            2022            2023            2024            Total
--------------------------------------------------------------------------------------------------------------------------------------------------------
Full Implementation and Maintenance costs (Table 3, Row            275.4            54.7            54.7            54.7            54.7           494.0
 1).....................................................
Commercial Programs (57.81%)............................           159.2            31.6            31.6            31.6            31.6           285.6
Medicaid and CHIP programs (17.66%).....................            48.6             9.7             9.7             9.7             9.7            87.2
Medicare Advantage Programs (24.53%)....................            67.6            13.4            13.4            13.4            13.4           121.2
--------------------------------------------------------------------------------------------------------------------------------------------------------


[[Page 7663]]

    Methods of Bearing Cost by Program: Commercial plans have the 
options to deal with increased costs by either temporarily absorbing 
them (for purposes of market competitiveness), increasing premiums to 
enrollees, or reducing benefits.
    To the extent that issuers increase premiums for plans in the FFE, 
there would be Federal premium tax credit (PTC) impacts. However, the 
PTC formula is highly individual-specific, that is, it is the result of 
the relationship between the premium of the second lowest-cost silver 
plan applicable to a specific consumer in a specific month, the cost of 
the actual plan purchased by that consumer for that month, and that 
consumer's income. Consequently, it would not be possible to estimate 
the magnitude of the PTC impact with a reliable degree of accuracy, 
since we cannot predict: (1) What proportion of costs would be passed 
on to enrollees as increased premiums; (2) to what extent commercial 
issuers may recoup investment costs through raising premiums on the 
second-lowest cost silver plans or on other plans; and (3) whether or 
in what ways such premium increases may impact the PTC calculation or 
eligibility with respect to various consumers,
    To deal with this uncertainty, we list the possible Federal PTC 
impacts as a qualitative impact. Most importantly, we assume the 
unlikely worst case scenario that all cost is passed on as premium to 
the enrollee without subsidization; we then show that the net impact 
per enrollee per month is extremely small (see Table 7).
    Medicare Advantage: Medicare Advantage Organizations (MAOs) pass 
increased costs back to the Trust Fund. For those (most) MAOs whose bid 
amount is below the benchmark, the Trust Fund provides total 
expenditures to the MAOs 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 MAOs are increasing their bid 
amounts to reflect the costs of this proposed rule, it follows that the 
rebate, equaling the difference between the benchmark and bid, is 
decreased, resulting in less rebates paid to the MAOs. Based on our 
historical and projected experience, 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 proposed rule, are reduced from 
the rebates. The MAO in its submitted bid, can address this reduction 
of rebates by either: (1) Temporarily, for marketing purposes, 
absorbing the loss, and reducing its profit margin; (2) reduce the 
additional benefits it provides the enrollee paid for by the rebate; or 
(3) raise enrollee premiums.
    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 open API provisions would be built into 
the capitation rates and matched at the State's medical assistance 
match rate. For purposes of these estimates we use the weighted FMAP, 
58.44.
    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 5 uses these proportions to estimate the impact of the API on 
the Federal Government. For example, the $28.4 million cost to the 
Federal government for Medicaid/CHIP for 2020, the implementation year 
of the API, is obtained by multiplying the State Agency Medical 
Assistance average match rate to Medicaid Managed Care Plans, 58.44%, 
by the $48.6 million total cost to Medicaid for 2020 listed in Table 4.

                                     Table 5--Costs (in Millions) Incurred by Federal Government by Program and Year
--------------------------------------------------------------------------------------------------------------------------------------------------------
                          Year                                 2020            2021            2022            2023            2024            Total
--------------------------------------------------------------------------------------------------------------------------------------------------------
For Commercial Programs.................................             0.0             0.0             0.0             0.0             0.0             0.0
For Medicaid/CHIP programs (58.44%, average State Agency            28.4             5.6             5.6             5.6             5.6            51.0
 medical assistance match rate).........................
For Medicare/Advantage Programs (The bid increase in                23.0             4.6             4.6             4.6             4.6            41.2
 spending due to this proposed rule reduces the
 difference between the benchmark and the bid. The Trust
 Fund incurs 34% of this reduction while plans incur 66%
 of this reduction in the form of smaller rebates than
 would have been received had the cost of this provision
 not been included in the bid)..........................
--------------------------------------------------------------------------------------------------------------------------------------------------------

    By taking the difference between the respective cells in Tables 4 
and 5 we obtain the remaining costs for the API. To this amount must be 
added the coordination cost for the dual eligibles (row 2 of Table 3). 
For example, Medicaid/CHIP has a remaining cost of $20.3 million ($48.6 
million total cost for 2020 (Table 4)-$28.4 million matched by Medicaid 
State Agencies (Table 5) + $0.7 million total cost for coordination of 
dual eligibles (Table 3) * 17.66 percent (proportion of total costs 
incurred by Medicaid/CHIP (Table 4)). (There are minor differences due 
to

[[Page 7664]]

rounding). The results are summarized in Table 6.

                                           Table 6--Remaining Costs (in Millions) for API by Year and Program
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                                               2020            2021            2022            2023            2024            Total
--------------------------------------------------------------------------------------------------------------------------------------------------------
Commercial..............................................           159.6            32.9            32.9            32.3            31.6           289.2
Medicaid/Chip...........................................            20.3             4.4             4.4             4.2             4.0            37.4
Medicare Advantage......................................            44.8             9.4             9.4             9.1             8.8            81.5
--------------------------------------------------------------------------------------------------------------------------------------------------------

    The further discussion of bearing these costs, is clarified, if we 
reformulate the costs in terms of costs per enrollee. To do this we use 
enrollments by program. For commercial enrollment we use the 2016 MLR 
data, for MA enrollment we use the August 2018 data, and for Medicaid 
and CHIP we use September 2018 data. These enrollment numbers are 76, 
66,\67\ 20,\68\ and 7\4\ million enrollees in the commercial, Medicaid, 
MA and separate CHIP programs respectively. Thus, for purposes of this 
analysis, we use a total of 169 million (76+67+20+6) enrollees in all 
programs. Table 7 presents cost per enrollee by program and year. For 
example, there is a 28-cent cost to Medicaid/CHIP state agencies in 
2020 (20.3 million remaining cost (Table 6) divided by 73 million (66 
million Medicaid + 7 million CHIP)).\69\
---------------------------------------------------------------------------

    \67\ https://www.medicaid.gov/medicaid/program-information/medicaid-and-chip-enrollment-data/report-highlights/.
    \68\ 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.
    \69\ To give an idea of how the per enrollee per year numbers 
would change had we used updated enrollment, we note that the latest 
MA enrollment (as of January 2019) is for January 2019 and is 22 
million, the latest Medicaid enrollment is for Oct 2018 and is still 
73 million, and the latest commercial enrollment is for 2017 and is 
73.5. The resulting per-enrollee-per-year cost impacts would be 
$2.17, 0.28, and $2.04 versus the numbers in Table 7 which are 
$2.10, 0.28, and $2.24. These changes per enrollee per year would 
not affect any of our conclusions about negligibility relative to 
the 4 and 5 digit per enrollee per year expenses for Medicare, 
Medicaid and the Federally Funded exchange.

                                           Table 7--Cost per Enrollee per Year (Dollars and Cents) by Program
--------------------------------------------------------------------------------------------------------------------------------------------------------
                                              Current
                                            enrollment
                                           (millions) by       2020            2021            2022            2023            2024            Total
                                              program
--------------------------------------------------------------------------------------------------------------------------------------------------------
Commercial..............................              76            2.10            0.43            0.43            0.42            0.42            3.81
Medicaid/Chip...........................              73            0.28            0.06            0.06            0.06            0.05            0.51
Medicare Advantage......................              20            2.24            0.47            0.47            0.46            0.44            4.08
--------------------------------------------------------------------------------------------------------------------------------------------------------

    Using Table 7 we can assess the approximate impact of the remaining 
cost.
    Commercial: As pointed out above, the Commercial program has the 
options of absorbing costs or passing costs to enrollees either in the 
form of premiums or reduced benefits. The cost per enrollee in 2021 
through 2024 is under a half dollar and could comfortably be passed on 
to enrollees. For purposes of market competitiveness, it is very likely 
that some of the 2020 cost of $2.10 per enrollee will be absorbed by 
each QHP in an FFE.
    Medicaid: Medicaid state agencies are adding a cost under 30 cents 
per enrollee for 2020-2024. Since total costs per enrollee for the 
Medicaid program are several thousand dollars we do not believe this 
additional 30 cents per enrollee cost to be a significant burden.
    Medicare Advantage: Medicare Advantage plans in their June-
submitted bids would address the reduced rebates (arising from 
increased bid costs due to the increased costs of this proposed 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 choose 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 7).
    Table 8 summarizes these methods of bearing the remaining costs.

           Table 8--How Programs Would Defray Remaining Costs
------------------------------------------------------------------------
 
------------------------------------------------------------------------
Commercial........................  Commercial plans have the options of
                                     absorbing costs (for example, in
                                     2020 for reasons of market
                                     competitiveness), increasing
                                     premiums to enrollees, or reducing
                                     benefits.
Medicaid/CHIP.....................  Medicaid Managed Care plan would
                                     bear the cost (under a dime per
                                     enrollee) which is negligible
                                     compared to current costs per
                                     enrollee.
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 proposed 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 8).
------------------------------------------------------------------------


[[Page 7665]]

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.
    This proposed rule affects (1) Commercial Issuers (2) MA plans, 
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 $38.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 the commercial, MA, or Medicaid/
CHIP programs. We have no way of directly assessing the size of Parent 
Organizations. Therefore, as a proxy, we analyze each program 
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 MAOs 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; 
and
    (3) A Part D bid consistent with Part D regulations in 42 CFR part 
423.

These bids project payments to hospitals, providers and staff, as well 
as the cost of administration and profits. Because the API requirements 
proposed 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 MAOs who reimburse providers and 
other stakeholders for their services. A second component of the Trust 
Fund payment to MAOs 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 are 
approximately 66 percent). Benchmarks are based on a formula using an 
estimate of the Medicare FFE per capita cost for the geographic area, 
which are adjusted to reflect the per capita cost of each county in the 
United States and its territories. Payments from the Medicare Trust 
Funds for monthly capitation are capped at the benchmark; for basic 
benefit bids under the benchmark, a portion, currently 66 percent, of 
the difference between the bid and benchmark is made available to the 
MA organization to either: (1) Pay the premium for supplemental 
benefits; (2) include reductions in cost sharing; (3) provide 
additional non-Medicare covered benefits; or (4) 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.
    MAOs are made aware of the benchmark through the annual CMS 
publication, ``Medicare Advantage Capitation Rates and Medicare 
Advantage and Part D Payment Policies and Final Call Letter,'' which, 
consistent with section 1853 of the Act, is released prior to MAO 
submission of bids. Therefore, the bids of most MAOs are below the 
benchmark and consequently most MAOs receive from the Trust Fund a 
total expenditure equaling payment for the bid plus the rebate.
    Because of these proposed API provisions, MAOs would be raising the 
June-submitted bid amount to reflect additional costs. While the Trust 
Fund pays these bid amounts in full, the rebate goes down: 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 MAO. The MAO has several options of dealing with these 
increased bid costs and reduced rebates: The MAO 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 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'' 
the intent being that the ``effect'' of reduced rebates is less 
additional benefits or higher enrollee premiums than would have 
happened had the cost of the provisions of this proposed rule not been 
included in the bid.
    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) organizations. This proposed rule affects MA HMOs, 
MA POS plans, and MA PPOs but does not affect Cost Plans, Prescription 
Drug Plans nor PACE organizations.
    There are a variety of ways to assess whether MAOs meet the $38.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, 32 
percent of the MAOs fell below the $38.5 million threshold for small 
businesses. Additionally, an analysis of 2016 data, the most recent 
year for which we have actual data on MAO net worth, shows that 33 
percent of all MAOs fall below the minimum threshold for small 
businesses.
    Medicaid: We next assess the impact on Medicaid MCOs. The Society 
of Actuaries (SOA) published ``Medicaid Managed Care Organizations: 
Considerations in Calculating Margin in Rate Setting'' in 2017.\70\ The 
report provided an MS Excel spreadsheet of Medicaid MCOs using data 
from 2013-2015. That report noted that ``[n]ot every state requires 
Medicaid MCOs to submit Annual Statements, so not every MCO is 
represented. MCOs in California and Arizona are shown with a limited 
set of metrics, based on what was available and provided by HMA [Health 
Management Associates].'' Of the 231 MCOs listed in the 2015 worksheet, 
196 provided data that are adequate to identify MCOs with annual 
``revenue'' less than $38.5 million. (NOTE: Since total revenue is 
reported at the company level, which includes revenue from non-Medicaid 
sources, we used ``direct premium written'' in the Medicaid portion of 
the worksheet as a proxy for annual revenue on the individual plan 
level.) Of the 196 Medicaid MCOs, only

[[Page 7666]]

15 MCOs or 7.7 percent had ``revenue'' less than $38.5 million in 2015.
---------------------------------------------------------------------------

    \70\ Society of Actuaries, Medicaid Managed Care Organizations: 
Considerations in Calculating Margin in Rate Setting. Accessed at 
https://www.soa.org/research-reports/2017/medicaid-margins/, pg. 49.
---------------------------------------------------------------------------

    Commercial: Based on the 2016 CMS MLR data, approximately 85 out of 
494, or 17 percent of companies (that either had only commercial 
business, or had commercial plus Medicare and/or Medicaid business) had 
total premium revenue of less than $38,500,000. In other words, for MA, 
Medicaid, and Commercial, 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 proposed rule has a substantial impact on a substantial number 
of small entities, the proposed 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 3 
of this section which shows that the total raw (not discounted) net 
effect of this final rule over 5 years is 500 million dollars.
    Medicare Advantage: We first assess impact on MA plans. Comparing 
the 500 million dollar 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 proposed 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.\71\ Hence, the total cost of this proposed rule 
over 5 years, $500 million, is significantly below the 3 percent-5 
percent threshold for significant impact to Medicaid Managed Care 
plans.
---------------------------------------------------------------------------

    \71\ Table 17 of Appendix D, ``Capitation Payments and 
Premiums'', in the CMS report, ``2016 Actuarial Report on the 
Financial Outlook for Medicaid,'' accessible at URL https://www.medicaid.gov/medicaid/finance/downloads/medicaid-actuarial-report-2016.pdf.
---------------------------------------------------------------------------

    Commercial: As discussed prior to Table 4, based on data in the 
public, CMS MLR files, commercial plans had a revenue of at least $370 
billion in 2016. We say at least, because this only includes 
organizations with either: (1) Only commercial; (2) both commercial and 
MA; or (3) both commercial and Medicaid. Had all organizations been 
included in the CMS MLR files (including those that only offer MA and/
or Medicaid) the amount would be greater than $370 billion. Therefore, 
the aggregate raw cost of this proposed rule over 5 years, $500 
million, is significantly below the 3 percent-5 percent threshold for 
significant impact to Commercial plans.
    We conclude, that although a significant number of small plans in 
all programs are affected by this rule, this impact is not significant.
    Besides the fact that the impact is not significant, we are not 
concerned that small plans will have a burden in implementing these 
requirements since as indicated above, without considering any rebates 
or Federal matching funds, the cost of this provision is $1.63 per 
enrollee per year in the first implementation year, and $0.34 in the 
following years for maintenance, these per enrollee costs are 
negligible when compared to the typical costs per enrollee (several 
thousand dollars).
    Consequently, the Secretary has determined that this proposed 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 program and 
plan in Tables 4 through 8 and section XVI.H. of this proposed 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 603 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 
proposed 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 require spending in any 1 year of $100 million in 1995 
dollars, updated annually for inflation. In 2018, that is approximately 
$150 million. The apportionment of total cost between the MA, Medicaid, 
Commercial and Chip programs is detailed in both section XVI.B. (Tables 
4 through 8) and section XVI.H of this RIA showing that costs for both 
enrollees and the states are small. 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 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 proposed 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 proposed rule. For each plan and 
state 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 proposing new 
requirements in section III. of this proposed 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, excluding SADP issuers, that offer plans 
through the FFE at 45 CFR 156.221 to implement open APIs for making 
certain data available to enrollees and the public. These openly 
published APIs will permit third-party applications to retrieve 
standardized data for adjudicated claims, encounters with capitated and 
subcapitated providers, provider remittances, beneficiary cost-sharing, 
reports of lab test results, provider directories, and preferred drug 
lists. We believe that these proposals are designed to empower patients 
by mandating that entities subject to our API proposal take steps--by 
implementing the API--to enable

[[Page 7667]]

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 
support moving our healthcare 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 
provider visits, and facilitating identification of fraud, waste, and 
abuse.
    To estimate the number of impacted issuers, we reviewed parent 
organizations of health plans across MA, Medicaid MCOs, and QHPs in 
FFEs to remove organizations that would not be subject to our proposal, 
such as 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 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 the Commercial market. To this we add the one 
state that operates its CHIP and Medicaid separately. Thus, we have a 
total of 345 parent entities (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 
entity for CHIP is reasonable and plausible.
    As noted in section XIII.C.3. of this proposed rule, to implement 
the new requirements for APIs, we estimate that organizations and 
states would conduct three major work phases: Initial design; 
development and testing; and long-term support and maintenance. (For a 
detailed description of these phases, see section XIII.C.3. of this 
proposed 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/. 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. Regarding Blue Button access, results were 
either negative or unclear.
    We also cross-referenced health plan organizations offering MA 
plans with health plan organizations that offer plans in the Federal 
Employee Health Benefit (FEHB) program because a percentage of those 
organizations offer plans with patient portal access and Blue Button 
functionality. The FEHB, 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 the Collection of Information section of this 
proposed rule and summarized in Table 3, 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 $798,356 
per implementation or an aggregate cost of $275,432,820 ($798,356 x 345 
parent entities). For a detailed discussion of the one-time costs 
associated with implementing the API requirements we refer readers to 
section XIII.C.3. of this proposed 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 and 
vetting of third party applications. We estimate the burden related to 
the requirements for APIs to have an annual cost of $158,406 per 
implementation or an aggregate cost of $54,650,070 (345 parent entities 
x $158,406). For a detailed discussion of the annual costs associated 
with implementing the API requirements, we refer readers to section 
XIII.C.3. of this proposed 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 healthcare data 
through pdf and text format is vital,

[[Page 7668]]

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 healthcare data will ultimately 
empower them to make informed decisions about their healthcare. Our 
proposals 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 \72\ 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,\73\ 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. Recently, the Administration launched the MyHealthEData 
initiative.\74\ This government-wide initiative aims to empower 
patients by ensuring that they have full access to their own healthcare 
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 healthcare 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.
---------------------------------------------------------------------------

    \72\ May 2018, EHR Incentive Program, Payment Summary Report, 
accessed at https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/May2018_SummaryReport.pdf.
    \73\ ONC, Health IT Dashboard, ``Office-based Physician Health 
IT Adoption: State rates of physician EHR adoption, health 
information exchange & interoperability, and patient engagement 
(2015),'' https://dashboard.healthit.gov/apps/physician-health-it-adoption.php (last accessed July 9, 2018).
    \74\ https://www.cms.gov/Newsroom/MediaReleaseDatabase/Press-releases/2018-Press-releases-items/2018-03-06.html.
---------------------------------------------------------------------------

    Health plans should have the ability to exchange data instantly 
with other payers for care coordination or transitions, and with 
providers to facilitate more efficient care. Health plans 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 an open 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 Fast Healthcare Interoperability Resources 
(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. Currently, 31 states 
and the District of Columbia now submit buy-in data to CMS, daily and 
28 states and the District of Columbia receive buy-in response files 
from CMS daily.
    We are proposing to establish 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. We propose that 
states would be required to begin participating in daily exchange of 
buy-in data with CMS by April 1, 2022.
    We estimate the cost for states to comply with these new 
requirements to be one-time costs associated with state systems 
updates, totaling $3,273,965 across impacted states and over the 3-year 
implementation period. We first identified those states already 
exchanging data daily, and then determined there are 19 states that we 
anticipate will need to make a systems change to send buy-in data to 
CMS daily, and 22 states that we anticipate will need to make a systems 
change to receive buy-in data from CMS daily. We then estimated that 
each change would involve 960 hours of computer analyst time at $83.18 
per hour, for a one-time cost to be a little less than $80,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 under $160,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 effective 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.
    States submit data on MMA 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 cost-sharing). While 42 CFR 
423.910(d) requires states to submit at least one MMA file each month, 
states have the option to submit multiple MMA files throughout the 
month (up to one per day). 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.
    We are proposing 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 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 estimate the cost for 
states to comply with these new requirements to be a one-time cost 
associated with state systems updates, totaling $3,034,406 across 
impacted states, and across the 3 years which states have to implement 
the requirement. There are 37 states and the District of Columbia that 
we anticipate will need to make a systems change to send MMA data to 
CMS daily. We estimate the one-time cost for a state to be a little 
less than $80,000 for this MMA data systems change. For a detailed 
discussion of the costs associated with these requirements we refer 
readers to section XIII.C. of this proposed rule. We did not estimate 
any savings related to submitting MMA files daily, as data lags only 
delay when data are sent; delays do not impact the

[[Page 7669]]

effective date and total costs. While we did not estimate savings, we 
anticipate that states may experience longer term reduction in 
administrative burden.
    If these proposals are finalized as proposed, we anticipate that 
states would have approximately 3 years to implement daily exchange of 
buy-in and MMA data. For each state there would be a one-time cost to 
make needed systems changes, and thereafter, no new on-going costs. 
States will have the ability to choose, in consultation with CMS, when 
in the 3-year 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 an even distribution 
beginning in May 2019 and ending in April 2022. The total cost impact 
over the 3-year implementation period for this provision is $6,308,371 
($3,273,965 + $3,034,406), comprising $0.7 million in FY 2019, $2.2 
million in FY 2020, $2.2 million in FY 2021, and $1.2 million in FY 
2022. Since the proposed effective date is April 1, 2022, we estimate 
no costs for FY 2023.
3. Revisions to the Conditions of Participation for Hospitals and 
Critical Access Hospitals (CAHs)
    We are seeking to further expand CMS requirements for 
interoperability within the hospital and CAH CoPs by focusing on 
electronic patient event notifications. We are proposing new 
requirements in section X. of this proposed 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. Specifically, for hospitals, psychiatric 
hospitals and CAHs, we are proposing similar requirements to revise the 
CoPs for Medicare- and Medicaid-participating hospitals, psychiatric 
hospitals, and CAHs by adding a new standard, ``Electronic 
Notifications,'' that would require hospitals, psychiatric hospitals, 
and CAHs to make electronic patient event notifications available to 
another healthcare facility or to another community provider. We 
propose to limit this requirement to only those hospitals, psychiatric 
hospitals, and CAHs which currently possess EHR systems with the 
technical capacity to generate information for electronic patient event 
notifications, recognizing that not all Medicare- and Medicaid-
participating hospitals have been eligible for past programs promoting 
adoption of EHR systems. We propose that these notifications would need 
to be sent at admission and either immediately prior to or at the time 
of the patient's 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) for whom the hospital, psychiatric hospital, or CAH 
has a reasonable certainty of receipt of notifications. 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.\75\
---------------------------------------------------------------------------

    \75\ Unruh MA, Jung HY, Kaushal R, Vest JR, Hospitalization 
event notifications and reductions in readmissions of Medicare FFS 
beneficiaries in the Bronx, New York. J AM Med Inform Assoc, 2017 
Apr 1, accessed at https://www.ncbi.nlm.nih.gov/pubmed/28395059.
---------------------------------------------------------------------------

    These notifications are automated, electronic communications from 
the provider to another facility or another community provider 
identified by the patient. These automated communications alert the 
receiving provider 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. However, regardless of the 
information included these alerts can help ensure that a receiving 
provider is aware that the patient has received care elsewhere. The 
notification triggers a receiving provider 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.
    Virtually all EHR systems generate the basic messages commonly used 
to support electronic patient event notifications. 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 this proposed change because EHR implementation 
across care settings varies in maturity rates, leading to potential 
variance in cost and impact across such settings. We believe that this 
proposal would impose minimal additional costs on hospitals. The cost 
of implementing these proposed changes would largely be limited to the 
one-time cost related initial implementation of the notification 
system, and to the revision of a policies and procedures as they relate 
to discharge planning. There also may be some minimal cost associated 
with communicating these changes to affected staff. However, we believe 
that these costs would be offset by the benefits derived from positive 
outcomes in health care quality and public health outcomes. Therefore, 
while this proposal would impose a minimal burden on hospitals, we 
believe that, in sum, the changes proposed would greatly benefit 
patients overall.
4. Effects of Other Proposed Policy Changes
    In addition to those proposed policy changes discussed previously 
that we are able to model, we are proposing to make various other 
changes in this proposed rule. Generally, we have limited or no 
specific data available with which to estimate the impacts of these 
proposed changes. Our estimates of the likely impacts associated with 
these other proposed changes are discussed in this section.
a. Care Coordination Across Payers
    In section V. of this proposed rule, we are proposing a new 
requirement for MA plans, Medicaid managed care plans, CHIP managed 
care entities, and QHP issuers in FFEs to require these plans to 
maintain a process to exchange, at a minimum, the USCDI data set upon 
an enrollee's request. Under our proposal, each of these plans subject 
to the requirement would, upon an enrollee's request: (1) Accept the 
data set from another plan 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 plan that 
currently covers the enrollee; and (3) send the data set at any time 
during enrollment or up to 5 years after

[[Page 7670]]

enrollment has ended to a recipient identified by the enrollee.
    Such transactions would be made in compliance with applicable laws.
    We believe that sending and receiving this minimum data would 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.
    We believe that this proposal would impose minimal additional costs 
on plans. We note that we do not specify a transport standard in the 
proposal and anticipate that plans may opt to use APIs, such as the API 
that this proposed rule would also require. 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 proposed 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 this proposed rule, we are proposing to require 
MA plans, Medicaid managed care plans, CHIP managed care entities and 
QHP issuers in FFEs to participate in trust networks in order to 
improve interoperability in these programs. We believe that 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. A trusted exchange framework allows for 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. Widespread payer participation in such a framework might also 
allow for more complete access, exchange, and use of all electronically 
accessible health information for authorized use under applicable state 
or federal law. Under our proposal, participation would be required in 
a trusted exchange framework that meets the following criteria:
     The trusted exchange network must be able to exchange PHI, 
defined in 45 CFR 160.103, in compliance with all applicable state and 
federal laws across jurisdictions.
     The trusted exchange network must connect both inpatient 
EHRs and ambulatory EHRs.
     The trusted exchange network must support secure messaging 
or electronic querying by and between patients, providers and payers.
    We believe that this proposal would impose minimal additional costs 
on plans.

D. Alternatives Considered

    This proposed rule contains a range of proposed and potential 
future policies. It provides descriptions of the statutory provisions 
that are addressed, identifies the proposed policies, and presents 
rationales for our decisions and, where relevant, alternatives that 
were considered. We carefully considered the alternatives to this 
proposed rule but concluded that none would adequately and immediately 
begin to address the critical issue of the lack of patient access and 
interoperability, or exchange of health care data within the health 
care system.
    The critical policy decision was how broadly or narrowly to 
classify the standards required to implement interoperability. Overly 
prescriptive standards may stifle innovation and, in turn, increase 
costs. On the other side, broad language surrounding standards risked 
leaving too much open to interpretation and continuing the uncertainty 
about which standards would be the most practical and cost-effective to 
implement. We determined it was most appropriate to propose a technical 
and standards framework that strikes a balance between these two ends 
of the spectrum, and to establish that we expect the standards 
framework to expand and mature as interoperability increases.
    A second decision was how broadly or narrowly to apply the proposed 
policies and requirements. For example, alternatives to requiring 
health plans to provide claims data to patients via an open API could 
have been altered in a number of ways, such as requiring more or less 
information to be provided to patients or, simultaneously, to require 
additional information beyond that already accessible through existing 
APIs be provided to patients by providers. Ultimately, we opted to 
continue to consider most matters pertaining to providers in separate 
RFIs, such as that in the FY 2019 IPPS proposed rule seeking 
information about program participation conditions and requirements, 
and to maintain the policies proposed in this rule as policies that 
will further enhance and secure the foundation of future 
interoperability, including through inclusion of payers, through care 
coordination, and through matters of security and identity 
confirmation.
    As we recognize that advancing interoperability is no small or 
simple matter, we continue to explore alternatives and potential other 
policies. We have 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 herein, should be imposed to promote interoperability. For 
example, the Innovation Center is seeking comment on general principles 
around promoting interoperability within Innovation Center models for 
integration into new models as part of the design and testing of 
innovative payment and service delivery models. Additionally, we are 
seeking comment on how we may leverage our program authority to provide 
support to those working on improving patient matching. For example, we 
are requesting comment on whether CMS should require, in Medicare FFS, 
the MA program, Medicaid FFS, CHIP FFS, Medicaid managed care programs, 
CHIP managed care entities, and the FFEs, use of a particular patient 
matching software solution with a proven success rate of a certain 
percentage validated by HHS or a 3rd party. We also continue to 
consider feedback received from RFIs issued in various rules over the 
course of the past year and to incorporate those suggestions into our 
strategy.

E. Accounting Statement and Table

    In accordance with OMB Circular A- 4, Table 9 depicts an accounting 
statement summarizing the assessment of the benefits, costs, and 
transfers associated with this regulatory action.

[[Page 7671]]



                                          Table 9--Accounting Statement
----------------------------------------------------------------------------------------------------------------
                                                                                       Units
                                                      Primary    -----------------------------------------------
                    Category                         estimate                      Discount rate
                                                                   Year dollars         (%)       Period covered
----------------------------------------------------------------------------------------------------------------
Benefits:
----------------------------------------------------------------------------------------------------------------
    Qualitative.................................   API requirements will alleviative the burden for
                                                  beneficiaries and enrollees 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.
                                                   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 healthcare
                                                  information ecosystem that allows and encourages the
                                                  healthcare market to tailor products and services to compete
                                                  for patients, thereby increasing quality, decreasing costs,
                                                  and helping them live better, healthier lives.
----------------------------------------------------------------------------------------------------------------
Costs:
----------------------------------------------------------------------------------------------------------------
    Annualized Monetized $ millions/year........          106.26            2020               7       2020-2024
                                                          102.73            2020               3       2020-2024
----------------------------------------------------------------------------------------------------------------

    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), mitigating the amount 
transferred to enrollees. One approach to estimate impact on enrollees 
was made in section XVI.B. of this RIA. However, this analysis did not 
take into account transfers.
    We now re-estimate the potential full transfer. As noted in section 
Tables 4 through 8 of XVI.B. of this RIA, we have in 2021 through 2024 
under a dollar increase in premium 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 2024 with the initial 1-year cost 
amortized over 5 years. In other words, we assume a cost of $110 
(275.4/5 + 54.7)
    We point out that this premium increase should be counterbalanced 
by projected savings arising from the provisions in this proposed rule. 
More specifically, we expect the availability of portable electronic 
transfer of medical data proposed by this rule to increase prevention 
of future medical illnesses 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.
    We present two estimates. First, we estimate using the enrollment 
figures used in Table 7 of this RIA. Table 7 shows that we have 169 
million (76+73+20) in programs that will be spending about $110 million 
per year. Ignoring Federal subsidies, and assuming that all costs will 
be passed on to enrollees (which is contrary to our experience), the 
169 million enrollees would each incur an extra 65 cents (110/169) a 
year to achieve the $110 million goal. We next estimate using premium 
versus enrollment as was done in section XVI.B. of this RIA.
    Prior to discussing potential transfers to enrollees, we discuss 
how this proposed rule may affect commercial enrollees not in the MA, 
Medicaid, CHIP, or FFE programs. Technically, plans are only required 
to provide interoperability for enrollees in the MA, Medicaid, CHIP, 
and FFE programs. However, it is both possible and likely, that a 
Parent Organization providing interoperability for its FFE and other 
program enrollees as required, may choose to offer this to commercial 
enrollees. Consequently, it is possible that to cover the cost of 
offering interoperability to commercial enrollees outside the MA, 
Medicaid, CHIP and FFE programs, the Parent Organizations, raise 
premiums to both their commercial enrollees as well as the MA, 
Medicaid, CHIP or FFE enrollees. Thus it is possible (and we argue 
likely) that this proposed rule will affect commercial enrollees even 
though there is no requirement to provide them interoperability. 
Therefore, we believe we are obligated in this RIA to calculate the 
cost impact per enrollee should the Parent Organizations offer 
interoperability (and should they pass on the cost of interoperability 
in terms of commercial premium). The rest of the discussion below 
explores this possibility.\76\
---------------------------------------------------------------------------

    \76\ Note that our analysis in Tables 5,6,7,8 also assume that 
costs are incurred by commercial enrollees even though there is no 
requirement to provide them with interoperability. We believe this 
the most likely scenario. However, if we are restrictive in our 
impact analysis and only assume MA, Medicaid, CHIP and FFE enrollees 
are bearing the cost the results of Tables 5-8 would not change the 
negligibility conclusion as the following justifications show: We 
have assumed 20 million, 73 million and 76 million enrollees in the 
MA, Medicaid and Commercial programs (Table 7). The 20 million and 
73 million remain accurate. The 76 million (commercial enrollees) 
must be replaced by FFE enrollees. For this purpose we use QHP data. 
Based on internal data (some of which has not yet been published), 
for 2017 there were 9,757,747 enrollees with $55,109,210,072 total 
premium resulting in a $5600 per enrollee per year cost, and for 
2018, there were 9,925,382 enrollees with $70,738,585,845 total 
premium resulting in a $7100 per enrollee per year cost. To 
illustrate how this changes the Table 7 impact, the $2.10 per 
enrollee per year cost for 2020 commercial must be replaced by 
$15.96 to account for a division by 10 million versus 76 million. 
Although this is a big increase, $15.96 is still only about one 
third a percent of the per-enrollee-per-year costs of the FFE. Thus 
the cost is still negligible. Furthermore, a Parent Organization 
actuary reviewing these numbers would probably seriously recommend 
that all enrollees including commercial be offered the 
interoperability since that significantly reduces the per enrollee 
per year cost.
---------------------------------------------------------------------------

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

[[Page 7672]]

commercial market MLR is generally calculated as the percent of each 
dollar of after-tax premium revenue spent by the issuer on medical 
products and services, and activities that improve the quality of 
health care. If the issuer MLR for a state market is below the 
applicable threshold, then the issuer must return the difference to 
policyholders. It follows, that if interoperability costs 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 85 percent (in practice it can vary by 
state market), but the issuer's MLR is below the threshold at 75 
percent. Then the issuer would have to return the 10 percent as a 
rebate. If the interoperability costs 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 81 percent rather than 75 percent). 
Similarly, if both the applicable threshold and issuer MLR are 85 
percent, then the issuer would not owe a rebate.
    There are two effects of recognizing these costs as QIA: (1) For 
issuers below the applicable MLR threshold, the rebate from issuers to 
policyholders would go down by some amount between $0 and the 
interoperability cost; and (2) for issuers at or above the MLR 
standards, the premium transfers from enrollees to issuers will go up 
by some amount between $0 and the interoperability cost.
    To estimate these amounts, we used the public use 2016 MLR files on 
the CMS website that were used for Tables 4 through 7 of this RIA. The 
total 2016 premium revenue on the commercial side was approximately 
$370 billion. Of the $370 billion, the total 2016 premium revenue of 
issuers that were below the commercial MLR standard (80 or 85 percent, 
depending on the market) was approximately $19.4 billion and that 
subset of issuers paid a total of $455 million in rebates.
    As mentioned earlier, to proceed further we use the estimates of 
the interoperability costs which are $110 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: 
MA (including Part D sponsors); Medicaid; CHIP; and Commercial. Thus, 
of the $110 million level annual cost of interoperability, we estimate 
$64 million (57.81 percent commercial proportion x $110 million level 
annual interoperability cost) to be the cost for the commercial market.
    In estimating the transfers to policyholders in the commercial 
market, we must distinguish between the $19.4 billion of premium 
revenues of issuers whose MLR was below the applicable threshold and 
the $350.6 billion of premium revenues ($370 billion total revenue-
$19.4 billion) of issuers whose MLR was at or above the applicable 
threshold. We can now calculate the estimated aggregate transfer in the 
commercial market from the policyholders to the issuers whether through 
premium or rebates as follows:
     Interoperability cost = 0.017 percent of revenue premium 
($64 million cost/$370 billion total revenue).
     Reduced MLR rebates = $3.3 million (0.017 percent x $19.4 
billion premium from issuers below the applicable MLR threshold).
     Increased premiums = Up to $60.0 million (0.017 percent x 
($370 billion total revenue-$19.4 billion premium from issuers below 
the applicable MLR threshold)).
     Total transfer from enrollees = Up to $63.3 million ($60.0 
million increased premium + $3.3 million reduced rebate).
     Transfer per enrollee = 83 cents ($63.3 million/76 million 
commercial enrollee).
    We note that the 83 cents (under a dollar per enrollee) is 
consistent with the results obtained in Tables 4 through 8 (with exact 
raw amounts by year without amortization of a large first year 
expense). These calculations are summarized in Table 10.
    These calculations are summarized in Table 10.

                        Table 10--Transfers to Enrollee Resulting From the Proposed Rule
----------------------------------------------------------------------------------------------------------------
 
----------------------------------------------------------------------------------------------------------------
                                      Level Annual Cost of Interoperability
----------------------------------------------------------------------------------------------------------------
(A)...................  First year cost of                275.4  Estimated in this        In millions.
                         interoperability.                        proposed rule.
(B)...................  First year cost                   55.08  (A)/5..................  In millions.
                         amortized over 5 years.
(C)...................  Continuation year cost             54.7  Estimated in this        In millions.
                         of interoperability.                     proposed rule.
(D)...................  Level interoperability           109.78  (B) + (C)..............  In millions.
                         cost per year.
----------------------------------------------------------------------------------------------------------------
                                     Commercial Percent of Premium Revenues
----------------------------------------------------------------------------------------------------------------
(E)...................  Total premium revenues              640  Sum of (F) (G) and (H)   In billions.
                         in commercial,                           Below.
                         Medicaid and Medicare.
(F)...................  Commercial Premium                  370  58%....................  2016 CMS MLR files (in
                         revenues (dollar                                                  billions); Percentage
                         amount and percent).                                              obtained by dividing
                                                                                           by column E.
(G)...................  Medicare Advantage                  157  25%....................  2016 CMS MLR files (in
                         Premium revenues                                                  billions); Percentage
                         (Dollar amount and                                                obtained by dividing
                         percent).                                                         by column E.
(H)...................  Medicaid Premium                    113  18%....................  2016 CMS MLR files (in
                         revenues (Dollar                                                  billions); Percentage
                         amount and percent).                                              obtained by dividing
                                                                                           by column E.
----------------------------------------------------------------------------------------------------------------
                    Annual Interoperability Cost as a Percent of Commercial Premium Revenues
----------------------------------------------------------------------------------------------------------------
(I)...................  Annualized Level                 109.78  (D)....................  In millions.
                         interoperability cost.
(J)...................  Percent of total                    58%  (F)....................  ......................
                         revenues related to
                         commercial market.
(K)...................  Interoperability cost             63.67  (I) x (J)..............  In millions.
                         for commercial issuers.
(L)...................  Commercial Premium              370,000  (F)....................  In millions.
                         revenues.

[[Page 7673]]

 
(M)...................  Interoperability cost            0.017%  (K)/(L)................  ......................
                         as a percent of total
                         commercial revenue.
----------------------------------------------------------------------------------------------------------------
            Commercial Revenue Broken Out by Whether Above or Below MLR Threshold (Requiring Rebate)
----------------------------------------------------------------------------------------------------------------
(N)...................  Total Commercial                370,000  (F)....................  In millions.
                         Revenue.
(O)...................  Revenues of commercial           19,400  2016 CMS MLR files (in   ......................
                         market issuers whose                     millions).
                         MLR is below threshold.
(P)...................  Revenues of commercial          350,600  (N)-(O)................  In millions.
                         market issuers whose
                         MLR is at or above the
                         threshold.
----------------------------------------------------------------------------------------------------------------
                 Transfer To Enrollee per Enrollee From Decreased Rebates and Increased Premium
----------------------------------------------------------------------------------------------------------------
(Q)...................  Reduction in commercial             3.3  (M) x (O)..............  In millions.
                         market rebates from
                         interoperability for
                         those issuers paying
                         rebates.
(R)...................  Premium increase from              60.0  (M) x (P)..............  In millions.
                         interoperability for
                         those commercial
                         market issuers not
                         paying rebates.
(S)...................  Total increase to                  63.3  (Q) + (R)..............  In millions.
                         commercial enrollees
                         from interoperability.
(T)...................  Number Commercial                    76  2016 CMS MLR files (in   ......................
                         Enrollees.                               millions).
(U)...................  Dollar increase in                $0.83  (S)/(T)................  ......................
                         premium per enrollee.
----------------------------------------------------------------------------------------------------------------

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 proposed rule is 
considered an E.O. 13771 regulatory action. We estimate that this rule 
generates $56.7 million in annualized costs, discounted at 7 percent 
relative to year 2016, over an infinite time horizon. Details on the 
estimated costs of this proposed 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.

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) proposes to amend 42 CFR chapter IV and the 
Office of the Secretary (HHS) proposes to further amend 45 CFR subtitle 
A, subchapter B (as proposed to be amended in ONC's proposed rule 
``21st Century Cures Act: Interoperability, Information Blocking, and 
the ONC Health IT Certification Program'' published elsewhere in this 
issue of this Federal Register), 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

[[Page 7674]]

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 is revised to read as follows:

    Authority:  42 U.S.C 1395w26 and 1395w-27.

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 an 
open Application Programming Interface (API) that permits third-party 
applications to retrieve, with the approval and at the direction of an 
individual MA enrollee, 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 enrollees through the API 
described in paragraph (a) of this section:
    (i) Standardized 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) Standardized encounter data, no later than one (1) business 
day after data concerning the encounter is received by the MA 
organization;
    (iii) Provider directory data on the MA organization's network of 
contracted providers, including names, addresses, phone numbers, and 
specialties, updated no later than 30 business days after changes are 
made to the provider directory; and
    (iv) Clinical data, including laboratory results, if the MA 
organization manages 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) Standardized data concerning adjudicated claims for covered 
Part D drugs, including remittances and enrollee cost-sharing, no later 
than 1 business day after a claim is adjudicated;
    (ii) Pharmacy directory data, including the number, mix, and 
addresses of network pharmacies; and
    (iii) 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:
    (1) Must implement, maintain, and use API technology conformant 
with 45 CFR 170.215;
    (2) Must conduct routine testing and monitoring 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 minimally required to comply with HIPAA 
privacy and security requirements in 45 CFR part 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 following regulations regarding content 
and vocabulary standards for data available through the API, where 
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 the only available standards for the data type or 
element;
    (ii) Content and vocabulary standards at 45 CFR part 162 and 42 CFR 
423.160 where required by law or where such standards are the only 
available standards for the data type or element; or
    (iii) The content and vocabulary standards in either paragraph 
(c)(3) (i) or (ii) of this section as determined appropriate for the 
data type or element, where a specific data type or element may be 
encoded or formatted using content and vocabulary standards in either 
paragraph (c)(3)(i) or (ii) of this section.
    (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) Where 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:
    (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 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

[[Page 7675]]

    (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) MA organizations must maintain a 
process for the electronic exchange of, at a minimum, the data classes 
and elements included in the regulations regarding 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 enrollee. At the request of an enrollee, the MA organization 
must:
    (i) Receive such data from any other health care plan 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 such data to any other 
health care plan that currently covers the enrollee; and
    (iii) At any time the enrollee is currently enrolled in the MA plan 
and up to 5 years after disenrollment, send such data to a recipient 
designated by the enrollee.
    (2) MA organizations must participate in a trusted exchange network 
which:
    (i) Is capable of exchanging protected health information, defined 
at 45 CFR 160.103, in compliance with all applicable State and Federal 
laws across jurisdictions;
    (ii) Is capable of connecting to inpatient electronic health 
records and ambulatory electronic health records; and
    (iii) Supports secure messaging or electronic querying by and 
between providers, payers and patients.
    (g) Enrollee resources regarding privacy and security. An MA 
organization must provide on its 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, and 
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; and
    (ii) The Federal Trade Commission (FTC).
    (h) Applicability. This section is applicable beginning on and 
after January 1, 2020.
0
7. 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.  422.119.
* * * * *

PART 423--VOLUNTARY MEDICARE PRESCRIPTION DRUG BENEFIT

0
8. 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
9. 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,'', and following the 
phrase ``in a manner specified by CMS'' by adding the following phrase 
``and frequency specified in paragraph (d)(2) of this section,''; and
0
d. By adding paragraph (d)(2).
    The addition reads as follows:


Sec.  423.910  Requirements.

* * * * *
    (d) State enrollment reporting. * * *
    (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
10. The authority citation for part 431 is revised to read as follows:

    Authority: 42 U.S.C. 1302.

0
11. 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 an open Application 
Programming Interface (API) that permits third-party applications to 
retrieve, with the approval and at the direction of a beneficiary, 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 beneficiaries through the API described in paragraph 
(a) of this section:
    (1) Standardized 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) Standardized encounter data through the API within one (1) 
business day of receiving the data from providers, other than MCOs, 
PIHPs, and PAHPs, compensated on the basis of capitation payments;
    (3) Provider directory information specified in section 1902(a)(83) 
of the Act, no later than 30 calendar days after the State receives 
provider directory information or updates to provider directory 
information;
    (4) Clinical data, including laboratory results, if the State 
manages any such data, no later than one (1) business day after the 
data is received by the State; and
    (5) 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:
    (1) Must implement, maintain, and use API technology conformant 
with 45 CFR 170.215;
    (2) Must conduct routine testing and monitoring to ensure the API 
functions properly, including assessments to

[[Page 7676]]

verify that the API is fully and successfully implementing privacy and 
security features such as, but not limited to, those minimally required 
to comply with HIPAA privacy and security requirements in 45 CFR part 
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 following regulations regarding content 
and vocabulary standards for data available through the API, where 
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 the only available standards for the data type or 
element;
    (ii) Content and vocabulary standards at 45 CFR part 162 and 42 CFR 
423.160 where required by law, or where such standards are the only 
available standards for the data type or element; or
    (iii) The content and vocabulary standards in either paragraphs 
(c)(3)(i) or (ii) of this section, as determined appropriate for the 
data type or element, where a specific data type or element may be 
encoded or formatted using content and vocabulary standards in either 
paragraph (c)(3)(i) or (ii) of this section.
    (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) Where 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:
    (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 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 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 on its 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, and 
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; and
    (ii) The Federal Trade Commission (FTC).
    (g) Applicability. This section is applicable beginning on or after 
July 1, 2020.

PART 438--MANAGED CARE

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

    Authority: 42 U.S.C. 1302.

0
13. Section 438.62 is amended by adding paragraph (b)(1)(vi) 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 regulations regarding the 
content standard at 45 CFR 170.213. Information received by the MCO, 
PIHP, or PAHP must be incorporated into the MCO's, PIHP's, or PAHP's 
records about the enrollee. At the request of an enrollee, the MCO, 
PIHP, or PAHP must:
    (A) Accept such data from any other health care plan 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 such data to 
any other health care plan that currently covers the enrollee; and
    (C) At any time the enrollee is currently enrolled in the MCO, 
PIHP, or PAHP and up to 5 years after disenrollment, send such data to 
any other recipient designated by the enrollee.
* * * * *
0
14. Section 438.242 is amended by adding paragraphs (b)(5) and (6) to 
read as follows:


Sec.  438.242  Health information systems.

* * * * *
    (b) * * *
    (5) Participate in a trusted exchange network which:
    (i) Is capable of exchanging protected health information as 
defined in 45 CFR 160.103, in compliance with all applicable State and 
Federal laws from all relevant jurisdictions;
    (ii) Is capable of connecting to inpatient electronic health 
records and ambulatory electronic health records, and;
    (iii) Supports secure messaging or electronic querying by and 
between providers, payers and patients.
    (6) 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

[[Page 7677]]

    (i) Include all standardized 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; and
    (ii) Provider directory information required in Sec.  431.60(b)(3) 
of this chapter, which must include all information required in Sec.  
438.10(h)(1).
* * * * *

PART 457--ALLOTMENTS AND GRANTS TO STATES

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

    Authority: 42 U.S.C. 1302.

0
16. 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);
0
c. Revising paragraph (c).
    The addition and revision reads as follows:


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
17. 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 an open application 
programming interface (API) that permits third-party applications to 
retrieve, with the approval and at the direction of the individual 
beneficiary, 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 beneficiaries through the API described in paragraph 
(a) of this section:
    (1) Standardized 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) Standardized encounter data through the API within one (1) 
business day of receiving the data from providers, other than MCOs, 
PIHPs, or PAHPs, compensated on the basis of capitation payments;
    (3) Provider directory information, including updated provider 
information no later than 30 calendar days after the State receives 
updated provider information;
    (4) Clinical data, including laboratory results, if a State manages 
any such data, no later than one (1) business day after the data is 
received by the State; and
    (5) 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:
    (1) Must implement, maintain, and use API technology conformant 
with 45 CFR 170.215;
    (2) Must conduct routine testing and monitoring 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 minimally required to 
comply with HIPAA privacy and security requirements in 45 CFR part 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 following regulations regarding content 
and vocabulary standards for data available through the API, where 
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 the only available standards for the data type or 
element;
    (ii) Content and vocabulary standards at 45 CFR part 162 and 42 CFR 
423.160 where required by law, or where such standards are the only 
available standards for the data type or element; or
    (iii) The content and vocabulary standards in either paragraphs 
(c)(3)(i) or (ii) of this section, as determined appropriate for the 
data type or element, where a specific data type or element may be 
encoded or formatted using content and vocabulary standards in either 
paragraphs (c)(3)(i) or (ii) of this section.
    (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 45 CFR 170.215, the 
National Coordinator has approved the updated version for use in the 
ONC Health IT Certification Program; and
    (C) Where 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:
    (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:

[[Page 7678]]

    (1) Reasonably determines 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 on its 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 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, and 
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; and
    (ii) The Federal Trade Commission (FTC).
    (g) Applicability. This section is applicable beginning on or after 
July 1, 2020.
0
18. 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 (5), (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
    (i) Include all standardized 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; and
    (ii) Provider directory information required in Sec.  
457.730(b)(3), which must include all information required in Sec.  
438.10(h)(1) of this chapter.
* * * * *

PART 482--CONDITIONS OF PARTICIPATION: HOSPITALS

0
19. 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
20. Sections 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 with the capacity to generate 
information for patient event notifications in accordance with 
paragraph (d)(2) of this section, then the hospital must demonstrate 
that--
    (1) The 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) The system complies with the regulations regarding the content 
exchange standard at 45 CFR 170.205(a)(4)(i);
    (3) The system sends notifications that must include the minimum 
patient health information (which must be patient name, treating 
practitioner name, sending institution name, and, if not prohibited by 
other applicable law, patient diagnosis);
    (4) At the time of the patient's admission to the hospital, the 
system sends notifications directly or through an intermediary that 
facilitates exchange of health information, to licensed and qualified 
practitioners, other patient care team members, and post-acute care 
services providers and suppliers:
    (i) That receive the notification for treatment, care coordination, 
or quality improvement purposes;
    (ii) That have an established care relationship with the patient 
relevant to his or her care; and
    (iii) For whom the hospital has a reasonable certainty of receipt 
of notifications; and
    (4) Either immediately prior to or at the time of the patient's 
discharge or transfer from the hospital, the system sends notifications 
directly or through an intermediary that facilitates exchange of health 
information, to licensed and qualified practitioners, other patient 
care team members, and post-acute care services providers and 
suppliers:
    (i) That receive the notification for treatment, care coordination, 
or quality improvement purposes;
    (ii) That have an established care relationship with the patient 
relevant to his or her care; and
    (iii) For whom the hospital has a reasonable certainty of receipt 
of notifications.
0
21. 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 with the capacity to generate 
information for patient event notifications in accordance with 
paragraph (f)(2) of this section, then the hospital must demonstrate 
that--
    (1) The 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) The system complies with the regulations regarding the content 
exchange standard at 45 CFR 170.205(a)(4)(i);
    (3) The system sends notifications that must include the minimum 
patient health information (which must be patient name, treating 
practitioner name, sending institution name, and, if not prohibited by 
other applicable law, patient diagnosis);
    (4) At the time of the patient's admission to the hospital, the 
system sends notifications directly, or through an intermediary that 
facilitates exchange of health information, to licensed and qualified 
practitioners, other patient care team members, and post-acute care 
services providers and suppliers:
    (i) That receive the notification for treatment, care coordination, 
or quality improvement purposes;
    (ii) That have an established care relationship with the patient 
relevant to his or her care; and
    (iii) For whom the hospital has a reasonable certainty of receipt 
of notifications; and
    (5) Either immediately prior to or at the time of the patient's 
discharge or transfer from the hospital, the system sends notifications 
directly or through an intermediary that facilitates exchange

[[Page 7679]]

of health information, to licensed and qualified practitioners, other 
patient care team members, and post-acute care services providers and 
suppliers:
    (i) That receive the notification for treatment, care coordination, 
or quality improvement purposes;
    (ii) That have an established care relationship with the patient 
relevant to his or her care; and
    (iii) For whom the hospital has a reasonable certainty of receipt 
of notifications.

PART 485--CONDITIONS OF PARTICIPATION: SPECIALIZED PROVIDERS

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

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

0
23. 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 with the capacity to generate 
information for patient event notifications in accordance with 
paragraph (d)(2) of this section, then the CAH must demonstrate that--
    (1) The 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) The system complies with the regulations regarding the content 
exchange standard at 45 CFR 170.205(a)(4)(i);
    (3) The system sends notifications that must include the minimum 
patient health information (which must be patient name, treating 
practitioner name, sending institution name, and, if not prohibited by 
other applicable law, patient diagnosis);
    (4) At the time of the patient's admission to the CAH, the system 
sends notifications directly or through an intermediary that 
facilitates exchange of health information, to licensed and qualified 
practitioners, other patient care team members, and post-acute care 
services providers and suppliers:
    (i) That receive the notification for treatment, care coordination, 
or quality improvement purposes;
    (ii) That have an established care relationship with the patient 
relevant to his or her care; and
    (iii) For whom the CAH has a reasonable certainty of receipt of 
notifications; and
    (5) Either immediately prior to or at the time of the patient's 
discharge or transfer from the CAH, the system sends notifications 
directly or through an intermediary that facilitates exchange of health 
information, to licensed and qualified practitioners, other patient 
care team members, and post-acute care services providers and 
suppliers:
    (i) That receive the notification for treatment, care coordination, 
or quality improvement purposes;
    (ii) That have an established care relationship with the patient 
relevant to his or her care; and
    (iii) For whom the CAH has a reasonable certainty of receipt of 
notifications.

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
24. The authority citation for part 156 is revised 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
25. 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, QHP issuers in a Federally-
facilitated Exchange, not including stand-alone dental plans (SADP) 
issuers, must implement and maintain an open Application Programming 
Interface (API) that permits third-party applications to retrieve, with 
the approval and at the direction of an individual enrollee, 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 in a Federally-facilitated 
Exchange must make the following information accessible to its 
enrollees through the API described in paragraph (a) of this section:
    (i) Standardized 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) Standardized encounter data, 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 such data, no later than one (1) business day after 
data is received by the issuer.
    (c) Technical requirements. A QHP issuer in a Federally-facilitated 
Exchange:
    (1) Must implement, maintain, and use API technology conformant 45 
CFR 170.215;
    (2) Must conduct routine testing and monitoring 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 minimally required to comply with HIPAA 
privacy and security requirements in 45 CFR part 164, 42 CFR parts 2 
and 3, and other applicable law protecting privacy and security of 
individually identifiable data;
    (3) Must comply with the following regulations regarding the 
content and vocabulary standards for data available through the API 
where 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 the only available standards for the data type or element;
    (ii) Content and vocabulary standards at 45 CFR part 162 and 42 CFR 
423.160 where required by law, or where such standards are the only 
available standards for the data type or element; or
    (iii) The content and vocabulary standards in either paragraph 
(c)(3)(i) or (ii) of this section as determined appropriate for the 
data type or element, where a specific data type or element may be 
encoded or formatted using content and vocabulary standards in either 
paragraph (c)(3)(i) or (ii) of this section.
    (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 45 CFR 170.215, the 
National

[[Page 7680]]

Coordinator has approved the updated version for use in the ONC Health 
IT Certification Program; and
    (iii) Where 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 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:
    (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 in 
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 issuer:
    (1) Reasonably determines 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 45 CFR 171.102, including but not 
limited to criteria that may rely on automated monitoring and risk 
mitigation tools.
    (f) Exchange of data between plans. (1) Subject to paragraph (d) of 
this section, QHP issuers in a Federally-facilitated Exchange, not 
including SADP issuers, must maintain a process for the electronic 
exchange of, at a minimum, the data classes and elements included in 
the regulations regarding the content standard at 45 CFR 170.213 of 
this subchapter. Information received by a QHP issuer must be 
incorporated into the QHP issuer's records about the enrollee. At the 
request. A QHP issuer must:
    (i) Accept such data from any other health care plan 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 such data to any other health 
care plan that currently covers the enrollee; and
    (iii) At any time the enrollee is currently enrolled in the plan 
and up to 5 years after disenrollment, send such data to a recipient 
designated by the enrollee.
    (2) QHP issuers must participate in a trusted exchange network 
which:
    (i) Is capable of exchanging protected health information, defined 
at 45 CFR 160.103 of this subchapter, in compliance with all applicable 
State and Federal laws of relevant jurisdictions;
    (ii) Is capable of connecting to inpatient electronic health 
records and ambulatory electronic health records; and
    (iii) Supports secure messaging or electronic querying by and 
between providers, payers and patients.
    (g) Enrollee resources regarding privacy and security. A QHP issuer 
in a Federally-facilitated Exchange must provide on its 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, and 
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; 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), (b), or (c) 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.
    (2) The Federally-facilitated Exchange may grant an exception to 
the requirements in paragraphs (a), (b), or (c) if the Exchange 
determines that making such health plan available through such Exchange 
is in the interests of qualified individuals and qualified employers in 
the State or States in which such Exchange operates.
    (i) Applicability. This section is applicable for plan years 
beginning on or after January 1, 2020.
    (ii) [Reserved]

    Dated: December 14, 2018.
Seema Verma,
Administrator, Centers for Medicare & Medicaid Services.
    Dated: January 10, 2019.
Alex M. Azar II,
Secretary, Department of Health and Human Services.
[FR Doc. 2019-02200 Filed 2-22-19; 4:15 pm]
 BILLING CODE 4120-01-P