Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers
| Published date | 01 May 2020 |
| Citation | 85 FR 25510 |
| Record Number | 2020-05050 |
| Section | Rules and Regulations |
| Court | Centers For Medicare & Medicaid Services |
Federal Register, Volume 85 Issue 85 (Friday, May 1, 2020)
[Federal Register Volume 85, Number 85 (Friday, May 1, 2020)]
[Rules and Regulations]
[Pages 25510-25640]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2020-05050]
[[Page 25509]]
Vol. 85
Friday,
No. 85
May 1, 2020
Part II
Department of Health and Human Services
-----------------------------------------------------------------------
Centers for Medicare & Medicaid Services
-----------------------------------------------------------------------
42 CFR Parts 406, 407, 422, Et al.
45 CFR Part 156
Medicare and Medicaid Programs; Patient Protection and Affordable Care
Act; Interoperability and Patient Access for Medicare Advantage
Organization and Medicaid Managed Care Plans, State Medicaid Agencies,
CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, and Health Care
Providers; Final Rule
Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and
Regulations
[[Page 25510]]
-----------------------------------------------------------------------
DEPARTMENT OF HEALTH AND HUMAN SERVICES
Centers for Medicare & Medicaid Services
42 CFR Parts 406, 407, 422, 423, 431, 438, 457, 482, and 485
Office of the Secretary
45 CFR Part 156
[CMS-9115-F]
RIN 0938-AT79
Medicare and Medicaid Programs; Patient Protection and Affordable
Care Act; Interoperability and Patient Access for Medicare Advantage
Organization and Medicaid Managed Care Plans, State Medicaid Agencies,
CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges, and Health Care
Providers
AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: This final rule is intended to move the health care ecosystem
in the direction of interoperability, and to signal our commitment to
the vision set out in the 21st Century Cures Act and Executive Order
13813 to improve the quality and accessibility of information that
Americans need to make informed health care decisions, including data
about health care prices and outcomes, while minimizing reporting
burdens on affected health care providers and payers.
DATES: These regulations are effective on June 30, 2020.
FOR FURTHER INFORMATION CONTACT:
Alexandra Mugge, (410) 786-4457, for issues related to
interoperability, CMS health IT strategy, and technical standards.
Denise St. Clair, (410) 786-4599, for issues related API policies
and related standards.
Natalie Albright, (410) 786-1671, for issues related to Medicare
Advantage.
Laura Snyder, (410) 786-3198, for issues related to Medicaid.
Rebecca Zimmermann, (301) 492-4396, for issues related to Qualified
Health Plans.
Meg Barry, (410) 786-1536, for issues related to CHIP.
Thomas Novak, (202) 322-7235, for issues related to trust exchange
networks and payer to payer coordination.
Sharon Donovan, (410) 786-9187, for issues related to federal-state
data exchange.
Daniel Riner, (410) 786-0237, for issues related to Physician
Compare.
Ashley Hain, (410) 786-7603, for issues related to hospital public
reporting.
Melissa Singer, (410) 786-0365, for issues related to provider
directories.
CAPT Scott Cooper, USPHS, (410) 786-9465, for issues related to
hospital and critical access hospital conditions of participation.
Russell Hendel, (410) 786-0329, for issues related to the
Collection of Information or the Regulation Impact Analysis sections.
SUPPLEMENTARY INFORMATION:
Table of Contents
I. Background and Summary of Provisions
A. Purpose
B. Overview
C. Executive Order and MyHealthEData
D. Past Efforts
E. Challenges and Barriers to Interoperability
F. Summary of Major Provisions
II. Technical Standards Related to Interoperability Provisions, and
Analysis of and Responses to Public Comments
A. Technical Approach and Standards
B. Content and Vocabulary Standards
C. Application Programming Interface (API) Standard
D. Updates to Standards
III. Provisions of Patient Access Through APIs, and Analysis of and
Responses to Public Comments
A. Background on Medicare Blue Button
B. Expanding the Availability of Health Information
C. Standards-based API Proposal for MA, Medicaid, CHIP, and QHP
Issuers on the FFEs
IV. API Access to Published Provider Directory Data Provisions, and
Analysis of and Responses to Public Comments
A. Interoperability Background and Use Cases
B. Broad API Access to Provider Directory Data
V. The Health Information Exchange and Care Coordination Across
Payers: Establishing a Coordination of Care Transaction To
Communicate Between Plans Provisions, and Analysis of and Responses
to Public Comments
VI. Care Coordination Through Trusted Exchange Networks: Trust
Exchange Network Requirements for MA Plans, Medicaid Managed Care
Plans, CHIP Managed Care Entities, and QHPs on the FFEs Provisions,
and Analysis of and Responses to Public Comments
VII. Improving the Medicare-Medicaid Dually Eligible Experience by
Increasing the Frequency of Federal-State Data Exchanges Provisions,
and Analysis of and Responses to Public Comments
A. Increasing the Frequency of Federal-State Data Exchanges for
Dually Eligible Individuals
B. Request for Stakeholder Input
VIII. Information Blocking Background and Public Reporting
Provisions, and Analysis of and Responses to Public Comments
A. Information Blocking Background
B. Public Reporting and Prevention of Information Blocking on
Physician Compare
C. Public Reporting and Prevention of Information Blocking for
Eligible Hospitals and Critical Access Hospitals (CAHs)
IX. Provider Digital Contact Information Provisions, and Analysis of
and Responses to Public Comments
A. Background
B. Public Reporting of Missing Digital Contact Information
X. Conditions of Participation for Hospitals and Critical Access
Hospitals (CAHs) Provisions, and Analysis of and Responses to Public
Comments
A. Background
B. Provisions for Hospitals (42 CFR 482.24(d))
C. Provisions for Psychiatric Hospitals (42 CFR 482.61(f))
D. Provisions for CAHs (42 CFR 485.638(d))
XI. Provisions of the Final Regulations
XII. Collection of Information Requirements
A. Background
B. Wage Estimates
C. Information Collection Requirements (ICRs)
XIII. Regulatory Impact Analysis
A. Statement of Need
B. Overall Impact
C. Anticipated Effects
D. Alternatives Considered
E. Accounting Statement and Table
F. Regulatory Reform Analysis Under E.O. 13771
G. Conclusion
Regulation Text
I. Background and Summary of Provisions
In the March 4, 2019 Federal Register, we published the ``Medicare
and Medicaid Programs; Patient Protection and Affordable Care Act;
Interoperability and Patient Access for Medicare Advantage Organization
and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies
and CHIP Managed Care Entities, Issuers of Qualified Health Plans on
the Federally-facilitated Exchanges and Health Care Providers''
proposed rule (84 FR 7610) (hereinafter referred to as the ``CMS
Interoperability and Patient Access proposed rule''). The proposed rule
outlined our proposed policies that were intended to move the health
care ecosystem in the direction of interoperability, and to signal our
commitment to the vision set out in the 21st Century Cures Act and
Executive Order 13813 to improve quality and accessibility of
information that Americans need to make informed
[[Page 25511]]
health care decisions, including data about health care prices and
outcomes, while minimizing reporting burdens on affected health care
providers and payers. We solicited public comments on the CMS
Interoperability and Patient Access proposed rule. In this final rule,
we address those public comments and outline our final policies in the
respective sections of this rule.
A. Purpose
This final rule is the first phase of policies centrally focused on
advancing interoperability and patient access to health information
using the authority available to the Centers for Medicare & Medicaid
Services (CMS). We believe this is an important step in advancing
interoperability, putting patients at the center of their health care,
and ensuring they have access to their health information. We are
committed to working with stakeholders to solve the issue of
interoperability and getting patients access to information about their
health care, and we are taking an active approach to move participants
in the health care market toward interoperability and the secure and
timely exchange of health information by adopting policies for the
Medicare and Medicaid programs, the Children's Health Insurance Program
(CHIP), and qualified health plan (QHP) issuers on the individual
market Federally-facilitated Exchanges (FFEs). For purposes of this
rule, references to QHP issuers on the FFEs excludes issuers offering
only stand-alone dental plans (SADPs), unless otherwise noted for a
specific proposed or finalized policy. Likewise, we are also excluding
QHP issuers only offering QHPs in the Federally-facilitated Small
Business Health Options Program Exchanges (FF-SHOPs) from the
provisions of this rule and so, for purposes of this rule references to
QHP issuers on the FFEs excludes issuers offering QHPs only on the FF-
SHOPs. We note that, in this final rule, FFEs include FFEs in states
that perform plan management functions. State-Based Exchanges on the
Federal Platform (SBE-FPs) are not FFEs, even though consumers in these
states enroll in coverage through HealthCare.gov, and QHP issuers in
SBE-FPs are not subject to the requirements in this rule.
B. Overview
We are dedicated to enhancing and protecting the health and well-
being of all Americans. One critical issue in the U.S. health care
system is that people cannot easily access their health information in
interoperable forms. Patients and the health care providers caring for
them are often presented with an incomplete picture of their health and
care as pieces of their information are stored in various, unconnected
systems and do not accompany the patient to every care setting.
Although more than 95 percent of hospitals \1\ and 75 percent of
office-based clinicians \2\ are utilizing certified health IT,
challenges remain in creating a comprehensive, longitudinal view of a
patient's health history.3 4 5 This siloed nature of health
care data prevents physicians, pharmaceutical companies, manufacturers,
and payers from accessing and interpreting important data sets,
instead, encouraging each group to make decisions based upon a part of
the information rather than the whole. Without an enforced standard of
interoperability, data exchanges are often complicated and time-
consuming.
---------------------------------------------------------------------------
\1\ Office of the National Coordinator. (2019). Hospitals' Use
of Electronic Health Records Data, 2015-2017. Retrieved from https://www.healthit.gov/sites/default/files/page/2019-04/AHAEHRUseDataBrief.pdf.
\2\ Office of the National Coordinator. (2019, December 18).
Health IT Playbook, Section 1: Electronic Health Records. Retrieved
from https://www.healthit.gov/playbook/electronic-health-records/.
\3\ Powell, K. R. & Alexander, G. L. (2019). Mitigating Barriers
to Interoperability in Health Care. Online Journal of Nursing
Informatics, 23(2). Retrieved from https://www.himss.org/library/mitigating-barriers-interoperability-health-care.
\4\ Hochman, M., Garber, J., & Robinson, E. J. (2019, August
14). Health Information Exchange After 10 Years: Time For A More
Assertive, National Approach. Retrieved from https://www.healthaffairs.org/do/10.1377/hblog20190807.475758/full/.
\5\ Payne, T. H., Lovis, C., Gutteridge, C., Pagliari, C.,
Natarajan, S., Yong, C., & Zhao, L. (2019). Status of health
information exchange: A comparison of six countries. Journal of
Global Health, 9(2). doi: 10.7189/jogh.09.020427.
---------------------------------------------------------------------------
We believe patients should have the ability to move from payer to
payer, provider to provider, and have both their clinical and
administrative information travel with them throughout their journey.
When a patient receives care from a new provider, a record of their
health information should be readily available to that care provider,
regardless of where or by whom care was previously provided. When a
patient is discharged from a hospital to a post-acute care (PAC)
setting there should be no question as to how, when, or where their
data will be exchanged. Likewise, when an enrollee changes payers or
ages into Medicare, the enrollee should be able to have their claims
history and encounter data follow so that information is not lost. As
discussed in more detail in section III. of this final rule, claims and
encounter data can offer a more holistic understanding of a patient's
health, providing insights into everything from the frequency and types
of care provided and for what reason, medication history and adherence,
and the evolution and adherence to a care plan. This information can
empower patients to make better decisions and inform providers to
support better health outcomes.
For providers in clinical and community settings, health
information technology (health IT) should be a resource, enabling
providers to deliver high quality care, creating efficiencies and
allowing them to access all payer and provider data for their patients.
Therefore, health IT should not detract from the clinician-patient
relationship, from the patient's experience of care, or from the
quality of work life for physicians, nurses, other health care
professionals, and social service providers. Through standards-based
interoperability and information exchange, health IT has the potential
to facilitate efficient, safe, high-quality care for individuals and
populations.
All payers should have the ability to exchange data seamlessly with
other payers for timely benefits coordination or transitions, and with
health care and social service providers to facilitate more coordinated
and efficient care. Payers are in a unique position to provide
enrollees with a comprehensive picture of their claims and encounter
data, allowing patients to piece together their own information that
might otherwise be lost in disparate systems. This information can
contribute to better informed decision making, helping to inform the
patient's choice of coverage options and care providers to more
effectively manage their own health, care, and costs.
We are committed to working with stakeholders to solve the issue of
interoperability and patient access in the U.S. health care system
while reducing administrative burdens on providers and are taking an
active approach using all available policy levers and authorities to
move participants in the health care market toward interoperability and
the secure and timely exchange of health care information.
C. Executive Order and MyHealthEData
On October 12, 2017, President Trump issued Executive Order 13813
to Promote Healthcare Choice and Competition Across the United States.
Section 1(c)(iii) of Executive Order 13813 states that the
Administration will improve access to, and the quality of, information
that Americans need to make informed health care decisions, including
information about health care
[[Page 25512]]
prices and outcomes, while minimizing reporting burdens on impacted
providers, and payers, meaning providers and payers subject to this
rule.
In support of Executive Order 13813, the Administration launched
the MyHealthEData initiative. This government-wide initiative aims to
empower patients by ensuring that they have access to their own health
information and the ability to decide how their data will be used,
while keeping that information safe and secure. MyHealthEData aims to
break down the barriers that prevent patients from gaining electronic
access to their health information from the device or application of
their choice, empowering patients and taking a critical step toward
interoperability and patient data exchange.
In March 2018, the White House Office of American Innovation and
the CMS Administrator announced the launch of MyHealthEData, and CMS's
direct, hands-on role in improving patient access and advancing
interoperability. As part of the MyHealthEData initiative, we are
taking a patient-centered approach to health information access and
moving to a system in which patients have immediate access to their
computable health information such that they can be assured that their
health information will follow them as they move throughout the health
care system from provider to provider, payer to payer. To accomplish
this, we have launched several initiatives related to data sharing and
interoperability to empower patients and encourage payer and provider
competition. We continue to advance the policies and goals of the
MyHealthEData initiative through various provisions included in this
final rule.
As finalized in this rule, our policies are wide-reaching and will
have an impact on all facets of the health care system. Several key
touch points of the policies in this rule include:
Patients: Enabling patients to access their health
information electronically without special effort by requiring the
payers subject to this final rule to make data available through an
application programming interface (API) to which third-party software
applications connect to make data available to patients for their
personal use. This encourages patients to take charge of and better
manage their health care, and thus these initiatives are imperative to
improving a patient's long-term health outcomes.
Clinicians and Hospitals: Ensuring that health care
providers have ready access to health information about their patients,
regardless of where the patient may have previously received care. We
are also implementing policies to prevent health care providers from
inappropriately restricting the flow of information to other health
care providers and payers. Finally, we are working to ensure that
better interoperability reduces the burden on health care providers.
Payers: Implementing requirements to ensure that payers
(that is, entities and organizations that pay for health care), such as
payers in Medicare Advantage, Medicaid, and CHIP, make enrollee
electronic health information held by the payer available through an
API such that, with use of software expected to be developed by payers
and third parties, the information becomes easily accessible to the
enrollee and data flow seamlessly with the enrollee as such enrollees
change health care and social service providers and payers.
Additionally, our policies ensure that payers make it easy for current
and prospective enrollees to identify which providers are within a
given plan's network in a way that is simple and easy for enrollees to
access and understand, and thus find the providers that are right for
them.
As a result of our efforts to standardize data and technical
approaches to advance interoperability, we believe health care
providers and their patients, as well as other key participants within
the health care ecosystem such as payers, will have appropriate access
to the information necessary to coordinate individual care; analyze
population health trends, outcomes, and costs; and manage benefits and
the health of populations, while tracking progress through quality
improvement initiatives. We are working with other federal partners
including the Office of the National Coordinator for Health Information
Technology (ONC) on this effort with the clear objectives of improving
patient access and care, alleviating provider burden, and reducing
overall health care costs, all while taking steps to protect the
privacy and security of patients' personal health information. As
evidence of this partnership, ONC is releasing the ONC 21st Century
Cures Act final rule (published elsewhere in this issue of the Federal
Register) in tandem with this final rule. It is this coordinated
federal effort, in conjunction with strong support and innovation from
our stakeholders, that will help us move ever closer to true
interoperability.
D. Past Efforts
The Department of Health and Human Services (HHS) has been working
to advance the interoperability of electronic health information for
over 15 years. For a detailed explanation of past efforts, see the CMS
Interoperability and Patient Access proposed rule (84 FR 7612 through
7614).
E. Challenges and Barriers to Interoperability
Through significant stakeholder feedback, we understand that there
are many barriers to interoperability, which have obstructed progress
over the years. We have conducted stakeholder meetings and roundtables;
solicited comments via RFIs; and received additional feedback through
letters and rulemaking. All of this input together contributed to the
policies in our Interoperability and Patient Access proposed rule, and
when combined with the comments we received on the proposed rule, the
content of this final rule. Some of the main barriers shared with us,
specifically patient identification, lack of standardization,
information blocking, the lack of adoption and use of certified health
IT among post-acute care (PAC) providers, privacy concerns, and
uncertainty about the requirements of the Health Insurance Portability
and
Accountability Act of 1996 (HIPAA) Privacy, Security, and Breach
Notification Rules, were discussed in the proposed rule (84 FR 7614
through 7617). While we have made efforts to address some of these
barriers in this final rule and through prior rules and actions, we
believe there is still considerable work to be done to overcome some of
these challenges toward achieving interoperability, and we will
continue this work as we move forward with our interoperability
efforts.
F. Summary of Major Provisions
This final rule empowers patients in MA organizations, Medicaid and
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs, by finalizing several
initiatives that will break down those barriers currently keeping
patients from easily accessing their electronic health care
information. Additionally, the rule creates and implements new
mechanisms to enable patients to access their own health care
information through third-party software applications, thereby
providing them with the ability to decide how, when, and with whom to
share their information.
[[Page 25513]]
We are finalizing with modifications our proposal to require MA
organizations, Medicaid and CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs to
implement and maintain a standards-based Patient Access API. This
Patient Access API must meet the technical standards finalized by HHS
in the ONC 21st Century Cures Act final rule (published elsewhere in
this issue of the Federal Register) at 45 CFR 170.215 (currently
including Health Level 7[supreg] (HL7) Fast Healthcare Interoperability
Resources[supreg] (FHIR) Release 4.0.1) and the content and vocabulary
standards finalized by HHS in the ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register) at 45 CFR
170.213, as well as content and vocabulary standards at 45 CFR part 162
and the content and vocabulary standards at 42 CFR 423.160. We are
finalizing that through the Patient Access API, payers must permit
third-party applications to retrieve, with the approval and at the
direction of a current enrollee, data specified at 42 CFR 422.119,
431.60, 457.730, and 45 CFR 156.221. Specifically, we are requiring
that the Patient Access API must, at a minimum, make available
adjudicated claims (including provider remittances and enrollee cost-
sharing); encounters with capitated providers; and clinical data,
including laboratory results (when maintained by the impacted payer).
Data must be made available no later than one (1) business day after a
claim is adjudicated or encounter data are received. We are requiring
that beginning January 1, 2021, impacted payers make available through
the Patient Access API the specified data they maintain with a date of
service on or after January 1, 2016. This is consistent with the
requirements for the payer-to-payer data exchange detailed in section
V. of this final rule. Together these policies facilitate the creation
and maintenance of a patient's cumulative health record with their
current payer.
We are finalizing regulations to require that MA organizations,
Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP
managed care entities make standardized information about their
provider networks available through a Provider Directory API that is
conformant with the technical standards finalized by HHS in the ONC
21st Century Cures Act final rule (published elsewhere in this issue of
the Federal Register) at 45 CFR 170.215, excluding the security
protocols related to user authentication and authorization and any
other protocols that restrict availability of this information to
particular persons or organizations. Authentication and authorization
protocols are not necessary when making publicly available data
accessible via an API. We are finalizing that the Provider Directory
API must be accessible via a public-facing digital endpoint on the
payer's website to ensure public discovery and access. At a minimum,
these payers must make available via the Provider Directory API
provider names, addresses, phone numbers, and specialties. For MA
organizations that offer MA-PD plans, they must also make available, at
a minimum, pharmacy directory data, including the pharmacy name,
address, phone number, number of pharmacies in the network, and mix
(specifically the type of pharmacy, such as ``retail pharmacy''). All
directory information must be made available to current and prospective
enrollees and the public through the Provider Directory API within 30
calendar days of a payer receiving provider directory information or an
update to the provider directory information. The Provider Directory
API is being finalized at 42 CFR 422.120 for MA organizations, at 42
CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for
Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies,
and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. Here we
are finalizing that access to the published Provider Directory API must
be fully implemented by January 1, 2021. We do strongly encourage
payers to make their Provider Directory API public as soon as possible
to make and show progress toward meeting all the API requirements being
finalized in this rule.
We are finalizing our proposal, with certain modifications as
detailed in section V. of this final rule, to require MA organizations,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to coordinate care between payers by exchanging, at
a minimum, the data elements specified in the current content and
vocabulary standard finalized by HHS in the ONC 21st Century Cures Act
final rule (published elsewhere in this issue of the Federal Register)
at 45 CFR 170.213 (currently the ``United States Core Data for
Interoperability'' (USCDI) version 1 \6\). This payer-to-payer data
exchange requires these payers, as finalized at 42 CFR 422.119(f) for
MA organizations, at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care
plans (and by extension under Sec. 457.1216 CHIP managed care
entities), and at 45 CFR 156.221(f) for QHP issuers on the FFEs, to
send, at a current or former enrollee's request, specific information
they maintain with a date of service on or after January 1, 2016 to any
other payer identified by the current enrollee or former enrollee. This
is consistent with the Patient Access API detailed in section III. of
this final rule. We are also finalizing a provision that a payer is
only obligated to share data received from another payer under this
regulation in the electronic form and format it was received. This is
intended to reduce burden on payers. We are finalizing that this payer-
to-payer data exchange must be fully implemented by January 1, 2022.
---------------------------------------------------------------------------
\6\ Office of the National Coordinator. (n.d.). U.S. Core Data
for Interoperability (USCDI). Retrieved from https://www.healthit.gov/isa/us-core-data-interoperability-uscdi.
---------------------------------------------------------------------------
In response to comments discussed more fully below, we are not
finalizing our proposal to require MA organizations, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to
participate in a trusted exchange network given the concerns commenters
raised regarding the need for a mature Trusted Exchange Framework and
Common Agreement (TEFCA) to be in place first, and appreciating that
work on TEFCA is ongoing at this time.
We are finalizing the requirements that all states participate in
daily exchange of buy-in data, which includes both sending data to CMS
and receiving responses from CMS daily, and that all states submit the
MMA file data to CMS daily by April 1, 2022 in accordance with 42 CFR
406.26, 407.40, and 423.910, respectively, as proposed. These
requirements will improve the experience of dually eligible individuals
by improving the ability of providers and payers to coordinate
eligibility, enrollment, benefits, and/or care for this population.
We are finalizing our proposal to include an indicator on Physician
Compare for the eligible clinicians and groups that submit a ``no''
response to any of the three prevention of information blocking
statements for MIPS. In the event that these statements are left blank,
the attestations will be considered incomplete, and we will not include
an indicator on Physician Compare. The indicator will be posted on
Physician Compare, either on the profile pages or in the downloadable
database, starting with the 2019 performance period data available for
public reporting starting in late 2020.
[[Page 25514]]
We are finalizing our proposal to include information on a publicly
available CMS website indicating that an eligible hospital or critical
access hospital (CAH) attesting under the Medicare FFS Promoting
Interoperability Program had submitted a ``no'' response to any of the
three attestation statements related to the prevention of information
blocking. In the event that an eligible hospital or CAH leaves a
``blank'' response, the attestations will be considered incomplete, and
no information will be posted related to these attestation statements.
We will post this information starting with the attestations for the
EHR reporting period in 2019 and expect this information will be posted
in late 2020.
Additionally, as detailed in section IX. of this final rule, we are
finalizing our proposal to publicly report the names and NPIs of those
providers who do not have digital contact information included in the
National Plan and Provider Enumeration System (NPPES) system beginning
in the second half of 2020 as proposed. Additionally, we will continue
to ensure providers are aware of the benefits of including digital
contact information in NPPES, and when and where their names and NPIs
will be posted if they do not include this information. We do strongly
encourage providers to include FHIR endpoint information in NPPES if
and when they have the information, as well.
To further advance electronic exchange of information that supports
effective transitions of care we are finalizing the requirement for a
hospital, psychiatric hospital, and CAH, which utilizes an electronic
medical records system or other electronic administrative system that
is conformant with the content exchange standard at 45 CFR
170.205(d)(2) to demonstrate that: (1) Its system's notification
capacity is fully operational and that it operates in accordance with
all state and federal statutes and regulations regarding the exchange
of patient health information; (2) its system sends notifications that
must include the minimum patient health information specified in
section X. of this final rule; and (3) its system sends notifications
directly, or through an intermediary that facilitates exchange of
health information, and at the time of a patient's registration in the
emergency department or admission to inpatient services, and also prior
to, or at the time of, a patient's discharge and/or transfer from the
emergency department or inpatient services, to all applicable post-
acute care services providers and suppliers, primary care practitioners
and groups, and other practitioners and groups identified by the
patient as primarily responsible for his or her care, and who or which
need to receive notification of the patient's status for treatment,
care coordination, or quality improvement purposes. We are establishing
that this policy will be applicable 12 months after publication of this
rule for hospitals, including psychiatric hospitals, and CAHs to allow
for adequate and additional time for these institutions, especially
small and/or rural hospitals as well as CAHs, to come into compliance
with the new requirements.
Finally, we note that we included two RFIs in the proposed rule:
one related to interoperability and health IT adoption in PAC settings
and one related to the role of patient matching in interoperability and
improved patient care. We thank commenters for the insights shared on
these two topics. We are reviewing these comments and will take them
into consideration for potential future rulemaking.
Throughout this final rule, we refer to terms such as ``patient,''
``consumer,'' ``beneficiary,'' ``enrollee,'' and ``individual.'' We
note that every reader of this final rule is a patient and has or will
receive medical care at some point in their life. In this final rule,
we use the term ``patient'' as an inclusive term, but because we have
historically referred to patients using the other terms noted above in
our regulations, we use specific terms as applicable in sections of
this final rule to refer to individuals covered under the health care
programs that CMS administers and regulates. We also note that when we
discuss patients, we acknowledge a patient's personal representative.
Per the HIPAA privacy regulations at 45 CFR 164.502(g), a personal
representative is someone authorized under state or other applicable
law to act on behalf of the individual in making health care related
decisions (such as a parent, guardian, or person with a medical power
of attorney).\7\ Policies in this final rule that require a patient's
action could be addressed by a patient's personal representative.
---------------------------------------------------------------------------
\7\ See OCR guidance regarding personal representatives at
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html.
---------------------------------------------------------------------------
We also use terms such as ``payer,'' ``plan,'' and ``issuer'' in
this final rule. Certain portions of this final rule are applicable to
the Medicare Fee-for-Service (FFS) Program, the Medicaid FFS Program,
the CHIP FFS program, Medicare Advantage (MA) organizations, Medicaid
Managed Care plans (managed care organizations (MCOs), prepaid
inpatient health plans (PIHPs), and prepaid ambulatory health plans
(PAHPs)), CHIP Managed Care entities (MCOs, PIHPs, and PAHPs), and QHP
issuers on the FFEs. We use the term ``payer'' in the preamble of this
final rule as an inclusive term for all these programs (and plan types
in the case of plans), but we also use specific terms as applicable in
sections of this final rule. Finally, we use the term ``provider,''
too, as an inclusive term comprising individuals, organizations, and
institutions that provide health services, such as clinicians,
hospitals, skilled nursing facilities, home health agencies, hospice
settings, laboratories, suppliers of durable medical equipment,
community based organizations, etc., as appropriate in the context
used.
II. Technical Standards Related to Interoperability Provisions, and
Analysis of and Responses to Public Comments
A. Technical Approach and Standards
1. Use of Health Level 7[supreg] (HL7) Fast Healthcare Interoperability
Resources[supreg] (FHIR) for APIs
Section 106(b)(1)(B)(ii) of the Medicare Access and CHIP
Reauthorization Act of 2015 (MACRA) defines health IT
``interoperability'' as the ability of two or more health information
systems or components to exchange clinical and other information and to
use the information that has been exchanged using common standards to
provide access to longitudinal information for health care providers in
order to facilitate coordinated care and improved patient outcomes.
Interoperability is also defined in section 3000 of the Public Health
Service Act (PHSA) (42 U.S.C. 300jj), as amended by section 4003 of the
21st Century Cures Act. Under that definition, ``interoperability,''
with respect to health IT, means such health IT that enables the secure
exchange of electronic health information with, and use of electronic
health information from, other health IT without special effort on the
part of the user; allows for complete access, exchange, and use of all
electronically accessible health information for authorized use under
applicable state or federal law; and does not constitute information
blocking as defined in section 3022(a) of the PHSA, which was added by
section 4004 of the Cures Act. We believe the PHSA definition is
consistent with the MACRA definition of ``interoperability''.
Consistent with the CMS Interoperability and Patient Access
[[Page 25515]]
proposed rule (84 FR 7619), we will use the PHSA definition of
``interoperability'' for the purposes of this final rule.
We believe the PHSA definition of ``interoperability'' is useful as
a foundational reference for our approach to advancing the
interoperability and exchange of electronic health information for
individuals throughout the United States, and across the entire
spectrum of provider types and care settings with which health
insurance issuers and administrators need to efficiently exchange
multiple types of relevant data. We noted the PHSA definition of
``interoperability'' is not limited to a specific program or
initiative, but rather can be applied to all activities under the title
of the PHSA that establishes ONC's responsibilities to support and
shape the health information ecosystem, including the exchange
infrastructure for the U.S. health care system as a whole. The PHSA
definition is also consistent with HHS's vision and strategy for
achieving a health information ecosystem within which all individuals,
their personal representatives, their health care providers, and their
payers are able to send, receive, find, and use electronic health
information in a manner that is appropriate, secure, timely, and
reliable to support the health and wellness of individuals through
informed, shared decision-making,\8\ as well as to support consumer
choice of payers and providers.
---------------------------------------------------------------------------
\8\ See, for example, Office of the National Coordinator.
(2015). Connecting Health and Care for the Nation: A Shared
Nationwide Interoperability Roadmap, Final Version 1.0. Retrieved
from https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf.
---------------------------------------------------------------------------
We summarize the public comment we received on use of the PHSA
definition of ``interoperability'' and provide our response.
Comment: One commenter specifically supported the use of the PHSA
definition of ``interoperability''.
Response: We appreciate the commenter's support.
A core policy principle we aim to support across all policies in
this rule is that every American should be able, without special effort
or advanced technical skills, to see, obtain, and use all
electronically available information that is relevant to their health,
care, and choices--of plans, providers, and specific treatment options.
In the proposed rule, we explained this included two types of
information: personal health information that health care providers and
health plans, or payers, must make available to an individual, such as
their current and past medical conditions and care received; and
information that is of general interest and should be widely available,
such as plan provider networks, the plan's formulary, and coverage
policies (84 FR 7619).
We also discussed that while many consumers today can often access
their own electronic health information through patient or enrollee
portals and proprietary applications made available by various
providers and health plans, they must typically go through separate
processes to obtain access to each system, and often need to manually
aggregate information that is delivered in various, often non-
standardized, formats. The complex tasks of accessing and piecing
together this information can be burdensome and frustrating to
consumers.
An API can be thought of as a set of commands, functions,
protocols, or tools published by one software developer (``A'') that
enable other software developers to create programs (applications or
``apps'') that can interact with A's software without needing to know
the internal workings of A's software, all while maintaining consumer
privacy data standards.\9\ This is how API technology enables the
seamless user experiences associated with applications familiar from
other aspects of many consumers' daily lives, such as travel and
personal finance. Standardized, transparent, and pro-competitive API
technology can enable similar benefits to consumers of health care
services.\10\
---------------------------------------------------------------------------
\9\ See https://www.hl7.org/fhir/security.html for information
on how FHIR servers and resources integrate privacy and security
protocols into the data exchange via an API.
\10\ ONC has made available a succinct, non-technical overview
of APIs in context of consumers' access to their own medical
information across multiple providers' EHR systems, which is
available at the HealthIT.gov website at https://www.healthit.gov/api-education-module/story_html5.html.
---------------------------------------------------------------------------
While acknowledging the limits of our authority to require use of
APIs to address our goals for interoperability and data access, we
proposed to use our programmatic authority to require that a variety of
data be made accessible by requiring that MA organizations, Medicaid
state agencies, Medicaid managed care plans, CHIP agencies, CHIP
managed care entities, and QHP issuers on the FFEs, adopt and implement
``openly published,'' or secure, standards-based APIs. In the CMS
Interoperability and Patient Access proposed rule, we used the short
form terminology, ``open API''. We appreciate that this term can be
misunderstood to mean ``open'' as in ``not secure''. In actuality, an
``open API'' is a secure, standards-based API that has certain
technical information openly published to facilitate uniform use and
data sharing in a secure, standardized way. To avoid this
misinterpretation, we will use the term ``standards-based API'' in this
final rule where we used ``open API'' in the proposed rule. This is
also in better alignment with the terminology used in the ONC 21st
Century Cures Act proposed rule (84 FR 7453) and final rule (published
elsewhere in this issue of the Federal Register). We noted that having
certain data available through standards-based APIs would allow
impacted enrollees to use the application of their choice to access and
use their own electronic health information and other related
information to manage their health. See section III.C.2.a. of the CMS
Interoperability and Patient Access proposed rule for further
discussion (84 FR 7629).
Much like our efforts under Medicare Blue Button 2.0, also part of
the MyHealthEData initiative, which made Parts A, B, and D claims and
encounter data available via an API to Medicare beneficiaries, the
policies in this rule extend these benefits to even more patients. As
of January 2020, over 53,000 Medicare beneficiaries have taken
advantage of Blue Button. Currently, there are 55 production
applications and over 2,500 developers working in the Blue Button
sandbox. For more information on Blue Button 2.0 see section III. of
this final rule. As we noted in the CMS Interoperability and Patient
Access proposed rule, we believe that our Patient Access API, in
particular, will result in claims and encounter information becoming
easily accessible for the vast majority of patients enrolled with
payers regulated by CMS. As finalized, these policies will apply to all
MA organizations, all Medicaid and CHIP FFS programs, all types of
Medicaid managed care plans (MCOs, PIHPs, and PAHPs), as well as CHIP
managed care entities, and QHP issuers on the FFEs. We hope that states
operating Exchanges might consider adopting similar requirements for
QHPs on the State-Based Exchanges (SBEs), and that other payers in the
private sector might consider voluntarily offering data accessibility
of the type included in the policies being finalized here so that even
more patients across the American health care system can easily have
and use such information to advance their choice and participation in
their health care. In this way, we hope that the example being set by
CMS will raise consumers' expectations and
[[Page 25516]]
encourage other payers in the market to take similar steps to advance
patient access and empowerment outside the scope of the requirements
being finalized in this rule.
We explained in the CMS Interoperability and Patient Access
proposed rule (84 FR 7620) that those seeking further information
regarding what a standards-based API is are encouraged to review the
discussion of the standardized API criterion and associated policy
principles and technical standards included in ONC's 21st Century Cures
Act proposed rule (84 FR 7424) and final rule (published elsewhere in
this issue of the Federal Register). These rules provide more detailed
information on API functionality and interoperability standards
relevant to electronic health information. We noted that while that
discussion was specific to health IT, including Electronic Health
Records (EHR) systems, certified under ONC's Health IT Certification
Program rather than the information systems generally used by payers
and plan issuers for claims, encounters, or other administrative or
plan operational data, it included information applicable to
interoperability standards, as well as considerations relevant to
establishing reasonable and non-discriminatory terms of service for
applications seeking to connect to the standards-based API discussed in
this rule. While we reiterate that we did not propose to require payers
to use Health IT Modules certified under ONC's program to make
administrative data such as claims history or provider directory
information available to enrollees, we believe that the discussion of
APIs and related standards in the ONC 21st Century Cures Act rules will
be of use to those seeking to better understand the role of APIs in
health care information exchange.
We also discussed in our proposed rule how other industries have
advanced the sort of standards-based API-driven interoperability and
innovation that we seek in the health system (84 FR 7620). We have
sought to collaborate and align with ONC's proposed and final policies
specifically related to APIs under the Cures Act as we developed and
finalized these policies. In general, as we noted in our proposed rule,
we believe the following three attributes of standards-based APIs are
particularly important to achieving the goal of offering individuals
convenient access, through applications they choose, to available and
relevant electronic health and health-related information:
The API technologies themselves, not just the data
accessible through them, are standardized;
The APIs are technically transparent; and
The APIs are implemented in a pro-competitive manner.
In that section of the CMS Interoperability and Patient Access
proposed rule, we discussed these concepts generally and how they were
applicable in the health care context for all payers, and explained how
these were relevant to our specific proposals, which are discussed in
detail in section III. of this final rule. To revisit this full
discussion, see the proposed rule (84 FR 7620 through 7621). We did not
receive comments on this general discussion. Any comments on specific
proposals that refer to these three attributes are discussed in this
final rule in the context of the specific proposals.
2. Privacy and Security Concerns in the Context of APIs
As we noted in the CMS Interoperability and Patient Access proposed
rule, HHS has received a wide range of stakeholder feedback on privacy
and security issues in response to prior proposals \11\ about policies
related to APIs that would allow consumers to use an app of their
choosing to access protected health information (PHI) held by or on
behalf of a HIPAA covered entity. Such feedback included concerns about
potential security risks to PHI created by an API connecting to third-
party applications and the implications of an individual's data being
shared with these third-party apps at the direction of the individual.
---------------------------------------------------------------------------
\11\ For instance, see discussion of stakeholder comments in the
2015 Edition final rule at 80 FR 62676.
---------------------------------------------------------------------------
As we discussed in our Interoperability and Patient Access proposed
rule (84 FR 7621), deploying API technology would offer consumers the
opportunity to access their electronic health information held by
covered entities (including, but not limited to MA organizations, the
Medicare Part A and B programs, the Medicaid program, CHIP, QHP issuers
on the FFEs, and other health insurance issuers in the private
markets), and would not lessen any such covered entity's duties under
HIPAA and other laws to protect the privacy and security of information
it creates, receives, maintains, or transmits, including but not
limited to PHI. A covered entity implementing an API to enable
individuals to access their health information must take reasonable
steps to ensure an individual's information is only disclosed as
permitted or required by applicable law. The entity must take greater
care in configuring and maintaining the security functionalities of the
API and the covered entities' electronic information systems to which
it connects than would be needed if it was implementing an API simply
to allow easier access to widely available public information. In
accordance with the HIPAA Privacy and Security Rules, the covered
entity is required to implement reasonable safeguards to protect PHI
while in transit. If an individual requests their PHI in an EHR be sent
to the third party by unencrypted email or in another unsecure manner,
which the individual has a right to request, reasonable safeguards
could include, for example, carefully checking the individual's email
address for accuracy and warning the individual of risks associated
with the unsecure transmission. We note that the standards-based APIs
discussed in this final rule are secure methods of data exchange.
HIPAA covered entities and their business associates continue to be
responsible for compliance with the HIPAA Rules, the Federal Trade
Commission Act (FTC Act), and all other laws applicable to their
business activities including but not limited to their handling of
enrollees' PHI and other data. As we stated in the CMS Interoperability
and Patient Access proposed rule (84 FR 7610), nothing proposed in that
rule was intended to alter or should be construed as altering existing
responsibilities to protect PHI under the HIPAA Rules or any other laws
that are currently applicable.
However, we acknowledged that a number of industry stakeholders may
mistakenly believe that they are responsible for determining whether an
application to which an individual directs their PHI employs
appropriate safeguards regarding the information it receives. In the
proposed rule we discussed Office for Civil Rights (OCR) guidance that
noted that covered entities are not responsible under the HIPAA Rules
for the security of PHI once it has been received by a third-party
application chosen by an individual (84 FR 7621 through 7622).
Further, we noted in the CMS Interoperability and Patient Access
proposed rule that the HIPAA Privacy Rule \12\ established the
individual's right of access, including a right to inspect
[[Page 25517]]
and/or receive a copy of PHI held in designated record sets by covered
entities and their business associates as detailed at 45 CFR 164.524.
We specifically noted in the proposed rule that OCR had indicated in
regulations and guidance, that an individual could exercise their right
of access by requesting that their information be sent to a third
party.\13\
---------------------------------------------------------------------------
\12\ More information on the Privacy Rule, including related
rulemaking actions and additional interpretive guidance, is
available at https://www.hhs.gov/hipaa/for-professionals/privacy/index.html.
\13\ See 45 CFR 164.524(c)(2) and (3), and 164.308(a)(1), OCR
HIPAA Guidance/FAQ-2036: https://www.hhs.gov/hipaa/for-professionals/faq/2036/can-an-individual-through-the-hipaa-right/index.html, and OCR HIPAA Guidance/FAQ-2037: https://www.hhs.gov/hipaa/for-professionals/faq/2037/are-there-any-limits-or-exceptions-to-the-individuals-right/index.html.
---------------------------------------------------------------------------
As we also noted in the proposed rule (84 FR 7622), we are aware of
stakeholder concerns about which protections apply to non-covered
entities, such as direct-to-consumer applications. As we explained in
the proposed rule, when a non-covered entity discloses an individual's
confidential information in a manner or for a purpose not consistent
with the privacy notice and terms of use to which the individual
agreed, the FTC has authority under section 5 of the FTC Act (15 U.S.C.
Sec. 45(a)) to investigate and take action against unfair or deceptive
trade practices. The FTC has applied this authority to a wide variety
of entities.\14\ The FTC also enforces the FTC Health Breach
Notification Rule, which applies to certain types of entities,
including vendors of personal health records and third-party service
providers, that fall outside of the scope of HIPAA, and therefore, are
not subject to the HIPAA Breach Notification Rule.\15\ This FTC Health
Breach Notification Rule explains the process and steps third parties
must follow when they discover a breach of identifiable personal health
record information they maintain. Any violation of this Rule is
enforced by the FTC as an unfair or deceptive act or practice under the
FTC Act.
---------------------------------------------------------------------------
\14\ See also cases where this authority was used, such as 2012
FTC action against Facebook (see https://www.ftc.gov/enforcement/cases-proceedings/092-3184/facebook-inc) and 2012 FTC action against
MySpace (see https://www.ftc.gov/enforcement/cases-proceedings/102-3058/myspace-llc-matter).
\15\ See 16 CFR part 318; see also https://www.healthit.gov/sites/default/files/non-covered_entities_report_june_17_2016.pdf.
---------------------------------------------------------------------------
We recognized that this is a complex landscape for patients, who we
anticipate will want to exercise due diligence on their own behalf in
reviewing the terms of service and other information about the
applications they consider selecting. Therefore, we proposed specific
requirements on payers to ensure enrollees have the opportunity to
become more informed about how to protect their PHI, important things
to consider in selecting an application, and where they can submit a
complaint if they believe a HIPAA covered entity or business associate
may not be in compliance with their duties under the HIPAA Rules, or if
they believe they have been subjected to unfair or deceptive acts or
practices related to a direct-to-consumer application's privacy
practices or terms of use. A full discussion of the Enrollee and
Beneficiary Resources Regarding Privacy and Security provision can be
found in section III.C.2.h. of this final rule.
In some circumstances, we noted that the information that we
proposed to require be made available through an API per a patient's
request, under the various program-specific authorities authorizing
this rulemaking, were also consistent with the enrollee's right of
access for their data held by a covered entity or their business
associate under the HIPAA Privacy Rule. But we also noted that some
data to which an individual is entitled to access under HIPAA may not
be required to be transferred through the API. For instance, when the
covered entity does not hold certain information electronically. In
those instances, we noted that the inability to access data via an API
would in no way limit or alter responsibilities and requirements under
other law (including though not limited to the HIPAA Privacy, Security,
and Breach Notification Rules) that apply to the organizations that
would be subject to this regulation. Even as these requirements are
finalized, the organization may still be called upon to respond to
individuals' request for information not available through the API, or
for all of their information through means other than the API. We
encouraged HIPAA covered entities and business associates to review the
OCR website for resources on the individual access standard at https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html
to ensure they understand their responsibilities.
We again encourage HIPAA covered entities and business associates
to review their responsibilities under HIPAA in light of the recent
decision in Ciox Health, LLC v. Azar, et al., No. 18-cv-0040 (D.D.C.
January 23, 2020).\16\ The court order vacates a portion of the HIPAA
Privacy Rule related to the individual right of access ``insofar as it
expands the HITECH Act's third-party directive beyond requests for a
copy of an electronic health record with respect to [protected health
information] of an individual . . . in an electronic format.'' \17\
Generally, the court order vacates a portion of the HIPAA Privacy Rule
that provides an individual the right to direct a covered entity to
send protected health information that is not in an EHR to a third
party identified by the individual.
---------------------------------------------------------------------------
\16\ See, https://ecf.dcd.uscourts.gov/cgi-bin/show_public_doc?2018cv0040-51.
\17\ See, https://hds.sharecare.com/wp-content/uploads/2020/01/CiOX-Health-v.-HHS-Court-Order-3-24-2020.pdf.
---------------------------------------------------------------------------
This decision does not affect CMS' programmatic authorities, as
discussed in detail in section III. of the CMS Interoperability and
Patient Access proposed rule (83 FR 7629 through 7630) and section III.
of this final rule, to propose and finalize the Patient Access API for
the programs specified. Additionally, the court's decision did not
alter individuals' right under HIPAA to request and obtain a copy of
their records. Because the goal of the Patient Access API in our
programs is to give patients access to their own information for their
own personal use through a third-party app, we believe these policies
as adopted in this rule remain consistent with the spirit of access
rights under HIPAA.
As discussed in detail below, many commenters discussed the issues
of privacy and security in regard to information made available to
third-party applications. Here, we summarize the public comments we
received on general issues and concerns around privacy and security of
a standards-based API, and provide our responses.
Comment: A few commenters supported OCR's efforts to more clearly
account for use cases, or specific situations, in which apps are used
to exchange patients' electronic health information. Some commenters
noted support for OCR's FAQ that specifies that covered entities are
not responsible or liable for the privacy and security of PHI once it
is transmitted at the individual's direction to and received by a
third-party application. One commenter expressed concern that CMS and
ONC proposed requirements would make the safeguards of HIPAA moot if
HIPAA is not extended to third-party applications that are able under
this rule to display patient data. Without extending HIPAA, the
commenter fears payers and providers will be liable if the third-party
misuses patient data.
Response: We appreciate the commenters' support. We reiterate that
HIPAA covered entities and business associates are responsible for
meeting their HIPAA privacy and security obligations to protect patient
data they
[[Page 25518]]
maintain, and absent patient requests to the contrary, are obligated to
take reasonable measures to protect these data in transit. Once these
data are transmitted and no longer under the control of the covered
entity or business associate, those entities no longer have any
obligations under HIPAA for the privacy and security of the PHI,
because these data are no longer subject to HIPAA. We stress, as
discussed in the CMS Interoperability and Patient Access proposed rule,
nothing in this rule alters covered entities' or business associates'
responsibilities to protect PHI under the HIPAA Privacy and Security
Rules.
The only instance per the policies proposed in this rule that would
allow a payer to deny access to an app, as discussed in the proposed
rule and underlying the rationale for finalizing 42 CFR 422.119(e),
431.60(e), 438.242(b)(6) (redesignated as Sec. 438.242(b)(5) see
section VI. in this rule), 457.730(e), 457.1233(d)(2), and 45 CFR
156.221(e), would be if the covered entity or its business associate's
own systems would be endangered if it were to engage with a specific
third-party application through an API, for instance if allowing such
access would result in an unacceptable security risk. Therefore, as we
also noted, covered entities and business associates are free to offer
advice to patients on the potential risks involved with requesting data
transfers to an application or entity not covered by HIPAA, but such
efforts generally must stop at education and awareness or advice
regarding concerns related to a specific app. For instance, if a payer
notes that an app a patient requests receive their data does not lay
out in its privacy policy specifically how the patient's personal data
will be used, the payer could choose to inform the patient they may not
want to share their data with that app without a clear understanding of
how the app may use the data, including details about the app's
secondary data use policy. If the patient still wants their data to be
shared, or does not respond to the payer's warning, the payer would
need to share these data via the API absent an unacceptable security
risk to the payer's own system. For more information on this ability to
inform patients, see section III.C.2.g. of this final rule. The
requirements finalized in this rule do not impact or change obligations
under the HIPAA Privacy and Security Rules in any way.
Comment: A few commenters noted discrepancies in the terminology
used in the OCR FAQ mentioned in the CMS Interoperability and Patient
Access proposed rule compared to terminology used throughout the CMS
Interoperability and Patient Access proposed rule and the ONC 21st
Century Cures Act proposed rule, and suggested that any terminology
inconsistencies be addressed and harmonized. These commenters noted
that the OCR FAQ pertains to ``electronic protected health
information'' (ePHI), and uses the term ``electronic health record
(EHR) system developer'', which differs from terms used in the CMS
Interoperability and Patient Access and the ONC 21st Century Cures Act
proposed rules.
Response: We appreciate comments regarding variance in the
terminology used in OCR guidance and the CMS Interoperability and
Patient Access proposed rule. Regarding the relationship between ePHI
and electronic health information (EHI), we refer readers to the
discussion in the ONC 21st Century Cures Act final rule (published
elsewhere in this issue of the Federal Register). OCR guidance uses the
term ``electronic health record system developer'' \18\ to refer to a
health IT developer that develops and maintains electronic health
record systems containing PHI for a covered entity, and therefore is a
business associate of those covered entities. The guidance also uses
``app developer'' to describe the creator of the app that is designated
to receive an individual's PHI. ONC uses related terms that have a
specific meaning within the context of ONC programs. For instance, ONC
uses the term ``health IT developer'' for the purposes of the ONC
Health IT Certification Program to refer to a vendor, self-developer,
or other entity that presents health IT for certification or has health
IT certified under the program. In addition, the ONC 21st Century Cures
Act proposed rule proposed to define the term ``health IT developer of
certified health IT'' for the purposes of implementing provisions of
the Cures Act (84 FR 7510). We do not use these ONC program-specific
terms in this CMS rule. We simply refer to any developer of a third-
party app, of which an electronic record systems developer may be one.
---------------------------------------------------------------------------
\18\ See Office of the National Coordinator. (n.d.). Health
Information Technology. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/health-information-technology/index.html.
---------------------------------------------------------------------------
Comment: One commenter requested clarification on a covered
entity's liability under HIPAA if a patient transfers their health
information from a covered entity's mobile access portal or application
to a third-party application not covered under HIPAA.
Response: As noted above, HIPAA covered entities and business
associates are responsible for meeting their HIPAA privacy and security
obligations to protect patient data they maintain, and absent patient
requests to the contrary, are obligated to take reasonable measures to
protect these data in transit. Once these data are received by a third-
party and no longer under the control of the covered entity or its
business associate, the covered entity and business associate are not
liable for the privacy and security of the PHI or any electronic health
information sent. While HIPAA covered entities and their business
associates may notify patients of their potential concerns regarding
exchanging data with a specific third-party not covered by HIPAA, they
are not required to do so, and they may not substitute their own
judgment for that of the patient requesting the data be transferred.
Comment: Several commenters recommended that CMS include a safe
harbor provision in the regulatory text of this final rule to indicate
that plans and providers are not responsible for the downstream privacy
and security of PHI.
Response: Regarding commenters' interest in a ``safe harbor''
provision for covered entities when data is transmitted to a third-
party app, we do not have the authority, nor do we believe it is
necessary, to incorporate these principles in a safe harbor provision
under the HIPAA Privacy and Security Rules. Covered entities and
business associates are not responsible for the data after the data
have been received by the intended recipient. This has been taken into
account in developing the requirements for the Patient Access API.
Comment: Several commenters expressed concerns that app developers
are not subject to many of the current laws protecting the privacy and
security of electronic health information. Several commenters requested
that HHS specify what requirements non-HIPAA covered app developers
will be subject to.
Response: We appreciate the commenters' concerns. As discussed in
the CMS Interoperability and Patient Access proposed rule (84 FR 7622),
HIPAA protections do not extend to third-party apps (that is, software
applications from entities that are not covered entities or business
associates). However, the FTC has the authority to investigate and take
action against unfair or deceptive trade practices under the FTC Act
and the FTC Health Breach Notification Rule when a third-party app does
not adhere to the stated privacy policy. We have shared these comments
with the FTC. State laws may provide additional protections as well.
[[Page 25519]]
Although CMS cannot regulate the third-party apps directly, and thus
cannot establish specific requirements for them, we are sharing best
practices and lessons learned from our experience with Blue Button 2.0,
as applicable, with app developers to further support strong privacy
and security practices: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Also, as previously noted, payers will
be required to share educational resources with patients regarding how
to choose a third-party application while protecting their health
information. Further, as discussed in section III. of this final rule,
we are providing payers with a framework they can use to request that
third-party apps attest to covering certain criteria in their privacy
policy, such as information about secondary data use, which payers can
use to educate patients about their options.
In addition, there are technical requirements for APIs defined in
the ONC 21st Century Cures Act proposed rule, and finalized by HHS in
ONC's final rule (published elsewhere in this issue of the Federal
Register) at 45 CFR 170.215, that enable and support persistent user
authentication and app authorization processes. It is important to
clarify that any app accessing the Patient Access API would be doing so
only with the approval and at the direction of the specific patient.
While these technical standards at 45 CFR 170.215 establish the
requirements for the API itself, when implemented, these technical
standards in turn set requirements on the app developer for the app's
identity proofing and authentication processes that must be met in
order to connect to the API and access the specific patient's data
through the API, as further discussed in section III. of this final
rule. These technical requirements do not, however, address concerns
around data security and use once data are with the third-party. This
level of privacy and security would be addressed in the app's terms and
conditions or privacy notice.
Comment: Many commenters expressed concern regarding the secondary
use of health information by business partners of third-party
applications. A few commenters noted that consumers may not always be
aware of the business partners of third-party apps, especially as this
information is typically part of a lengthy privacy notice or dense or
difficult to understand terms and conditions.
Response: We appreciate the commenters' concerns. As noted, we do
not have the authority to directly regulate third-party apps. As a
result, we cannot dictate how an app uses or shares data. We have
chosen to require payers to educate patients about how to choose a
third-party app that best mitigates potentially risks related to
secondary data uses. One way we will address these concerns is to offer
payers and app developers best practices from our own experiences using
a patient-centered privacy policy, particularly related to Blue Button
2.0. As we discuss in section III.C.2.h. of this final rule, we
recognize that the payers that will be subject to the API provisions of
this final rule are in the best position to ensure that patients have
the information that they need to critically assess the privacy and
security of their designated third-party options, and may be best
situated to identify for patients the potential implications of sharing
data and to advise a patient if there is a breach of their data. This
is why we proposed and are finalizing a requirement at 42 CFR
422.119(g), 431.60(f), 457.730(f), 438.242(b)(5) (proposed as Sec.
438.242(b)(6) see section VI. in this rule), and 457.1233(d)(2), and 45
CFR 156.221(g), detailing the beneficiary and enrollee resources
regarding consumer-friendly, patient facing privacy and security
information that must be made available on the websites of the payers
subject to this final rule. As discussed in greater detail in section
III.C.2.h. of this final rule, CMS will be providing payers with
suggested content they can consult and tailor as they work to produce
the required patient resource document. We are also sharing best
practices and links to model language of an easy-to-understand, non-
technical, consumer-friendly privacy policy, again building off of our
lessons learned with Blue Button 2.0, to support payers and developers
in this effort: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Also, as noted above, we discuss in section
III. of this final rule, a framework payers can use to request that
third-party apps attest to covering certain criteria in their privacy
policy, such as information about secondary data use. It will be
important to encourage patients' understanding of app privacy policies,
including secondary use policies. The policies we are finalizing in
this rule help us support payers and developers as they work to make
sure patients are informed consumers through education and awareness,
and that patients understand their rights.
Comment: Several commenters expressed concerns over the complexity
of overlapping federal and state privacy laws, which they noted would
be perpetuated by uncertainty in privacy and security requirements when
apps become more widely used in the health care space. These commenters
requested work be done to harmonize state and federal privacy laws.
Another commenter recommended that Congress enact comprehensive
consumer privacy protections.
Response: We appreciate these commenters' concerns and
recommendations. However, these comments are beyond the scope of this
regulation.
Comment: Several commenters recommended that CMS work closely with
other HHS agencies and the FTC to establish a transparent regulatory
framework for safeguarding the privacy and security of patient
electronic health information shared with apps. A few commenters
recommended CMS establish workgroups to share experiences and technical
assistance for implementing privacy and security approaches.
Response: We appreciate the commenters' suggestions. As noted
above, we have shared commenter's concerns with the FTC and relevant
HHS Operating Divisions, such as OCR.
3. Specific Technical Approach and Standards
Achieving interoperability throughout the health system is
essential to achieving an effective, value-conscious health system
within which consumers are able to choose from an array of health plans
and providers. An interoperable system should ensure that consumers can
both easily access their electronic health information held by plans
and routinely expect that their claims, encounter, and other relevant
health history information will follow them smoothly from plan to plan
and provider to provider without burdensome requirements for them or
their providers to reassemble or re-document the information. Ready
availability of health information can be especially helpful when an
individual cannot access their usual source of care, for instance if
care is needed outside their regular provider's business hours, while
traveling, or in the wake of a natural disaster.
The proposals described in section III.C.2. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7628 through
7639) would impose new requirements on MA organizations, Medicaid and
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs (excluding issuers offering only
SADPs or issuers in the FF-SHOP,
[[Page 25520]]
unless otherwise noted) to implement standardized, transparent APIs.
Using the API, these entities would be required to provide current
enrollees with specified claims and encounter data and certain clinical
information if such information is maintained. We proposed that these
entities would also be required to make available through the API
information already required to be widely available, including provider
directory and plan coverage information, such as formulary information.
In developing the proposal delineating the information that would be
required to be made available through an API, consistent with the
proposed technical requirements, we were guided by an intent to have
available through the API all of the individual's electronic health
information held by the payer in electronic format that is compatible
with the API or that can, through automated means, be formatted to be
accurately rendered through the API. We were also guided by an intent
to make available through standardized, secure API technology all of
the provider directory and formulary information maintained by the
impacted payers that can be made compatible with the API.
Both the API technology itself and the data it makes available must
be standardized to support true interoperability. Therefore, as
discussed in detail in the proposed rule, we proposed to require
compliance with both (1) ONC's 21st Century Cures Act rule proposed
regulations regarding content and vocabulary standards for representing
electronic health information as finalized and (2) technical standards
for an API by which the electronic health information would be required
to be made available as finalized. For the proposals described in
section III.C.2.b. of the CMS Interoperability and Patient Access
proposed rule (which addressed transmissions for purposes other than
those covered by HIPAA transaction standards, with which all the payers
subject to this final rule will continue to be required to comply under
45 CFR part 162), we proposed requiring compliance with the
interoperability standards proposed for HHS adoption in the ONC 21st
Century Cures Act proposed rule (84 FR 7424) as finalized.
In proposing to require that regulated entities comply with ONC-
proposed regulations for non-HIPAA covered transactions (84 FR 7424)
and therefore, requiring the use of specified standards, we noted that
we intended to preclude regulated entities from implementing API
technology using alternative technical standards to those ONC proposed
for HHS adoption at 45 CFR 170.215, which details the API technical
standards, including the use of FHIR. Other technical standards that
would be precluded include, but are not limited to, those not widely
used to exchange electronic health information in the U.S. health
system. We further noted that we intended to preclude entities from
using earlier versions of the technical standards adopted at 45 CFR
170.215 by requiring compliance with only specified provisions of 45
CFR part 170, and deliberately excluding others. We also discussed how
by proposing to require use of the proposed content and vocabulary
standards as finalized by requiring compliance with 42 CFR 423.160 and
45 CFR part 162, and proposed at 45 CFR 170.213, we intended to
prohibit use of alternative standards that could potentially be used
for these same data classes and elements, as well as earlier versions
of the adopted standards named in 42 CFR 423.160, 45 CFR part 162, and
proposed at 45 CFR 170.213.
While we generally intended to preclude regulated entities from
using content and vocabulary standards other than those described in 42
CFR 423.160, 45 CFR part 162, or proposed 45 CFR 170.213 (and technical
standards at 45 CFR 170.215), we recognized there may be circumstances
that render the use of other content and vocabulary alternatives
necessary. As discussed below, we proposed to allow the use of
alternative content and vocabulary standards in two circumstances.
First, where other content or vocabulary standards are expressly
mandated by applicable law, we proposed to permit use of those other
mandated standards. Second, where no appropriate content or vocabulary
standard exists within 45 CFR part 162, 42 CFR 423.160, or proposed 45
CFR 170.213 and 170.215, we proposed we would permit use of any
suitable gap-filling options, as may be applicable to the specific
situation.
We used two separate rulemakings because the 21st Century Cures Act
proposed rule (84 FR 7424), which included API interoperability
standards proposed for HHS adoption, would have broader reach than the
scope of the CMS Interoperability and Patient Access proposed rule (84
FR 7610). At the same time, we wished to assure stakeholders that the
API standards required of MA organizations, state Medicaid agencies,
state CHIP agencies, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs under the proposal would be
consistent with the API standards proposed by ONC for HHS adoption
because we would require that the regulated entities follow specified,
applicable provisions of the ONC-proposed requirements as finalized.
Requiring that CMS-regulated entities comply with the regulations
regarding standards finalized by HHS in ONC's 21st Century Cures Act
rule will support greater interoperability across the health care
system, as health IT products and applications that would be developed
for different settings and use cases would be developed according to a
consistent base of standards that supports more seamless exchange of
information. In the CMS Interoperability and Patient Access proposed
rule, we welcomed public comment on our proposal to require compliance
with the standards proposed for adoption by HHS through ONC's 21st
Century Cures Act proposed rule, as well as on the best method to
provide support in identifying and implementing the applicable content
and vocabulary standards for a given data element.
Finally, while noting that we believed that the proposal to require
compliance with the standards proposed by ONC for HHS adoption was the
best approach, we sought public comment on any alternative by which CMS
would separately adopt the standards proposed for adoption in the ONC
21st Century Cures Act proposed rule and identified throughout the CMS
Interoperability and Patient Access proposed rule, as well as future
interoperability, content, and vocabulary standards. We stated that we
anticipated any alternative would include incorporating by reference
the FHIR R2, R3, and/or R4 based on comments and OAuth 2.0 technical
standards and the USCDI version 1 content and vocabulary standard
(described in sections II.A.3.b. and II.A.3.a. of the CMS
Interoperability and Patient Access proposed rule, respectively) in CMS
regulation to replace the proposed references to ONC regulations at 45
CFR 170.215, 170.213, and 170.205, respectively. However, we
specifically sought comment on whether this alternative would present
an unacceptable risk of creating multiple regulations requiring
standards or versions of standards across HHS' programs, and an
assessment of the benefits or burdens of separately adopting new
standards and incorporating updated versions of standards in CFR text
on a program by program basis. Furthermore, we sought comment on: How
such an option might impact health IT development timelines; how
potentially creating multiple regulations regarding standards over time
across HHS might impact system implementation; and other
[[Page 25521]]
factors related to the technical aspect of implementing these
requirements.
We summarize the public comments we received regarding separately
adopting standards in this CMS rule and provide our responses.
Comment: Many commenters supported CMS' proposed alignment with the
standards proposed in ONC's 21st Century Cures Act proposed rule to be
adopted by HHS to promote interoperability, noting it was the most
effective and efficient approach. Commenters explained that this
alignment was critical to ensure interoperability across the health
care industry, and overwhelmingly preferred ``one source of truth'' for
all standards referenced in the CMS Interoperability and Patient Access
proposed rule. These commenters explained having highly technical
standards, including content and vocabulary standards, in different CMS
and ONC regulations would create the potential for error and
misalignment of standards or versions of standards across HHS programs.
Commenters supported alignment across agencies, and indicated concern
that if the standards were adopted in different regulations, it would
complicate the process of updating the standards when necessary, and
increase the cost and burden of data capture, data management, and data
exchange. Commenters did note opportunities for even greater alignment
across the CMS and ONC rulemakings at the data element level,
indicating that the ONC rule should include all data elements required
in the CMS rule, specifically calling out data elements in an
Explanation of Benefits (EOB) not specifically included in the USCDI
(proposed for codification at 45 CFR 170.213).
Response: We appreciate the commenters' support for alignment of
the regulations adopted in this final rule with the standards as
finalized by HHS in the ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register). We agree
that the best way to ensure continued alignment is to have the
regulations we are adopting here--governing MA organizations, state
Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs,
CHIP managed care entities, and QHP issuers on the FFEs--cross
reference the specific regulations codifying the standards adopted by
HHS in the ONC 21st Century Cures Act final rule. Our intent is to
ensure alignment and consistent standards across the regulated
programs. We agree that this will help support interoperability across
the health care industry and help set clear and consistent goals for
all payers, providers, vendors, and developers. CMS and ONC will
continue to coordinate closely on standards, including content and
vocabulary standards and impacted data elements and use cases, and we
will continue to work closely with all stakeholders to ensure that this
process is consensus-based. Regarding the recommendation to add data
elements from the EOB not yet included in the USCDI, we have shared
these recommendations with ONC, and we refer readers to the discussion
in ONC's 21st Century Cures Act final rule on the USCDI and the
Standards Version Advancement Process (published elsewhere in this
issue of the Federal Register).
B. Content and Vocabulary Standards
The content and vocabulary standards HHS ultimately adopts
applicable to the data provided through the standards-based API will,
by necessity, vary by use case and within a use case. For instance,
content and vocabulary standards supporting consumer access vary
according to what specific data elements MA organizations, Medicaid and
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs have available electronically.
Where another law does not require use of a specific standard, we
proposed to require use of, in effect, a catalogue of content and
vocabulary standards from which the regulated entities may choose in
order to satisfy the proposed requirements in 42 CFR 422.119, 431.60,
457.730, 438.252, and 457.1233, and 45 CFR 156.221. A further
discussion of these proposals can be found in section II.B. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7623 through
7624). These proposals are detailed in section III.C.2.b. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7626 through
7639), and comments received on these proposals are summarized with our
responses in section III.C.2.b. of this final rule. Specifically, we
note that we proposed to adopt the content and vocabulary standards as
finalized by HHS in ONC's 21st Century Cures Act final rule (published
elsewhere in this issue of the Federal Register) at 45 CFR 170.213.
This standard is currently the USCDI version 1.
C. Application Programming Interface (API) Standard
In section III.C.2.b. of the CMS Interoperability and Patient
Access proposed rule, we proposed to require compliance with the API
technical standard proposed by ONC for HHS adoption at 45 CFR 170.215
as finalized (84 FR 7589). By requiring compliance with 45 CFR 170.215,
we proposed to require use of the foundational Health Level 7[supreg]
(HL7) \19\ Fast Healthcare Interoperability Resources[supreg] (FHIR)
standard,\20\ several implementation specifications specific to FHIR,
and complementary security and app registration protocols, specifically
the Substitutable Medical Applications, Reusable Technologies (SMART)
Application Launch Implementation Guide (IG) 1.0.0 (including mandatory
support for ``refresh tokens,'' ``Standalone Launch,'' and ``EHR
Launch'' requirements), which is a profile of the OAuth 2.0
specification, as well as the OpenID Connect Core 1.0 standard,
incorporating errata set 1. A further discussion of these proposals can
be found in section II.C. (84 FR 7624 through 7625) and the proposals
are detailed in section III. of the CMS Interoperability and Patient
Access proposed rule (84 FR 7626 through 7639). Comments received on
these proposals are summarized with our responses in section III. of
this final rule.
---------------------------------------------------------------------------
\19\ Health Level Seven International[supreg] (HL7) is a not-
for-profit, ANSI-accredited standards development organization (SDO)
focused on developing consensus standards for the exchange,
integration, sharing, and retrieval of electronic health information
that supports clinical practice and the management, delivery and
evaluation of health services. Learn more at ``About HL7'' web page,
last accessed 06/27/2018.
\20\ FHIR Overview. (n.d.). Retrieved from https://www.hl7.org/fhir/overview.html.
---------------------------------------------------------------------------
We proposed to adopt the technical standards as finalized by HHS in
the ONC 21st Century Cures Act final rule (published elsewhere in this
issue of the Federal Register) at 45 CFR 170.215. HHS is finalizing
adoption of HL7 FHIR Release 4.0.1 as the foundational standard for
APIs at 45 CFR 170.215(a)(1). Instead of the Argonaut IG and server to
support exchange of the USCDI proposed at 45 CFR 170.215(a)(3) and
(a)(4) (84 FR 7424), HHS is finalizing the HL7 FHIR US Core IG STU
3.1.0 at 45 CFR 170.215(a)(2). The HL7 SMART Application Launch
Framework IG Release 1.0.0 was proposed at 45 CFR 170.215(a)(5) (84 FR
7424). HHS is finalizing the HL7 SMART Application Launch Framework IG
Release 1.0.0 (which is a profile of the OAuth 2.0 specification),
including mandatory support for the ``SMART on FHIR Core
Capabilities,'' at 45 CFR 170.215(a)(3). HHS is finalizing as proposed
adoption of OpenID Connect Core 1.0, incorporating errata set 1 at 45
CFR 170.215(b), as well as adoption of version 1.0.0: STU 1 of the FHIR
Bulk Data Access specification at 45 CFR
[[Page 25522]]
170.215(a)(4). HHS is not finalizing the adoption of FHIR Release 2 or
FHIR Release 3, API Resource Collection in Health (ARCH) Version 1, or
the HL7 Consent2Share FHIR Consent Profile Design that were proposed at
45 CFR 170.215(a)(1), (c)(1), (a)(2), or (c)(2), respectively (84 FR
7424). For a full discussion, see the ONC 21st Century Cures Act final
rule (published elsewhere in this issue of the Federal Register). The
content and vocabulary standards and technical standards finalized by
HHS in the ONC 21st Century Cures Act final rule provide the foundation
needed to support implementation of the policies as proposed and now
finalized in this rule.
D. Updates to Standards
In addition to efforts to align standards across HHS, we recognized
in the proposed rule that while we must codify in regulation a specific
version of each standard, the need for continually evolving standards
development has historically outpaced our ability to amend regulatory
text. To address how standards development can outpace our rulemaking
schedule, we proposed in section III.C.2.b. of the CMS Interoperability
and Patient Access proposed rule (84 FR 7630 through 7631) that
regulated entities may use updated versions of required standards if
use of the updated version is required by other applicable law. In
addition, under certain circumstances, we proposed to allow use of an
updated version of a standard if the standard is not prohibited under
other applicable law.
For content and vocabulary standards at 45 CFR part 162 or 42 CFR
423.160, we proposed to allow the use of an updated version of the
content or vocabulary standard adopted under rulemaking, unless the use
of the updated version of the standard: Is prohibited for entities
regulated by that part or the program under that section; Is prohibited
by the Secretary for purposes of these policies or for use in ONC's
Health IT Certification Program; or is precluded by other applicable
law. We remind readers that other applicable law includes statutes and
regulations that govern the specific entity. For the content and
vocabulary standards proposed by ONC for HHS adoption at 45 CFR 170.213
(84 FR 7589) (currently, USCDI version 1),\21\ as well as for API
technical standards proposed by ONC for HHS adoption at 45 CFR 170.215
(84 FR 7589) (including HL7 FHIR and other standards and implementation
guides (IGs) as discussed above),\22\ we proposed to allow the use of
an updated version of a standard adopted by HHS, provided such updated
version has been approved by the National Coordinator through the
Standards Version Advancement Process described in the ONC 21st Century
Cures Act proposed rule (84 FR 7424), as finalized. A further
discussion of these proposals can be found in section II.D. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7625 through
7626). These proposals are also detailed in section III. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7626 through
7639), and comments received on these proposals are summarized with our
responses in section III. of this final rule.
---------------------------------------------------------------------------
\21\ For more information on the USCDI, see https://www.healthit.gov/USCDI.
\22\ For more information on FHIR, see https://www.hl7.org/fhir/overview.html.
---------------------------------------------------------------------------
III. Provisions of Patient Access Through APIs, and Analysis of and
Responses to Public Comments
A. Background on Medicare Blue Button
As discussed in the CMS Interoperability and Patient Access
proposed rule (84 FR 7626), we are committed to advancing
interoperability, putting patients at the center of their health care,
and ensuring they have simple and easy access, without special effort,
to their health information. With the establishment of the initial
Medicare Blue Button[supreg] service in 2010, Medicare beneficiaries
became able to download their Part A, Part B, and Part D health care
claims and encounter data through MyMedicare.gov in either PDF or text
format. While the original Blue Button effort was a first step toward
liberating patient health information, we recognized that significant
opportunities remain to modernize access to that health information and
the ability to share health information across the health ecosystem. We
believe that moving to a system in which patients have access to and
use of their health information will empower them to make better
informed decisions about their health care. Additionally,
interoperability, and the ability for health information systems and
software applications to communicate, exchange, and interpret health
information in a usable and readable format, is vital to improving
health care. Allowing access to health information only through PDF and
text formats limit the utility of and the ability to effectively share
the health information.
Medicare Blue Button 2.0 is a new, modernized version of the
original Blue Button service. It enables beneficiaries to access their
Medicare Parts A, B, and D claims and encounter data and share that
electronic health information through an Application Programming
Interface (API) with applications, services, and research programs they
select. As discussed in section II.A. of the CMS Interoperability and
Patient Access proposed rule (see 84 FR 7618 through 7623), API
technology allows software from different developers to connect with
one another and exchange electronic health information in electronic
formats that can be more easily compiled and leveraged by patients and
their caregivers. Beneficiaries may also select third-party
applications to compile and leverage their electronic health
information to help them manage their health and engage in a more fully
informed way in their health care.
Today, Blue Button 2.0 contains 4 years of Medicare Part A, B, and
D data for 53 million Medicare beneficiaries. These data are available
to patients to help them make more informed decisions. Beneficiaries
dictate how their data can be used and by whom, with identity and
authorization controlled through MyMedicare.gov. Medicare beneficiaries
can authorize sharing their information with an application using their
MyMedicare.gov account information. Beneficiaries authorize each
application, service, or research program they wish to share their data
with individually. A beneficiary can go back to MyMedicare.gov at any
time and change the way an application uses their information. Using
Blue Button 2.0, beneficiaries can access their health information;
share it with doctors, caregivers, or anyone they choose; and get help
managing and improving their health through a wide range of apps and
other computer-based services. Blue Button 2.0 is an optional service--
beneficiaries choose the apps and services they want to use.
Today, Medicare beneficiaries using Blue Button 2.0 can connect
with apps that keep track of tests and services they need and receive
reminders, track their medical claims, make appointments and send
messages to their doctors, get personalized information about their
symptoms and medical conditions, find health and drug plans, keep track
of their medical notes and questions, and connect to research
projects.\23\ These are
[[Page 25523]]
just some of the ways Blue Button 2.0 is using a standards-based, FHIR-
enabled API to lead the charge and unleash the power of health data.
---------------------------------------------------------------------------
\23\ To review a list of apps currently available to Blue Button
2.0 users, visit https://www.medicare.gov/manage-your-health/medicares-blue-button-blue-button-20/blue-button-apps.
---------------------------------------------------------------------------
B. Expanding the Availability of Health Information
1. Patient Benefits of Information Access
As discussed in the CMS Interoperability and Patient Access
proposed rule, we believe there are numerous benefits associated with
individuals having simple and easy access to their health care data
under a standard that is widely used. Whereas EHR data are frequently
locked in closed, disparate health systems, care and treatment
information in the form of claims and encounter data is comprehensively
combined in a patient's claims and billing history. Claims and
encounter data, used in conjunction with EHR data, can offer a broader
and more holistic understanding of an individual's interactions with
the health care system than EHR data alone. As one example,
inconsistent benefit utilization patterns in an individual's claims
data, such as a failure to fill a prescription or receive recommended
therapies, can indicate that the individual has had difficulty
financing a treatment regimen and may require less expensive
prescription drugs or therapies, additional explanation about the
severity of their condition, or other types of assistance. Identifying
and finding opportunities to address the individual's non-adherence to
a care plan are critical to keeping people with chronic conditions
healthy and engaged so they can avoid hospitalizations. While a health
plan can use claims and encounter data to help it identify which
enrollees could benefit from an assessment of why they are not filling
their prescriptions or who might be at risk for particular problems,
putting this information into the hands of the individual's chosen care
provider--such as the doctor or nurse practitioner prescribing the
medications or the pharmacist who fills the prescriptions--helps them
to engage the patient in shared decision making that can help address
some of the reasons the individual might not be willing or able to take
medications as prescribed. By authorizing their providers to access the
same information through a standards-based API, individuals can further
facilitate communication with their care teams. Enabling the provider
to integrate claims and encounter information with EHR data gives the
provider the ability to use the combined information, with relevant
clinical decision support tools, as part of normal care delivery in a
less burdensome way, leading to improved care. This may be particularly
important during times of system surge, an event that generates a large
and sudden demand for health services, for example, when access to such
information may help to inform patient triage, transfer, and care
decisions.
Further, we noted that we believe patients who have immediate
electronic access to their health information are empowered to make
more informed decisions when discussing their health needs with
providers, or when considering changing to a different health plan. We
discussed that currently not all beneficiaries enrolled in MA plans
have immediate electronic access to their claims and encounter data and
those who do have it, cannot easily share it with providers or others.
The same is true of Medicaid beneficiaries and CHIP enrollees, whether
enrolled in FFS or managed care programs, and enrollees in QHPs on the
FFEs. As industries outside of health care continue to integrate
multiple sources of data to understand and predict their consumers'
needs, we believe it is important to position MA organizations,
Medicaid and CHIP FFS programs and managed care entities, and QHP
issuers on the FFEs to do the same to encourage competition,
innovation, and value.
We noted that CMS has programmatic authority over MA organizations,
Medicaid programs (both FFS and managed care), CHIP (both FFS and
managed care), and QHP issuers on the FFEs. We proposed to leverage CMS
authority to make claims and encounter data available through APIs as a
means to further access for patients in these programs along with other
plan data (such as provider directory data) as detailed in sections
III.C. and IV. of the CMS Interoperability and Patient Access proposed
rule. For a complete discussion of these proposals, see the proposed
rule (84 FR 7626 through 7640).
2. Alignment with the HIPAA Right of Access
As discussed in section II. of this final rule, the recent decision
in Ciox Health, LLC v. Azar, et al. vacates a portion of the HIPAA
Privacy Rule that provides an individual the right to direct a covered
entity to send protected health information that is not in an EHR to a
third party identified by the individual. It does not alter a patient's
right to request access to their records. In addition, the decision
does not affect CMS' programmatic authorities, as discussed in detail
in section III. of the CMS Interoperability and Patient Access proposed
rule (83 FR 7629 through 7630) and later in this section of this final
rule. Prior to this decision, in the CMS Interoperability and Patient
Access proposed rule, we discussed that the HIPAA Privacy Rule, at 45
CFR 164.524, provides that an individual has a right of access to
inspect and obtain a copy of their PHI \24\ that is maintained by or on
behalf of a covered entity (a health plan or covered health care
provider \25\) in a designated record set.\26\ It was noted that, at
that time, a covered entity was required to provide the access in any
readily producible form and format requested by the individual, and
that the right of access also includes individual's right to direct a
covered entity to transmit PHI directly to a third party the individual
designates to receive it.\27\
---------------------------------------------------------------------------
\24\ See 45 CFR 160.103, definition of protected health
information.
\25\ The third type of HIPAA covered entity, a health care
clearinghouse, is not subject to the same requirements as other
covered entities with respect to the right of access. See 45 CFR
164.500(b).
\26\ See 45 CFR 164.501, definition of designated record set.
\27\ For more information, see https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html.
---------------------------------------------------------------------------
We explained that software applications using the Patient Access
API proposed at 42 CFR 422.119, 431.60, 438.242(b)(6) (finalized as
438.242(b)(5) in this rule; see section VI.), 457.730, and
457.1233(d)(2), and 45 CFR 156.221, and further discussed below, would
provide an additional mechanism through which the individuals who so
choose could exercise the HIPAA right of access to their PHI, by giving
them a simple and easy electronic way to request, receive, and share
data they want and need, including with a designated third party.
However, as discussed in section II. of the CMS Interoperability and
Patient Access proposed rule (84 FR 7621 through 7622), due to
limitations in the current availability of interoperability standards
for some types of health information, or data, we noted the API
requirement may not be sufficient to support access to all of the PHI
subject to the HIPAA right of access because a patient's PHI may not
all be transferable through the API. For instance, we proposed to
require payers to make claims and encounter data as well as a specified
set of clinical data (that is, clinical data maintained by the
applicable payer in the form of the USCDI version 1 data set) available
through the Patient Access API.
[[Page 25524]]
However, a patient may request access to an X-ray image as well.
Currently, the X-ray image itself is not captured under the USCDI
version 1 data set, and though the necessary FHIR resources to share
this information via an API like the Patient Access API are available,
use is not required under this rulemaking and so a payer may not be
able to share such information via the API. Therefore, under our
proposal, a HIPAA covered entity would have to share this type of
information in a form and format other than the Patient Access API in
order to comply with our program proposals and in keeping with the
HIPAA Privacy Rule right of access.
C. Standards-Based API Proposal for MA, Medicaid, CHIP, and QHP Issuers
on the FFEs
1. Introduction
We proposed to add new provisions at 42 CFR 422.119, 431.60,
438.242(b)(6) (finalized as Sec. 438.242(b)(5) in this rule; see
section VI.), 457.730, 457.1233(d), and 45 CFR 156.221, that would,
respectively, require each MA organization, Medicaid FFS program,
Medicaid managed care plan, CHIP FFS program, CHIP managed care entity,
and QHP issuer on an FFE to implement, test, and monitor a standards-
based API that is accessible to third-party applications and
developers. We noted that states with CHIPs were not required to
operate FFS systems and that some states' CHIPs were exclusively
operated by managed care entities. We did not intend to require CHIPs
that do not operate a FFS program to establish an API; rather, we noted
that these states may rely on each of their contracted plans, referred
to throughout the CMS Interoperability and Patient Access proposed rule
and this final rule as CHIP managed care entities, to set up such a
system.
As discussed, the API would allow enrollees and beneficiaries of MA
organizations, Medicaid and CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs to
exercise their HIPAA right of access to certain health information
specific to their plan electronically, through the use of common
technologies and without special effort. We explained how ``common
technologies,'' for purposes of the proposal, means those that are
widely used and readily available, such as computers, smartphones, or
tablets.
The proposals are detailed in section III.C. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7626 through
7639), and comments received on these proposals and our responses are
noted below in this final rule.
2. The Standards-Based API Proposal
In the proposed rule, we addressed the following components of the
standards-based API. Specifically, we discussed:
Authority to require implementation of a standards-based
API by MA organizations, Medicaid and CHIP state agencies, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs;
The API technical standard and content and vocabulary
standards;
Data required to be available through the standards-based
API and timeframes for data availability;
Documentation requirements for APIs;
Routine testing and monitoring of standards-based APIs;
Compliance with existing privacy and security
requirements;
Denial or discontinuation of access to the API;
Enrollee and beneficiary resources regarding privacy and
security;
Exceptions or provisions specific to certain programs or
sub-programs; and
Applicability and timing.
We also included an RFI on information sharing between payers and
providers through APIs.
Specifically, we proposed nearly identical language for the
regulations requiring standards-based APIs at 42 CFR 422.119; 431.60,
and 457.730, and 45 CFR 156.221 for MA organizations, Medicaid state
agencies, state CHIP agencies, and QHP issuers on the FFEs; Medicaid
managed care plans would be required, at 42 CFR 438.242(b)(6)
(finalized as 438.242(b)(5) in this rule; see section VI.), to comply
with the requirement at 42 CFR 431.60, and CHIP managed care entities
would be required by 42 CFR 457.1233(d)(2) to comply with the
requirement at 42 CFR 457.730. As discussed in detail in the CMS
Interoperability and Patient Access proposed rule, we proposed similar
if not identical requirements for these various entities to establish
and maintain a standards-based API, make specified data available
through that API, disclose API documentation, provide access to the
API, and make resources available to enrollees. We noted that we
believed that such nearly identical text is appropriate as the reasons
and need for the proposal and the associated requirements are the same
across these programs. We intended to interpret and apply the
regulations proposed in section III.C. of the CMS Interoperability and
Patient Access proposed rule similarly and starting with similar text
is an important step to communicate that to the applicable entities
that would be required to comply (except as noted below with regard to
specific proposals).
In paragraph (a) of each applicable proposed regulation, we
proposed that the regulated entity (that is, the MA organization, the
state Medicaid or CHIP agency, the Medicaid managed care plan, the CHIP
managed care entity, or the QHP issuer on an FFE, as applicable) would
be required to implement and maintain a standards-based API that
permits third-party applications to retrieve, with the approval and at
the direction of the individual patient, data specified in paragraph
(b) of each regulation through the use of common technologies and
without special effort from the beneficiary. By ``common technologies
and without special effort'' by the enrollee, we explained that the
regulation means use of common consumer technologies, like smart
phones, home computers, laptops, or tablets, to request, receive, use,
and approve transfer of the data that would be available through the
standards-based API technology. By ``without special effort,'' we
proposed to codify our expectation that third-party software, as well
as proprietary applications and web portals operated by the payer could
be used to connect to the API and provide access to the data to the
enrollee. In the CMS Interoperability and Patient Access proposed rule
(84 FR 7628 through 7638), we addressed the data that must be made
available through the API in paragraph (b); the regulation regarding
the technical standards for the API and the data it contains in
paragraph (c); the documentation requirements for the API in paragraph
(d); explicit authority for the payer regulated under each regulation
to deny or discontinue access to the API in paragraph (e); and,
requirements for posting information about resources on security and
privacy for beneficiaries in paragraphs (f) or (g). Additional
requirements specific to certain programs, discussed in sections IV.
and V. of the CMS Interoperability and Patient Access proposed rule,
were also included in some of the regulations that address the API. We
address those additional requirements in sections IV. and V. of this
final rule.
a. Authority To Require Implementation of a Standards-Based API
As noted in the CMS Interoperability and Patient Access proposed
rule (84 FR 7629 through 7630), the proposal would apply to MA
organizations, Medicaid
[[Page 25525]]
state agencies and managed care plans, state CHIP agencies and managed
care entities, and QHP issuers on the FFEs. We noted that the proposal
for Medicaid managed care plans, at 42 CFR 438.242(b)(6) (finalized as
438.242(b)(5) in this rule; see section VI.), would require MCOs,
PIHPs, and PAHPs to comply with the regulation that we proposed for
Medicaid state agencies at 42 CFR 431.60 as if that regulation applied
to the Medicaid managed care plan. Similarly, we intended for CHIP
managed care entities to comply with the requirements we proposed at 42
CFR 457.730 via the regulations proposed at 42 CFR 457.1233(d)(2). We
proposed to structure the regulations this way to avoid ambiguity and
to ensure that the API proposal would result in consistent access to
information for Medicaid beneficiaries and CHIP enrollees, regardless
of whether they are in a FFS delivery system administered by the state
or in a managed care delivery system. We noted that CHIP currently
adopts the Medicaid requirements at 42 CFR 438.242 in whole. We
proposed revisions to 42 CFR 457.1233(d)(1) to indicate CHIP's
continued adoption of 42 CFR 438.242(a), (b)(1) through (5), (c), (d),
and (e), while we proposed specific text for CHIP managed care entities
to comply with the regulations proposed at 42 CFR 457.1233(d)(2) in
lieu of the proposed Medicaid revision, which we noted would add 42 CFR
438.242(b)(6) (finalized as Sec. 438.242(b)(5) in this rule; see
section VI.). In our discussion of the specifics of the proposal and
how we proposed to codify it at 42 CFR 422.119, 431.60, 457.730, and 45
CFR 156.221, we referred in the CMS Interoperability and Patient Access
proposed rule and refer in this final rule only generally to 42 CFR
438.242(b)(5) (proposed as 438.242(b)(6); see section VI.) and
457.1233(d)(2) for this reason.
(1) Medicare Advantage
Sections 1856(b) and 1857(e) of the Social Security Act (the Act)
provide CMS with the authority to add standards and requirements for MA
organizations that the Secretary finds necessary and appropriate and
not inconsistent with Part C of the Medicare statute. In addition,
section 1852(c) of the Act requires disclosure by MA organizations of
specific information about the plan, covered benefits, and the network
of providers; section 1852(h) of the Act requires MA organizations to
provide their enrollees with timely access to medical records and
health information insofar as MA organizations maintain such
information. The information required to be made available under these
authorities through the APIs in this final rule is within the scope of
information that MA organizations must make available under section
1852(c) and (h) of the Act and the implementing regulations at 42 CFR
422.111 and 422.118. As technology evolves to allow for faster, more
efficient methods of information transfer, so do expectations as to
what is generally considered ``timely.'' Thus, we noted in the CMS
Interoperability and Patient Access proposed rule our belief that to
align the standards with 21st century demands, we must take steps for
MA enrollees to have immediate, electronic access to their health
information and plan information. We further noted that the proposed
requirements were intended to achieve this goal by providing patients
access to their health information through third-party apps retrieve
data via the required APIs.
The CMS Interoperability and Patient Access proposed rule
provisions for MA organizations relied on our authority in sections
1856(b) and 1857(e) of the Act (which provide CMS with the authority to
add standards and requirements for MA organizations), and explained how
the information to be provided is consistent with the scope of
disclosure under section 1852(c) and (h) of the Act, to propose that MA
organizations make specific types of information, at minimum,
accessible through a standards-based API and require timeframes for
update cycles. Requirements for the Patient Access API further
implement and adopt standards for how MA organizations must ensure
enrollee access to medical records or other health information as
required by section 1852(h) of the Act. Similarly, the Provider
Directory API is a means to implement the disclosure requirements in
section 1852(c) regarding plan providers. Throughout section III.C. of
the CMS Interoperability and Patient Access proposed rule, we explained
how and why the standards-based API proposal was necessary and
appropriate for MA organizations and the MA program. We discussed how
these requirements would give patients simple and easy access to their
health information through common technologies, such as smartphones,
tablets, or laptop computers, without special effort on the part of the
user by facilitating the ability of patients to get their health
information from their MA organization through a user-friendly third-
party app. The goals and purposes of achieving interoperability for the
health care system as a whole are equally applicable to MA
organizations and their enrollees. Thus, the discussion in section II.
of the CMS Interoperability and Patient Access proposed rule served to
provide further explanation as to how a standards-based API proposal is
necessary and appropriate in the MA program. In addition, we noted that
having easy access to their claims, encounter, and other health
information would also facilitate beneficiaries' ability to detect and
report fraud, waste, and abuse--a critical component of an effective
programs.
To the extent necessary, we also relied on section 1860D-12(b)(3)
of the Act to add provisions specific to the Part D benefit offered by
certain MA organizations; that provision incorporates the authority to
add program requirements to the contracts from section 1857(e)(1) of
the Act. For MA organizations that offer MA Prescription Drug plans, we
proposed requirements in 42 CFR 422.119(b)(2) regarding electronic
health information for Part D coverage. We explained that this proposal
was supported by the disclosure requirements imposed under section
1860D-4(a) of the Act, requiring Part D claims information, pharmacy
directory information, and formulary information to be disclosed to
enrollees. Also, we note here that 42 CFR 423.136(d) requires Part D
plans to ensure timely access by enrollees to the records and
information that pertain to them. The APIs in this rule further
implement and build on these authorities for ensuring that Part D
enrollees have access to information.
(2) Medicaid and CHIP
We proposed new provisions at 42 CFR 431.60(a), 457.730,
438.242(b)(6) (finalized as 42 CFR 438.242(b)(5) in this rule; see
section VI.), and 457.1233(d)(2) that would require states
administering Medicaid FFS or CHIP FFS, Medicaid managed care plans,
and CHIP managed care entities to implement a standards-based API that
permits third-party applications with the approval and at the direction
of the beneficiary or enrollee to retrieve certain standardized data.
The proposed requirement would provide Medicaid beneficiaries' and CHIP
enrollees simple and easy access to their information through common
technologies, such as smartphones, tablets, or laptop computers, and
without special effort on the part of the user.
For Medicaid, we proposed these new requirements under our
authority under section 1902(a)(4) of the Act, which requires that a
state Medicaid plan provide such methods of administration as are found
by the Secretary to be necessary for the proper and efficient
[[Page 25526]]
operation of the plan, and section 1902(a)(19) of the Act, which
requires that care and services be provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
For CHIP, we proposed these requirements under the authority in section
2101(a) of the Act, which sets forth that the purpose of title XXI is
to provide funds to states to provide child health assistance to
uninsured, low-income children in an effective and efficient manner
that is coordinated with other sources of health benefits coverage.
Together we noted that these proposals would provide us with authority
(in conjunction with our delegation of authority from the Secretary) to
adopt requirements for Medicaid and CHIP that are necessary to ensure
the provision of quality care in an efficient and cost-effective way,
consistent with simplicity of administration and the best interest of
the beneficiary.
We noted that we believed that requiring state Medicaid and CHIP
agencies and managed care plans/entities to take steps to make Medicaid
beneficiaries' and CHIP enrollees' claims, encounters, and other health
information available through interoperable technology would ultimately
lead to these enrollees accessing that information in a convenient,
timely, and portable way, which is essential for these programs to be
effectively and efficiently administered in the best interests of
beneficiaries. Further, we noted that there are independent statutory
provisions that require the disclosure and delivery of information to
Medicaid beneficiaries and CHIP enrollees; the proposal would result in
additional implementation of those requirements in a way that is
appropriate and necessary in the 21st century. We also noted that we
believed making this information available in APIs and ultimately apps
may result in better health outcomes and patient satisfaction and
improve the cost effectiveness of the entire health care system,
including Medicaid and CHIP. Having easy access to their claims,
encounter, and other health information may also facilitate
beneficiaries' ability to detect and report fraud, waste, and abuse--a
critical component of an effective programs.
We discussed that as technology has advanced, we have encouraged
states, health plans, and providers to adopt various forms of
technology to improve the accurate and timely exchange of standardized
health care information. We noted that the proposal would move Medicaid
and CHIP programs in the direction of enabling better information
access by Medicaid beneficiaries and CHIP enrollees, which would make
them active partners in their health care by providing a way for them
to easily monitor and share their data. By requiring that certain
information be available in and through standardized formats and
technologies, we noted that the proposal moved these programs toward
interoperability, which is key for data sharing and access, and
ultimately, improved health outcomes. We also noted that states would
be expected to implement the CHIP provisions using CHIP administrative
funding, which is limited under sections 2105(a)(1)(D)(v) and
2105(c)(2)(A) of the Act to 10 percent of a state's total annual CHIP
expenditures.
(3) Qualified Health Plan Issuers on the Federally-Facilitated
Exchanges
We proposed a new QHP minimum certification standard at 45 CFR
156.221(a) that would require QHP issuers on the FFEs to implement a
standards-based API that would permit third-party applications, with
the approval and at the direction of the individual enrollee, to
retrieve standardized data as specified in the proposal. We also
proposed to require that the data be made available to QHP enrollees
through common technologies, such as smartphones or tablets, and
without special effort from enrollees.
We proposed the new requirements under our authority in section
1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as
amended by the Health Care and Education Reconciliation Act of 2010
(Pub. L. 111-148, enacted March 23, 2010, and Pub. L. 111-152, enacted
March 30, 2010, respectively) (collectively referred to as the
Affordable Care Act), which afforded the Exchanges the discretion to
certify QHPs that are in the best interests of qualified individuals
and qualified employers. Specifically, section 1311(e) of the
Affordable Care Act authorized Exchanges to certify QHPs that meet the
QHP certification standards established by the Secretary, and if the
Exchange determined that making available such health plan through such
Exchange is in the interests of qualified individuals and qualified
employers in the state in which such Exchange operates.
In the CMS Interoperability and Patient Access proposed rule, we
noted specifically in our discussion on QHP issuers on the FFEs, but
applicable to all payers impacted by this rule, that we believe there
are numerous benefits associated with individuals having access to
their health plan data that is built upon widely used standards. The
ability to easily obtain, use, and share claims, encounter, and other
health data enables patients to more effectively and easily use the
health care system. For example, by being able to easily access a
comprehensive list of their adjudicated claims, patients can ensure
their providers know what services they have already received, can
avoid receiving duplicate services, and can help their providers verify
when prescriptions were filled. We noted that we believe these types of
activities would result in better health outcomes and patient
satisfaction and improve the cost effectiveness of the entire health
care system. Having simple and easy access, without special effort, to
their health information, including cost and payment information, also
facilitates patients' ability to detect and report fraud, waste, and
abuse--a critical component of an effective program. We noted that
existing and emerging technologies provide a path to make information
and resources for health and health care management universal,
integrated, equitable, accessible to all, and personally relevant.
Specifically, for QHP issuers on the FFEs, we stated that we believe
generally certifying only health plans that make enrollees' health
information available to them in a convenient, timely, and portable way
is in the interests of qualified individuals and qualified employers in
the state or states in which an FFE operates. We also noted we
encouraged SBEs to consider whether a similar requirement should be
applicable to QHP issuers participating in their Exchange.
We did not receive comments on the authorities discussed in this
section to implement the Patient Access API. We are finalizing these
provisions, with the modifications discussed in section III.C. of this
rule, under this authority. Additionally, we are making two
modifications to the regulation text to more clearly identify issuers
subject to the regulation. First, we are modifying the scope of the
applicability of the regulation to issuers on the individual market
FFEs, effectively excluding issuers offered through the FF-SHOP, and we
are explicitly excluding QHP issuers on the FFEs that only offer SADPs.
b. API Technical Standard and Content and Vocabulary Standards
We proposed to require compliance with 45 CFR 170.215 as finalized
at 42 CFR 422.119(a) and (c), Sec. 431.60(a) and (c), 457.730(a) and
(c), 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see
section VI.) and 457.1233(d)(2), and 45 CFR 156.221(a) and (c), so that
MA organizations, Medicaid and CHIP FFS
[[Page 25527]]
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs implement standards-based API technology
conformant with the API technical standards finalized by HHS in the ONC
21st Century Cures Act final rule (published elsewhere in this issue of
the Federal Register), as discussed in section II.A.3. of the CMS
Interoperability and Patient Access proposed rule and section II. of
this final rule. We further proposed to require that the data available
through the API be in compliance with the regulations regarding the
following content and vocabulary standards, where applicable to the
data type or data element, unless an alternate standard is required by
other applicable law: Standards adopted at 45 CFR part 162 and 42 CFR
423.160; and standards finalized by HHS in the ONC 21st Century Cures
Act final rule at 45 CFR 170.213 (USCDI version 1). See section II.A.3.
of the CMS Interoperability and Patient Access proposed rule for
further information about how entities subject to this rule would be
required to utilize these standards. We proposed that both the API
technical standard and the content and vocabulary standards would be
required across the MA program, Medicaid program, and CHIP, and by QHP
issuers on the FFEs.
With the proposed requirements to implement and maintain an API at
42 CFR 422.119(a), 431.60(a), and 457.730(a), we proposed corresponding
requirements at 42 CFR 422.119(c) for MA plans, 431.60(c) for Medicaid
FFS programs, and 457.730(c) for CHIP FFS programs implementing the
proposed API technology. At proposed 42 CFR 422.119(c), 431.60(c), and
457.730(c), MA plans and the state Medicaid or CHIP agency (for states
that operate CHIP FFS systems) would be required to implement,
maintain, and use API technology conformant with the standards
finalized by HHS in the ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register) at 45 CFR
170.215; for data available through the API, to use content and
vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and
finalized at 45 CFR 170.213, unless alternate standards are required by
other applicable law; and to ensure that technology functions in
compliance with applicable law protecting the privacy and security of
the data, including but not limited to 45 CFR parts 162, 42 CFR part 2,
and the HIPAA Privacy and Security Rules.
We similarly proposed at 45 CFR 156.221(c) that QHP issuers on the
FFEs must implement, maintain, and use API technology conformant with
the API technical standards finalized by HHS in the ONC 21st Century
Cures Act final rule (published elsewhere in this issue of the Federal
Register) at 45 CFR 170.215; for data available through the API, use
content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR
423.160, and finalized at 45 CFR 170.213, unless alternate standards
are required by other applicable law; and ensure that technology
functions in compliance with applicable law protecting the privacy and
security of the data, including but not limited to 45 CFR part 162, 42
CFR part 2, and the HIPAA Privacy and Security Rules.
We noted that we believed these proposals would serve to create a
health care information ecosystem that allows and encourages the health
care market to tailor products and services to better serve and compete
for patients, thereby increasing quality, decreasing costs, and
empowering patients with information that helps them live better,
healthier lives. Additionally, under our proposal, clinicians would be
able to review, with the approval and at the direction of the patient,
information on the patient's current prescriptions and services
received by the patient; the patient could also allow clinicians to
access such information by sharing data received through the API with
the clinician's EHR system--by forwarding the information once the
patient receives it or by letting the clinician see the information on
the patient's smartphone using an app that received the data through
the API. Developers and providers could also explore approaches where
patients can authorize release of the data through the API directly to
the clinician's EHR system.
We also encouraged payers to consider using the proposed API
infrastructure as a means to exchange health information for other
health care purposes, such as to health care providers for treatment
purposes. Sharing interoperable information directly with the patient's
health care provider in advance of a patient visit would save time
during appointments and ultimately improve the quality of care
delivered to patients. Most clinicians and patients have access to the
internet, providing many access points for viewing health information
over secure connections. We noted that we believed these proposed
requirements would significantly improve patients' experiences by
providing a mechanism through which they can access their data in a
standardized, computable, and digital format in alignment with other
public and private health care entities. We stated that we designed the
proposals to empower patients to have simple and easy access to their
data in a usable digital format, and therefore, empower them to decide
how their health information is going to be used. However, we reminded
payers, and proposed to codify that the regulation regarding the API
would not lower or change their obligations as HIPAA covered entities
to comply with regulations regarding standard transactions at 45 CFR
part 162.
Finally, we also proposed to add a new MA contract requirement at
42 CFR 422.504(a)(18) specifying that MA organizations must comply with
the requirement for access to health data and plan information under 42
CFR 422.119.
We summarize the public comments we received on the Patient Access
API proposal, generally, and the technical standards we proposed for
the API and its content, and provide our responses.
Comment: Many commenters indicated support for the overall proposal
to require the specified payers to provide patients access to their
health care information through a standards-based API. These commenters
supported the goals to provide patients near real-time, electronic
access to their claims, treatment, and quality information. Many
commenters were also supportive of provider access to patient data
through APIs, if the patient consented to (or authorized) access, in
order to support coordinated care. One commenter was specifically in
favor of the patient access proposal noting it supports patient access
to their historical claims information. Finally, one commenter
requested that CMS explain whether ``API technology'' has the same
definition as in the ONC proposed rule.
Response: We appreciate the commenters' support for the Patient
Access API proposal and are finalizing this policy with modifications,
as discussed in detail below. We also note that both the CMS and ONC
rules use the term ``API'' consistently as we work together to align
technology and standards and forward interoperability across the entire
health care system. We do note, however, that the Patient Access API
did not propose to include quality information.
Comment: One commenter requested CMS specify the historical look-
back period for API exchange. In addition, one commenter requested that
CMS not require data older than from 2019 be made available through
APIs due to the implementation costs of standardizing older
information.
[[Page 25528]]
Response: We appreciate the commenters' suggestions. The proposed
rule did not specify a historical look-back period for the Patient
Access API or limit the timeframe of the data that must be available
through the API. To ensure consistent implementation and minimize the
burden on payers, we are finalizing additional text in the applicable
regulations to specify that MA organizations at 42 CFR 422.119(h),
state Medicaid FFS programs at 42 CFR 431.60(g), Medicaid managed care
plans at 42 CFR 438.62(b)(1)(vii), CHIP FFS programs at 42 CFR
457.730(g), CHIP managed care entities at 42 CFR 457.1233(d), and QHP
issuers on the FFEs at 45 CFR 156.221(i), beginning January 1, 2021 (or
plan years beginning on or after January 1, 2021 for QHPs on the FFEs),
must make available through the Patient Access API data that they
maintain with a date of service on or after January 1, 2016. This means
that no information with a date of service earlier than January 1, 2016
will need to be made available through the Patient Access API. By
``date of service,'' we mean the date the patient received the item or
service, regardless of when it was paid for or ordered. This is
consistent with how we are finalizing the payer-to-payer data exchange
requirement for MA organizations at 42 CFR 422.119(f), Medicaid managed
care plans at Sec. 438.62(b)(1)(vi) (made applicable to CHIP managed
care entities through incorporation in Sec. 457.1216), and QHP issuers
on the FFEs at 45 CFR 156.221(f). Aligning the years of data available
through the Patient Access API with the payer-to-payer data exchange
will minimize cost and burden specific to this regulatory requirement
and will provide patients with the same timeframe of information as
payers, furthering transparency. Together these policies facilitate the
creation and maintenance of a patient's cumulative health record with
their current payer.
We do not believe limiting the Patient Access API to data only from
January 1, 2019 forward is sufficient to help patients most benefit
from this data availability. However, we do appreciate that making
older data available for electronic data exchange via the Patient
Access API is part of the cost of the API. As a result, limiting this
to data with a date of service of January 1, 2016 forward minimizes
cost and burden while maximizing patient benefit.
Comment: A few commenters expressed concerns and indicated that
they did not believe the Patient Access API proposal would move the
health care industry toward the stated goal of helping patients make
more informed care decisions. Several commenters were concerned that
certain patient groups, such as those with low technology access and/or
health literacy, would not make use of electronic applications for
making health care decisions. A few commenters recommended CMS not
limit patient access to health information through apps alone,
especially for populations with low technology access and/or literacy.
Response: We appreciate the commenters' concerns. However, more and
more Americans are using portable technology like smart phones and
tablets to conduct a myriad of daily activities. Approximately 81
percent of U.S. adults reported owning a smartphone and 52 percent
reported owning a tablet computer in 2019.\28\ An American Community
Survey Report from the U.S. Census Bureau reported that in 2016, 82
percent of households reported an internet subscription and 83 percent
reported a cellular data plan.\29\
---------------------------------------------------------------------------
\28\ Pew Research Center. (2019, June 12). Retrieved from
https://www.pewinternet.org/fact-sheet/mobile.
\29\ Ryan, C. (2018). Computer and internet Use in the United
States: 2016 (American Community Survey Reports, ACS-39). Retrieved
from https://www.census.gov/content/dam/Census/library/publications/2018/acs/ACS-39.pdf.
---------------------------------------------------------------------------
People have a right to be able to manage their health information
in this way should they choose. We appreciate that not everyone is
comfortable with, has access to, or uses electronic applications in
making health care decisions. Such patients will maintain the same
access that they have to their personal health information today. This
regulation does not change any existing patient information rights.
This regulation simply adds new options to ensure patients have the
information they need, when, and how they need it.
Comment: Several commenters indicated concerns over what they
believe would be a costly implementation. A few commenters questioned
who would be required to bear the costs of implementation and
maintenance of the APIs, with one commenter requesting CMS explicitly
permit payers to charge patients and other third-party partners for the
costs of API implementation and maintenance. In contrast, a few
commenters recommended that payers should not be allowed to charge
patients to access their information through APIs. A few commenters
requested CMS provide federal grant funding to support payers in
implementing the proposed APIs.
Response: We appreciate the commenters' concerns and
recommendations. As discussed in section XIII. of this final rule, we
are providing updated cost estimates for implementing and maintaining
the Patient Access API, moving from a single point estimate to a
range--including a low, primary, and high estimate--to better take into
account the many factors that impact the cost of implementation. We
have revised our original estimate of $788,414 per payer, to a primary
estimate of $1,576,829 per payer, increasing our original estimate by a
factor of 2 to account for additional information that was provided by
commenters, which we still believe is relatively minimal in relation to
the overall budget of these impacted payers. We have included a low
estimate of $718,414.40 per organization, and a high estimate of
$2,365,243 per organization. We refer readers to sections XII. and
XIII. of this final rule for a detailed discussion of our revised cost
estimates.
We acknowledge that payers may pass these costs to patients via
increased premiums. In this way, patients could absorb the cost of the
API. However, we note the costs of ``premiums'' for MA, Medicaid, and
CHIP enrollees are primarily borne by the government, as are some
premium costs for enrollees of QHP issuers on the FFEs who receive
premium tax credits. We believe that the benefits created by the
Patient Access API outweigh the costs to patients if payers choose to
increase premiums as a result.
At this time, we are not able to offer support for the
implementation of this policy through federal grant funding. Regarding
costs for Medicaid managed care plans--since the Patient Access API
requirements must be contractual obligations under the Medicaid managed
care contract--the state must include these costs in the development of
a plan's capitation rates. These capitation rates would be matched at
the state's medical assistance match rate. State Medicaid agency
implementation costs would be shared by the state and federal
government, based on the relevant level of Federal Financial
Participation, which is 50 percent for general administrative costs and
90 percent for system development costs.
Comment: A few commenters described concerns with the maturity of
APIs for data exchange, as well as the fact that implementation of
FHIR-based APIs is so new in health care, and expressed that they
believed there were challenges with meeting the proposed requirement
given the newness of the needed standards, particularly regarding
standardizing the required data elements and vocabularies. Several
[[Page 25529]]
commenters were concerned that APIs would not be implemented in a
standardized fashion, which could lead to interoperability challenges,
and noted the need for testing for certain use cases, such as
exchanging data from plan to patients and from plan-to-plan, as well as
the exchange of provider directory and/or pharmacy/formulary
information. Several commenters suggested CMS and/or HHS publish
implementation guides to support consistent and standardized
implementation of FHIR-based APIs and their associated data standards.
Response: We appreciate the commenters' concerns. As stated in
section II. of this final rule, the content and vocabulary standards
and technical standards HHS is finalizing in the ONC 21st Century Cures
Act final rule (published elsewhere in this issue of the Federal
Register) provide the foundation needed to support implementation of
the policies as proposed and now finalized in this rule. That said, we
have been working with HL7 and other industry partners to ensure the
implementation guides requested are freely available to payers to use
if they choose to use them. Use of these implementation guides is not
mandatory; however, if a payer does choose to use the publicly
available guidance, it will limit payer burden and support consistent,
interoperable API development and implementation. Therefore, use of
this publicly available guidance can help address the consistency
concerns raised. Part of the development process of any implementation
guide is consensus review, balloting, and testing. We are providing a
link to specific implementations guides and reference implementations
for all interested payers for both the Patient Access API and the
Provider Directory API (discussed in section IV. of this final rule)
that provide valuable guidance to further support sharing the needed
data using the required standards: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. The implementation guides
provide information payers can use to meet the requirements of the
policies being finalized in this rule without having to develop an
approach independently, saving time and resources. In addition, the
reference implementations allow payers to see the APIs in action and
support testing and development.
Comment: A few commenters indicated concerns with an impending
proliferation of multiple health plan APIs. Instead, commenters
recommended a centralized, standardized approach where CMS would
require the use of Blue Button 2.0 as the platform for providing
patient access to their health data from all impacted programs
(Medicare Advantage, Medicaid, CHIP, and QHPs on the FFEs). Commenters
suggested this would also reduce the burden on app developers to
develop to one API rather than multiple APIs for various regulated
entities.
One commenter requested CMS implement a pilot program for the API
proposals, citing CMS' Blue Button pilot. One commenter suggested CMS
convene a group of 10-12 subject matter experts from payers along with
other relevant stakeholders, such as developers, to meet with CMS, ONC,
and the FTC to facilitate a smooth path to the API compliance deadline
and ensure a successful implementation.
Response: We appreciate the commenters' concerns and
recommendations. However, we do not wish to require use of the Blue
Button 2.0 platform as a centralized solution. We believe that industry
will best have the ability to take interoperability to the next level
by leading the development of APIs that meet the requirements in the
regulations at 42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233,
as well as 45 CFR 156.221, and which they maintain and control. Blue
Button is essentially the hub for the Medicare data that CMS, as a
payer, is making available to our beneficiaries. We do not wish to
require the centralization of other payer data under this rule. We are
requiring other payers to also unleash their data and provide the same
benefits to their enrollees in a standardized way. As noted above, we
are providing a link to specific implementation guides and reference
implementations to further support implementation of the Patient Access
API, as well as the Provider Directory API (discussed in section IV. of
this final rule), for all payers to use: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Use of these
freely available materials is not required, but if used will reduce
development burden for both payers and app developers and facilitate
industry-wide interoperability.
Although we appreciate the recommendation to consider a pilot, we
believe it is important to move ahead with APIs at this time to help
the health care sector as a whole--including patients, providers and
payers--start to benefit from this technology as so many other sectors
have. Also, as previously noted in this final rule, we will share
lessons learned and best practices from our experience with Blue Button
as relevant and appropriate to aid the successful implementation of the
API requirements included in this final rule.
Regarding the request to convene subject matter experts, we
reiterate our commitment to continuing our collaboration with our
federal partners and a diversity of industry stakeholders to ensure a
successful and smooth implementation of the requirements included in
this final rule. As this collaboration is ongoing, we do not believe it
is necessary to convene a new, dedicated group.
Comment: One commenter recommended that CMS consider standards to
allow payers and providers to upload patient data directly to a patient
portal that is owned and managed by the patient. One commenter
suggested that Health Information Exchanges (HIEs) and Health
Information Networks (HINs) can be a central source for patients to
obtain aggregated data in a single location.
Response: We thank commenters for these recommendations. We
appreciate that HIEs and HINs can provide patients with valuable
information, and we look forward to innovative solutions from this
community. One option would be to leverage APIs and support patient
access via this technology. We did not propose to use a portal
approach. One of the advantages of an API approach is that any system
can make data available and that data can be used by any other system
that is following the same approach to mapping and transporting data
without a need to otherwise link the systems or ensure any system-level
compatibility. Having APIs that can be accessed by third-party apps
permits the patient to choose how they want to access their data, and
it promotes innovation in industry to find ways to best help patients
interact with their data in a way that is most meaningful and helpful
to them. This same flexibility and interoperability is not easily
realized through a portal solution, and thus we will not consider this
recommendation at this time.
Comment: A few commenters requested CMS confirm the proposed
preclusion policy for versions of standards and standards themselves at
42 CFR 422.119(c)(4) for MA organizations, 42 CFR 431.60(c)(4) for
Medicaid FFS programs, 42 CFR 438.242(b)(5) for Medicaid managed care
plans, 42 CFR 457.730(c)(4) for CHIP FFS programs, 42 CFR
457.1233(d)(1) for CHIP managed care entities, and 45 CFR 156.221(c)(4)
for QHP issuers on the FFEs. These commenters recommended CMS indicate
that the preclusion policy would prohibit plans from using standards
not named by CMS for the
[[Page 25530]]
specified API functions, but would not prohibit them from using those
standards for other use cases not regulated by CMS.
Response: We confirm that the requirements in this regulation will
not preclude a payer from using a standard not finalized in this rule
for use cases that are not specifically discussed in this final rule as
required for use with the Patient Access API requirement or the
Provider Directory API requirement (discussed in section IV. of this
final rule). The content and vocabulary standards being adopted are
specifically applicable to the data identified and required to be made
available through the Patient Access API and Provider Directory API;
this means that if there is a content standard identified in the
regulation text for the information specified in the regulation text as
required to be made available through the API, the payer subject to the
regulation must make available through the API at least these data
elements using the named content standard. This final rule indicates
the minimum data that must be made available via these APIs. This does
not prevent a payer from including more information via either API
using other available standards. We do strongly support the continued
use and adoption of FHIR standards for additional use cases to promote
interoperability and efficient and effective transfer of electronic
health information, generally.
Comment: A few commenters expressed concerns that contracts between
health care providers and payers need to be standardized in order to
support the requirements of the CMS Interoperability and Patient Access
proposed rule. A few additional commenters specifically noted that
timing requirements for making information available through APIs
should be specified in these contracts. One commenter requested CMS
prohibit payers from using the Patient Access API requirements to place
additional contractual demands on health care providers.
Response: We appreciate the commenters' concerns that there will be
downstream impacts from the Patient Access API requirements on the
relationship between payers and their contracted health care providers.
It will be up to each payer's discretion to address whether this
information needs to be included in contracts with providers. We do not
believe it is necessary or appropriate for CMS to adopt regulations to
standardize all contracts between payers and health care providers to
accomplish this and are not convinced it would be wise to try to do so
as each payer is unique, as are their relationships with their
contracted providers. We are finalizing the implementation timeline
with modifications from the proposal, as further discussed below, to
provide payers and providers more time to address all implementation
issues. We do not anticipate this will create significant additional
provider burden.
Comment: Several commenters supported the CMS proposal to adopt
FHIR as the technical standard for payer APIs. Several commenters
recommended adopting FHIR Release 4 (R4), also referred to as ``version
4,'' noting it is more robust than Release 2 (R2), particularly
regarding laboratory information. A few other commenters supported the
use of FHIR R2 with the eventual transition to R4. One commenter
indicated their recommendation on the version of FHIR to adopt (R2 vs
R4) would depend on the timeline CMS provides payers for compliance. A
few commenters also suggested CMS align with the version of FHIR that
ONC adopts in its final rule.
Response: We thank commenters for their recommendations, which we
have shared with ONC. We are adopting the standards as finalized by HHS
in ONC's 21st Century Cures Act final rule (published elsewhere in this
issue of the Federal Register). As a result, the regulations we are
finalizing will require the use of the standards identified at 45 CFR
170.215, which specifically include the use of HL7 FHIR Release 4.0.1.
As previously stated, we believe that requiring regulated entities to
comply with the specified standards regulations finalized by HHS in
ONC's 21st Century Cures Act final rule (published elsewhere in this
issue of the Federal Register) will support greater alignment and
interoperability across the health care system, as health IT products
and applications that will be developed for different settings and use
cases will be developed according to a consistent base of standards
that support a more seamless exchange of information. Extending the
implementation date, as further discussed below, should provide the
necessary time to build to and use FHIR Release 4.0.1.
Comment: Although many commenters were generally in support of the
proposal to use FHIR, several commenters did raise specific
implementation concerns. Several commenters expressed concerns about
the costs and burden for payers and providers to update to the
necessary FHIR standard for content exchange, especially for historical
data that may not currently be coded to support FHIR. Many of these
commenters cautioned CMS from proceeding too quickly with FHIR adoption
and implementation. One commenter noted that semantic interoperability
is needed for true interoperability but that significant mapping and
implementation efforts would be needed to achieve this goal. One
commenter requested CMS provide federal funding to support adoption and
implementation of FHIR-based APIs.
Response: We appreciate the commenters' concerns. Regarding the
readiness of the FHIR standards and the need for semantic
interoperability, we agree that semantic interoperability is important.
As noted in this section, though not required for use, we are providing
a link to specific implementation guides and reference implementations
that include information about the FHIR resources to use to code and
map the required data elements as to facilitate interoperable data
exchange via the Patient Access API, as well as the Provider Directory
API (discussed in section IV. of this final rule). This addresses the
concern raised regarding semantic interoperability.
Regarding burden, as indicated in section XIII. of this final rule,
we do not anticipate that upgrading to HL7 FHIR Release 4.0.1 and
preparing historical data for electronic transfer via an API using
these standards will be more than a relatively minimal expense. We are
also limiting the amount of historic information that will need to be
included in the Patient Access API to information with a date of
service on or after January 1, 2016. This should also help address
concerns around expense and burden. In addition, we note the discussion
below regarding the implementation date for this policy appreciating
the commenters' concerns about moving too quickly. Regarding federal
funding and costs, we note that for several of the types of payers that
must comply with the Patient Access API requirements, there is
significant federal participation in the costs.
For Medicaid FFS, the provision of enhanced federal match rate is
addressed in section 1903(a)(3)(A) of the Act and provides a 90 percent
match rate for the sums expended during such quarter as are
attributable to the design, development, or installation of such
mechanized claims processing and information retrieval systems as the
Secretary determines are likely to provide more efficient, economical,
and effective administration of the plan.
For Medicaid managed care plans, since the Patient Access API
requirements must be contractual obligations under the Medicaid
[[Page 25531]]
managed care contract, the costs must be included in the development of
a plan's capitation rates. Approved capitation rates would be matched
at the state's medical assistance match rate.
As is discussed in section XIII. of this final rule, MA
organizations may include in their bids the costs of implementing
provisions of this rule that pertain to MA. The bid, as compared to the
benchmark, is a significant component of what the government pays MA
organizations for the provision of Part A and Part B benefits: (1) For
bids at or below the benchmark, the government pays the bid as the
capitation amount, and (2) for bids that are above the benchmark, the
government pays the benchmark and the remainder of the bid amount is
the premium charged to enrollees of the plan.
For CHIP, the federal government pays an enhanced federal medical
assistance percentage (EFMAP) to states for all costs associated with
CHIP, including systems costs. For federal FY 2020, the EFMAPS will
range from approximately 65 to 81.5 percent. We note that states will
be expected to implement the CHIP provisions using CHIP administrative
funding, which is limited under section 2105(a)(1)(D)(v) and
2105(c)(2)(A) of the Act to 10 percent of a state's total annual CHIP
expenditures.
For QHP issuers on the FFEs, we would expect that issuers would
raise premiums in the short term in order to cover the costs associated
with developing and implementing these new standards. To the extent
that premiums are raised for all QHP issuers on the FFEs, federal
contributions for the subsidized population in the form of advanced
premium tax credits will increase proportionally in those initial
years. Non-subsidized consumers will be expected to pay for the
increase in premiums themselves and any increases may impact the
ability of some consumers to afford coverage. Some consumers may
instead select other options or opt out of coverage if they find QHPs
unaffordable.
Comment: A few commenters indicated they did not support CMS'
proposal to use one standard adopted by HHS (FHIR, which ONC had
proposed for adoption at 45 CFR 170.215) as the foundational standard
for standards-based APIs. A few commenters suggested CMS permit the use
of other standards for exchanging the proposed patient data during a
transition period or until the FHIR standards are more mature. One
commenter recommended the use of HIPAA Administrative Simplification
transaction standards such as those maintained by X12. One commenter
noted that these HIPAA transaction standards were more accessible to
payers to represent clinical and case management data. This commenter
suggested CMS should precisely identify the specific claims data layout
of the HIPAA Administrative Simplification transaction standards that
payers would be required to generate and receive because the HIPAA
Administrative Simplification transaction standards layout varies by
payer type. However, one commenter noted that patients may not find
information available through HIPAA standards useful.
A few commenters suggested CMS should assist affected payers with
meeting the technical implementation requirements by explaining the
intent of the required use of the HIPAA Administrative Simplification
transaction content and vocabulary standards with the HL7 FHIR
standards. Commenters recommended that CMS review and reconcile
differences between existing standards that are required for Medicaid
programs, in particular. For example, commenters suggested identifying
situations in which CMS has required the use of X12 Electronic Data
Interchange standards and reconciling these requirements with the
adoption of the HL7 FHIR standards.
Response: We appreciate the commenters' concerns and
recommendations. The policies included in this final rule are not
intended to alter HIPAA requirements in any way, and these electronic
data exchanges are not defined transactions under HIPAA regulations,
therefore there is no need to reconcile use of X12 and the HL7 FHIR
standards required in this rule. We appreciate that the HIPAA standards
are more known to many payers at this time; however, we believe the use
of FHIR standards is important for advancing the policies finalized in
this rule, which require the transmission of information beyond what is
available using X12 standards alone. At the same time, as discussed in
the proposed rule, we are requiring entities subject to this rule to
use HIPAA content and vocabulary standards at 45 CFR part 162 where
required by other applicable law, or where such standards are the only
available standards for the data type or element (84 FR 7623). The use
of the FHIR standard supports making this information available through
an API. This is not in conflict with the use of other standards to
represent the data being transmitted through the API. Instead, the FHIR
standard can be thought of as defining an envelope, while the contents
of the envelope can be represented by different content and vocabulary
standards used in conjunction with FHIR to make data interoperable and
accessible. For additional information on FHIR standards, we direct
commenters to the ONC's 21st Century Cures Act final rule (published
elsewhere in this issue of the Federal Register). To support
implementation of the policies included in this final rule, we are
providing a link to specific implementation guides and reference
implementations that provide valuable guidance to further support
sharing the needed data using the required standards: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
As discussed in section II.A.3. of the CMS Interoperability and
Patient Access proposed rule (84 FR 7622 through 7623), we recognized
that while we must codify in regulation a specific version of each
standard, the need for continually evolving standards development has
historically outpaced our ability to amend regulations. To address how
standards development can outpace our rulemaking schedule, we offered
several proposals. We proposed that regulated entities may use an
updated version of a standard where required by other applicable law.
We also proposed that regulated entities may use an updated version of
the standard where not prohibited by other applicable law, under
certain circumstances.
We summarize the public comments we received on our approach to
allowing voluntary adoption of updated standards and provide our
responses.
Comment: A few commenters expressed support for the proposal to
allow plans to upgrade to newer versions of standards supporting data
classes in the USCDI as standards evolve. A few commenters specifically
supported the proposal to align with ONC's proposed Standards Version
Advancement Process and allow payers to adopt newer versions of FHIR
once approved for use by HHS. A few commenters were concerned with
backwards compatibility if implementers--payers and developers--are
permitted to move to new versions of standards, while a few commenters
supported the proposed requirement to maintain compatibility with
adopted standards while upgrading to newer standards. One commenter
expressed concerns with difficulty tracking compliance with standards
as they move through different versions, generally, and requested CMS
establish
[[Page 25532]]
a versioning system or identifier for consistency and transparency.
A few commenters specifically discussed the NCPDP SCRIPT standard;
however, these comments are out of scope for this rulemaking because
this rulemaking does not apply to ePrescribing transactions.
Response: We appreciate the commenters' input. We are adopting the
ability to use updated standards. As proposed, implementers will need
to ensure that use of the updated (or newer) standard (instead of the
standard specified in the applicable regulation) does not disrupt an
end user's ability to access the data available through the API, which
should address concerns raised around backward compatibility.
Specifically, we are finalizing at 42 CFR 422.119(c)(4) for MA
organizations, 42 CFR 431.60(c)(4) for Medicaid FFS programs, 42 CFR
438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(c)(4) for
CHIP FFS programs, 42 CFR 457.1233(d)(1) for CHIP managed care
entities, and 45 CFR 156.221(c)(4) for QHP issuers on the FFEs
permission to use an updated version of standards adopted at 45 CFR
170.215, 45 CFR 170.213, 45 CFR part 162, or 42 CFR 423.160, subject to
the conditions proposed. As long as use of the updated version of a
standard is not otherwise prohibited, permitted in accordance with the
conditions described, and, does not disrupt an end user's ability to
access the data per the requirements of the API, it may be used.
Regarding the recommendation for CMS to establish a versioning
system or identifier, we appreciate this recommendation and will review
the suggestion for future consideration.
c. Data Required To Be Available Through the Standards-Based API &
Timeframes for Data Availability
We proposed the content that must be accessible for each enrollee
of an entity subject to the standards-based API proposal as set out at
proposed paragraph (b) of 42 CFR 422.119, 431.60, and 457.730, and 45
CFR 156.221; as noted previously, the regulations for Medicaid managed
care plans and CHIP managed care entities cross-reference and
incorporate the regulations we proposed for Medicaid and CHIP FFS
programs. We noted that the types of content proposed would represent
the minimum threshold for compliance; at their discretion, MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs
would have the option to use the API required by the proposed rule to
make additional types of health information or plan information
available, exceeding these minimum requirements.
We requested comment on the data proposed to be made available as
detailed in the subsections below. We proposed that MA organizations,
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs permit third-party
applications to retrieve, with the approval and at the direction of an
enrollee, certain specific data: Adjudicated claims data, including
provider remittances and beneficiary or enrollee cost-sharing data;
encounter data from capitated providers; and clinical data, including
laboratory results (but only if maintained by the payer).
(1) Patient Claims and Encounter Data
We proposed that the adjudicated claims data required to be
provided include approved and denied claims. Under the proposal,
adjudicated claims data includes that for which the plan has made an
initial payment decision even when the period during which an enrollee
can file an appeal is still in effect, or when the enrollee has filed
an appeal and is awaiting a decision on that appeal. Such appeal
decisions might be called reconsiderations, reconsidered decisions,
organization determinations, or use other terms, but the term is not
relevant. We specifically requested comments from plans regarding the
feasibility of including such claims data, including any possible
timing issues.
The proposal included timeframe requirements for making these
various categories of data available through the standards-based API.
For MA organizations, proposed 42 CFR 422.119(b)(1)(i), (ii), and
(b)(2)(i) would require standards-based API access to all claims
activity pertaining to standardized adjudicated claims (including cost,
specifically provider remittances and enrollee cost-sharing) and
standardized encounter data for benefits covered by the plan (that is,
Medicare Part A and Part B items and services, Part D prescription
drugs if covered by the MA plan, and any supplemental benefits) no
later than one (1) business day after a claim is processed or the
encounter data are received by the MA organization. We used the terms
``adjudicated'' and ``processed'' interchangeably in this context.
For Medicaid state agencies and managed care plans, we proposed
that standardized claims data and encounter data would be required
(specifically at 42 CFR 431.60(b)(1) and (2)) through the API no later
than one (1) business day after the claim is processed or the data are
received. For State Medicaid agencies in connection with the FFS
program, we explained that the API would have to include all claims
data concerning adjudicated claims and encounter data from providers
(other than MCOs, PIHPs or PAHPs) that are paid using capitated
payments. The requirement for Medicaid managed care plans to provide
encounter data is specified, in conjunction with the incorporation of
the Medicaid FFS requirement into the Medicaid managed care
regulations, at 42 CFR 438.242(b)(6)(i) (finalized as Sec.
438.242(b)(5)(i) in this rule; see section VI.). Similarly, we proposed
that encounter data that Medicaid managed care plans must make
available through the API would include any data from subcontractors
and providers compensated by the managed care plan on the basis of
capitation payments, such as behavioral health organizations, dental
management organizations, and pharmacy benefit managers. The API for
Medicaid managed care plans would have to include all claims and,
therefore, encounter data that would be included regardless if it is
adjudicated or generated by the managed care plan itself, a
subcontractor, or a provider compensated on the basis of capitation
payments. All data would need to be obtained in a timely manner to
comply with these proposed requirements that these types of data be
available through the API no later than one (1) business data after a
claim is processed or the encounter data are received.
For CHIP agencies and managed care entities, access to standardized
claims data and encounter data would be required (specifically at 42
CFR 457.730(b)(1) and (2)) through the API no later than one (1)
business day after the claim is processed or the encounter data are
received. The proposal for CHIP state agencies (regarding FFS programs)
and CHIP managed care entities is identical to the proposal for
Medicaid state agencies (regarding FFS programs) and Medicaid managed
care plans. For QHP issuers on the FFEs, the proposed regulation at 45
CFR 156.221(b) would require claims and encounter data to be available
through the Patient Access API no later than one (1) business day after
adjudication or receipt, respectively.
Specifically regarding QHP issuers on the FFEs, at 45 CFR
156.221(b)(1)(i) and (ii), we proposed to require that QHP issuers
participating on the FFEs make available through the API standardized
data concerning adjudicated claims (including cost) and standardized
[[Page 25533]]
encounter data. Under proposed paragraph (b)(1)(i), we proposed that
QHP issuers on the FFEs would be required to make available
standardized data concerning adjudicated claim, provider remittance,
and enrollee cost-sharing data through the API within one (1) business
day after the claim is processed. Under proposed paragraph (b)(1)(ii),
we proposed that QHP issuers on the FFEs would be required to provide
standardized encounter data through the API no later than one (1)
business day after the data are received by the issuer.
As discussed in the CMS Interoperability and Patient Access
proposed rule (84 FR 7632 through 7633), the proposed timeframe--making
the data available to the third-party app with the approval and at the
direction of the patient through the API no later than one (1) business
day after processing a claim or receiving encounter data--would ensure
that data provided to the third-party app, and ultimately the patient,
through the API would be the most current data available. Providing the
most current data may be critical if the data are provided by an
enrollee to his or her health care provider to use in making clinical
decisions. As proposed, the claims and encounter data to be disclosed
would include information such as enrollee identifiers, dates of
service, payment information (provider remittance if applicable and
available), and enrollee cost-sharing. Our proposal did not exclude any
elements from the claims and encounter--or the clinical data--required
to be made available through the Patient Access API. The ability for
enrollees--created and facilitated by the API required under the
proposal--to access this information electronically would make it
easier for them to take it with them as they move from payer to payer
or among providers across the care continuum.
Regarding the provision of encounter data through the API no later
than one (1) business day after receiving the data, we noted that the
proposal would mean that a payer must rely on capitated providers
submitting their encounter data in a timely manner to ensure that
patients receive a timely and complete set of data. To the extent
providers do not submit in a timely manner, there would be a delay in
patients having access to their data. We recommended that MA
organizations, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs that would need this information in order
to meet the proposed API requirements in a timely manner should
consider whether their contracts with network providers should include
timing requirements for the submission of encounter data and claims so
that the payer can comply with the API requirements more timely. For
Medicaid and CHIP FFS programs, we encouraged states to consider other
means to ensure that necessary encounter data from providers is also
provided on a timely basis.
We summarize the public comments we received on making claims and
encounter data available via the Patient Access API and provide our
responses.
Comment: A few commenters expressed concern that there are no named
or mature industry FHIR-based standards available for representing and
exchanging claims information. One commenter requested CMS only require
a specific subset of claims information that would be most useful to
patients, suggesting patient name, diagnoses codes, procedure codes,
drug codes, service date(s), provider of service, and out-of-pocket
costs.
Response: We appreciate the commenters' concerns and
recommendations. We have been working with industry partners to ensure
the necessary FHIR standard and implementation guides as specified at
45 CFR 170.215 are now available to ensure that payers can fully
implement sharing claims data via a FHIR-based API, as we are
finalizing our proposal to have payers impacted by this rule make
claims and encounter data available via the standards-based Patient
Access API no later than one (1) business day after claims processing
or encounter data receipt. To further support payers as they work to
build the Patient Access API and map claims and encounter data for
exchange via a FHIR-based API, in partnership with industry, we have
worked to ensure relevant implementation guides and reference
implementations are available. A link to specific implementation guides
and reference implementations for claims and encounter data have been
produced and tested and can be found at https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Though not
mandatory, using these publicly available resources will reduce payer
burden as they work to prepare their data for exchange via a FHIR-based
API.
We also appreciate the recommendation to only include a subset of
claims information. However, we believe it is important for patients to
have all of their claims information in order to facilitate informed
decision making. Patients have a right to their claims data. While that
information currently can be obtained through various means, we decline
to require that only a subset of the available claims information be
available through the Patient Access API.
Comment: One commenter noted that health plans cannot verify the
accuracy of all information contained in a claim. This commenter
requested CMS should state that these policies do not mandate that
payers audit and correct all information furnished by health care
providers beyond what is currently necessary for existing rules,
regulations, and internal business purposes.
Response: We appreciate the commenter's concern. We agree that our
regulations, as proposed and as finalized, for this Patient Access API
do not require that payers do any additional audit or review of the
claims they receive beyond current practices. To the extent that payers
wish to, they may include a disclaimer or other notice to enrollees as
part of the API to indicate this. Such a disclaimer would be
permissible under these regulations.
Comment: A few commenters recommended that further standardization
work be done to improve the accuracy of the claims data field that
identifies the attributed health care provider administering services.
If this data element is accurate, commenters note it will help ensure
patients are reaching out to the right clinician. Commenters believe
this could reduce confusion when patients seek clarification or request
amendments to their health information.
Response: We appreciate the commenters' recommendation and will
evaluate potential future options to address this concern through our
work with HL7 and other industry partners. We do note, however, this
seems to be a data accuracy issue and not a standardization issue. That
said, we do strongly encourage all payers and providers to work
together to ensure the accuracy of these and all data.
Comment: A few commenters were concerned that claims data were not
accurate representations of clinical findings and therefore not
valuable in assisting patients in making health care decisions. These
commenters expressed fears that patients may misinterpret claims
information for health care decision-making when claims data serve a
payment use case.
Response: We appreciate the commenters' concerns. We do note,
however, that there is valuable information on the claim relevant to a
patient's care and care history that can inform health care decision-
making. For instance, this information provides patients with the names
of the providers they have visited, when they visited
[[Page 25534]]
certain providers for certain medical needs, when tests or procedures
were conducted, and more information about these tests and procedures.
This information alone is very useful to patients as they plan and
discuss future care with their providers. Also, in the absence of
clinical data (which is required to be provided through the Patient
Access API under this rule only if the payer maintains such data),
claims and encounter data provide a basis of information for patients
to work with and get value from.
Comment: One commenter sought clarification on the scope of
Medicaid-covered services to which the requirement to make claims and
encounter data available through an API applies. This commenter
recommended that CMS specify that this requirement to make claims and
encounter data available does not apply to long-term care waiver
services, such as in-home care, meal preparation or delivery, and
transportation. The commenter stated that providing claims and
encounter data for these services through the API would be cumbersome
for a variety of reasons including the fact that long-term care waiver
services tend to have frequent (daily or weekly) utilization by each
participant, which would result in an unwieldly number of claims or
encounters being provided through the API for each individual.
Response: We confirm that under 42 CFR 431.60(b)(1) and (2), 42 CFR
457.730(b)(1) and (2), 42 CFR 438.242(b)(5) (proposed as Sec.
438.242(b)(6); see section VI.), and 42 CFR 457.1233(d), states and
managed care plans must make adjudicated claims and encounter data
available through the API for all Medicaid- or CHIP-covered services,
including long-term services and supports (LTSS). This requirement
extends to in-home care, transportation services, and all other
Medicaid- or CHIP-covered services for which a claim or encounter is
generated and adjudicated. We do not believe the number of claims
generated by LTSS will make the data unwieldy or unusable by the
beneficiary. We believe that the benefits of providing claims and
encounter data to beneficiaries so they can make better health care
decisions and know which providers have been paid for providing
services to them is no less important simply because it is a frequently
provided service. Some beneficiaries may find having such data on
frequently rendered services more important since billing with such
frequency may make it more prone to errors, fraud, waste, and abuse.
Comment: Several commenters were concerned with the appropriateness
of sharing certain claims information, particularly specific costs such
as negotiated rates that commenters believed could reveal trade secrets
or be considered proprietary information. These commenters requested
CMS ensure that confidential, proprietary cost information is excluded
from the proposed requirements. One commenter believed that disclosure
of information such as negotiated rates would lead to higher health
prices in the industry and other anticompetitive behavior.
Specifically, this commenter gave the example where dominant payers in
a geographic or other market use this price information to deter
competitors from entering into value-based payment arrangements. One
commenter also requested that third-party apps be prohibited from
aggregating or using any cost information for purposes other than
transfer of the data to the patient.
Response: We note that we take our obligations seriously to protect
from disclosure information that is protected under current law. We
also affirm our commitment to safeguarding data protected by law from
inappropriate use and disclosure. We understand the concerns raised
around sharing cost data. We appreciate the commenters' concerns,
however we reiterate that we are committed to giving patients access to
their health information, and we believe the benefits of making this
information available to patients through third-party apps outweigh
these concerns. It is critical for patients to better understand health
care costs and be able to plan and budget as well as possible. Having
cost information, which is already accessible to patients, available to
them in a more easy-to-understand presentation would allow patients to
get the maximum benefit from this information. If a patient uses an app
to view their health information that does not clearly indicate it will
not use this cost data for any other purpose, there is a chance the app
could aggregate or otherwise analyze the data, assuming the single app
has access to enough patient data in a given market or patients who use
a particular payer or plan, to make such an analysis possible.
Appreciating patients already have access to this information and
understanding the possibility for secondary uses of such data, we are
finalizing the policy as proposed to require plans to share adjudicated
claims, including provider remittances and enrollee cost-sharing
information, via the FHIR-based Patient Access API so patients can
continue to access this information in ways that will be most useful to
them. We reiterate, however, that we do not have the authority to
directly regulate third-party apps.
Comment: A few commenters also indicated that even if patients had
access to price information, they would not have the ability to
negotiate or impact health care costs. One commenter noted that
patients would find prospective cost information more valuable than
retrospective payment information.
Response: We appreciate the commenters' input. With access to price
information, patients who would have cost sharing that is tied to such
prices can be more informed consumers of their health care. Even
patients who have no direct financial responsibility tied to these
prices can benefit from knowing the information in the event their
insurance coverage changes in the future or so they can appreciate the
relationship between the services they receive and their cost to the
health care system. It is important for patients to understand as much
as they can about their care. For instance, understanding the costs of
past services can help them plan for future services. As a result, this
information has great value to patients even if it does not directly
impact their ability to specifically influence what they pay for their
care, or tell them exactly how much their next service will cost out of
pocket.
Comment: Many comments were received regarding price transparency,
generally, and were beyond the scope of the discussion in this rule.
Overall, these were out of scope for this final rule as they referenced
other rulemaking activities within HHS.
Response: We appreciate the commenters' strong interest in greater
price transparency in health care. We strongly support the
Administration's and Department's efforts to continue to move toward
greater transparency to help health care consumers make the most
informed decisions. We point to the recent release of the CY 2020
Hospital Outpatient Prospective Payment System Policy Changes and
Payment Rates and Ambulatory Surgical Center Payment System Policy
Changes and Payment Rates. Price Transparency Requirements for
Hospitals To Make Standard Charges Public final rule (84 FR 65524).
This final rule establishes requirements for all hospitals operating in
the United States to make their standard charges available to the
public under section 2718(e) of the PHSA, as well as an enforcement
scheme under section 2718(b)(3) to enforce those requirements.
Specifically, sections 2718(b)(3) and 2718(e) of the PHSA require that
for each year each hospital operating within the United States
[[Page 25535]]
establish (and update) and make public a list of the hospital's
standard charges for items and services provided by the hospital,
including for diagnosis-related groups established under section
1886(d)(4) of the Act. This final rule requires hospitals (as defined
at 45 CFR 180.20) to establish, update, and make public a list of their
gross charges, payer-specific negotiated charges (including the de-
identified minimum and maximum negotiated charges), and discounted cash
prices for all items and services online in a single digital file that
is in a machine-readable format, as well as their payer-specific
negotiated charges (including the de-identified minimum and maximum
negotiated charges) and discounted cash prices (or gross charges, if a
discounted cash price is not offered by the hospital) for a more
limited set of shoppable services online in a consumer-friendly format.
We also direct commenters to the tri-agency Transparency in
Coverage proposed rule (84 FR 65464) for additional proposals to
further price transparency.
Comment: Some commenters generally opposed the proposal to make
claims and encounter data available through a standards-based API no
later than one (1) business day after receiving it. Some commenters
suggested the proposed data availability timeframe is challenging due
to the timeline for sharing adjudicated claims, in particular, noting
the different timeframes for payment discharge, benefit determination,
and settlement of the patient account. One commenter noted the reliance
on third-party contractors to adjudicate claims and the time required
to migrate data from one system to another and that validation could
take longer than one (1) business day. Several commenters expressed
concern about the timeframe based on revised determinations or revised
decisions triggered by data that arrives after the initial
determination. One commenter specifically questioned the value of
third-party application use of claims data when an enrollee has filed
an appeal and is awaiting a reconsideration decision. One commenter
recommended CMS only permit finalized claims where a determination has
been made be available to be shared via the Patient Access API.
Some commenters specifically referenced the reliance of MA plans on
pharmacy benefit management organizations for the administration of
Part D benefits as a factor in the ability to make these claims data
available within one (1) business day after receiving them. Other
commenters referenced the Explanation of Benefit requirements that
provide a timeframe for information adjustment, which means that the
final information may not be available in one (1) business day.
Several commenters suggested an alternative timeframe of 3 or 5
days for vendor-adjudicated claims, citing time and costs. Some
commenters recommended a grace period for plans when there is a delay
due to delayed provider encounter data submission. In addition, some
requested an exception for specific conditions attributable to certain
claims and encounter data. Other commenters recommended that CMS work
with stakeholders to determine an appropriate timeframe for making
claims and encounter data available via the Patient Access API.
Response: We appreciate the commenters' concerns and
recommendations, including comments regarding claims that may be under
appeal. We are finalizing this policy as proposed that payers make
available through the Patient Access API, no later than one (1)
business day after the information is received: (1) Adjudicated claims,
including claims data for payment decisions that may be appealed, were
appealed, or are in the process of appeal, and (2) encounter data. We
reiterate that this is one (1) business day after the claim is
adjudicated or encounter data are received. This allows for potential
delays in adjudication or delays in providers submitting their
encounter data. It does not require payers and providers to change
their contractual relationships or current processes for receipt,
though we strongly encourage payers and providers to work together to
make patient data available in as timely a manner as possible.
We believe it is valuable to patients to be able to have their data
in as timely a manner as possible. Having access to this information
within one (1) business day could empower patients to have the
information they need when they need it to inform care coordination and
improve patient outcomes. If a patient needs to get follow-up care,
having the information relevant to their previous visit is important
and valuable. API technology allows this exchange to happen more
quickly and efficiently, and we believe it is important to leverage
this technological opportunity to ensure patients have the most current
information about their care.
It is also important for patients to get this information timely
even if there is the possibility of a change in determination due to
appeal or other factors. We conducted research to evaluate the maturity
of claims to inform researchers using the Chronic Conditions Data
Warehouse (CCW) data.\30\ This research indicates that nearly half of
all Medicare FFS or carrier claims are submitted once and unchanged,
and nearly 85 percent of inpatient claims are never adjusted. For
carrier claims, 99 percent are fully mature at 10 months; and of non-
inpatient claims that were adjusted, 0.13 percent or less had the
diagnosis code changed. What this research shows is that many claims
remain unchanged, and those that do take more that 3 or 5 days after
adjudication to begin to mature. This wait would not provide patients
more accurate or complete data; it would only delay their ability to
benefit from access to their information. Patients have a right to see
the full lifecycle of their claims and encounter information, and we
believe they should be able to have access to their information as soon
as it is available. Even if the payment amounts may change due to
appeal, for instance, the services received and the providers who
rendered them are less likely to change. This is very useful
information and could impact care decisions and facilitate better care
coordination if available as soon as possible. We do appreciate that
there are many factors that could influence when some data are
available. Again, we encourage payers to work with health care
providers and third-party contractors to ensure timely data processing.
---------------------------------------------------------------------------
\30\ Chronic Conditions Data Warehouse. (2017, October). CCW
White Paper: Medicare Claims Maturity (Version 2.0). Retrieved from
https://protect2.fireeye.com/url?k=7bd1837b-2785aa50-7bd1b244-0cc47a6d17cc-590a0fb580f6d595&u=http://www2.ccwdata.org/documents/10280/19002256/medicare-claims-maturity.pdf.
---------------------------------------------------------------------------
Comment: Several commenters expressed concern that the proposed
timeframe for payers to share claims and encounter data with patients
could require providers to accelerate their submissions to payers
triggering additional requirements in existing contracts for the
submission of claims and encounter data. Some commenters cautioned
there could be potential downstream consequences such as narrowing a
payer's provider network. One commenter recommended removal of proposed
rule preamble language suggesting that MA plans, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs could
consider adding time requirements for submission of claims and
encounter data in their contracts with providers. One commenter
recommended CMS provide sample contract language or dedicate resources
[[Page 25536]]
to educating providers about the intent of these possible contract
revisions.
Response: We appreciate the commenters' concerns and
recommendations. As discussed in the CMS Interoperability and Patient
Access proposed rule, we do appreciate that some payers may consider
adding timeframes to contracts with providers to help ensure patients
get timely access to their claims and encounter data. Again, we
strongly encourage providers to make this information available in as
timely a fashion as possible to best assist patients in having access
to their health information. Adding language to contracts is one way
for payers and providers to work together to ensure patients get this
valuable information in as timely a manner as possible. We believe
providers can benefit as well if this information is available sooner;
it could be shared with them for the purposes of care coordination in a
more timely manner, too. It may take some time for providers to improve
internal efficiencies to meet potential new timeline requirements, but
we believe the long-term benefit outweighs potential short term
implementation burden. We do note, however, that the policy being
finalized in this rule is specific to payers making adjudicated claims
and encounter information available to patients via the Patient Access
API within one (1) business day after the payer receives the
information. Any additional timeframes are between the payers and their
providers.
(2) Provider Directory Data
We proposed at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3),
438.242(b)(6)(ii), 457.730(b)(3), and 457.1233(d)(2)(ii) that the
required Patient Access API make available provider directory data,
including updates to such data. The proposal at 45 CFR 156.221 would
not require QHP issuers to permit third-party retrieval of provider
directory (and preferred drug list information) because such
information is already required to be provided by QHP issuers on the
FFEs.
For MA organizations, at proposed 42 CFR 422.119(b)(1)(iii), we
proposed to specify that MA organizations make specific provider
directory information for their network of contracted providers
accessible through their Patient Access APIs: The names of providers;
addresses; phone numbers; and specialty. This information is the same
information MA organizations are already required to disclose to their
enrollees under 42 CFR 422.111(b)(3) and make available online under 42
CFR 422.111(h)(2)(ii). As proposed, MA organizations would be required
to ensure the availability of this information through the Patient
Access API for all MA plans. We noted that including this information
in a standards-based API allows non-MA third-party applications to
consume, aggregate, and display this data in different contexts,
allowing patients to understand and compare plan information in a way
that can best serve their individual needs. As proposed, MA plans would
be required to update provider directory information available through
the API no later than 30 business days after changes to the provider
directory are made.
Under proposed 42 CFR 431.60(b)(3) and 457.730(b)(3), state
Medicaid and CHIP agencies respectively would be required to make
provider directory information available through the Patient Access
API, including updated provider information no later than 30 calendar
days after the state receives this provider directory information or
updates to provider directory information. The proposed regulation for
Medicaid managed care plans at 42 CFR 438.242(b)(6) (finalized as Sec.
438.242(b)(6) in this final rule; see section IV. of this final rule)
and for CHIP managed care entities at 42 CFR 457.1233(d)(2) would
require MCOs, PIHPs, and PAHPs to comply with the same timeframe, with
the addition of specific provider directory information as noted in 42
CFR 438.242(b)(6)(ii) and 457.1233(d)(2)(ii). For Medicaid managed care
plans and CHIP managed care entities, we proposed the provider
directory information available through the API must include all
information that is specified in 42 CFR 438.10(h)(1) about provider
directories for disclosure to managed care enrollees. We proposed that
the Patient Access API be updated with new provider directory
information within 30 calendar days from when the updated information
is received by the state (or the managed care plan under 42 CFR
438.242(b)(6) (finalized as Sec. 438.242(b)(6) in this final rule; see
section IV. of this final rule) and Sec. 457.1233(d)(2)) to be
consistent with existing Medicaid managed care rules at 42 CFR
438.10(h)(3). We proposed that the API implemented by the state
Medicaid agency would include the data elements specified for
disclosure by Medicaid state agencies in section 1902(a)(83) of the
Act; we proposed at 42 CFR 438.242(b)(6)(ii) that the Patient Access
API implemented by Medicaid managed care plans would have the data
elements specified for disclosure at 42 CFR 438.10(h)(1). For CHIP
agencies that operate FFS systems and CHIP managed care entities at 42
CFR 457.730(b)(3) and 457.1233(d)(2)(ii), respectively, we also
proposed that provider directory data be available through the API no
later than 30 calendar days after receipt of updated information.
We did not propose a similar requirement for QHP issuers on the
FFEs. As discussed in the CMS Interoperability and Patient Access
proposed rule (84 FR 7633), these issuers are already required, under
45 CFR 156.230(c) and implementing guidance, to make provider directory
information accessible in a machine-readable format. Because this
information is already highly accessible in this format, we noted that
we did not believe the benefits of making it also available through a
standards-based API outweigh the burden for QHP issuers on the FFEs.
However, we sought comment as to whether this same requirement should
apply to QHP issuers, or if such a requirement would be overly
burdensome for them.
To avoid unnecessary duplication of effort and potential confusion,
we are not finalizing the proposal to include provider directory
information in the Patient Access API. Instead, we are finalizing the
inclusion of this information (consistent in scope as proposed for the
Patient Access API) in the public facing Provider Directory API
discussed in section IV. of this final rule, which requires MA
organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP
FFS programs, and CHIP managed care entities to provide public access
to complete and accurate provider directory information at 42 CFR
422.120, 431.70, 438.242(b)(6), 457.760, and 457.1233(d)(3).
Appreciating that the comments we received on provider directory
information and APIs addressed issues relevant to both including these
data in the Patient Access API discussed in this section of the final
rule, but more so making this information more widely available through
the Provider Directory API as discussed in section IV. of this final
rule, all comments and our responses related to provider directory
information via APIs can be found in section IV. of this final rule.
(3) Clinical Data Including Laboratory Results
Regarding the provision of clinical data, including laboratory
results, we proposed at 42 CFR 422.119(b)(1)(iv) that MA organizations
make clinical data, such as laboratory test results, available through
the API if the MA organization maintains such data. We also proposed in
paragraph (c)(3)(i) that
[[Page 25537]]
the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213,
be used as the content and vocabulary standard for the clinical data
made available through the API. We intended the proposal to mean that
the data required under paragraph (b)(1)(iv) be the same as the data
that is specified in that content and vocabulary standard defined at 45
CFR 170.213. In effect, we proposed that at a minimum any clinical data
included in the USCDI standard, proposed by ONC for HHS adoption at 45
CFR 170.213, be available through the Patient Access API if such data
are maintained by the MA organization. We recognized that some MA
organizations receive this information regularly, or as a part of their
contracted arrangements for health services, but that not all MA
organizations do. Therefore, we proposed that this requirement would
apply to MA organizations, regardless of the type of MA plan offered by
the MA organization, but only under circumstances when the MA
organization receives and maintains this clinical data as a part of its
normal operations. The proposed requirement aligned with existing
regulations at 42 CFR 422.118, which required MA organizations to
disclose to individual enrollees any medical records or other health or
enrollment information the MA organizations maintain with respect to
their enrollees. We proposed that this data be available through the
API no later than one (1) business day from its receipt by the MA
organization.
Similarly, the proposed regulations for Medicaid and CHIP FFS
programs and managed care plans (proposed 42 CFR 431.60(b)(4) and Sec.
457.730(b)(4)), required provision through the Patient Access API of
standardized clinical data, including laboratory results, if available,
no later than one (1) business day after the data are received (by the
state or the managed care plan or entity). We noted that this would
ensure that data provided through the API would be the most current
data available, which may be critical if the data are being shared by
an enrollee with a health care provider who is basing clinical
decisions on these data. As noted, like proposed 42 CFR 422.119(c), the
Medicaid and CHIP regulations proposed compliance with the regulations
regarding the USCDI standard, proposed by ONC for HHS adoption at 45
CFR 170.213, as the content and vocabulary standard for the clinical
data available through the Patient Access API; therefore, we proposed
that at a minimum any clinical data included in that USCDI standard be
made available through the Patient Access API within one (1) business
day of receipt. For state agencies managing Medicaid or CHIP FFS
programs, we proposed that such data be made available through the API
under the proposal if the state maintains clinical data. The proposed
regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6)
(finalized as Sec. 438.242(b)(5) in this rule; see section VI.) and
CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs,
PIHPs, and PAHPs to comply with the same standard in terms of the scope
of information and the timing of its availability through the Patient
Access API; the limitation that the clinical data be maintained by the
entity for it to be required to be sent via the Patient Access API
would carry through to managed care plans and entities under the
proposal.
Proposed 45 CFR 156.221(b)(1)(iii) would require QHP issuers on the
FFEs to also make these clinical data, including laboratory results,
available via the Patient Access API, with the approval and at the
direction of the enrollee, if the QHP maintains such data.
We recognized not all of the entities subject to this requirement
have uniform access to this type of data and sought comment on what
barriers exist that would discourage them from obtaining, maintaining,
and making these data available through the Patient Access API.
We summarize the public comments we received on the inclusions of
clinical data, specifically the data included in the USCDI standard,
via the Patient Access API and provide our responses below.
Comment: Several commenters expressed concerns that payers are
typically not the original source of clinical information, including
data elements that are part of the USCDI, and would not be the best
source of the most accurate clinical data for patients. These
commenters noted concerns with data accuracy provided by payers who are
typically secondary sources of this clinical information and explained
that payers do not verify this information. One commenter believed the
originator should be providing the data, or that payers should be
allowed to indicate the provenance of the data and where to direct
questions regarding data accuracy. There was concern that the
administrative burden on providers could increase due to patient
inquiries and requests to correct or clarify their data.
Response: We appreciate the commenters' concerns and
recommendations. We understand that payers are not the source of this
clinical information; however, payers do maintain clinical data that
can be of great value to patients. We note that provenance is one data
class within the USCDI. As such, this information would be available to
patients. We also note, that as discussed above, we intend to provide
suggested content for educational information that payers will be able
to tailor and use to communicate with their patients about the Patient
Access API. Payers can choose to indicate the part of a data exchange
that was received from an outside source so the receiving party
understands where to direct questions. This will also help patients
understand how to address incorrect information as it can be made clear
where questions should be directed. Payers are under no obligation
under this Patient Access API requirement to validate or correct
clinical data received from another source; and, providers are under no
obligation to submit updated data to payers should patients suggest
there is an error in their data. We do encourage payers and providers
to continually work to ensure the accuracy of the patient data they
maintain and share to the extent possible. The Patient Access API must
include all of the specified clinical information for the enrollee
maintained by the payer with a date of service on or after January 1,
2016.
Comment: A few commenters were concerned that payers could use
clinical data to discriminate against providers, such as through
discriminatory reimbursement models, for instance offering lower
reimbursement rates for certain types of care that a physician deems
necessary or in the best interest of the patient based on the data
viewed about the doctor and the care they provide.
Response: We appreciate the commenters' concerns; however, we note
the fact that some payers are already automatically accessing a
physician's EHR for other purposes, either as an elective offering or
through contractual requirements. As a result, additional data than is
required to meet the requirements of this final rule are already being
shared between providers and payers. We reiterate that payers are not
entitled to receive information from a health care provider if such
information is protected by applicable federal, state, or local law
from disclosure to the payer. This final rule does not change any such
existing legal obligations.
Comment: A few commenters expressed concerns over provider
liability for the quality or accuracy of
[[Page 25538]]
clinical data and for being given certain sensitive patient diagnosis
and problems information, particularly if the provider is a downstream
recipient of such data.
Response: We appreciate the commenters' concerns, but reiterate
that the policies finalized in this regulation do not change any payer
or provider's obligations to abide by existing federal and state
regulations and law, including 42 CFR part 2, which governs certain
substance use disorder records, which are some of the most sensitive
health information. We note, however, that the patient can direct the
entity to transfer this sensitive data upon their designation of a
recipient, or may provide consent or authorization for the transfer, as
applicable. As a provider, and likely as a covered entity under HIPAA,
providers are experienced in handling sensitive data. Access through an
API will provide a new route to receiving sensitive data, not add to
the burden of protecting such information, given the continued need to
maintain compliance with all applicable rules and regulations. These
policies just allow this information to be transmitted via an API with
the approval and at the direction of the patient.
Comment: Some commenters expressed concern that patients may not
understand, or may be confused by, the health information that will be
available, and questioned if this information will all be relevant to
patients. A few commenters recommended that educational materials and
resources be developed to ensure that the data are useful and do not
cause alarm.
Response: We appreciate the commenters' concerns and
recommendations. We appreciate that every patient may not understand
every piece of information in their medical record. We intend to
provide suggested content for educational materials or other patient
resources that payers can tailor and use to ensure that patients have
information about how to accurately and productively navigate their
health care information, as further discussed below in this section. It
is important for patients to have access to their records, review them,
and have an opportunity to raise questions and seek clarification about
the information maintained in them.
Comment: One commenter requested CMS explain the requirement that
MA organizations make clinical data available through the Patient
Access API if the entity ``manages such data,'' particularly what is
meant by ``manages such data.'' This commenter noted that providers
manage clinical data and requested clarification of whether the
requirement applies to MA organizations. Another commenter expressed
similar concerns and inquired whether ``managed by the payer'' would
include only lab results or all clinical data. Commenters questioned if
``manage'' meant ``electronically stored in a database under the
payer's control''?
Response: We appreciate the commenters' request for additional
information. As noted in the CMS Interoperability and Patient Access
proposed rule, payers, including MA organizations, need to make these
data available through the API when the payer receives and maintains
these data as a part of its normal operations (84 FR 7633). We used the
verb ``manages'' to communicate that this proposed requirement would
apply when the payer has access to the data, control over the data, and
the authority to make the data available through the API. In order to
more closely align with how the relevant HIPAA Privacy Rule requirement
refers to such activity, we are finalizing the regulation text at 42
CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), as well as 45
CFR 156.221(b)(1)(iii) with the verb ``maintains'' in place of the verb
``manages''. As such, we define ``maintain'' to mean the payer has
access to the data, control over the data, and authority to make the
data available through the API.
Comment: One commenter questioned if Medicaid agencies will be
required to provide clinical data regardless of the type of transaction
by which the agency received the data.
Response: We confirm that Medicaid and CHIP agencies, and their
respective managed care plans, will be required under 42 CFR
431.60(b)(3), 457.730(b)(3), 438.242(b)(5), and 457.1233(d) to provide
clinical data through the API if the state or managed care plan
maintains such clinical data. Clinical data subject to this requirement
includes laboratory results and other clinical data, and must be made
available through the Patient Access API regardless of the type of
transaction by which the state or managed care plan received the data
originally. However, if the data were received under the payer-to-payer
data exchange requirement finalized in section V. of this final rule at
42 CFR 422.119(f), 438.62(b)(1)(vi), and 457.1216, and 45 CFR
156.221(f), then the payer would only need to share the clinical data
received via the payer-to-payer data exchange via the Patient Access
API if the data were received from another payer via a standards-based
API. As required at 42 CFR 422.119(f)(1)(iii), 438.62(b)(1)(vi)(C), and
457.1216 and 45 CFR 156.221(f)(1)(iii), data received via the payer-to-
payer data exchange only need to be made available to share in the
electronic form and format they were received from another payer. If a
payer receives data specifically for the payer-to-payer data exchange
via an API, they can then make these data available via the Patient
Access API without additional burden--the payer will not be required
per this final rule to take data from another payer received as a
direct result of the payer-to-payer data exchange policy and prepare it
to be shared via the Patient Access FHIR-based API; the payer will only
be required to incorporate that data into the enrollee's record so that
it can be shared with a new payer, if requested by the patient, in the
electronic form and format received. Appreciating concerns raised
around the burden of preparing data for exchange via an API, we have
provided this guidance to minimize this burden. We note that Medicaid
and CHIP state agencies are not subject to the payer-to-payer data
exchange requirement in this rulemaking, as we did not propose this
policy for these entities.
Comment: A few commenters recommended that patients have access to
detailed and accurate lab test and results information through the
Patient Access API. A few commenters were not supportive of CMS'
proposal that laboratory information be made available only where
available. One commenter recommended that these same API requirements
apply to laboratories providing service to Medicare and Medicaid
patients as any provider receiving reimbursement for medical services.
One commenter expressed concern that lab information is not
standardized and may be difficult to exchange.
Response: We appreciate the commenters' concerns and
recommendations. These regulations requiring the Patient Access API and
detailing the data available through the Patient Access API, as
proposed and as finalized, do not apply to laboratories or to any
providers--these requirements are specific to payers as detailed above,
but we will review the recommendations made for potential future
consideration.
Regarding concerns about standardized data exchange of laboratory
information, the regulations finalized in this rule provide the content
and vocabulary standards at 45 CFR 170.213 needed to address sharing
laboratory data through the API. Implementation guidance, now
[[Page 25539]]
available at https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index, though not mandatory, can be used to further
support sharing these data utilizing the content and vocabulary
standards adopted in this rule. These implementation guides and
reference implementations provide additional support to help payers
implement this policy in a standardized way that facilitates
interoperability.
Comment: Some commenters were concerned about the proposed timeline
and challenges specifically because of the nature of laboratory data,
specifically laboratory results. Final results can replace preliminary
results, and laboratory data coming from third parties can take time to
receive. Additionally, there may be conflicting disclosure requirements
that permit up to 30 days to pass before laboratory data are available
to a payer.
Response: We appreciate the commenters' concerns. We do understand
that there are many factors that could influence when some data are
available. However, we reiterate that this Patient Access API policy
requires the information to be shared no later than one (1) business
day after it is received by the regulated payer. If it takes additional
time for laboratory information to be provided to a payer, that does
not impact the payer's obligation to make the data available via the
Patient Access API no later than one (1) business day after the receipt
of the information by the payer. Therefore, we strongly encourage all
payers and providers to work to make data available in as timely a
fashion as possible to ensure an optimally informed health care
ecosystem.
Comment: Many commenters supported the proposal to require
providing the information in the USCDI via the Patient Access API.
Commenters supported alignment with ONC on this and encouraged
additional alignment across government data sets. Commenters also
supported the data classes and associated standards in the proposed ONC
USCDI. One commenter specifically noted support for the pediatric vital
signs proposed as part of the USCDI. A few commenters recommended the
addition of data classes that are already proposed as part of the
USCDI, such as clinical notes, provenance, and unique device
identifiers. A few commenters strongly supported the inclusion of notes
in the USCDI, citing several studies of the benefits of patients having
this information including, but not limited to, patient literacy,
empowerment, health care coordination, medication adherence, and
safety. One commenter recommended only final notes be considered
applicable to the USCDI and that the imaging note be removed from the
types of required notes. This commenter also indicated that notes that
contain sensitive information were likely subject to a variety of state
privacy laws. A few commenters noted further standardization work was
needed for provenance data fields.
Response: We appreciate the commenters' support and
recommendations; we have shared these comments about the USCDI with ONC
for future consideration. We agree that aligning with ONC and
finalizing exchange of the USCDI as defined at 45 CFR 170.213 in ONC's
21st Century Cures Act final rule (published elsewhere in this issue of
the Federal Register) has many benefits and will help us reach our
interoperability goals. We refer readers to ONC's final rule for the
specifics of exactly how the USCDI standard is being finalized by HHS.
As finalized here, the clinical data required to be made available
through the Patient Access API at 42 CFR 422.119(b)(1)(iii),
431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii) at a
minimum are the USCDI version 1 as defined at 45 CFR 170.213 and
specified in this rule at 42 CFR 422.119(c)(3)(i), 431.60(c)(3)(i), and
457.730(c)(3)(i), and 45 CFR 156.221(c)(3)(i). We do note the policies
finalized in this regulation do not alter obligations under existing
federal and state laws. We reiterate that we are working closely with
HL7 and other partners leading the effort to develop standards to
ensure helpful guidance is available for payers to consult as they work
to implement the policies being finalized in this rule. Again, we note
that, though not mandatory, we are providing a link to specific
implementation guides and reference implementations that provide
valuable guidance to support payers as they work to implement the
Patient Access API: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
Comment: One commenter requested that all the data elements in the
USCDI be specifically enumerated in the regulation text of this final
rule for clarity. A few commenters recommended CMS and ONC limit the
definition of electronic health information to solely the data classes
included in the USCDI. Another commenter did not believe this
definition should be limited to identifiable information. One commenter
suggested that the definition of electronic health information should
include real price information.
Response: We appreciate the commenters' recommendations. We are
finalizing our regulation text that requires use of the standard
specified at 45 CFR 170.213 in ONC's separate rulemaking to ensure
alignment and consistency across the two regulations. That specific
standard is currently the USCDI version 1 and therefore the USCDI will
be the initial standard applicable under this final rule. Additional
information about the data classes and data elements included in USCDI
can be found at http://www.healthit.gov/USCDI. We continue to use
``electronic health information'' as defined by ONC at 45 CFR 171.102.
With regard to specifically listing the data elements in the USCDI, we
believe cross referencing ONC's regulation better supports our goal of
aligning with ONC's policy regarding this information.
Comment: One commenter did not support the proposed requirement to
provide patients with the USCDI data because the commenter believed it
was not feasible for payers. The commenter indicated that payers do not
typically collect clinical data. One commenter recommended that CMS use
FHIR bundles, or a collection of relevant FHIR resources, rather than
the USCDI. One commenter was concerned with how free text fields would
be addressed in the USCDI. One commenter expressed concern that CMS
would require the use of non-HIPAA standards in the USCDI for providing
data to patients.
Response: We appreciate the commenters' concerns and
recommendations. We acknowledge that payers do not maintain all
clinical data for all patients and our regulation text at 42 CFR
422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), and 45 CFR
156.221(b)(1)(iii), as finalized, specifically limits the obligation to
make clinical data available through the Patient Access API to those
payers that maintain any such data. If a payer subject to these
regulations (including the Medicaid and CHIP managed care plans that
are subject to regulations that incorporate these requirements)
maintain the data elements specified in this final rule, these data
elements must be shared as noted in this final rule using the standards
indicated. If payers do maintain valuable clinical data about patients,
patients have a right to these data. This is a first step in providing
patients with information from their medical record in an efficient
electronic format.
We appreciate the recommendation to look at alternatives to the
USCDI, but we believe it is critical for interoperability to align with
ONC and see great value
[[Page 25540]]
in the continued coordination between CMS, ONC, and partners such as
HL7 to ensure helpful guidance is available for payers to consult as
they work to successfully implement these final rule policies. To this
end, we again note that we have provided a link to specific
implementation guides and reference implementations that, though not
mandatory, can be used to support consistent implementation. We refer
readers to additional information on the USCDI at http://www.healthit.gov/USCDI and available guidance at https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index to best
understand how to implement all data classes and elements included in
the USCDI including text fields. Regarding the use of non-HIPAA versus
HIPAA standards, we do not believe there is a conflict, and we refer
readers to the discussion of Administrative Simplification transaction
standards in section III.C.2.b. of this final rule for more
information.
Comment: One commenter suggested that standards development
organizations such as HL7 would be better positioned to support data
standardization rather than the proposed USCDI approach. A few
commenters noted there are different use cases for various data types
and that coordination is required to expand the data in the USCDI. One
commenter recommended CMS allow voluntary extensions to data sets
outside of the USCDI to support the growth of new standards and data
types from a payer perspective.
Response: We appreciate the commenters' recommendations. In
addition, we appreciate the valuable role of standards development
organizations, like HL7, and reiterate our commitment to working with
such partners as industry develops the necessary standards and
associated guidance to implement the policies being finalized in this
rule. We will continue to refer to the USCDI as finalized by HHS in
ONC's 21st Century Cures Act final rule (published elsewhere in this
issue of the Federal Register) at 45 CFR 170.213 to ensure alignment
and consistency across the two regulations. We further refer readers to
additional information about the USCDI and the expansion process as
defined by ONC at http://www.healthit.gov/USCDI. We note that this
expansion process is a consensus process that allows for public input
and comment and strongly recommend stakeholders continue to engage in
this valuable process. This coordination and consensus is a cornerstone
of our interoperability efforts. We also note that the data elements
required in this final rule represent the minimum data that must be
shared under our finalized policy through a payer's Patient Access API.
We strongly encourage payers to share more data as the more data that
patients have access to, the more they will benefit from this access.
We agree that continuing to push these limits will spur innovation and
growth.
Comment: A few commenters requested additional information
regarding the definitions of terminology used when discussing the USCDI
in the CMS Interoperability and Patient Access proposed rule. One
commenter requested more information on the meaning of ``state
agencies,'' in reference to ``any clinical data included in the USCDI
standard . . . be available through the API,'' and if this meant that
if the state agency managed an immunization registry it would be
required to make the data available through an API. Another commenter
requested CMS to provide more information about the use of ``forward''
(in the preamble) versus ``send'' (in the regulatory text) regarding
the USCDI, including whether the information needs to be available to
the receiving payer and whether use of a trusted exchange network is
required.
Response: We appreciate the commenters' requests for additional
information. We note that the term ``state agencies'' in this instance
in the proposed rule (84 FR 7634) refers to those state agencies that
manage Medicaid and CHIP programs. If a Medicaid or CHIP state agency
has immunization data in connection with its Medicaid program or CHIP
as defined in the USCDI, these data would be required to be available
via the Patient Access API per our proposal as finalized. We note that
in section V. of this final rule, we require the exchange of the USCDI
between payers subject to this regulation; this payer-to-payer data
exchange does not require the use of an API. As finalized, our policies
do not require the use of a trusted exchange network. Regarding the use
of terms ``forward'' and ``send,'' we note this means that the data
must be exchanged with the patient as specified here in section III. of
this final rule or between payers as discussed in section V. of this
final rule.
(4) Drug Benefit Data, Including Pharmacy Directory, and Formulary Data
We proposed that drug benefit data, including pharmacy directory
information and formulary or preferred drug list data, also be
available through the Patient Access API at proposed 42 CFR
422.119(b)(2)(ii) and (iii), 431.60(b)(5), and 457.730(b)(5). (Our
proposal for providing prescription drug claims through this API is
discussed in section III.C.2.c.(1) of the CMS Interoperability and
Patient Access proposed rule (84 FR 7632).) As previously discussed,
Medicaid managed care plans would be required by 42 CFR 438.242(b)(6)
(finalized as Sec. 438.242(b)(5) in this rule; see section VI.) to
comply with the requirement at 42 CFR 431.60(b)(5), and CHIP managed
care entities would be required by 42 CFR 457.1233(d)(2) to comply with
the requirement at 42 CFR 457.730(b)(5).
We proposed at 42 CFR 422.119(b)(2)(ii) and (iii) that MA
organizations offering MA-PD plans must make available through the API
the following pharmacy benefit data: (1) Pharmacy directory data,
including the number, mix (specifically the type of pharmacy, such as
``retail pharmacy''), and addresses of pharmacies in the plan network;
and (2) formulary data including covered Part D drugs and any tiered
formulary structure or utilization management procedure which pertains
to those drugs. The pharmacy directory information is the same
information that MA-PD plans--like all Part D plans--must provide on
their websites under 42 CFR 423.128(b)(5) and (d)(2). While
prescription drug claims would have to be made available through the
Patient Access API no later than one (1) business day after the MA-PD
plan's receipt of that information, we did not propose a specific
timeframe for pharmacy directory or formulary information to be
available (or updated) through the API. We noted that we intended that
the requirements in 42 CFR part 423 requiring when and how information
related to pharmacy directories be updated would apply to the provision
of this information through the API; we solicited comment whether we
should address this in the regulation text or otherwise impose a
timeframe for this information to be made available through the API.
At 42 CFR 431.60(b)(5), for Medicaid FFS programs, and at 42 CFR
457.730(b)(5) for CHIP FFS programs, we proposed that states would be
required to include and update information about covered outpatient
drugs and updates to such information, including, where applicable,
preferred drug list information, no later than one (1) business day
after the effective date of any such information or updates to such
information.
We did not propose a similar requirement for QHP issuers on the
FFEs because, like the provider
[[Page 25541]]
directory information, QHP issuers are required to make drug formulary
data accessible in a machine-readable format.
As discussed above for the provider directory information, to avoid
unnecessary duplication of effort and potential confusion, we are also
not finalizing the proposal to include pharmacy directory information
in the Patient Access API. Instead, we are only finalizing the
inclusion of this information as proposed and explained above be
included in the public facing Provider Directory API discussed in
section IV. of this final rule, which requires MA organizations that
offer MA-PD plans to provide public access to pharmacy directory
information at 42 CFR 422.120(b). Relevant comments are also discussed
in section IV. of this final rule.
We summarize the public comments received on our proposal that
information about drug coverage and pharmacy benefit coverage be
available through the Patient Access API and provide our responses.
Comment: One commenter recommended CMS require that MA plans make
information about patients' step therapy available for sharing
electronically. This commenter opposes step therapy and recommended
that it not be used in MA or Part D.
Response: The use of step therapy is beyond the scope of this rule.
However, because step therapy is a utilization management procedure, it
is included among the types of information MA-PDs must make available
about Part D drugs through the API. In regard to information about
utilization management that pertains to basic benefits, which was not
addressed in this rule, we appreciate the commenter's recommendations
and will evaluate them for potential future consideration.
Comment: One commenter strongly recommended the inclusion and
standardization of prescription drug monitoring program data (PDMP) for
exchange through APIs, although this commenter referred more to
exchange between providers for downstream clinical decision support and
analytics rather than for patient access. A few commenters were not in
favor of sharing PDMP data through APIs. A few commenters were not
supportive of PDMP data being available to other providers and payers.
Response: We appreciate the commenters' recommendations and
concerns. However, we note that this information is not required to be
available through the Patient Access API as it is not within the scope
of 422.119(b)(2).
Comment: Several commenters expressed concern that the proposals in
42 CFR 431.60(b)(5), 457.730(b)(5), 438.242(b)(6) (finalized as 42 CFR
431.60(b)(4), 457.730(b)(4), and 438.242(b)(5) in this rule), and 45
CFR 457.1233(d) to provide information on covered outpatient drugs and
preferred drug lists through an API within one (1) business day after
the effective date of the information or updates to the information may
be a challenge for state Medicaid and CHIP agencies and Medicaid and
CHIP managed care entities. One commenter recommended to first require
state Medicaid pharmacy programs to focus on developing interoperable
standards for API development and only require managed care entities to
adopt the standards once the API has been tested and scaled at the
state level.
Response: We appreciate the commenters' concerns. We understand
that our proposed timeframe of one (1) business day may be
operationally challenging for states and managed care plans but
continue to believe that this timeframe is critical in order for
beneficiaries and prescribers to have this information as soon as the
information is applicable to coverage or in near real time since this
information could improve care and health outcomes. We believe that
timely data are particularly important during urgent or emergency
situations. We note that having access to this information as soon as,
or even before, it is effective is necessary for patients and their
providers to make important decisions about which medications should be
included in a patient's care plan. This is particularly important for
patients who may not be able to cover a medication out of pocket if it
is not covered by their plan. Therefore, we are finalizing the
timeframe. We decline to only apply these requirements to state
Medicaid programs (and decline to postpone application of the timeframe
to managed care plans until a future time as recommended by the
commenter) because this approach would not be consistent with our goal
of ensuring that the patients covered by the payers impacted by this
requirement have access to the specified data. We also note that we are
providing a link to specific implementation guidance and reference
implementations for all payers to further support sharing the needed
data using the required standards: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. We are finalizing these
requirements for the API to include formulary information for MA
organizations offering MA-PD plans, state Medicaid and CHIP FFS
programs, Medicaid managed care plans, and CHIP managed care entities.
In addition to comments about the specific types of information we
proposed be made available through the Patient Access API, we also
received comments on additional types of information stakeholders would
like to see included. We summarize the public comments we received on
this topic and provide our responses.
Comment: Commenters made a number of suggestions for additional
data to be made available to patients via the Patient Access API. Some
of the data requested is already included in the proposal and being
finalized for inclusion as proposed. In addition to these requests, a
few commenters recommended CMS also require the inclusion of
information regarding prior authorization decisions, drug pricing, and
a direct phone number for patients to call providers and their staff
about prior authorization issues. A few commenters specifically
requested prior authorization decision information, including active
prior authorizations, be made accessible to patients; a few other
commenters suggested this prior authorization information be available
to providers.
Commenters recommended future versions of the USCDI include
additional data so that these data would be available via the Patient
Access API. A few commenters recommended the USCDI include social
determinants of health data. One commenter recommended CMS and ONC
include additional immunization data elements from the CDC endorsed
data elements for immunization and the American Immunization Registry
Association's Functional Guide. One commenter recommended Care Team
Data Class as well as Data Class Provenance ``Author Health
Profession'' be added. One commenter recommended including coverage and
explanation of benefit data to the USCDI per the CARIN Alliance's
Implementation Guide. Another commenter recommended CMS include data
elements related to administrative transactions. One commenter
recommended the USCDI include Digital Imaging and Communications in
Medicine (DICOM) images in addition to the already included imaging
notes. A few commenters requested CMS specifically require the use of
Systematized Nomenclature of Dentistry (SNODENT) for dentistry
findings, disorders, and diagnoses, versus making SNODENT optional as
part of the proposed USCDI.
[[Page 25542]]
A few commenters recommended that additional care settings or
provider types are considered for additional USCDI data classes in the
future. These included anesthesiology, registered dietitian
nutritionists, and post-acute care settings (including hospice). One
commenter recommended that the USCDI include additional FHIR-based
pharmacy benefit standard-based formulary and drug benefit data.
Another commenter requested that Admission, Discharge, and Transfer
(ADT) data classes and data elements be included in the USCDI. One
commenter recommended CMS work with the industry to standardize
unstructured encounter data. One commenter was concerned that the USCDI
includes data traditionally collected in EHRs and that data/standards
for non-health care transactions are not included (for example, home
modifications). One commenter expressed concerns that the USCDI does
not include the entire designated record set, such as images and
genomic test reports and recommends this be included.
Response: We appreciate the commenters' recommendations and will
work with ONC to evaluate these recommendations for possible future
consideration, as appropriate and feasible.
We also received comments detailing concerns with the volume of
data being proposed to be made available through the Patient Access
API. We summarize the public comments we received on this topic and
provide our responses.
Comment: A few commenters were concerned with the potential volume
of data that will be made available to patients through the Patient
Access API. A few commenters requested CMS provide more information
regarding the minimum information required to be shared under our
policies. One commenter suggested that an advisory panel determine the
volume and types of information that patients should receive.
Response: We appreciate the commenters' concerns and
recommendations. Regarding the data to be made available to patients,
as noted in section III.C.2.b. of this final rule, to ensure consistent
implementation and minimize the burden on payers, we are finalizing in
the applicable regulations additional text to specify that MA
organizations at 42 CFR 422.119(h), state Medicaid FFS programs at 42
CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii),
CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at
42 CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221(i),
beginning January 1, 2021 (or beginning with plan years beginning on or
after January 1, 2021 for QHPs on the FFEs), must make available
through the Patient Access API data they maintain with a date of
service on or after January 1, 2016. We are also finalizing the same
years of data be available through the Patient Access API and for the
payer-to-payer data exchange requirement discussed in section V. of
this final rule. These policies support the ultimate goal to provide
patients access to their cumulative health information.
We are finalizing as proposed the minimum content required to be
accessible through the Patient Access API in the regulation text at 42
CFR 422.119(b), 431.60(b), 438.242(b)(5), and 457.730(b), and 45 CFR
156.221(b). This specifically includes adjudicated claims (including
cost); encounters with capitated providers; provider remittances;
enrollee cost-sharing; and clinical data (including laboratory results)
(where maintained by the applicable payer), as well as formularies or
preferred drug lists for all impacted payers except QHP issuers on the
FFEs. As discussed above, these data must be shared using the content
and vocabulary standards at 45 CFR 170.213, finalized by HHS in ONC's
21st Century Cures Act final rule (published elsewhere in this issue of
the Federal Register), and in 45 CFR part 162 and 42 CFR 423.160. We
believe that patients have a right to their health care information so
they can use and share this information to best inform their health
care decisions. We appreciate the recommendation to create an advisory
panel, and will evaluate it for potential future consideration.
d. Documentation Requirements for APIs
We proposed that the specific business and technical documentation
necessary to interact with the proposed APIs be made freely and
publicly accessible. As discussed in section II.A.1 of the CMS
Interoperability and Patient Access proposed rule (84 FR 7620), we
believed transparency about API technology is needed to ensure that any
interested third-party application developer can easily obtain the
information needed to develop applications technically compatible with
the organization's API. Transparency is also needed so that third-
parties can understand how to successfully interact with an
organization's API. This includes how to satisfy any requirements the
organization may establish for verifying a developer's identity and
their applications' authenticity, consistent with the payer's security
risk analysis and related organizational policies and procedures. In
this way payers can ensure they maintain an appropriate level of
privacy and security protection for data on their systems.
Specifically, at 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45
CFR 156.221(d), we proposed virtually identical text to require the
regulated entities to make complete accompanying documentation
regarding the API publicly accessible by posting this documentation
directly on the applicable entity's website or via a publicly
accessible hyperlink. As previously discussed, Medicaid managed care
plans would be required by 42 CFR 438.242(b)(6) (finalized as Sec.
438.242(b)(5) in this rule; see section VI.) to comply with the
requirement at 42 CFR 431.60(d), and CHIP managed care entities would
be required by 42 CFR 457.1233(d)(2) to comply with the requirement at
42 CFR 457.730(d). In requiring that this documentation be made
``publicly accessible,'' we noted that we expected that any person
using commonly available technology to browse the internet could access
the information without any preconditions or additional steps beyond
downloading and using a third-party application to access data through
the API. We also noted that this was not intended to preclude use of
links the user would click to review the full text of lengthy documents
or access sources of additional information, such as if the
technology's supplier prefers to host technical documentation at a
centralized location. Rather, we meant ``additional steps'' to include
actions such as: Collecting a fee for access to the documentation;
requiring the reader to receive a copy of the material via email; or
requiring the user to read promotional material or agree to receive
future communications from the organization making the documentation
available.
We summarize the public comments received on our proposal regarding
API documentation and provide our responses.
Comment: Some commenters opposed the API documentation proposal
indicating payers and providers will be required to provide data
without a charge, but the freely and publicly accessible documentation
would enable applications to collect data and possibly sell the data
back to payers and providers if needed for secondary uses such as
provider directories.
Some commenters supported fees for documentation noting the funds
required to create and maintain data for sharing between payers and
enrollees.
[[Page 25543]]
Commenters believed third parties should be charged a fee to maintain
the API. One commenter expressed concern that the business model of the
third-party applications hinges on their ability to sell the data they
collect for secondary uses while payers and providers would be required
to provide information to vendors absent a fee. This commenter argued
that charging third-party vendors a fee for documentation could be one
way for vendors to absorb some of the cost of maintaining the API in
exchange for the data they could potentially use to make a profit.
Response: We also appreciate the concerns raised around the
secondary uses of data shared with third-parties. We note that under
section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it is considered a
deceptive act to use a person's sensitive information without
disclosing in product documentation how this information will be
shared.\31\ In addition, we do not believe that charging a fee to
access API documentation is appropriate to offset secondary data use
concerns. We refer readers to the additional discussion below regarding
informing patients about potential secondary uses of data.
---------------------------------------------------------------------------
\31\ See also cases where this authority was used, such as 2012
FTC action against Facebook (see https://www.ftc.gov/enforcement/cases-proceedings/092-3184/facebook-inc), the 2012 FTC action
against MySpace (see https://www.ftc.gov/enforcement/cases-proceedings/102-3058/myspace-llc-matter), and the 2017 FTC action
against VIZIO (see https://www.ftc.gov/enforcement/cases-proceedings/162-3024/vizio-inc-vizio-inscape-services-llc).
---------------------------------------------------------------------------
The data that must be shared via the API under this policy are data
that the payers have and must currently share with patients under
existing law. The public directory data is already public information.
We do not believe it is appropriate to charge a fee for documentation
required to access such available data. Taking the example of provider
directory data raised by commenters, currently there are vendors that
collect the publicly available directory data, clean these data,
supplement these data, and offer this enhanced data product back to
payers and providers. It is not the data the vendors are charging for
as much as it is the service of cleaning and enhancing these data.
Vendors may generate revenue from their third-party apps, but a major
component of this is the service they are providing--building the app,
making the data the patient directs to them most usable and valuable--
that generates the revenue. Payers must already make these data
available to patients. These data alone may also drive revenue, but it
is the patient's prerogative to provide their data to a third-party in
order to get a service in exchange. Being sure patients are as informed
as possible about secondary uses of data and how this may impact them
is important. As a result, we discuss this issue more below.
Comment: Some commenters indicated support for permitting access to
documentation without access fees, citing concern that the fees would
be extended to consumers as well as logistical concerns for how they
would be paid. A few commenters specifically recommended alignment with
the ONC 21st Century Cures Act proposed rule API documentation
requirement by using the language included in the discussion of the
proposed requirement at 45 CFR 170.315(g)(10) stating that the
documentation should be ``accessible to the public via a hyperlink
without additional access requirements, including, without limitation,
any form of registration, account creation, `click-through' agreements,
or requirement to provide contact details or other information prior to
accessing the documentation'' (84 FR 7484).
Response: We do appreciate the requests to explicitly state what we
mean by ``public access'' and ensure it is clear this does not permit
any additional restrictions or fees. As a result, to further align with
the discussion in the ONC 21st Century Cures Act proposed rule (84 FR
7477), and the CMS Interoperability and Patient Access proposed rule
(84 FR 7620), we are finalizing regulation text stating that ``publicly
accessible'' means we expect that any person using commonly available
technology to browse the internet could access the information without
any preconditions or additional steps, such as a fee for access to the
documentation; a requirement to receive a copy of the material via
email; a requirement to register or create an account to receive the
documentation; or a requirement to read promotional material or agree
to receive future communications from the organization making the
documentation available. We are finalizing this requirement at 42 CFR
422.119(d), 431.60(d), 438.242(b)(5) (through cross-reference to
Medicaid FFS), 457.730(d), 457.1233(d)(2) (through cross-reference to
CHIP FFS), and 45 CFR 156.221(d).
Comment: One commenter did not support this documentation proposal
for security reasons as the commenter believed that if the
documentation was public, any third-party or organization could
potentially call, or connect to, a payer's API. This commenter
preferred an alternate approach where CMS stipulates in order to call
an API, there would need to be appropriate security tokens in place
between the two parties engaged in the data exchange.
Response: We appreciate the commenters' concerns. We note, however,
that making the documentation available publicly does not impact the
security of the standards-based API itself. This level of transparency
is common in other industries and across standards, and has been shown
to lead to innovation and competition. HL7 is built on free and open
documentation to ensure that all developers can equally access
information. Reviewing the documentation available for FHIR is one way
of appreciating the value of this information and how having it freely
accessible can allow innovators to engage with health care data in the
most meaningful ways.\32\ Having access to the documentation is not the
same as access to the actual API for the purposes of data exchange.
---------------------------------------------------------------------------
\32\ HL7 International. (n.d.). FHIR Overview. Retrieved from
https://www.hl7.org/fhir/overview.html.
---------------------------------------------------------------------------
Appreciating the comments received and the need to have
documentation available to ensure successful implementation and use of
the Patient Access API, we are finalizing our proposal to make publicly
accessible documentation that includes, at a minimum: (1) API syntax,
function names, required and optional parameters supported and their
data types, return variables and their types/structures, exceptions and
exception handling methods and their returns; (2) The software
components and configurations an application must use in order to
successfully interact with the API and process its response(s); and (3)
All applicable technical requirements and attributes necessary for an
application to be registered with any authorization server(s) deployed
in conjunction with the API. As noted, we have made one modification by
adding the definition of ``publicly accessible'' to the relevant
regulation text.
e. Routine Testing and Monitoring of Standards-Based APIs
At 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR
156.221(c)(2) for MA organizations, state Medicaid and CHIP FFS
programs, and QHP issuers on the FFEs, respectively, we proposed that
the API must be routinely tested and monitored to ensure it is
functioning properly, including assessments to verify that the API is
fully and successfully implementing privacy and security features such
as but not limited to those required to
[[Page 25544]]
comply with the HIPAA Privacy and Security Rules, 42 CFR parts 2 and 3,
and other applicable law protecting privacy and security of
individually identifiable health information. As proposed, Medicaid
managed care plans would be required by 42 CFR 438.242(b)(6)
(redesignated as 438.242(b)(5) in this final rule; see section VI. of
this final rule) to comply with the requirement at 42 CFR 431.60(c),
and CHIP managed care entities would be required by 42 CFR
457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(c).
Additionally, we noted that while federal laws that regulate MA
organizations and MA plans supersede any state law except where noted
under section 1856(b)(3) of the Act, some state, local, or tribal laws
that pertain to privacy and security of individually identifiable
information generally, and that are not specific to health insurance,
may also apply to MA organizations and MA plans in the context of the
proposal. For the other entities regulated under the proposals in these
various programs, we noted that we also intended the phrase ``other
applicable law'' to include federal, state, tribal or local laws that
apply to the entity.
We proposed this requirement to establish and maintain processes to
routinely test and monitor the standards-based APIs to ensure they are
functioning properly, especially with respect to their privacy and
security features. We explained in the preamble of the proposed rule
that under the proposal, MA organizations, Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs would have to implement, properly maintain,
update (as appropriate), and routinely test authentication features
that will be used to verify the identity of individual enrollees who
seek to access their claims and encounter data and other PHI through
the API. Similarly, as discussed, compliance with the proposed
requirements would mean that these entities must implement, maintain,
update (as appropriate), and routinely test authorization features to
ensure an individual enrollee or their personal representative can only
access claims and encounter data or other PHI that belongs to that
enrollee. As is the case under existing HIPAA Privacy Rule
requirements, where an individual is also a properly designated
personal representative of another enrollee, the HIPAA covered entity
must provide the personal representative appropriate access to the
information about the enrollee that has designated them as their
personal representative, just as they would if the personal
representative were the enrollee.
We summarize the public comments we received on routine testing and
monitoring and provide our responses.
Comment: Several commenters supported the proposal to require that
payers routinely test and monitor the standards-based API needed to
meet the requirements of this proposal. One commenter recommended that
this be self-regulated rather than mandated, however. A few commenters
expressed concern with the requirement to test and monitor the API. A
few additional commenters expressed concern that there is no consensus
on a common testing environment. One commenter believed that testing
and monitoring will be costly.
Several commenters urged CMS to provide additional information and
guidance on any requirements for testing and monitoring APIs, including
the expected frequency of testing. A few commenters requested
additional information on whether payers will be required to
demonstrate compliance by submitting or reporting on testing plans. One
commenter requested clarification on the process if an issue is found
during testing or monitoring. One commenter requested that CMS specify
what ``routine'' means.
Response: We appreciate the commenters' concerns and
recommendations. We did not specify exactly at what intervals or
frequency testing should be done, and thus did not quantify
``routine,'' as we believe it is important that payers put a process in
place that works best for them to conduct testing and monitoring at
regular intervals to ensure the required API remains in compliance and
is working as expected. We will provide best practice information,
including information on available API testing tools to support payers
with this required activity. In our review of the proposed regulation
text, we realized that the regulation text at 42 CFR 422.119(c)(2),
431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2) did not specify
the requirement to also update (as appropriate) the API to ensure it
functions properly and includes assessments to verify an individual
enrollee or their personal representative can only access claims and
encounter data or other PHI that belongs to that enrollee. We are
finalizing additional text to this effect. We are also removing the
word ``minimally'' from this regulation text in order to ensure it is
clear that privacy and security features must be reasonable and
appropriate, consistent with the requirements of the HIPAA Security
Rule. We note that this testing requirement is accounted for in
sections XII. and XIII. of this final rule as one of the expected steps
of implementing and maintaining an API. This is part of the cost
factored into implementation of the API and is a necessary part of
using an API. It is also part of current software development best
practices. Payers implementing APIs can incorporate testing tools into
a comprehensive testing plan and continuous integration (CI) system,
which can automatically validate adherence to the implementation guide
when changes are made to further mitigate this cost.
f. Compliance With Existing Privacy and Security Requirements
In the hands of a HIPAA covered entity or its business associate,
individually identifiable health information, including information in
patient claims and encounter data, is PHI and protected by the HIPAA
Rules. Ensuring the privacy and security of the claims, encounter, and
other health information when it is transmitted through the API is
important. Therefore, in the CMS Interoperability and Patient Access
proposed rule (84 FR 7635), we reminded MA organizations, state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs that mechanisms and
practices to release PHI, including but not limited to authorization
and authentication protocols and practices, must provide protection
sufficient to comply with the HIPAA Rules and other privacy and
security law (whether federal, state, tribal, or local) that may apply
based on the specific circumstances. As proposed, the entities subject
to these requirements would need to continuously ensure that all
authorization and authentication mechanisms provide sufficient
protections to enrollee PHI and that they function as intended. We
specifically requested public comment on whether existing privacy and
security standards, including but not limited to those in 45 CFR part
164, are sufficient with respect to these proposals, or whether
additional privacy and security standards should be required by CMS as
part of the proposal.
We note that comments and our responses related to privacy and
security issues, generally, can be found in section II.A.2. of this
final rule. Here, we summarize the public comments we received on
privacy and security as it relates to consent, authentication, and
identity verification and provide our responses.
[[Page 25545]]
Comment: A few commenters expressed concerns with using the
proposed FHIR standards for obtaining patient consent, with some noting
the lack of mature consent mechanisms supported through FHIR. A few
commenters expressed concerns that there are no mature or widely
accepted standards for documenting patient consent electronically,
generally. One commenter suggested that the patient be able to see
their consent preferences and the types of data that have been
authorized for sharing from a central location.
One commenter recommended that CMS or OCR develop a standardized
data sharing patient consent form that payers, providers, and health IT
vendors can use to ensure appropriate consent. A few commenters
recommended that CMS require payers and/or apps to use ONC's Model
Privacy Notice. One commenter recommended that CMS and FTC should
develop plain language consumer notifications that could be used by app
developers. One commenter recommended that CMS require payers to
include in their enrollment process an efficient ``check off''
authorization for an enrollee to release their information to their
providers. A few commenters noted that it should be the responsibility
of the app to verify the patient's ability to provide consent.
Response: We appreciate the commenters concerns and
recommendations, and we have shared these with ONC for consideration.
Regarding FHIR standards for consent, we refer readers to discussion in
the ONC 21st Century Cures Act final rule (published elsewhere in this
issue of the Federal Register), which considers the status of current
development efforts around consent resources. We will continue to work
with ONC and industry partners to monitor the development of FHIR
resources to support consent management. We believe that the security
protocols at 45 CFR 170.215 are sufficient to authenticate users and
authorize individuals to access their data maintained by payers in
accordance with the requirements described in this rule and, therefore,
provide the necessary consent mechanisms for payers to implement the
policies in this rule.
We appreciate the additional recommendations made regarding
developing consent materials for all payers to use, as well as
recommendations around the use of the ONC Model Privacy Notice. More
information on available consent options can be found at https://gforge.hl7.org/gf/project/cbcc/frs/, and ONC's Model Privacy Notice is
available at https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn, which interested payers or app vendors can
use. We will evaluate recommendations made that would add requirements
on payers that we had not proposed, including any centralized solution,
for possible future rulemaking.
Comment: Several commenters supported efforts to verify if an
entity is authorized to access the data they are seeking. One commenter
supported the proposed use of the OAuth standard. One commenter
believes that the use of OAuth 2.0 for client application authorization
and OpenID Connect for client application authentication should include
authenticity, integrity, and non-repudiation standards. Another
commenter suggested CMS permit flexibility in the implementation of
security standards. A few commenters expressed concerns with using the
proposed FHIR standards for identity proofing alone and supported
additional measures, such as biometrics, be employed as well. A few
commenters expressed concern about open-ended token access once
initially authenticated and instead recommended CMS implement a 90-day
timeframe for the authentication token to remain open. One commenter
suggested that encryption of authentication credentials is not
sufficient.
One commenter believed that the only true means by which an
individual can assert their identity is through a government-issued ID,
and if this cannot be produced, the commenter noted several limitations
that should be put in place to prohibit data sharing until further
authentication can be done. Another commenter suggested CMS look into
biometrics as a means for improving identity proofing. A few commenters
recommended the use of multi-factor authentication to verify the
identification of an individual.
A few commenters recommended requiring payers give their members an
online way to self-enroll for the necessary credentials to access their
health information via an API. One commenter stated that this will
reduce the time it takes for an organization to verify a request. One
commenter recommended that this should apply to any of a payer's
patients who have been a member in the past 5 years. One commenter
expressed concern that without clear guidelines for how patients can
access their data, patients may face barriers such as trying to get
authentication credentials, and trying to get an app authorized.
A few commenters recommended CMS develop a common method to
validate the identity and authority of the requesting party. One
commenter recommended CMS issue guidance on authenticating the
requestor that offers a simple, secure method to obtain authentication
across all entities. A few commenters supported efforts to develop
methods to verify a caregiver for a patient and allow that caregiver to
access all health information systems.
Response: We appreciate the commenters' concerns and
recommendations. We are finalizing as proposed to require compliance
with 45 CFR 170.215 as finalized by HHS in the ONC 21st Century Cures
Act final rule (published elsewhere in this issue of the Federal
Register). This requires use of HL7 FHIR Release 4.0.1, and
complementary security and app registration protocols, specifically the
SMART Application Launch Implementation Guide (SMART IG) 1.0.0
(including mandatory support for the ``SMART on FHIR Core
Capabilities''), which is a profile of the OAuth 2.0 specification, and
the OpenID Connect Core 1.0 standard, incorporating errata set 1).
Additional information and implementation guidance can be found at
http://hl7.org/fhir/smart-app-launch/. The goal of using these
resources is to make authorization electronic, efficient, and secure so
that patients can access their health information as effortlessly as
possible.
We agree that multifactor authentication represents a best practice
for privacy and security in health care settings, and we note that an
important benefit of the OAuth 2.0 standard HHS is finalizing is that
it provides robust support for multifactor authentication. By requiring
that payers subject to our Patient Access API requirement use an API
that is conformant with 45 CFR 170.215, where HHS has finalized the
SMART IG, we are supporting the use of multifactor authentication. We
also note that as part of ONC's 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register), HHS is
finalizing a new provision in the ONC certification program that would
require health IT developers to attest as to whether they support
multifactor authentication, further encouraging adoption of such
security practices. We also strongly encourage payers subject to the
requirements in this final rule to employ robust privacy and security
protocols, and use multifactor authentication, where appropriate.
Multifactor authentication is industry accepted, routinely used across
many sectors,
[[Page 25546]]
known to patients, and a low burden option that could significantly
increase security.
Though we appreciate commenters' requests to leave flexibility
here, we do believe adopting the standards as finalized by HHS in ONC's
21st Century Cures Act final rule regarding the use of the SMART IG
(using the OAuth 2.0 standard) and OpenID Connect Core 1.0 is an
important starting point. In addition, we note that the technical
standards at 45 CFR 170.215 address the comments regarding tokens, as
HHS is finalizing use of tokens at 45 CFR 170.215 as part of the SMART
IG. We note that ONC is requiring that a token be valid for at least 3
months for certified health IT; we encourage payers subject to this
final rule to align with this best practice. We appreciate
recommendations for a centralized solution to patient authentication
and identity proofing, and caregiver access, and will take these under
consideration as appropriate.
Comment: Many commenters expressed that patients should have
ultimate authority and the ability to consent to what type of
information can be shared as well as who can access their health
information. One commenter recommended CMS require that patients have
the ability to filter or request only the specific data that they want
to be shared. One commenter requested that payers be able to access the
specific types of data a patient authorized the app to access. One
commenter added patients should also have an accounting of disclosures
or access to their data.
A few commenters expressed concerns over the sharing of patient
electronic health information with health care providers that the
patient has not consented to share with. A few commenters expressed
specific concerns with sharing electronic health information beyond the
immediate health care provider, such as with providers with which a
patient may be seeking a second opinion or additional care. One
commenter was concerned with the sharing of family health history data
particularly for family members who have not consented.
A few commenters recommended that providers be able to pre-filter
or select which data can be made available to the patient, citing
concerns with the sensitivity of some provider notes or patient
confusion in interpreting certain information. A few commenters also
suggested that providers be able to select which information can be
made available to the payer.
Response: We appreciate the commenters' concerns and suggestions.
Collectively, HHS has been working to evaluate various technical
specifications for data segmentation to enhance privacy protections and
comply with applicable law (such as laws regarding privacy for minors
or 42 CFR part 2). Both HHS and the industry as a whole are currently
evaluating future use cases related to segmenting data at the patient
request. At this time, however, the policies as they are being
finalized under this rule require that the payers, with the approval
and at the direction of the patient, provide all of the data as
specified in the applicable regulation text. Beyond this, payers,
providers, and patients cannot direct specific segments of data be made
available via this Patient Access API. The necessary technical
specifications to allow a patient to request some data elements be
shared but not others are not widely adopted.\33\ If the patient
requests their data via the Patient Access API from a payer, the payer
must make available all of the data allowed per current law, such as 42
CFR part 2 and relevant state laws, including the data as specified in
this final rule. We reiterate, however, that the data that are
available to be shared are only to be shared at the patient's request.
If there are data elements the patient does not want to be shared, they
can choose not to make the request. In addition, we note that this
policy allows data to be exchanged from the payer to a third-party app
of the patient's choice for their personal use. This rule does not
require any data exchange directly between or with providers.
---------------------------------------------------------------------------
\33\ For information on adoption levels for technical
specifications related to data segmentation, see the
Interoperability Standards Advisory at https://www.healthit.gov/isa/data-segmentation-sensitive-information.
---------------------------------------------------------------------------
Specifically regarding the comment on sharing family history, we
note that the health information required to be shared under this
policy includes claims and encounter data as well as the data included
in the USCDI version 1. At this time, ``family history'' is not a
specific data class within the USCDI. As a result, we do not believe
this should be an issue under this current policy. We will, however,
take this into consideration as we consider future policy options.
We appreciate the recommendation for patients to have a full record
of disclosures or access to their health information via the API. At
present, the HIPAA Privacy Rule requires accountings of certain
disclosures. Consistent with the spirit of this accounting of
disclosures, we encourage payers to consider setting up functionality
to allow patients to view a record of when and with whom their data
have been shared via the API.
Comment: Many commenters expressed concerns over the complexity
with parsing or segmenting electronic health information that is
considered sensitive and/or is subject to 42 CFR part 2 rules.
Commenters requested CMS take into account these situations with these
API proposals and cited use cases such as women's health, sexual
health, young adult health, mental health, and substance abuse
treatment. A few commenters noted concerns that some health care
providers may discriminate or treat a patient differently if they were
able to access certain patient's health information. A few commenters
recommended that HHS align part 2 and HIPAA regulations. One commenter
recommended the use of the Consent2Share (C2S) FHIR Consent Profile
developed by SAMHSA. Another commenter suggested CMS defer adoption of
the Data Segmentation for Privacy standards until an API FHIR standard
version is finalized and the Consent2Share guide is revised to conform
to that version.
Response: We appreciate the commenters concerns and
recommendations. We are currently evaluating future options around
parsing or segmenting data, generally, using the API. As noted above,
HHS is collectively working to explore standards and technical supports
for data segmentation for privacy and consent management and point
commenters to the ONC 21st Century Cures Act final rule for additional
discussion on this. We also note that using the appropriate FHIR
profiles, such as those being finalized by HHS in the ONC 21st Century
Cures Act final rule (published elsewhere in this issue of the Federal
Register) for API technical standards, including the SMART IG (using
the OAuth 2.0 standard) and OpenID Connect as finalized at 45 CFR
170.215, can be leveraged to support this. Again, we note that
additional information and implementation guidance can be found at
http://hl7.org/fhir/smart-app-launch/. However, we reiterate that
payers' privacy and security obligations under the HIPAA Rules and 42
CFR part 2 are not impacted by this final rule.
Comment: A few commenters expressed particular concern for
appropriate authorization of parent/guardian proxies for minor
patients. One commenter recommended CMS align the CMS Interoperability
and Patient Access proposed rule with the Children's Online Privacy
Protection Act (COPPA), which was created to
[[Page 25547]]
protect the privacy of children under 13 and has been in effect since
2000.
Response: We appreciate the commenters concerns and
recommendations, which we are reviewing for future possible
consideration in regulation. We note that this current regulation does
not change any existing privacy relationships between minors and
parents. If, for instance, a teenage minor has asserted their
protections to not have their guardians see their Explanation of
Benefits, the payer would be obligated to maintain these protections
when sharing data via the API. For non-minor dependents, again the
existing policies hold true.
Regarding privacy in an enrollment group, at this time, a
policyholder can see the claims for all members of their enrollment
group unless there is an agreed upon privacy provision available and in
place. The HIPAA Privacy Rule states at 45 CFR 164.522 that individuals
have a right to request restrictions on how a covered entity will use
and disclose protected health information about them for treatment,
payment, and health care operations. However, a covered entity is not
generally required to agree to an individual's request for a
restriction unless certain limited exceptions are met \34\, but is
bound by any restrictions to which it does agree. After the Affordable
Care Act extended the age that group health plans and issuers of health
insurance coverage in the group or individual market that offer
dependent coverage of children must continue to make such coverage
available to adult children until age 26, some states, including
California, Colorado, Washington, Oregon, and Maryland, have enacted
stricter protections regarding privacy rights, and although all of
these states operate their own SBEs and issuers on these Exchanges are
not implicated in this rule, to the extent issuers are operating in
both these and FFE states and have applied their privacy policies
across markets, consumers in FFE states may also benefit from these
stricter protections. This final rule does not alter obligations under
any existing federal, state, local, or tribal law. Again, we note that
this data sharing is currently ongoing; the API just provides an
additional way to facilitate this exchange.
---------------------------------------------------------------------------
\34\ See 45 CFR 154.522(a)(1)(vi) for a discussion of the
limited exceptions.
---------------------------------------------------------------------------
g. Issues Related to Denial or Discontinuation of Access to the API
We believe patients have a right to their health information.
However, a covered entity is not expected to tolerate unacceptable
levels of risk to the PHI held by the covered entity in its systems, as
determined by its own risk analysis. Accordingly, it may be appropriate
for an organization to deny or terminate specific applications'
connection to its API under certain circumstances in which the
application poses an unacceptable risk to the PHI on its systems.
At 42 CFR 422.119(e), Sec. 431.60(e), 438.242(b)(6) (redesignated
as Sec. 438.242(b)(5) in this rule; see section VI.), 457.730(e),
457.1233(d)(2) and 45 CFR 156.221(e) for MA organizations, state
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs, respectively, we
proposed to specify the circumstances under which these regulated
entities, which are all HIPAA covered entities subject to HIPAA privacy
and security requirements, may decline to establish or may terminate a
third-party application's connection to the covered entity's API while
remaining in compliance with the proposed requirement to offer patients
access through standards-based APIs. We noted in the CMS
Interoperability and Patient Access proposed rule that we intended for
the proposal to be consistent with the HIPAA Rules, and we noted that
these circumstances apply to specific applications, rather than the
third party itself (84 FR 7635 through 7636).
Specifically, we proposed that a payer subject to our API proposal
could deny access to the API if the payer reasonably determined that
allowing that application to connect or remain connected to the API
would present an unacceptable level of risk to the security of PHI on
the payer's systems. We further proposed that this determination would
be made consistent with the payer's HIPAA Security Rule obligations and
based on objective, verifiable criteria that would be applied fairly
and consistently across all applications through which enrollees seek
to access their electronic health information as defined at 45 CFR
171.102, including but not limited to criteria that may rely on
automated monitoring and risk mitigation tools.
Where we proposed to require access through standards-based APIs to
otherwise publicly available information, such as provider directories,
the entities subject to the proposal may also deny or terminate an
application's connection to the API when it makes a similar
determination about risk to its systems. However, depending on how the
organization's systems are designed and configured, we recognize that
the criteria and tolerable risk levels appropriate to assessing an
application for connection to an API for access to publicly available
information may differ from those required for API access to non-
published personally identifiable information (PII).
We also anticipated that, where an application's connection has
been terminated under these circumstances, it might be feasible in some
instances for the organization to allow the application to reconnect to
the API if and when the flaw or compromise of the application has been
addressed sufficiently that the organization can no longer fairly say
the application's API connection continues to pose an unacceptable
risk.
We summarize the public comments we received on denial or
discontinuation of service and provide our responses.
Comment: Several commenters supported the proposal to allow payers
to deny or discontinue access to apps that pose security risks. One
commenter specifically supported that the proposal does not allow
payers to deny requests based on concerns about the worthiness of the
third-party as a recipient of PHI, because patients have the right to
share their health information with the app they choose.
Several commenters encouraged CMS to develop and/or further define
guidelines for identifying ``unacceptable risk'' and establish a
clearer standard for acceptable circumstances when API access can be
restricted or denied. A few commenters expressed concerns that the
proposed requirements may be interpreted differently among payers,
apps, users, and providers. One commenter expressed concern because
payers are liable for breaches that occur during data exchange and the
commenter does not believe the proposal provides clear authority to
deny access based on such security concerns. A few commenters requested
that CMS provide more information regarding whether payers may delay
and/or deny certain apps that are suspected, or proven to be bad
actors. One commenter requested that CMS make the distinction between
the risk posed by providing PHI and providing other widely available
payer data. A few commenters requested CMS define a time period for how
long the ban on access may remain in place. One commenter sought
additional
[[Page 25548]]
information on whether payers will be able to deny third-party access
across the board for all patient queries and plans. A few commenters
suggested that CMS should develop a clear process for app developers to
follow in the event that a covered entity denies access to an API. A
few commenters recommended that CMS include in the final rule a
reference to ONC's information blocking definition and clarify that
unacceptable levels of risk could be an exception to information
blocking.
Response: We appreciate the commenters' concerns. As discussed in
the CMS Interoperability and Patient Access proposed rule, the criteria
and process for assessing unacceptable risk to a payer's system are
part of the payer's responsibilities under the HIPAA Security Rule (84
FR 7635). The HIPAA Security Rule requires a covered entity to perform
risk analysis as part of its security management processes.\35\ HHS
makes a number of tools available to assess risk.\36\ Additional tools
are available through the National Institute of Standards and
Technology (NIST).\37\
---------------------------------------------------------------------------
\35\ 45 CFR 164.308(a)1)(ii)(A).
\36\ For more information, see https://www.hhs.gov/hipaa/for-professionals/security/index.html.
\37\ Brooks, S., Garcia, M., Lefkovitz, Ligthman, S., & Nadeau,
E. (2017, January). NISTIR 8062
An Introduction to Privacy Engineering and Risk Management in
Federal Systems. Retrieved from https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.
---------------------------------------------------------------------------
We note that this policy regarding denial or discontinuation of
service refers to a payer's determination that allowing access to their
API by a third party would result in risk to their system. As also
noted previously, covered entities, in accordance with HIPAA privacy
and security obligations, should take reasonable measures to protect
data in transit, unless an individual expressly asks that the
information be conveyed in an unsecure form or format (assuming the
individual was warned of and accepted the risks associated with the
unsecure transmission). As explained in this section above, it is the
responsibility of payers to assess the risk to their system and act
accordingly regardless of whether the data being accessed via the API
is PHI or not. If the concern is the security of the payer's system,
the type of data being transferred is not at issue. Absent an
individual's instruction to disregard in-transit security, if while
assessing the security of the app's connection to the API, the covered
entity determines the data could be compromised in transit, the payer
could discontinue or deny access in order to project the ePHI on its
system. Again, this assessment must be based on objective, verifiable
criteria in accordance with obligations under the HIPAA Security Rule.
Having considered comments, we are finalizing that payers may deny or
discontinue any third-party application's connection to their API if
the payer reasonably determines, consistent with its security analysis
under 45 CFR part 164 subpart C, that allowing an application to
connect or remain connected to the API would present an unacceptable
level of risk to the security of protected health information on the
payer's systems or in transit in instances in which the individual did
not tell the payer to disregard in-transit risk. For example, where an
individual requests that their unencrypted ePHI be transmitted to an
app, the payer would not be responsible for unauthorized access to the
individual's ePHI while in transmission to the app. When access has
been denied or discontinued due to security concerns, we encourage
payers and third parties to work together to address the concerns if
and as possible to best serve patients. We are not able to set a
specific time period or process for this as it is beyond our authority,
however, we do note that the HIPAA Privacy Rule requires access to be
provided to the individual in a timely manner. Regarding information
blocking, we refer readers to the ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register).
Comment: One commenter requested that CMS indicate whether third-
party applications will be subject to HIPAA or FTC regulations. One
commenter requested information about whether patients will be able to
terminate third-party access to their health data.
Response: We appreciate the commenters' request for more
information. We refer commenters to OCR and FTC for additional
information about jurisdiction over third-party apps. We do note, as
discussed earlier, that under section 5 of the FTC Act (15 U.S.C. Sec.
45(a)), the FTC does regulate such third-party apps. Regarding a
patient's ability to terminate third-party access, this would be
something determined in the terms and conditions of each app.
Comment: A few commenters recommended that covered payers should
have the flexibility to establish additional terms and conditions when
denying third-party applications access to their systems. One commenter
stated that payers should be able to develop their own validation
process for enrollees and have the right to not release the data where
the full scope cannot be validated. One commenter stated the payers
should be able to refuse to connect to non-vetted apps. Another
commenter stated that payers should be able to restrict access if the
information exchanged is not permitted under the HIPAA Privacy Rule or
if the exchange or use would compromise the confidentiality, integrity,
and availability of the information. One commenter recommended that CMS
allow covered entities to remove an app from their system if the app
does not follow the approved privacy policy. One commenter recommended
that providers should be allowed to require a business associate
agreement (BAA) with third-party app developers that connect to the API
required under this final rule. One commenter suggested allowing
restrictions on data mining. However, one commenter expressed concern
that payers may place unnecessary barriers and burdens on third-party
app developers. The commenter encouraged CMS to ensure that payers
cannot place additional constraints on apps, such as requiring a BAA,
additional security audits, or requiring that apps make commitments
about how it will or will not use the information patients store on it.
Response: We appreciate the commenters' recommendations.
Specifically, regarding the ability to deny access to a third-party
app, we are finalizing this policy as proposed with one modification to
add additional clarity around what it means to reasonably determine
risk. As such, and as noted above, we are finalizing that payers may
deny or discontinue any third-party application's connection to their
API if the payer reasonably determines, consistent with its security
analysis under 45 CFR part 164 subpart C, that allowing an application
to connect or remain connected to the API would present an unacceptable
level of risk to the security of protected health information on the
payer's systems and the payer makes this determination using objective,
verifiable criteria that are applied fairly and consistently across all
applications and developers. As patients have a right to their data and
this proposal provides the payers the ability to appropriately protect
their systems and the data they hold on it, we do not believe any
additional restrictions are needed at this time. We also note it would
not be appropriate to require a patient-designated third party to enter
into a BAA with a payer as the API-facilitated exchange is taking place
per the request of the patient and not by,
[[Page 25549]]
on behalf of, or in service to the payer.\38\ In addition, we reiterate
that it is beyond our authority to regulate third parties directly. We
do note that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it
is considered a deceptive act to use a person's sensitive information
without disclosing in product documentation how this information will
be shared. We do, however, believe patient privacy and security are
vitally important. As a result, we lay out an option for payers to ask
a third-party app to attest to certain privacy provisions, to help make
patients aware of the privacy risks associated with their choices, as
detailed in the next section.
---------------------------------------------------------------------------
\38\ See 45 CFR 164.103 Definitions, regarding functions of
business associate.
---------------------------------------------------------------------------
Comment: Several commenters had suggestions on how to further this
proposal. A few commenters recommended that CMS could require apps to
attest to certain privacy and security provisions, and if they did not,
payers could deny access to the API. One commenter recommended that
payers be required to vet third-party applications centrally, rather
than requiring vetting for every payer and plan. A few commenters
expressed concern that it will be significantly burdensome for payers
and providers to vet every app that patients may choose to use in
support of more central vetting. One commenter suggested that app
developers should be able to proactively request to be vetted by a
payer, even if the app developer has not received a request from a
member.
Many commenters recommended CMS and/or HHS establish a
certification, independent verification, or vetting process for third-
party applications and vendors that would vet or test apps for certain
functions, including privacy and security assurances. As an
alternative, one commenter recommended CMS require apps generate an
accounting of disclosures or join a trusted exchange network.
A few commenters requested CMS share its best practices with app
authorization and access under the Blue Button 2.0 initiative. A few
commenters recommended CMS, or the payers pre-approve and/or maintain a
list of approved apps in order for them to access data. Several
commenters supported CMS' proposal to allow patients to select any app
of their choice. One commenter recommended that providers and payers be
required to authenticate the apps their patients choose to use to gain
access.
One commenter recommended that third-party application should be
clear in their terms and conditions when a consumer downloads an app,
and if they are not, a payer should not be required to interface with
the app. One commenter recommended that the proposal for payers to deny
or terminate specific applications from connecting to its API if the
risk posed to its systems is unacceptable should be extended to
hospitals, health systems, and other health care providers. One
commenter suggested that payers should be required to consider the
security risks related to provider EHR systems when determining whether
to deny or terminate a third-party application. One commenter
recommended that CMS develop three options for denial of an
application: denial at each API endpoint, centralized application
denial, or no denial. One commenter suggested that CMS could consider
allowing providers to voluntarily seek assurances or certifications
that third-parties are abiding by the API's terms.
Response: We appreciate the commenters' recommendations, and we
appreciate the concerns raised around privacy and security and the
discussion regarding additional steps we can take to protect patient
health information. We note that hospitals, health systems, and other
health care providers are considered covered entities under HIPAA, and
the HIPAA Privacy and Security Rules apply.
We do appreciate that app vetting, in particular, is an issue of
great interest to payers and providers. We note that we strongly value
the role that industry can play in this capacity, and we support
efforts within industry to facilitate efficient and effective, publicly
accessible information on vetted apps and vendors. We believe industry
is in the best position to collectively find the best ways to identify
those apps with strong privacy and security practices. We also
appreciate the commenters' request for best practices learned through
our experience with Blue Button 2.0. You can find this information at
https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
We are not going to pursue the recommendation to develop a CMS or
HHS app certification program. Under our current authorities, we do not
believe we have the ability to require a third-party app to take part
in such a certification program.
We do appreciate that, above all else, stakeholders commented on
privacy and security and the need to do more to protect patient health
information. Throughout this rule we have noted the limitations to our
authority to directly regulate third-party applications. We have also
explained that we are finalizing that payers can deny API access to a
third-party app that a patient wishes to use only if the payer assesses
that such access would pose a risk to the PHI on their system. We
appreciate, however, that more needs to be done.
In the ONC 21st Century Cures Act final rule (published elsewhere
in this Federal Register), ONC notes that it is not information
blocking to inform a patient about the advantages and disadvantages and
any associated risks with sharing their health information with a third
party. In this rule, we are finalizing that impacted payers must share
educational resources with patients to help them be informed stewards
of their health information and understand the possible risk of sharing
their data with third-party apps. As discussed above, commenters
believe it is a risk when patients do not understand what happens after
their data leaves the protection of HIPAA and are transmitted to a
third-party app. Commenters were specifically concerned about secondary
uses of data. A clear, plain language privacy policy is the primary way
a patient can be informed about how their information will be protected
and how it will be used once shared with a third-party app.
Taking into consideration comments indicating strong public support
for additional privacy and security measures, we are further building
off of the privacy and security policies we are finalizing in this rule
by asserting that MA organizations, Medicaid FFS programs, Medicaid
managed care plans, CHIP FFS programs, CHIP managed care entities, and
QHP issuers on the FFEs are encouraged, but are not required, to
request third-party apps attest to having certain privacy and security
provisions included in their privacy policy prior to providing the app
access to the payer's API. If a payer chooses, they can ask that the
apps requesting access to their API with the approval and at the
direction of the patient to attest that important provisions that can
help keep a patient's data private and secure are in place. Explaining
certain practices around privacy and security in a patient-friendly,
easy-to-read privacy policy helps inform patients about an app's
practices for handling their data. It helps patients understand if and
how the app will protect their health information and how they can be
an active participant in the protection of their information. Also, as
explained earlier in this final rule, if an app has a written privacy
policy and does not follow the policies as written, the FTC has
authority to intervene. As a result,
[[Page 25550]]
we assert that impacted payers can, but are not required to, ask a
third-party app to attest that:
The app has a publicly available privacy policy, written
in plain language,\39\ that has been affirmatively shared with the
patient prior to the patient authorizing app access to their health
information. To ``affirmatively share'' means that the patient had to
take an action to indicate they saw the privacy policy, such as click
or check a box or boxes.
---------------------------------------------------------------------------
\39\ Plain Language Action and Information Network. (2011, May).
Federal Plain Language Guidelines. Retrieved from https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf.
---------------------------------------------------------------------------
The app's privacy policy includes, at a minimum, the
following important information:
++ How a patient's health information may be accessed, exchanged,
or used by any person or other entity, including whether the patient's
health information may be shared or sold at any time (including in the
future);
++ A requirement for express consent from a patient before the
patient's health information is accessed, exchanged, or used, including
receiving express consent before a patient's health information is
shared or sold (other than disclosures required by law or disclosures
necessary in connection with the sale of the application or a similar
transaction);
++ If an app will access any other information from a patient's
device; or
++ How a patient can discontinue app access to their data and what
the app's policy and process is for disposing of a patient's data once
the patient has withdrawn consent.
Payers can look to industry best practices, including the CARIN
Alliance's Code of Conduct \40\ and the ONC Model Privacy Notice\41\
for other provisions to include in their attestation request that best
meet the needs of their patient population. If a payer chooses to
request third-party apps provide this attestation, the payer must not
discriminate in its implementation, including for the purposes of
competitive advantage. Specifically, if a payer requests this
attestation of one app, it must request it of all apps that seek to
obtain data. If the third-party app does not attest that their privacy
policy meets the provisions indicated by the payer, the payer may
inform patients that the app did not attest and advise them to
reconsider using this third-party app. The notification to the patient
should make it clear that the app has not attested to having the basic
privacy and security protections and indicate what those are, and that
the patient should exercise caution before opting to disclose their
information to the app. If the patient still requests the payer make
their data available to the third-party app, the payer must provide API
access to the app unless doing so would endanger the security of PHI on
the payer's systems. This process should not overly delay the patient's
access. If the app does not attest positively or at all, the payer must
work to quickly inform the patient and provide a short window for the
patient to cancel their request the data be shared. If the patient does
not actively respond, the payer must move forward as the patient has
already directed their data be shared and this initial request must be
honored.
---------------------------------------------------------------------------
\40\ See https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/.
\41\ See https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.
---------------------------------------------------------------------------
We believe it is important for patients to have a clear
understanding of how their health information may be used by a third-
party, as well as how to stop sharing their health information with a
third-party, if they so choose. We believe the use of this attestation,
in combination with patient education, will help patients be as
informed as possible while providing payers with a lower burden vetting
option. We believe this will better help protect patient privacy and
security and mitigate many of the concerns raised. Together, this
framework and the requirement for payers to provide patients with
educational resources will help continue to move us toward a safer data
exchange environment. This is a critical focus for CMS, and we look
forward to continuing to work with stakeholders to keep patient privacy
and data security a top priority.
h. Enrollee and Beneficiary Resources Regarding Privacy and Security
As discussed in section II.A. of the CMS Interoperability and
Patient Access proposed rule (84 FR 7618 through 7623), we are
committed to maximizing enrollees' access to and control over their
health information. We noted that we believed this calls for providing
enrollees that would access data under the proposal with essential
information about the privacy and security of their information, and
what to do if they believe they have been misled or deceived about an
application's terms of use or privacy policy.
At 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR
156.221(g), we proposed to require MA organizations, state Medicaid and
CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs, to make available to their
current and former enrollees certain information about: factors to
consider in selecting a health information management application,
practical strategies to help them safeguard the privacy and security of
their data, and how to submit complaints to OCR or FTC. The proposed
obligations would apply to Medicaid managed care plans and CHIP managed
care entities through cross-references proposed in 42 CFR 438.242(b)(6)
(finalized as Sec. 438.242(b)(5) in this final rule; see section VI.
of this final rule) and Sec. 457.1233(d)(2).
The general information about the steps individuals can take to
help protect the privacy and security of their health information
should not be limited to, but should specifically include and emphasize
the importance of understanding the privacy and security practices of
any application to which they entrust their data. Information about
submitting complaints should include both specific contact information
for the OCR and FTC complaints processes and a brief overview, in
simple and easy-to-understand language, of: What organizations are
HIPAA covered entities, OCR's responsibility to oversee compliance with
HIPAA, and FTC's complementary responsibility to take action against
unfair or deceptive practices, including by non-covered entities that
may offer direct-to-consumer health information management
applications.
We proposed that this information must be made available on the
website of the payers subject to the proposed requirement, and through
other appropriate mechanisms through which the payer ordinarily
communicates with enrollees that are seeking to access their health
information held by the payer. This could include customer portals,
online customer service help desks, and other locations, such as any
portals through which enrollees and former enrollees might request
disclosure of their data to a third-party application through the
payer's API. We also proposed that the payer must make this information
available in non-technical, simple, and easy to understand language.
We explained in the proposed rule how we anticipate that payers
could meet the requirement to provide information to current and former
enrollees in whole or in part using materials designed for consumer
audiences that are available on the HHS website. However, we noted that
whether the organization chooses to draft its own resource materials to
provide the required information or to
[[Page 25551]]
rely on governmental or other sources for such materials, the
organization will be responsible for ensuring that the content of the
materials is adequate to inform the patient regarding the privacy and
security risks, and that it remains current as relevant law and policy
may evolve over time. We sought comment on the proposal, and we invited
additional comments on what specific information resources in addition
to those already available on the websites noted above would be most
useful to entities in meeting this requirement. We anticipated using
this feedback to help inform HHS planning and prioritization of
informational resource development work in addition to making a
decision on the final rule regarding the proposal.
We summarize the public comments we received on enrollee resources
and provide our responses.
Comment: Several commenters supported the enrollee resources
proposal that would require payers to make information available to
consumers about selecting an app, safeguarding data, and submitting
complaints. Several commenters supported the recommendation that the
resources be available in consumer-friendly language and be presented
in a way that is easy for consumers to understand. One commenter
requested more information about whether payers may make the
educational information available through electronic disclosures, such
as emailing the information to enrollees, in addition to making the
information available online.
Response: We appreciate the commenters' support. We do note that
payers may share the information through other appropriate mechanisms
usually used to communicate with patients, such as secure email, as
well as include the information on a payer website.
Comment: A few commenters recommended that CMS provide patient
education resources to help patients understand the information
available to them through the payers' APIs. These commenters expressed
concerns that patients may not fully understand the context of the
data, such as detailed claims information that may not be intuitive to
understand. Several commenters expressed concern with consumers' lack
of knowledge about the privacy and security of their health information
as it relates to third-party applications. Several commenters expressed
concern that consumers may not understand that their health information
is not protected by HIPAA once the information is sent to a non-covered
third-party app or how an app may use their health information.
Many commenters recommended that CMS develop and/or support
education for consumers. Several commenters stated that CMS should have
the responsibility to develop educational materials, rather than the
payers or providers. Many commenters recommended that CMS collaborate
with other regulatory agencies, including OCR and the FTC, to provide
consumer education and notification materials. Several commenters
recommended that CMS and other HHS agencies develop a campaign to
educate patients about the privacy and security of health information,
including the risks and challenges when connecting to third-party apps
as well as differences between HIPAA and non-HIPAA covered entities and
how the differences may affect how their data are used, stored, and
shared.
Specifically, a few commenters recommended that CMS and FTC should
require that third-party app developers inform consumers that HIPAA
privacy rules will not apply when they agree to share their data with
apps and describe how they will use the consumer's data. One commenter
recommended that educational materials include information on the
differences between HIPAA and FTC protections. One commenter
recommended that CMS, OCR, or FTC publish the resources on their
website and maintain a complaint portal. A few commenters stated that
it is the responsibility of all stakeholders to inform consumers of
their rights and use of PHI. One commenter recommended that the
responsibility of providing educational materials to the consumer
should fall on an organization where the patient may have a longer-
term, non-transactional relationship, such as an HIE.
Several commenters expressed concern that educational resources
will not be enough to promote privacy and security. Several commenters
recommended that CMS and ONC should require third-party apps to provide
notifications on how they may use, share, or sell their health
information. One commenter expressed concern that there will not be
enough oversight over third-party apps. The commenter recommended that
CMS use HIPAA as a framework for developing a privacy structure for
third-party apps.
Response: We appreciate the commenters' concerns and
recommendations. We agree it is important to help ensure patients fully
understand their health information, their rights, and the implications
of sharing their information. It is also important patients know what
to do if there is a breach of their health information. We appreciate
that it would eliminate some burden from payers and providers if we
assist with the production of the educational materials needed for the
purposes of the requirements in this final rule. As a result, CMS is
providing suggested content for educational materials that payers can
use to tailor to their patient population and share with patients. We
are finalizing the requirement with modification that payers must
publish on their websites the necessary educational information, but we
will help supply the content needed to meet this requirement. The
suggested content we are providing for the educational materials will
be shared through our normal communication channels including via
listservs and is available via our website: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. The
modification we are making is to refine the language in the regulation
text to expressly state that payers must include a discussion about a
third-party app's secondary uses of data when providing factors to
consider in selecting an application at 42 CFR 422.119(g)(1),
431.60(f)(1), and 457.730(f)(1), and 45 CFR 156.221(g)(1). In addition,
at 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g),
we are modifying the regulation text to state the payer must make these
materials available in an easily accessible location on its public
website.
We note, however, that our authority is limited to helping payers
educate patients about their privacy and security rights and where they
can go for additional information. We have shared commenter feedback
with our federal partners and will continue to work with all
stakeholders to ensure patients, providers, and payers have the
information they need to address privacy and security issues relevant
to the regulations finalized in this rule. We will also continue
coordinating with ONC and all of our federal partners through the
Federal Health IT Coordinating Council and other federal partnering
opportunities to ensure we are tracking the impact of this final rule
together, as appropriate. Privacy and security, however, is a much
larger issue, and we remind commenters that CMS does not have authority
to regulate third-party apps or their developers or develop privacy
frameworks that exceed the scope of our authority or this final rule.
Comment: Several commenters provided additional recommendations
related to patient resources. One commenter recommended requiring
[[Page 25552]]
payers to include information on how the consumer can contact the payer
directly to report a privacy or security breach. One commenter
recommended that CMS develop an easy-to-understand questionnaire for
third-party applications to fill out that included information about
how the app plans to use the data. This questionnaire could be
available to patients. One commenter recommended that educational
information about tools be available to family members and clinicians
and not just the patient. One commenter suggested including educational
content for specific conditions or patient populations, such as for
pediatric care.
Several commenters recommended that CMS include a requirement that
the educational materials developed for consumers should also include
materials for consumers who may be limited English proficient or have
low health literacy. A few commenters recommended that educational
materials should be developed with special considerations for
vulnerable populations. One commenter recommended that consistent
information be available across multiple settings to accommodate
varying levels of technology literacy.
Response: We appreciate the commenters' recommendations. As
indicated above, we will be providing suggested content for educational
materials to assist payers in meeting their educational obligations
under this final rule as detailed at 42 CFR 422.119(g), 431.60(f), and
457.730(f), and 45 CFR 156.221(g). We note that this would also be
available to caregivers and family members as we are requiring this
material to be posted on the payer's website. Payers can tailor these
materials to best meet the needs of their patient populations,
including literacy levels, languages spoken, conditions, etc. Regarding
recommendations to have patients contact the payer directly in the
event of a breach, that is the patient's prerogative; a payer is
required by the HIPAA Privacy Rule to have procedures for individuals
to submit complaints, and to provide directions for doing so in its
Notice of Privacy Practices. Individuals may also submit complaints to
the OCR and FTC, in the appropriate situations, to address these
concerns. Finally, we reiterate that we do not have the authority to
regulate apps, so we cannot ask apps to fill out a questionnaire or
facilitate sharing that information with patients. We do note that we
are making available a document containing best practices for app
developers to follow, with a special emphasis on ways to protect the
privacy and security of patient data: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
i. Exceptions or Provisions Specific to Certain Programs or Sub-
Programs
We proposed certain exceptions or specific additional provisions as
part of the CMS Interoperability and Patient Access proposed rule (84
FR 7637) for certain QHP issuers on the FFEs. We also proposed
specifics about how MA organizations subject to the regulations
finalized here would have to include certain information about the Part
D benefit if the MA organization also offered Part D benefits; those
aspects of the proposals are addressed in section III.C.2.c(1) of this
final rule.
Related to QHP issuers, we specifically proposed two exceptions.
First, we proposed that the requirements proposed in 45 CFR 156.221(a)
not apply to issuers offering only SADPs on the FFEs. In contrast to
QHP issuers of medical plans, issuers offering only SADPs offer
enrollees access to a unique and specialized form of medical care. We
believed the proposed standards and health IT investment would be
overly burdensome for SADP issuers as related to their current
enrollment and premium intake and could result in SADP issuers no
longer participating in FFEs, which would not be in the best interest
of enrollees. Additionally, we believed much of the benefit to
enrollees from requiring issuers of QHPs to make patient data more
easily available through a standard format depends upon deployment of
standards-based API technology that conforms to standards proposed by
ONC for HHS adoption at 45 CFR 170.215 (84 FR 7589) and a corresponding
energetic response by the developer community in developing innovative,
useful, usable, and affordable consumer-facing applications through
which plan enrollees can conveniently access, use, and share their
information as they choose. Based on the proposals to require
implementation of standards-based API technology in the Medicare,
Medicaid and CHIP programs, as well as by QHP issuers on the FFEs, we
would anticipate significantly expanding the implementation of
standards-based APIs by medical plans. However, we noted that we did
not anticipate similar widespread usage with respect to SADPs.
Therefore, we believed that the utility of access to issuers' data is
less applicable to dental coverage, and did not believe it would be in
the interest of qualified individuals and qualified employers in the
states in which an FFE operates to not certify SADPs because they do
not provide patient access to their data through a standards-based API.
We sought comment on whether we should apply this policy to SADP
issuers in the future.
We also proposed to provide an exceptions process through which the
FFEs may certify health plans that do not provide patient access
through a standards-based API, but otherwise meet the requirements for
QHP certification. We proposed in 45 CFR 156.221(h)(1) that if a plan
applying for QHP certification that is to be offered through an FFE
does not provide patient access to their data through a standards-based
API, the issuer must include as part of its QHP application a narrative
justification outlining the reasons why the plan cannot reasonably
satisfy the requirements in proposed 45 CFR 156.221(a), (b), or (c),
the impact of non-compliance upon enrollees, the current or proposed
means of providing health information to enrollees, and proposed
solutions and timeline to achieve API compliance. In 45 CFR
156.221(h)(2), we proposed that the FFE may grant an exception to the
requirement to provide enrollees access to data through standards-based
API technology, if the FFE determines that making available such health
plan is in the interest of qualified individuals and qualified
employers in a particular FFE state. We anticipated that this exception
would be provided in limited situations. For example, we would consider
providing an exception for small issuers, issuers who are only in the
individual or small group market, financially vulnerable issuers, or
new entrants to the FFEs who demonstrate that deploying standards-based
API technology consistent with the required interoperability standards
would pose a significant barrier to the issuer's ability to provide
coverage to consumers, and not certifying the issuer's QHP or QHPs
would result in consumers having few or no plan options in certain
areas. We sought comment on other circumstances in which the FFE should
consider providing an exception.
We summarize the public comments we received on QHP exemptions and
provide our responses.
Comment: Several commenters supported CMS' proposal to exempt SADPs
from the requirements to provide a patient API. These commenters agreed
with the justification offered that dental information may not be as
useful to patients, as well as the resource burden concern for SADPs. A
few commenters did not support the proposal to exempt SADPs from the
patient API proposed requirements, suggesting it may help dentists and
their patients make more
[[Page 25553]]
informed decisions and that dental information may help other health
care providers for patient treatment.
Response: We appreciate the commenters support, as well as the
concerns raised. We believe the financial impact on SADP issuers may
result in fewer SADPs available in the FFEs. We may consider the
application of this policy to SADP issuers in future rulemaking. We are
finalizing this policy as proposed and exempting SADPs from the Patient
Access API at this time.
Comment: A few commenters expressed support for the proposal to
allow CMS to review a QHP issuer's justification for an exception to
the Patient Access API proposal. One commenter recommended CMS require
QHPs that are granted an exception to notify potential enrollees that
they will not be compliant with the requirement to provide enrollees
access to data through standards-based API technology. A few commenters
did not support or expressed concern with CMS' proposal to grant QHPs
an exception process, fearing an impact to patient care and uneven
patient access to health data. One commenter did not want plans and
entities to function solely as data consumers or aggregators. One
commenter suggested that exceptions should be rare, limited, and for a
defined duration.
A few commenters recommended CMS establish or work with plans to
make clear the evaluation criteria for reviewing exception requests to
ensure parity. One commenter recommended CMS define a standard for
expected alternative API implementation timeline. This commenter also
recommended CMS establish a timeline for evaluating exception requests.
One commenter requested CMS specify how justifications will be
submitted as well as guidance in its annual Letter to Issuers in the
FFEs to assist providers in understanding the requirements of the
exception application process.
Response: We appreciate the commenters' concerns and
recommendations. Regarding concerns that this exception would impact
care and access to health data, we believe it is more important to
ensure patients have access to QHPs, and if an exception can provide
consumers continued coverage, the exception is the preferable approach.
We are evaluating the additional recommendations provided for future
consideration. Further, in order to better clarify the applicability of
the API-related requirements, we are revising 45 CFR 156.221(h) to
expand the exceptions process to encompass all requirements in
paragraphs (a) through (g), rather than (a) through (c) in the proposed
rule. This will ensure that QHP issuers on the FFEs that are not able
to meet any of the standards will be subject to the exceptions process.
Again, we believe that ensuring patients have access to QHPs is
paramount. We also note that additional guidance will be provided to
QHP issuers in the future in order to specify how issuers will
demonstrate compliance with these standards.
Comment: Several commenters recommended that CMS expand the
proposal to provide exemptions to the Patient Access API proposal to
other types of plans for similar reasons including implementation
burden and potential unintended consequences, such as driving plans out
of the market. The types of payers that the commenters recommended be
provided exemptions include MA, Medicaid (including MCOs, Medicare-
Medicaid Plans, Fully Integrated Dual-Eligible Special Needs Plan,
Long-Term Services and Supports), CHIP, public health agencies, smaller
QHPs and small plans, and new and current QHP issuers. A few commenters
recommended CMS include ``local plans'' in the definition of ``small
issuer.'' One commenter recommended that tribes also be exempt from
this policy.
Response: We appreciate the commenters' recommendations, and we
appreciate the concerns that certain payers may have unique
circumstances making new requirements potentially more challenging. We
note that these policies only apply to Medicare Advantage
organizations, Medicaid and CHIP FFS programs, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs. We are
only finalizing one exemption, the exception noted below, not
identified in the proposed rule, however. We do not believe the burden
or potential unintended consequences outweigh the immense benefit to
patients and the potential for improved health outcomes these policies
can facilitate.
As noted earlier in this final rule, we are modifying the scope of
the applicability of the regulations to QHP issuers on an individual
market FFE. In considering the application to issuers offering plans
through the FF-SHOPs, we believe that, like the exception for issuers
of SADPs discussed above, the financial burden to implement these
policies may result in fewer issuers offering plans through the FF-
SHOPs and could result in small employers and consumers having fewer or
no FF-SHOP plan options. Further, we believe that most FF-SHOP issuers
likely would qualify for exclusion via the exceptions process we are
finalizing. We have modified 45 CFR 156.221(h)(2) to remove the
reference to ``qualified employers'' and paragraph (i) to include
applicability to individual market FFEs.
j. Applicability and Timing
At 42 CFR 422.119(h) and 45 CFR 156.221(i), we proposed specific
provisions regarding applicability and timing for MA organizations and
QHP issuers on the FFEs that would be subject to the proposal. We did
not propose specific regulation text for 42 CFR 431.60 or 438.242
because we intended to make the regulation text effective on the
applicable date, as discussed below. We noted that we expected that
state Medicaid and CHIP agencies would be aware of upcoming new
regulations and planning for compliance with them when they are
applicable, even if the new regulation is not yet codified in the CFR;
we similarly expected that such agencies will ensure that their managed
care plans/entities will be prepared for compliance. Unlike Medicaid
state agencies and managed care plans and state CHIP agencies and
managed care entities, MA organizations and QHP issuers on the FFEs
generally are subject to rules regarding bid and application
submissions to CMS in advance of the coverage period; for example, MA
organizations must submit bids to CMS by the first Monday in June of
the year before coverage starts in order to be awarded an MA contract.
In an abundance of caution and to ensure that these requirements for MA
organizations and QHP issuers on the FFEs are enforceable and reflected
in the bids and applications these entities submit to us in advance of
when the actual requirements must be met, we proposed to codify the
actual compliance and applicability dates of these requirements. We
solicited comment on this approach.
For MA organizations, under 42 CFR 422.119(h), we proposed that the
requirements would be applicable beginning January 1, 2020. Under the
proposal, the requirements at 42 CFR 422.119 would be applicable for
all MA organizations with contracts to offer any MA plan on that date
and thereafter. We requested feedback about the proposed timing from
the industry. In particular, we solicited information and requested
comment from MA organizations about their current capability to
implement an API consistent with the proposal and the costs associated
with compliance by January 1, 2020, versus compliance by a future date.
For Medicaid FFS at 42 CFR 431.60, CHIP agencies that operate FFS
systems at 42 CFR 457.730, Medicaid managed
[[Page 25554]]
care plans at 42 CFR 438.242(b)(6) (finalized as Sec. 438.242(b)(5) in
this rule; see section VI.), and CHIP managed care entities at 42 CFR
457.1233(d)(2), we proposed that the API requirements would be
applicable beginning July 1, 2020, regardless of when the managed care
contract started. We noted that given the expected date of publication
of the final rule, we believed July 1, 2020, would provide state
Medicaid agencies and CHIP agencies that operate FFS systems, Medicaid
managed care plans, and CHIP managed care entities sufficient time to
implement. We solicited comment on the proposal and whether additional
flexibility would be necessary to take into account the contract terms
that states use for their Medicaid managed care plans.
For CHIP, we noted that we are aware that some states do not
provide any benefits on a FFS basis, and we did not intend for those
states to implement an API outside their managed care plans. Therefore,
we proposed in 42 CFR 457.700(c) that separate CHIP agencies that
provide benefits exclusively through managed care entities may meet the
requirements of 42 CFR 457.730 by requiring the managed care entities
to meet the requirements of 42 CFR 457.1233(d)(2) beginning July 1,
2020.
For QHP issuers on the FFEs, we proposed in 45 CFR 156.221(i) that
these requirements would be applicable for plan years beginning on or
after January 1, 2020. We sought comment on the timing of these
requirements, and on how long issuers, particularly smaller issuers,
anticipate it would take to come into compliance with these
requirements.
We explained in the CMS Interoperability and Patient Access
proposed rule our belief that these proposals would help to create a
health care information ecosystem that allows and encourages the health
care market to tailor products and services to compete for patients,
thereby increasing quality, decreasing costs, and helping them live
better, healthier lives. Additionally, under these proposals,
physicians would be able to access information on their patient's
current prescriptions and services by reviewing the information with
the patient on the patient's personal device or by the patient sharing
data with the provider's EHR system, which would save time during
appointments and ultimately improve the quality of care delivered to
beneficiaries. Most health care professionals and consumers have
widespread access to the internet, providing many access points for
viewing health care data over secure connections. These proposed
requirements would significantly improve beneficiaries' experiences by
providing a secure mechanism through which they can access their data
in a standardized, computable format.
We noted that these proposals were designed to empower patients by
making sure that they have access to health information about
themselves in a usable digital format and can make decisions about how,
with whom, and for what uses they will share it. By making claims data
readily available and portable to the enrollee, these initiatives
supported efforts to move our health care system away from a FFS
payment system that pays for volume and toward a payment system that
pays for value and quality by reducing duplication of services, adding
efficiency to patient visits to providers; and, facilitating
identification of fraud, waste, and abuse. Data interoperability is
critical to the success of new payment models and approaches that
incentivize high quality, efficient care. All of the health care
providers for a patient need to coordinate their care for a value-based
system to work, and that requires information to be securely shareable
in standardized, computable formats. Moreover, we noted that patients
needed to understand and be actively involved in their care under a
value-based framework. We committed to supporting requirements that
focus on these goals, and we noted we believe that the specific
proposals supported these efforts.
We summarize the public comments we received on applicability and
timing of the Patient Access API and provide our responses.
Comment: A few commenters supported the proposed timeline for
implementing APIs. One commenter believes that payers have sufficient
time to prepare APIs and recommended that CMS maintain the proposed
timeline. One commenter suggested that to address payer concerns CMS
could reward plans, such as through higher HEDIS scores, who are able
to meet the January 1, 2020 date.
Many commenters expressed concern with the proposed implementation
timelines. Many commenters believed that payers and developers will
need more time to implement the requirements and encouraged CMS to
delay the implementation date. A few commenters were concerned that
without sufficient time and resources to implement security protocols,
payers will be unable to meet the proposed requirements. Many
commenters believed that additional time will allow health IT vendors
and payers to develop, test, and implement the necessary systems.
Several commenters expressed concern with the costs needed to implement
the proposals under the proposed timelines.
Several commenters recommended an implementation deadline no
earlier than 2021, while several other commenters recommended a
proposed implementation date of January 1, 2022. One commenter each
suggested January 1, 2023 and January 1, 2024, while another
recommended 12 months after the publication of the rule. Many
commenters recommended a timeline of at least 18 to 24 months after
publication of the final rule. Several commenters recommended aligning
the CMS timelines with the ONC timelines, therefore recommending CMS
implement policies in this final rule 2 years after the publication of
this final rule. A few commenters recommended a 36-month timeline for
all proposed policy implementation dates included in this rulemaking.
A few commenters did not support proposing a timeline yet. The
commenters noted that the standards and the infrastructure should be
more mature before implementation dates are set. One commenter
suggested that CMS and ONC convene a planning group to establish a more
appropriate timeline.
Several commenters encouraged CMS take a phased approach, which
some explained as creating a ``glide path'' from ``proof of concept''
to more advanced use cases and a more expansive set of data. Commenters
had a few different recommendations for which data elements could be
included in which phase of the implementation in such a scenario. A few
commenters suggested an approach where smaller plans meet fewer
requirements initially and phase-in to full adoption. One commenter
requested that CMS exempt small issuers from the requirements of the
rule.
A few commenters recommended delaying any disincentives and/or
penalties until 2 years after implementation. One commenter expressed
concern that the different implementation dates for different payers
may create confusion, particularly for dual eligible beneficiaries.
Response: We appreciate the commenters' concerns and
recommendations. We understand that payers need time to be able to
develop, test, and implement the APIs being finalized in this rule. We
appreciate that it will take time to map and prepare historic data for
sharing via the standards-based FHIR API. We want to be sure that
payers have the time and guidance needed to fully and accurately
[[Page 25555]]
implement the policies being finalized in this rulemaking. We do not
agree, however, that it is necessary to convene a planning group to
develop a timeline for implementation. The public has had the
opportunity to provide feedback on this issue as part of this
rulemaking. As a result, we are finalizing the implementation date of
the Patient Access API as January 1, 2021 for all payers impacted by
this rulemaking, except for QHP issuers on the FFEs, for which the rule
will be applicable beginning with plan years beginning on or after
January 1, 2021. We strongly encourage payers to implement these
policies as soon as they are capable, but the Patient Access API will
not be required until January 1, 2021. For Medicaid managed care, we
remind states that should they determine that obligations in this rule
warrant a retroactive adjustment to capitation rates, those adjustments
must be certified by an actuary in a revised rate certification and
submitted to CMS as a contract amendment, pursuant to 42 CFR 438.7(c).
We do appreciate the commenters' suggestion to evaluate a phased
implementation approach. As a result, you will see in section IV. of
this final rule how we are using the Provider Directory API proposal as
a way for payers to show they are making progress toward API
development and access.
k. Request for Information on Information Sharing Between Payers and
Providers Through APIs
We proposed the implementation of standards-based APIs for making
accessible data that a third party could use to create applications for
patients to access data in order to coordinate and better participate
in their medical treatment. While in some instances, direct provider to
health plan transmission of health information may be more appropriate
than sharing data through a standards-based API, in other instances a
patient may wish to send a provider a copy of their health information
via another health care provider's API. In such cases, patients could
direct the payer to transmit the health information to an application
(for example, an application offered by a health care provider to
obtain patient claims and encounter data, as well as lab test results
(if applicable)) on a one-off and as-needed basis. To the extent a
HIPAA covered entity offers patients access to their records via a
standards-based application, another HIPAA covered entity may be able
to obtain an individual's health information from the app for
treatment, payment, or certain health care operations purposes, without
need of an individual's authorization, consistent with the HIPAA Rules
(see 45 CFR 164.506). Under other laws, providers may need to obtain
specific individual consent to obtain health information related to
care provided by a behavioral health provider, treatment received at a
substance use disorder treatment facility, certain 42 CFR part 2-
covered diagnoses or other claims-related information, or labs that
suggest a part 2 diagnosis. We explained in the CMS Interoperability
and Patient Access proposed rule how we did not intend to expand any
scope of authority to access patient data nor to contravene existing
requirements related to disclosure of PHI under the HIPAA Rules and
other legal standards, but instead specified a new and additional
mechanism by which to share health information as directed by the
individual, through the use of API technology in compliance with all
existing federal, state, local, and tribal privacy and security laws.
We explained how, in the future, we anticipate payers and providers
may seek to coordinate care and share information in such a way as to
request data on providers' or a payer's patient/insured overlapping
population(s) in one transaction. We sought comment for possible
consideration in future rulemaking on the feasibility of providers
being able to request a download on a shared patient population using a
standards-based API. We thank commenters for their insights and are
reviewing the comments received for inclusion in potential future
rulemaking.
In addition to the comments we received about the specific sections
of this Patient Access API proposal, we also received a number of
comments that were specific to the types of payers impacted by the
proposal, generally. We summarize these public comments by payer type
and provide our responses.
We received these public comments related to Medicare Advantage.
Comment: One commenter suggested CMS require that MA organizations
make patient data maintained in connection with the organizations'
various individual and small group market plans available for access
and exchange through the Patient Access API.
Response: We appreciate the commenter's suggestion. However, in
light of the limits on CMS's authority over MA organizations,
commercial insurance, and group health plans, we are not adopting
requirements to apply as broadly as the commenter suggested. We note
that QHP issuers on the individual market FFEs are required under this
final rule to implement the Patient Access API, and we encourage other
individual markets, as well as small group market plans and group
health plans to do so, as well.
Comment: One commenter recommended CMS specify the expectations of
MA organizations regarding supplemental benefits in relation to the
Patient Access API. One commenter recommended CMS evaluate whether the
standards proposed for this API are appropriate for the dental care
space.
Response: We appreciate the commenter's request for additional
information. We note that MA claims data, encounter data, and clinical
data related to supplemental benefits, including dental services, are
subject to the API requirement, even if issuers only offering SADPs on
FFEs are not subject to the requirement.
Comment: One commenter requested additional information on whether
Medicare Advantage D-SNPs would be required to provide patients an API.
Response: We appreciate the commenter's request for additional
information. We note D-SNPs are MA plans offered by MA organizations
and therefore subject to the API requirement adopted at 42 CFR 422.119.
Comment: One commenter requested additional information of whether
data shared via an API would be subject to member communication rules,
such as Medicare Communications and Marketing Guidelines.
Response: We appreciate the commenter's request for additional
information. Whether or not data shared via the Patient Access API
being finalized at 42 CFR 422.119(b) falls under the purview of CMS's
communication and marketing rules would be dependent on factors such as
the relationship of the developer and the MA plan(s), the content
accompanying the API data, and the intended outcome of the application
using the API data. MA plans must continue to follow the provisions of
42 CFR part 422 (such as but not limited to 42 CFR 422.118(d), 422.2260
through 422.2268), including in circumstances when their communications
and marketing materials include data that is retrieved through an API.
For example, if a field marketing organization (FMO) uses API data to
create a software application that compares the provider networks for
the plans the FMO is contracted to sell, the application would fall
under the MA marketing and communications regulations and CMS's
oversight. Conversely, if a developer uses API data to create an
independent application that provides an alternative
[[Page 25556]]
means of scheduling provider appointments, the application would fall
outside of CMS's purview.
We received these public comments related to Medicaid and CHIP.
Comment: Several commenters requested additional information on
which Medicaid programs would be required to implement and maintain a
standards-based API. One commenter wanted additional information as to
whether all state's Medicaid Management Information Systems (MMIS)
would be required to develop APIs. This commenter stated that while it
seemed clear that the rule does not require health plans to use Health
IT modules to make administrative data available, the role of a payer's
claims adjudication system (including MMIS) is unclear.
Response: We appreciate the commenters' request for information. In
proposed 42 CFR 431.60 and 457.730, we specified that states would have
to implement and maintain an API for FFS Medicaid programs and CHIP; we
also proposed in 42 CFR 438.242(b)(6) (finalized as 42 CFR
438.242(b)(5) in this rule; see section VI.) and 457.1233(d) that
states would have to require each MCO, PIHP, and PAHP to comply with 42
CFR 431.60 (under Medicaid managed care contracts) and 457.730 (under
CHIP managed care contracts) as if such requirements applied directly
to them. We are finalizing these policies as proposed. Sections 431.60
and 457.730 do not require a specific system to be used for the
implementation and maintenance of the API, thus we defer to each state
and Medicaid managed care plan to determine which of their systems
would be the most appropriate.
Comment: One commenter requested that CMS clarify if an arrangement
in which a state provided beneficiaries access to their FFS data by
delegating the API function to a managed care plan would be sufficient
to satisfy the rule, or if each entity in the chain is required to
implement their own systems, portals, and/or API interfaces. This
commenter questioned if CMS envisioned the creation of a national
network to exchange Medicare/Medicaid records that would satisfy these
requirements in a centralized fashion.
Response: We appreciate the commenter's request for information. We
are, however, somewhat unclear what the commenter meant by ``delegating
the API function to a managed care plan.'' We believe the commenter may
be questioning if a state could utilize a managed care plan to
implement the API required for the state's FFS beneficiaries in lieu of
the state implementing the API required in 42 CFR 431.60. If so, the
proposed rule did not anticipate nor prohibit that type of an
arrangement. As such, this final rule could permit such an arrangement,
but we remind a state contemplating using such an arrangement that it
must meet the all of the requirements in this final rule, including the
timelines and scope specified for data accessibility in Sec.
431.60(b). There is no plan for a national network to exchange
Medicare/Medicaid records in lieu of the APIs being finalized in this
rule at this time.
Comment: One commenter suggested that CMS establish a stakeholder
workgroup to identify best practices in data-sharing with Medicaid
beneficiaries.
Response: We appreciate this suggestion and encourage states and
Medicaid managed care plans to work with their stakeholders to identify
best practices for data-sharing with Medicaid beneficiaries in their
states.
Comment: A commenter expressed concern that reimbursing states for
modification of their IT systems at an enhanced match rate while
reimbursing managed care plans for their system modifications at the
state's standard match rate creates an uneven playing field for
Medicaid managed care plans and a disparity of funding. This commenter
noted that in states that make extensive use of managed care, the bulk
of system modifications needed to carry out and maintain the proposed
interoperability capabilities for Medicaid enrollees will be borne by
Medicaid managed care plans and requested that CMS revise its proposal
to reflect that all costs attributable to design, development,
installation, enhancement, or ongoing operation of both state and
Medicaid managed care plan systems will receive the appropriate
enhanced federal match. Finally, this commenter requested that CMS take
a more rigorous approach and update its methodology for review of state
MCO capitation rates to ensure that proposed rates include reasonable
allowances for costs of IT systems work performed by the state's
Medicaid managed care plans in furtherance of the proposals in this
regulation.
Response: We appreciate the commenter's concern. However, we do not
agree that the difference in the federal match rate creates an uneven
playing field. Capitation rates must be actuarially sound independent
of the federal matching rate that applies to the payment of those
rates. The provision of enhanced federal match rate is addressed in
section 1903(a)(3)(A) of the Act and provides a 90 percent match rate
for ``. . . the sums expended during such quarter as are attributable
to the design, development, or installation of such mechanized claims
processing and information retrieval systems as the Secretary
determines are likely to provide more efficient, economical, and
effective administration of the plan . . .'' It does not specifically
provide an enhanced match rate for the portion of a capitation rate
that may be included for information technology expenditures, and we do
not have the authority to extend the enhanced match rate beyond the
conditions specified in statute. We already have a very rigorous
capitation rate review process and will review any changes noted by the
states in those rates, including any specifically noted for IT system
enhancements specific to the requirements finalized in this rule.
Comment: One commenter requested that the new requirement to
implement and maintain an API must be uniform across the system and
non-negotiable to Medicaid managed care plans, state government, and
providers. One commenter noted that CMS should address situations where
states may choose to adopt additional or conflicting data sharing
requirements in Medicaid or CHIP managed care contracts. This commenter
further stated that it is critical that covered health plans be subject
to uniform standards for data accessed through an API and that CMS
should work with state Medicaid and CHIP programs to ensure that any
state mandated requirements for data accessed through an API are
harmonized with the new federal standards. This commenter suggested
that submission of the encounters in a timely manner by all involved
with the new rule must be a non-negotiable condition for the receipt of
Medicare or Medicaid reimbursement. In addition, the commenter noted
that enforcement cannot be left to plans based on variable contract
terms but must be provided by federal agencies.
Response: We agree with the commenter that implementation of
standards-based APIs should be consistent across states and Medicaid
and CHIP managed care plans and have codified the requirements for APIs
in 42 CFR 431.60(b), 457.730(b), 438.242(b)(6) (finalized as
438.242(b)(5) in this rule; see section VI.), and 457.1233(d) to ensure
an appropriate level of uniformity and consistency while still
providing states with an adequate level of flexibility to go beyond the
minimum standards included in this final rule when they believe doing
so benefits their beneficiaries. While we do not have a specific
provisions that
[[Page 25557]]
conditions payment on the timely receipt of encounters, states and
managed care plans may find that a useful provision to include in their
contracts. States must have a monitoring system in effect for their
Medicaid managed care programs under Sec. 438.66(b)(6), which also
specifies ``information systems, including encounter data reporting''
as a required element. Similarly, we have certain program oversight
responsibilities, such as the review of certain Medicaid and CHIP
managed care contracts and all capitation rates, and will incorporate
oversight of requirements in this final rule to the extent appropriate.
Comment: One commenter noted that CMS encourages the Medicaid and
CHIP FFS programs to use the API as a means to exchange PHI with
providers for treatment purposes, suggesting the data would be shared
in advance of a patient's visit. But CMS also states that this proposal
can empower the patient to decide how their health information is going
to be used. This commenter requested additional information of the role
CMS intends for the patient and the provider to have in the use of
APIs.
Response: While we believe that a beneficiary's use of an API to
obtain their health care data will play an important role in their
health care, as proposed and finalized, this rule does not set
standards for health care provider use of apps to obtain information
from payers. As proposed and finalized in 42 CFR 431.60(a) and
457.730(a), the API permits third-party applications to retrieve a
patient's data at the patient's request. A beneficiary may make the
decision to obtain their health care data through such an app and share
it with a provider in advance of a visit or otherwise.
Comment: One commenter requested clarity on whether the proposed
rule requires all states' MMIS [Medicaid Management Information System]
to make information available to patients within one (1) business day
of receipt or adjudication of administrative data (adjudicated claims,
encounters, provider remittance, etc.). This commenter expressed
concern that these data could appear to conflict with data obtained by
a patient directly from a managed care plan, causing confusion and
increasing administrative overhead.
Response: We appreciate the commenter's request for additional
information. Medicaid beneficiaries should not be receiving the
information from both the state and managed care plan for the same
service. If the beneficiary is receiving a service under the state's
Medicaid FFS program, the requirements in Sec. 431.60 apply; that is,
the state is responsible for providing the specified data elements in
Sec. 431.60(b) through the API. If the beneficiary is enrolled in a
managed care plan (receiving the service under the managed care plan's
contract), the requirements in Sec. 438.242(b)(5) (proposed as Sec.
438.242(b)(6); see section VI.) apply; that is, the managed care plan
is responsible for providing the specified data elements in Sec.
431.60(b) through the API. The beneficiary should not receive data that
is in conflict with other data that is made available through the API.
The same is true for CHIP. If the beneficiary is in CHIP FFS, the
requirements in Sec. 457.730 apply; that is, the state is responsible
for providing the specified data elements in Sec. 457.730(b) through
an API. If the beneficiary is enrolled in a managed care plan, the
requirements in Sec. 457.1233(d) apply; that is, the managed care plan
is responsible for providing the specified data elements in Sec.
457.730(b) through the API.
Comment: One commenter expressed concerns regarding the ongoing
burden for state Medicaid and CHIP agencies to monitor the API, privacy
and security features, and potential security risks posed by the
numerous applications that may connect to the API. This commenter
recommended that states be required to monitor the compliance of each
of their managed care plans regarding the API requirements.
Response: We understand the commenter's concerns about burden
related to the API, as well as the need for states to monitor the API
for privacy and security. These requirements are specified at 42 CFR
431.60(c)(1) and (2) and 457.730(c)(1) and (2). While we understand
that there is some burden for states and managed care plans related to
the development and implementation of the API, we continue to believe
that the benefits and potential for improved health outcomes outweigh
the burden associated with these requirements. We also confirm for
commenters that states are required to monitor compliance for their
contracted managed care plans in regard to the API requirements under
42 CFR 438.242(b)(5) (proposed as 42 CFR 438.242(b)(6); see section
VI.) and 457.1233(d). Since these requirements apply to managed care
plans, states are required to include the requirements under their
managed care contracts and must ensure that plans comply with the
standards specified in 42 CFR 431.60 and 457.730 as if those
requirements applied directly to the managed care plan.
Comment: Several commenters stated that the Patient Access API
proposal places a significant burden on Medicaid and CHIP beneficiaries
to monitor the privacy and security of their own health information
while it is being accessed by non-HIPAA covered entities. One commenter
recommended that CMS consider how educational efforts could be uniquely
tailored to specific populations, such as Medicaid beneficiaries,
particularly given the need for special considerations when attempting
to engage with vulnerable populations. This commenter recommended that
CMS amend or revise the current language in its proposed rule to
explicitly require that API vendors be responsible for the education of
consumers. Another commenter noted that many Medicaid and CHIP
beneficiaries are children and that app developers, states, and managed
care plans will also need to develop resources for minor access and
control over health information and educate members accordingly.
Response: We appreciate the commenters' concerns, and we
acknowledge that some Medicaid beneficiaries may find negotiating the
privacy and security app landscape burdensome. Any patient, including
one who is not comfortable with technology, may choose not to use this
method of data exchange. However, we would like all beneficiaries to be
able to benefit from these apps. One way we are looking to mitigate
this burden is through education. We believe that it is important for
beneficiaries to have the educational resources to be able to best
evaluate their third-party options. States and managed care plans must
comply with the requirements 42 CFR 431.60(f) and 457.730(f) that
require states and managed care plans to develop and provide on a
public website beneficiary resources regarding privacy and security,
including information on how beneficiaries can protect the privacy and
security of their health information in non-technical, simple and easy-
to-understand language. We note in section III.C.2.h. of this final
rule, that CMS will provide suggested content for educational material
payers can use to meet this requirement. States, Medicaid managed care
plans, and CHIP managed care entities have vast experience with
techniques for creating effective communications for their
beneficiaries and we encourage states and managed care plans to tailor
these resources for their Medicaid and CHIP populations. We also agree
that states and managed care plans will need to develop or refine
resources to address patient access for minor populations and for
populations based on health literacy levels. We do
[[Page 25558]]
note that we do not have the authority to regulate vendors. While we
agree that API vendors should have a role in educating consumers,
states and managed care plans are the entities responsible for
developing and implementing the API; therefore, we believe it is more
appropriate for states and managed care plans to develop and provide
the educational resources for beneficiaries.
Comment: A few commenters requested that CMS modify the rule to
exempt Medicaid managed care plans. Commenters noted that Medicaid
managed care plans are already operating with razor thin margins and
the proposed rule will substantially increase the costs for Medicaid
managed care plans. Further, commenters noted that due to the
substantial increase in costs, plans may not be able to meet the MLR
requirements in 42 CFR 438.8. Another commenter suggested that CMS
explicitly exclude from the requirements of the rule long[hyphen]term
services and supports (LTSS) plans. Some commenters also recommended
that CMS exclude dental plans from the requirements in the proposed
rule.
Response: We appreciate the commenters' concerns, however we are
not exempting Medicaid or CHIP managed care plans, including LTSS or
dental plans, from the requirements in this rule, as such an approach
would not be consistent with our goal of ensuring that all
beneficiaries across the health care market, including Medicaid FFS and
managed care, have access to and can exchange specified health care
data. We are finalizing the Patient Access API requirements for state
Medicaid and CHIP agencies and managed care plans, including LTSS and
dental plans. States and managed care plans must make adjudicated
claims and encounter data available through the API for all Medicaid-
covered services, including LTSS and dental. This requirement extends
to all Medicaid-covered services for which a claim, or encounter claim,
is generated and adjudicated. Regarding costs for managed care plans--
since the Patient Access API requirements must be contractual
obligations under the managed care contract--the state must include
these costs in the development of a plan's capitation rates.
Final Action: After consideration of the comments received, and for
the reasons outlined in our response to these comments and in the CMS
Interoperability and Patient Access proposed rule, we are finalizing
with modifications our proposal to require MA organizations, Medicaid
and CHIP FFS programs, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs to implement and maintain a
standards-based Patient Access API that meets the technical standards
as finalized by HHS in the ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register) at 45 CFR
170.215, content and vocabulary standards adopted at 45 CFR part 162
and 42 CFR 423.160, and finalized by HHS at 45 CFR 170.213 (USCDI
version 1), unless alternate standards are required by other applicable
law; includes the data elements specified in this final rule, and
permits third-party applications to retrieve, with the approval and at
the direction of the enrollee, data specified at 42 CFR 422.119,
431.60, 457.730, and 45 CFR 156.221. Specifically, we are finalizing
that the Patient Access API must, at a minimum, make available
adjudicated claims; encounters with capitated providers; provider
remittances; enrollee cost-sharing; and clinical data, including
laboratory results (where maintained by the impacted payer). Data must
be made available no later than one (1) business day after a claim is
adjudicated or encounter data are received by the impacted payer. We
are not finalizing a requirement for the Patient Access API to make
provider directory and pharmacy directory information available.
Instead, to limit burden, we are only requiring provider and, in the
case of MA-PD plans, pharmacy directory information be included in the
Provider Directory API discussed in section IV. of this final rule.
We are finalizing the proposed documentation requirements noting
business and technical documentation necessary to interact with the API
must be made freely and publicly accessible. We note that the APIs need
to comply with all existing federal and state privacy and security
laws. We are finalizing, consistent with the HIPAA Rules that a payer
may deny access to the Patient Access API if the payer reasonably
determines that allowing a specific third-party application to connect
or remain connected to the API would present an unacceptable level of
risk to the security of PHI on the payer's systems based on objective
and verifiable criteria. We are also finalizing that payers need to
make available to enrollees resources explaining factors to consider in
selecting an app for their health information, practical strategies to
safeguard their privacy and security, and how to submit complaints to
OCR or FTC. We do note that we are providing payers with suggested
content they can use and tailor to meet this requirement, available
here: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. We also note that impacted payers are allowed
to request that third-party apps attest to having certain information
included in their privacy policy, and inform patients about this
attestation, to help ensure patients are aware of the privacy risks
associated with their choices.
We are finalizing this policy with the following technical
corrections and additional information. At 42 CFR 422.119(a) and
(b)(1); 42 CFR 431.60(a) and (b); 42 CFR 457.730(a) and (b); and, 45
CFR 156.221(a) and (b) we specify these policies apply to current
patients and their personal representatives. At 42 CFR
422.119(b)(1)(i), (1)(ii), and (2)(i); 42 CFR 431.60(b)(1) and (2); 42
CFR 457.730(b)(1) and (2); and, 45 CFR 156.221(b)(1)(i) and (ii) we are
removing the word ``standardized'' to avoid confusion as the standards
are specified elsewhere. We are finalizing the regulation text at 42
CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), with the verb
``maintains'' in place of the verb ``manages'' in order to more closely
align with the relevant HIPAA Privacy Rule requirement. We are
finalizing a technical correction at 42 CFR 431.60(b)(2) and 42 CFR
457.730(b)(2) to replace ``within one (1) business day'' with ``no
later than 1 business day after'' to be consistent across payers. We
have added text to specifically indicate that the technical
requirements at 42 CFR 422.119(c), 431.60(c), and 457.730(c), and 45
CFR 156.221(c) apply to the API under paragraph (a) of the respective
sections. We are finalizing at 42 CFR 422.119(c)(2), 431.60(c)(2),
457.730(c)(2), and 45 CFR 156.221(c)(2), to include additional text to
explicitly require, as described in the CMS Interoperability and
Patient Access proposed rule (84 FR 7635) the requirement to also
update (as appropriate) the API to ensure it functions properly and
includes assessments to verify an individual enrollee or their personal
representative can only access claims and encounter data or other PHI
that belongs to that enrollee. In addition, we are removing the word
``minimally'' from this regulation text in order to ensure it is clear
that privacy and security features must be reasonable and appropriate,
consistent with the requirements of HIPAA Privacy and Security Rules,
42 CFR parts 2 and 3, and other applicable law protecting privacy and
security of individually identifiable health information. We are making
a technical
[[Page 25559]]
change for readability only at 42 CFR 422.119(c)(3) and (4)(ii)(C),
431.60(c)(3) and (4)(ii)(C), 438.242(b)(5), 457.730(c)(3) and
(4)(ii)(C), 457.1233(d)(1), and 45 CFR 156.221(c)(3) and (4)(ii)(C). In
addition, we have refined the language at 42 CFR 422.119(g), 431.60(f),
and 457.730(f), and 45 CFR 156.221(g) to state the payer must make
education materials available ``in an easily accessible location on its
public website,'' and at 42 CFR 422.119(g)(1), 431.60(f)(1), and
457.730(f)(1), and 45 CFR 156.221(g)(1) to include a reference to
``secondary uses of data.''
At 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 CFR 156.221(d),
we are finalizing additional text to specify that ``publicly
accessible'' means that any person using commonly available technology
to browse the internet could access the information without any
preconditions or additional steps, such as a fee for access to the
documentation; a requirement to receive a copy of the material via
email; a requirement to register or create an account to receive the
documentation; or a requirement to read promotional material or agree
to receive future communications from the organization making the
documentation available.
In the CMS Interoperability and Patient Access proposed rule, the
criteria and process for assessing unacceptable risk to a payers system
was explained as part of the payer's responsibilities under the HIPAA
Security Rule (84 FR 7635). At 42 CFR 422.119(e)(1), 431.60(e)(1),
438.242(b)(5), 457.730(e)(1), and 457.1233(d), as well as 45 CFR
156.221(e)(1) we are finalizing additional text to note that payers
should determine risk consistent with its security risk analysis under
45 CFR part 164 subpart C to indicate the specific section of the HIPAA
Security Rule implicated here. We are modifying 45 CFR 156.221(h)(2) to
remove the reference to ``qualified employers'' and 45 CFR 156.221(i)
to include applicability to ``individual market'' FFEs to exclude
issuers offering plans through the FF-SHOPs. Finally, we are finalizing
for MA organizations at 42 CFR 422.119(h), Medicaid FFS programs at 42
CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii),
CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at
42 CFR 457.1233(d), that beginning January 1, 2021, and for QHP issuers
on the FFEs at 45 CFR 156.221(i) beginning with plan years beginning on
or after January 1, 2021, these payers must make available through the
Patient Access API data they maintain with a date of service on or
after January 1, 2016, consistent with the payer-to-payer data exchange
requirement discussed in section V. of this final rule.
IV. API Access to Published Provider Directory Data Provisions, and
Analysis of and Responses to Public Comments
A. Interoperability Background and Use Cases
In section III. of the CMS Interoperability and Patient Access
proposed rule (84 FR 7626 through 7639), we focused on patient access
to their own data through a standardized, transparent API--the Patient
Access API. As part of this proposal, we discussed and sought comment
on requiring payers at 42 CFR 422.119(b)(1)(iii) and (b)(2)(ii) for MA
organizations, 42 CFR 431.60(b)(3) for Medicaid FFS programs, 42 CFR
438.242(b)(6)(ii) for Medicaid managed care plans, 42 CFR 457.730(b)(3)
for CHIP FFS programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed
care entities to provide their provider directory information through
that same Patient Access API. In addition, the proposed rule sought
comment on making the provider directory information available through
a public-facing standards-based API. As we discussed in the CMS
Interoperability and Patient Access proposed rule (84 FR 7639), making
provider directory information available through a public-facing API
raised different issues than API access proposals related to patient
data. Based on our consideration of public comments summarized and
responded to below, and in an effort to avoid duplicative effort and
additional burden resulting from having the provider directory
information included in both the Patient Access API and the Provider
Directory API, we are finalizing the requirement for a public-facing
Provider Directory API at 42 CFR 422.120 for MA organizations, 42 CFR
431.70 for Medicaid FFS programs, 42 CFR 438.242(b)(6) for Medicaid
managed care plans, 42 CFR 457.760 for CHIP FFS programs, and 42 CFR
457.1233(d)(3) for CHIP managed care entities, but we will not finalize
our proposal to also provide access to this provider directory
information through the Patient Access API at 422.119, 42 CFR 431.60,
42 CFR 438.242(b)(6), 42 CFR 457.730, and 42 CFR 457.1233(d)(2),
respectively.
Provider directories make key information about health care
professionals and organizations available to help consumers identify a
provider when they enroll in an insurance plan or as new health needs
arise. For example, such information might include hours of operation,
languages spoken, specialty/services, and availability for new
patients. Provider directories also function as a resource used by the
provider community to discover contact information of other providers
to facilitate referrals, transitions of care, and care coordination for
enrollees.
As discussed in the CMS Interoperability and Patient Access
proposed rule, the current applicable regulations for MA plans (42 CFR
422.111) and Medicaid and CHIP managed care plans (42 CFR
438.10(e)(2)(vi) and (h) and 457.1207, respectively) already require
that provider directories be made available to enrollees and potential
enrollees in hard copy and on the plan's website. Section 1902(a)(83)
of the Act requires state Medicaid agencies to publish a directory of
certain physicians on the public website of the State agency. A
regulation for QHP issuers (45 CFR 156.230(b)) requires public access
to the QHP's provider directory in addition to distribution and access
for enrollees. In addition to mandating that this information be
accessible, the current regulations also address the content of such
directories and the format and manner in which MA plans, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs must make the information available.
Making this required provider directory information available to
enrollees and prospective enrollees through an API could support
development of third-party software applications, or apps, (whether
standalone or integrated with providers' EHR technology) that would
pull in current information about available providers to meet
enrollees' current needs. Broad availability of provider directory data
through interoperable API technology would also allow for innovation in
applications or other services that help enrollees and prospective
enrollees to more easily compare provider networks while they are
considering their options for changing health plans. Finally, we noted
in our proposal that a consistent, FHIR-based API-driven approach to
making provider directory data accessible could reduce provider burden
by enabling payers to more widely share basic information about the
providers in their networks, such as provider type, specialty, contact
information, and whether or not they are accepting new patients.
[[Page 25560]]
B. Broad API Access to Provider Directory Data
In sections III.C. and IV. of the CMS Interoperability and Patient
Access proposed rule (84 FR 7633, 7639 through 7642), we proposed to
require at 42 CFR 422.119(b)(1)(iii) for MA organizations, 42 CFR
431.60(b)(3) for Medicaid FFS programs, 42 CFR 438.242(b)(6)(ii) for
Medicaid managed care plans, 42 CFR 457.730(b)(3) for CHIP FFS
programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed care entities
that payers subject to the proposed rule make standardized information
about their provider networks available through API technology, so that
the public, including third-party app developers and patients, could
access and use that information, including republishing the information
or information derived from that information in a user-friendly way. As
discussed in the preamble of the CMS Interoperability and Patient
Access proposed rule, we sought comment on making provider directory
information more generally available (84 FR 7639 through 7642). We
discussed requiring that the API technology conform to the API
standards proposed by ONC for HHS adoption at 45 CFR 170.215 (84 FR
7589). Currently, because QHP issuers on the FFEs are already required
to make provider directory information available in a specified,
machine-readable format,\42\ we did not propose that QHP issuers would
have to make provider directory information available through an API.
However, we requested information regarding whether this same
requirement should apply to QHP issuers, or if such a requirement would
be overly burdensome for them. We thank commenters for their insights
on this request for information and are reviewing the comments received
for inclusion in potential future rulemaking.
---------------------------------------------------------------------------
\42\ Available at http://cmsgov.github.io/QHP-provider-formulary-APIs/developer/index.html.
---------------------------------------------------------------------------
We noted in the preamble of the proposed rule that, since this
provider directory information is already available and accessible to
enrollees without cost to them under existing law, this information
should be as accessible through the API as it is required to be when
posted on the organization's websites. Therefore, we proposed that the
technical standards proposed (now finalized) by HHS in the ONC 21st
Century Cures Act final rule (published elsewhere in this issue of the
Federal Register) at 45 CFR 170.215 (specifically at paragraphs (a)(3)
and (b)) that are specific to authenticating users and confirming
individuals' authorization or request to disclose their personal
information to a specific application through an API, namely the SMART
IG (using the OAuth 2.0 standard) and OpenID Connect Core 1.0, should
not apply to our proposed public access to provider directory
information through APIs (84 FR 7639). We noted that while we were
aware the organization will nevertheless need to take appropriate steps
to mitigate the potential security risks of allowing any application to
connect to the API through which it offers provider directory access,
we emphasized that these steps should be appropriate to the level of
risk associated with the specific use case of accessing otherwise
public information through API technology. We also noted that those
wishing to access these data should not be unduly burdened by security
protocols that are not necessary to provide the appropriate degree of
protection for the organization's systems and data.
As referenced in sections II. and III. of the CMS Interoperability
and Patient Access proposed rule (84 FR 7618 through 7639), we intended
to develop additional guidance, incorporating feedback from industry
that provides implementation best practices relevant to FHIR-conformant
standards-based APIs to help organizations subject to the requirements
proposed in this rulemaking. To that end, we solicited comment on what
specific resources would be most helpful to organizations implementing
APIs under requirements proposed in the proposed rule.
We summarize all public comments we received on making provider
directory information available through an API--in terms of requiring a
dedicated, publicly accessible Provider Directory API and more
generally sharing provider directory information via an API, including
as proposed under the Patient Access API discussed in section III. of
this final rule and provide our responses.
Comment: Many commenters supported a requirement for MA
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, and CHIP managed care entities to make standardized
information about their provider networks available through API
technology to current enrollees, prospective enrollees, and possibly
the general public. Commenters stated that they believe accurate
provider directory data will improve transparency and accessibility of
information regarding a provider's network status, which will help with
efforts to address surprise billing and other coverage issues related
to whether providers are in or out-of-network.
Response: We thank commenters for their support. Appreciating that
provider information is already publicly available, and unlike the
other information included in the Patient Access API discussed in
section III. of this final rule, is of a less sensitive nature, to
avoid potential confusion and reduce burden resulting from having the
provider directory information included in both the Patient Access API
and the Provider Directory API, we are only requiring that one API--the
Provider Directory API--provide access to provider directory
information. As a result, we are finalizing additional regulation text
to require the Provider Directory API at 42 CFR 422.120 for MA
organizations; at 42 CFR 431.70 for Medicaid state agencies; at 42 CFR
438.242(b)(6) for managed care plans; at 42 CFR 457.760 for CHIP state
agencies; and at 42 CFR 457.1233(d)(3) for CHIP managed care entities.
This Provider Directory API must include the same information about the
provider directory as originally proposed for the Patient Access API.
Specifically, the Provider Directory API must include provider
directory data on a payer's network of contracted providers, including
names, addresses, phone numbers, and specialties, updated no later than
30 calendar days after a payer receives provider directory information
or updates to provider directory information. We are finalizing the
applicable regulation text with the phrase ``complete and accurate'' to
emphasize our intent that the directory data meet this standard. For MA
organizations that offer MA-PD plans, the Provider Directory API must
also make available pharmacy directory data, we are specifying that the
plans must make available, at a minimum, pharmacy name, address, phone
number, number of pharmacies in the network, and mix (specifically the
type of pharmacy, such as ``retail pharmacy''). As with the provider
directory information, we are finalizing that pharmacy directory
information must be updated no later than 30 calendar days after the MA
organization that offers the MA-PD plan receives pharmacy directory
information or updates to pharmacy directory information.
Comment: Some commenters disagreed with the proposal. They stated
that payers are already required to make this information available and
this proposal could result in unnecessary duplication of effort and
additional costs. One commenter suggested CMS provide an exemption for
payers that are
[[Page 25561]]
already providing this information in a manner that aligns with the
requirements in the proposed rule.
Response: We appreciate the commenters' concern about potentially
duplicative effort. While we understand that different payers are
already required to make this information available in a machine
readable format or on a public website according to the different rules
associated with each program, we believe that making this information
available through a standardized API will bring additional benefits to
enrollees and prospective enrollees by making it easier for developers
to incorporate this information into consumer-facing applications. We
note that we did not propose to extend the requirement regarding
provider directory information to QHP issuers on the FFEs, as these
issuers are already required to make provider directory information
available according to a specific standard for the electronic transfer
of this information, as discussed in the CMS Interoperability and
Patient Access proposed rule (84 FR 7633).
Comment: Many commenters raised concerns about the accuracy of
provider directory information that would be available through the API,
and how these inaccuracies can have a negative impact on consumers. One
commenter stated that there is a high prevalence of inaccurate provider
directories issued by MA organizations, in particular, and for other
public and private payers, generally, and that this can bring into
question the adequacy and validity of a network. Another noted that
inaccurate provider directories have also resulted in patients
receiving surprise bills as a result of seeing an out-of-network
physician. Commenters expressed concern that making provider directory
information more accessible through an API could exacerbate the impact
of inaccuracies resulting in conflicting and confusing information for
consumers, for instance, where an enrollee participates in two plans
and receives different information about the same provider from each.
Commenters discussed a variety of steps that CMS should take in
concert with the proposal to ensure that provider directory information
made available through the API is tested to ensure it is current,
correct, and accurate. One commenter suggested CMS require payers to
provide API vendors with accurate provider directory information.
Response: We appreciate commenters' concerns and thank the
commenters for their suggestions. We have taken a number of steps to
improve the accuracy of provider directory information for plans
subject to direct regulation by CMS, such as implementing a process to
audit directory information with MA organizations to identify
deficiencies in an effort to increase data accuracy (for more
information see https://www.cms.gov/Medicare/Health-Plans/ManagedCareMarketing/Downloads/Provider_Directory_Review_Industry_Report_Round_3_11-28-2018.pdf). We
will take the suggestions provided into consideration as we continue
this effort. We encourage all enrollees to check with a new provider
about network participation to avoid surprises and continue to explore
ways to work with the payers that we directly regulate (like MA
organizations) to improve the accuracy of directories.
We are finalizing regulation text on the Provider Directory API at
42 CFR 422.120(b), 431.70(b), 438.242(b)(6), 457.760(b), and
457.1233(d)(3) to require that accurate and complete provider directory
information be made available through the API. We believe that this
language will clarify our expectation that payers take steps to ensure
provider directory information made available through the API
accurately reflects the current providers within the payer's network.
Commenter: Several commenters responded to our proposal that
impacted payers update provider directory information made available
through the API to current and prospective enrollees within 30 days of
receiving an update to their directory information. The commenters
suggested that CMS should decrease the amount of time allowed for
updates; for instance, one commenter suggested that CMS should require
that provider directory information is updated within 48 hours of a
change, while another recommended directory updates occur in real time,
or on a regular basis as frequently as possible.
Some commenters who supported the requirement that provider
directories be publicly available through API technology specifically
expressed concerns with how frequently directories must be updated in
the case of Medicaid and CHIP programs. One commenter recommended that
the clock for the 30-day requirement begins from the date the state
provides the information to the Medicaid or CHIP managed care plan.
Another commenter recommended that entities should be required to
update provider directories in real-time.
Response: We appreciate commenters' suggestions, and agree that
more frequent updates of the provider directory information made
available through the API could help to increase the accuracy of this
information. Our proposed 30-day time frame was not intended to
preclude payers from updating the information available via the API on
a shorter timeframe, or from making updates in real time. However, we
understand that payers may have different operational processes for
making updates to their provider directories and are seeking to set a
minimum floor for how frequently information available through the API
must be updated. This is consistent with timeframes for other updates
some of these payers are required to make. For instance, Medicaid
managed care plans must update paper provider directories monthly and
electronic provider directories no later than 30 days after the plan
receives the updated information under Sec. 438.10(h)(3).
The Provider Directory API regulations finalized here require that
state Medicaid and CHIP agencies, and managed care plans, make
available through the API provider directory information no later than
30 calendar days after the state or managed care plan receives the
provider directory information or updates to the provider directory
information. We confirm that the state or managed care plan must make
the provider directory information available through the API within 30
calendar days of receiving the information. This timeframe for managed
care plans is consistent with the requirement in Sec. 438.10(h)(3) for
Medicaid managed care plans, which applies to CHIP managed care
entities under Sec. 457.1207.
We decline to require updates to provider directories in real-time
as we do not believe that such a timeframe is operationally feasible
for MA organizations, states or Medicaid and CHIP managed care plans at
this time. We are finalizing our proposal that MA organizations, state
Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP
managed care entities update provider directory information made
available through this API within 30 days of receiving a change as
proposed.
Comment: Several commenters believe that, in order to increase the
accuracy of provider directory data, CMS should take steps to hold
providers responsible for the accuracy of their provider directory
information. One commenter suggested CMS require health care providers
to update their information with a centralized entity, for instance a
trusted health information exchange, rather than looking to impacted
payers to include these mandates in their contracts with
[[Page 25562]]
providers. Another suggested that CMS should require providers to
submit rosters to CMS each month indicating which health plans they
contract with, enabling CMS to validate information provided through
the proposed API. Another commenter suggested CMS ensure that CMS-
regulated payers are provided with updated provider information in a
timely manner by making such reporting requirements a condition of
participation in Medicare.
Response: We appreciate commenters' suggestions, and agree that
providers have an important role to play in ensuring that provider
directory information about them, provided to, and used by the payers
with which they contract or participate, is up-to-date. While we did
not include any proposals in this rulemaking specifically focused on
provider responsibility for updating the information to be made
available through the proposed API, we will continue to work with
federal and industry partners to identify opportunities to improve the
accuracy of provider directory information across the health care
system.
Comment: Several commenters noted that a centralized repository
that can serve as a ``source of truth'' for provider directory
information is needed to ensure accuracy, and urged CMS to support work
across stakeholders for such an approach. One commenter noted that
health information exchanges (HIEs) could help payers to update their
information through access to the directories that HIEs use for
clinical data exchange.
Response: We thank commenters for their input. Our policy is
focused around payers making provider directory information available
through APIs to provide greater access to specific information on the
providers in their networks. However, we believe entities focused on
aggregating provider directory information can serve an important role,
and we encourage payers to work with partners that maintain this
information to improve accuracy.
Comment: Several commenters suggested additional information for
inclusion as part of the provider directory information made available
through the API for current and prospective enrollees (in addition to
provider names, addresses, phone numbers, and specialties), such as
NPIs for individual and group providers, practice group name, health
system name, as well as the specific plan(s) and tiers a provider
participates in. One commenter also suggested including minimum
provider demographics to be included in the clinical and administrative
transactions to ensure accurate provider matching; whether the provider
is accepting new patients; information about which providers are in-
network for a plan by geography and/or specialty regardless of whether
the individual is a member of a particular plan or is researching plan
options; and which clinicians are in-network for care coordination and
plan switching purposes.
Response: We appreciate commenters' suggestions and agree that this
additional information may be helpful to consumers. However, at this
time we are seeking to minimize the burden for the regulated payers
that must comply with this proposal, and have sought to identify a
minimum set of provider directory information that aligns with existing
requirements applicable to MA organizations (including MA organizations
that offer MA-PD plans), state Medicaid and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed care entities regarding such
directories. We do encourage payers to explore how they can make
additional provider directory data available through the API to most
benefit current and prospective enrollees. Also, we note that the
requirements in this final rule set out the minimum requirements;
payers are strongly encouraged to go beyond that minimum, if and as
possible, to make useful information available for their enrollees and
beneficiaries.
Comment: One commenter who supported our proposal also urged CMS to
take additional steps to make provider directories more accessible to
enrollees, for instance by integrating a provider directory in future
iterations of Plan Finder for MA plans, and ensuring the directory data
is accurate and up to date.
Response: We thank the commenter for the suggestions. We will take
these suggestions into consideration.
Comment: Several commenters addressed issues with technical
standards for provider directory information, with several stating that
appropriate standards for making this information available through an
API are still emerging. For instance, one commenter noted that current
provider directory standards were written for FHIR Release 3 and that
the standard has not been adopted by the field. The commenter stated
that before CMS requires payers to make provider directory information
available via a standards-based API, more work is needed to build the
provider directory specification in FHIR Release 4.
Several commenters suggested that CMS should delay implementing
this proposal, proposed to be applicable starting January 1, 2020,
until stakeholders have been able to establish consensus-based
standards for the creation and display of directory information. One
commenter encouraged CMS to develop a voluntary, multi-stakeholder
partnership to establish data content FHIR-based standards related to
provider directories and then wait to establish the timeframe for
provider directory data updates until the development of these FHIR-
based standards are completed.
Response: We appreciate commenters' concerns, and agree that
updated FHIR-based provider directory implementation guidance is
important for implementation of this policy. We confirm here that HL7
FHIR Release 4.0.1--the API standard adopted at 45 CFR 170.215 and
which must be used under our Provider Directory API requirement--
provides a base standard for moving information through an API. The
basic information (name, phone number, address, and specialty) required
for this Provider Directory API can all be represented through FHIR
Release 4.0.1. Additional implementation guidance will provide
additional information for how to use the FHIR Release 4.0.1 base
standard to make provider directory information available and ensure
greater uniformity in implementation and reduce implementation burden
for payers. As noted in section III. of this final rule, we have been
working with HL7 and partners to ensure the necessary consensus-based
standards and associated guidance are available so that impacted payers
can consistently implement all of the requirements included in this
final rule. We are providing a link to a specific FHIR Release 4.0.1
implementation guide and reference implementation for all interested
payers for the Provider Directory API that provide valuable guidance to
further support sharing the needed data using the required standards:
https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Though not mandatory, using this guidance will lower payer
burden and support consistent implementation of the FHIR Release 4.0.1
APIs.
Appreciating the time needed for payers to build, implement, and
test these APIs, we are providing additional time for implementation,
and are finalizing January 1, 2021 as the implementation date for the
Provider Directory API for all payers subject to this requirement.
Appreciating the value of making this information publicly accessible,
we do encourage payers to
[[Page 25563]]
implement this Provider Directory API as soon as they are able. We are
requiring at 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for
Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed
care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR
457.1233(d)(3) for CHIP managed care entities that these payers make
the Provider Directory API accessible via a public-facing digital
endpoint on their website. We will check a random sample of payer
websites for links to these publicly accessible APIs, starting in
January 2021 to evaluate compliance.
Comment: One commenter suggested that, as CMS already requires
provider directory information to be made available online by payers
subject to this rule, for interoperability transactions CMS should
require use of a standard described as ``the HIPAA 274 transaction.''
The commenter stated that the metadata defined within this transaction
can drive a consistent payload for an API to support provider directory
information sharing.
Response: We appreciate the commenter's suggestion, but at this
time we are finalizing requirements for provider directory information
to be available through an API using the standards at 45 CFR 170.215,
including, FHIR Release 4.0.1 standards finalized by HHS in the ONC
21st Century Cures Act final rule (published elsewhere in this issue of
the Federal Register) to consistently align all various API formats
throughout the rule with a single modern standard capable of meeting
all requirements. CMS understands that some information within the X12
274 Transaction (Healthcare Provider Information Transaction Set for
use within the context of an Electronic Data Interchange (EDI)
environment) may provide the basic provider information to support an
API. HHS, however, has not adopted the X12 274 transaction standard
under HIPAA or for any other use. Moreover, the required availability
of a plan's entire provider directory via an API is not a HIPAA
transaction that has been defined or associated with a specific
transaction under HIPAA. We believe that using FHIR Release 4.0.1 for
the purpose of this Provider Directory API will provide greater long
term flexibility for payers subject to this rule, allowing them the
ability to meet minimum requirements, and extend beyond these
requirements based on the industry's diverse and evolving needs
surrounding provider directories, while reducing impact on those who
may not be ready to receive additional information beyond the minimum
set of data required by this final rule.
Comment: One commenter requested that CMS ensure public health
agencies are also able to access provider directory information made
available through the API, while another commenter requested that
approved agents and brokers be granted access to this information.
Response: Under this final rule, the Provider Directory API must be
publicly accessible, so that any third party can access an impacted
payer's provider directory information. Our regulation text reflects
this by requiring that the Provider Directory API be accessible via a
public-facing digital endpoint on the applicable payer's website. The
value of making this information available via an API is that third-
party developers will be able to access it to make it available in
valuable and useful ways for all interested stakeholders. We therefore
anticipate that public health agencies, agents, and brokers, and any
other member of the public would be able to access these data via
third-party apps.
Comment: Several commenters suggested CMS require payers to include
other types of non-physician professionals within their provider
directories, such as nurse practitioners, certified registered nurse
anesthetists, physical therapists, and post-acute care providers.
Commenters stated that including additional qualified licensed non-
physician providers could help increase patient access to care.
Response: We appreciate commenters' suggestions. We did not propose
to change the parameters of the information required to be included in
provider directories for the payers subject to the Provider Directory
API requirement here. Existing requirements for paper and on-line
provider directories, such as those in 42 CFR 422.111 and 438.10(h),
are not changed or limited by this final rule. Instead, our API
proposals and this final rule focus on making certain payers (that is,
MA organizations, state Medicaid and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed care entities) share provider
directory information through an API. How ``provider'' is defined in
this context is outside the scope of this regulation.
Comment: One commenter recommended that CMS amend the API
requirement to also include FHIR endpoint information for providers as
part of provider directory information, to ensure access to regional/
national directories in addition to the current partial ones.
Response: We agree with commenters that FHIR endpoint information
is important to improve interoperability across providers. We discuss
FHIR endpoints in section IX. of this final rule. For this Provider
Directory API, we have focused on a minimum set of information of
primary interest to patients and typically found in provider
directories. However, we encourage payers to consider including other
data elements that may add value to the Provider Directory API. We may
consider expanding this minimum set of information in potential future
rulemaking.
Comment: One commenter suggested that CMS impose penalties on plans
that do not comply with the provider directory requirement.
Response: We thank the commenter for this suggestion. We did not
propose to establish additional penalties for noncompliance with the
requirement to make provider directory information available through an
API; however, we note that the requirement to make provider directory
information available through an API will be a requirement for MA
organizations, Medicaid managed care plans and CHIP managed care
entities to fulfill under their contracts in their respective programs.
Therefore, existing enforcement authority for ensuring compliance with
those contracts will apply. Further, the API requirements, including
the provider directory components of the required API(s) will be
required for state Medicaid and CHIP agencies operating FFS Medicaid
programs and CHIPs.
Final Action: After consideration of the comments received, and for
the reasons outlined in our response to these comments and in the CMS
Interoperability and Patient Access proposed rule, we are finalizing
regulations to require that MA organizations, Medicaid and CHIP FFS
programs, Medicaid managed care plans, and CHIP managed care entities
make standardized information about their provider networks available
via a FHIR-based API conformant with the standards finalized by HHS in
the ONC 21st Century Cures Act final rule (published elsewhere in this
issue of the Federal Register) at 45 CFR 170.215 (including FHIR
Release 4.0.1), excluding the security protocols related to user
authentication and authorization and any other protocols that restrict
the availability of this information to anyone wishing to access it. At
a minimum, these payers must make available via the Provider Directory
API provider names, addresses, phone numbers, and specialties. For MA
organizations that offer MA-PD plans, we are specifying that they must
make available, at a minimum, pharmacy
[[Page 25564]]
directory data, including the pharmacy name, address, phone number,
number of pharmacies in the network, and mix (specifically the type of
pharmacy, such as ``retail pharmacy''), updating the regulation text
from the proposed rule, which simply stated ``number, mix, and
addresses of network pharmacies''. All directory information must be
available through the API within 30 calendar days of a payer receiving
the directory information or an update to the directory information. We
note we have also revised the proposed regulation text for making
directory information available through an API to specify consistently
that the directory information must be complete and accurate and that
updates must be made in ``calendar'' days.
The Provider Directory API is being finalized at 42 CFR 422.120 for
MA organizations, at 42 CFR 431.70 for Medicaid state agencies, at 42
CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760
for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed
care entities. We are finalizing that access to the published Provider
Directory API must be fully implemented by January 1, 2021 for all
payers subject to this new requirement. We encourage payers to
implement this Provider Directory API as soon as they are able to make
and show progress toward the API requirements in this final rule and to
signal their commitment to making the information that will empower
their patients easily accessible and usable. Under this final rule, MA
organizations, Medicaid and CHIP FFS programs, Medicaid managed care
plans, and CHIP managed care entities must make the Provider Directory
API accessible via a public-facing digital endpoint on their website to
ensure public discovery and access.
V. The Health Information Exchange and Care Coordination Across Payers:
Establishing a Coordination of Care Transaction To Communicate Between
Plans Provisions, and Analysis of and Responses To Public Comments
We proposed a new requirement for MA organizations, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs to require these payers to maintain a process to coordinate care
between payers by exchanging, at a minimum, the USCDI at the enrollee's
request as specified in the proposed regulation text. Instead of
specifically proposing use of the USCDI, we proposed use of a content
standard adopted by ONC at 45 CFR 170.213, which was proposed in a
companion proposed rule, the ONC 21st Century Cures Act proposed rule
as the USCDI (version 1) (84 FR 7441 through 7444). Understanding that
enrollees' information is already exchanged between plans for use in
carrying out various plan functions,\43\ payers have experience
exchanging, receiving, and incorporating data from other plans into an
enrollee's record. We proposed requiring the USCDI data set be
exchanged at the enrollee's direction, and when received by a payer,
incorporated into the recipient payer's data system. As proposed, upon
request from an enrollee, the USCDI data set would have to be sent to
another payer that covers the enrollee or a payer identified by the
enrollee at any time during coverage or up to 5 years after coverage
ends, and the payer would have to receive the USCDI data set from any
payer that covered the enrollee within the preceding 5 years. These
proposals were intended to support patient directed coordination of
care; that is, each of the payers subject to the requirement would be
required to, upon an enrollee's request: (1) Receive the data set from
another payer that had covered the enrollee within the previous 5
years; (2) send the data set at any time during an enrollee's
enrollment and up to 5 years later, to another payer that currently
covers the enrollee; and (3) send the data set at any time during
enrollment or up to 5 years after enrollment has ended to a recipient
identified by the enrollee.
---------------------------------------------------------------------------
\43\ See Office for Civil Rights. (2016, August 16). 3014-HIPAA
and Health Plans--Uses and Disclosures for Care Coordination and
Continuity of Care. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/3014/uses-and-disclosures-for-care-coordination-and-continuity-of-care/index.html.
---------------------------------------------------------------------------
We identified in the proposed rule that this proposal is based on
our authority under sections 1856(b) and 1857(e) of the Act to adopt
standards and contract terms for MA plans; section 1902(a)(4) of the
Act to adopt methods of administration for state Medicaid plans,
including requirements for Medicaid managed care plans (MCOs, PIHPs,
and PAHPs); section 2101(a) of the Act for CHIP managed care entities
(MCOs, PIHPs, and PAHPs); and section 1311(e)(1)(B) of the Affordable
Care Act for QHP issuers on the FFEs. We explained in the CMS
Interoperability and Patient Access proposed rule our belief that the
proposal will help to reduce provider burden and improve patient access
to their health information through coordination of care between payers
(84 FR 7640 through 7642). We also noted that the CHIP regulations
incorporate and apply, through an existing cross-reference at 42 CFR
457.1216, the Medicaid managed care plan requirements codified at 42
CFR 438.62(b)(1)(vi). Therefore, the proposal for Medicaid managed care
plans described also applied to CHIP managed care entities even though
we did not propose new regulation text in part 457. We proposed that
this new requirement would be applicable starting January 1, 2020 for
MA organizations, Medicaid managed care plans, CHIP managed care
entities, and beginning with plan years beginning on or after January
1, 2020 for QHP issuers on the FFEs. Among other topics related to the
proposal, we solicited comments on the proposed date these policies
would be applicable.
We proposed to codify this new requirement at 42 CFR 422.119(f) for
MA organizations; at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care
plans (and by extension under existing rules at 42 CFR 457.1216, to
CHIP managed care entities); and at 45 CFR 156.221(f) for QHP issuers
on the FFEs. The proposed new requirement was virtually identical for
MA organizations, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs, with modifications in the
proposal necessary for specific payer types to account for the program
needs of each. The proposed regulation text references the content
standard adopted at 45 CFR 170.213, which ONC proposed as the USCDI
(version 1) data set (84 FR 7441 through 7444). We noted we believed
that exchanging this data set would help both enrollees and health care
providers coordinate care and reduce administrative burden to ensure
that payers provide coordinated high-quality care in an efficient and
cost-effective way that protects program integrity. For a full
discussion of the benefits we anticipate from this data exchange
requirement, see the discussion in the CMS Interoperability and Patient
Access proposed rule (84 FR 7640).
In addition to the benefits for care coordination at the payer
level and reduced provider burden, we noted that once the requested
information, as specified by the USCDI standard, was made available to
the patient's current plan, the enrollee would have access to multiple
years of their health information through the proposed Patient Access
API, discussed in section III.C. of the CMS Interoperability and
Patient Access proposed rule and in this final rule. This is the case
because the proposal required the receiving payer to incorporate the
received data into its records about the patient, therefore making
these data the payer maintains, and data available to share with the
[[Page 25565]]
patient via the Patient Access API. The USCDI data set includes
clinical data points essential for care coordination. Access to these
data would provide the patient with a more comprehensive history of
their medical care, helping them to make better informed health care
decisions. We sought comment on how plans might combine records and
address error reconciliation or other factors in establishing a more
longitudinal record for each patient.
We proposed to allow multiple methods for electronic exchange of
the information, including use of the APIs proposed in section III. of
the CMS Interoperability and Patient Access proposed rule (84 FR 7627
through 7639), to allow for patient-mediated exchange of payer
information or direct payer-to-payer communication, subject to HIPAA
requirements, 42 CFR part 2, and other applicable federal and state
laws. We noted that we considered requiring the use of the FHIR-based
API discussed in section III. of the proposed rule for this information
exchange; however, we understood that some geographic areas might have
a regional health information exchange (HIE) that could coordinate such
data transfers for any HIE-participating MA plans, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs
that are subject to the proposal. We sought comment on whether it would
be beneficial to interoperability and patient care coordination for us
to require the use of the FHIR-based API otherwise proposed, and
whether this should be the only mechanism allowed for this exchange, or
whether multiple methods for electronic exchange of the information
should be allowed under the proposed policy and whether CMS might be
able to leverage its program authority to facilitate the data exchanges
contemplated by the proposal. We expected enrollees to have constant
access to requesting an exchange of data as the proposal would require
exchange of the USCDI data set whenever an enrollee makes such a
request, which may occur at times other than enrollment or
disenrollment. We acknowledged that in some cases payers subject to the
proposed requirement may be exchanging patient health information with
other payers that are not similarly required to exchange USCDI data
sets for enrollees, for example, if a consumer changes their health
coverage from a QHP on an FFE to employer-sponsored coverage, and we
requested comment on how to support patients and providers in those
situations.
We also proposed that a patient should be able to request his or
her information from their prior payer up to 5 years after dis-
enrollment, which is considerably less than existing data retention
policies for some of the payers.\44\ Further, we proposed that the
health information received as part of the USCDI (version 1) data set
under our proposal would have to be incorporated into the IT and data
systems of each payer that receives the USCDI data set under the
proposed requirement, such that the enrollee's data would be cumulative
and move with the enrollee as he or she changes enrollment. For
example, if a patient is enrolled in Plan 1 in 2020 and Plan 2 in 2021,
then requests the data from Plan 1 to be sent to Plan 2, Plan 2 would
have at least 2 years (2020 and 2021) of health information for that
patient. If the patient moves to Plan 3 in 2022, Plan 3 should receive
both 2020 and 2021 data from Plan 2 at the patient's request. While the
proposal would require compliance (and thus exchange of these data
sets) only by MA plans, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs, we noted that we hoped that
compliance by these payers could be the first step toward adoption and
implementation of these standards on a voluntary basis by other payers
throughout the health care system.
---------------------------------------------------------------------------
\44\ Under 42 CFR 422.504(d) and 438.3(u), MA organizations and
Medicaid managed care plans, and CHIP plans must retain records for
at least 10 years. Under 45 CFR 156.705; 45 CFR 155.1210(b)(2), (3)
and (5), QHP issuers on the FFEs must also retain records for 10
years.
---------------------------------------------------------------------------
Research indicates that the completeness of a patient record and
the availability of up-to-date and relevant health information at the
point of care can have a significant impact on patient outcomes.\45\ We
noted that we believe the proposal for MA organizations, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs to exchange the USCDI data set in particular scenarios would
support improvement in care coordination by allowing for sharing of key
patient health information when an enrollee requests it.
---------------------------------------------------------------------------
\45\ Office of the National Coordinator. (2019, June 4).
Improved Diagnostics & Patient Outcomes. Retrieved from https://www.healthit.gov/topic/health-it-and-health-information-exchange-basics/improved-diagnostics-patient-outcomes.
---------------------------------------------------------------------------
We proposed that the payers subject to this new requirement would
be required to exchange, at a minimum, the data classes and elements
included in the content standard proposed to be adopted at 45 CFR
170.213 in the ONC 21st Century Cures Act proposed rule, specifically,
the USCDI (version 1) data set. On behalf of HHS, ONC proposed to adopt
the USCDI as a standard (84 FR 7441 through 7444), to be codified at 45
CFR 170.213, and the proposed regulation text cross-references this
regulation. These data exchanges would provide the enrollee's new payer
with a core set of data that could be used to support better care
coordination and improved outcomes for the enrollee. We considered
requiring plans to exchange all the data that we proposed be available
through an API (see section III. of the CMS Interoperability and
Patient Access proposed rule (84 FR 7627 through 7639)) but we
understood that ingesting data and reconciling errors has challenges
and proposed this more limited data set to address those concerns. We
sought comment on whether the USCDI data set would be comprehensive
enough to facilitate the type of care coordination and patient access
described in the proposal, or whether additional data fields and data
elements that would be available under the API proposal in section III.
of the CMS Interoperability and Patient Access proposed rule (84 FR
7627 through 7639) should also be required. For a full discussion of
the benefits of the USCDI for this data exchange, see the CMS
Interoperability and Patient Access proposed rule (84 FR 7641).
We stated that we believed that the proposed requirement would also
support dually eligible individuals who are concurrently enrolled in MA
plans and Medicaid managed care plans. Under the proposal, both of the
dually eligible individual's payers would be subject to the requirement
to exchange that individual's data in the form of the USCDI, which
should improve the ability of both payers to coordinate care based on
that data, as discussed in the CMS Interoperability and Patient Access
proposed rule (84 FR 7642). We sought comment on how payers should
coordinate care and exchange information for dually eligible
individuals. We also sought comment on the associated burden on plans
to exchange the USCDI data set under the proposal. In addition, we
noted that we were interested in comments about potential legal
barriers to exchanging the USCDI data set as would be required under
the proposal; for example, whether there were federal, state, local,
and tribal laws governing privacy for specific use cases (such as in
the care of minors or for certain behavioral health treatments) that
would raise additional considerations that we should address in this
regulation or in guidance.
We stated that activities related to the proposed requirement could
qualify as a quality improvement activity (QIA)
[[Page 25566]]
meeting the criteria described in section 2718(a)(2) of the PHSA for
purposes of the Medical Loss Ratio (MLR) requirements for QHP issuers
on an FFE,\46\ and similar standards for treatment of QIA standards
applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs)
under 42 CFR 438.8, CHIP managed care entities under 42 CFR
457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490. An
entity's MLR is generally calculated as the proportion of revenue spent
on clinical services and QIA. There are several specific criteria an
expense must meet, such as being designed to improve health quality and
health outcomes through activities such as care coordination, in order
to qualify as QIA.\47\ We requested comments related to this assumption
and its implications.
---------------------------------------------------------------------------
\46\ While this rulemaking is specific to QHP issuers
participating on the FFEs, we note that to the extent other
commercial market issuers incur similar costs for coverage sold in
the individual or group markets, those expenses may similarly
qualify as QIA.
\47\ See, for example, 45 CFR 158.150 and 45 CFR 158.151.
---------------------------------------------------------------------------
We summarize the public comments we received on the payer-to-payer
data exchange, as well as on whether these new activities may qualify
as QIA for MLR purposes, and provide our responses.
Comment: Many commenters were very supportive of this proposal and
indicated their belief that these new data exchange requirements could
improve care coordination by reducing burden on both beneficiaries and
providers by limiting the need for duplicative letters of medical
necessity, preventing inappropriate step therapy, and reducing
unnecessary utilization reviews and prior authorizations.
Response: We appreciate the commenters' support for this payer-to-
payer data exchange proposal. We are finalizing this proposal with some
modifications as detailed below. Under this final rule, payers subject
to this requirement must maintain a process for the electronic exchange
of, at a minimum, the data classes and elements included in the content
standard finalized by HHS in the ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register) at 45 CFR
170.213, which is currently version 1 of the USCDI. We are also
finalizing that payers must use this process to exchange the USCDI-
defined data set with the approval and at the direction of a current or
former enrollee, or the enrollee's personal representative, to align
with the language used for the API requirements. Furthermore, we are
finalizing the proposal that upon receipt, the receiving payer must
incorporate the data set into the payer's own records about the
enrollee with a clarification that this obligation applies to records
about current enrollees. We clarify here that incorporating the data
into the payer's records under this specific regulation would not
require that the payer treat or rely on these data as its own, but that
the payer must include these data in the record it maintains for each
enrollee. While the obligation to incorporate data received from other
payers into the receiving payer's records applies only for data about
current enrollees, once incorporated, these data must be maintained
even after a current enrollee leaves the payer's coverage. We do not
want to be overly prescriptive about how these data are used by each
payer at this time. Initially, we are only requiring that these data
are incorporated into the existing record to facilitate the creation
and maintenance of a patient's cumulative health record with their
current payer. In subsequent rulemaking, however, we may be more
specific, depending on proposed use cases, and propose more
prescriptive use of specific data.
Comment: Some commenters expressed concern about each payer's
increased access to clinical information impacting coverage decision-
making. Commenters noted that while historically physicians have
controlled the patient's clinical data in determining what to submit to
obtain reimbursement for care provided, payers would now have access to
information outside of the scope of the specific service being billed
by a provider. Commenters noted that a payer may access the exchanged
health data from a prior payer and determine that a patient has already
received treatment for a condition and deny, delay, and/or require
prior authorization for allegedly duplicative treatment. Additionally,
a few commenters expressed concern that payers may use prior
information to restrict coverage for medically necessary care that a
patient may have received previously. A few commenters recommended that
CMS require that payers must attest that the exchanged data cannot be
used to deny or delay treatment, increase rates, or implement step
therapy.
Response: We appreciate the commenters' concerns. We note that this
regulation does not make any changes to when payers can deny coverage.
The data received via this data exchange must be used per all
applicable law, regulation, and in accordance with payer contracts as
it relates to coverage decisions and, specifically, coverage denial.
Nothing in this regulation changes any existing obligations or policies
related to coverage or services. Further, as proposed and finalized,
the regulations regarding the exchange of data among payers is
triggered by an enrollee's request that the information be sent or
received and incorporated. The individual enrollee retains control in
this situation and can refrain from requesting information be sent to a
new or current payer. We do note, however, that there are currently
scenarios where payers can exchange data without an enrollee's request,
such as for payment and health care operations.
Comment: Several commenters were concerned about the responsibility
of MA plans, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs to forward information from other payers or
information from outside their organization where they did not control
data integrity. Also, commenters were concerned there might be
information that is contradictory and were unsure of each payer's
responsibilities in that case.
Response: We appreciate the commenters' concerns. We do believe
that patients have a right to their data. In addition, they have a
right to request that their health data follow them throughout their
health care journey. It is only when patients are able to facilitate
the sharing of their data, and even see it themselves, such as via the
Patient Access API, that they will be able to understand where there
may be opportunities to work with their previous and current providers
and payers to ensure they have an accurate health record. Today, to the
extent permitted by law, payers may exchange patient data without the
patient's consent for various purposes including payment and health
care operations. The policy we are finalizing here will allow the
patient to facilitate that exchange of their health information. In
using this process, patients can ensure their payers and providers have
the most accurate and up-to-date information about them.
Payers can choose to indicate which data being exchanged were
received from a previous payer so the receiving payer, or even a
patient, understands where to direct questions and is aware of the
scope of control over data integrity. This will also help receiving
payers and patients understand how to reconcile contradictory
information as it can be made clear where questions should be directed.
Payers are under no obligation under this regulation to update,
validate, or correct data received from another payer.
[[Page 25567]]
Comment: Several commenters agreed with the proposed suggestion
that activities related to this proposal may qualify as QIA meeting the
criteria described in section 2718(a)(2) of the PHSA for purposes of
the MLR requirements for QHP issuers on the FFEs, and similar standards
for treatment of quality improvement standards applicable to Medicaid
managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP
managed care entities under 42 CFR 457.1203(f), and MA plans under 42
CFR 422.2400 through 422.2490.
Response: We confirm that we continue to believe that expenses for
the care coordination data exchanges required by this final rule may
qualify as QIA for purposes of calculating the MLR for payers that
engage in such exchanges. As noted above, while this rulemaking is
specific to QHP issuers participating on the FFEs, to the extent other
commercial market issuers incur similar costs for coverage sold in the
individual or group markets, those expenses may similarly qualify as
QIA. We appreciate the commenters' support and will consider
recognizing the expenses related to this data exchange as QIA in future
rulemaking or guidance, as may be necessary.
Comment: Many commenters were concerned about the time frame to
implement this provision and were concerned making this policy
applicable in 2020 would not provide enough time to operationalize this
policy.
Response: We appreciate the commenters' concerns and understand
that it will take time to fully and properly implement this policy. We
are finalizing this payer-to-payer data exchange requirement with an
applicability date of January 1, 2022 with respect to the exchange of
the USCDI data set.
Although we did not propose to require payers to use an API to
exchange the USCDI under this payer-to-payer data exchange proposal, we
appreciate and support that some payers would like to leverage the
Patient Access API (discussed in section III. of this final rule) to
meet the requirements of this payer-to-payer data exchange. The Patient
Access API requirement makes USCDI data available to the patient or a
third party at the patient's direction. Because the Patient Access API
is facilitating the exchange of the USCDI, some of the work to develop
an API to exchange these data and the work to map the relevant USCDI
data will be completed by January 1, 2021, when the Patient Access API
must be made available as finalized in section III. of this rule. In
addition, if a payer receives data via an API, the payer could then
incorporate it into a patient's record and in turn share it with the
patient via the Patient Access API with little additional work needed.
We appreciate the value of using an API for this data exchange, and
we understand the efficiencies that it can add to both this payer-to-
payer data exchange as well as the Patient Access API policy. We also
appreciate that incorporating data from other payers received via an
API will be a new experience for payers, however. For instance, payers
will need to develop a process to incorporate data from other payers
into their systems, including potentially processes for tagging these
data as originating with another payer so they can efficiently share
that information with patients and future payers. These are additional
processing steps that take time to implement.
In evaluating the comments on the proposals in this rule, and
appreciating the value of sharing and exchanging data via APIs, we see
the benefit of having all data exchanged via APIs. Therefore, we may
consider for future rulemaking an API-based payer-to-payer data
exchange. At this time, we believe that an applicability date of
January 1, 2022 for compliance with this requirement is appropriate.
This provides time for payers to get experience with the Patient Access
API, and provides payers with additional time to fully and successfully
implement this payer-to-payer data exchange requirement.
To support a more seamless data exchange and to further clarify
this payer-to-payer data exchange requirement, we are finalizing some
modifications of the proposed regulation text at 42 CFR
422.119(f)(1)(ii) and (iii) for MA organizations; at 42 CFR
438.62(b)(1)(vi)(B) and (C) for Medicaid managed care plans (and by
cross-reference from 42 CFR 457.1216, to CHIP managed care entities);
and at 45 CFR 156.221(f)(1)(ii) and (iii) for QHP issuers on the FFEs
to clearly indicate payers are obligated under this proposal to, with
the approval and at the direction of a current or former enrollee,
exchange data with any other payer identified by the enrollee. The
proposed regulation text used both the term ``recipient'' and ``any
other health care plan'' to identify where these data would be sent at
an enrollee's request; the term ``recipient'' could have been
interpreted more broadly than we intended. In the final regulation
text, we are using ``payer'' instead and consolidating the proposed
provisions that would require the payer that is subject to these rules
to send data at the enrollee's request at any time during enrollment or
up to 5 years after enrollment ends. As discussed in section III. of
this final rule, we are also specifying in the final regulations that a
payer is only required to send data received under this payer-to-payer
data exchange requirement in the electronic form and format it was
received. In this way, a payer would not be asked to receive paper
records from another payer under this policy and then in turn share
those paper records with another payer in the future at the patient's
direction. If the payer received a patient's information via an API,
the payer must share it via an API if the payer they are sending to has
the capacity to receive it. If a patient requests that a former payer
send their information to their new payer and then requests that their
new payer make their data accessible via that new payer's Patient
Access API, the new payer would only be required to include the
information received from the former payer at the patient's direction
if this newly acquired information was received via a FHIR-based API.
Otherwise, the new payer is only required to share data via the Patient
Access API that the payer already maintains and has prepared to be
shared via a FHIR-based API.
We are also finalizing new regulation text, at 42 CFR 422.119(h)
for MA organizations; at 42 CFR 438.62(b)(1)(vii) for Medicaid managed
care plans (and by cross-reference from 42 CFR 457.1216, to CHIP
managed care entities); and at 45 CFR 156.221(i) for QHP issuers on the
FFEs, that these regulated payers will need to comply with the payer-
to-payer data exchange requirements beginning January 1, 2022 (or
beginning with plan years beginning on or after January 1, 2022 for QHP
issuers on the FFEs). In addition, this requirement, as finalized,
provides that payers are required to exchange data they maintain with a
date of service on or after January 1, 2016. In this way, payers only
have to prepare a defined initial historical set of data for sharing
via this payer-to-payer data exchange policy, as also required under
the Patient Access API policy discussed in section III. of this final
rule. We believe that delaying implementation to January 1, 2022 and
specifying that only data with a date of service on or after January 1,
2016 must be exchanged under the new requirement addresses concerns
about the timing and level of burden involved in meeting this
requirement. This also clarifies that if certain information is not
maintained by the
[[Page 25568]]
payer, the payer is not obligated to seek out and obtain the data.
We also sought comment on how this policy might impact dually
eligible individuals. We summarize the public comments we received on
this payer-to-payer data exchange specifically regarding our request
for comment for how this policy might impact dually eligible
individuals who are concurrently enrolled in MA plans and Medicaid
managed care plans and provide our responses.
Comment: A few commenters supported the proposal because it could
improve care coordination for dually eligible beneficiaries. One
commenter noted that because of this proposal, MA plans and Medicaid
MCO plans would have the same data and health history for an
individual. One commenter believed that this could help states that do
not have an easily accessible source of data for knowing when their
Medicaid beneficiaries are enrolled for Medicare. This commenter
recommended including enrollment source and enrollment and
disenrollment dates in the data exchanged between payers.
Response: We appreciate the commenters' support and the suggestion
noted. We will further evaluate this suggestion for future
consideration.
Comment: One commenter requested additional information regarding
how plans should account for gaps in plan coverage over the course of 5
years. The commenter believed this will be particularly important for
dual eligible and Medicaid beneficiaries who may move in and out of a
health plan program as their status may change due to changing
circumstances.
Response: We appreciate the commenter's request for information. We
note that one payer would only be obligated to send another payer
information that the payer maintains (which could include data received
from other payers under this final rule that must be incorporated into
the current payer's records). If in the 5 years prior to January 1,
2022, a patient was in a Medicaid managed care plan for 1 year in 2019
and then there was a break in service with the patient returning for 1
year in 2021, this Medicaid managed care plan would be required to
share data from 2019 and 2021 if requested by the patient. It would not
be the managed care plan's responsibility to address the gaps in the
data that the plan maintains. Assuming that the patient was enrolled in
an MA plan or another Medicaid managed care plan in 2020, the patient
could request that the plan they had in 2020 independently send their
data to the payer they have indicated. In this way, the indicated payer
is now the holder of the comprehensive information, as under this
requirement a payer must incorporate the data received from other
payers under this policy into their data system. If the patient leaves
to go to a new payer in 2023, the one payer that now maintains their
data from 2019 to 2022 would be the one payer that could forward the
data to the new payer, in the electronic form and format it was
received. We acknowledge that this may be complex for dually eligible
beneficiaries.
Comment: A few commenters noted advantages, burdens, and
complexities associated with plans serving dually eligible
beneficiaries continuously aggregating real-time member data from
multiple plans. One commenter noted that each payer should only be
responsible for their own data set and the coordination of data across
multiple plans and providers would be more ideally done through a
Trusted Exchange Framework and Common Agreement (TEFCA). This commenter
noted that additional technical capabilities will be required due to
the possibility of overlapping coverage when combining and
incorporating records.
Response: We appreciate these thoughtful comments. We note that
this payer-to-payer data exchange is only required when initiated by an
enrollee's request, and only applies to the payers who are subject to
our final regulations at 42 CFR 422.119(f)(1) and (h) for MA
organizations; 42 CFR 438.62(b)(1)(vi) and (vii) for Medicaid managed
care plans (and by cross-reference from 42 CFR 457.1216, to CHIP
managed care entities); and at 45 CFR 156.221(f) and (i) for QHP
issuers on the FFEs. The enrollee may request this payer-to-payer
exchange just once, or more frequently. We did not propose, and are not
finalizing, any requirement for continuous data exchange, however.
Final Action: After consideration of the comments received, and for
the reasons outlined in our response to these comments and in the CMS
Interoperability and Patient Access proposed rule, we are finalizing
with modifications our proposal at 42 CFR 422.119(f)(1) and
438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to require MA
organizations, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs to maintain a process for the electronic
exchange of, at a minimum, the data classes and elements included in
the content standard adopted at 45 CFR 170.213 (currently version 1 of
the USCDI), as outlined in section III. of this final rule.
Specifically, we are finalizing as proposed that the payers subject to
these regulations incorporate the data they receive into the enrollee's
record. In the final regulation text, we are using the language ``with
the approval and at the direction'' of the enrollee versus ``at the
request'' of the enrollee to align with the language used for the API
requirements.
We are finalizing modifications to the proposed regulation text to
streamline the text and best specify the scope of the policy as
intended, as well as to align the text for all payer types as
appropriate. Specifically, at 42 CFR 422.119(f)(1)(i),
438.62(b)(1)(vi)(A) (and by cross-reference from 42 CFR 457.1216), and
at 45 CFR 156.221(f)(1)(i), the regulation text states that relevant
payers ``receive'' versus ``accept'' data for current enrollees. At 42
CFR 422.119(f)(1)(ii), 438.62(b)(1)(vi)(B) (and by cross-reference from
42 CFR 457.1216), and at 45 CFR 156.221(f)(1)(ii), the final
regulations provide that a payer must send the defined information set
to any other payer. In addition, at 42 CFR 422.119(f)(1)(iii),
438.62(b)(1)(vi)(C) (and by cross-reference from 42 CFR 457.1216), and
at 45 CFR 156.221(f)(1)(iii), we specify that a payer is only obligated
to send data received from another payer under this policy in the
electronic form and format it was received. This is intended to reduce
burden on payers. We note the final regulations do use the term
``payer'' in place of ``health care plan'' to clarify that the scope of
the obligations are for all payers impacted by this regulation. Also at
45 CFR 156.221(f)(1), we updated the title of the paragraph to align
with the parallel regulations for other payers types, and we corrected
an incomplete sentence. Finally, we specify that this policy also
applies to an enrollee's personal representative.
We are also finalizing regulation text to address when these
regulated payers must comply with these new requirements at 42 CFR
422.119(h) for MA organizations; at 42 CFR 438.62(b)(1)(vii) for
Medicaid managed care plans (and at 42 CFR 457.1216, to CHIP managed
care entities); and at 45 CFR 156.221(i) for QHP issuers on the FFEs.
Starting January 1, 2022, and for QHP issuers on the FFEs starting with
plan years beginning on or after January 1, 2022, the finalized
regulation requires these payers to exchange data with a date of
service on or after January 1, 2016 that meets the requirements of this
section and which the payer maintains. In this way, payers only have to
prepare an initial historical set of data for sharing via this payer-
to-payer data exchange policy that is consistent with the data set to
be available through the
[[Page 25569]]
Patient Access API, as finalized in section III. of this final rule.
VI. Care Coordination Through Trusted Exchange Networks: Trust Exchange
Network Requirements for MA Plans, Medicaid Managed Care Plans, CHIP
Managed Care Entities, and QHP Issuers on the FFEs Provisions, and
Analysis of and Responses to Public Comments
We proposed to require MA plans, Medicaid managed care plans, CHIP
managed care entities, and QHP issuers on the FFEs to participate in
trust networks in order to improve interoperability in these programs.
We noted that we would codify this requirement in, respectively, 42 CFR
422.119(f)(2), Sec. 438.242(b)(5), and Sec. 457.1233(d) (which cross-
references the requirements in 42 CFR 438.242(b)(5)) and 45 CFR
156.221(f). In general, payers and patients' ability to communicate
between themselves and with health care providers could considerably
improve patient access to data, reduce provider burden, and reduce
redundant and unnecessary procedures. Trusted exchange networks allow
for broader interoperability beyond one health system or point to point
connections among payers, providers, and patients. Such networks
establish rules of the road for interoperability, and with maturing
technology, such networks are scaling interoperability and gathering
momentum with participants, including several federal agencies, EHR
vendors, retail pharmacy chains, large provider associations, and
others.
The importance of a trusted exchange framework to such
interoperability is reflected in section 4003(b) of the Cures Act,
which was discussed in more detail in section I.D. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7612 through
7614). In section VI. of the CMS Interoperability and Patient Access
proposed rule (84 FR 7642), we discussed and explained our proposal to
require certain payers to participate in trusted exchange networks. A
trusted exchange framework allows for the secure exchange of electronic
health information with, and use of electronic health information from,
other health IT. Widespread payer participation in such a framework
might allow for more complete access and exchange of all electronically
accessible health information for authorized use under applicable state
or federal law, which we believe would lead to better use of such data.
We noted that while we cannot require widespread payer participation in
trust networks, we proposed to use our program authority in the MA
program, Medicaid managed care program, CHIP managed care program, and
QHP certification program for the FFEs to increase participation in
trust networks and to bring the potential benefits of participating in
such programs, including improved interoperable communication and care
coordination, which result in opportunities for improved patient
outcomes and burden reduction.
We proposed to require, beginning January 1, 2020, that MA plans,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs participate in a trusted exchange network. The
proposal was based on our authority under: Sections 1856(b) and 1857(e)
of the Act to adopt standards and contract terms for MA plans; section
1902(a)(4) of the Act to adopt methods of administration for the
administration state Medicaid plans, including requirements for
Medicaid managed care plans (MCOs, PIHPs, and PAHPs); section 2101(a)
for CHIP managed care entities (MCOs, PIHPs, and PAHPS); and section
3001(c)(9)(F)(iii) of the PHSA and section 1311(e)(1)(B) of the
Affordable Care Act for QHP issuers on an FFE. Under the proposal, and
consistent with section 4003(b) of the Cures Act, participation would
be required in a trusted exchange framework that met the following
criteria:
(1) The trusted exchange network must be able to exchange PHI,
defined at 45 CFR 160.103, in compliance with all applicable state and
federal laws across jurisdictions.
(2) The trusted exchange network must be capable of connecting both
inpatient EHRs and ambulatory EHRs.
(3) The trusted exchange network must support secure messaging or
electronic querying by and between patients, providers, and payers.
We proposed to codify these requirements for these payers at 42 CFR
422.119(f)(2) for MA organizations, Sec. 438.242(b)(5) for Medicaid
managed care plans, Sec. 457.1233(d)(2) for CHIP managed care
entities, and 45 CFR 156.221(f) for QHPs on the FFEs.
On April 19, 2019, ONC released the draft Trusted Exchange
Framework and Common Agreement (TEFCA Draft 2) for public comment.\48\
Previous commenters on draft 1 of the TEFCA, particularly payers
providing comments, requested that existing trust networks that are
operating successfully be leveraged in further advancing
interoperability; thus, we considered a possible future approach to
payer-to-payer and payer-to-provider interoperability that leverages
existing trust networks to support care coordination and improve
patient access to their data. We requested comments on this approach
and how it might be aligned in the future with section 4003(b) of the
Cures Act. We also requested comments on the applicability date we
proposed for the trusted exchange network participation requirement and
what benefits and challenges the payers subject to our proposal might
face meeting this requirement for additional consideration in future
rulemaking.
---------------------------------------------------------------------------
\48\ See https://www.healthit.gov/sites/default/files/page/2019-04/FINALTEFCAQTF41719508version.pdf. For additional information
about TEFCA, see https://www.healthit.gov/topic/interoperability/trusted-exchange-framework-and-common-agreement.
---------------------------------------------------------------------------
We summarize the public comments we received on this topic and
provide our responses.
Comment: Although many stakeholders supported the concept of this
proposal, there were strong exceptions. Many commenters, particularly
payers, indicated that it was premature for CMS to finalize a proposal
related to trusted exchange network participation before the first
version of the Common Agreement under ONC's TEFCA was finalized.
Commenters noted that, even though they supported using a trusted
exchange network, it would not be advisable until after TEFCA as
outlined in section 4003 of the 21st Century Cures Act was available to
facilitate this proposal.
Response: We appreciate that although commenters supported the
general concept of trusted exchange network participation and how it
could advance interoperability and data exchange, the true value of
this concept might be best realized via TEFCA in the future. We agree
that trusted exchange networks can play a positive role, but given the
concerns commenters raised regarding the need for a mature TEFCA, and
appreciating the ongoing work on TEFCA being done at this time, we are
not finalizing this policy at this time.
Comment: Some commenters noted that more detail would be needed to
understand how this proposal would be operationalized. These commenters
also indicated more information would be needed to understand how this
policy would relate to existing Health Information Exchanges (HIEs) and
Health Information Networks (HINs) and whether these entities would
qualify as trusted exchange networks. A few commenters indicated this
policy may be redundant appreciating the existing role of HIEs and
HINs.
Response: We appreciate the commenters' concerns and requests for
[[Page 25570]]
additional information. We will keep these in mind as we consider
possible future proposals around participation in trusted exchange
networks.
Comment: Many commenters expressed concerns with the proposed
implementation timeline. They did not believe this policy could be
implemented by January 1, 2020. Commenters indicated it would take more
time to meet the necessary requirements and fully understand the
implications of the policy, particularly for HIEs and HINs. Many
commenters suggested a delay ranging from 12 to 24 months. Other
commenters suggested CMS align the timeline of this proposal with TEFCA
implementation milestones. In addition to a delay, some commenters
suggested an exemption process.
Response: We appreciate the commenters concerns, and based on these
concerns and those summarized from other commenters, we are not
finalizing this proposal at this time. To reflect this in this final
rule, the regulation text proposed for all impacted payers is not being
finalized. In addition, as 42 CFR 438.242(b)(5) is not being finalized,
the regulation text proposed at 42 CFR 438.242(b)(6) is being
redesignated as 42 CFR 438.242(b)(5).
Final Action: After consideration of the comments received, and for
the reasons outlined in our response to these comments, we are not
finalizing this proposal to require MA organizations, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to
participate in a trusted exchange network.
VII. Improving the Medicare-Medicaid Dually Eligible Experience by
Increasing the Frequency of Federal-State Data Exchanges Provisions,
and Analysis of and Responses to Public Comments
A. Increasing the Frequency of Federal-State Data Exchanges for Dually
Eligible Individuals
1. Background
The Medicare and Medicaid programs were originally created as
distinct programs with different purposes. The programs have different
rules for eligibility, covered benefits, and payment. The programs have
operated as separate and distinct systems despite a growing number of
people who depend on both programs (known as dually eligible
individuals) for their health care. There is an increasing need to
align these programs--and the data and systems that support them--to
improve care delivery and the beneficiary experience for dually
eligible individuals, while reducing administrative burden for
providers, health plans, and states. The interoperability of state and
CMS eligibility and Medicaid Management Information System (MMIS)
systems is a critical part of modernizing the programs and improving
beneficiary and provider experiences. Improving the accuracy of data on
dual eligibility by increasing the frequency of federal-state data
exchanges is a strong first step in improving how these systems work
together.
2. Data Exchanges To Support State Buy-In for Medicare Parts A and B
States and CMS routinely exchange data on who is enrolled in
Medicare and Medicaid, and which parties are liable for paying that
beneficiary's Parts A and B premiums. These data exchanges support
state, CMS, and Social Security Administration (SSA) premium
accounting, collections, and enrollment functions. Section 1843 of the
Act permits states to enter into an agreement with the Secretary to
facilitate state ``buy-in,'' that is, payment of Medicare premiums, in
this case Part B premiums, on behalf of certain individuals. For those
beneficiaries covered under the agreement, the state pays the
beneficiary's monthly Part B premium. Section 1818(g) of the Act
establishes the option for states to amend their buy-in agreement to
include enrollment and payment of the Part A premium for certain
specified individuals. All states and the District of Columbia have a
Part B buy-in agreement; 36 states and the District of Columbia have a
Part A buy-in agreement.
To effectuate the state payment of Medicare Part A or Part B
premiums, a state submits data on a buy-in file to CMS via an
electronic file transfer (EFT) exchange setup. The state's input file
includes a record for each Medicare beneficiary for whom the state is
adding or deleting coverage, or changing buy-in status. In response,
CMS returns an updated transaction record that provides data
identifying, for each transaction on the state file, whether CMS
accepted, modified, or rejected it, as well a Part A or Part B billing
record showing the state's premium responsibility. In addition, the CMS
file may ``push'' new updates obtained from SSA to the state, for
example, changes to the Medicare Beneficiary Identifier number or a
change of address.
We have issued regulations for certain details of the state buy-in
processes. For Medicare Part A, 42 CFR 407.40 describes the option for
states to amend the buy-in agreement to cover Part A premiums for
Qualified Medicare Beneficiaries (QMBs). For Medicare Part B, 42 CFR
406.26 codifies the process for modifying the buy-in agreement to
identify the eligibility groups covered. CMS subregulatory guidance,
specifically Chapter 3 of the State Buy-in Manual,\49\ specifies that
states should exchange buy-in data with CMS at least monthly, but
describes the option for states to exchange buy-in data with CMS daily
or weekly. Likewise, states can choose to receive the CMS response data
file daily or monthly. We note that 35 states and the District of
Columbia are now submitting buy-in data to CMS daily; 31 states and the
District of Columbia are now receiving buy-in response files from CMS
daily.
---------------------------------------------------------------------------
\49\ Centers for Medicare and Medicaid Services. (2003). State
Buy-In Manual: Chapter 3--Data Exchange. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/downloads/buyin_c03.pdf. (Last accessed June 24, 2019).
---------------------------------------------------------------------------
While many states submit and receive buy-in files daily, some
continue to only do so on a monthly basis. We have become increasingly
concerned about the limitations of monthly buy-in data exchanges with
states. The relatively long lag in updating buy-in data means that the
state is not able to terminate or activate buy-in coverage sooner, so
the state or beneficiary may be paying premiums for longer than
appropriate. In most cases, funds must be recouped and redistributed--a
burdensome administrative process involving debits and payments between
the beneficiary, state, CMS, and SSA. Additionally, transaction errors
do occur in the current data exchange processes. In a monthly exchange,
it can take multiple months to correct and resubmit an improperly
processed transaction, exacerbating the delays in appropriately
assigning premium liability, leading to larger mispayment, recoupment,
and redistribution of premiums. Exchanging the buy-in data with greater
frequency supports more timely access to coverage.
All states' systems already have the capacity to exchange buy-in
data. We acknowledge that states that do not already exchange data
daily will need an initial, one-time systems change to do so. However,
moving to a daily data exchange would result in a net reduction of
burden for states, and further, reduce administrative complexity for
beneficiaries and providers. More frequent submission of updates to
individuals' buy-in status positively impacts all involved. For a full
discussion of the benefits, see the CMS Interoperability and Patient
Access
[[Page 25571]]
proposed rule (84 FR 7643 through 7644).
While there exist opportunities to modernize the platform for buy-
in data exchange, we believe that an important first step is to promote
the exchange of the most current available data. Section 1843(f) of the
Act specifies that Part B buy-in agreements shall contain such
provisions as will facilitate the financial transactions of the State
and the carrier with respect to deductions, coinsurance, and otherwise,
and as will lead to economy and efficiency of operation. Further,
section 1818(g)(2)(A) of the Act on Part A buy-in identifies this
section 1843(f) requirement as applicable to Part A buy-in. While the
regulations governing buy-in agreements (see 42 CFR 406.26 and 407.40)
are silent on the frequency of buy-in data exchanges, current guidance
articulates that the required buy-in data may be submitted daily,
weekly, or monthly. Therefore, we proposed to establish frequency
requirements in the regulations at 42 CFR 406.26(a)(1) and 407.40(c) to
require all states to participate in daily exchange of buy-in data with
CMS, with ``daily'' meaning every business day, but that if no new
transactions are available to transmit, data would not need to be
submitted on a given business day. We noted that we believe these
requirements will improve the economy and efficiency of operation of
the buy-in process. We proposed that states would be required to begin
participating in daily exchange of buy-in data with CMS by April 1,
2022. We noted that we believe this applicability date would allow
states to phase in any necessary operational changes or bundle them
with any new systems implementation. In the CMS Interoperability and
Patient Access proposed rule, we estimated that 19 states would need to
make a system change to send buy-in data to CMS daily and 22 states
would need to make a system change to receive buy-in data from CMS
daily (84 FR 7668). Based on more recent data, we estimate that 26 and
19 states would require such system changes, respectively. We updated
our estimates to determine the one-time cost to be $85,000 per state,
per change, so a state that needs to make systems updates to both send
buy-in data daily, and receive buy-in data daily would have a one-time
cost of just over $170,000. We sought comment on the proposals.
We summarize the public comments we received on data exchanges to
support state buy-in for Medicare Parts A and B and provide our
responses.
Comment: Almost all those who commented on these provisions
supported the proposal to require that all states participate in daily
exchange of buy-in data with CMS by April 1, 2022. Commenters stated
that the changes would improve the timeliness and accuracy of
eligibility and enrollment data, and enhance capability for
coordination of benefits.
Response: We appreciate the strong support for the proposed change
to the regulation.
Comment: One commenter supported the change, but also encouraged
CMS to modify its own processes and systems to effectively leverage
daily data exchanges to support enhanced care for dually eligible
individuals. Another commenter requested clarification if the daily
state submission of the buy-in file encompasses a reciprocal daily
response from CMS to the states.
Response: We agree that CMS and states both play important roles in
implementing systems changes to support the state buy-in process.
Currently, states can choose to exchange buy-in data with CMS daily,
weekly, or monthly; and separately, they can choose to receive the CMS
response data file daily, weekly, or monthly. We proposed that all
states both send data to CMS and receive responses from CMS on a daily
basis. We will continue to look for opportunities to optimize CMS
systems and processes to support better care for dually eligible
individuals.
Comment: One commenter supported requiring frequent exchanges of
this data as a way to eliminate current inefficiencies and improve
benefit coordination for the dually eligible population so long as this
requirement does not impose additional reporting requirements on
clinicians.
Response: We appreciate the support for our proposal. We confirm
that the regulation as proposed does not create additional reporting
requirements on clinicians. As noted in the preamble to the CMS
Interoperability and Patient Access proposed rule, we estimate that the
change to a daily submission would result in a net reduction of burden
for states, and further, reduce administrative complexity for
beneficiaries and providers.
Comment: One commenter noted that the proposed applicability date
of April 1, 2022 will be sufficient for this change, but for overall
unity in the rule's proposed changes, encouraged CMS to consider
aligning the applicability date of this proposal with an overall
extended implementation time frame of at least 2 years--and ideally 5
years--for the remainder of the rule's provisions.
Response: We appreciate the value in aligned implementation
timelines. However, given that other provisions in this rule for health
plans and states are distinct from this requirement, and will be
required beginning in 2020, we continue to believe that the April 1,
2022 implementation timeline proposed for daily exchange of buy-in data
is appropriate.
Comment: Commenters recommended that CMS establish a process for
states to provide Medicare dual eligible special needs plans (D-SNPs)
with, at a minimum, data on beneficiaries' Medicaid coverage.
Commenters requested CMS align the eligibility and enrollment
information that health plans receive with the information being shared
between states and the federal government so there is a single ``source
of truth'' on these data. Commenters noted this consistency is critical
to improving care coordination for dually eligible individuals.
Response: D-SNPs have an important role in supporting their
enrollees' access to Medicaid benefits. We understand that in many
states D-SNPs have limited access to timely data on Medicaid
enrollment. We note that we do provide data to D-SNPs and other MA
plans on the Medicaid status of their members. While we appreciate the
value of D-SNPs getting additional Medicaid coverage data such as
Medicaid plan enrollment, we decline to modify the regulations to
require states to do so as it is beyond the scope of this proposal.
However, we continue to explore opportunities to provide plans with
data that would assist them in better coordinating benefits and
coverage for their dually eligible enrollees.
Comment: One commenter noted that the CMS Interoperability and
Patient Access proposed rule does not require states to input the
latest eligibility data in a specific timeframe on their claims
platforms. The commenter noted that not having this clarity means that
there could be a potential for inconsistent data. The commenter
recommended that CMS require state Medicaid programs to update their
claims platforms daily to assist with accurate data exchanges.
Response: We appreciate the point the commenter is making. Our
proposal did not explicitly address how states incorporate eligibility
data with claims and other systems. We will consider this
recommendation for the future as we gain additional experience with
daily data exchange.
Comment: Two commenters stated that daily exchange of buy-in data
would require significant systems changes and costs. One of these
commenters recommended that CMS revise the proposal to update the
frequency of exchange from monthly to
[[Page 25572]]
weekly, rather than daily. The commenter noted that it would seldom
have new information to send on a daily basis, but that determining on
a daily basis whether there was any new information to send would be a
large effort. Finally, the commenter requested if CMS finalized the
regulation to require daily updates, that provisions be made for states
whose systems cycles are other than within a calendar day, for example,
6 p.m. to 6 a.m.
Response: We appreciate the costs that the state may bear to make
the systems changes necessary to implement these provisions. We will
provide technical assistance and opportunities for shared learning
through webinars and training to support states' transition.
We also note that federal matching funds at the standard rate of 50
percent for administration will reduce the states' costs. States may
also be eligible for enhanced 90 percent federal matching funds for the
costs of developing and implementing any necessary system changes
required by regulation, and enhanced 75 percent federal matching funds
for their system's maintenance and operation costs. These enhanced
federal matching funds would be available for their Eligibility and
Enrollment (E&E) systems (and, if necessary, their Medicaid Management
Information System (MMIS)). States would request enhanced funding
through the Advance Planning Document (APD) process.
Even though there are costs to the states in implementing daily
exchange of buy-in data, other commenters uniformly supported the value
of daily exchanges in improving the experience of dually eligible
individuals, and in reducing burden on states, providers, and plans to
reconcile payment. As a result, we decline to make the suggested
change.
With respect to the point that there would often not be updates on
a daily basis, we reiterate that no file would be required on business
days where there were no updates. We expect that states would be able
to automate their systems so that they check daily for changes to buy-
in status that would need to be submitted to CMS on the buy-in file,
but also automate a process by which the system only generates a buy-in
file upon identifying such a change. We appreciate the additional
coding required to implement this logic but expect that once
implemented, no additional interventions would be needed. We will work
with states that have implemented these changes to identify and share
best practices in identifying data changes to trigger daily
submissions.
Finally, in response to the concern about whether states that have
an overnight processing cycle would be permitted to continue doing so,
we affirm that the proposed regulation would permit this.
After consideration of the public comments and for the reasons
articulated in the CMS Interoperability and Patient Access proposed
rule and our responses to comments, we are finalizing changes to 42 CFR
406.26 and 407.40 as proposed.
3. Exchange of State MMA Data Files
States submit data on files at least monthly to CMS to identify all
dually eligible individuals, including full-benefit and partial-benefit
dually eligible individuals (that is, those who get Medicaid help with
Medicare premiums, and often for cost-sharing). The file is called the
``MMA file,'' but is occasionally referred to as the ``State Phasedown
file.'' The MMA file was originally developed to meet the need to
timely identify dually eligible individuals for the then-new Medicare
Part D prescription drug benefit. The Medicare Modernization Act (MMA)
established that, beginning January 1, 2006, Medicare would be
primarily responsible for prescription drug coverage for full-benefit
dually eligible individuals; established auto-enrollment of full-
benefit dually eligible individuals into Medicare prescription drug
plans (with regulations further establishing facilitated enrollment
into prescription drug plans for partial-benefit dually eligible
individuals), provided that dually eligible individuals are treated as
eligible for the Medicare Part D Low Income Subsidy (LIS), sometimes
called Extra Help; defined phased down state contributions to partly
finance Part D costs for dually eligible individuals; and required
risk-adjusting capitation payments for LIS (which include dually
eligible) enrollees of Part D plans. To support these new requirements,
we issued 42 CFR 423.910, establishing monthly reporting by states, in
which states would submit, at least monthly, a data file identifying
dually eligible individuals in their state. Over time, we used these
files' data on dual eligibility status to support Part C capitation
risk-adjustment, and most recently, to feed dual eligibility status to
Part A and B eligibility and claims processing systems so providers,
suppliers, and individuals have accurate information on beneficiary
cost-sharing obligations.
Currently, regulations require states to submit at least one MMA
file each month. However, states have the option to submit multiple MMA
files throughout the month (up to one per day). Most states submit MMA
data files at least weekly. In the CMS Interoperability and Patient
Access proposed rule, we estimated that 37 states and DC would need to
make a system change to send MMA data to CMS daily (84 FR 7668). Based
on more recent data, we estimate that 36 states and DC would require
such system changes. As CMS now leverages MMA data on dual eligibility
status into systems supporting all four parts of the Medicare program,
it is becoming even more essential that dual eligibility status is
accurate and up-to-date. Dual eligibility status can change at any time
in a month. Waiting up to a month for status updates can negatively
impact access to the correct level of benefit at the correct level of
payment. Based on our experience with states that exchange data daily,
more frequent MMA file submissions benefit states, individuals, and
providers, in a number of ways. For a full discussion of the benefits,
see the CMS Interoperability and Patient Access proposed rule (84 FR
7644).
As noted, current regulation requires that each state submit an MMA
file at least monthly. We have implemented ``work-arounds'' for lags in
dual eligibility status for Part D, including the ``Best Available
Evidence'' policy (see 42 CFR 423.800(d)), as well as the Limited
Income Newly Eligible Transition demonstration, which provides short
term drug coverage for dually eligible individuals with no Part D plan
enrollment in a given month (see Medicare Prescription Drug Benefit
Manual, Chapter 3, Section 40.1.4).\50\ While these work-arounds
provide needed protections, more frequent data exchanges would mitigate
the need for them.
---------------------------------------------------------------------------
\50\ Centers for Medicare and Medicaid Services. (2017).
Medicare Prescription Drug Benefit Manual: Chapter 3--Eligibility,
Enrollment and Disenrollment. Retrieved from https://www.cms.gov/Medicare/Eligibility-and-Enrollment/MedicarePresDrugEligEnrol/Downloads/CY_2018_PDP_Enrollment_and_Disenrollment_Guidance_6-15-17.pdf. (Last accessed June 24, 2019).
---------------------------------------------------------------------------
Ensuring information on dual eligibility status is accurate and up-
to-date by increasing the frequency of federal-state data exchange is
an important step in the path to interoperability. As a result, we
proposed to update the frequency requirements in 42 CFR 423.910(d) to
require that, starting April 1, 2022, all states submit the required
MMA file data to CMS daily, and to make conforming edits to 42 CFR
423.910(b)(1). Daily would mean every
[[Page 25573]]
business day, but that if no new transactions are available to
transmit, states would not need to submit data on a given business day.
We proposed requiring that states begin submitting these data daily to
CMS by April 1, 2022 because we believed this applicability date would
allow states to phase in any necessary operational changes or bundle
them with any new systems implementation. We estimated an updated one-
time cost for a state to be $85,000 for this MMA data systems change.
For a detailed discussion of the costs associated with these
requirements, we refer readers to section XVI. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7660 through
7673), as well as section XVI of this final rule. We sought comment on
these proposals.
We summarize the public comments we received on exchange of state
MMA data files and provide our responses.
Comment: Almost all those who commented on this provision supported
the proposal to require all states to participate in daily submission
of MMA file data with CMS by April 1, 2022. Commenters noted that the
changes would improve the timeliness and accuracy of eligibility and
enrollment data, enhance coordination of benefits, and support greater
integration of care.
Response: We appreciate the strong support for the proposed change
to the regulation.
Comment: One commenter supported the proposed change, but requested
CMS consider standardizing which file types and data sets will be
acceptable to support standardized daily submissions, for the overall
purpose of improving the state and CMS data exchanges.
Response: We understand the suggestion that we standardize which
upstream data sets (for example, CMS finder files, state eligibility
data) states should use to support daily MMA file submissions. To that
end, we will provide technical assistance to states that need to make
changes to submit the file daily. As part of that effort, we will work
with states that already submit MMA files daily to understand and share
information on best practices on the upstream data sets necessary to
implement daily MMA file submissions.
Comment: One commenter noted that the proposed applicability date
of April 1, 2022 will be sufficient for this change, but for overall
unity in the rule's proposed changes, encouraged CMS to consider
aligning the effective date of this proposal with an overall extended
implementation time frame of at least 2 years--and ideally 5 years--for
the remainder of the rule's provisions.
Response: We appreciate the value in aligned implementation
timelines. However, given that other provisions in this rule for health
plans and states are distinct from this requirement, and will be
required beginning in 2020, we continue to believe that the April 1,
2022 implementation timeline proposed for daily MMA file submissions is
appropriate.
Comment: A few commenters noted the value of the data in the MMA
file to Medicaid managed care organizations (MCO), Medicare dual
eligible special needs plans (D-SNPs), Health Information Exchanges,
and providers for the purposes of coordinating enrollment, benefits,
and/or care for dually eligible individuals. These commenters requested
access to the daily MMA file. One commenter noted that some states are
sharing Medicare plan enrolment data from these files with their
Medicaid MCOs while also providing batch inquiry data sharing
mechanisms to D-SNPs on Medicaid plan enrollment. This commenter
recommended that CMS encourage or require all states to follow this
process at a minimum.
Commenters also encouraged CMS to leverage the MMA file to support
parties complying with the D-SNP integration standards recently issued
in 42 CFR 422.2.
Response: We appreciate these suggestions to promote access to data
for plans and providers serving dually eligible individuals, and we
will explore these ideas further for potential future consideration.
However, we decline to modify the regulation as suggested, as the
recommended changes are beyond the scope of the proposal, which is
limited to the frequency of the file exchange.
Comment: A few commenters made additional suggestions for
streamlining data exchanges. In addition to making the MMA files
accessible to plans and providers, some commenters recommended adding
Medicaid plan enrollment information to MMA files to create a single
source of Medicare-Medicaid enrollment data for dually eligible
individuals. Another commenter suggested a potential pathway to
streamlining data exchanges would be for CMS to allow state Transformed
Medicaid Statistical Information System (T-MSIS) files to serve as the
beneficiary data source for third-party applications.
Response: We appreciate the value of streamlining data exchanges,
including access to a consistent data source on eligibility and
enrollment. We also acknowledge the overlap of certain data exchanged
in the MMA and T-MSIS file, though we note we would need to carefully
explore the implications and impacts of merging operational data
exchanges such as the MMA file--which result in changes to an
individual's Medicare benefit--with informational exchanges such as T-
MSIS. We will consider exploring these opportunities further for
potential future consideration. However, we decline to modify the
regulation as suggested, as the recommended changes are beyond the
scope of the proposal, which is limited to the frequency of the file
exchange.
Comment: Several commenters noted significant system changes and
cost to update the frequency of exchanging MMA files to daily. One
commenter stated that they believe HHS has underestimated the cost to
upgrade the MMA system to support daily exchange. The commenter
encouraged CMS to provide an updated estimate for the costs to upgrade
the system that include additional operational costs. This commenter
and others encouraged CMS to consider providing additional funding to
state Medicaid programs that will need to upgrade their data systems.
One commenter questioned if CMS would consider increasing the FMAP
states receive for interoperability activities that support dual
eligible plans integrations and in particular, for programmatic or
systems changes to come into compliance with D-SNP integration. The
commenter noted that this increase could exceed existing enhanced
matches, for example allowing the 90 percent match to apply for ongoing
systems operations that facilitate care coordination.
Response: We appreciate the input on the level of effort needed to
submit the MMA file daily. As noted elsewhere, we will provide
technical assistance and opportunities for shared learning through
webinars and training to support states' transition. We also note that
federal matching funds of 50 percent for administration will reduce the
states' costs. States may also be eligible for enhanced 90 percent
federal matching funds for the costs of developing and implementing any
necessary system changes required by regulation, and enhanced 75
percent federal matching funds for their system's maintenance and
operation costs. These enhanced federal matching funds would be
available for their Eligibility and Enrollment systems (and, if
necessary, their Medicaid Management Information System (MMIS)). States
would request enhanced funding through the Advance Planning Document
(APD) process.
[[Page 25574]]
As commenters did not provide specific information on the costs in
excess of our assessment, we find that we have no basis to make a
reasonable adjustment. As such, we are maintaining our estimate of the
number of hours required, as detailed in sections XII. and XIII. of
this final rule.
Comment: One commenter opposed increasing states submission of the
MMA file from monthly to daily, recommending instead that the frequency
be increased to weekly. The commenter stated that determining on a
daily basis whether there was any new information to send would be a
significant effort, as multiple upstream systems may have to be
changed, and further, that there would seldom be new data to send on a
daily basis. The commenter requested that if CMS finalized the
regulation to require daily exchanges that states be permitted to
continue to existing processing cycles that cross business, for
example, run overnight between 6:00 p.m. to 6:00 a.m.
Response: We acknowledge the commenter's concerns about resources,
but note that other commenters--even those who echoed concerns about
resources--uniformly supported the value of daily exchanges in
improving the experience of dually eligible individuals and the ability
of providers and plans to coordinate eligibility, enrollment, benefits,
and/or care for this population. As we note above, we are committed to
providing technical assistance and federal matching funds to support
needed systems changes at the state. As a result, we decline to make
the recommended change.
With respect to the point that there would not be updates on a
daily basis, we reiterate that no file would be required on business
days when there were no updates. We expect that states would be able to
automate their systems so that they check daily for changes to data
that would need to be submitted to CMS on the MMA file, but also
automate a process by which the system only generates an MMA file upon
identifying such a change. We appreciate the additional coding required
to implement this logic but that that once implemented, no additional
interventions would be needed. We will work with states that have
implemented these changes to identify and share best practices in
identifying data changes to trigger daily submissions.
Finally, in response to the concern about states that have an
overnight processing cycle to continue so to meet the definition of
``daily,'' the proposed regulation would permit this.
After consideration of the public comments and for the reasons
articulated in the CMS Interoperability and Patient Access proposed
rule and our responses to comments, we are finalizing 42 CFR 423.910 as
proposed.
B. Request for Stakeholder Input
In addition to the proposals discussed above, we sought public
comment for consideration in potential future rulemaking on how we can
achieve greater interoperability of federal-state data for dually
eligible individuals, including in the areas of program integrity and
care coordination, coordination of benefits and crossover claims,
beneficiary eligibility and enrollment, and their underlying data
infrastructure. For more information on our request for comment, see
the CMS Interoperability and Patient Access proposed rule (84 FR 7645).
We thank commenters for their input. We will consider the information
received for potential future rulemaking.
Final Action: We will require all states to participate in daily
exchange of buy-in data, which includes both sending data to CMS and
receiving responses from CMS daily, and require all states submit the
required MMA file data to CMS daily by April 1, 2022. These policies
are being finalized in 42 CFR 406.26, 407.40, and 423.910,
respectively, as proposed. These requirements will improve the
experience of dually eligible individuals and the ability of providers
and payers to coordinate eligibility, enrollment, benefits, and/or care
for this population. Federal matching funds of 50 percent for
administration are available to support states' costs. States may also
be eligible for enhanced 90 percent federal matching funds for the
costs of developing and implementing any necessary system changes
required by this regulation, and enhanced 75 percent federal matching
funds for their system's maintenance and operation costs. CMS will
provide technical assistance to the states that need to make changes to
submit their files daily, including best practices on the upstream data
sets necessary to implement daily MMA file submissions.
VIII. Information Blocking Background and Public Reporting Provisions,
and Analysis of and Responses to Public Comments
A. Information Blocking Background
1. Legislative Background and Policy Considerations
The nature and extent of information blocking has come into focus
in recent years. In 2015, at the request of the Congress, ONC submitted
a Report on Health Information Blocking \51\ (hereinafter referred to
as the ``Information Blocking Congressional Report''), in which ONC
commented on the then current state of technology, health IT, and
health care markets. Notably, ONC observed that prevailing market
conditions create incentives for some individuals and entities to
exercise their control over electronic health information in ways that
limit its availability and use. Since that time, ONC and other
divisions of HHS have continued to receive feedback from patients,
clinicians, health care executives, payers, app developers and other
technology companies, registries and health information exchanges,
professional and trade associations, and many other stakeholders
regarding practices which may constitute information blocking. Despite
significant public and private sector efforts to improve
interoperability and data liquidity, engagement with stakeholders
confirms that adverse incentives remain and continue to undermine
progress toward a more connected health system.
---------------------------------------------------------------------------
\51\ Office of the National Coordinator. (2015, April 9). Report
to Congress on Health Information Blocking. Retrieved from https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf.
---------------------------------------------------------------------------
Based on these economic realities and first-hand experience working
with the health IT industry and stakeholders, ONC concluded in the
Information Blocking Congressional Report that information blocking is
a serious problem and recommended that the Congress prohibit
information blocking and provide penalties and enforcement mechanisms
to deter these harmful practices.
MACRA became law in the same month that the Information Blocking
Congressional Report was published. Section 106(b)(2)(A) of MACRA
amended section 1848(o)(2)(A)(ii) of the Act to require that an
eligible professional must demonstrate that he or she has not knowingly
and willfully taken action (such as to disable functionality) to limit
or restrict the compatibility or interoperability of certified EHR
technology, as part of being a meaningful EHR user. Section
106(b)(2)(B) of MACRA made corresponding amendments to section
1886(n)(3)(A)(ii) of the Act for eligible hospitals and, by extension,
under section 1814(l)(3) of the Act for CAHs. Sections 106(b)(2)(A) and
(B) of MACRA provide that the manner of this demonstration is to be
through a process specified by the Secretary, such as the use of an
attestation. To implement these provisions, as discussed further
[[Page 25575]]
below, we established and codified attestation requirements to support
the prevention of information blocking, which consist of three
statements containing specific representations about a health care
provider's implementation and use of CEHRT. To review our discussion of
these requirements, we refer readers to the CY 2017 Quality Payment
Program final rule (81 FR 77028 through 77035).
Recent empirical and economic research further underscores the
complexity of the information blocking problem and its harmful effects.
For a full discussion of the research, see the CMS Interoperability and
Patient Access proposed rule (84 FR 7645 through 7646).
In December 2016, section 4004 of the Cures Act added section 3022
of the PHSA (the ``PHSA information blocking provision''), which
defines conduct by health care providers, health IT developers, and
health information exchanges and networks that constitutes information
blocking. The PHSA information blocking provision was enacted in
response to ongoing concerns that some individuals and entities are
engaging in practices that unreasonably limit the availability and use
of electronic health information for authorized and permitted purposes
(see the definition of electronic health information proposed by ONC
for HHS adoption at 45 CFR 171.102 (84 FR 7588)). These practices
undermine public and private sector investments in the nation's health
IT infrastructure and frustrate efforts to use modern technologies to
improve health care quality and efficiency, accelerate research and
innovation, and provide greater value and choice to health care
consumers.
The information blocking provision defines and creates possible
penalties and disincentives for information blocking in broad terms,
working to deter the entire spectrum of practices likely to interfere
with, prevent, or materially discourage access, exchange, or use of
electronic health information. The PHSA information blocking provision
applies to health care providers, health IT developers, exchanges, and
networks. The information blocking provision also provides that the
``Secretary, through rulemaking, shall identify reasonable and
necessary activities that do not constitute information blocking for
purposes of the definition at section 3022(a)(1) of the PHSA.'' ONC's
21st Century Cures Act proposed rule proposed ``exceptions'' to the
information blocking provision. These exceptions are reasonable and
necessary activities that would not constitute information blocking. In
addition to the attestation discussed in this section, all health care
providers would also be subject to the separate information blocking
regulations proposed by ONC for HHS adoption at 45 CFR part 171 (84 FR
7601 through 7605).
B. Public Reporting and Prevention of Information Blocking on Physician
Compare
Physician Compare (http://www.medicare.gov/physiciancompare) draws
its operating authority from section 10331(a)(1) of the Affordable Care
Act. Consistent with section 10331(a)(2) of the Affordable Care Act,
Physician Compare initiated a phased approach to publicly reporting
performance scores that provide comparable information on quality and
patient experience measures. A complete history of public reporting on
Physician Compare is detailed in the CY 2016 Physician Fee Schedule
(PFS) final rule with comment period (80 FR 71117 through 71122). More
information about Physician Compare, including the history of public
reporting and regular updates about what information is currently
available, can also be accessed on the Physician Compare Initiative
website at https://www.cms.gov/medicare/quality-initiatives-patient-assessment-instruments/physician-compare-initiative/.
As discussed in the CY 2018 Quality Payment Program final rule (82
FR 53820), Physician Compare has continued to pursue a phased approach
to public reporting under MACRA in accordance with section 1848(q)(9)
of the Act. For a discussion of public reporting on Physician Compare,
see the CMS Interoperability and Patient Access proposed rule (84 FR
7646 through 7647).
Building upon the continuation of our phased approach to public
reporting and understanding the importance of preventing information
blocking, promoting interoperability, and the sharing of information,
we proposed to make certain data about the attestation statements on
the prevention of information blocking referenced in the CMS
Interoperability and Patient Access proposed rule (84 FR 7645)
available for public reporting on Physician Compare, drawing upon our
authority under section 10331(a)(2) of Affordable Care Act, which
required us to make publicly available on Physician Compare information
on physician performance that provides comparable information for the
public on quality and patient experience measures. Section 10331(a)(2)
of the Affordable Care Act provided that to the extent scientifically
sound measures that are developed consistent with the requirements of
section 10331 of the Affordable Care Act are available, such
information shall include, to the extent practicable, an assessment of
the coordination of care and other information as determined
appropriate by the Secretary. We noted our belief that section
10331(a)(2) of the Affordable Care Act provided the statutory authority
to publicly report certain data about the prevention of information
blocking attestation statements as an assessment of care coordination
and as other information determined appropriate by the Secretary.
Furthermore, the prevention of information blocking attestation
statements are required for a clinician to earn a Promoting
Interoperability performance category score, which is then incorporated
into the final score for MIPS, and we are required to publicly report
both of these scores under section 1848(q)(9)(A) of the Act. Publicly
posting this information as an indicator is consistent with our
finalized policy to publicly report, either on the profile pages or in
the downloadable database, other aspects of the Promoting
Interoperability performance category, such as objectives, activities,
or measures specified in the CY 2018 Quality Payment Program final rule
(82 FR 53826 through 53827). We note that we finalized at 42 CFR
414.1395(b), that, with the exception of data that must be mandatorily
reported on Physician Compare, for each program year, we rely on the
established public reporting standards to guide the information
available for inclusion on Physician Compare. The public reporting
standards require data included on Physician Compare to be
statistically valid, reliable, and accurate; be comparable across
submission mechanisms; and, meet the reliability threshold. To be
included on the public facing profile pages, the data must also
resonate with website users, as determined by CMS.
There are three prevention of information blocking attestation
statements under 42 CFR 414.1375(b)(3)(ii)(A) through (C) to which
eligible clinicians reporting on the Promoting Interoperability
performance category of MIPS must attest. To report successfully on the
Promoting Interoperability performance category, in addition to
satisfying other requirements, an eligible clinician must submit an
attestation response of ``yes'' for each of these statements. For more
information about these statements, we refer readers to the preamble
discussion
[[Page 25576]]
in the CY 2017 Quality Payment Program final rule (81 FR 77028 through
81 FR 77035).
The Promoting Interoperability performance category weight
comprises 25 percent of a MIPS eligible clinician's final score for
each MIPS payment year, as specified at 42 CFR 414.1375(a). As
specified at 42 CFR 414.1405(b)(2), MIPS eligible clinicians with a
final score below the performance threshold receive a negative MIPS
payment adjustment factor on a linear sliding scale. Certain MIPS
eligible clinicians who submit data for the Promoting Interoperability
performance category may be eligible for reweighting, as specified
under 42 CFR 414.1380(c)(2). As specified at 42 CFR 414.1405(a),
(b)(1), and (b)(2), MIPS eligible clinicians may receive a positive,
neutral, or negative MIPS payment adjustment factor. As specified at 42
CFR 414.1405(c), the applicable percent for MIPS payment year 2021 is 7
percent. For MIPS payment year 2022, and each subsequent MIPS payment
year, it is 9 percent. For more information about the MIPS, we refer
readers to the preamble discussion in the CY 2020 Quality Payment
Program final rule (84 FR 62946 through 63083).
We noted our belief that it would benefit the public to know if
eligible clinicians have attested negatively to the statements under 42
CFR 414.1375(b)(3)(ii) as this may assist the patient in selecting a
clinician or group who collaborates with other clinicians, groups, or
other types of health care providers by sharing information
electronically, and does not withhold information that may result in
better care. Therefore, we proposed to include an indicator on
Physician Compare for the eligible clinicians and groups that submit a
``no'' response to any of the three statements under 42 CFR
414.1375(b)(3)(ii)(A) through (C). In the event that these statements
are left blank, that is, a ``yes'' or a ``no'' response is not
submitted, the attestations would be considered incomplete, and we
would not include an indicator on Physician Compare. We also proposed
to post this indicator on Physician Compare, either on the profile
pages or the downloadable database, as feasible and appropriate,
starting with the 2019 performance period data available for public
reporting starting in late 2020. We refer readers to the 2019 Promoting
Interoperability Information Blocking Factsheet at https://qpp-cm-prod-content.s3.amazonaws.com/uploads/282/2019%20PI%20Information%20Blocking%20Fact%20Sheet.pdf for more
information about the attestation statements.
Under 42 CFR 414.1395(b), these data must meet our established
public reporting standards, including that to be included on the public
facing profile pages, the data must resonate with website users, as
determined by CMS. In previous testing with patients and caregivers, we
learned that effective use of CEHRT is important to them when making
informed health care decisions. For more information about previous
testing with patients and caregivers, we refer readers to the Physician
Compare Technical Expert Panel (TEP) Summary Report at https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/physician-compare-initiative/Downloads/Physician-Compare-TEP-Summary-2018.pdf. To determine how to best display and meaningfully
communicate the indicator on the Physician Compare website, the exact
wording and, if applicable, profile page indicator would be determined
after user testing and shared with stakeholders through the Physician
Compare Initiative page, listservs, webinars, and other available
communication channels. We noted that the proposal was contingent upon
the availability of and technical feasibility to use the data for
public reporting.
We summarize the public comments we received on this topic and
provide our responses.
Comment: Most commenters supported our proposal to publicly report
an indicator on the Physician Compare website for the eligible
clinicians and groups that submit a ``no'' response to any of the three
prevention of information blocking attestation statements, noting that
the indicator would discourage clinicians and groups from information
blocking and help Medicare patients and caregivers make informed health
care decisions.
Response: We thank commenters for their support and agree that
publicly reporting an indicator on Physician Compare will discourage
clinicians and groups from information blocking and help Medicare
patients and caregivers make informed decisions.
Comment: Some commenters expressed concern for various reasons
about publicly reporting an indicator on the Physician Compare website
for the eligible clinicians and groups that submit a ``no'' response to
any of the three prevention of information blocking attestation
statements. Several of these commenters thought the indicator would be
redundant, since there is already an incentive for clinicians to attest
to the prevention of information blocking statements in order to earn a
MIPS Promoting Interoperability performance category score. Some
commenters were concerned that an indicator may not accurately reflect
whether a clinician or group is knowingly or willfully information
blocking, since they may be confused about the attestation statements'
meanings. A few commenters suggested delaying Physician Compare's
indicator implementation in order to give clinicians and groups,
particularly small and rural practices, time to become more familiar
with the attestations. Other commenters expressed concern as to whether
Medicare patients and caregivers would find the indicator useful; one
of these commenters suggested conducting a pilot study to make such a
determination. Finally, several commenters suggested an appeal process
or an opportunity for clinicians and groups to review their information
prior to public reporting.
Response: We appreciate the commenters' concerns. We believe
publicly reporting an indicator on Physician Compare for the eligible
clinicians and groups that submit a ``no'' response to any of the three
prevention of information blocking attestation statements is not
redundant, as Medicare patients and caregivers do not currently have
access to this type of information, which could aid them in making
informed health care decisions.
Regarding concerns about clinicians, including small and rural
practices, needing time to become familiar with the attestations, we
believe there has been sufficient time for clinicians to become
familiar with them, since these attestation statements have been a MIPS
Promoting Interoperability performance category requirement since the
2017 performance period. We also believe that webinars and educational
materials that CMS has made available have provided clinicians and
groups an opportunity to become familiar with the information blocking
attestation statements. We will also continue to support small and
rural practices by offering free and customized resources available
within local communities, including direct, one-on-one support from the
Small, Underserved, and Rural Support Initiative along with our other
no-cost technical assistance (83 FR 59720). Regarding whether an
information blocking indicator would be meaningful to patients and
caregivers, we note that under 42 CFR 414.1395(b), these data must meet
our established public reporting standards, including that to be posted
on public facing profile pages, the data must resonate with website
users, as determined by CMS. Such user testing to date has shown that
[[Page 25577]]
effective CEHRT usage is important to patients when making health care
decisions. In addition, as specified at 42 CFR 414.1375(b)(3)(ii), MIPS
eligible clinicians must attest to the prevention of information
blocking statements. For more information about these statements, we
refer readers to the preamble discussion in the CY 2017 Quality Payment
Program final rule (81 FR 77028 through 81 FR 77035). In addition, we
note that section 4004 of the Cures Act added section 3022 of the PHSA,
which directs HHS to identify reasonable and necessary activities
conducted by health care providers, health IT developers, and health
information exchanges and networks that would not constitute
information blocking as defined in section 3022. For more information,
see the information blocking discussion in ONC's 21st Century Cures Act
final rule (published elsewhere in this issue of the Federal Register).
While we appreciate the commenter's suggestion to conduct a pilot
study, we believe that further user testing will allow us to gain the
additional understanding necessary.
Regarding the comments requesting an opportunity to review or an
appeal process, we note that, under 42 CFR 414.1395(d), for each
program year, CMS provides a 30-day preview period for any clinician or
group with Quality Payment Program data before the data are publicly
reported on Physician Compare. Although at this time we do not preview
indicator information, clinicians and groups will be able to preview
their Promoting Interoperability performance category information,
including their attestation responses to the three statements during
the MIPS targeted review process. All performance data publicly
reported on Physician Compare will reflect the scores eligible
clinicians and groups receive in their MIPS performance feedback, which
will be available for review and potential correction during the
targeted review process (83 FR 59912).
Comment: Many commenters recommended additional actions to prevent
information blocking, beyond publicly reporting an indicator on
Physician Compare. Some commenters recommended implementing additional
penalties for clinicians and groups that attest ``no'' to the
prevention of information blocking attestations, such as corrective
action. Other commenters suggested CMS offer more positive incentives.
Several commenters suggested having additional indicators, such a
positive one for those who attest ``yes.'' Another commenter
recommended treating a blank response to the three attestation
statements as a ``no'' response. A few commenters recommended that the
proposed indicator not be used for clinicians and groups that
participate in trusted exchange networks.
Response: We appreciate commenters' suggestions and will consider
them for potential future rulemaking, to the extent permitted by our
authority. To the extent of our authority, we will consider treatment
of attestation statements that are left blank, use of a positive
indicator on the Physician Compare profile pages or downloadable
database, and the use of the proposed indicator for clinicians and
groups that participate in trusted exchange networks for potential
future rulemaking.
Regarding commenters' suggestions for additional penalties, we note
that section 4004 of the Cures Act identifies potential penalties and
disincentives for information blocking. Health care providers
determined by the Inspector General to have committed information
blocking shall be referred to the appropriate agency to be subject to
appropriate disincentives using authorities under applicable federal
law, as the Secretary sets forth through notice and comment rulemaking.
In the ONC 21st Century Cures Act proposed rule, a request for
information regarding disincentives for health care providers was
included (84 FR 7553).
Comment: Some commenters requested additional information on the
proposed information blocking indicator. A few of these commenters
requested additional information on the attestation requirements for
clinicians and groups participating in other programs, such as Medicare
Advantage. Several commenters requested additional guidance on
exceptions to the attestations. Another commenter requested more
information on the implications for clinicians and groups who leave the
attestation statements blank and do not attest ``yes'' or ``no.''
Several commenters questioned how clinicians' responses to the three
attestation statements would be verified for accuracy.
Response: The three attestation statements are required under the
MIPS, which is a Medicare FFS program. We note that 42 CFR 414.1310(b)
and (c) provide that Qualifying APM Participants (QPs) and Partial QPs
who do not report on applicable measures and activities that are
required to be reported under MIPS for any given performance period in
a year are excluded from this definition at 42 CFR 414.1305 of a MIPS
eligible clinician per the statutory exclusions defined in section
1848(q)(1)(C)(ii) and (v) of the Act. Therefore, the prevention of
information blocking indicator would be applicable only to MIPS
eligible clinicians and groups under Medicare FFS and not to other
programs, such as MA. Under MIPS, the attestation statements are
required for all eligible clinicians under the Promoting
Interoperability performance category of MIPS, as specified at 42 CFR
414.1375(b)(3)(ii) (81 FR 77035). If the attestation statements are
left blank, that is, a ``yes'' or ``no'' response is not submitted, the
attestations would be considered incomplete and the clinician or group
would not receive a Promoting Interoperability performance category
score. In this situation, we would not have an affirmative or negative
response to the three attestation statements from the clinician or
group, and we would not have enough information to determine whether
the clinician or group is knowingly and willfully information blocking.
Regarding exceptions to the attestation requirements, under 42 CFR
414.1380(c)(2) the Promoting Interoperability performance category may
be reweighted to zero percent of the final score for a MIPS eligible
clinician in certain circumstances, and clinicians who receive
reweighting would not have to submit data for the Promoting
Interoperability performance category, including their responses to the
attestation statements. Regarding verification of clinicians'
attestation statements, we note that we finalized in prior rulemaking
that we will perform ongoing monitoring of MIPS eligible clinicians and
groups on an ongoing basis for data validation, auditing, program
integrity issues, and instances of non-compliance with MIPS
requirements. If a MIPS eligible clinician or group is found to have
submitted inaccurate data for MIPS, we finalized that we would reopen
and revise the determination in accordance with the rules set forth at
42 CFR 405.980 through 405.986 (81 FR 77362).
Final Action: After consideration of the comments received, and for
the reasons outlined in our responses to these comments, we are
finalizing this policy as proposed. Specifically, we are finalizing to
include an indicator on Physician Compare for the eligible clinicians
and groups that submit a ``no'' response to any of the three prevention
of information blocking attestation statements for MIPS under 42 CFR
414.1375(b)(3)(ii)(A) through (C), as proposed. In the event that these
statements are left blank, that is, a ``yes''
[[Page 25578]]
or a ``no'' response is not submitted, the attestations will be
considered incomplete, and we will not include an indicator on
Physician Compare. We will post this indicator on Physician Compare,
either on the profile pages or in the downloadable database, as
feasible and appropriate, starting with the 2019 performance period
data available for public reporting starting in late 2020.
C. Public Reporting and Prevention of Information Blocking for Eligible
Hospitals and Critical Access Hospitals (CAHs)
Section 1886(n)(4)(B) of the Act requires the Secretary to post in
an easily understandable format a list of the names and other relevant
data, as determined appropriate by the Secretary, of eligible hospitals
and CAHs who are meaningful EHR users under the Medicare FFS program,
on a CMS website. In addition, that section requires the Secretary to
ensure that an eligible hospital or CAH has the opportunity to review
the other relevant data that are to be made public with respect to the
eligible hospital or CAH prior to such data being made public. We noted
in the CMS Interoperability and Patient Access proposed rule (84 FR
7647) that we believed certain information related to the prevention of
information blocking attestation statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3) would constitute other relevant data
under section 1886(n)(4)(B) of the Act. Specifically, we referred to
the three prevention of information blocking attestation statements
under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) to which eligible
hospitals and CAHs must attest for purposes of the Promoting
Interoperability Program. As part of successfully demonstrating that an
eligible hospital or CAH is a meaningful EHR user for purposes of the
Promoting Interoperability Program, the eligible hospital or CAH must
submit an attestation response of ``yes'' for each of these statements.
For more information about these statements, we referred readers to the
preamble discussion in the CY 2017 Quality Payment Program final rule
(81 FR 77028 through 77035).
We noted in the CMS Interoperability and Patient Access proposed
rule (84 FR 7647) that we believed it would be relevant to the public
to know if eligible hospitals and CAHs have attested negatively to the
statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) as it could
indicate that they are knowingly and unreasonably interfering with the
exchange or use of electronic health information in ways that limit its
availability and use to improve health care. As we stated in the CY
2017 Quality Payment Program final rule, we believed that addressing
issues related to information blocking would require additional and
more comprehensive measures (81 FR 77029). In addition, publicly
posting this information would reinforce our commitment to focus on
increased interoperability and the appropriate exchange of health
information. We proposed to post information on a CMS website available
to the public indicating that an eligible hospital or CAH attesting
under the Medicare FFS Promoting Interoperability Program submitted a
``no'' response to any of the three statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3). In the event that these statements
are left blank, that is, a ``yes'' or a ``no'' response is not
submitted, we proposed the attestations would be considered incomplete,
and we would not post any information related to these attestation
statements for that hospital or CAH. We proposed to post this
information starting with the attestations for the EHR reporting period
in 2019, and we expected the information would be posted in late 2020.
In accordance with section 1886(n)(4)(B) of the Act, we proposed to
establish a process for each eligible hospital and CAH to review the
information related to their specific prevention of information
blocking attestation statements before it is publicly posted on a CMS
website. Specifically, for each program year, we proposed a 30-day
preview period for an eligible hospital or CAH to review this
information before it is publicly posted. During the 30-day preview
period, we proposed that all of the information that we would publicly
post would be available for the eligible hospital or CAH to review, and
we would consider making changes to the information on a case-by-case
basis (for example, in the event the eligible hospital or CAH
identifies an error, and we subsequently determine that the information
is not accurate). Additional information on the review process would be
provided outside of the rulemaking process through the usual
communication channels for the program.
We summarize the public comments we received on this topic and
provide our responses.
Comment: Many commenters indicated their strong support for this
proposal and suggested that we finalize the proposal, as commenters
believe it is necessary in building an interoperable health system. One
commenter believes that maintaining accountability and enforcing
penalties is critical to maintaining individual health and safety.
Another commenter agreed, stating that information blocking is
detrimental to the health, safety, and welfare of patients. Many
commenters indicated that information blocking should not be tolerated
for competitive or financial reasons, further indicating that consumers
and stakeholders should be made aware of those who participate in
information blocking practices, as this transparency can prevent
potential medical errors and improve the overall quality of care.
Response: We thank commenters for their support for the proposal.
We agree with the commenters and believe that the proposed policy would
be both appropriate and effective in reinforcing our commitment to
focus on increasing interoperability and the appropriate exchange of
health information. Knowingly or willfully preventing, avoiding, or
withholding information limits interoperability and prevents the
sharing of important health information.
Comment: Many commenters indicated support for the promotion of
health information exchange and the prevention of information blocking,
generally, but expressed several concerns about the implementation of
this proposal. A couple of commenters were concerned that there is not
enough time to develop the policies and procedures needed to streamline
the proposed process, and in response, suggested building in a period
of non-enforcement (a practice period without posting any information
publicly). Several commenters expressed concern that there will not be
an opportunity to dispute information prior to publication, and
requested including a guarantee of the proposed 30-day preview period
prior to the publication of certain information on a CMS website.
Finally, commenters had concerns about how policies related to
information blocking and changes to the 2015 Edition of certified
health IT proposed in ONC's 21st Century Cures Act proposed rule may
impact the prevention of information blocking attestations under the
Promoting Interoperability Program.
Response: We appreciate the commenters' concerns and suggestions.
We are finalizing the proposal to post this information starting with
the attestations for the EHR reporting period in 2019, and we are
targeting for this information to be posted in late 2020. Although we
will not have a period of non-enforcement (postponing posting of
information publicly), we are building in a 30-day preview period
during which any discrepancies or concerns may be addressed on a case-
by-case
[[Page 25579]]
basis prior to posting. Additional information on the preview period
will be provided outside of the rulemaking process through the usual
communication channels for the program. With regard to ONC's 21st
Century Cures Act rule, the prevention of information blocking
attestation statements under the Promoting Interoperability Program are
not affected by ONC's final rule policies and remain unchanged.
Comment: A number of commenters supported the prevention of
information blocking, but had concerns about the additional burden this
proposal may add. One commenter requested reassurance that this process
will not increase burden, while a few other commenters shared concerns
that this process will increase burden.
Response: We appreciate the commenters' concerns. As eligible
hospitals and CAHs are already required to respond to these three
attestation statements under the Promoting Interoperability Program, we
do not believe this proposal would require additional reporting effort,
or thereby increase burden. We do not believe the 30-day preview period
would increase burden as it will be an opportunity for eligible
hospitals and CAHs to ensure the accuracy of the information that will
be posted publicly, should they choose to take advantage of this
opportunity.
Comment: Many commenters stated that there should be an audit or
spot check process to validate the responses provided to the three
attestation statements. Commenters indicated concern that those who
knowingly participate in information blocking practices will answer
`yes' to the three attestation statements simply to complete the
question/answer sequencing in the reporting system. Further, commenters
expressed concern regarding how easy it could be for their peers to
respond dishonestly, and requested more stringent auditing practices
from CMS. A number of commenters requested additional information on
how a ``blank'' response would be treated for purposes of this
proposal; one commenter believed that a ``blank'' should be considered
a ``no'', and another commenter believed that a ``blank'' should simply
be considered as a ``blank.''
Response: We appreciate the commenters' concerns. We do not have a
specific auditing practice in place for these specific attestation
statements. Instead, all eligible hospitals and CAHs are required to
submit responses to the attestation statements under the Promoting
Interoperability Program and must respond accurately, as any eligible
hospital or CAH participating in the Promoting Interoperability Program
may be subject to an audit. In the event that an eligible hospital or
CAH leaves a ``blank'' response to an attestation statement, where a
``yes'' or a ``no'' response is not submitted, the response would be
considered incomplete, and no information would be posted related to
these attestation statements at this time.
Comment: Many commenters supported the effort to prevent
information blocking, though several believed that posting certain
information on a CMS website of those who attest `no' to the prevention
of information blocking statements may not strongly impact the issue.
Of the reasons given, one commenter remained agnostic on whether such a
policy would have tangible success in deterring information blocking,
several commenters stated that the information posted on a CMS website
will have little meaning to consumers, and others believed that this
process would not promote interoperability nor would it improve patient
access to information.
Response: We appreciate all of the commenters' concerns. As
discussed in the CY 2017 Quality Payment Program Final Rule (81 FR
77029), the act of information blocking is a systemic problem that
Congress has expressed concerns about. Growing evidence has established
that there is a strong incentive for health care providers to
unreasonably interfere with the exchange of health information. We
believe that publicly posting certain information on a CMS website is
one valuable tool in our continued effort to deter these information
blocking practices.
As patients gain access to more data, they become more empowered
and more informed decision makers. Knowing if a physician may be
information blocking could influence their decision to see that
physician. In addition, knowing patients can see this information may
deter physicians from engaging in this behavior. For these reasons, we
do believe that this effort will have an impact and be meaningful to
consumers. We do also believe that this policy will promote
interoperability and improve patient access to information. With
patients becoming more empowered, this drives health care providers to
move toward information sharing rather than information blocking, which
directly leads to improved patient access to information.
Comment: A couple commenters suggested moving away from posting
public information, and instead focusing on creating positive incentive
programs, enhancing guidance, providing more education, and fostering
change through encouraging the prevention of information blocking. Some
commenters agreed with the approach, but believed CMS could develop
more concrete measures that would have a stronger justification for
posting information on a CMS website versus using the three attestation
statements.
Response: Thank you for these comments and suggestions. To the
extent that the commenters are requesting that we create positive
incentive programs that include incentive payments to eligible
hospitals and CAHs, we note that we can only do so to the extent
authorized by law. We will take into consideration the suggestions for
enhancing prevention of information blocking guidance, providing more
education, and fostering change through encouragement in potential
future rulemaking.
Comment: A few commenters were in favor of posting certain
information on eligible hospitals and/or CAHs that provide a ``no''
response to the prevention of information blocking attestation
statements, but have requested additional ways to discourage this
practice. Commenters requested that those who are knowingly and
willfully blocking the transfer of information also be fined, per
instance or per patient, as a way of disincentivizing this practice. A
couple commenters suggested strengthening this provision by
establishing an easy way for stakeholders to report potential
information blocking activities.
Response: We appreciate the commenters' suggestions regarding
additional ways to discourage information blocking. We refer commenters
to section 3022(b)(2)(B) of the PHSA, which provides that any health
care provider determined by the Office of the Inspector General (OIG)
to have committed information blocking shall be referred to the
appropriate agency to be subject to appropriate disincentives using
authorities under applicable federal law, as the Secretary sets forth
through notice and comment rulemaking. Health care providers would also
be subject to the separate information blocking regulations proposed by
ONC for HHS adoption at 45 CFR part 171 (84 FR 7601 through 7605).
Further, we note that ONC's 21st Century Cures Act proposed rule
included a request for information regarding disincentives for health
care providers (84 FR 7553).
Comment: Many commenters, while in agreement with publicly posting
certain information related to
[[Page 25580]]
information blocking, had concerns that eligible hospitals and CAHs are
being held accountable for the practices of health IT vendors. Many
commenters were concerned that vendors are restricting the transfer of
data by data embargoing, actively blocking, and refusing or prohibiting
the transfer of data. Further, there were concerns that vendors are
requiring complex programs, the purchase of many costly programs, and
requiring excessive fees to conduct data transfer. Last, several
commenters requested that vendors be penalized equally, and in the same
manner, as eligible hospitals and CAHs.
Response: We appreciate the commenters' support for the proposal,
and we also appreciate their concerns. We emphasize that the
information blocking provision (section 4004 of the Cures Act) applies
to health IT developers of certified health IT. Section 3022(a)(1) of
the PHSA, in defining information blocking, refers to four classes of
individuals and entities that may engage in information blocking and
which include: Health care providers, health IT developers of certified
health IT, networks, and exchanges. In the ONC 21st Century Cures Act
proposed rule, ONC proposed to adopt definitions of these terms to
provide clarity regarding the types of individuals and entities to whom
the information blocking provision applies (84 FR 7601 through 7602).
Regarding penalties, section 4004 of the Cures Act identifies
potential penalties and disincentives for information blocking. Health
IT developers, health information networks, and health information
exchanges that the Inspector General, following an investigation,
determines to have committed information blocking shall be subject to a
civil monetary penalty determined by the Secretary for all such
violations identified through such investigation, which may not exceed
$1,000,000 per violation. Such determination shall take into account
factors such as the nature and extent of the information blocking and
harm resulting from such information blocking, including, where
applicable, the number of patients affected, the number of providers
affected, and the number of days the information blocking persisted.
Health care providers determined by the Inspector General to have
committed information blocking shall be referred to the appropriate
agency to be subject to appropriate disincentives using authorities
under applicable Federal law, as the Secretary sets forth through
notice and comment rulemaking.
Comment: One commenter suggested a collaboration between CMS, ONC,
and OIG in order to address information blocking together, to combat
information blocking consistently and from all angles.
Response: We appreciate the commenter's suggestion, and note that
CMS, ONC, and OIG are consistently working together on issues such as
information blocking so that our policies are complementary and work
together to address the issue.
Final Action: After consideration of the comments received, and for
the reasons outlined in our response to these comments and in the CMS
Interoperability and Patient Access proposed rule, we are finalizing
this policy as proposed. We will include information on a CMS website
available to the public indicating that an eligible hospital or CAH
attesting under the Medicare FFS Promoting Interoperability Program
submitted a ``no'' response to any of the three prevention of
information blocking attestation statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3). We will post this information
starting with the attestations for the EHR reporting period in 2019,
and expect the information will be posted in late 2020. In the event
that an eligible hospital or CAH leaves a ``blank'' response to an
attestation statement, where a ``yes'' or a ``no'' response is not
submitted, the attestations will be considered incomplete, and no
information will be posted related to these attestation statements. We
will establish a process for each eligible hospital and CAH to review
the information related to their specific prevention of information
blocking attestation statements before it is publicly posted on the CMS
website. For each program year, we will have a 30-day preview period
for an eligible hospital or CAH to review this information before it is
publicly posted. During the 30-day preview period, all of the
information that we will publicly post will be available for the
eligible hospital or CAH to review, and we will consider making changes
to the information on a case-by-case basis.
IX. Provider Digital Contact Information Provisions, and Analysis of
and Responses to Public Comments
A. Background
Congress required the Secretary to create a provider digital
contact information index in section 4003 of the Cures Act. This index
must include all individual health care providers and health care
facilities, or practices, in order to facilitate a comprehensive and
open exchange of patient health information. Congress gave the
Secretary the authority to use an existing index or to facilitate the
creation of a new index. In comments received on the FY 2019 IPPS
proposed rule RFI, there was strong support for a single, public
directory of provider digital contact information. Commenters noted
that digital communication could improve interoperability by
facilitating efficient exchange of patient records, eliminating the
burden of working with scanned paper documents, and ultimately
enhancing care coordination.
To ensure the index is accessible to all clinicians and facilities,
we updated the National Plan and Provider Enumeration System (NPPES)
\52\ to be able to capture digital contact information for both
individuals and facilities. It is important to note that the
aforementioned updates to the NPPES entailed the addition of two
additional data fields. However, due to an administrative oversight,
the data elements which allow for the digital capture of contact
information are not OMB approved. CMS acknowledges this violation of
the Paperwork Reduction Act of 1995 (PRA) and is currently working to
remediate the issue by creating a new PRA package and thereby come into
compliance with the PRA. Prior to its submission for OMB approval, the
new information collection request will be made available for public
review and comment as required by the PRA.
---------------------------------------------------------------------------
\52\ The NPPES website at https://nppes.cms.hhs.gov/.
---------------------------------------------------------------------------
NPPES currently supplies National Provider Identifier (NPI) numbers
to health care providers (both individuals and facilities), maintains
their NPI record, and publishes the records online. The Secretary
adopted the NPI as the HIPAA administrative simplification standard
identifier for health care providers (69 FR 3434). HIPAA covered
entities, including health care providers, health plans, and health
care clearinghouses, must use the NPI in HIPAA transactions. All health
care providers that transmit health information in electronic form in
connection with a HIPAA transaction must obtain an NPI.
Health care providers are required to communicate to the NPPES any
information that has changed within 30 days of the change (45 CFR
162.410(a)(4)). We review NPPES to ensure a provider has a valid NPI as
part of the Medicare enrollment process, as well as the revalidation
process, which occurs every 3 to 5 years depending on the provider or
supplier type.
[[Page 25581]]
Information in NPPES is publicly accessible via both an online
search option and a downloadable database option. As a result, adding
digital contact information to this existing index is an efficient and
effective way to meet the Congressional requirement to establish a
digital contact information index and to promote the sharing of
information.
As of June 2018, NPPES has been updated to include the capability
to capture one or more pieces of digital contact information that can
be used to facilitate secure sharing of health information. For
instance, providers can submit a Direct address, which functions
similar to a regular email address, but includes additional security
measures to ensure that messages are only accessible to the intended
recipient in order to keep the information confidential and secure.
``Direct'' is a technical standard for exchanging health information.
Direct addresses are available from a variety of sources, including EHR
vendors, State Health Information Exchange entities, regional and local
Health Information Exchange entities, as well as private service
providers offering Direct exchange capabilities called Health
Information Service Providers (HISPs) (https://www.healthit.gov/sites/default/files/directbasicsforprovidersqa_05092014.pdf). NPPES can also
capture information about a wide range of other types of endpoints that
providers can use to facilitate secure exchange of health information,
for instance a FHIR server URL or query endpoint associated with a
health information exchange. We strongly encourage the inclusion of
this FHIR endpoint information in NPPES in support of the Patient
Access API policy discussed in section III. of this final rule and the
Provider Directory API policy discussed in section IV. of this final
rule. Using NPPES as one way to make these endpoints publicly known
will significantly support interoperability throughout the health care
system.
In addition, NPPES can now maintain information about the type of
contact information providers and organizations are associated with,
along with the preferred uses for each address. Each provider in NPPES
can maintain their own unique information or associate themselves with
information shared among a group of providers. Finally, in March 2019,
NPPES added a public API which can be used to obtain the digital
contact information stored in the database. Although NPPES is now
better equipped to maintain provider digital contact information, many
providers have not submitted this information. In the 2015 final rule,
``Medicare and Medicaid Programs; Electronic Health Record Incentive
Program-Stage 3 and Modifications to Meaningful Use in 2015 Through
2017'' (80 FR 62901), we finalized a policy to collect information in
NPPES about the electronic addresses of participants in the EHR
Incentive Program (specifically, a Direct address and/or other
``electronic service information'' as available). However, this policy
was not fully implemented at the time, in part due to the limitations
of the NPPES system which have since been addressed. As a result, many
providers have not yet added their digital contact information to NPPES
and digital contact information is frequently out of date.
In light of these updates to the NPPES system, all individual
health care providers and facilities can take immediate action to
update their NPPES record online to add digital contact information.
This simple step will significantly improve interoperability by making
valuable contact information easily accessible. For those providers who
continue to rely on the use of cumbersome, fax-based modes of sharing
information, we hope that greater availability of digital contact
information will help to reduce barriers to electronic communication
with a wider set of providers with whom they share patients.
Ubiquitous, public availability of digital contact information for all
providers is a crucial step towards eliminating the use of fax machines
for the exchange of health information. We urged all providers to take
advantage of this resource to implement Congress' requirement that the
Secretary establish a digital contact information index.
B. Public Reporting of Missing Digital Contact Information
Entities seeking to engage in electronic health information
exchange need accurate information about the electronic addresses (for
example, Direct address, FHIR server URL, query endpoint, or other
digital contact information) of potential exchange partners. A common
directory of the electronic addresses of health care providers and
organizations could enhance interoperability and information exchange
by providing a resource where users can obtain information about how to
securely transmit electronic health information to a provider.
We proposed to increase the number of providers with valid and
current digital contact information available through NPPES by publicly
reporting the names and NPIs of those providers who do not yet have
their digital contact information included in the NPPES system. We
proposed to begin this public reporting in the second half of 2020, to
allow individuals and facilities time to review their records in NPPES
and update the system with appropriate digital contact information. We
also requested comment from stakeholders on the most appropriate way to
pursue this public reporting initiative, including where these names
should be posted, with what frequency, and any other information
stakeholders believed would be helpful.
We noted that we believed this information would be extremely
valuable to facilitate interoperability, and we appreciated Congress'
leadership in requiring the establishment of this directory. We
requested stakeholder comment on additional possible enforcement
authorities to ensure that individuals and facilities make their
digital contact information publicly available through NPPES. For
example, we questioned if Medicare reporting programs, such as MIPS,
should require eligible clinicians to update their NPPES data with
their digital contact information? Should CMS require this information
to be included as part of the Medicare enrollment and revalidation
process? How can CMS work with states to promote adding information to
the directory through state Medicaid programs and CHIP? Should CMS
require providers to submit digital contact information as part of
program integrity processes related to prior authorization and
submission of medical record documentation? We noted that we would
review comments for possible consideration in future rulemaking on
these questions.
We summarize the public comments we received on this topic and
provide our responses.
Comment: Many stakeholders shared our goal of improving the
accuracy and completeness of data in the NPPES.
Response: We thank commenters for their support and are finalizing
this policy as proposed.
Comment: Many commenters, while supporting the ultimate goal of the
proposal, noted doubts about whether the proposal would be effective at
increasing the accuracy and completeness of digital contact information
in NPPES. Commenters believed that a public reporting mechanism would
not serve as a meaningful deterrent to providers leaving their
information blank. One commenter stated that they believed, even with
the implementation of this proposal, high rates of inaccuracies would
persist in NPPES, and
[[Page 25582]]
stakeholders would continue to rely on internal sources of information.
Several commenters stated that, given the likelihood that this proposal
would not result in meaningful improvements, this proposal would
represent unnecessary administrative burden for providers.
Response: We thank commenters for their feedback on the potential
effectiveness of this proposal. While we believe that this proposal is
an important initial step toward increasing the accuracy of information
in NPPES, we appreciate that this proposal may not be sufficient to
fully realize the goal of NPPES serving as a comprehensive index of
provider digital contact information. To this end, we requested comment
on other programs that CMS could leverage to improve the completeness
and accuracy of information in NPPES. The responses to this comment
solicitation are discussed in more detail below.
Comment: Many commenters recommended that, instead of pursuing a
policy based on ``public shaming,'' it would be more effective for CMS
to consider incentive-based policies for updating their digital contact
information in NPPES.
Response: We thank commenters for their recommendations. While we
believe the proposed policy is an important step toward increasing the
completeness and accuracy of information in NPPES, we believe that
other policy initiatives using incentives may be effective as well,
such as leveraging opportunities under the MIPS program, and we will
consider these approaches for potential inclusion in future rulemaking.
Comment: In the proposed rule, CMS requested comment on additional
possible enforcement authorities to ensure that individuals and
facilities make their digital contact information publicly available
through NPPES. Many commenters supported the use of other authorities
to increase the accuracy and completeness of digital contact
information in NPPES, stating that they believe these authorities were
more likely to be effective than the proposed policy for publicly
reporting the names and NPIs of those providers that have not included
digital contact information in NPPES.
For instance, many commenters believed that including this
requirement in the MIPS program would be a more effective strategy for
achieving the goals of the policy. Commenters believed this would be
more effective due to the incentives available through the MIPS
program. Commenters also believed that use of the MIPS program would be
more effective since the Promoting Interoperability category of MIPS
already includes requirements to electronically exchange health
information, and the goal of increasing availability of digital contact
information would align with those features of the program. Commenters
also believed that tying this policy to the MIPS program would help to
ensure annual updates of digital contact information as part of
required MIPS data submissions.
Several commenters also supported the use of the Medicare
enrollment or revalidation process and the use of program integrity
processes as ways to promote updating of digital contact information in
NPPES.
Response: We thank commenters for their input on additional
enforcement mechanisms. We will take these comments under consideration
as we consider potential future rulemaking or operational changes to
these programs that are consistent with each program's statutory
authority.
Comment: Many commenters suggested that CMS provide additional
education and guidance about the benefits of adding their digital
contact information to NPPES. These commenters recommended that CMS
engage in public education as a necessary step before proceeding with
public reporting in order to build awareness among providers of the
importance of updating this information. For instance, one commenter
noted that many hospital-based physicians are not aware of their
digital contact information, currently relying on their institution's
informatics division to manage this data. Others suggested that
providers are not aware of the new functionality in NPPES allowing for
submission of digital contact information and that education will be
needed to familiarize providers with this feature. Commenters
recommended that public education initiatives be targeted at those
providers least likely to be familiar with the new functionality, and
that CMS should work with specialty societies and other provider
representatives to ensure education reaches a wide variety of
providers. Some commenters also stated that a public education
initiative alone would be a more appropriate alternative to public
reporting of providers' names and NPIs.
Response: We appreciate commenters' recommendations around the need
for public education. Since updating the functionality in NPPES
starting in 2018, we have taken steps to familiarize the provider
community with these updates and plan to continue and expand this
outreach. We agree that education efforts will be important to ensure
that providers are aware of their responsibilities and that they may be
at risk of having their names and NPIs publicly reported if they do not
update their digital contact information in NPPES in a timely manner.
While recognizing the importance of public education, we also believe
that more aggressive steps are needed to accelerate the accuracy of
completeness of information within NPPES, therefore we are finalizing
the policy to publicly report the names and NPIs of providers that do
not include digital contact information in NPPES.
Comment: CMS proposed to begin public reporting in the second half
of 2020. A number of commenters suggested that CMS delay this timeframe
to allow providers more time to be made aware of the policy, review
their NPPES record, and add missing information. One commenter believed
that this timeline was not consistent with the time that would be
required for CMS to reach small providers with information about the
new policy, and recommended a delay of at least an additional 12 months
before public reporting begins.
Response: We appreciate commenters' concerns and suggestions
regarding the appropriate timeframe for public reporting under this
proposal. However, we believe that the proposed timeline allows
sufficient time for outreach and education to make providers aware of
the requirement. We are therefore finalizing this timeframe as
proposed.
Comment: Many commenters expressed concerns about the accuracy of
information in NPPES, stating that inaccurate information imposes a
burden on both providers and consumers who may try to collect and use
this information only to find out that it is incorrect. These
commenters noted inaccurate contact information also poses a problem
for providers who are concerned with sending protected health
information to the wrong recipient. One commenter stated that these
challenges raise questions about whether a public file is appropriate
to serve as the basis for increasing interoperability across provider
systems.
Commenters suggested steps CMS could take to improve the accuracy
of information in NPPES. One commenter suggested that CMS establish a
requirement that providers update their information within a set time
period. Another commenter suggested that NPPES post the date that
information associated with a given NPI was last updated so that
individuals reviewing the database could assess its accuracy. Several
commenters urged CMS to
[[Page 25583]]
conduct direct outreach to providers to confirm their information, or
to validate provider information with other sources, such as state
licensing boards, in order to increase accuracy.
Response: We appreciate commenters' concerns about the accuracy of
provider contact information within NPPES. The ``Last Updated'' date is
posted on the ``NPI View'' page for records in the public NPPES NPI
Registry. It should also be noted that providers are required to update
information included in NPPES within 30 days of a change (45 CFR
162.410(a)(4)). However, we understand from commenters that in practice
these updates often do not occur, contributing to historical challenges
with the accuracy of NPPES data.
We appreciate commenters' suggestions for ways to improve the
accuracy of data within NPPES, and we will take these suggestions into
consideration.
Comment: Several commenters noted that providers who have not
participated in the Promoting Interoperability Program (formerly the
EHR Incentive Programs) are more likely to not have digital contact
information available than those that have participated and received
incentives for adoption of health information. Commenters stated that
these providers would be at a disadvantage under the proposed policy,
and that identifying these providers as noncompliant through a public
reporting mechanism would be unfair. Commenters stated that this group
likely includes smaller practices, rural clinicians, hospital-based
clinicians, and clinicians employed at a variety of settings which were
not eligible for EHR incentives, such as rehabilitation centers.
Response: We appreciate commenters' concerns regarding those
clinicians that are less likely to have existing digital contact
information. While we understand that it may take more time for these
clinicians to obtain and submit digital contact information to NPPES,
we believe that the timeframe for implementing this proposal will
provide sufficient notice to clinicians. We also believe that obtaining
digital contact information, such as a Direct address, is now widely
available to clinicians, including those who do not have certified EHR
systems. Accordingly, we believe that these providers will be able to
obtain digital contact information and add it to their NPPES record
with relatively minimal burden.
Comment: Many commenters suggested that CMS establish a process for
offering providers a chance to review their information and correct any
issues prior to the implementation of public reporting. Commenters
stated that CMS should issue communication to providers informing them
of the status of their digital contact information, and that
communications should include mechanisms which allow the provider to
make corrections. One commenter recommended that CMS institute a 60-day
review period prior to public reporting similar to the review period
established for data included on the Physician Compare website.
Response: We appreciate commenters' suggestions regarding
opportunities for clinicians to review their information prior to the
implementation of this public reporting policy. We have already
implemented multiple methods for providers to review their information
allowing them to correct any issues with their NPPES record. Providers
can review their information using the NPPES NPI Registry (https://npiregistry.cms.hhs.gov/), the NPPES NPI Registry API (https://npiregistry.cms.hhs.gov/registry/help-api), or the NPPES Data
Dissemination file (https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/NationalProvIdentStand/DataDissemination). Each source currently contains all the information
that will allow providers to determine the correctness of their
information. As discussed above, we will also engage in continued
public education efforts to ensure providers are aware of the benefits
of including digital contact information in NPPES, as well as the
associated public reporting policy.
Comment: Several commenters requested additional information about
what kind of digital contact information would satisfy this
requirement. One commenter recommended that providers should be able to
specify other digital endpoints besides a Direct address. Another
commenter requested clarity on whether the digital fax numbers would
qualify as digital contact information.
Response: As discussed in the proposed rule, NPPES is able to
capture a variety of different digital endpoints. A digital fax number
is not considered a digital endpoint for the purposes of this proposal.
For more information on the digital contact information which can be
added to NPPES, see https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html.
Comment: Several commenters recommended that CMS partner with other
centralized authorities that collect provider information. Commenters
stated that relying on providers alone to update their information will
not provide the levels of accuracy necessary for other providers to
utilize NPPES for routine exchange of electronic health information.
Commenters noted that today, directory services that employ appropriate
identify proofing processes and other means for ensuring records are
up-to-date are much more likely to possess accurate information than
NPPES, and CMS should seek to improve the quality of NPPES by working
with these partners. Commenters believed that by working with these
entities, CMS could greatly reduce provider burden associated with
entering information into and updating information in NPPES.
Response: We appreciate commenters' input regarding other
strategies to improve the accuracy of the digital contact information
within NPPES.
Comment: Several commenters requested additional guidance on how
the public reporting mechanism would operate. One commenter sought
information on where the names would be publicly reported. Another
commenter questioned how CMS would address public reporting of
providers that have an NPI but do not have active practice locations
where they are providing services under Medicare or engaging in
communication with patients.
Response: We thank commenters for these questions. Following the
publication of the final rule, we will release additional information
around the public reporting mechanism including where we intend to
publish the names and NPIs of providers that do not have digital
contact information in NPPES, as well as information about whether
certain providers would be exempt from public reporting.
Comment: One commenter questioned how providers would be expected
to know their digital contact information as this information may not
be visible to providers in many EHR systems.
Response: We encourage providers, especially clinicians, to work
with health IT administrators in their organization or directly with
their health IT vendor if they are unclear on where their digital
contact information can be found. We also note that NPPES now provides
for bulk uploading of information to multiple NPI records, and
encourage clinicians to work with health IT administrators in their
organization to develop streamlined processes for updating this
information in a way that imposes minimal burden on clinicians.
Comment: Several commenters noted the Provider Enrollment, Chain,
and Ownership System (PECOS) system
[[Page 25584]]
would be the most appropriate location for storing digital contact
information.
Response: While we understand the interest in using PECOS as the
location for storing digital contact information, we are not
considering this as an option at this time. PECOS collects information
specific to provider and supplier enrollment in the Medicare program
and the system is limited to the fields on the CMS 855 Enrollment
forms. Any other data outside of this is optional. There are also many
operational and systematic issues that prevent PECOS from being
utilized to implement the digital contact information requirement.
Comment: Several commenters raised questions about what entities
would have access to the information in NPPES. One commenter stated
that any entity should be able to gain access to NPPES in order to
advance interoperability. Another noted that making digital endpoints
publicly accessible via an API that may be accessible to third parties
could pose a risk to the security of protected health information
available through those APIs, and recommended that CMS make this
information available to other entities only if the third-party entity
requests access from the API owner.
Response: NPPES already furnishes a public downloadable data
dissemination file as well as a public API that provides the public
information available in the NPI Registry. Both files are publicly
accessible. Please note that this proposal is not related to the
Patient Access API discussed in section III. of this final rule that
can include patient protected health information.
Comment: A number of commenters requested additional information on
issues related to NPPES functionality, and sought guidance on how to
enter digital contact information. For instance, numerous commenters
believed that the NPPES does not allow for a provider to enter
information for multiple practice and billing locations. Several
commenters sought information about whether a provider could enter
multiple digital endpoints, for instance if they employ different
endpoints for different types of communication. One commenter requested
information on whether a provider could enter digital contact
information for his or her employer, rather than individual
information.
Response: For more information on how information is captured in
NPPES, we encourage commenters to review information available on the
NPPES website at https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html.
Comment: Several commenters suggested that CMS develop a digital
contact information interoperability standard for facilitating
efficient exchange of patient records.
Response: We appreciate commenters' suggestions, and note that we
continue to collaborate with ONC, other federal partners, and industry
stakeholders, to develop more robust provider directory standards that
can support exchange of this information. We also direct commenters to
the discussion of the Provider Directory API in section IV. of this
final rule.
Final Action: After consideration of the comments received, and for
the reasons outlined in our response to these comments and in the CMS
Interoperability and Patient Access proposed rule, we are finalizing to
publicly report the names and NPIs of those providers who do not have
digital contact information included in the NPPES system beginning in
the second half of 2020 as proposed. Additionally, we will engage in
continued public education efforts to ensure providers are aware of the
benefits of including digital contact information in NPPES, including
FHIR API endpoints, and when and where this information will be posted.
X. Conditions of Participation for Hospitals and Critical Access
Hospitals (CAHs) Provisions, and Analysis of and Responses to Public
Comments
A. Background
As noted in the CMS Interoperability and Patient Access proposed
rule (84 FR 7649 through 7653), we appreciate the pathways Congress has
created for action on interoperability and have been working diligently
with ONC to implement them. In order to ensure broad stakeholder input
to inform the proposals, we published a Request for Information (RFI)
on interoperability in several proposed rules, including the FY 2019
IPPS proposed rule (83 FR 20550). Specifically, we published the RFI
entitled, ``Promoting Interoperability and Electronic Healthcare
Information Exchange Through Possible Revisions to the CMS Patient
Health and Safety Requirements for Hospitals and Other Medicare- and
Medicaid-Participating Providers and Suppliers.'' We requested
stakeholders' input on how we could use the CMS health and safety
standards that are required for providers and suppliers participating
in the Medicare and Medicaid programs (that is, the Conditions of
Participation (CoPs), Conditions for Coverage (CfCs), and Requirements
for long term care facilities) to further advance electronic exchange
of information that supports safe, effective transitions of care
between hospitals and community providers. Specifically, we requested
comment on revisions to the current CMS CoPs for hospitals such as:
Requiring that hospitals transferring medically necessary information
to another facility upon a patient transfer or discharge do so
electronically; requiring that hospitals electronically send required
discharge information to a community provider via electronic means if
possible and if a community provider can be identified; and requiring
that hospitals make certain information available to patients or a
specified third-party application (for example, required discharge
instructions) via electronic means if requested.
The RFI discussed several steps we have taken in recent years to
update and modernize the CoPs and other health and safety standards to
reflect current best practices for clinical care, especially in the
area of care coordination and discharge planning. For a complete
discussion of this work, see the proposed rule (84 FR 7649 through
7650).
In the September 30, 2019 Federal Register, we published a final
rule, ``Medicare and Medicaid Programs; Revisions to Requirements for
Discharge Planning'' (84 FR 51836) (``Discharge Planning final rule''),
that revises the discharge planning requirements that hospitals
(including psychiatric hospitals, long-term care hospitals, and
inpatient rehabilitation facilities), critical access hospitals (CAHs),
and home health agencies, must meet to participate in Medicare and
Medicaid programs. The rule supports CMS' interoperability efforts by
promoting the exchange of patient information between health care
settings, and by ensuring that a patient's necessary medical
information is transferred with the patient after discharge from a
hospital, CAH, or post-acute care services provider. By requiring that
all of the patient's necessary medical information, including his or
her post-discharge goals of care and treatment preferences, must be
documented in the patient's medical record and transferred along with
the patient at the time of discharge to an appropriate receiving health
care facility, such as a PAC service provider or agency, and to other
outpatient service providers and practitioners responsible for the
patient's follow-up or ancillary care, the rule aims to better prepare
patients and their caregivers to be active partners and advocates for
their health care and community support needs upon
[[Page 25585]]
discharge from the hospital or post-acute care setting.
While we finalized a broad requirement for sending necessary
medical information in accordance with all applicable laws, rather than
listing specific data elements (such as those explicitly aligned with
the data referenced as part of the Common Clinical Data Set (CCDS) that
was finalized in the 2015 final rule, ``Medicare and Medicaid Programs;
Electronic Health Record Incentive Program--Stage 3 and Modifications
to Meaningful Use in 2015 Through 2017'' (80 FR 62762), we also ensured
that the revisions to the CoPs did not conflict with the CCDS, or
future standards proposed for adoption for electronic exchange of
health information, specifically the USCDI. The discharge planning CoPs
do not bar providers from sending all additional appropriate medical
information regarding the patient's current course of illness and
treatment, post-discharge goals of care, and treatment preferences in
accordance with applicable laws. However, we note here that the
Discharge Planning final rule does not require hospitals, CAHs, and
HHAs to transfer the necessary patient medical information exclusively
by electronic means nor does it require that providers notify the
appropriate providers, suppliers, and practitioners receiving the
necessary medical information of the patient's discharge as we are now
requiring in this final rule.
Additionally, the Discharge Planning final rule further supports
interoperability and a patient's access to his or her own medical
records by updating the hospital Patient Rights CoP to now state that
the patient has the right to access his or her medical records in the
form and format requested (including in an electronic form or format
when such medical records are maintained electronically). Therefore,
the hospital CoPs now include an explicit requirement that, as a
condition of participation, hospitals must provide patients with access
to their medical records in an electronic format upon the patient's
request if the hospital has the capacity to do so.
In response to the RFI in the FY 2019 IPPS proposed rule, many
stakeholders supported our goals of increasing interoperability, and
acknowledged the important role that hospital settings play in
supporting care coordination. Stakeholders agreed that use of
electronic technology was an important factor in ensuring safe
transitions. Multiple stakeholders emphasized that electronic data
exchange between hospitals and physician offices, as well as with
hospices, HHAs, SNFs, and other post-acute care services providers, was
especially important during care transitions when maintaining access to
patient health information, including medication information, and is
extremely relevant to the patient's next phase of care. Additionally,
stakeholders noted that giving patients and their caregivers access to
important health information (such as discharge information along with
accurately reconciled lists of discharge medications) created a more
patient-centered health care system, and reduced the risk of errors and
hospital readmissions. But many stakeholders also expressed concerns
about implementing policy changes within the CoPs that might increase
the compliance burden on hospitals. However, several stakeholders also
strongly recommended that CMS add details to the CoPs, and require that
hospitals share not only medically necessary information with physician
offices, HHAs, and SNFs (such as pending tests and discharge
summaries), but also notifications of when patients were admitted to
the hospital as well as discharged or transferred from the hospital and
admitted to the care of applicable PAC services providers and
suppliers.
Given responses to the RFI, as well as previous rulemaking
activities, we sought to further expand CMS requirements for
interoperability within the hospital and CAH CoPs as part of the CMS
Interoperability and Patient Access proposed rule by focusing on
electronic patient event notifications. In addition, we noted that we
were committed to taking further steps to ensure that facilities that
are electronically capturing information are electronically exchanging
that information with providers who have the capacity to accept it.
Infrastructure supporting the exchange of electronic health
information across settings has matured substantially in recent years.
Research studies have increasingly found that health information
exchange interventions can affect positive outcomes in health care
quality and public health, in addition to more longstanding findings
around reductions in utilization and costs. A recent review of how
health information exchange interventions can improve cost and quality
outcomes identified a growing body of high-quality studies showing that
these interventions are associated with beneficial results.\53\ The
authors identified a number of studies demonstrating positive effects
on outcomes associated with better care coordination, such as
reductions in 30-day readmissions,54 55 56 and improved
medication reconciliation.\57\
---------------------------------------------------------------------------
\53\ Menachemi, N., Rahurkar, S., Harle, C.A., & Vest, J.R.
(2018). The benefits of health information exchange: An updated
systematic review. Journal of the American Medical Informatics
Association, 25(9), 1259-1265. doi: 10.1093/jamia/ocy035.
\54\ Yeaman, B., Ko, K., del Castillo, R. (2015). Care
transitions in long-term care and acute care: Health information
exchange and readmission rates. The Online Journal of Issues in
Nursing, 20(3). doi: 10.3912/OJIN.Vol20No03Man05.
\55\ Vest, J.R., Kern, L.M., Silver, M.D., & Kaushal, R. (2015).
The potential for community-based health information exchange
systems to reduce hospital readmissions. Journal of the American
Medical Informatics Association, 22(2), 435-442. doi: 10.1136/
amiajnl-2014-002760.
\56\ Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest, J.R. (2017).
Hospitalization event notifications and reductions in readmissions
of Medicare fee-for-service beneficiaries in the Bronx, New York.
Journal of the American Medical Informatics Association, 24(e1),
e150-e156. doi: 10.1093/jamia/ocw139.
\57\ Boockvar, K.S., Ho, W., Pruskowski, J., Dipalo, K.E., Wong,
J.J., Patel, J., . . . Hung, W. (2017). Effect of health information
exchange on recognition of medication discrepancies is interrupted
when data charges are introduced: Results of a cluster-randomized
controlled trial. Journal of the American Medical Informatics
Association, 24(6), 1095-1101. doi: 10.1093/jamia/ocx044.
---------------------------------------------------------------------------
Electronic patient event notifications from hospitals, or clinical
event notifications, are one type of health information exchange
intervention that has been increasingly recognized as an effective and
scalable tool for improving care coordination across settings,
especially for patients at discharge. This approach has been associated
with a reduction in readmissions following implementation of such
notifications.\58\ We noted that the evidence cited in this section to
support the use of innovative health information exchange interventions
and approaches, such as the patient event notifications that we
proposed to require, can be applied to various types of hospitals,
including psychiatric hospitals, as well as to CAHs, as discussed
below.
---------------------------------------------------------------------------
\58\ Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest, J.R. (2017).
Hospitalization event notifications and reductions in readmissions
of Medicare fee-for-service beneficiaries in the Bronx, New York.
Journal of the American Medical Informatics Association, 24(e1),
e150-e156. doi: 10.1093/jamia/ocw139.
---------------------------------------------------------------------------
Patient event notifications are automated, electronic
communications from the discharging provider to another facility, or to
another applicable community provider as identified by the patient
(such as a patient's primary care practitioner or practice group, post-
acute care services providers and suppliers, and other practitioners
and providers that need the notification for post-acute care
coordination, treatment, and/or quality improvement purposes),
[[Page 25586]]
which alerts the receiving provider that the patient has received care
at a different setting. Depending on the implementation, information
included with these notifications can range from conveying the
patient's name, other basic demographic information, and the sending
institution to a richer set of clinical data on the patient. Even with
a minimum set of information included, these notifications can help
ensure that a receiving provider, facility, or practitioner is aware
that the patient has received care elsewhere. The notification triggers
a receiving provider, facility, or practitioner to reach out to the
patient and deliver appropriate follow-up care in a timely manner. By
notifying the individuals and entities that need notification of the
patient's status for treatment, care coordination, or quality
improvement purposes, the notification can help to improve post-
discharge transitions and reduce the likelihood that a patient would
face complications from inadequate follow-up care.
In addition to their effectiveness in supporting care coordination,
virtually all EHR systems generate the basic messages commonly used to
support electronic patient event notifications. These notifications are
based on admission, discharge, and transfer (ADT) messages, a standard
message used within an EHR as the vehicle for communicating information
about key changes in a patient's status as they are tracked by the
system (more information about the current standard supporting these
messages is available at http://www.hl7.org/implement/standards/product_brief.cfm?product_id=144). As noted in the Interoperability
Standards Advisory (ISA) published by ONC, this messaging standard has
been widely adopted across the health care system (see https://www.healthit.gov/isa/sending-a-notification-a-patients-admission-discharge-andor-transfer-status-other-providers).
ADT messages provide each patient's personal or demographic
information (such as the patient's name, insurance, next of kin, and
attending physician), when that information has been updated, and also
indicate when an ADT status has changed. To create an electronic
patient event notification, a system can use the change in ADT status
to trigger a message to a receiving provider or to a health information
exchange system that can then route the message to the appropriate
provider. In addition to the basic demographic information contained in
the ADT message, some patient event notification implementations attach
more detailed information to the message regarding the patient's
clinical status and care received from the sending provider.
B. Provisions for Hospitals (42 CFR 482.24(d))
We proposed to revise the CoPs for Medicare- and Medicaid-
participating hospitals at 42 CFR 482.24 by adding a new standard at
paragraph (d), ``Electronic Notifications,'' that would require
hospitals to send electronic patient event notifications of a patient's
admission, discharge, and/or transfer to another health care facility
or to another community provider or practitioner. We proposed to
require hospitals to convey, at a minimum, the patient's basic personal
or demographic information, as well as the name of the sending
institution (that is, the hospital), and, if not prohibited by other
applicable law, the patient's diagnosis. In proposing that patient
event notifications sent by a hospital's medical records system include
diagnosis, where not prohibited by other applicable law, we requested
comment on the technical feasibility of this proposal, noting that we
recognize some existing ADT messages might not include diagnosis, as
well as the challenges in appropriately segmenting this information in
instances where the diagnosis may not be permitted for disclosure under
other applicable laws.
We also encouraged hospitals, as their systems and those of the
receiving providers allowed, to work with patients and their
practitioners to offer more robust patient information and clinical
data upon request in accordance with applicable law.
For a hospital that currently possesses an EHR system with the
capacity to generate the basic patient personal or demographic
information for electronic patient event notifications, we proposed
that compliance with the proposed standard within the Medical records
services CoP (42 CFR 482.24) would be determined by the hospital
demonstrating to the surveyor or accrediting organization that its
system: (1) Is fully operational and that it operates in accordance
with all state and federal statutes and regulations regarding the
exchange of patient health information; (2) utilizes the content
exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i);
(3) sends notifications that would have to include the minimum patient
health information (which, as noted above, would be the patient's name,
treating practitioner name, sending institution name, and, if not
prohibited by other applicable law, patient diagnosis); and (4) sends
notifications directly, or through an intermediary that facilitates
exchange of health information, and at the time of the patient's
admission to the hospital and either immediately prior to or at the
time of the patient's discharge and/or transfer from the hospital.
We proposed to limit this requirement to only those hospitals which
currently possess EHR systems with the technical capacity to generate
information for electronic patient event notifications as discussed
below, recognizing that not all Medicare- and Medicaid-participating
hospitals have been eligible for past programs promoting adoption of
EHR systems. We noted our goal in proposing the requirement was to
ensure that hospital EHR systems have a basic capacity to generate
messages that can be utilized for notifications by a wide range of
receiving providers, enabled by common standards. We believed that a
system that utilizes the ADT messaging standard, which is widely used
as the basis for implementing these notifications and other similar use
cases, would meet this goal by supporting the availability of
information that can be used to generate information for patient event
notifications. Specifically, we proposed that the system utilize the
ADT messaging standard incorporated by reference at 45 CFR
170.205(a)(4)(i).\59\
---------------------------------------------------------------------------
\59\ Health Level Seven Messaging Standard Version 2.5.1 (HL7
2.5.1), an Application Protocol for Electronic Data Exchange in
Healthcare Environments, February 21, 2007.
---------------------------------------------------------------------------
We noted that, while there are no criteria under the ONC Health IT
Certification Program which certifies health IT to create and send
electronic patient event notifications, the ADT standard is referenced
by other certification criteria under the program. Specifically, this
standard supports certification criteria related to transferring
information to immunization registries, as well as transmission of
laboratory results to public health agencies as described at 45 CFR
170.315(f) under the 2015 Edition certification criteria, and at 45 CFR
170.314(f) under the 2014 Edition. Thus, we expect systems that include
Health IT Modules certified to meet criteria which reference this
standard will possess the basic capacity to generate information for
notification messages. We further noted that adopting certified health
IT that meets these criteria has been required for any hospital seeking
to qualify for the Promoting Interoperability Programs (formerly the
EHR Incentive Programs).
We recognized that there is currently significant variation in how
hospitals have utilized the ADT messages to
[[Page 25587]]
support implementation of patient event notifications. We also
recognized that many hospitals, which have already implemented
notifications, may be delivering additional information beyond the
basic information included in the ADT message (both automatically when
a patient's status changes and then upon request from receiving
providers) to receiving practitioners, patient care team members, and
post-acute care services providers and suppliers with whom they have
established patient care relationships and agreements for patient
health information exchange as allowed by law. We believe consensus
standards for ADT-based notifications may become more widely adopted in
the future (we refer readers to ONC's ISA \60\ for more information
about standards under consideration). However, at this time, we stated
that we did not wish to restrict hospitals from pursuing more advanced
content as part of patient notifications, nor to create redundant
requirements where hospitals already have a suitable notification
system in place. Accordingly, while we specified that hospitals subject
to the proposal possess a system utilizing this standard, we proposed
that hospitals could utilize other standards or features to support
their notification systems. We requested comment on the proposal,
including whether this requirement would achieve the goal of setting a
baseline for hospitals' capacity to generate information for electronic
notifications, while still allowing for innovative approaches that
would potentially increase the effectiveness of these notifications
toward improving patient outcomes and safety during transitions in
care.
---------------------------------------------------------------------------
\60\ Office of the National Coordinator. (n.d.). Admission,
Discharge, and Transfer. Retrieved from https://www.healthit.gov/isa/admission-discharge-and-transfer.
---------------------------------------------------------------------------
We further proposed that the hospital would need to demonstrate
that the system's notification capacity was fully operational, that it
operated in accordance with all state and federal statutes and
regulations regarding the exchange of patient health information. We
intended for these notifications to be required, at minimum, for
inpatients admitted to, and discharged and/or transferred from the
hospital. However, we also noted that patient event notifications are
an effective tool for coordinating care across a wider set of patients
that may be cared for by a hospital. For instance, a patient event
notification could ensure that a primary care physician was aware that
his or her patient had received care at the emergency room, and
initiate outreach to the patient to ensure that appropriate follow-up
for the emergency visit was pursued. While we encouraged hospitals to
extend the coverage of their notification systems to serve additional
patients, outside of those admitted and seen as inpatients, we also
sought comment on whether we should identify a broader set of patients
to whom this requirement would apply, and if so, how we should
implement such a requirement in a way that minimizes administrative
burden on hospitals.
Additionally, we proposed that the hospital would have to
demonstrate that its system sends notifications that include the
minimum patient health information (specifically, patient name,
treating practitioner name, sending institution name, and, if not
prohibited by other applicable law, patient diagnosis). We proposed
that the hospital would also need to demonstrate that the system sends
notifications directly, or through an intermediary that facilitates
exchange of health information, at the time of the patient's hospital
admission, discharge, or transfer, to licensed and qualified
practitioners, other patient care team members, and PAC services
providers and suppliers that: (1) Receive the notification for
treatment, care coordination, or quality improvement purposes; (2) have
an established care relationship with the patient relevant to his or
her care; and (3) the hospital has reasonable certainty that such
notifications are received. We noted that we believed the proposal
would allow for a diverse set of strategies that hospitals might use
when implementing patient event notifications.
Through these provisions, we sought to allow for different ways
that a hospital might identify those practitioners, other patient care
team members, and PAC services providers and suppliers that are most
relevant to both the pre-admission and post-discharge care of a
patient. We proposed that hospitals send notifications to those
practitioners or providers that had an established care relationship
with the patient relevant to his or her care. We recognized that
hospitals and their partners may identify appropriate recipients
through various methods. For instance, hospitals might identify
appropriate practitioners by requesting this information from patients
or caregivers upon arrival, or by obtaining information about care team
members from the patient's record. We expected hospitals might develop
or optimize processes to capture information about established care
relationships directly, or work with an intermediary that maintains
information about care relationships. In other cases, we noted that
hospitals may, directly or through an intermediary, identify
appropriate notification recipients through the analysis of care
patterns or other attribution methods that seek to determine the
provider most likely to be able to effectively coordinate care post-
discharge for a specific patient. The hospital or intermediary might
also develop processes to allow a provider to specifically request
notifications for a given patient for whom they are responsible for
care coordination as confirmed through conversations with the patient.
Additionally, we expected hospitals, psychiatric hospitals, and
CAHs to comply with the HIPAA Rules set out at 45 CFR parts 160 and 164
if these proposed CoP requirements for patient event notifications were
finalized. As required at 42 CFR 482.11 for hospitals and psychiatric
hospitals and at 42 CFR 485.608 for CAHs, these providers must comply
with all pertinent currently existing federal laws, including the HIPAA
Privacy and Security Rules. The Privacy Rule permits patient event
notifications as disclosures for treatment purposes (the proposed
required notifications, when finalized, also may be treated as
disclosures required by law (see 45 CFR 164.502(a)).
We also recognized that factors outside of the hospital's control
might determine whether or not a notification was successfully received
and utilized by a practitioner. Accordingly, we proposed that a
hospital would only need to send notifications to those practitioners
for whom the hospital has reasonable certainty of receipt. While we
stated that we expected hospitals would, to the best of their ability,
seek to ensure that notification recipients were able to receive
notifications (for instance, by obtaining a recipient's Direct address
\61\), we understood that technical issues beyond the hospital's
control could prevent successful receipt and use of a notification.
---------------------------------------------------------------------------
\61\ For more information about obtaining a Direct addresses,
see https://www.healthit.gov/sites/default/files/directbasicsforprovidersqa_05092014.pdf.
---------------------------------------------------------------------------
Finally, we noted that hospitals have an existing responsibility
under the CoPs at 42 CFR 482.43(d) to ``transfer or refer patients,
along with necessary medical information, to appropriate facilities,
agencies, or outpatient services, as needed, for follow-up or ancillary
care.'' We emphasized that the proposal regarding patient event
notifications would be separate from the
[[Page 25588]]
requirement regarding necessary medical information at 42 CFR
482.43(d). However, we recognized that processes to implement the
proposal, if finalized, could intersect with the hospital's discharge
planning process. We noted that nothing in the proposal would affect
the hospital's responsibilities under 42 CFR 482.43(d). However, we
noted if the proposal was finalized, hospitals might wish to consider
ways to fulfill these requirements in ways that reduce redundancy while
still remaining compliant with existing requirements. For instance,
where appropriate and allowed by law, hospitals might seek to include
required necessary medical information within the same message as a
patient event notification.
C. Provisions for Psychiatric Hospitals (42 CFR 482.61(f))
Medicare- and Medicaid-participating psychiatric hospitals must
comply with all of the hospital CoPs at 42 CFR 482.1 through 482.23 and
at 42 CFR 482.25 through 482.57. They also must adhere to special
provisions regarding medical records at 42 CFR 482.61 and staffing
requirements at 42 CFR 482.62. Since the medical records requirements
are different for psychiatric hospitals, and since these hospitals do
not have to comply with the regulations at 42 CFR 482.24, we proposed a
new electronic notification standard at 42 CFR 482.61(f) within the
special provisions for psychiatric hospitals in this section.
Similar to the proposal for hospitals at 42 CFR 482.24(d), we
proposed a new standard at 42 CFR 482.61(f), ``Electronic
Notifications,'' that would require psychiatric hospitals to send
electronic patient event notifications of a patient's admission,
discharge, and/or transfer to another health care facility or to
another community provider.
As we proposed for hospitals, we proposed to limit this requirement
to only those psychiatric hospitals which currently possess EHR systems
with the technical capacity to generate information for electronic
patient event notifications, defined as systems that utilize the
content exchange standard incorporated by reference at 45 CFR
170.205(a)(4)(i). We proposed that that for a psychiatric hospital that
currently possessed an EHR system with the capacity to generate the
basic patient personal or demographic information for electronic
patient event (ADT) notifications, compliance with the proposed
standard within the Special medical records requirements for
psychiatric hospitals CoP (42 CFR 482.61) would be determined by the
hospital demonstrating that its system: (1) Is fully operational and
that it operated in accordance with all state and federal statutes and
regulations regarding the exchange of patient health information; (2)
utilizes the content exchange standard incorporated by reference at 45
CFR 170.205(a)(4)(i); (3) sends notifications that would have to
include the minimum patient health information (specifically, patient
name, treating practitioner name, sending institution name, and, if not
prohibited by other applicable law, patient diagnosis); and (4) sends
notifications directly, or through an intermediary that facilitates
exchange of health information, and at the time of the patient's
admission to the hospital and either immediately prior to or at the
time of the patient's discharge and/or transfer from the hospital. We
requested comment on the policy as part of this hospital proposal in
section X.B. of the CMS Interoperability and Patient Access proposed
rule (84 FR 7650 through 7652).
We also proposed that the hospital would need to demonstrate that
the system sends notifications directly, or through an intermediary
that facilitates exchange of health information, and either immediately
prior to or at the time of the patient's hospital admission, discharge,
or transfer, to licensed and qualified practitioners, other patient
care team members, and PAC services providers and suppliers that: (1)
Receive the notification for treatment, care coordination, or quality
improvement purposes; (2) have an established care relationship with
the patient relevant to his or her care; and (3) the hospital is
reasonably certain will receive such notifications.
We referred readers to the extended discussion of the proposals in
sections X.A. and B. of the CMS Interoperability and Patient Access
proposed rule (84 FR 7649 through 7652). We sought comment on these
proposals.
D. Provisions for CAHs (42 CFR 485.638(d))
We believe implementation of patient event notifications are also
important for CAHs to support improved care coordination from these
facilities to other providers in their communities. Therefore, similar
to the proposals for the hospital and psychiatric hospital medical
records requirements as discussed in the preceding sections, we
proposed to revise 42 CFR 485.638, by adding a new standard to the CAH
Clinical records CoP at paragraph (d), ``Electronic Notifications.'' As
discussed, the proposed standard would require CAHs to send electronic
patient event notifications of a patient's admission, discharge, and/or
transfer to another health care facility or to another community
provider.
We proposed to limit this requirement to only those CAHs which
currently possess EHR systems with the technical capacity to generate
information for electronic patient event notifications, defined as
systems that utilize the content exchange standard incorporated by
reference at 45 CFR 170.205(a)(4)(i). We proposed that for a CAH that
currently possessed an EHR system with the capacity to generate the
basic patient personal or demographic information for electronic
patient event (ADT) notifications, compliance with the proposed
standard within the Clinical records services CoP (42 CFR 485.638)
would be determined by the CAH demonstrating that its system: (1) Is
fully operational and that it operates in accordance with all state and
federal statutes and regulations regarding the exchange of patient
health information; (2) utilizes the content exchange standard
incorporated by reference at 45 CFR 170.205(a)(4)(i); (3) sends
notifications that would have to include the minimum patient health
information (specifically, patient name, treating practitioner name,
sending institution name, and, if not prohibited by other applicable
law, patient diagnosis); and (4) sends notifications directly, or
through an intermediary that facilitates exchange of health
information, and at the time of the patient's admission to the CAH and
either immediately prior to or at the time of the patient's discharge
and/or transfer from the CAH. We requested comment on the policy as
part of the hospital proposal in section X.B. of the CMS
Interoperability and Patient Access proposed rule (84 FR 7650 through
7652).
Additionally, we proposed that the CAH would need to demonstrate
that the system sends notifications directly, or through an
intermediary that facilitated exchange of health information, and at or
immediately prior to the time of the patient's CAH admission,
discharge, or transfer, to licensed and qualified practitioners, other
patient care team members, and PAC services providers and suppliers
that: (1) Receive the notification for treatment, care coordination, or
quality improvement purposes; (2) have an established care relationship
with the patient relevant to his or her care; and (3) the CAH is
reasonably certain will receive such notifications.
[[Page 25589]]
E. Comments and Responses on the Provisions of the Proposed Rule; Final
Actions and Provisions of the Final Rule for Hospitals (42 CFR
482.24(d)), Psychiatric Hospitals (42 CFR 482.61(f)); and CAHs (42 CFR
485.638(d))
We requested comments on the proposals including stakeholder
feedback about how the proposals should be operationalized.
Additionally, we sought comment on how CMS should implement these
proposals as part of survey and certification guidance in a manner that
minimizes compliance burden on hospitals, psychiatric hospitals, and
CAHs while ensuring adherence with the standards. We also sought
stakeholder input about a reasonable timeframe for implementation of
these proposals for hospitals, psychiatric hospitals, and CAHs,
respectively.
We received more than 600 public comments on this section that were
specific to the patient event notification requirements proposed for
inclusion in the CoPs, but which generally did not distinguish among
the requirements individually proposed for hospitals, psychiatric
hospitals, and CAHs at 42 CFR 482.24(d), 482.61(f), and 485.638(d),
respectively. We summarize the public comments we received on our
proposals related to the Conditions of Participation and provide our
responses in this section. This summary of the public comments and our
responses apply equally to all three provider types included under this
proposed requirement and the specific provisions proposed for each
unless otherwise noted. We provide the final actions and the provisions
of the final rule at the end of this section.
Comment: Many commenters supported the proposals to require
hospitals (including psychiatric hospitals) and CAHs to send electronic
patient event notifications of a patient's admission, discharge, and/or
transfer to another health care facility or to another community
provider. Commenters stated that they believed implementing patient
event notifications would be a highly effective tool to improve care
transitions for patients moving between a hospital and other settings,
including returning home. Commenters believed that increasing the
sharing of patient event notifications at admission and discharge can
lead to improved outcomes, higher quality, and lower cost care.
Commenters also pointed to many instances in which these notifications
are being utilized today, stating that they believe that patient event
notifications had effectively contributed to improved care
coordination. For instance, one commenter pointed to the statewide
requirement for hospitals in Maryland to transmit notifications, noting
that this has been an important policy supporting care coordination in
the state. Several commenters noted that the availability of
notification information is especially important for the success of
value-based payment models, such as ACO initiatives, where participants
may be financially at risk for costs associated with poor care
transitions.
Response: We appreciate commenters' support for the proposal and
are finalizing our proposal with modifications as discussed below.
Comment: While many commenters agreed that patient event
notifications are an important way to improve care coordination, some
disagreed that the CoPs were the appropriate vehicle for advancing
their use. Many commenters stated that by placing the patient event
notification requirements in the CoPs, CMS is putting hospitals'
participation in Medicare at risk, which they stated would be an
excessive penalty for failure to implement patient event notifications
in accordance with the proposed requirements.
Commenters also stated that the survey and certification process
was not well-suited to determining compliance with the proposed CoP
``Electronic notifications'' standard. These commenters questioned how
surveyors would assess compliance with the requirements, including one
commenter who questioned how a hospital would demonstrate that its
system sent notifications that improve the coordination of care, and
not just show that its system is merely functioning as required. They
further stated that a survey team would need clear guidance on how to
assess providers for compliance to ensure that hospitals are
transmitting patient information to, and receiving it from, other
providers.
Additionally, one commenter stated that hospital accreditation
programs are not the appropriate entities to assess compliance, due to
the technical nature of the requirements.
Commenters also expressed concern that tying these requirements to
the CoPs could lead to hospitals sending more information than is
necessary to ensure compliance, further increasing excessive
information received by providers.
Response: We appreciate the commenters' concerns regarding use of
the CoPs to advance the use of patient notifications; however, we
disagree that the CoPs are an inappropriate vehicle for this purpose.
We believe that the capability to send patient event notifications
should be a fundamental feature of hospital medical record systems to
support effective care transitions and promote patient safety during
transitions. This belief is consistent with the statutory authority for
establishing and appropriately updating the CoPs as that authority is
contained in section 1861(e) of the Act, which defines institutions
that meet the definition of a hospital for Medicare purposes.
Specifically, section 1861(e)(2) of the Act requires that a hospital
``maintains clinical records on all patients,'' and section 1861(e)(9)
of the Act requires that a hospital ``meets such other requirements as
the Secretary finds necessary in the interest of the health and safety
of individuals who are furnished services in the institution.'' As
discussed in the proposed rule (84 FR 7650), we believe patient event
notifications can help to improve care coordination for patients
discharged from the hospital and reduce the incidence of events such as
hospital readmissions that could have been avoided through more timely
follow-up care.
Further, including a CoP requirement for patient event
notifications at the time of a patient's discharge or transfer as we
have proposed and are finalizing in this rule is also consistent with
section 1861(ee)(2) of the Act, which states that the Secretary shall
develop guidelines and standards for the discharge planning process in
order to ensure a timely and smooth transition to the most appropriate
type of and setting for post-hospital or rehabilitative care. We
believe patient event notifications are an effective tool for ensuring
that the settings responsible for follow-up care are made aware that
their patients have been discharged in an expeditious manner. We
believe that these notifications can be utilized to more effectively
trigger care coordination activities that promote timely transitions.
We have chosen to include these requirements in the CoPs for medical
records services, and not those for discharge planning, because we
believe that the medical records CoPs provide a more global approach to
the notifications than do the discharge planning CoPs, especially since
we are requiring notifications for inpatient admissions as well as ED
and outpatient observation admissions or registrations in addition to
patient discharges and transfers. Therefore, given this statutory
authority, we maintain that the CoPs are an appropriate vehicle for
advancing the use of patient event notifications.
We also disagree that the CoPs are an inappropriate vehicle for
this policy due to what the commenters' characterize as
[[Page 25590]]
the disproportionate penalties associated with noncompliance with this
CoP. We note that while the CoPs are a significant regulatory
mechanism, noncompliance with one subordinate standard under one CoP
must be considered relative to a hospital's compliance or noncompliance
with the many other CoPs and standards as well as the severity of the
noncompliance and the risk it poses to patient health and safety. Under
the heading, ``Determining the Severity of Deficiencies,'' the State
Operations Manual (SOM), Appendix A--Survey Protocol, Regulations and
Interpretive Guidelines for Hospitals cites the regulations at 42 CFR
488.26 (``The decision as to whether there is compliance with a
particular requirement, condition of participation, or condition for
coverage, depends upon the manner and degree to which the provider or
supplier satisfies the various standards within each condition.'') as
the basis for determining the various levels of noncompliance with the
CoPs during a survey (https://www.cms.gov/Regulations-andGuidance/Guidance/Manuals/downloads/som107ap_a_hospitals.pdf; p.19).
From page 19 of the SOM, Appendix A:
``When noncompliance with a condition of participation is noted,
the determination of whether a lack of compliance is at the Standard or
Condition level depends upon the nature (how severe, how dangerous, how
critical, etc.) and extent (how prevalent, how many, how pervasive, how
often, etc.) of the lack of compliance. The cited level of the
noncompliance is determined by the interrelationship between the nature
and extent of the noncompliance.
``A deficiency at the Condition level may be due to noncompliance
with requirements in a single standard or several standards within the
condition, or with requirements of noncompliance with a single part
(tag) representing a severe or critical health or safety breach. Even a
seemingly small breach in critical actions or at critical times can
kill or severely injure a patient, and represents a critical or severe
health or safety threat.
``A deficiency is at the Standard level when there is noncompliance
with any single requirement or several requirements within a particular
standard that are not of such character as to substantially limit a
facility's capacity to furnish adequate care, or which would not
jeopardize or adversely affect the health or safety of patients if the
deficient practice recurred.''
Regarding the comments questioning how surveyors, either state
surveyors or those from one of the hospital accreditation programs,
would determine compliance with the notification requirements, we will
issue, as we do with all new or revised CoP requirements, new
interpretive guidelines, which include survey procedures, for the State
Operations Manual, following finalization of this rule and prior to the
rule's effective date. We will advise and train state surveyors on the
new requirements as is the normal procedure when new and/or revised
CoPs and standards are finalized. For example, the current Medical
Record Services CoP requirements, contained at 42 CFR 482.24, and in
which we are finalizing these new patient event notification
requirements, primarily contain provisions for administrative systems
or processes where the hospital is responsible for demonstrating that
the various components of its medical records system or process are in
place and operational in order to comply with the overall requirements
of the CoP. Surveyors would then approach these new requirements in a
similar fashion and apply similar survey procedures and methods that do
not require surveyors to have deep technical knowledge of various
systems in order to determine compliance. As with the survey of the
hospital's total medical records system, surveyors would utilize basic
and effective survey procedures and methods such as:
Review of the organizational structure and policy
statements and an interview with the person responsible for the medical
records service to first ascertain that the hospital has a system that
meets the initial requirements for patient event notifications in order
to determine whether or not the hospital is exempt from the specific
patient event notification requirements that follow.
Review of a sample of active and closed medical records
for completeness and accuracy, including any patient event
notifications, in accordance with federal and state laws and
regulations and hospital policy.
Interview of medical records and other hospital staff,
including physicians and other practitioners, to determine
understanding of the patient events notification function of the
system.
Conducting observations and interviews with medical
records staff and leadership to determine if requirements for patient
event notifications are being met.
CMS-approved accreditation organizations (AOs) with hospital
programs are required, at a minimum, to enforce standards that meet or
exceed hospital CoP requirements, so each AO will be responsible for
training its survey and accreditation staff on the patient event
notification requirements finalized in this rule ahead of the
applicable date established by CMS.
Finally, the patient event notification requirements that we are
finalizing require a hospital to send only a minimal amount of patient
information in order to be in compliance with the provisions. These
requirements are consistent with our belief that existing patient event
notification systems have demonstrated that a minimal set of
information can achieve the desired effect of improving care
coordination while imposing minimal burden on providers. However,
hospitals are not prohibited from sending more detailed information
under these requirements and we would expect each hospital is fully
aware of its own capacity to send additional patient information, other
applicable laws governing this, and the capacities of the intended
recipients to receive additional patient information, and would base
its decisions to send additional information on these factors as well
as on what is best for the patient. Based on our experience with
hospitals, we disagree with the commenter that a hospital would
unnecessarily send ``excessive'' amounts of patient information in an
attempt to ensure a determination that the hospital was in compliance.
To prevent such confusion, we have clearly delineated the patient
information requirements in this final rule.
Comment: Many commenters stated that the CoPs were not appropriate
for advancing goals related to interoperability and the use of health
IT. Commenters stated that CMS currently regulates provider use of
technology through a variety of other avenues, such as the Promoting
Interoperability Programs, and that adding the proposed requirements
under the CoPs would add an unnecessary additional mechanism for
addressing these issues. Commenters believed this could lead to
additional provider burden and confusion, as stakeholders would be
required to navigate duplicative requirements around the electronic
exchange of information. Several commenters stated that, by shifting
focus to compliance with the proposed requirements, and requiring
hospitals to engage in duplicative reporting on information exchange,
this proposal could divert funding and attention from necessary
investments in interoperable health information exchange. Commenters
stated that they believed using the CoPs
[[Page 25591]]
in this fashion was inconsistent with congressional intent for how HHS
should regulate the use of health IT.
Commenters also noted that HHS is currently seeking to establish a
range of new policies designed to advance the interoperable exchange of
health information. Commenters believed these policies could have a
significant impact on the sharing of health information, including the
sharing of patient event notifications, and that CMS should refrain
from rulemaking through the CoPs until these polices have been
finalized. One commenter also noted that, at the time the comment
period on the CMS Interoperability and Patient Access proposed rule
closed, CMS' Discharge Planning rule (80 FR 68125) had not yet been
finalized, and that it would be premature to add this requirement in
advance of finalizing related revisions to the discharge planning
section of the CoPs.
Commenters further stated that HHS has a variety of other
mechanisms for advancing electronic information exchange and improving
the infrastructure for exchange that would be more effective than
adding requirements to the CoPs. Several commenters expressed concern
that using the CoPs would set static requirements that are ill-suited
to an evolving technology environment and the innovation needed to
increase adoption of notifications across providers.
Response: We appreciate commenters' input. As noted above, we
disagree with commenters who stated that the CoPs are not an
appropriate mechanism for policy related to interoperability or the use
of health IT. Existing CoPs address requirements related to medical
records systems as well as the transfer of health information, and we
believe there is no reason that these regulations should not address
technology issues where the use of technology may be relevant to
patient health and safety, provided that such references to technology
in the CoPs do not lead to ``static requirements'' as noted by the
commenter, and which we believe we have avoided doing in both the
proposed and final rules. Furthermore, while a 2017 review of the
current available scientific evidence on the impact of different health
information technologies on improving patient safety outcomes, warned
that health care organizations ``need to be selective in which
technology to invest in, as literature shows that some technologies
have limited evidence in improving patient safety outcomes,'' the
review also stated that there ``should be no doubt that health
information technology is an important tool for improving healthcare
quality and safety.'' \62\ According to the authors of the review,
evidence from a number of studies shows that health IT offers numerous
opportunities for improving and transforming health care that includes
the potential to reduce human errors, improve clinical outcomes,
facilitate care coordination, improve practice efficiencies, and track
data over time. Based on this evidence as well as the evidence directly
related to patient event notifications that we cited previously, we
believe that the requirements for patient event notifications that we
have proposed and that we are finalizing in this rule will have a
positive impact on many of these same areas, especially regarding the
facilitation of care coordination for patients, leading to improved
outcomes and enhanced patient health and safety.
---------------------------------------------------------------------------
\62\ Alotaibi, Y., & Federico, F. (2017). The impact of health
information technology on patient safety. Saudi Medical Journal,
38(12), 1173-1180. doi: 10.15537/smj.2017.12.20631.
---------------------------------------------------------------------------
While we appreciate the importance of aligning policies across
different programs to minimize provider burden, we believe that the
proposed requirements are not addressed elsewhere and are appropriate
for inclusion in the CoPs. Additionally, we disagree with commenters
who stated that the proposed requirements will require hospitals to
engage in duplicative reporting on information exchange since the
proposed requirements do not require hospitals and CAHs to do any type
of reporting to CMS in order to comply with the requirements. We also
understand that other proposed or recently finalized policies may be
relevant to the proposed requirements in this rule; however, we believe
these policies will complement one another and serve to enable the
proposed requirements around patient event notifications. As we noted
above regarding the final rule published on September 30, 2019,
Discharge Planning final rule (84 FR 51836), the revised discharge
planning CoPs do not require hospitals, CAHs, and HHAs to transfer
necessary patient medical information exclusively by electronic means,
nor do they require that providers notify the appropriate providers,
suppliers, and practitioners receiving the necessary medical
information of the patient's discharge (or admission) as we are now are
requiring in this final rule. We believe that the two rules, as written
and finalized, do not conflict, but instead complement and support each
other in CMS' goal of improving patient care transitions. Therefore, we
disagree with the comments stating that the patient event notification
requirements are premature or duplicative in relation to the final
discharge planning requirements for hospitals, CAHs, and HHAs.
Regarding concerns that it will be challenging to update the CoPs
to reflect changing technology requirements, our proposal sought to
focus primarily on functional requirements that will allow hospitals
the flexibility to pursue innovation and adapt their systems over time,
similar to other functional requirements under the Medical Records
Services CoP. Where we do reference a specific standard, in order to
determine whether or not a hospital's system would be subject to the
proposed ``Electronic notifications'' standard, we reference a content
exchange standard at 45 CFR 170.205(d)(2) common to many EHRs that we
believe is unlikely to undergo changes that would require frequent
updates.
Comment: Commenters stated that including these requirements under
the CoPs would significantly increase the compliance burden for
providers. Commenters believed that the proposed policy was contrary to
other recent HHS burden reduction initiatives for providers. Commenters
also believed that this proposal would add additional layers of
regulation to what is a common practice for many hospitals today,
further increasing provider burden.
Several commenters stated that CMS had underestimated the burden
associated with this proposal. They disagreed that implementing patient
event notifications would be largely limited to a one-time cost, and
stated that there would be substantial work required prior to
implementing the proposal and continuous work around receiving
notifications from other providers. Commenters suggested that CMS
pursue other initiatives to alleviate costs, such as standardizing the
data set for patient event notifications. Stakeholders also urged CMS
to ensure that providers have cost-effective choices for required
technology solutions, and to not create an environment that encourages
over-pricing of solutions.
Response: We appreciate commenters' concerns about additional
provider burden. While we understand that this new requirement may
impose some additional implementation burden on hospitals, commenters
also expressed that there are many ways for hospitals to minimize this
burden through the use of existing technologies and services, such as
health information exchanges and other service providers which capture
notification information from a hospital's EHR and route it to
[[Page 25592]]
appropriate recipients. We believe that there is sufficient flexibility
in the current proposal to ensure hospitals have a broad range of
options for implementation and will be able to comply in a way that
aligns with their existing capabilities.
We believe that care coordination can have a significant positive
impact on the quality of life, consumer experience, and health outcomes
for patients. However, we acknowledge that though such activities can
have positive impact, they will likely generate some costs. We believe
it is difficult to quantify the impact of these changes because EHR
implementation across care settings varies in maturity rates, leading
to potential variance in cost and impact across such settings.
Nonetheless, we have attempted to estimate the burden for those
hospitals and CAHs that currently utilize electronic medical records
systems or other electronic administrative systems that are conformant
with the content exchange standard at 45 CFR 170.205(d)(2), and which
generate information to support the basic messages commonly used for
electronic patient event notifications, but which are not currently
transmitting notifications. The cost of implementing these changes will
include a one-time cost related to initial implementation of the
notification system. Additionally, we have also estimated recurring
maintenance costs for either those hospitals or CAHs that use hospital
or CAH IT services staff to perform this recurring maintenance, or for
those hospitals and CAHs that contract with third party outside
services providers to perform this maintenance. We also stress that the
requirements that we are finalizing here do not mandate that a hospital
or CAH must purchase and implement a new EHR system. Rather, as
finalized here, the provisions require a hospital or a CAH to
demonstrate compliance with all of the provisions contained at 42 CFR
482.24(d), 482.61(f), and 485.638(d) only if it utilizes an electronic
medical records system or other electronic administrative system that
is conformant with the content exchange standard at 45 CFR
170.205(d)(2). We note here then that a hospital or a CAH that does not
meet the basic requirements denoted in the standard language at
paragraphs 42 CFR 482.24(d), 482.61(f), and 485.638(d) is exempt from
demonstrating compliance with the requirements that follow and will not
be surveyed for those specific provisions once a surveyor determines
that the system used by the hospital or CAH is not conformant with the
content exchange standard discussed here.
Comment: Many commenters supported the proposal to limit the
application of the proposed requirements to hospitals that possess a
system capable of generating information for patient event
notifications, while several disagreed with CMS and thought that CMS
should not limit these requirements to only certain hospitals. Numerous
commenters also sought additional information on how CMS will determine
whether a hospital's system is subject to the proposed CoP standard.
Commenters stated that the proposed rule did not indicate how surveyors
would determine which electronic records systems possess required
attributes, and that surveyors would not have the technical expertise
required to make this determination.
Response: In the CMS Interoperability and Patient Access proposed
rule, we proposed to limit this requirement to only those hospitals
which currently possess EHR systems with the technical capacity to
generate information for electronic patient event notifications. We
defined a system with this capacity as one that utilizes the ADT
messaging standard, Health Level Seven (HL7[supreg]) Messaging Standard
Version 2.5.1 (HL7 2.5.1)) incorporated by reference at 45 CFR
170.205(a)(4)(i). We noted that this standard is referenced by
certification criteria related to transferring information to
immunization registries, as well as transmission of laboratory results
to public health agencies as described at 45 CFR 170.315(f), and that
adoption of certified health IT that meets these criteria has been
required for any hospital seeking to qualify for the Promoting
Interoperability Program. We believe hospitals and surveyors will be
able to determine whether an EHR system possesses the capacity to
generate information for electronic patient event notifications,
defined for the purposes of the CoP as a system conformant with the
specified ADT messaging standard (HL7 2.5.1), based on existing
requirements for other programs, such as the Promoting Interoperability
Program. In general, we believe that information about whether a system
complies with this provision will be easy to obtain from a hospital's
health IT developer.
As discussed below, we are finalizing a citation to the ADT
messaging standard (HL7 2.5.1) at 45 CFR 170.205(d)(2).
Comment: A commenter noted that in some instances a hospital's
patient event notification system is connected to the hospital's
registration system rather than its EHR system, which is used for
clinical purposes only.
Response: We appreciate the comment and the opportunity to note
here that the ``electronic medical records system'' described in the
CoPs is not limited to the EHR system used for the management of
clinical data. Hospitals would also be permitted to send patient event
notifications using their registration system. Based on this comment,
we are revising the language at 42 CFR 482.24(d), 482.61(f), and
485.638(d) in this final rule to now state that if the hospital (or
psychiatric hospital or CAH), ``. . . utilizes an electronic medical
records system or other electronic administrative system,'' then the
hospital (or psychiatric hospital or CAH) would need to demonstrate
that its system complies with the provisions that follow in this
section.
Comment: In the proposed rule we sought comment on whether we
should identify a broader set of patients to whom this requirement
would apply, beyond those admitted and treated as inpatients. For
instance, we noted that a patient event notification could ensure a
primary care physician is aware that their patient has received care at
the emergency room, and initiate outreach to the patient to ensure that
appropriate follow-up for the emergency visit is pursued (84 FR 7651).
Many stakeholders responded to this request for comment by stating
that they supported extending this policy to also include patients seen
in a hospital's emergency department (ED). Commenters stated that
requiring systems to be able to send these notifications would be an
important way to support better care coordination and prevent
unnecessary repeat visits to the emergency department. Commenters also
suggested that this requirement should include patients seen in the
hospital for ``observational'' stays, but who are not admitted as
inpatients.
Response: We agree with the commenters that ED patients should be
included in the patient event notification system, and have revised the
regulatory text at 42 CFR 482.24(3)(i) and (4)(i), 482.61(3)(i) and
(4)(i), and 485.638(3)(i) and (4)(i) to include these patients. Many
patients registered in the ED are eventually discharged home after
being treated, while others are either held for observation in a
hospital bed as outpatients or admitted as inpatients to the hospital.
The revisions we are finalizing here would require a hospital's system
to send patient event notifications for patients who are registered in
the ED, if applicable, and then also for patients admitted as
[[Page 25593]]
inpatients, regardless if the patient was admitted from the ED, from an
observation stay, or as a direct admission from home, from their
practitioner's office, or as a transfer from some other facility. We
agree with the commenters and believe that if we were not to include ED
patients in the notification requirements in this final rule, we would
miss an important opportunity for positively impacting the care
transitions and the continuing care of a significant number of patients
seen in the nation's hospital emergency departments. Including ED
patients in the patient event notification requirements is consistent
with the purpose of the CoPs as a regulatory means of promoting and
protecting the overall health and safety of all hospital patients,
regardless of their physical location in the hospital.
To illustrate when a patient event notification is, and is not,
required, we would like to point out the following scenarios. A
hospital's system would be expected to send one notification when a
patient is first registered in a hospital's ED or as an observational
stay (that is, in both of these cases, the patient would be considered
an outpatient and not an inpatient at this point in time), and a second
notification if the same patient was then later admitted to a hospital
inpatient services unit (for example, medical unit, labor and delivery
unit, telemetry unit, neurology unit, surgical unit, intensive care
unit (ICU), etc.), or if the same patient was admitted for inpatient
services, but was being boarded in the ED while waiting for an
inpatient unit bed. In contrast, a second patient event notification
would not be required if an already admitted inpatient was transferred
from one inpatient services unit of the hospital to another (for
example, if the patient was admitted to the hospital's ICU, but was
then later transferred to the hospital's ``step-down'' or
``intermediate care'' unit or to a medical unit, in which case, the
patient continued to remain an inpatient of the hospital), or if an
already admitted patient was being boarded in the ED and then was
transferred to an inpatient unit when a bed became available. However,
while the requirements do not prohibit a hospital from electing to send
a patient event notification when a patient is transferred to one
inpatient services unit of the hospital to another, the requirements
finalized in this rule are based on a change in the patient's status
from outpatient to inpatient, and not necessarily on the physical
location of the patient.
Finally, in all cases, a patient's discharge or transfer from the
hospital, either from the ED or an observational stay or an inpatient
services unit, would still require the hospital to send another and
separate patient event notification to the applicable entities as
required under this rule.
Comment: We proposed that hospitals should send notifications to
those practitioners or providers that have an established care
relationship with the patient relevant to his or her care (84 FR 7652).
Many commenters sought additional information about the term
``established care relationship'' and how hospitals should discern who
has an established care relationship with a patient. Commenters noted
that the list of providers who have an ``established care
relationship'' with a patient could be very extensive and requested
more information on the extent of the specialization of care team
members covered by the requirement. One commenter suggested CMS
indicate that the term ``established care relationship'' only applies
to one that is current and directly related to the patient's diagnosis
for which the notification is sent. Another commenter suggested that
CMS define ``established care relationship'' as the principle physician
identified by the patient and any institution that the patient
identifies. Several commenters suggested that CMS replace the term
``established care relationship'' with ``active relationship,'' and
noted that this would also ensure payers received the notifications, as
their relationship with a patient may not be included under the
definition of a ``care'' relationship. One commenter suggested that CMS
note that hospitals have the latitude to choose the recipient of the
notification. Commenters also sought direction on how hospitals should
approach a situation in which a patient does not have a primary care
provider, or in which a provider who has an established care
relationship with the patient cannot be easily identified. Several
commenters noted that effective notification systems are often
organized around a subscription model, in which receiving providers are
responsible for identifying those patients for whom they would like to
receive notifications.
Response: We appreciate commenters' input. We agree that the term
``established care relationship'' could be subject to an overly broad
interpretation that is not consistent with our goal to set a minimum
floor for these requirements under the CoPs. Accordingly, we are
finalizing a more limited set of recipients to whom a hospital's system
must send patient event notifications for the purposes of meeting this
CoP. We are finalizing at 42 CFR 482.24(d)(5), 482.61(f)(5), and
485.638(d)(5) requirements that the hospital's system send
notifications to the following recipients as applicable: The patient's
established primary care practitioner; the patient's established
primary care practice group or entity; or other practitioners or
practice groups or entities, identified by the patient as the
practitioner, or practice group or entity, primarily responsible for
his or her care. We believe that the use of the modifier
``established,'' as finalized here in the context of a patient's
established primary care practitioner or his or her established primary
care practice group or entity, more clearly signifies a care
relationship that the patient recognizes as primary or one that is
evidenced by documentation of the relationship in the patient's medical
record. As an example, if the patient's established primary care
practitioner refers the patient to the hospital, this primary care
practitioner should receive the event notification. We believe this
language improves upon the proposed term ``established care
relationship,'' which commenters correctly noted is too vague in
meaning, too broad in scope, and too open to various interpretations,
all of which could prove burdensome for hospitals to demonstrate
compliance with the requirements here. We note that this final policy
does not prevent a hospital from sending patient event notifications to
other practitioners, in accordance with all applicable laws, who may be
relevant to a patient's post-discharge care and would benefit from
receiving patient event notifications, nor would it prevent a hospital
from seeking to identify these other practitioners. However, we believe
this more limited set of recipients is more appropriate to our goal of
setting baseline requirements and will provide hospitals with
sufficient specificity to comply with the requirements.
In cases where a hospital is not able to identify a primary care
practitioner for a patient, the patient has not identified a provider
to whom they would like information about their care to be sent, or
there is no applicable PAC provider or supplier identified, we would
not expect a hospital to send a patient event notification for that
patient. We note that under the CoP, a hospital would be required to
demonstrate that its system sends notifications to appropriate
recipients. We expect that hospitals would demonstrate this capability
in variety of ways, for instance, by demonstrating that the hospital
has processes and policies in place to identify patients' primary care
practitioners and
[[Page 25594]]
incorporate this information into the patient event notification
system, or through recording information received from patients about
their providers.
Comment: Commenters stated that obtaining information about
providers who have an ``established care relationship'' with a given
patient and maintaining lists of these providers and contact
information for delivery of patient event notifications would impose
significant burden on hospitals. One commenter noted that patients may
not reliably provide information about their providers, and recommended
that in those cases the recipient of the patient event notification
should identify their relationship with a patient in advance.
Several commenters noted that, to the extent hospitals already have
operational processes and infrastructure in place to determine
destinations for notifications, these processes should be left in
place. Several commenters noted that, in order to successfully route
messages to the appropriate provider, hospitals would need to be able
to overcome challenges associated with patient matching: The ability
for a hospital to accurately match records about a patient with the
records held by a receiving provider. Commenters stated that challenges
with patient matching could inhibit patient event notifications from
being received by the correct provider and will lead to frequent
pushback from providers about receiving notifications regarding
patients they are not affiliated with. Commenters also noted the
importance of community-wide directories that map the address of a
provider to their electronic endpoint destination, which would allow a
hospital to query a directory and find the destination of the patient's
choice.
Response: As noted, we are finalizing a more limited minimum set of
recipients for patient event notifications than originally proposed.
This set of recipients is focused on a patient's established primary
care practitioner (or established primary care practice group or
entity) or any other practitioner (or practice group or entity)
identified by the patient as primarily responsible for his or her care.
However, we are retaining inclusion in this final rule of PAC providers
and suppliers as required recipients of notifications as originally
proposed. In order to clarify the PAC services providers and suppliers
that are required recipients, we are modifying this proposal to refer
to ``all applicable PAC services providers and suppliers.'' For
purposes of this policy, applicable PAC services providers and
suppliers would be those PAC services providers and suppliers with whom
the patient has an established care relationship prior to admission or
to whom the patient is being transferred or referred. Similar to our
modification to reference the patient's established primary care
practitioner, these PAC services providers and suppliers would be those
with an established care relationship immediately preceding the
hospital registration or admission (such as a PAC services provider or
supplier from which the patient was transferred to the hospital) or
those with which a relationship is being established for purposes of
treatment and/or care coordination post-discharge from the hospital.
The potential recipients of patient event notifications will be limited
to only those that need to receive notification of the patient's status
for treatment, care coordination, or quality improvement purposes. We
believe that this final policy will reduce potential operational burden
associated with a broader ``established care relationship'' definition.
We believe that increasing numbers of hospitals now commonly seek to
identify patients' primary care practitioners and their contact
information, including any digital contact information, or partner with
intermediaries that identify primary care practitioners, and that many
hospitals will be able to continue to use their existing processes to
satisfy the CoP. If a hospital has processes in place for identifying
patients' primary care practitioners and other applicable providers,
but is not able to identify an appropriate recipient for a patient
event notification for a specific patient, the hospital would not be
expected to send a notification for that patient.
Research using CMS data on readmission rates in Medicare-
participating hospitals from 2007 to 2015 shows that the readmission
rates for targeted conditions (that is, a set of specific diagnoses
measured by Medicare) declined from 21.5 percent to 17.8 percent, and
rates for non-targeted conditions declined from 15.3 percent to 13.1
percent.\63\ While this decline in readmissions rates is attributable
to multiple factors, we believe that one of the significant factors
driving down avoidable patient readmissions is identification by the
hospital of the patient's established primary care practitioner (or
practice group) and his or her contact information prior to discharge
and/or transfer. Increased and early identification of the patient's
primary care practitioner is more likely to lead to more accurate and
timely transfer of patient health information from hospital-based
practitioners to community-based primary care practitioners.
Additionally, early identification of a patient's primary care
practitioner along with the patient event notification to the
practitioner that his or her patient is about to be discharged from the
hospital is most likely to have a net positive effect on scheduled
post-discharge follow-up rates for patients most at risk for avoidable
readmissions.
---------------------------------------------------------------------------
\63\ Alper, E., O'Malley, T.A., & Greenwald, J. (n.d.). Hospital
discharge and readmission. Retrieved from https://www.uptodate.com/contents/hospital-discharge-and-readmission.
---------------------------------------------------------------------------
We appreciate commenters concerns about patient matching
challenges. This is a larger issue beyond the scope of this CoP
proposal and this current rule, but we will consider this issue for
future revisions and updates to the CoPs. With the continued increase
in the use of electronic data in health care organizations and among
providers of health care services, there has been a continued need for
patient matching, or patient identity management (PIM) processes, in
health care organizations, including hospitals. PIM has been defined as
the ability to uniquely ascertain the identity of a patient, assign
that patient's record an identifier that is unique within the
organization, system, or exchange network, and match that patient's
record within and between systems using a number of demographic data
elements, such as the patient's first name, last name, address, and
date of birth. Effective PIM supports patient identity integrity, which
the National Association of Healthcare Access Management defines as
accurately identifying and matching the right patient with his or her
complete medical record, every time, in every provider setting.\64\
Accurate patient identity management is critical to successfully
delivering the right care to the correct patients.
---------------------------------------------------------------------------
\64\ National Association of Healthcare Access Management.
(2016, March 17). NAHAM Public Policy Statement on Patient Identity
Integrity. Retrieved from https://nahamnews.blogspot.com/2016/03/naham-public-policy-statement-on.html.
---------------------------------------------------------------------------
Capturing incorrect or incomplete data can result in critical
patient care issues and risk privacy breaches. Health care
organizations are more likely to have their EHR system filled with
duplicate patient records and inaccurate information about their
patients when they are not managing an effective PIM process. Having an
ineffective PIM process will most definitely negatively impact a
hospital's patient event notification system, which is one of the many
reasons why a rigorous PIM process is essential to patient care as
health IT moves forward. Additionally, PIM has become crucial in order
to (1)
[[Page 25595]]
enable health record document consumers to obtain trusted views of
their patient subjects; (2) facilitate data exchange projects; (3)
abide by the current regulations concerning patient information-related
transparency, privacy, disclosure, handling, and documentation; and (4)
make the most efficient use of limited health care resources by
reducing redundant data collection.\65\
---------------------------------------------------------------------------
\65\ Gliklich, R., Dreyer, N., & Leavy, M. (Eds.). (2014).
Registries for Evaluating Patient Outcomes: A User's Guide (3rd
ed.). Rockville, MD: AHRQ Publication. Retrieved from https://www.ncbi.nlm.nih.gov/books/NBK208616/.
---------------------------------------------------------------------------
Nationally recognized practices and standards for ensuring patient
identity integrity have been identified by organizations such as the
National Association of Healthcare Access Management, American Health
Information Management Association, the Agency for Healthcare Research
and Quality, and ONC. These standards include standardizing demographic
data fields and internally evaluating the accuracy of patient matching
within health care organizations.
We believe this presents an opportunity for the health IT industry
to lead the way in developing innovative solutions to patient matching,
or PIM, that can benefit all facets of the health care industry.
However, appreciating the importance of accurate patient matching, CMS
will continue to evaluate ways to support improved patient matching
solutions.
Comment: Several commenters suggested additional provider types
that should receive patient event notifications. For instance,
commenters suggested health plans should be included on the list of
recipients for patient event notifications, noting that this
information would be valuable to plans responsible for coordinating
services for beneficiaries and reducing readmissions. One commenter
also recommended sending notifications to public health departments.
Several commenters also requested that specific health care
professionals be identified as recipients. Commenters also suggested
that other caregivers such as relatives be included on the list of
recipients.
Response: We appreciate commenters' suggestions about adding
additional recipients for patient event notifications. While there may
be other entities that could benefit from receiving patient event
notifications, we believe it is more appropriate for the purposes of
the CoP requirements to focus on a minimal set of recipients for
notifications. This approach would not preclude hospitals from sending
notifications to other entities, including health plans, provided
hospitals comply with applicable laws and regulations regarding sharing
of patient data.
Comment: Many commenters suggested that CMS should consider
approaches that aim to incentivize providers to implement patient event
notifications, rather than requiring hospitals to do so through the
CoPs. Commenters stated that adding this requirement would result in
unnecessary and burdensome duplication of requirements that hospitals
are already subject to as part of existing programs focused on
advancing health information exchange. Specifically, many commenters
recommended that CMS seek to advance these goals through the Promoting
Interoperability Program. Commenters suggested CMS consider adding a
measure to the program based on patient event notifications, noting
that such a measure could mirror the ``active engagement'' concept
currently used for public health measures under the program or be
assessed through an attestation similar to current attestations related
to information blocking. Several commenters also noted our discussion
of potentially establishing a set of ``health IT activities'' under the
Promoting Interoperability Program (84 FR 7618) that would not be
linked to performance measures, noting that such a concept would be
well-suited to advancing patient event notifications. One commenter
noted that the Promoting Interoperability Program, with its annual
performance assessment, is more appropriate to supporting progress on
technology goals than the CoPs, and that a measure reported annually
could better assess the degree to which providers are improving their
usage of patient event notifications.
Commenters also recommended other alternative strategies that CMS
could engage in to incentivize use of patient event notifications, such
as models established under Innovation Center authority. Commenters
believed that highlighting the use of patient event notifications in
connection with alternative payment models could help to strengthen the
business case for this intervention. Another commenter recommended that
the use of patient event notifications could be incentivized through an
offset or bonus in a hospital-focused quality program, or through
offering regulatory flexibility (for instance around telehealth) to
hospitals that choose to implement a system for notifications.
Response: We appreciate commenters' suggestions to encourage the
use of patient event notifications through the Promoting
Interoperability Program. In order for an action to serve as the basis
for a measure under the Promoting Interoperability Program, the action
must require the use of certified health IT. As discussed in the CMS
Interoperability and Patient Access proposed rule, at this time there
is no certification criterion included in ONC's certification program
for the creation and transmission of patient event notifications (84 FR
7651). As discussed elsewhere in this final rule, ONC does not believe
there is a widely adopted consensus standard for patient event
notifications at this time. ONC will continue to monitor adoption of
standards for this use case and consider whether it would be
appropriate to develop a certification criterion for this
functionality. Accordingly, we believe it would not be feasible to add
a measure related to patient event notifications to the Promoting
Interoperability Program at this time.
We appreciate commenters input about other programs that could
advance the use of patient event notifications, such as models
established under Innovation Center authority, and will take these
under consideration.
Comment: Several commenters addressed the use of the ADT standard
for patient event notifications. One commenter noted that the ADT
messaging standard is very broad and that implementations are subject
to significant variability and customization. Commenters highlighted
the fact that there is significant variation in the implementation of
the ADT standard, limiting interoperability across interfaces using
this standard, and suggested that CMS clarify specific content and
triggering events for ADT data exchange. Another commenter noted that
the lack of an implementation guide for the use of ADT messages for
notifications is challenging, as this guidance is essential for
understanding what information must be sent and how. Commenters who
believed that the reference to the ADT standard would require the
establishment of new interfaces for exchanging ADT messages stated that
recipient providers would not be able to receive ADT messages if they
do not have an inbound ADT interface in place. Many commenters believed
that specifying the HL7 2.5.1 ADT message standard would be overly
restrictive and recommended that CMS not specify a specific standard
for these transactions at this time. Commenters urged CMS to focus on
creating functional requirements rather than identifying specific
mechanisms or standards for
[[Page 25596]]
the data. Other commenters stated that any standard should be required
as a floor, rather than a ceiling. One stakeholder recommended that CMS
compile stakeholder feedback to better understand which standard would
be preferred by the industry.
Several commenters supported adoption of the ADT message standard
(HL7 2.5.1), stating that it is the most frequently used standard for
the transmission of patient event notifications. One commenter urged
CMS to avoid policies that allow a hospital to deviate from a required
standard, and to align with standards proposed by ONC to ensure
consistency across different types of data exchange.
One commenter suggested that CMS explore moving to later versions
of the HL7 2.5.1 standard, which provide additional message types,
segments, and codes while others noted that additional work will be
needed by standards setting bodies such as HL7 to develop a more robust
standard in the future.
Other commenters supported the flexibility discussed in the CMS
Interoperability and Patient Access proposed rule with respect to using
other standards and features to support sending patient event
notifications. One commenter supported the flexibility provided in the
proposed rule, but believed that this flexibility may introduce
challenges for those providers receiving and incorporating information
provided by a hospital.
Several commenters urged CMS to not require the use of certified
EHR technology (CEHRT) to send ADT messages, noting that hospitals
currently use a variety of solutions to send patient event
notifications. One commenter noted that the HL7 protocol cannot be sent
using Direct messaging or other exchanges used for continuity of care
documents. One commenter noted that ADT information is not available in
real time, and that an open API for both the hospital and receiving
provider would be needed to enable real-time notifications. Commenters
recommended that CMS instead focus on the use of standards-based feeds
from the hospital's technology of choice.
Response: We appreciate commenters' feedback. We recognized in the
CMS Interoperability and Patient Access proposed rule that there is
currently significant variation in how hospitals have utilized ADT
messages to support implementation of patient event notifications (84
FR 7651). In recognition of this current state, we proposed to require
that a hospital would be subject to this CoP if its system complied
with the ADT messaging standard, but we did not propose to require that
hospitals use a specific standard to format or deliver patient event
notifications. We believe this flexibility is necessary due to
significant variation in how HL7 2.5.1 messages have been used to
support notifications, and allows providers to use other standards for
structuring and delivering this information that they may be currently
using to implement patient event notifications, or may prefer to use
for other reasons.
As noted, our intent is to allow flexibility; therefore, we have
refrained from specifying a standard for delivery of patient event
notifications that could be overly limiting for hospitals. We are
finalizing revised regulation text at 42 CFR 482.24(d), 482.61(f), and
485.638(d) that specifies that a hospital system's conformance with the
ADT standard will be used solely to determine whether a hospital is
subject to the CoP. Requirements regarding the content and format of
the patient event notifications, which a hospital's system must send to
satisfy the CoP, are limited to the minimal information elements
described elsewhere in this final rule. We are not specifying a
standard for the content, format, or delivery of these notifications.
We also note that we did not specify that hospitals must use a
specific technology to send patient event notifications; for instance,
we did not specify that a hospital must use the capabilities of
certified health IT to send notifications, nor that hospitals must send
notifications via an interface adhering to the HL7 messaging standard.
We hope that this response addresses commenters' concerns, and
clarifies that the reference to the HL7 messaging standard in these
requirements does not preclude use of other standards for transporting
patient event notifications. In addition, we note that our
understanding is that many successful patient event notification
implementations have used the content of HL7 messages in conjunction
with other forms of transport, such as Direct messages.
While we agree with commenters that common usage of a single,
strictly defined standard would increase interoperability for these
transactions, we do not believe that this is possible at this time. At
the same time, we strongly encourage hospitals, and any intermediaries
a hospital may partner with, to adopt standards-based approaches to the
structure and transmission of patient event notifications, including
the many standards-based solutions described by commenters. We
acknowledge that, at this time, the use of different standards may
result in decreased ability for certain providers to receive
notifications from sending hospitals, depending on the attributes of
their respective systems. We will consider whether there are additional
ways we can encourage hospitals to move towards increased
interoperability for these transactions in the future.
We also wish to address and clarify a discrepancy in the way we
referenced the ADT messaging standard in the proposed rule.
Specifically, in the preamble of the proposed rule we cited 45 CFR
170.299(f)(2), where the HL7 2.5.1 messaging standard is listed for
incorporation by reference. However, in the regulation text of the
proposed rule, we erroneously cited to 45 CFR 170.205(a)(4)(i), which
contains the C-CDA standard instead of HL7 2.5.1. The C-CDA standard is
referenced in certification criteria related to summary of care records
(84 FR 7678). As discussed above, we are finalizing our policy that a
hospital will be subject to the requirements in this section if it uses
a system conformant with the HL7 2.5.1 content exchange standard, which
indicates a system has the basic capacity to generate information for
patient event notifications. In this final rule, we are revising the
regulation text and finalizing a citation to the HL7 2.5.1 content
exchange standard where it is currently referenced at 45 CFR
170.205(d)(2). We believe that this citation is the most appropriate
way to reference the HL7 2.5.1 standard.
Comment: Several commenters requested that CMS indicate whether it
would be acceptable to transmit information using other standards than
the ADT message, specifically delivering messages using the C-CDA
standard, which providers must use to satisfy the requirements of the
transitions of care measures under the Promoting Interoperability
Programs. Several commenters stated that they would prefer to format
messages using this standard, which they already use for the Promoting
Interoperability Program, and that a requirement to deliver messages
according to the HL7 ADT messaging standard would result in duplicative
work. Others questioned whether transmitting notifications via a
FHIR[supreg]-based API would be permissible.
Response: In the proposed rule, we stated that a hospital's medical
records system is a compliant system if it utilizes the ADT messaging
standard. However, we did not propose a specific format or standard for
the patient event notification that a hospital would be required to
send under the proposed CoP. Thus, hospitals would be allowed to
transmit patient event notifications
[[Page 25597]]
using other standards, such as the C-CDA or via a FHIR-based API.
Comment: Many commenters supported the inclusion of diagnosis in
patient event notifications where permitted by law, stating that this
information is helpful for supporting care coordination between a
hospital and other providers. One commenter noted that this information
can be included by leveraging certain segments of the HL7 ADT feed, and
that this segment can also be filtered for sensitive diagnoses that are
prohibited for transmission under certain state or federal laws.
A number of commenters expressed concerns about requiring the
inclusion of diagnosis, noting that hospitals may not have this
information at the time of admission, when only the presenting symptom
may be available, or immediately at discharge. Other commenters noted
that while this is important information for improving care
coordination, diagnosis is not included in the most basic versions of
the HL7 ADT messaging standard. Other commenters noted that clinical
data is more appropriate for transfer through other standards for
sharing clinical data, such as the C-CDA standard, which is specified
to support the exchange of clinical summaries using certified health
IT. These commenters noted that rather than requiring the inclusion of
diagnosis in the patient event notification, it would make more sense
to allow hospitals to transfer this information by attaching a clinical
summary to the notification, or by providing this information upon
request from a receiving provider.
Response: We agree with commenters that diagnosis is an important
data element to share during care transitions. However, our intention
for this proposal has been to set a minimal floor for patient event
notifications, allowing for significant flexibility, in recognition of
the wide variety of ways that providers are currently implementing
patient event notifications. We are concerned that the proposed
requirement to include diagnosis could introduce unnecessary burden for
hospitals that will be seeking to satisfy this requirement utilizing
the most basic information available in an ADT message to support
patient event notifications. As a result, we are not finalizing a
requirement that diagnosis must be included in patient event
notifications at 42 CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2).
We wish to reiterate that this final policy in no way precludes
hospitals from including additional information, such as diagnosis, in
a patient event notification. We also note that hospitals are required
to send other necessary medical information to receiving providers
under the hospital CoP on Discharge Planning at 42 CFR 482.43. In
addition, certain clinical information such as diagnosis is included in
the summary of care record which hospitals must be capable of
transferring electronically in order to meet the health information
exchange measures under the Promoting Interoperability Program.
Comment: Several commenters suggested CMS require hospitals to
include additional informational elements in patient event
notifications, such as: Discharge disposition; chief complaint;
medication profile; insurance policy coverage information; additional
information about the hospital, such as address and tax ID; contact
information for a variety of resources such as social services agencies
and legal assistance providers; and other information that can be used
for patient matching. Commenters believe that additional information
would have a positive impact on care coordination. Other commenters
supported the proposal to require only a limited data set. One
commenter recommended that CMS impose additional parameters on the
information included as part of patient event notifications, including
a requirement that data must be recent and relevant to patient care.
Response: We appreciate commenters' suggestions, and agree that
this additional information can have a positive impact on care
coordination, patient matching, and other requirements. However, we do
not believe that this information should be required within the CoPs
for patient event notifications. We have heard from many stakeholders
that even patient event notifications with extremely limited
information can have a positive effect on care coordination when they
are delivered in a timely manner. In addition, we understand that
hospitals are currently delivering patient event notifications with
widely varying sets of information. Finally, we note that hospitals are
required to send other necessary medical information to receiving
providers under the hospital CoP on Discharge Planning at 42 CFR
482.43. While we decline to require additional data at this time, to
ensure that hospitals are able to satisfy the requirement with minimal
effort, we encourage hospitals to consider other information that can
be added to patient event notifications to support care coordination.
Comment: Many commenters suggested that CMS work with ONC to add a
certification criterion or a condition of certification related to the
transmission of patient event notifications under ONC's certification
program. Many commenters stated that hospitals should not be required
to comply with the proposed requirements until they have had an
opportunity to adopt certified technology supporting these
requirements. Commenters believed this would assure hospitals that
their systems are compliant with the proposed requirements. Moreover,
commenters expressed concern that without complementary regulation
directed toward health IT developers, the burden for ensuring these
technical capabilities would rest on hospital providers alone. Some
commenters suggested that ONC should also include data elements related
to patient event notifications in the USCDI, or seek to standardize
notification data elements in another way, to ensure that notifications
can be received by other EHR systems. Commenters also pointed to a
variety of emerging initiatives which focus on barriers to information
exchange, such as TEFCA, policies to address information blocking, and
updates to API technology under the ONC certification program.
Commenters urged CMS to leverage these initiatives to advance the use
of patient event notifications, for instance, by incorporating patient
event notification functionality through the networks established as
part of TEFCA.
Response: We appreciate commenters' input. As we noted in the CMS
Interoperability and Patient Access proposed rule, there is currently
no certification criterion specific to creating and sending electronic
patient event notifications included in ONC's certification program (84
FR 7651). While ONC monitors the development of consensus standards for
patient event notifications as part of its ISA (https://www.healthit.gov/isa/admission-discharge-and-transfer), ONC has not yet
proposed to develop a certification criterion based on any of these
standards. Instead of focusing on the use of a specific certification
criterion, we have sought to allow hospitals flexibility in how they
satisfy the proposed CoP. We believe this is consistent with current
practices around patient event notifications that have been implemented
in a wide variety of ways across hospitals. We appreciate that many
other policy initiatives may intersect with how hospitals implement
patient event notification requirements. While we believe that
providers will be
[[Page 25598]]
able to implement patient event notifications based on existing systems
and infrastructure, we believe that many of the initiatives commenters
mentioned will help to enable and enhance notification capabilities as
they are introduced.
Comment: A number of commenters stated that the proposal would
disproportionately burden rural and critical access hospitals.
Commenters noted that providers in these settings may not have an EHR
system, or may be unable to upgrade to the newest edition of certified
technology. For small and rural providers that do have an EHR system,
commenters expressed concern about the implementation costs providers
would need to incur as they work with their EHR vendors to deploy new
functionality. Commenters noted that, while working with an
intermediary could substantially reduce the burden associated with this
proposal, many small and rural hospitals are operating in geographic
areas that are not yet served by entities such as health information
exchanges that could serve as intermediaries, requiring these hospitals
to dedicate significant resources to developing a compliant solution.
This lack of access to appropriate infrastructure would put small and
rural hospitals at disproportionate risk of noncompliance with the CoP
standard, despite the significant effects penalties for noncompliance
may have on underserved communities. Several commenters raised concerns
about these providers' ability to shoulder compliance costs with the
proposed requirements, and suggested CMS provide funding opportunities
to these hospitals to mitigate the potential burden associated with the
proposal.
Response: We appreciate commenters' concerns about the impact of
this proposal on small, rural, and critical access hospitals (CAHs). We
note that those hospitals without an EHR system with the technical
capacity to generate information for electronic patient event
notifications, defined as a system conformant with the ADT messaging
standard (HL7 2.5.1), will not be subject to this final rule.
Furthermore, we believe that changes finalized in this rule will ease
some of the potential compliance burden associated with the rule, and
make it easier for these hospitals to comply successfully with the CoP
standard. For example, our final policy extends the applicable date for
the requirements as well as defining a more limited set of a recipients
to whom hospitals must send notifications for the purposes of
compliance with the CoP.
Comment: Many commenters noted that patient event notifications are
most effective when they take into account receiving providers'
preferences. Commenters noted that recipients need flexibility to
determine the information that they want to be notified about, the
frequency of notification delivery, and how they would like
notifications delivered; otherwise providers may experience ``signal
fatigue'' due to receiving an excessive number of messages that do not
contain information the provider finds useful. Commenters expressed
concern that, under the proposed requirements, hospitals would not have
flexibility to take into account receiving providers' preferences for
receiving patient event notifications. They further believed that the
proposed requirements would result in hospitals sending information to
all providers regardless of their interest in receiving notifications,
while implementation experience has shown that notifications are more
successful when receiving providers can request the information they
would like to receive.
Response: We appreciate commenters' concerns about the importance
of incorporating provider recipients' preferences when implementing
patient notification systems. We understand from stakeholders that a
key feature of successful patient event notification implementations is
flexibility with respect to the manner in which notifications are
delivered, to allow for better alignment with individual providers'
workflows. Without such flexibility, providers are more likely not to
find notification systems useful, reducing their effectiveness to
improve care coordination.
We note that under the proposed requirement, hospital systems must
send patient notifications in accordance with the proposed
requirements. However, this would not preclude hospitals, working
either directly with providers or through an intermediary, from
tailoring the delivery of patient notifications in a manner consistent
with individual provider preferences. For instance, while a hospital's
system must be able to send notifications at both admission and
discharge, as well as at the time of registration in the emergency
department, if a specific provider prefers only to receive
notifications upon discharge, nothing would prevent the hospital from
limiting the notifications sent to that provider accordingly.
We note that our revised regulation text states that hospitals must
send notifications to those recipients that ``need to receive
notification of the patient's status for treatment, care coordination,
or quality improvement purposes.'' We believe that this standard will
allow hospitals the discretion to determine which recipients need to
receive notifications, for instance, by declining to send certain
notifications where a practitioner has stated that such notifications
are not necessary or effective for supporting care coordination. In
cases where the hospital has partnered with an intermediary to deliver
notifications, the intermediary may exercise this discretion on behalf
of a hospital.
Comment: Many commenters supported the proposal to allow use of an
intermediary to deliver patient event notifications. Commenters stated
that use of an intermediary could reduce operational burden on
hospitals by maintaining recipient information, supporting more
effective patient matching, and delivering notifications in accordance
with receiving providers' preferences. Commenters pointed to numerous
examples of how intermediaries, such as health information exchanges,
are successfully facilitating the delivery of more complete and
accurate patient event notifications from today.
Response: We thank commenters for their support and agree that the
use of intermediaries to deliver patient notifications can reduce
burden on hospitals and support effective notification systems.
Comment: Several commenters sought additional information on our
proposals with respect to the use of an intermediary, and whether
exclusive use of an intermediary, provided other requirements are met,
would satisfy the CoP. Commenters stated that they believe hospitals
should be able to exclusively make use of an intermediary. Other
commenters suggested that CMS should ``deem'' a hospital compliant with
the CoP if they demonstrate that they are using an intermediary to
deliver notifications, as long as the intermediary has not been found
to violate information blocking rules.
Response: In the CMS Interoperability and Patient Access proposed
rule, we stated that, if finalized, hospitals would be required to send
notifications ``directly or through an intermediary that facilitates
exchange of health information.'' We believe this would allow exclusive
use of either method, or a combination of these methods, provided other
requirements of the CoP are met. For instance, if a hospital makes
exclusive use of an intermediary to satisfy the CoP, the hospital would
still be subject to the requirement that
[[Page 25599]]
notifications must be sent to the set of recipients we are finalizing
in this rule, specifically all applicable post-acute care services
providers and suppliers as well as a patients' primary care
practitioners or practice groups and entities primarily responsible for
a patient's care, as well as practitioners identified by the patient.
Given this requirement, exclusive use of an intermediary with a limited
ability to deliver notifications to the specified set of recipients,
for instance an intermediary which restricts its delivery to only those
providers within a specific integrated health care system, would not
satisfy the CoP. Alternatively, if a hospital demonstrates that an
intermediary connects to a wide range of recipients and does not impose
restrictions on which recipients are able to receive notifications
through the intermediary, exclusive use of such an intermediary would
satisfy the CoP.
Comment: Commenters sought additional information on whether it
would be permissible for a hospital to delegate responsibility for
making a determination about the existence of a patient's care
relationships to an intermediary that facilitates delivery of a patient
notification.
Response: In the CMS Interoperability and Patient Access proposed
rule we discussed a variety of methods through which hospitals can
identify recipients for patient notifications, including through
partnering with intermediaries such as health information exchanges (84
FR 7652). We reiterate that we believe this is one way that hospitals
are currently identifying recipients for notifications, and that using
an intermediary to do so may reduce operational burden for hospitals.
Thus, hospitals would be permitted to delegate this authority.
Comment: Several commenters requested additional information on
whether ACOs would be entitled to receive patient event notifications.
Commenters stated that ACOs represent groups of providers and suppliers
and work directly on their behalf. Therefore, it was unclear whether
they would be considered intermediaries or providers and suppliers for
the purposes of the proposed CoP. Commenters stated that patient event
notifications are used by many ACOs today, and that ACOs both receive
notifications directly from hospitals and through other intermediaries
such as health information exchanges.
Response: We note that the proposed CoP does not create an
entitlement for any specific provider or intermediary to receive
patient event notifications. Rather, it requires hospitals to
demonstrate that their medical records system sends patient event
notifications in a manner compliant with the proposed requirements. We
believe there is nothing in the proposed requirements that would
prevent ACOs that have business associate relationships with the
intended primary care practitioner or practice group or entity from
receiving patient event notifications on behalf of that practitioner,
group, or entity so long as their business associate agreement allows
them to fulfill that role.
Comment: Several commenters suggested that CMS should develop a
mechanism for allowing community providers to report that they have not
received notifications from a given hospital, or that the notifications
received are incomplete or unreasonably delayed. Commenters believe
that such a mechanism would ensure patient event notification systems
are functional and help to establish delivery parameters across a
community.
Response: We appreciate commenters' input, but are unclear here as
to whether the commenters are requesting that we develop a regulatory
mechanism within the CoP provisions to allow for a community provider
to report to a hospital any issues it may be experiencing with the
hospital's notification system or if the request is for CMS to develop
some other type of mechanism to accomplish this, such as an incentive-
based payment mechanism as a means of encouraging a hospital to include
this reporting function as part of its notification system. If it is
the latter type of request, then such a mechanism would be outside the
scope of the CoPs and this section of the rule. However, if it is the
former type of request, we will consider these ideas as we evaluate
future updates and revisions to the CoPs with regard to patient event
notifications.
Comment: We proposed that a hospital would only need to send
notifications to those practitioners for whom the hospital has
reasonable certainty of receipt (84 FR 7652). We further explained that
we expected hospitals would, to the best of their ability, seek to
ensure that notification recipients were able to receive notifications,
but that we recognized that factors outside of the hospital's control
may determine whether or not a notification was successfully received
and utilized by a practitioner.
Many commenters stated that a standard of ``reasonable certainty''
would hold hospitals responsible for factors outside of their control
that prevent delivery of notifications, and that hospitals should only
be held accountable for transmission of information, not receipt.
Commenters stated that it would be very difficult for hospitals to
obtain reasonable certainty given the limitations of the infrastructure
that is currently available for sharing health information. Several
commenters believed that the phrase ``reasonable certainty'' would
impose a new affirmative duty to validate receipt of notifications,
which would result in significant additional administrative burden for
hospitals. Several commenters suggested that CMS replace the term
``reasonable certainty'' with alternatives such as ``reasonable
effort'' or ``reasonable confidence.'' They believed these alternative
standards would better reflect actions within the hospital's control.
Response: We appreciate commenters' feedback. In proposing that
hospitals send notifications to those practitioners for whom the
hospital has reasonable certainty of receipt, we sought to adapt a
similar standard currently identified in guidance for the Promoting
Interoperability Program (see https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/MedicareEH_2019_Obj2-.pdf) regarding the expectations of participants
in that program when they transfer a summary of care record to another
provider. However, we concur with commenters that a standard of
``reasonable certainty,'' while appropriate for the Promoting
Interoperability Program, in which participants are required to use
certified technology for the transmission and receipt of summary of
care documents, may not be appropriate in the context of this proposal,
which permits flexibility in both the technology used to send and
receive patient event notifications and the format of the notification
itself. We agree that a standard that better reflects actions within
the hospital's control would be much more appropriate in this
circumstance. Accordingly, we are revising our final policy (at 42 CFR
482.24(d)(5), 482.61(f)(5), and 485.638(d)(5)) to now require that a
hospital (or a CAH) must demonstrate that it ``has made a reasonable
effort to ensure that'' the system sends the notifications to any of
the following that need to receive notification of the patient's status
for treatment, care coordination, or quality improvement purposes to
all applicable post-acute care services providers and suppliers and:
(1) The patient's established primary care practitioner; (2) the
patient's established primary care practice group or entity; or (3)
other
[[Page 25600]]
practitioner, or other practice group or entity, identified by the
patient as the practitioner, or practice group or entity, primarily
responsible for his or her care.
We believe that this modified standard will provide hospitals and
CAHs with appropriate flexibility and can account for the constraints
of providers' existing systems. We also believe that this modified
standard takes into account the fact that some recipients may not be
able to receive patient event notifications, or may not be able to
receive notifications in a manner consistent with a hospital system's
capabilities, and the fact that hospitals and CAHs may not be able to
identify provider recipients for some patients. We expect that
surveyors will evaluate whether a hospital is making a reasonable
effort to send patient event notifications while working within the
constraints of its existing technology infrastructure.
Comment: Several commenters offered their assessments of readiness
across hospitals to implement patient event notifications. One
commenter pointed to hospitals' high levels of engagement in some form
of health information exchange as an indication that hospitals are
well-positioned to distribute patient event notifications, and stated
that establishing ADT-based notification feeds did not impose
significant burdens on hospitals. Another commenter agreed that the
technical capabilities to implement notifications exists today, and
stated that the primary challenge for hospitals would be in updating
business and operational practices to comply.
Other commenters stated that functionality to use ADT message
information for patient event notifications is not part of certified
electronic health record technology and that not all EHRs are capable
of generating notifications. They stated that EHRs are not able to
automatically send and receive notifications and cautioned CMS against
oversimplifying the development burden associated with implementation.
One commenter suggested that CMS should provide supplemental funding to
support hospitals' costs, workflow changes, and technical expertise
associated with implementation.
Response: We thank commenters for their insights. We share the
assessment of commenters who stated that most hospitals will be able to
implement patient event notifications with minimal burden due to the
widespread adoption of technology systems that can be utilized to
support generating and sending these notifications. Patient event
notifications have been widely recognized as an important way to
support patient safety, by enabling providers and suppliers responsible
for the post-discharge care of a patient to quickly initiate care
coordination protocols that can mitigate the risk of deterioration of a
patient's condition following a hospital stay. We understand some
commenters' concerns that the ability to send patient event
notifications has not been included as a capability certified under the
ONC certification program, and that there is no widely adopted, uniform
approach to sending patient event notifications at this time. However,
as noted by many commenters, we believe there are a wide variety of
available, low-cost solutions that providers can adopt to fulfill the
minimal requirements described in this final rule. Accordingly, we have
provided significant flexibility for providers to meet these
requirements by not including additional technical specifications about
how patient event notifications must be formatted and shared. We
believe that this approach allows flexibility for hospitals to
establish patient event notifications that meet the requirements in
ways that minimize implementation burden; however, we recognize that
the lack of a uniform approach may lead to instances where a provider
is unable to receive notifications sent by a hospital in a seamless,
interoperable fashion.
Comment: Commenters stated that national infrastructure for health
information exchange was not yet mature enough to support the
widespread implementation of patient event notifications and that
successful implementation of notifications requires the ability to
acquire data feeds and a rules engine to support alerting routing and
delivery, as well as a patient index function to create and verify
patient panels. While many commenters believed that this infrastructure
might be available in the future, for instance, through establishment
of the TEFCA, they stated that it is not ubiquitous today. Without this
infrastructure, commenters noted that providers would be required to
support a large number of point-to-point interfaces with other
providers that lack scalability, and will be highly costly,
inefficient, and burdensome to develop and maintain. One commenter
recommended that CMS establish that, for compliance purposes, a
hospital would only be required to demonstrate a notification has been
sent for a single patient. This would allow surveyors to confirm that
the system is functional while allowing for variation across hospitals
depending on their capabilities to send notifications under different
circumstances. One commenter suggested that CMS should focus on
incentivizing providers to participate in existing scalable networks
that support health information exchange, including patient event
notifications.
Response: We agree with commenters that the national health
information exchange infrastructure to support patient event
notifications is not yet ubiquitous. However, we believe that the
health information infrastructure that exists today will be sufficient
to provide substantial support for the requirements we are finalizing
in this rule. As other commenters noted, organizations such as health
information exchanges are supporting the sharing of patient event
notifications in many areas today. While we understand there is
variation in availability of this infrastructure, we believe there are
options increasingly available for hospitals to implement basic patient
event notifications that will allow hospitals to demonstrate they have
made a ``reasonable effort'' to ensure their system sends the required
notifications, as per the policy finalized in this final rule.
We appreciate the suggestion that the CoP should specify a hospital
could achieve compliance through demonstrating that a notification has
been sent for a single patient, and that this would ease compliance
concerns expressed by stakeholders. However, we believe that these
concerns are addressed through the more limited standard in our final
policy that requires a hospital (or CAH) to make a ``reasonable
effort'' to ensure that its system sends these notifications. In
addition, and as previously noted, survey and certification
interpretive guidelines utilize a variety of approaches to evaluate
whether a hospital has satisfied the CoP, and in this final rule we
decline to employ overly prescriptive regulatory language that might
significantly limit options for surveyors as they assess compliance.
Comment: Many commenters identified challenges related to the
proposal that a hospital demonstrate that its system sends
notifications to licensed and qualified practitioners, other patient
care team members, and post-acute care services providers and suppliers
meeting certain conditions (84 FR 7651). Commenters stated that the
proposal seemed to require a hospital to be able to send a notification
to any other health care provider and assumed that the receiving
provider would have the technological capabilities to receive this
information. Commenters stated that this is not realistic given the
current
[[Page 25601]]
state of technology adoption among receiving providers, and that
recipients would need to develop capabilities to receive, incorporate,
and use these notifications for the proposal to be effective.
Commenters stated that, today, notifications would only be likely
to reach recipients only a percentage of the time citing many factors
related to the limitations of EHR technology that prevent providers and
clinicians from incorporating electronic information into their EHRs.
For instance, commenters noted that EHRs must be able to confidentially
match transferred data to a patient, incorporate the notification into
the EHR, and ensure that it is reviewed and stored in a clinically
appropriate way to ensure it is effectively used. Commenters stated
that CMS should consider complementary requirements and/or supports for
ambulatory and other facilities to ensure they are able to receive
patient event notifications provided by hospitals. Commenters requested
additional information on the expectations for receiving providers to
successfully receive and incorporate patient event notifications, and
noted they may face significant burden associated with technical
development if expected to be able to receive these notifications.
Moreover, commenters expressed concerns about the capacity of
specific providers, including small and rural physician practices and
post-acute care providers and suppliers, to receive patient event
notifications. Commenters specifically noted that post-acute care
providers were not provided financial incentives under the HITECH, and
therefore many post-acute care providers are not using EHRs or are
using EHRs that are not able to exchange information with hospital
EHRs. Several commenters recommended that CMS not hold hospitals
accountable for delivering patient event notifications to post-acute
care suppliers, given the difficulties these suppliers would have in
receiving these notifications. Others stated that the inability of
these providers to receive notifications would limit the effectiveness
of the proposed requirements.
Response: We appreciate commenters input on this issue. In the CMS
Interoperability and Patient Access proposed rule, we stated that a
hospital subject to the proposed requirements must demonstrate that its
system sends notifications to certain recipients. We do not expect that
a hospital would ``demonstrate'' that its system meets these
requirements through meeting a comprehensive measure of performance.
Likewise, we would not expect a hospital's system to be capable of
electronically communicating with every possible provider, facility, or
practitioner system, or of satisfying every possible preference for
delivery of patient event notifications that a provider, facility, or
practitioner might attempt to impose on the hospital. As noted above,
we are modifying our proposal to require that a hospital makes a
``reasonable effort'' to ensure that its system sends patient event
notifications to the specified recipients.
Under the survey and certification process we would expect a
hospital to demonstrate its system's compliance with the CoP in a
variety of ways, subject to the system's capabilities. For instance, if
a given system sends notifications via Direct messaging, we might
expect surveyors to review whether the hospital has a process in place
for capturing Direct addresses of patients' primary care practitioners
to enable the system to send patient event notifications to these
recipients.
Finally, with regard to comments about PAC services providers and
suppliers that were not eligible for incentives for EHR adoption under
the EHR Incentive Programs established by the HITECH Act, we again note
that the requirements in this final rule are limited to only those
hospitals and CAHs that possess and utilize EHR or other administrative
systems with the technical capacity to generate information for
electronic patient event notifications. Moreover, a hospital or CAH
with such a system must only demonstrate that it has made a
``reasonable effort'' to ensure that its system sends notifications to
any of the specified recipients, including all applicable post-acute
care services providers and suppliers (that is, to those PAC services
providers and suppliers to whom the patient is being transferred or
referred).
Comment: In the CMS Interoperability and Patient Access proposed
rule, we did not explicitly address the effective implementation date
for the proposed revisions to the CoPs. However, we note that revisions
to the CoPs are generally applicable 60 days from the publication of a
final rule.
Many commenters recommended CMS allow additional time for
implementation beyond the usual applicable date of these revisions.
Commenters stated that additional time was required to allow providers
to complete technical upgrades and train staff on new workflows. One
commenter suggested that CMS finalize different timeframes based on
whether hospitals are in an area with existing infrastructure for
transmitting patient event notifications. Another commenter suggested
that CMS develop working groups to determine appropriate timelines for
implementation.
Response: We agree with commenters that additional time would be
appropriate for hospitals and CAHs to implement the proposed
requirements. Therefore, we are finalizing that the requirements will
be applicable 12 months after the publication date of this final rule.
Comment: Multiple commenters addressed privacy implications of the
proposed requirements. Commenters sought clarity on whether patient
consent would be required to send a patient event notification, or
whether hospitals would be able to honor a patient's request to opt-out
of sharing information with providers in the form of a patient event
notification. Commenters urged CMS to issue further guidance about
privacy and security challenges associated with sending patient event
notifications, for instance, how hospitals should address cases where
they cannot confirm the identity of a provider, and/or where
transmission could risk improper disclosure of protected health
information. Several commenters suggested that concerns about
noncompliance could lead some hospitals to be overly hasty in sending
patient event notifications without considering the privacy impact of
the transmission, potentially leading to inappropriate disclosures of
information.
Response: We appreciate commenters' concerns about preserving
patient privacy. Nothing in this proposed rule should be construed to
supersede hospitals' compliance with HIPAA or other state or federal
laws and regulations related to the privacy of patient information. We
note that hospitals would not be required to obtain patient consent for
sending a patient event notification for treatment, care coordination,
or quality improvement purposes as described in this final policy.
However, we also recognize that it is important for hospitals to be
able to honor patient preferences to not share their information. While
the CoP would require hospitals to demonstrate that their systems can
send patient event notifications, we do not intend to prevent a
hospital from recording a patient's request to not share their
information with another provider, and, where consistent with other
law, restrict the delivery of notifications as requested by the patient
and consistent with the individual right to request restriction of uses
and disclosures established in the
[[Page 25602]]
HIPAA Privacy Rule. Similarly, if a hospital is working with an
intermediary to deliver patient event notifications, the intermediary
may record information about a patient's preferences for how their
information is shared, and, where consistent with other law, restrict
the delivery of notifications accordingly. Based on commenters'
concerns regarding a patient's ability to request that his or her
medical information (in the form of a patient event notification) is
not shared with other settings, we are revising and finalizing a
requirement in this rule that a hospital (or CAH) must demonstrate that
its notification system sends notifications, ``to the extent
permissible under applicable federal and state law and regulations and
not inconsistent with the patient's expressed privacy preferences.''
Regarding improper disclosure of health information where a
hospital cannot confirm the identity of a receiving provider, we note
that under this policy a hospital would not be under any obligation to
send a patient event notification in this case. Under our final policy,
hospitals would be required to make a ``reasonable effort'' to ensure
their systems send notifications to the specified recipients. We
believe this standard will account for instances in which a hospital
(or its intermediary) cannot identify an appropriate recipient for a
patient event notification despite establishing processes for
identifying recipients, and thus is unable to send a notification for a
given patient.
Comment: Many commenters raised concerns about how hospitals would
be able to implement the proposed patient event notifications while
complying with state and federal laws and regulations around the
transmission of sensitive data. Commenters noted these issues are
particularly relevant for psychiatric hospitals included in the
proposal. Commenters noted that some states have more stringent privacy
and consent requirements that apply to individuals treated in mental
health facilities which may impact the sending of patient event
notifications. One commenter noted that hospitals with behavioral
health units do not disclose patient event information as part of their
primary system data feed due to requirements that disclosure of this
information must be accompanied by written consent. Commenters also
noted that appropriately segregating this data is expensive and time
consuming.
Response: Nothing in this requirement should be construed as
conflicting with hospitals' ability to comply with laws and regulations
restricting the sharing of sensitive information. While hospitals
subject to the CoP would need to demonstrate their system sends
notifications to appropriate recipients, hospitals would not be
expected to share patient information through a notification unless
they have obtained any consents necessary to comply with existing laws
and regulations.
Comment: Many commenters supported the proposal to require a
hospital's system demonstrate that it sends patient event notifications
at the time of admission, and at, or just prior to, the time of
discharge. Commenters emphasized that it is important for notification
information to be timely in order for it to be effective in improving
care coordination. One commenter stated that some providers find that
notifications triggered by an ADT message are triggered too early,
prior to the availability of a discharge summary, and sought additional
information about whether hospitals may use other triggers for a
patient event notification.
Response: We appreciate commenters' support for the proposal. We
believe patient event notifications are most useful when tied to
admission (or registration, as is the term generally used for patients
seen in the ED) and discharge events, as receiving near-real time
information about a patient's hospitalization can ensure receiving
providers, facilities, and practitioners are able to act quickly to
ensure successful care coordination. While we agree that sending
available clinical information along with a patient event notification
can be helpful, we believe that delaying notifications until all of the
information about a patient's hospitalization is available would likely
decrease the value of the notification.
Comment: Several commenters suggested that the requirements should
be limited to external providers and not include providers that may
share the same EHR as the hospital as part of an integrated delivery
system. Commenters noted that organizations may have other ways to
notify these providers about a discharge, and that hospitals should be
exempt from sending notifications to these providers.
Response: Under the proposed requirements, we are not specifying a
format or transport method for patient event notifications.
Accordingly, hospitals could use a mix of approaches to deliver patient
event notifications, for instance, by partnering with an intermediary
to deliver notifications to external providers, while using features
internal to a shared EHR system to transmit information to providers
that are part of the same organization.
Comment: Several commenters sought clarity on how the patient event
notifications would relate to information blocking policy, and urged
CMS to ensure that any new CoP requirements are aligned with other
policies around information blocking. Several commenters suggested
that, as an alternative to the proposed requirements, CMS should
establish a standard under the CoPs that states hospitals will not
engage in information blocking, to be aligned with policies established
by ONC in the 21st Century Cures Act final rule.
Response: We note that there are currently three prevention of
information blocking attestation statements under 42 CFR
495.40(b)(2)(i)(I)(1) through (3) to which eligible hospitals and CAHs
must attest for purposes of the Promoting Interoperability Program. As
part of successfully demonstrating that an eligible hospital or CAH is
a meaningful EHR user for purposes of the Promoting Interoperability
Program, the eligible hospital or CAH must submit an attestation
response of ``yes'' for each of these statements. These attestations
are discussed further in section VIII. of this final rule. We also
refer commenters to section 3022(b)(2)(B) of the Public Health Service
Act (PHSA), which provides that any health care provider determined by
the OIG to have committed information blocking shall be referred to the
appropriate agency to be subject to appropriate disincentives using
authorities under applicable federal law, as set forth by the Secretary
through notice and comment rulemaking. Further, we refer commenters to
the ONC 21st Century Cures Act proposed rule for additional discussion
on disincentives (84 FR 7553).
Final Action: After consideration of the comments received, and for
the reasons outlined in our response to these comments and in the CMS
Interoperability and Patient Access proposed rule, we are finalizing
these proposals with some modifications and reorganization of the
provisions. These policies are being finalized at 42 CFR 482.24(d),
482.61(f), and 485.638(d) for Conditions of Participation for
hospitals, psychiatric hospitals, and specialized providers (CAHs).
Based on public comments, and to further advance electronic
exchange of information that supports effective transitions of care for
patients between hospitals and CAHs and their community PAC services
providers and suppliers as well as their primary care practitioners,
the following requirements at 42 CFR 482.24(d),
[[Page 25603]]
482.61(f), and 485.638(d) are being finalized here with modifications
and reorganization from the proposed requirements (84 FR 7678):
We are revising 42 CFR 482.24(d) by deleting the reference
to ``paragraph (d)(2) of this section'';
We are revising 42 CFR 482.61(f) by deleting the reference
to ``paragraph (d)(2) of this section'';
We are revising 42 CFR 485.638(d) by deleting the
reference to ``paragraph (d)(2) of this section'';
We are revising 42 CFR 482.24(d) by adding new language to
the regulatory text so that it now includes ``or other electronic
administrative system, which is conformant with the content exchange
standard at 45 CFR 170.205(d)(2),'';
We are revising 42 CFR 482.61(f) by adding new language to
the regulatory text so that it now includes ``or other electronic
administrative system, which is conformant with the content exchange
standard at 45 CFR 170.205(d)(2),'';
We are revising 42 CFR 485.638(d) by adding new language
to the regulatory text so that it now includes ``or other electronic
administrative system, which is conformant with the content exchange
standard at 45 CFR 170.205(d)(2),'';
We are deleting all of the regulatory text proposed at 42
CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2), including the
inaccurate references to ``45 CFR 170.205(a)(4)(i);''
We are redesignating 42 CFR 482.24(d)(3), 482.61(f)(3),
and 485.638(d)(3) as 42 CFR 482.24(d)(2), 482.61(f)(2), and
485.638(d)(2), respectively, and also revising the regulatory text to
now state that the system sends notifications that must include at
least patient name, treating practitioner name, and sending institution
name;
We are redesignating 42 CFR 482.24(d)(4), 482.61(f)(4),
and 485.638(d)(4) as 42 CFR 482.24(d)(3), 482.61(f)(3), and
485.638(d)(3), respectively, and also revising the regulatory text to
now state that, ``to the extent permissible under applicable federal
and state law and regulations, and not inconsistent with the patient's
expressed privacy preferences, the system sends notifications directly,
or through an intermediary that facilitates exchange of health
information, at the time of: the patient's registration in the
hospital's [or CAH's] emergency department (if applicable); or the
patient's admission to the hospital's [or CAH's] inpatient services (if
applicable).''
We are redesignating 42 CFR 482.24(d)(5), 482.61(f)(5),
and 485.638(d)(5) as 42 CFR 482.24(d)(4), 482.61(f)(4), and
485.638(d)(4), respectively, and also revising the regulatory text to
state that, ``to the extent permissible under applicable federal and
state law and regulations, and not inconsistent with the patient's
expressed privacy preferences, the system sends notifications directly,
or through an intermediary that facilitates exchange of health
information, at the time of: the patient's discharge or transfer from
the hospital's [or CAH's] emergency department (if applicable): or the
patient's discharge or transfer from the hospital's [or CAH's]
inpatient services (if applicable).''
We are deleting the regulatory text proposed at 42 CFR
482.24(d)(5), 482.61(f)(5), and 485.638(d)(5) and adding new regulatory
text to state that, ``the hospital [or CAH] has made a reasonable
effort to ensure that the system sends the notifications to all
applicable post-acute care services providers and suppliers, as well as
to any of the following practitioners and entities, which need to
receive notification of the patient's status for treatment, care
coordination, or quality improvement purposes: the patient's
established primary care practitioner; the patient's established
primary care practice group or entity; or other practitioner, or other
practice group or entity, identified by the patient as the
practitioner, or practice group or entity, primarily responsible for
his or her care.''
Finally, recognizing that hospitals, including psychiatric
hospitals and CAHs, are on the front lines of the COVID-19 public
health emergency, and in response to the number of comments received
regarding concerns with the applicability date for this rule, we are
establishing an applicability date of 12 months after finalization of
this rule for hospitals, including psychiatric hospitals, and CAHs to
allow for adequate and additional time for these institutions,
especially small and/or rural hospitals as well as CAHs, to come into
compliance with the new requirements.
XI. Provisions of the Final Regulations
Generally, this final rule incorporates the provisions of the CMS
Interoperability and Patient Access proposed rule as proposed. The
following provisions of this final rule differ from the proposed rule.
We are finalizing four proposals with modifications.
1. We are requiring MA organizations, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs to maintain a
process for the electronic exchange of, at a minimum, the data classes
and elements included in the content and vocabulary standard finalized
by HHS in the ONC 21st Century Cures Act final rule (published
elsewhere in this issue of the Federal Register) at 45 CFR 170.213
(currently version 1 of the USCDI), via a payer-to-payer data exchanged
as outlined in this section V. of this final rule. Specifically, we are
finalizing as proposed that impacted payers incorporate the data they
receive into the enrollee's record. We are finalizing that with the
approval and at the direction of a current or former enrollee, a payer
must send the defined information set to any other payer. In addition,
we specify that a payer is only obligated to send data received from
another payer under this policy in the electronic form and format it
was received.
Starting January 1, 2022, and for QHP issuers on the FFEs starting
with plan years beginning on or after January 1, 2022, the finalized
regulation requires these payers to make data available with a date of
service on or after January 1, 2016 that meets the requirements of this
section and which the payer maintains. In this way, payers only have to
prepare an initial historical set of data for sharing via this payer-
to-payer data exchange policy that is consistent with the data set to
be available through the Patient Access API, as finalized in section
III. of this final rule.
2. Regarding the Patient Access API, we are finalizing requirements
for MA organizations, Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to
implement and maintain a standards-based Patient Access API that meets
the technical standards as finalized by HHS in the ONC 21st Century
Cures Act final rule (published elsewhere in this issue of the Federal
Register) at 45 CFR 170.215, that include the data elements specified
in this final rule, and that permit third-party applications to
retrieve, with the approval and at the direction of a current enrollee,
data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221.
Specifically, we are finalizing that the Patient Access API must, at a
minimum, make available adjudicated claims; encounters with capitated
providers; provider remittances; enrollee cost-sharing; and clinical
data, including laboratory results (where maintained by the impacted
payer). We are not finalizing a requirement to include Provider
Directory information as part of the
[[Page 25604]]
Patient Access API. Instead, to limit burden, we are only requiring
provider and, in the case of MA-PD plans, pharmacy directory
information, be included in the Provider Directory API discussed in
section IV. of this final rule. Data via the Patient Access API must be
made available no later than one (1) business day after a claim is
adjudicated or encounter data are received by the impacted payer. We
are finalizing that MA organizations, Medicaid state agencies, Medicaid
managed care plans, CHIP state agencies, and CHIP managed care entities
must make available the date they maintain with a date of service on or
after January 1, 2016 beginning January 1, 2021, and for QHP issuers on
the FFEs beginning with plan years beginning on or after January 1,
2021.
3. We are finalizing a Provider Directory API for MA organizations,
Medicaid state agencies, Medicaid managed care plans, CHIP state
agencies, and CHIP managed care entities making standardized
information about their provider networks available via a FHIR-based
API conformant with the technical standards finalized by HHS in the ONC
21st Century Cures Act final rule (published elsewhere in this issue of
the Federal Register) at 45 CFR 170.215 (which include HL7 FHIR Release
4.0.1), excluding the security protocols related to user authentication
and authorization, or any other protocols that restrict the
availability of this information to anyone wishing to access it. At a
minimum, these payers must make available via the Provider Directory
API provider names, addresses, phone numbers, and specialties. For MA
organizations that offer MA-PD plans, they must also make available, at
a minimum, pharmacy directory data, including the pharmacy name,
address, phone number, number of pharmacies in the network, and mix
(specifically the type of pharmacy, such as ``retail pharmacy''). This
Provider Directory API must be fully implemented by January 1, 2021 for
all payers subject to this new requirement. Under this final rule, MA
organizations, Medicaid and CHIP FFS programs, Medicaid managed care
plans, and CHIP managed care entities must make the Provider Directory
API accessible via a public-facing digital endpoint on their website to
ensure public discovery and access.
Modifications being finalized for the timelines for these policies
will provide impacted payers ample time to build and test the required
standards-based APIs to meet the new API requirements. In addition,
providing more time for payer-to-payer data exchange between impacted
payers will ensure successful implementation, and better enable plans
to use a standards-based API to meet this requirement if they so
choose. We are not finalizing the Care Coordination through Trusted
Exchange Networks proposal. Although some commenters did show support
for the proposal, others raised strong concerns. Given the concerns
commenters raised specifically regarding the need for a mature TEFCA to
be in place first, and appreciating the ongoing work on the TEFCA being
done at this time, we are not finalizing this trusted exchange proposal
in this rule.
4. We are finalizing the Revisions to the Conditions of
Participation for Hospitals and Critical Access Hospitals proposal with
modifications that are based on public comments. Additionally, and
based on strong support from commenters, we are including patient event
notification requirements for any patient who accesses services in a
hospital (or CAH) emergency department. In response to the number of
comments received regarding concerns with the applicable date for this
policy, we are finalizing an applicability date of 12 months after
publication of this rule for hospitals, including psychiatric
hospitals, and CAHs to allow for adequate time for these institutions,
especially small and/or rural hospitals as well as CAHs, to come into
compliance with the new requirements.
All other policies are being substantially finalized as proposed.
XII. Collection of Information Requirements
Under the Paperwork Reduction Act of 1995, we are required to
provide 30-day notice in the Federal Register and solicit public
comment before a collection of information requirement is submitted to
the Office of Management and Budget (OMB) for review and approval. In
order to fairly evaluate whether an information collection should be
approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act
of 1995 requires that we solicit comment on the following issues:
The need for the information collection and its usefulness
in carrying out the proper functions of our agency.
The accuracy of our estimate of the information collection
burden.
The quality, utility, and clarity of the information to be
collected.
Recommendations to minimize the information collection
burden on the affected public, including automated collection
techniques.
We solicited public comment on each of these issues for the
following sections of this document that contain information collection
requirements (ICRs):
A. Background
Payers should have the ability to exchange data instantly with
other payers for care and payment coordination or transitions, and with
providers to facilitate more efficient care. Payers are in a unique
position to provide patients a complete picture of their claims and
encounter data, allowing patients to piece together their own
information that might otherwise be lost in disparate systems. To
advance our commitment to interoperability, we are finalizing our
proposals for the Patient Access API, the Provider Directory API, and
the payer-to-payer data exchange as discussed above.
We noted that these proposals were designed to empower patients by
making sure that they have access to health information about
themselves in a usable digital format and can make decisions about how,
with whom, and for what uses they will share it. By making claims data
readily available and portable to the enrollee, these initiatives
supported efforts to reduce burden and cost and improve patient care by
reducing duplication of services, adding efficiency to patient visits
to providers; and, facilitating identification of fraud, waste, and
abuse.
B. Wage Estimates
To derive average costs, we used data from the U.S. Bureau of Labor
Statistics' (BLS) May 2018 National Occupational Employment and Wage
Estimates (https://www.bls.gov/oes/current/oes_nat.htm). Table 1
presents the mean hourly wage, the cost of fringe benefits (calculated
at 100 percent of salary), and the adjusted hourly wage. In the CMS
Interoperability and Patient Access proposed rule, Table 1 was based on
the latest 2017 wage data (84 FR 7658). In this final rule, we have
updated Table 1 to reflect 2018 wage data, which is now the latest
available data.
[[Page 25605]]
Table 1--Occupation Titles and Wage Rates
----------------------------------------------------------------------------------------------------------------
Fringe Adjusted
Occupation title Occupation Mean hourly benefit ($/ hourly wage
code wage ($/hr) hr) ($/hr)
----------------------------------------------------------------------------------------------------------------
Administrators and Network Architects........... 15-1140 $45.09 $45.09 $90.18
Security Engineer............................... 17-2199 47.80 47.80 95.60
Computer and Information Analysts............... 15-1120 45.67 45.67 91.34
General Operations Manager...................... 11-1021 59.56 59.56 119.12
Operations Research Analysts.................... 15-2031 42.48 42.48 84.96
Software Developers, Applications............... 15-1132 51.96 51.96 103.92
Computer and Information Systems Managers....... 11-3021 73.49 73.49 146.98
Designers....................................... 27-1020 24.05 24.05 48.10
Technical Writer................................ 27-3042 36.30 36.30 72.60
Computer Systems Analysts....................... 15-1121 45.01 45.01 90.02
Network and Computer Systems Administrators..... 15-1142 41.86 41.86 83.72
Medical Records and Health Information 29-2071 21.16 21.16 42.32
Technician.....................................
Medical and Health Service Managers............. 11-9111 54.68 54.68 109.36
----------------------------------------------------------------------------------------------------------------
As indicated, we are adjusting the employee hourly wage estimates
by a factor of 100 percent. This is necessarily a rough adjustment,
both because fringe benefits and overhead costs vary significantly from
employer to employer, and because methods of estimating these costs
vary widely from study to study. Nonetheless, there is no practical
alternative and we believe that doubling the hourly wage to estimate
total cost is a reasonable accurate estimation method.
C. Information Collection Requirements (ICRs)
1. ICRs Regarding MMA File Requirements (42 CFR 423.910)
States transmit system generated data files, at least monthly, to
CMS to identify all dually eligible individuals, including full-benefit
and partial-benefit dually eligible beneficiaries (that is, those who
get Medicaid help with Medicare premiums, and often for cost-sharing).
The file is called the MMA file, but is occasionally referred to as the
``State Phasedown file.'' Section 423.910(d) requires states to
transmit at least one MMA file each month. However, states have the
option to transmit multiple MMA files throughout the month (up to one
per day). Most states transmit at least weekly. This information
collection activity is currently approved under OMB control number
0938-0958.
Ensuring information on dual eligibility status is accurate and up-
to-date by increasing the frequency of federal-state data exchange is
an important step toward interoperability. As a result, we proposed to
update the frequency requirements in 42 CFR 423.910(d) to require that
starting April 1, 2022, all states transmit the required MMA file data
to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1).
Daily would mean every business day, but if no new transactions are
available to transmit, data would not need to be transmitted on a given
business day. We estimate it would take a computer systems analyst
about 6 months (approximately 960 hours) to complete the systems
updates necessary to process and transmit the MMA data daily. After
completion of system updates, these system generated reports would be
set to run and transmitted to CMS on an automated production schedule.
As a result of updated information, we are revising the number of
states currently transmitting MMA daily data from 13 states, as stated
in the CMS Interoperability and Patient Access proposed rule, to 15
states. Consequently, we estimate a one-time aggregate burden for 36
entities (51 total entities (50 states and the District of Columbia)
minus the 15 states currently transmitting MMA daily data) to comply
with the requirement of transmission of daily MMA data at an aggregate
burden of $3,111,091 (36 entities * 960 hours * $90.02 per hour for a
computer system analyst to perform the updates). We have only estimated
the cost of system updates since the system transfers are done
automatically and this has no additional cost. We will be revising the
information collection request currently approved under 0938-0958 to
include the requirements discussed in this section.
2. ICRs Regarding API Proposals (42 CFR 422.119, 422.120, 431.60,
431.70, 438.242, 457.730, 457.760, 457.1233, and 45 CFR 156.221)
To promote our commitment to interoperability, we are finalizing
new requirements for a Patient Access API for MA organizations at 42
CFR 422.119, Medicaid FFS at 42 CFR 431.60, CHIP FFS at 42 CFR 457.730,
Medicaid managed care at 42 CFR 438.242(b)(5), CHIP managed care at 42
CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221.
Additionally, we are finalizing a publicly available Provider Directory
API for MA organizations at 42 CFR 422.120, at 42 CFR 431.70 for
Medicaid FFS, at 42 CFR 438.242(b)(6) for Medicaid managed care, at 42
CFR 457.760 for CHIP FFS, and at 42 CFR 457.1233(d)(3) for CHIP managed
care. We proposed to require these entities to establish standards-
based APIs that permit third-party applications to retrieve
standardized data for adjudicated claims, encounters with capitated
providers, provider remittances, beneficiary cost-sharing, reports of
lab test results, provider directories (and pharmacy directories for
MA-PDs), and preferred drug lists, where applicable. We finalized the
requirement for a Patient Access API and a Provider Directory API; this
final rule requires generally the same information as proposed to be
available through APIs but we are finalizing the requirement for two
APIs. Additionally, we proposed and are finalizing at 42 CFR
422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to
require MA organizations, Medicaid managed care plans, CHIP managed
care entities, and QHP issuers on the FFEs to maintain a process for
the electronic exchange of, at a minimum, the data classes and elements
included in the content standard adopted at 45 CFR 170.213 (currently
version 1 of the USCDI). To implement the new requirements for APIs and
payer to payer data exchange, we estimate that plans and states will
conduct three major work phases: Initial design, development and
testing, and long-term support and maintenance. In the proposed rule,
we provided detailed
[[Page 25606]]
estimations of the required labor categories and number of hours
required to implement the API provisions (84 FR 7659). We originally
estimated a one-time burden of $789,356.00 per organization or state
per implementation, with an ongoing maintenance cost $158,359.00 per
organization or state (84 FR 7659). We noted that, in the initial
design phase, we believed tasks would include: Determining available
resources (personnel, hardware, cloud space, etc.); assessing whether
to use in-house resources to facilitate an API connection or contract
the work to a third party; convening a team to scope, build, test, and
maintain the API; performing a data availability scan to determine any
gaps between internal data models and the data required for the
necessary FHIR resources; and, mitigating any gaps discovered in the
available data.
During the development and testing phase, we noted that plans and
states would need to conduct the following: Map existing data to HL7
\66\ FHIR standards, which would constitute the bulk of the work
required for implementation; allocate hardware for the necessary
environments (development, testing, production); build a new FHIR
server or leverage existing FHIR servers; determine the frequency and
method by which internal data are populated on the FHIR server; build
connections between the databases and FHIR server; perform capability
and security testing; and vet third-party applications, which includes
potentially asking third-party applications to attest to certain
privacy provisions.
---------------------------------------------------------------------------
\66\ Health Level Seven International (HL7[supreg]) is a not-
for-profit, ANSI-accredited standards development organization (SDO)
focused on developing consensus standards for the exchange,
integration, sharing, and retrieval of electronic health information
that supports clinical practice and the management, delivery and
evaluation of health services. Learn more at ``About HL7'' web page,
last accessed June 27, 2018.
---------------------------------------------------------------------------
After the completion of the API development, plans and states would
need to conduct the following throughout each year: Allocate resources
to maintain the FHIR server, which includes the cost of maintaining the
necessary patient data, and perform capability and security testing.
In the proposed rule, we proposed a new requirement for MA plans,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to maintain a process to coordinate care between
plans by exchanging, at a minimum, the USCDI at the enrollee's request
(84 FR 7640). Originally, we noted that we would allow multiple methods
for electronic exchange of the information, including use of the APIs.
Although we considered requiring the use of the FHIR-based API, we
understood that some geographic areas might have a regional health
information exchange that could coordinate such transactions. We also
noted other ways to exchange this data, such as: Direct plan-to-plan
exchange; leveraging connections to HIEs, or beneficiary-facing third-
party applications. Since the requirements for the payer-to-payer data
exchange and the API provisions share a content and vocabulary standard
and because plans will be investing in the development of the APIs in
this final rule, we believe that plans would overwhelmingly use these
APIs to meet the payer to payer data exchange requirements. As we had
no reliable way to determine which plans would utilize any of the
available methods to meet the payer-to-payer data exchange requirement
or how to determine the cost of each of these methods, given that each
plan could be at a different technology maturity level, we accounted
for costs for all impacted payers assuming the use of a newly developed
API to implement the payer-to-payer data exchange requirements, as this
would account for a higher effort options, and included this in our
original estimates for the API provisions.
We summarize the public comments we received on concerns raised
regarding our proposed cost of implementing and maintaining the APIs
and provide our responses.
Comment: Some commenters expressed concern that CMS underestimated
the complexity of implementing the API requirements and did not agree
with the agency's estimation that the API implementation is a one-time
cost. These commenters noted that additional costs include: The costs
to contract with third-party applications, the costs of ongoing
education, and the cost of answering questions from members about data
and errors. Commenters argued that the proposed API requirements
significantly add to overhead costs and will increase costs for
providers and payers, rather than facilitate information exchange and
better care for patients. One commenter estimated a range of between $1
million and $1.5 million to implement the API requirements, with an
additional $200,000 to maintain the API. Another commenter argued that
the costs of implementation could be as high as four times the
estimates CMS provided.
Response: We thank commenters for their input and understand their
concerns associated with the cost required to implement the
requirements of this final rule. We understand that our estimates
regarding the implementation of the API provisions may vary depending
on a number of factors, including, but not limited to a payer's current
knowledge of and experience with implementing FHIR-based APIs, and
whether an impacted payer will develop this technology in-house or seek
a third party contractor to support this effort.
To further develop our cost estimates, we reviewed the cost
estimates associated with updating Blue Button from Blue Button 1.0 to
2.0 to include a standards-based API, similar to the requirements of
this final rule. This update was estimated at $2 million. However, we
believe that the estimates associated with updating the existing Blue
Button 1.0 to a standards-based API for Blue Button 2.0 do not
accurately represent the costs for payers impacted by this final rule.
Blue Button 1.0 was developed across several federal agencies,
including the Departments of Defense, Health and Human Services, and
Veterans Affairs, with a capability to allow beneficiaries online
access to their own personal health records, such as the ability to
download PDF documents. Unlike the standards-based APIs required under
this final rule, Blue Button 1.0 was not originally developed with a
prescribed set of standards that allow for third-party apps to connect
and retrieve data via an API. The estimates for Blue Button account for
upgrading an existing technology platform that was not originally
developed to allow third-party app access via an API, which we believe
adds additional cost that may not impact all payers under this final
rule. Additionally, we note that costs related to federal procurement
and the need to engage multiple contractors to implement the updates to
Blue Button, while at the same time maintaining access to the original
system, caused the cost of implementing standards-based APIs for Blue
Button 2.0 to be higher than those costs for payers impacted by this
final rule. Therefore, we believe that the estimates for upgrading Blue
Button from 1.0 to 2.0 are not truly representative of the cost to
implement the standards-based API required by this final rule, but
nonetheless are valuable in further informing our cost estimates.
As noted above, we did receive one comment that suggested a cost
range between $1 million and $1.5 million to implement the API
requirements of this final rule, with another commenter indicating a
four-fold increase in costs relative to the estimates included in the
proposed rule. While disagreeing with
[[Page 25607]]
our bottom line, these commenters did not provide where in our detailed
analysis we underestimated costs. For example, it is unclear if the
commenters were including voluntary provider costs, or other costs when
calculating the dollar amounts for compliance. Therefore, without
specific examples of additional costs that need to be accounted for in
this impact analysis, we believe that our estimates are reasonable. To
address commenters' concerns regarding ongoing costs, we remind readers
that we specifically are accounting for a cost of $157,656 per
organization, for costs throughout the year to include: Allocating
resources to maintain the FHIR server, which includes the cost of
maintaining the necessary patient data, and perform capability and
security testing.
However, in an effort to take into account the additional
information that commenters presented regarding our costs estimates,
and understanding there are many factors that may influence the cost of
implementing these policies, as noted above, we are adjusting our cost
estimates to reflect a range instead of a point estimate. We believe
that our cost projections for an initial one-time cost to implement the
API requirements of this final rule of $718,414 per organization,
reflecting 6 months of work by a team of ten professionals, can now
serve as a minimum estimate; in other words, we do not believe it is
technically feasible to implement the requirements of this final rule
in less than 6 months. For a primary estimate, we have increased our
cost estimates by a factor of 2 to account for cost variation. We note
that using this factor of 2, the cost per organization is consistent
with the commenter stating a $1 million to $1.5 million per
organization cost. For a high estimate we have increased our cost
estimates by a factor of 3. Although, one commenter noted a factor of 4
should be included, all other information available to us, including
the commenter who noted a range between $1 million and $1.5 million,
and our estimates for upgrading Blue Button, a factor of 4 does not
appear to be reflective of the costs for implementation and represents
more of an outlier for cost estimating purposes. As shown in section
XIII. of this final rule, we have revised down our estimate of affected
individual market enrollees from 76 million (all commercial market
enrollees) to 17.5 million (those individual market enrollees directly
affected by this final rule). This reduction by a factor of 4 (76
million former estimate/17.5 million revised estimate) raises the cost
per individual market enrollee per year by a factor of 4 consistent
with the commenter's suggested factor of 4. This factor of 4, however,
only affects cost per enrollee per year; it does not affect total costs
as calculated in Table 2.
Additionally, we note that as part of our original estimated costs
associated with the annual burden of the requirements of this final
rule, we accounted for additional capability testing and long-term
support of the APIs, increased data storage needs, such as additional
servers, or cloud storage to store any additional patient health
information, and allocation of resources to maintain the FHIR server,
and perform capability and security testing. Therefore, our estimates
related to the annual burden account for the ongoing cost, and we are
not providing additional estimates for maintenance as this is already
factored in.
The burden estimate related to the new requirements for
implementing and maintaining the APIs reflects the time and effort
needed to collect the information described above and disclose this
information. We now estimate:
An initial set one-time costs associated with the
implementing the API requirements.
An ongoing maintenance cost after the system is set up,
and the costs associated with additional data storage, system testing,
and maintenance.
Consistent with our discussion above, we now regard this as a low
or minimum estimate, the argument being that a complex system cannot be
designed in less than 6 months. Our high estimate now reflects 18
months of work (4,320 hours) for administrators and network architects.
This is obtained by using a factor of 3 (4,320 hours (high estimate) =
3*1440 hours, the original estimate). For a primary estimate, we
estimate 12 months of work or 2,880 hours (1,440 hours * 2) for
administrators and network architects. The use of a factor of 2 is
consistent with a $2 million cost per entity and consistent with the
commenter who estimated an implementation cost of $1 million to $1.5
million. We note that, in terms of actual implementation, this
assumption is focused on the 2,880 hours of work that could be
conducted in less than 12 months through necessary personnel or third-
party contractor allocation, if needed. As a result, the ``12-month''
assumption is also consistent with the implementation of the new API
requirements, which must be implemented by January 1, 2021.
As can be seen from the bottom rows of Table 2:
For a low estimate, first year implementation will require
a total of 8,400 hours per organization at a cost of $718,414.40 per
organization (this number is obtained by adding the products of hourly
wages and hours required in each row, for example 1440*$90.18 +
960*$95.60, etc.).
For a high estimate, first year implementation will
require a total of 25,200 hours per organization at a cost of
$2,365,243 per organization (this number is obtained by adding the
products of hourly wages and hours required in each row).
For a primary estimate, first year implementation will
require a total of 16,800 hours of work per organization at a cost of
$1,576,829 per organization.
Therefore, the aggregate burden of the first year
implementation across 345 parent organizations \67\ is 2,898,000 hours
(8400 * 345) at a cost of $272 million ($718,414 * 345) for the low
estimate. Similar calculations show that the primary estimate is
5,796,000 hours at an aggregate cost of $544,005,936 million, and the
high estimate is 8,694,000 hours at a cost of $816,008,904.
---------------------------------------------------------------------------
\67\ We provide a detailed rationale for how we determined the
number of parent organizations in section XIII.C.1. of this final
rule. In that analysis we determined that 288 issuers and 56 states,
territories, and U.S. commonwealths, which operate FFS programs,
will be subject to the API provisions for Medicare, Medicaid, and
the commercial market. To this we added the one state that operates
its CHIP and Medicaid separately. Thus, we have a total of 345
parent entities (288+56+1).
---------------------------------------------------------------------------
Similarly, ongoing maintenance after the first year will
require a total of 1,710 hours per organization at a cost of
$157,656.60 per organization.
Therefore, the aggregate burden of ongoing implementation
across 345 parent organizations is $54.4 million ($157,656.60 * 345).
We explicitly note that a low and high estimate were only provided
for the first year, but not for subsequent years.
[[Page 25608]]
Table 2--First Year and Maintenance Cost of the API Provisions
--------------------------------------------------------------------------------------------------------------------------------------------------------
Mean Adjusted First year
Occupation hourly Fringe hourly First year hours First year Maintenance
Occupation title code wage ($/ benefit wage ($/ hours (low (primary hours (high hours
hr) ($/hr) hr) estimate) estimate) estimate)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Administrators and Network Architects... 15-1140 $45.09 $45.09 $90.18 1440 2880 4320 180
Security Engineer....................... 17-2199 47.80 47.80 95.60 960 1920 2880 240
Computer and Information Analysts....... 15-1120 45.67 45.67 91.34 480 960 1440 60
General Operations Manager.............. 11-1021 59.56 59.56 119.12 720 1440 2160 90
Operations Research Analysts............ 15-2031 42.48 42.48 84.96 960 1920 2880 120
Software Developers, Applications....... 15-1132 51.96 51.96 103.92 960 1920 2880 240
Computer and Information Systems 11-3021 73.49 73.49 146.98 720 1440 2160 90
Managers...............................
Designers............................... 27-1020 24.05 24.05 48.10 960 1920 2880 120
Technical Writer........................ 27-3042 36.30 36.30 72.60 240 480 720 30
Computer Systems Analysts............... 15-1121 45.01 45.01 90.02 960 1920 2880 120
Network and Computer Systems 15-1142 41.86 41.86 83.72 .............. 0 0 420
Administrators.........................
Total Hours per System.............. .......... .......... .......... .......... 8,400 16,800 25,200 1,710
Total Cost per system (Dollars) .......... .......... .......... .......... 788,414 1,576,829 2,365,243 157,657
(millions).........................
Total hours for 345 Organizations .......... .......... .......... .......... 2,898,000 5,796,000 8,694,000 589,950
(hours)............................
Total Cost for 345 Organizations .......... .......... .......... .......... 272,002,968 544,005,936 816,008,904 54,391,527
(millions $).......................
--------------------------------------------------------------------------------------------------------------------------------------------------------
3. ICRs Regarding Conditions of Participation for Hospitals and
Critical Access Hospitals (42 CFR 482.24(d), 482.61(f), 485.638(d))
We are expanding our requirements for interoperability within the
hospital and CAH CoPs by focusing on electronic patient event
notifications. We are implementing new requirements in section X. of
this final rule for hospitals at 42 CFR 482.24(d), for psychiatric
hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638(d).
Specifically, for hospitals, psychiatric hospitals, and CAHs, we are
finalizing similar requirements to revise the CoPs for Medicare- and
Medicaid-participating hospitals, psychiatric hospitals, and CAHs by
adding a new standard, ``Electronic Notifications,'' that will require
hospitals, psychiatric hospitals, and CAHs to make electronic patient
event notifications available to applicable post-acute care services
providers and suppliers, and to community practitioners such as the
patient's established primary care practitioner, established primary
care practice group or entity, or other practitioner or practice group
or entity identified by the patient as primarily responsible for his or
her care. We are limiting this requirement to only those hospitals,
psychiatric hospitals, and CAHs that utilize electronic medical records
systems, or other electronic administrative systems, which are
conformant with the content exchange standard at 45 CFR 170.205(d)(2),
recognizing that not all Medicare- and Medicaid-participating hospitals
have been eligible for past programs promoting adoption of EHR systems.
If the hospital's (or CAH's) system conforms to the content exchange
standard at 45 CFR 170.205(d)(2), the hospital (or CAH) must then
demonstrate that its system's notification capacity is fully
operational and that the hospital (or CAH) uses it in accordance with
all state and federal statutes and regulations applicable to the
hospital's (or CAH's) exchange of patient health information, and that
its system (to the extent permissible under applicable federal and
state law and regulations, and not inconsistent with the patient's
expressed privacy preferences) sends the notifications either directly,
or through an intermediary that facilitates exchange of health
information. It must also demonstrate that the notifications include at
least patient name, treating practitioner name, and sending institution
name.
Upon the patient's registration in the emergency department or
admission to inpatient services, and also either immediately prior to,
or at the time of, the patient's discharge or transfer (from the
emergency department or inpatient services), the hospital (or CAH) must
also demonstrate that it has made a reasonable effort to ensure that
its system sends the notifications to all applicable post-acute care
services providers and suppliers, as well as to any of the following
practitioners and entities, which need to receive notification of the
patient's status for treatment, care coordination, or quality
improvement purposes: (1) The patient's established primary care
practitioner; (2) the patient's established primary care practice group
or entity; or (3) other practitioner, or other practice group or
entity, identified by the patient as the
[[Page 25609]]
practitioner, or practice group or entity, primarily responsible for
his or her care.
These requirements will help support coordination of a patient's
care between settings or with services received through different care
settings. Electronic patient event notifications from these care
settings, or clinical event notifications, are one type of health
information exchange intervention that has been increasingly recognized
as an effective and scalable tool for improving care coordination
across settings. These notifications are typically automated,
electronic communications from the admitting or discharging provider to
applicable post-acute care services providers and suppliers, and also
to community practitioners identified by the patient, that alert the
receiving providers or community practitioners that a patient is
receiving, or has received, care at a different setting.
These notifications are frequently based on ``admission, discharge,
and transfer (ADT)'' messages, a standard message used within an EHR as
the vehicle for communicating information about key changes in a
patient's status as they are tracked by the system (more information
about the current standard supporting these messages is available at
http://www.hl7.org/implement/standards/product_brief.cfm?product_id=144). As noted in the ISA published by
ONC, this messaging standard has been widely adopted across the health
care system (see https://www.healthit.gov/isa/sending-a-notification-a-patients-admission-discharge-andor-transfer-status-other-providers).
We continue to believe that care coordination can have a
significant positive impact on the quality of life, consumer
experience, and health outcomes for patients. As we have noted in the
preamble to this rule, virtually all EHR systems (as well as older
legacy electronic administrative systems, such as electronic patient
registrations systems, and which we are including in this final rule)
generate information to support the basic messages commonly used for
electronic patient event notifications. While we acknowledge that some
level of implementation cost would be realized for those providers not
already transmitting notifications, we also note there is substantial
agreement that implementation of these basic messaging and notification
functions within such existing systems constitutes a relatively low
cost burden for providers, particularly when such costs are considered
alongside the innovative and beneficial patient care transition
solutions and models for best practices they provide.
Although we do not have current data on how many facilities are
already transmitting electronic patient event notifications, 59 percent
of hospitals were found to be routinely electronically notifying a
patient's primary care provider upon his or her entry to the hospital's
emergency department in 2015, which is an over 50 percent increase
since 2012.\68\ By using this historical data to plot a power trend
line (R-Squared: 0.9928), we estimate that approximately 71 percent of
hospitals may have been routinely transmitting patient event
notifications by 2018; therefore, we assume that 29 percent of
hospitals, or approximately 1,392, will incur costs associated with
updating or configuring their respective EHR systems for electronic
patient event notifications. While we do not have parallel data for
CAHs, we assume that a similar percentage, or approximately 394 CAHs,
will incur this burden. We note that this upwards trend of patient
event notification adoption may continue to some unknown extent absent
this final rule; however, we are limiting our projection of hospitals
that are most affected by these requirements to 2018 due to the amount
of uncertainty involved in quantifying this burden.
---------------------------------------------------------------------------
\68\ Office of the National Coordinator. (n.d.). Hospital
Routine Electronic Notification: Percent of U.S. Hospitals that
Routinely Electronically Notify Patient's Primary Care Provider upon
Emergency Room Entry, 2015. Retrieved from https://dashboard.healthit.gov/quickstats/pages/FIG-Hospital-Routine-Electronic-Notification.php.
---------------------------------------------------------------------------
We assume that this process will primarily require the services of
two medical records and health information technicians at approximately
$42.32/hour for 16 hours each, and 3 hours of time from a medical and
health services manager at approximately $109.36/hour, including the
costs of overhead and fringe benefits. Thus, the total burden per
facility is anticipated to be 35 hours, or approximately $1,682.32 ((16
hours * $42.32/hour * 2 health information technicians) + (3 hours *
$109.36/hour * 1 manager)). We assume that the ongoing burden
associated with maintenance of these systems would be approximately one
quarter of these amounts for the 2 medical records and health
information technicians, or 4 hours each, for a total of 8 hours and
$338.56 per facility (4 hours * $42.32/hour * 2 health information
technicians).
In this lower-bound scenario, we estimate that the total first-year
burden for hospitals and psychiatric hospitals is approximately 48,720
hours (35 hours * 1,392 hospitals) or $2,341,789 ($1,682.32 * 1,392
hospitals). In subsequent years, we estimate the burden is
approximately 11,136 hours (8 hours * 1,392 hospitals) or $471,276
($338.56 * 1,392 hospitals).
For CAHs we estimate that the total first-year burden is
approximately 13,790 hours (35 hours * 394 CAHs) or $662,834 ($1,682.32
* 394 CAHs). In subsequent years, we estimate the burden for CAHs is
approximately 3,152 hours (8 hours * 394 CAHs) or $133,393 ($338.56 *
394 CAHs).
Due to the amount of uncertainty involved in these estimates, we
are also presenting estimates for a scenario in which the number of
hospitals that routinely electronically notify primary care providers
both inside and outside of the hospital's system is assumed to have
remained static at the 2015 rate of 29 percent. This upper-bound
scenario would indicate that in 2018 approximately 3,407 hospitals and
964 CAHs did not routinely utilize patient event notification, and
therefore several thousand additional providers would incur the
previously estimated burden per facility.
For the purposes of the PRA, we are assuming the midpoint of this
range of effects. In this scenario 2,400 hospitals and psychiatric
hospitals, and 679 CAHs would incur the estimated burden. The burden
estimates associated with the revised CoPs are detailed in Table 3.
This information collection will be submitted to OMB under OMB Control
Number 0938-New.
[[Page 25610]]
Table 3--Summary of Hour and Dollar Burden by Number of Affected Providers
--------------------------------------------------------------------------------------------------------------------------------------------------------
Hospitals and psychiatric CAHs
--------------------------------------------------------------------------------- hospitals -----------------------------------
------------------------------------
Year 1 Subsequent years Year 1 Subsequent years
--------------------------------------------------------------------------------------------------------------------------------------------------------
Lower Bound................................... Affected Providers.............. 1,392
394
---------------------------------------------------------------------------------------------------------
Total Burden (hours)............ 48,720 11,136 13,790 3,152
Total Cost...................... $2,341,789.44 $471,275.52 $662,834.08 $133,392.64
---------------------------------------------------------------------------------------------------------
Primary Estimate.............................. Affected Providers.............. 2,400
679
---------------------------------------------------------------------------------------------------------
Total Burden (hours)............ 84,000 19,200 23,765 5,432
Total Cost...................... $4,037,568.00 $812,544.00 $1,142,295.28 $229,882.24
---------------------------------------------------------------------------------------------------------
Upper Bound................................... Affected Providers.............. 3,407
964
---------------------------------------------------------------------------------------------------------
Total Burden (hours)............ 119,245 27,256 33,740 7,712
Total Cost...................... $5,731,664.24 $1,153,473.92 $1,621,756.48 $326,371.84
--------------------------------------------------------------------------------------------------------------------------------------------------------
4. Summary of Information Collection Burdens
Table 4--Summary of Primary Information Collection Burdens
--------------------------------------------------------------------------------------------------------------------------------------------------------
Hourly
Burden per Total labor cost Total labor Total labor
Regulation section(s) OMB control No. Number of Number of response annual of cost 1st cost
respondents responses (hours) burden reporting year ($) subsequent
(hours) ($) years ($)
--------------------------------------------------------------------------------------------------------------------------------------------------------
Sec. 423.910...................... 0938-0958 *............ 36 36 960 34,560 $90.02 3,111,091 3,111,091
Sec. 422.119, Sec. 431.60, Sec. 0938-New............... 345 345 16,800 5,796,000 Varies 544,005,936 0
457.730, Sec. 438.242, Sec.
457.1233 and Sec. 156.221.
Sec. 422.119, Sec. 431.60, Sec. 0938-New............... 345 345 1,710 589,950 Varies ........... 54,391,527
457.730, Sec. 438.242, Sec.
457.1233, and Sec. 156.221.
Sec. 482.24(d) and Sec. 0938-New............... 2,400 2,400 35 84,000 Varies 4,037,568 ...........
482.61(f).
Sec. 482.24(d) and Sec. 0938-New............... 2,400 2,400 8 19,200 Varies ........... 812,544
482.61(f).
Sec. 485.638(d)................... 0938-New............... 679 679 35 23,765 Varies 1,142,295 ...........
Sec. 485.638(d)................... 0938-New............... 679 679 8 5,432 Varies ........... 229,882.24
-------------------------------------------------------------------------------------------------------------------
Total........................... ....................... ........... 6,884 Varies 6,552,907 Varies 552,296,890 58,545,044
--------------------------------------------------------------------------------------------------------------------------------------------------------
* This currently approved ICR will be revised to include the burden discussed in this rule.
XIII. Regulatory Impact Analysis
A. Statement of Need
As described in detail in section III. of this rule, the changes to
42 CFR parts 422, 431, 438, 457, and 45 CFR part 156 are part of the
agency's broader efforts to empower patients by ensuring that they have
full access to their own health care data, through common technologies
and without special effort, while keeping that information safe and
secure. Interoperability and the capability for health information
systems and software applications to communicate, exchange, and
interpret data in a usable and readable format, such as PDF or text, is
vital, but allowing access to health care data through PDF and text
format also limits the utility and sharing of data. Moving to a system
in which patients have access to their health care data will help
empower them to make informed decisions about their health care, as
well as share their data with providers who can assist these patients
with their health care. The policies are designed to move Medicare, MA,
Medicaid, CHIP, and QHP issuers on the FFEs further to that ultimate
goal of empowering their enrollees. As technology has advanced, we have
encouraged states, payers, and providers to adopt various forms of
technology to improve the accurate and timely exchange of standardized
health care information. The policies in this final rule enable
patients to be active partners in the exchange of electronic health
care data by easily monitoring or sharing their data.
States and CMS routinely exchange data on who is enrolled in
Medicare, and which parties are liable for paying that beneficiary's
Parts A and B
[[Page 25611]]
premiums. These ``buy-in'' data exchanges support state, CMS, and SSA
premium accounting, collections, and enrollment functions. We have
become increasingly concerned about the limitations of monthly buy-in
data exchanges with states. The relatively long lag in updating buy-in
data means that the state is not able to terminate or activate buy-in
coverage sooner, so the state or beneficiary may be paying premiums for
longer than appropriate. We note that once the data catch up, states
and CMS reconcile the premiums by recouping and re-billing, so premiums
collected are ultimately accurate, but only with an administratively
burdensome process involving debits and payments between the
beneficiary, state, CMS, SSA, and potentially providers. Daily buy-in
data exchange will reduce this administrative burden.
States submit data on files at least monthly to CMS to identify all
dually eligible individuals, including full-benefit and partial-benefit
dually eligible beneficiaries (that is, those who get Medicaid help
with Medicare premiums, and often for cost-sharing). The MMA file was
originally developed to meet the need to timely identify dually
eligible beneficiaries for the then-new Medicare Part D prescription
drug benefit. Over time, we use these files' data on dual eligibility
status to support Part C capitation risk-adjustment, and most recently,
feeding dual eligibility status to Part A and B eligibility and claims
processing systems so providers, suppliers, and beneficiaries have
accurate information on beneficiary cost-sharing obligations. As CMS
now utilizes MMA data on dual eligibility status in systems supporting
all four parts of the Medicare program, it is becoming even more
essential that dual eligibility status is accurate and up-to-date. Dual
eligibility status can change at any time in a month. Waiting up to a
month for status updates can negatively impact access to the correct
level of benefit at the correct level of payment. As described in
detail in section VII. of this rule, the changes to 42 CFR parts 406,
407, and 423 establish frequency requirements that necessitate all
states to participate in daily exchange of buy-in data, and updates
frequency requirements to require all states to participate in daily
exchange of MMA file data, with CMS by April 1, 2022.
B. Overall Impact
We have examined the impacts of this final rule as required by
Executive Order 12866 on Regulatory Planning and Review (September 30,
1993), Executive Order 13563 on Improving Regulation and Regulatory
Review (January 18, 2011), the Regulatory Flexibility Act (RFA)
(September 19, 1980, Pub. L. 96-354), section 1102(b) of the Social
Security Act, section 202 of the Unfunded Mandates Reform Act of 1995
(March 22, 1995; Pub. L. 104-4), Executive Order 13132 on Federalism
(August 4, 1999), the Congressional Review Act (5 U.S.C. 804(2)), and
Executive Order 13771 on Reducing Regulation and Controlling Regulatory
Costs (January 30, 2017).
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health and safety effects, distributive impacts, and equity). Section
3(f) of Executive Order 12866 defines a ``significant regulatory
action'' as an action that is likely to result in a rule: (1) Having an
annual effect on the economy of $100 million or more in any 1 year, or
adversely and materially affecting a sector of the economy,
productivity, competition, jobs, the environment, public health or
safety, or state, local or tribal governments or communities (also
referred to as ``economically significant''); (2) creating a serious
inconsistency or otherwise interfering with an action taken or planned
by another agency; (3) materially altering the budgetary impacts of
entitlement grants, user fees, or loan programs or the rights and
obligations of recipients thereof; or (4) raising novel legal or policy
issues arising out of legal mandates, the President's priorities, or
the principles set forth in the Executive Order.
A regulatory impact analysis (RIA) must be prepared for major rules
with economically significant effects ($100 million or more in any 1
year). We estimate that this rulemaking is ``economically significant''
as measured by the $100 million threshold, and hence also a major rule
under the Congressional Review Act. Accordingly, we have prepared an
RIA that to the best of our ability presents the costs and benefits of
the rulemaking. Table 5 summarizes the estimated costs presented in
section XII. of this final rule.
In the proposed rule, we provided detailed estimations of the
required labor categories and number of hours required to implement
standards-based APIs (84 FR 7659). We originally estimated a one-time
burden of $789,356 per organization or state, per implementation, with
an ongoing maintenance cost $158,359.80 per organization or state (84
FR 7659). As we detailed in section XII., to account for additional
information commenters presented regarding our costs estimates, we are
adjusting our original cost estimates to reflect a range, instead of a
point estimate. Our original estimate for the initial one-time cost to
implement the API requirements of this final rule of $788,414 per
organization will now serve as a minimum estimate. We have increased
our primary cost estimate by a factor of 2 to an initial one-time cost
of $1,576,829 per organization or state. Additionally, we are
increasing our original cost estimate by a factor of 3 for an initial
one-time cost of $2,365,243 per organization or state to serve as a
high estimate (detailed cost estimates are located in Table 5).
Table 5 reflects updated wages for 2018, the latest available from
the Bureau of Labor Statistics (BLS) website; the CMS Interoperability
and Patient Access proposed rule used 2017 wage estimates.
Nevertheless, the change in total impact was small. We note that
estimates below do not account for enrollment growth or higher costs
associated with medical care. This is because the cost of requirements
to implement patient access through APIs and for states to comply with
data exchange requirements are not impacted by enrollment growth or
higher costs associated with medical care. Per OMB guidelines, the
projected estimates are expressed in constant-year dollars (in this
case, using 2018 prices and wages).
Table 5 forms the basis for allocating costs by year and program to
the federal government, state Medicaid agencies, and parent
organizations.
[[Page 25612]]
Table 5--Estimated Costs (millions) of Final Rule by Provision
--------------------------------------------------------------------------------------------------------------------------------------------------------
Provision Dual Patient
----------------------------------- eligible access API
care (low
coordination estimate)
---------------------------
Sec. Percent of
422.119, Months in 25 month
Sec. Patient Patient Total cost Total cost Total cost year for window for
Sec. 431.60, access API access API (low (primary (high compliance compliance
Regulatory text 406.26, Sec. Sec. (primary (high estimate) estimate) estimate) for dual with dual
407.40, 438.242, estimate) estimate) eligible eligible
Sec. Sec. provisions provisions
423.910 457.730,
Sec.
457.123,
Sec.
156.221
--------------------------------------------------------------------------------------------------------------------------------------------------------
2020.............................. 2.8 272.0 544.0 816.0 274.8 546.8 818.8 10 40
2021.............................. 3.4 54.4 54.4 54.4 57.8 57.8 57.8 12 48
2022.............................. 0.8 54.4 54.4 54.4 55.2 55.2 55.2 3 12
2023.............................. 0.0 54.4 54.4 54.4 54.4 54.4 54.4 ........... ...........
2024.............................. 0 54.4 54.4 54.4 54.4 54.4 54.4 ........... ...........
2025.............................. 0.0 54.4 54.4 54.4 54.4 54.4 54.4 ........... ...........
2026.............................. 0.0 54.4 54.4 54.4 54.4 54.4 54.4 ........... ...........
2027.............................. 0.0 54.4 54.4 54.4 54.4 54.4 54.4 ........... ...........
2028.............................. 0.0 54.4 54.4 54.4 54.4 54.4 54.4 ........... ...........
2029.............................. 0.0 54.4 54.4 54.4 54.4 54.4 54.4 ........... ...........
---------------------------------------------------------------------------------------------------------------------
Total......................... 7.0 761.5 1033.5 1305.5 768.5 1040.5 1312.5 25.0 100
--------------------------------------------------------------------------------------------------------------------------------------------------------
Note: Totals may not equal sum of parts due to rounding.
Allocation of Cost Impact by Payer: As stated in section XII. of
this final rule, cost estimates have been aggregated at the parent
organization level because we believe that an organization that offers
QHPs on the FFEs, Medicare, Medicaid, and CHIP products would create
one system that would be used by all ``plans'' to whom it offers access
to data via APIs. We note that due to the implementation of APIs across
multiple business lines, there is no straightforward method to
immediately estimate parent organization expenditures on how much of
the cost is born by each payer. Although this section provides such
estimates it is important to understand how they are arrived at. A
summary by Table in this section is provided in Table 6. As shown in
Table 6:
We first ascertain total costs of implementing this final
rule by provision in (Table 5);
As indicated earlier, we have no straightforward way of
ascertaining total costs by payer since we do not have internal data
for each parent organization on how it allocates costs by program;
Therefore, to approximate costs we developed approximated
proportions of total cost of each parent organization by payer
(Medicare, Medicaid, CHIP, and Individual market, including individual
market plans sold on and off the Exchanges, as we expect that, among
parent organizations of issuers that offer QHPs on the FFEs, costs will
be passed on through all plans the issuers offer in the individual
market. Since this rule does not apply to QHP issuers offering QHPs
only on Federally-facilitated Small Business Health Options Program
Exchanges (FF-SHOPs) they were not included in our analysis.
Our use of available data includes many approximations due
to data limitations discussed in detail below (Table 7);
Table 7 then allows us to obtain proportions of total
costs for this final rule by payer (Table 8);
Since we know the way federal payments for both Medicare
and Medicaid are calculated, we can then obtain total costs by payer
incurred by the federal government (Table 9);
We next subtracted federal payments by payer (Table 9)
from total costs by payer (Table 8) to obtain the non-federal costs of
this final rule by payer (Table 10);
Table 11 presents the same data as Table 10; Table 10
presents total non-federal costs per payer, while Table 11 presents
average non-federal costs per enrollee per payer;
Table 12 presents the same data as Table 9; while Table 9
presents total costs to the federal government by payer, Table 12
presents average federal costs per enrollee by payer; and
Table 13 lists potential means for payers to deal with new
costs.
Table 6--Outline of the Flow of Logic by Table for This Impact Analysis
------------------------------------------------------------------------
Table Content of table Comments on table
------------------------------------------------------------------------
5........................... Total costs by Costs are fully
provision (API, developed in the
Dual). Collection of
Information section
of this final rule
(section XII. of
this final rule).
7........................... Proportion of There is no
premiums by program straightforward way
(2016-2018) used, to directly assess
in later tables, as parent organization
a proxy for cost by payer.
proportion of cost Therefore, for each
by program. payer we develop
approximate
percentages of cost
per payer.
8........................... API costs total cost We obtain the total
by year and Program API costs for this
(Medicare, final rule per
Medicaid, program by
Individual market multiplying the API
plans, and CHIP). costs (for all
This total cost is programs) of this
divided by cost to final rule (Table
the federal 5) by the
government (Table proportion of
9) and non-federal premiums presented
costs to plans and in Table 7.
enrollees (Table
10).
[[Page 25613]]
9........................... Total costs incurred Based on how federal
by the federal payments are
government by calculated in
program and year. Medicare and
Medicaid, we have
projected federal
proportions of the
total cost and
these are applied
to Table 8 to
obtain Table 9.
10.......................... Non-federal total Table 9 = Table 8-
costs for API by Table 10--non-
program by year. federal costs are
obtained by
subtracting federal
costs (Table 9)
from total costs
(Table 8).
11.......................... Average non-federal Tables 11 and 10
cost per enrollee present the same
per year by program data in different
for plans. forms. Table 10
presents total non-
federal cost by
program for states
and plans, while
Table 11 presents
average non-federal
costs per enrollee
per year for states
and plans.
12.......................... Average federal cost Tables 12 and 9
per enrollee per present the same
year by program for data in different
the federal forms. Table 9
government. presents total cost
to the federal
government (due to
matching programs),
while Table 12
presents average
cost per enrollee
to the federal
government.
13.......................... How payers would This table lists
defray the potential means for
remaining costs. a plan to deal with
extra costs. We
have no way of
predicting what
will actually
happen.
------------------------------------------------------------------------
Preliminary Estimates: This section provides several detailed
estimates of cost by payer (Table 7); we also account for federal
matching for Medicaid and payments by the Trust Fund for Medicare
Advantage organizations (Table 9); we indicate remaining burden on
plans (Tables 10, 11) and how they might account for it (Table 12).
However, these estimates are approximate as explained in detail below.
Data Sources for Cost by Payer: To obtain allocation of cost by
payer we used the CMS public use files for MLR data, for 2016.\69\ The
MLR data sets are for private insurance plans but the issuers of that
private insurance in many cases also have contracts to provide MA,
Medicaid, and CHIP managed care plans and report revenue, expense, and
enrollment data for these plans on the private insurance MLR reporting
form.
---------------------------------------------------------------------------
\69\ Center for Consumer Information and Insurance Oversight.
(n.d.). Medical Loss Ratio Data and System Resources. Retrieved from
https://www.cms.gov/CCIIO/Resources/Data-Resources/mlr.html.
---------------------------------------------------------------------------
Thus, these MLR data sets omit organizations that only have
Medicare or Medicaid. The data from the CMS MLR files also omit: (1)
The CHIP program; and (2) state Medicaid agencies. We now discuss these
omissions to assess the accuracy of using these MLR files.
CHIP: Eighty-five percent of the 194 CHIP managed care plans also
offer Medicaid and hence are covered by the parent entity. We believe
it reasonable that the remaining CHIP plans also have commercial
offerings since it would be inefficient to operate a CHIP-only plan, as
the total national CHIP enrollment is currently only about 7 million.
Similarly, except for one state, CHIP programs are run through the
state Medicaid agency; again, there would be one interoperability cost
for the one state agency since the resulting software and systems would
be used both for Medicaid and CHIP. Thus, while we are leaving out CHIP
programs in this analysis since they are not in the CMS MLR files, we
do not believe this materially alters the overall picture.
Medicare Advantage: We compared the CMS MLR files with the CMS
Trustee Report.\70\ According to the Trustee Report (Table IV.C2),
total MA revenue for 2016 was $189.1 billion. Thus, the reported amount
in the CMS MLR files of $157 billion for MA represents 83 percent (157/
189.1) of all MA activity reflected in the Trustee Report. Therefore,
we believe the proportions obtained from these MLR files are accurate.
---------------------------------------------------------------------------
\70\ See Table IV.C2 in, Boards of Trustees (Federal Hospital
Insurance and Federal Supplementary Medical Insurance Trust Funds).
(2018, June 5). The 2018 Annual Report of The Boards of Trustees of
the Federal Hospital Insurance and Federal Supplementary Medical
Insurance Trust Funds. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf.
---------------------------------------------------------------------------
Medicaid: For the year for which these MLR files provide data
(2016), about 70 percent of Medicaid enrollees were enrolled in
Medicaid managed care.\71\ Thus, although the MLR files omit state
agencies, we believe that the 70 percent of Medicaid enrollees enrolled
in Medicaid managed care provides a good approximation.
---------------------------------------------------------------------------
\71\ Centers for Medicare and Medicaid Services. (2018, November
8). CMS Proposes Changes to Streamline and Strengthen Medicaid and
CHIP Managed Care Regulations. Retrieved from https://www.cms.gov/newsroom/press-releases/cms-proposes-changes-streamline-and-strengthen-medicaid-and-chip-managed-care-regulations.
---------------------------------------------------------------------------
Individual and small group market plans: The MLR files contain data
on all commercial parent organizations whether these organizations have
other lines of business, such as Medicare Advantage or Medicaid, or
not. In discussing commercial plans, we account for: (A) Large group
market plans; (B) small group market plans, including SHOP plans; (C)
individual market Exchange plans; and (D) individual market off-
Exchange plans.
We have carved out the large employer plans since the
provisions of this final rule do not apply to them, and we do not
believe that parent organizations would pass on costs for individual
and small group market plans to large group employer-sponsored plans.
We have noted that the provisions of this final rule do
not apply to QHP issuers offering QHPs only on FF-SHOPs, so we are not
including small group market plans in this analysis.
We believe it is reasonable, that even though the
provisions of this final rule do not apply to off-Exchange individual
market plans, issuers subject to this rule offering QHPs on the FFEs
will spread the cost to all plans issuers offer in the individual
market. They will also likely offer the benefits of the APIs to all
covered lives, as they can be marketed as a value add service, and it
is logistically more challenging to offer a service to only a limited
number of enrollees.
We estimate that off-Exchange plans offered by issuers who
offer no QHPs on
[[Page 25614]]
FFEs are about 7 percent of total individual market enrollment.
Therefore, to the extent that we are including off-Exchange plans, the
calculations below will be an approximation, but given this low
proportion of off-Exchange-only issuers, we do not believe including
them in this approximation will have a major impact.
Best Estimates of Impact per Program and Payer: We present two
methods to obtain an estimate of cost by program and payer, both for
purposes of assessing impact on: (1) Small entities; (2) the federal
government; (3) payers (states and plans); and (4) enrollees. We could
assume costs proportional to current enrollment, or alternatively, we
could assume costs proportional to total premium. For purposes of
analyzing impact on small entities and impacts of the provision on the
federal government, payers, plans, and enrollees we are using the
method of assuming costs proportional to total premium (the method of
assuming costs proportional to current enrollment will be used below to
assess impact on transfers to enrollees).
The CMS Interoperability and Patient Access proposed rule used 2016
CMS MLR files (84 FR 7662). Since its publication, 2017 and 2018 data
have become available. However, we are only using these data to obtain
proportions and, as Table 7 shows, the proportions for premiums have
not changed significantly (only one quarter to one third percent for
Medicare and Medicaid). Therefore, we retain and continue to use the
2016 proportions for purposes of this analysis with a note that they
generally have remained constant. These proportions of premiums are
being used as a proxy to approximate total cost.
In the proposed rule we used the full $370 billion in commercial
premium in determining our proportions (84 FR 7662). As discussed
above, we are revising the estimates because upon further
consideration, we have concluded that issuers in the commercial group
markets are unlikely to spread the costs through increasing premium
rates on those types of plans because issuers are not required to
implement and maintain the API requirements of this final rule in the
group markets and there are no indications that employer groups in
these markets would be willing to pay for this provision through
increased premium rates. Consequently, the $370 billion commercial
premium is being reduced to $77 billion and the 76 million enrollees
are being reduced to 17.5 million.
As discussed above, the $370 billion (and 76 million enrollees)
represented both individual and small group and large group market
plans; the $77 billion and 17.5 million enrollees represent all
individual market plans whether they are sold on and/or off-Exchange.
We note that this reduction from our original estimate is due to the
fact that most plans are large employer plans, and the individual
market is only 20 to 23 percent of the full health insurance market.
This refinement better aligns with the proportion of the market
impacted by this final rule.
Among issuers with products in both the individual market and MA or
the individual market and Medicaid, the 2016 CMS MLR files show $77
billion reported in premium for individual market plans, $157 billion
reported for MA, and $113 billion reported for Medicaid. Consequently,
the proportion of interoperability cost for each of the programs is
22.19 percent (77/(77+157+113)), 45.24 percent (157/(77+157+113)), and
32.56 percent (113/(77+157+113)) for individual market plans, MA, and
Medicaid respectively. Table 7 shows similar proportions for 2017 and
2018.
Table 7--Proportion of Premiums (in Billions) for Medicare, Medicaid, and Individual Market Plans
----------------------------------------------------------------------------------------------------------------
Medicare Individual
Year Medicaid Advantage market plans Totals
----------------------------------------------------------------------------------------------------------------
2016 Premium (billions)......................... 113 157 77 347
2017 Premium (billions)......................... 119.5 170.3 86 376
2018 Premium (billions)......................... 127 184 91 402
2016 Percentage (used in this RIA in all 32.56% 45.24% 22.19% 100.00%
estimates) of total costs by program...........
2017 Percentage................................. 31.78% 45.29% 22.93% 100.00%
2018 Percentage................................. 31.62% 45.81% 22.56% 100.00%
----------------------------------------------------------------------------------------------------------------
As indicated earlier, since cost allocation at the parent
organization level and the allocations of each parent organization may
differ by program (Medicare, Medicaid, CHIP, and Individual market
plans) and is an internal business decision, we cannot directly assess
per-payer costs. However, using the MLR tables, we can assess the
proportions of cost by program. We can then multiply these proportions
(as presented in Table 7) by the total costs of this final rule as
presented in Table 5 to obtain Table 8, which breaks out the total
column in Table 5, the total cost by year of implementing and
maintaining the API, to offer API costs by year and program.
Table 8--API Costs (in Millions) by Year and Program
----------------------------------------------------------------------------------------------------------------
Full
implementation
and maintenance Individual Medicare
Year costs (millions) market plans Medicaid and Advantage
(from Table 5) (22.19%) CHIP (32.56%) (45.24%)
for API
provision
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate)..................... 272.0 60.4 88.6 123.1
2020 (Primary estimate)................. 544.0 120.7 177.2 246.1
2020 (High Estimate).................... 816.0 181.1 265.7 369.2
2021.................................... 54.4 12.1 17.7 24.6
2022.................................... 54.4 12.1 17.7 24.6
[[Page 25615]]
2023.................................... 54.4 12.1 17.7 24.6
2024.................................... 54.4 12.1 17.7 24.6
2025.................................... 54.4 12.1 17.7 24.6
2026.................................... 54.4 12.1 17.7 24.6
2027.................................... 54.4 12.1 17.7 24.6
2028.................................... 54.4 12.1 17.7 24.6
2029.................................... 54.4 12.1 17.7 24.6
-----------------------------------------------------------------------
Total (Low Estimate)................ 761.5 169.0 248.0 344.6
Total (Primary Estimate)............ 1033.5 229.3 336.6 467.6
Total (High Estimate)............... 1305.5 289.7 425.1 590.7
----------------------------------------------------------------------------------------------------------------
Methods of Bearing Cost by Payer
QHPs on the FFEs: Individual market plans have the option to deal
with increased costs by either temporarily absorbing them (for purposes
of market competitiveness), increasing premiums to enrollees, or
reducing non-essential health benefits. To the extent that issuers
increase premiums for individual market plans on the FFEs, there would
be federal premium tax credit (PTC) impacts. The purpose of the PTC is
to assist enrollees in paying premium costs. Since PTCs are only
available if an individual purchases an individual market plan on an
Exchange, the PTC estimates apply only to Exchange plans. In the PTC
estimate, we have accounted for the fact that some issuers have both
Exchange and non-Exchange plans, and some issuers have only non-
Exchange plans. We reflected these assumptions with global adjustments,
so we believe the estimates are reasonable in aggregate.
Medicare Advantage: MA organizations may increase bids to reflect
the costs of this final rule. Some of these expected increased bid
costs may increase Medicare Trust Fund payments. For those (most) MA
organizations whose bid amount is below the benchmark, the Trust Fund
provides total expenditures to the MA organizations consisting of: (1)
Full payment of the bid amount; and (2) the rebate, a portion of the
difference between the benchmark and the bid amount. Since MA
organizations are increasing their bid amounts to reflect the costs of
this final rule, it follows that the rebate, equaling the difference
between the benchmark and bid, is decreased, resulting in less rebates
paid to the MA organizations. Based on our past experience and
projections for the future, the rebate is estimated as 34 percent of
the difference between benchmark and bid. Thus, although the Trust Fund
pays the bid in full, nevertheless, 66 percent of the increased bid
costs arising from this final rule, are reduced from the rebates. The
MA organizations in its submitted bid, can address this reduction of
rebates by either: (1) Temporarily, for marketing purposes, absorbing
the loss by reducing its profit margin; (2) reducing the supplemental
benefits it provides the enrollee paid for by the rebate; or (3)
raising enrollee premiums in order to provide supplemental benefits for
which premiums are not paid by the rebate. The decision of what
approach to use is an internal business decision in part motivated by
unforeseen forces of marketing; we therefore have no way of predicting
what will happen.
Medicaid: State Medicaid agencies may be allowed to allocate the
costs of state information retrieval systems between the costs
attributable to design, development, installation, or enhancement of
the system--at a 90 percent federal match--and for ongoing operations
of the system--at a 75 percent federal match.
For Medicaid managed care entities, we assume an MCO, PIHP, and
PAHP cost for implementing the standards-based API provisions would be
built into the capitation rates and paid for by the state Medicaid
agency, with the state Medicaid agency being reimbursed at the state's
medical assistance match rate. For purposes of these estimates we use
the weighted FMAP, 58.44, which is based on our past experience with
this program.
Medicaid managed care costs constitute 52 percent of the Medicaid
program costs.\72\
---------------------------------------------------------------------------
\72\ Allen, K. (2019, April 18). Medicaid Managed Care Spending
in 2018. Retrieved from https://www.healthmanagement.com/blog/medicaid-managed-care-spending-in-2018/.
---------------------------------------------------------------------------
Consequently, for the first year (implementation year), the federal
matching is (0.48*0.90+0.52*0.5844) of the total program costs,
reflecting the 90 percent first year implementation matching for state
agencies which comprise 48 percent of the program cost plus 58.44
percent matching for the Medicaid managed care plans which comprise 52
percent of the program costs. Similarly, for years after the first the
federal costs are (0.48*0.75+0.52*0.5844) of total program costs.
CHIP: Most states operate Medicaid and CHIP from the same state
agency. One state is a notable exception in that it has a separate
Medicaid and CHIP agency. The federal government pays an enhanced
federal medical assistance percentage (EFMAP) to states for all costs
associated with CHIP, including systems costs (this is unlike Medicaid
where there are different FMAPs for different types of costs). For
federal FY 2019, the EFMAPs will range from 88 to 100 percent. For
federal FY 2020, the EFMAPs will range from approximately 76.5 to 93
percent. After federal FY 2020, the EFMAPs will range from
approximately 65 to 81.5 percent. Since the CHIP program federal rebate
ranges include the 90 percent and 75 percent federal matching
proportions of the Medicaid program, we are applying the 90 percent and
75 percent from Medicaid to the CHIP programs. Since the CHIP program
is small relative to the Medicaid program, we believe this approach
reasonable.
Table 9 uses these proportions to estimate the impact of the API on
the federal government. For example, the $65.2 million cost to the
federal government for Medicaid/CHIP for 2020
[[Page 25616]]
(low estimate), the implementation year of the API, is obtained by
multiplying the total $88.6 million (low estimate) cost listed in Table
8 by (0.48*0.90+0.52*0.5844) the ratio indicated in the previous
paragraphs.
These assumptions on all first-year federal expenses are reflected
in Table 9 which includes PTC payments as well as federal matching in
Medicaid and Medicare. For PTC and Medicare we have assumed Federal
payment in 2021. We note that we are not discussing at this point how
parent organizations will bear these costs. This will be discussed
below. However, the basis for the discussion is the calculation of non-
federal cost born by enrollees and plans which is obtained by
subtracting federal costs from total costs.
Table 9--Costs Incurred by Federal Government Program and Year
[In Millions]
----------------------------------------------------------------------------------------------------------------
For individual For Medicaid For Medicare
Year market plans CHIP Advantage
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate)............................................. 0.0 65.2 0.0
2020 (Primary estimate)......................................... 0.0 130.4 0.0
2020 (High Estimate)............................................ 0.0 195.5 0.0
2021 (Low estimate)............................................. 6.1 11.8 50.2
2021 (Primary Estimate)......................................... 6.1 11.8 92.1
2022 (High Estimate)............................................ 6.1 11.8 133.9
2022............................................................ 6.2 11.8 8.4
2023............................................................ 6.2 11.8 8.4
2024............................................................ 6.3 11.8 8.4
2025............................................................ 6.3 11.8 8.4
2026............................................................ 6.3 11.8 8.4
2027............................................................ 6.3 11.8 8.4
2028............................................................ 6.3 11.8 8.4
2029............................................................ 6.4 11.8 8.4
-----------------------------------------------
Total (Low Estimate)........................................ 56.4 171.0 117.1
-----------------------------------------------
Total (Primary Estimate).................................... 56.4 236.2 159.0
-----------------------------------------------
Total (High Estimate)....................................... 56.4 301.4 200.8
----------------------------------------------------------------------------------------------------------------
Note: The following percentages were applied to Table 8 to obtain Table 9: 0 percent for individual market
plans, 34 percent for Medicare advantage plans and 0.48*0.90+0.52*0.5844 (1st year) and 0.48*0.75+0.52*0.5844
(later years) for Medicaid. Furthermore, as discussed above, federal payments to Medicare Advantage for
implementation occurs fully in 2021.
By taking the difference between the respective cells in Tables 8
(total costs by program) and 9 (total matching by the federal
government), we obtain the remaining costs for the API for Medicare
Advantage plans and for state Medicaid agencies. To this amount (which
only deals with the API provisions) must be added the coordination cost
for the dual eligible (column 3 of Table 5) multiplied by the
proportion of costs presented in Table 7. This remaining cost born by
Medicare Advantage plans and state Medicaid agencies is presented in
Table 10. Since the federal government does not match QHP costs, the
total cost for QHPs on the FFEs is born in its entirety by the plans.
This also is listed in Table 10; however, in subtracting Table 9 from
Table 8, we exclude PTC costs. These are federal costs, but unlike
Medicare Advantage and Medicaid, the QHPs on the FFEs must account for
the full cost of implementation. These PTC costs are not used to defray
API costs.
For example, Table 10 lists for 2020 (low estimate), Medicaid/CHIP
a remaining cost to states of $24.3 million ($88.6 million total (low
estimate) cost for 2020 (Table 8)-$65.2 million matched by the federal
government (Table 9) + ($2.8 million total cost for coordination of
dual eligibles (Table 5) * 32.56 percent (proportion of total costs
incurred by Medicaid/CHIP (Table 7)). (There are minor differences due
to rounding.)
Table 10--Remaining Costs by Program for API by Year
[In millions]
----------------------------------------------------------------------------------------------------------------
For individual For Medicaid/ For Medicare
Year market plans CHIP Advantage
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate)............................................. 61.0 24.3 124.3
2020 (Primary estimate)......................................... 121.3 47.7 247.4
2020 (High Estimate)............................................ 181.7 71.1 370.1
2021 (Low estimate)............................................. 12.8 7.0 -24.1
2021(Primary Estimate).......................................... 12.8 7.0 -65.9
2021 (High Estimate)............................................ 12.8 7.0 -107.8
2022............................................................ 12.3 6.2 16.6
2023............................................................ 12.1 6.0 16.2
2024............................................................ 12.1 6.0 16.2
2025............................................................ 12.1 6.0 16.2
2026............................................................ 12.1 6.0 16.2
2027............................................................ 12.1 6.0 16.2
2028............................................................ 12.1 6.0 16.2
[[Page 25617]]
2029............................................................ 12.1 6.0 16.2
-----------------------------------------------
Total (Low Estimate)........................................ 170.5 79.3 230.6
-----------------------------------------------
Total (Primary Estimate).................................... 230.9 102.6 311.8
-----------------------------------------------
Total (High Estimate)....................................... 291.3 126.0 392.7
----------------------------------------------------------------------------------------------------------------
We next discuss in Tables 11 through 13 how payers and the federal
government will deal with these extra costs. We also discuss whether
the costs are excessive for existing plans as well as how new plans
might deal with these costs.
The further discussion of bearing these costs is illustrated by
reformulating the costs in terms of costs per enrollee (per year),
which is obtained by dividing the total cost to the payer for all
programs in which it participates (Medicare, Medicaid, CHIP, and
Individual market plans) by its total enrollment. As an example, if a
payer hypothetically spent $1 billion in a year for 100,000 enrollees
then the cost per enrollee per year is $10,000 ($1 billion/100,000).
As can be seen from this example, the cost per enrollee metric
facilitates comparison of costs. Since program expenditures for both
Medicaid and MA are typically hundreds of millions (or billions) of
dollars, concepts like burden and negligibility may not have intuitive
meaning, as opposed to the costs per enrollee, which are more
manageable and understandable.
To provide background, the 2018 Medicare Trust Fund Report \73\
states that costs per enrollee are projected to be roughly $12,000--
$14,000 for contract years 2020--2023 (Table IV.C3). The costs per
enrollee for the Medicaid program are similarly several thousand
dollars. The estimates in the 2019 Medicare Trust Fund Report are
identical.\74\
---------------------------------------------------------------------------
\73\ Boards of Trustees (Federal Hospital Insurance and Federal
Supplementary Medical Insurance Trust Funds). (2018, June 5). The
2018 Annual Report of The Boards of Trustees of the Federal Hospital
Insurance and Federal Supplementary Medical Insurance Trust Funds.
Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf.
\74\ See page 154 in, Boards of Trustees (Federal Hospital
Insurance and Federal Supplementary Medical Insurance Trust Funds).
(2019, April 22). The 2019 Annual Report of The Boards of Trustees
of the Federal Hospital Insurance and Federal Supplementary Medical
Insurance Trust Funds. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2019.pdf.
---------------------------------------------------------------------------
For purposes of indicating the cost per enrollee, we estimate 110.5
million enrollees will be affected by these provisions since currently
there are 17.5, 66,\75\ 20,\76\ and 7 \77\ million enrollees covered by
payers in the individual market, Medicaid, MA, and separate CHIP
programs, respectively. Table 11 presents costs per enrollee by program
for payers after reducing total costs by federal matching, while Table
12 presents costs per enrollee by program for the federal government.
---------------------------------------------------------------------------
\75\ Centers for Medicare and Medicaid Services. (n.d.). October
2019 Medicaid & CHIP Enrollment Data Highlights. Retrieved from
https://www.medicaid.gov/medicaid/program-information/medicaid-and-chip-enrollment-data/report-highlights/index.html.
\76\ Centers for Medicare and Medicaid Services. (n.d.). Monthly
Contract Summary Report--August 2018. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/MCRAdvPartDEnrolData/Monthly-Contract-and-Enrollment-Summary-Report-Items/Contract-Summary-2018-08.html?DLPage=1&DLEntries=10&DLSort=1&DLSortDir=descending.
\77\ Centers for Medicare and Medicaid Services. (n.d.). October
2019 Medicaid & CHIP Enrollment Data Highlights. Retrieved from
https://www.medicaid.gov/medicaid/program-information/medicaid-and-chip-enrollment-data/report-highlights/index.html.
---------------------------------------------------------------------------
For example, the 2020 (low estimate) cost per enrollee for
commercial individual market plans is $3.48 (Table 11), which is
obtained by dividing the total, 2020, low-estimate, non-federal,
individual market plan cost of $61 million (Table 10) by 17.5 million
enrollees. (This is based on the low estimate of cost for API; the high
estimate of cost would be $10.38 = $181.7 million/17.5 million).
The 2022 cost per enrollee for state Medicaid agencies after
federal matching is 9 cents per enrollee (Table 11), which is obtained
by dividing the total non-federal cost per program after federal
matching, $6.2 million (Table 10) by 73 million enrollees (66 million
in Medicaid + 7 million in CHIP). Each of these three calculations
restates total spending per program per stakeholder (government, state
Medicaid agencies, or Medicare Advantage plans) in terms of cost per
enrollee.
Table 11--Average Cost per Enrollee per Year (Dollars and Cents) by Program for Payers
----------------------------------------------------------------------------------------------------------------
Individual Medicare
Current enrollment by payer (millions) market plans Medicaid Advantage
(17.5) plans (73) plans (20)
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate)............................................. 3.48 0.33 6.22
2020 (Primary estimate)......................................... 6.93 0.65 12.37
2020 (High Estimate)............................................ 10.38 0.97 18.51
2021 (Low estimate)............................................. 0.73 0.10 -1.20
2021(Primary Estimate).......................................... 0.73 0.10 -3.30
2021 (High Estimate)............................................ 0.73 0.10 -5.39
2022............................................................ 0.70 0.09 0.83
2023............................................................ 0.69 0.08 0.81
2024............................................................ 0.69 0.08 0.81
2025............................................................ 0.69 0.08 0.81
[[Page 25618]]
2026............................................................ 0.69 0.08 0.81
2027............................................................ 0.69 0.08 0.81
2028............................................................ 0.69 0.08 0.81
2029........................................................ 0.69 0.08 0.81
-----------------------------------------------
Total (Low Estimate)........................................ 9.7 1.1 11.5
-----------------------------------------------
Total (Primary Estimate).................................... 13.2 1.4 15.6
-----------------------------------------------
Total (High Estimate)....................................... 16.6 1.7 19.6
----------------------------------------------------------------------------------------------------------------
Table 12--Average Cost per Enrollee per Year (Dollars and Cents) by Program for Federal Government
----------------------------------------------------------------------------------------------------------------
Individual Medicare
Current enrollment by payer (millions) market plans Medicaid Advantage
(17.5) plans (73) plans (20)
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate)............................................. 0.00 0.89 0.00
2020 (Primary estimate)......................................... 0.00 1.79 0.00
2020 (High Estimate)............................................ 0.00 2.68 0.00
2021 (Low estimate)............................................. 0.35 0.16 2.51
2021(Primary Estimate).......................................... 0.35 0.16 4.60
2021 (High Estimate)............................................ 0.35 0.16 6.69
2022............................................................ 0.35 0.16 0.42
2023............................................................ 0.35 0.16 0.42
2024............................................................ 0.36 0.16 0.42
2025............................................................ 0.36 0.16 0.42
2026............................................................ 0.36 0.16 0.42
2027............................................................ 0.36 0.16 0.42
2028............................................................ 0.36 0.16 0.42
2029............................................................ 0.37 0.16 0.42
-----------------------------------------------
Total (Low Estimate)........................................ 3.2 2.3 5.9
-----------------------------------------------
Total (Primary Estimate).................................... 3.2 3.2 7.9
-----------------------------------------------
Total (High Estimate)....................................... 3.2 4.1 10.0
----------------------------------------------------------------------------------------------------------------
In Table 13, we explain possible ways payers may deal with these
extra costs. We emphasize that Table 13 lists potential legal
possibilities. What actually happens will depend on market dynamics and
internal business decisions, and we have no straightforward way of
predicting what these actual behaviors and responses will be.
Individual Market Plans: As noted above, individual market plans
have the option of absorbing costs or passing costs to enrollees either
in the form of higher premiums or reduced benefits that are non-
essential health benefits (EHBs). The average estimated cost per
enrollee in 2021 through 2028 is under a dollar, which we assume
issuers would pass on to enrollees. However, for purposes of market
competitiveness, it is possible that some of the 2020 average estimated
cost of $3.48 per enrollee (low estimate) or $10.38 per enrollee per
year (high estimate) would be absorbed by each QHP issuer on an FFE.
Medicaid: State Medicaid agencies and CHIP are adding a cost under
10 cents per enrollee for 2021 through 2029. Total costs per enrollee
for the Medicaid program are several thousand dollars. We note, the
federal government is incurring costs capped at $2.68 per enrollee per
year in 2020 and at 16 cents per enrollee per year in 2021 through
2029.
Medicare Advantage: In their bids (submitted the June prior to the
beginning of the coverage year), Medicare Advantage plans would address
the reduced rebates (arising from increased bid costs due to the
increased costs of this final rule being included in the bid) by
either: (1) Temporarily absorbing costs by reducing profit margins; (2)
reducing the supplemental benefits paid for by the rebates; or (3)
raising enrollee cost sharing or premiums (however, we believe many
plans for competitive reasons would chose to remain zero premium and
either absorb losses for one year or reduce rebate-funded supplemental
benefits in the amount per enrollee shown in Table 9). Table 13
summarizes these methods of bearing the remaining costs.
[[Page 25619]]
Table 13--How Payers Would Defray Remaining Costs
------------------------------------------------------------------------
------------------------------------------------------------------------
Individual Market Plans........... Individual market plans generally
have the option of absorbing costs
(for example, for reasons of market
competitiveness), increasing
premiums to enrollees, or modifying
cost-sharing or non-EHB covered
benefits. Cost would be spread over
all parent organization enrollees
in a specified state and the
individual market in FFE states.
Small commercial individual market
issuers seeking certification of
plans as QHPs on the FFEs may
request an exception to the API
provisions.
Medicaid/CHIP..................... State Medicaid agencies would bear
the cost (under 10 cents per
enrollee). Medicaid plans are fully
capitated but may have to defer
first year costs.
Medicare Advantage (MA)........... MA plans in their June-submitted
bids would address the reduced
rebates (arising from increased bid
costs due to the increased costs of
this final rule being included in
the bid) by either: (1) Temporarily
absorbing costs by reducing profit
margins; (2) reducing additional
benefits paid for by the rebates;
or (3) raising enrollee cost
sharing (however, many plans for
competitive reasons would chose to
remain zero premium and either
absorb losses for one year or
reduce additional, rebate-funded
benefits in the amount per enrollee
shown in Table 9). Tax deferment
and amortization as applicable
ameliorates cost. Capital costs are
spread over entire parent
organization enrollees. New plans
are allowed to enter with initial
negative margins with the
expectation that they will
stabilize over the first few years.
------------------------------------------------------------------------
PTC Impact: First, we note that there will be no impact on the
expected 2020 PTC payment because 2020 premium rates were finalized
last year, so even if issuers incur expenses that they did not
anticipate when setting rates, they will not be able to reflect those
expenses in the premium rates, and therefore, the expected PTC payments
for 2020 will not change.
Table 10 shows that for 2021 through 2029 the estimated impact to
QHPs on the FFEs is a $12 million expense. This estimated $12 million
expense burden represents an increase to annual FFE premium of
approximately 0.03 percent.
Within the FFE states, the estimated expense burden will impact
premium rates in the individual market, and is spread across both
Exchange and non-Exchange QHPs. PTCs are only paid for QHPs offered
through Exchanges, and are calculated as a function of the second
lowest cost silver plan. Because of the wide variability of Exchange
plans we make the simplifying assumption that the industry would
increase the second-lowest-cost silver plan premium rate in the same
amount as the overall premium rate increase as a result of the RIA
expense estimate. We can then apply the overall rate increase to the
projected PTC payments in the FFE states to estimate the impact to PTC
payments.
Therefore, we estimate that impact to PTCs in the FFE states will
be approximately $6 million per year starting in 2021, which is about
0.02 percent of the total 2021 expected PTC payment in FFE states.
Again, the calculated PTC impacts in 2021 through 2029 are included
with all federal impacts in Table 9.
We next summarize the public comments we received on our estimated
impacts and provide our responses.
Comment: Some commenters requested that the government share more
in the associated costs of the open, standards-based API implementation
for both MA and Medicaid plans. These commenters noted that additional
financial sharing by the federal government would help remedy offsets
potentially being absorbed by the health plan that may result in
decreased benefits and/or increase premiums.
Medicare Advantage: Some commenters requested that the costs be
included in MA bids. Other commenters recommended that if CMS is going
to make specific technological requirements around implementation of
the CMS Interoperability and Patient Access proposed rule then health
plans should be allowed to include a percentage of these costs in their
MA bids. One commenter recommended that CMS could consider adding a
fixed dollar amount to MA bids if health plans complied with the
requirements of the proposed rule, or CMS could add it into the bid
tool.
Medicaid: Similar comments were made for Medicaid plans. One
commenter recommended that CMS provide states with a 100 percent
federal matching to facilitate implementation and that state Medicaid
agencies be required to include plan implementation costs into
capitation rates. Another commenter requested that CMS require state
Medicaid agencies to include a fixed amount of dollars or a percentage
of implementation costs into plan administrative costs to remedy the
cost impact of implementation.
Response: We appreciate the commenters' concerns and suggestions.
As noted previously in this RIA, we have assumed traditional federal
sharing of costs for both the MA and Medicaid programs. The results
have been presented in Tables 9 through 12 with Table 13 indicating how
payers and the federal government would defray costs. In Tables 11 and
12 the average estimated costs per enrollee (under $15) is compared
with overall costs per enrollee (several thousand dollars).
Additionally, we have been careful in our analysis to distinguish
between federal matching to state Medicaid entities in the first year,
federal matching to state Medicaid entities in later years, and federal
matching of state payment of capitation rates to state Medicaid
agencies. We take note that the commenter's concerns for specific
federal matching for the provisions of this final rule would require
legislative action. Consequently, when writing the CMS Interoperability
and Patient Access proposed rule, we did not believe it was necessary
to propose additional federal spending beyond the already existing
federal reimbursement to MA, Medicaid plans, and state agencies.
Comment: A few commenters expressed concern that the CMS
Interoperability and Patient Access proposed rule was not clear with
regard to whether or not state Medicaid agencies would be allowed to
allocate the costs of this implementation--at a 90 percent federal
match--and for ongoing operations of the system--at a 75 percent
federal match. Commenters requested that CMS provide clarity around the
use of such language and exactness of ``pay fors'' since this is vital
for state Medicaid agencies' cost estimates in implementing the
requirements of this rule.
Response: We agree with the commenters. We therefore have revised
the calculations to Table 10 to reflect the following more precise
accounting of costs: (1) 90 percent of state Medicaid costs are paid or
matched by the federal government in the first year of implementing new
systems; (2) 75 percent of Medicaid costs are matched for maintenance
costs; and (3) on average, state Medicaid agencies are
[[Page 25620]]
matched 58.44 percent. We believe this heightened level of detail
should satisfy commenter concerns. The revised numbers are reflected in
Tables 10 and Table 11.
Comment: One commenter noted that the developers of APIs may want
additional fees to implement or provide access to their APIs. The
commenter noted that these fees severely limit innovation in the
marketplace for health IT solutions for storing and utilizing patient
data, both on the patient and provider side of the equation.
Response: The data that must be shared via the API under this
policy are data that the payers have and must currently make available
to patients. We also anticipate that many payers will develop the APIs
in-house. If this commenter is more referencing the vendors creating
apps, versus APIs for payers, we also do not believe it is appropriate
to charge a fee, as discussed in section III. of this final rule. If
fees are charged for certain apps, it is not the data that are
generating the fee, it is the product or services; indeed, there is a
logical connection between the potential benefits of this rule
(facilitated by new or enhanced services) and non-quantified potential
costs (possibly including those associated with the development or
improvement of such services). Currently there are vendors that collect
the publicly available directory data, clean these data, supplement
these data, and offer this enhanced data product back to payers and
providers. It is not the data the vendors are charging for as much as
it is the service of cleaning and enhancing these data. Vendors may
generate revenue from their third-party apps, but a major component of
this is the service they are providing--building the app, making the
data the patient directs to them most usable and valuable--that
generates the revenue. Payers must already make these data available to
patients. These data alone may also drive revenue, but it is the
patient's prerogative to provide their data to a third party in order
to get a service in exchange
Comment: A few commenters noted that RIA does not contain any costs
for provider EHR connectivity. One commenter noted that EHR developers'
contracts with providers and health systems do not include the cost of
system updates that will be required to comply with this proposal.
Another commenter was concerned that EHR developers will charge
providers significant fees to perform the updates required to comply
with CMS' proposals, and providers will likely need to make additional
investments to learn how to use standards-based APIs and other new
technologies. Another commenter believes that for the clinical data to
be available in any API, the CEHRT used by providers needs to be
connected to a trusted exchange network. For many clinicians, the
commenter noted the costs for connecting their CEHRT to a trusted
network continues to remain a barrier.
Response: To address commenters' concerns with API connectivity to
an EHR, we note that there is no requirement for a payer to link the
Patient Access API to an EHR in this final rule, and there are
associated challenges, as discussed elsewhere in this RIA, with
attributing impacts to various interacting regulatory and other
policies. Indeed, we do note that if a provider does elect to connect
an EHR to the APIs finalized in this rule, they would be required to
meet all the requirements of ONC's Health IT Certification Program.\78\
As part of that program, the 2015 CEHRT includes, for example,
``application access'' certification criteria that requires health IT
to demonstrate it can provide application access to the Common Clinical
Data Set (CCDS) via an API.\79\ Furthermore, nearly a third of EHR
vendors are also using the FHIR standard to meet 2015 CEHRT
requirements.\80\
---------------------------------------------------------------------------
\78\ Office of the National Coordinator. (2019, March 27). About
the ONC Health IT Certification Program. Retrieved from https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program.
\79\ Centers for Medicare and Medicaid Services. (n.d.). 2019
Promoting Interoperability Programs: 2015 Edition Certified EHR
Technology Fact Sheet. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/CEHRT2015Ed_FactSheet-.pdf.
\80\ Posnack, S. & Baker, W. (2018, October 1). Heat Wave: The
U.S. is Poised to Catch FHIR in 2019. Retrieved from https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019.
---------------------------------------------------------------------------
C. Anticipated Effects
The RFA, as amended, requires agencies to analyze options for
regulatory relief of small businesses, if a rule has a significant
impact on a substantial number of small entities. For purposes of the
RFA, small entities include small businesses, nonprofit organizations,
and small governmental jurisdictions.
The API requirements in this final rule affect: 1) QHP issuers on
the FFEs, 2) MA organizations, including those that are also Part D
sponsors of MA-PD plans, as well as 3) Medicaid MCOs with a minimum
threshold for small business size of $41.5 million (https://www.sba.gov/federal-contracting/contracting-guide/size-standards).
Assessment of impact is complicated by the fact that costs have
been aggregated at the parent organization level. A typical parent
organization might have products with QHP issuers on the FFEs, MA, or
Medicaid/CHIP programs. We have no way of directly assessing the size
of parent organizations. Therefore, as a proxy, we analyze each payer
separately.
Medicare Advantage: We first assess the impact on MA plans. To
clarify the flow of payments between these entities and the federal
government, we note that MA organizations submit proposed plan designs
and estimates of the amount of revenue necessary to cover the cost of
those plan designs (called bids) by the first Monday in June of the
year preceding the coverage year. Regulations governing this process
are in 42 CFR part 422, subpart F. These bids must be broken down in
the following:
(1) The revenue requirements for providing Medicare Part A and Part
B benefits with actuarially equivalent cost sharing (this is the
``basic benefit bid'');
(2) The revenue requirements for providing supplemental benefits;
(3) The revenue requirements for Non-Benefit Expenses such as Sales
& Marketing, Direct and Indirect Administration, Net Cost of
Reinsurance, and Insurance Fees; and
(4) For MA-PD plans, a Part D bid consistent with Part D
regulations in 42 CFR part 423.
These bids project payments to hospitals, providers and staff for
covered benefits, as well as the cost of plan administration and
profits. Because the API requirements finalized in this rule will apply
to every MA plan and each MA plan must furnish at least the Medicare
Part A and Part B benefits, the cost of the API will be built into the
administrative component of the basic benefit bid. These bids in turn
determine one component of the payments of the Medicare Trust Fund to
the MA organizations who reimburse providers and subcontractors for
their services. A second component of the Trust Fund payment to MA
organizations are the rebates, which are a portion of the difference
between the basic benefit bid compared to an administratively-set
benchmark for the MA plan's service area (currently, based on our past
and projected experience, rebates vary by plan and are approximately 66
percent). Benchmarks are based on a formula using an estimate of the
Medicare FFS per capita cost for the geographic area, which are
adjusted to reflect the per capita cost of each county in the U.S. and
its territories and adjusted for the enrollees' health status
[[Page 25621]]
which is also known as the risk score. Payments from the Medicare Trust
Funds for monthly capitation rates (for basic benefits) are capped at
the benchmark; for basic benefit bids under the benchmark, a portion,
currently approximately 66 percent, of the difference between the bid
and benchmark is made available to the MA organization to either: (1)
Pay for additional supplemental benefits; (2) include reductions in
cost sharing in the plan design; or (3) provide buy-downs of Part B or
Part D premiums. Basic benefit bids that are at or above the benchmark
receive payment from the Trust Funds of the benchmark amount, with any
excess charged to the enrollee as a premium.
MA organizations are made aware of the benchmark through the annual
CMS publication, ``Announcement of Calendar Year [X] Medicare Advantage
Capitation Rates and Medicare Advantage and Part D Payment Policies,''
which, consistent with section 1853 of the Act, is released prior to MA
organizations submission of bids. This publication of the benchmark
when coupled with plan awareness that they will receive rebates if
their plan bids fall below the benchmark facilitates that bids of most
MA organizations are below the benchmark and consequently most MA
organizations receive from the Trust Fund a total expenditure equaling
payment for the bid plus the rebate.
Because of these API provisions, we assume that MA organizations
will be raising the June-submitted bid amount to reflect additional
administrative costs. While the Trust Fund pays these bid amounts in
full, the rebate goes down as the bid increases: That is, since the bid
amount goes up, the rebate, equaling the difference between the
benchmark and bid, decreases and results in less rebate payment to the
MA organization. The MA organization has several options of dealing
with these increased bid costs and reduced rebates: The MA organization
might decide to: (1) Temporarily absorb the loss by reducing its profit
margin (so as to reduce the bid amount and thereby increase the
rebates); (2) reduce additional benefits paid to the enrollee from the
rebates; or (3) raise enrollee premiums so as to compensate for the
reduction of enrollee premium that would have happened if the bid had
not been increased (note: for marketing purposes, many plans operate at
zero premium, and we do not consider this third option a likely
possibility). In this RIA, we have referred to options (2) and (3)
(reduction of additional benefits and raising of enrollee premiums) as
``passing the costs to the enrollee'' so that the ``effect'' of reduced
rebates is fewer supplemental benefits or higher enrollee premiums than
would have happened had the cost of the complying with the API
provisions of this final rule not been imposed.
There are various types of Medicare health plans, including MA
HMOs, POS plans, and PPOs; Demonstration plans; Cost Plans;
Prescription Drug Plans (PDP); and Programs of All-Inclusive Care for
the Elderly (PACE) organization plans. This final rule affects MA HMOs,
MA POS plans, and MA PPOs including those that are MA-PDs, but does not
affect Cost Plans, stand-alone Prescription Drug Plans, nor PACE
organizations.
There are a variety of ways to assess whether MA organizations meet
the $41.5 million threshold for small businesses. The assessment can be
done by examining net worth, net income, cash flow from operations and
projected claims as indicated in their bids. Using projected monetary
requirements and projected enrollment for 2018 from submitted bids,
approximately 30 percent of the MA organizations fell below the $41.5
million threshold for small businesses. Additionally, an analysis of
2016 data, the most recent year for which we have actual data on MA
organization net worth, shows that approximately 30 percent of all MA
organizations fall below the minimum threshold for small businesses.
Medicaid: We next assess the impact on Medicaid managed care plans.
Since Medicaid managed care plans receive 100 percent capitation from
the state, we generally expect that the costs associated with the API
provisions of this final rule, will be included in their capitation
rates and may be reasonable, appropriate, and attainable costs whether
they are a small business or not.
QHP issuers on the FFEs: Based on the 2016 CMS MLR data,
approximately 85 out of 494, or 17 percent of companies (that either
had only individual market business, or had individual market plus
Medicare and/or Medicaid business) had total premium revenue of less
than $41,500,000. In other words, for MA, Medicaid, and QHP issuers on
the FFEs, a significant number of small plans are affected. The RFA
requires us to assess whether the rule has a significant impact on the
plans, which we do next.
If a rule has a substantial impact on a substantial number of small
entities, the rule must discuss steps taken, including alternatives, to
minimize burden on small entities. While a significant number (more
than 5 percent) of not-for-profit organizations and small businesses
are affected by this final rule, the impact is not significant. To
assess impact, we use the data in Table 5, which shows that the total
raw (not discounted) net effect of this final rule over 10 years is
$714 million.
Medicare Advantage: We first assess impact on MA plans. Comparing
the $714 million number to the total monetary amounts projected to be
needed just for 2018, the most recent year on which we have finalized
plan submitted bid data (and which is expected to be less than the need
in future years including 2019), we find that that the impact of this
final rule is significantly below the 3 percent-5 percent threshold for
significant impact for MA plans.
Medicaid: We next assess impact on Medicaid managed care plans. The
total projected capitation payment and premiums for 2019 is projected
to be $337.6 billion.\81\ Hence, the total cost of this final rule over
10 years, $714 million, is significantly below the 3 percent-5 percent
threshold for significant impact to Medicaid managed care plans.
---------------------------------------------------------------------------
\81\ See ``Capitation payments & premiums'' in Table 17 of
Appendix D in, Office of the Actuary (Centers for Medicare and
Medicaid Services). (2016). 2016 Actuarial Report on the Financial
Outlook for Medicaid. Retrieved from https://www.medicaid.gov/medicaid/finance/downloads/medicaid-actuarial-report-2016.pdf.
---------------------------------------------------------------------------
QHP issuers on the FFEs: As discussed prior to Table 6 based on
data in the public CMS MLR files, commercial health insurance issuers
had premium revenue of $77 billion for individual market plan coverage
in 2016. Therefore, the aggregate raw cost of this final rule over 10
years, $762 million (low estimate) and $1.3 billion (high estimate), is
significantly below the 3 percent to 5 percent threshold for
significant impact to commercial plans. We believe, that although a
significant number of small plans under each program are affected by
this rule, on average this impact is not significant. Additionally, we
note that for those small entities that do find the cost of the
provisions of this final rule burdensome, an exception process has been
described in section III.C. of this final rule. Specifically, we note
that we may provide an exceptions process through which the FFEs may
certify health plans that do not provide patient access through a
standards-based API, but otherwise meet the requirements for QHP
certification. This process could apply for small issuers, issuers who
are only in the individual or small group market, financially
vulnerable issuers, or new entrants to the FFEs who demonstrate that
deploying standards-
[[Page 25622]]
based API technology consistent with the required interoperability
standards would pose a significant barrier to the issuer's ability to
provide coverage to consumers, and not certifying the issuer's QHP or
QHPs would result in consumers having few or no plan options in certain
areas.
Consequently, the Secretary has determined that this final rule
will not have a significant economic impact on a substantial number of
small entities and the requirements of the RFA have been met. Please
see our detailed analysis of apportionment of costs per payer in Tables
6 through 13 and section XIII.H. of this final rule for further
details.
In addition, section 1102(b) of the Act requires CMS to prepare an
RIA if a rule may have a significant impact on the operations of a
substantial number of small rural hospitals. This analysis must conform
to the provisions of section 604 of the RFA. For purposes of section
1102(b) of the Act, we define a small rural hospital as a hospital that
is located outside a Metropolitan Statistical Area and has fewer than
100 beds. We are not preparing an analysis for section 1102(b) of the
Act because we have determined, and the Secretary certifies, that this
final rule would not have a significant impact on the operations of a
substantial number of small rural hospitals.
Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA)
(Pub. L. 104-04, enacted March 22, 1995) also requires that agencies
assess anticipated costs and benefits before issuing any rule whose
mandates, except those that are conditions of federal program
participation, require spending in any 1 year of $100 million in 1995
dollars, updated annually for inflation. In 2020, that is approximately
$156 million. This rule does not impose any such unfunded mandates.
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a proposed rule (and subsequent
final rule) that imposes substantial direct requirement costs on state
and local governments, preempts state law, or otherwise has federalism
implications. This final rule will not have a substantial direct effect
on state or local governments, preempt state law, or otherwise have a
federalism implication. Therefore, the requirements of Executive Order
13132 are not applicable.
If regulations impose administrative costs, such as the time needed
to read and interpret this final rule, we should estimate the cost
associated with regulatory review. There are currently 288
organizations and 56 states and territories. We assume each
organization will have one designated staff member who will read the
entire rule.
Using the wage information from the BLS for medical and health
service managers (Code 11-9111), we estimate that the cost of reviewing
this rule is $139.14 per hour, including overhead and fringe benefits
(https://www.bls.gov/oes/current/naics5_524114.htm). Assuming an
average reading speed, we estimate that it would take approximately 6
hours for each person to review this final rule. For each payer that
reviews the rule, the estimated cost is $834.84 (6 hours x $139.14).
Therefore, we estimate that the total cost of reviewing this regulation
is $288,020 ($834.84 x 345 reviewers).
1. Requirements for Patient Access Through APIs
To promote our commitment to interoperability, we are implementing
new requirements in section III. of this final rule for MA
organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60,
Medicaid managed care at 42 CFR 438.242, CHIP FFS at 42 CFR 457.730,
CHIP managed care at 42 CFR 457.1233, and QHP issuers on the FFEs,
excluding QHP issuers offering only SADPs or only FF-SHOP plans, at 45
CFR 156.221 to implement standards-based APIs for making certain data
available to current enrollees. The Patient Access API will permit
third-party applications to retrieve data concerning adjudicated
claims, encounters with capitated providers, provider remittances,
patient cost-sharing, a subset of clinical data including lab test
results, if maintained by the payer, and, preferred drug lists, and for
MA-PD plans only, formulary data that includes covered Part D drugs,
and any tiered formulary structure or utilization management procedure,
which pertains to those drugs for MA-PD plans.
At 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for state
Medicaid agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care
plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR
457.1233(d)(3) for CHIP managed care entities, we are finalizing the
Provider Directory API. We believe that these policies are designed to
empower patients by requiring that impacted payers take steps--by
implementing the two required APIs--to enable enrollees to have access
to their data in a usable digital format and have (potentially) easier
means to share that data. By making these data readily available and
portable to the patient, these initiatives may help patients have the
ability to move from payer to payer, provider to provider, and have
both their clinical and administrative information travel with them
throughout their health care journey. Payers are in a unique position
to provide enrollees with a comprehensive picture of their claims and
encounter data, allowing patients to piece together their own
information that might otherwise be lost in disparate systems. This
information can contribute to better informed decision making, helping
to inform the patient's choice of coverage options and care providers
to more effectively manage their own health, care, and costs. By
encouraging them to take charge of and better manage their health and
having access to their health information, patients will have the
ability to share this information with their other providers, which may
reduce duplication of services, add efficiency to provider visits, and
facilitate identification of fraud, waste, and abuse.
To estimate the number of impacted payers, we reviewed parent
organizations of health plans across MA organizations, Medicaid MCOs,
and QHP issuers on the FFEs to remove organizations that would not be
subject to the policy, such as issuers that offer only SADPs;
transportation plans, and brokers such as non-emergency medical
transportation (NEMTs) brokers; PACE; visiting nurse and home health
care organizations; senior organizations such as Area Agencies on
Aging; and other organizations such as community action programs. After
removing these organizations, we then reviewed the remaining names of
parent organizations and health plans in the National Association of
Insurance Commissioners (NAIC) Consumer Information Support (CIS)
system to determine the legal name of the entity and whether the entity
was registered with the NAIC. We also used the 2018 NAIC Listing of
Companies to determine whether various health plans had associated
parent organizations using the NAIC's Group coding and numbering
system. If the health plan or parent organization did not appear in the
NAIC CIS or in the 2018 NAIC Listing of Companies, we then reviewed the
name of the entity in the Securities and Exchange online Edgar system
to locate the entity's Form 10-K filing, which includes an Exhibit
(Exhibit 21) that requires the entity to list its subsidiaries. If the
health plan or organization did not appear in these online systems or
listings, an online internet search using Google search
[[Page 25623]]
engine was conducted. After review, we have determined that 288 issuers
and 56 states, territories, and U.S. commonwealths, which operate FFS
programs, will be subject to the API provisions for Medicare, Medicaid,
and QHP issuers on the FFEs. To this we add the one state that operates
its CHIP and Medicaid separately. Thus, we have a total of 345 parent
organizations (288+56+1). We note that although 42 states have some
lower-income children in an expansion of Medicaid, and some higher-
income children or pregnant women in a separate CHIP, all but one of
these programs are operated out of the same agency. Although the CHIP
programs may be distinct, we believe they will use the same
infrastructure built for Medicaid. Thus, the addition of 1 parent
organization for CHIP is reasonable and plausible.
As noted in section XII.C.3. of this final rule, to implement the
Patient Access API together with the payer-to-payer data exchange
policies to facilitate a payer maintaining a cumulative health record
for their current enrollees, we estimated that organizations and states
would conduct three major work phases: Initial design; development and
testing; and long-term support of the APIs, including increased data
storage, such as additional servers, or cloud storage to store patient
health information and maintain it, and allocation of resources to
maintain the FHIR server, and perform capability and security testing.
(For a detailed description of these phases, see section XII.C.3. of
this final rule.)
As part of our research into the regulatory impact, we reviewed a
sample of health plan organizations offering MA plans to determine
whether any currently offer patient portal functionality with the MA
plan. If yes, we reviewed whether they offered the opportunity to
connect to Medicare's Blue Button 2.0. Health plan organizations
offering MA plans were identified from June 2018 data and statistics
compiled at https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/MCRAdvPartDEnrolData/index.html. We
initially reviewed the functionality offered by three organizations,
which together enroll over half of MA members through review of
publicly-available information such as press releases and website
informational materials. We found from this review that these
organizations not only offered patient portals primarily focused on
claims and user-entered data on their website, but that all three also
offered enrollees the opportunity to connect to Blue Button. We then
identified a selection of other health plan organizations at random and
conducted the same evaluation. Results indicate that the majority of
the health plan organizations we reviewed offer patients a way to
access claims data and other information via their websites and
sometimes via applications.
We also cross-referenced health plan organizations offering MA
plans with health plan organizations that offer plans in the Federal
Employees Health Benefits (FEHB) Program because a percentage of those
organizations offer plans with patient portal access and Blue Button
functionality. The FEHB Program, administered by the Office of
Personnel Management (OPM), reported in 2014 that 90 percent of its
participating plans offered enrollees access to a personal health
record on the organization's website. In addition, OPM reported that
over half of the FEHB participating plans expected to offer Blue Button
functionality by January 1, 2016. We sought to learn whether there was
any overlap between these two lists of organizations to gauge whether
additional organizations may already have the capability to offer
either patient portals or Blue Button, albeit in a different business
arm, as having internal capability may assuage some of the cost of
building out a new API to support patient access to claims data. While
we found significant overlap between UnitedHealthcare and the Blue
Cross Blue Shield Affiliates, we also were able to identify other
organizations that offer both MA plans and plans included in the FEHB.
While not definitive, this data allows us to draw the conclusion that a
number of health plan organizations have the technology in place to
offer patient portals to MA enrollees and, further, also have the
ability to offer MA enrollees Blue Button functionality.
As detailed in section XII. of this final rule and summarized in
Table 5, given the current state of interoperability, we estimate the
burden related to the new requirements for APIs to have an initial set
one-time costs of $788,414 per implementation or an aggregate cost of
$272 million ($788,414 x 345 parent organizations) minimum estimate; an
initial one-time cost of $1,576,829 per organization or state or an
aggregate cost of $544 million ($1,576,829 x 345 parent organizations)
primary estimate; and, an initial one-time cost of $2,365,243 per
organization or organization or an aggregate $816 million ($2,365,243 x
345 parent organizations) high estimate. For a detailed discussion of
the one-time costs associated with implementing the API requirements we
refer readers to section XII.C.3. of this final rule. Once the API is
established, we believe that there will be an annual cost for
performing necessary capability and security testing, performing
necessary upgrades, vetting of third-party applications, and
maintaining patient health information. We estimate the burden related
to the requirements for APIs to have an annual cost of $157,657 per
implementation or an aggregate cost of $54 million (345 parent
organizations x $157,657). For a detailed discussion of the annual
costs associated with implementing the API requirements, we refer
readers to section XII.C.3. of this final rule.
We are committed to fulfilling our role in promoting
interoperability, putting patients first and ensuring they have access
to their health care data. We recognize that there are significant
opportunities to modernize access to patient data and its ability to
share across the health ecosystem. We realize the importance of
interoperability and the capability for health information systems and
software applications to communicate, exchange, and interpret data in a
usable and readable format. Although allowing access to health care
data through pdf and text format is vital, it limits the utility of the
data, and its ability to be easily accessed and shared. Additionally,
we realize that moving to a system in which patients have access to
their health care data will ultimately empower them to make informed
decisions about their health care. Our policies here do not go as far
as our goals for how patients will be ultimately empowered, but take
steps in that direction.
We note that the federal government has spent over $35 billion
under the EHR Incentive Programs \82\ to incentivize the adoption of
EHR systems; however, despite the fact that 78 percent of physicians
and 96 percent of hospitals now use an EHR system,\83\ progress on
system-wide data sharing has been limited. Previous attempts to advance
interoperability have made incremental progress but have failed to
align the necessary stakeholders to drive momentum in a single
direction. In 2018, the Administration launched the
[[Page 25624]]
MyHealthEData initiative.\84\ This government-wide initiative aims to
empower patients by ensuring that they have access to their own health
care data and the ability to decide how their data will be used, while
keeping that information safe and secure. MyHealthEData aims to break
down the barriers that prevent patients from gaining electronic access
to their health care data and allow them to access that data from the
device or application of their choice that will connect to a plan's
API, empowering patients and taking a critical step toward
interoperability and patient data exchange.
---------------------------------------------------------------------------
\82\ Centers for Medicare and Medicaid Services. (2018, May).
EHR Incentive Program, Payment Summary Report. Retrieved from
https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/May2018_SummaryReport.pdf.
\83\ Office of the National Coordinator. (2015). Health IT
Dashboard--Office-based Physician Health IT Adoption: State rates of
physician EHR adoption, health information exchange &
interoperability, and patient engagement. Retrieved from https://dashboard.healthit.gov/apps/physician-health-it-adoption.php.
\84\ Centers for Medicare and Medicaid Services. (2018, May 6).
Trump Administration Announces MyHealthEData Initiative to Put
Patients at the Center of the US Healthcare System. Retrieved from
https://www.cms.gov/Newsroom/MediaReleaseDatabase/Press-releases/2018-Press-releases-items/2018-03-06.html.
---------------------------------------------------------------------------
Payers should have the ability to exchange data instantly with
other payers for care coordination or transitions, and with providers
to facilitate more efficient care. Payers are in a unique position to
provide enrollees a complete picture of their claims and encounter
data, allowing patients to piece together their own information that
might otherwise be lost in disparate systems. We are committed to
solving the issue of interoperability and achieving complete patient
access in the U.S. health care system and are taking an active approach
using all available policy levers and authorities available to move all
participants in the health care market toward interoperability and the
secure exchange of health care data. The modern internet app economy
thrives on a standards-based API software environment. Part of the
health care API evolution is incorporating many of the current
protocols from leading standards development organizations with the
newer FHIR web developer-friendly way of representing clinical data.
2. Increasing the Frequency of Federal-State Data Exchanges for Dually
Eligible Individuals
We routinely exchange data with states on who is enrolled in
Medicare, and which parties are liable for paying that beneficiary's
Part A and B premiums. These buy-in data exchanges support state, CMS,
and SSA premium accounting, collections, and enrollment functions. CMS
subregulatory guidance, specifically Chapter 3 of the State Buy-in
Manual, specifies that states should exchange buy-in data with CMS at
least monthly, but provides the option for states to exchange buy-in
data with CMS daily or weekly. Likewise, states can choose to receive
the CMS response data on a file daily or monthly.
We are establishing the frequency requirements in the regulation
itself to require all states to participate in daily exchange of buy-in
data to CMS, with ``daily'' meaning every business day, but that if no
new transactions are available to transmit, data would not need to be
submitted on a given business day. States will be required to begin
participating in daily exchange of buy-in data with CMS by April 1,
2022.
To estimate impact, we first note that there are a total of 51
entities, consisting of the 50 states and the District of Columbia that
can be affected by buy-in. Currently, 25 entities (24 states and the
District of Columbia) now submit buy-in data files to CMS daily and 32
entities (31 states and the District of Columbia) receive buy-in data
files from CMS daily. Consequently, we expect a one-time burden for 26
states (51 total entities minus 25 entities currently submitting daily
buy-in data) to comply with the daily buy-in data submissions, and a
similar one-time burden for 19 states (51 total entities minus 32
entities currently receiving buy-in data) to comply with the receipt of
daily buy-in data.
These numbers changed from those in the CMS Interoperability and
Patient Access proposed rule to reflect the most current data available
to CMS as of July 1, 2019. Between July 1 and publication of the final
rule it is likely that the numbers may change more. However, as can be
seen from Table 5, this aspect of the rule has minor impact (only a few
million dollars) compared with the overall impact of the rule (several
hundred million). Consequently, we are using these July 1 numbers in
the final rule.
We estimate that each required change, whether to submit buy-in
data or receive buy-in data, would take 6 months of work (approximately
960 hours) by a programmer working at an hourly rate of $90.02 per
hour. Since there are 45 required changes (19 states that need to
comply with receiving data plus 26 states that need to comply with
submitting data) we estimate an aggregate burden of $3,888,864 (45
changes * 960 hours of programming work * $90.02/hour).
The cost per state per change is approximately $85,000 (960 *
$90.02 = $86,419 exactly) and the costs for both changes (to both send
and receive buy-in data daily would be approximately $170,000 (2 *
$85,000).
We did not estimate any savings related to exchanging buy-in data
with greater frequency, as data lags only delay when states are billed
for premium costs; delays do not impact the applicability date and
total costs. While we did not estimate premium savings (since premium
collection is ultimately correct), we anticipate that states may
experience longer term reduction in administrative burden of making
those corrections.
As noted in section XII.C. of this final rule, we are updating the
frequency requirements in 42 CFR 423.910(d) to require that starting
April 1, 2022, all states submit the required MMA file data to CMS
daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily
would mean every business day, but that if no new transactions are
available to transmit, data would not need to be submitted on a given
business day. As noted in section XII.C. of this final rule, the
estimated burden across impacted states is $3,111,091.
Thus, the total burden to comply with increased frequency of
submission of MMA files and increased frequency of submission and
receipt of daily buy-in data files is $7 million ($3,888,864 total cost
for the buy-in provision plus $3,111,091 total cost for the MMA file
requirements).
We estimate a 25-month implementation period for these system
updates, from March 2020 to and including March 2022. In the CMS
Interoperability and Patient Access proposed rule, we assumed a 3-year
implementation period reflecting a May 1st start date and an April 1,
2022 applicability date. The revised 25-month implementation period
reflects an expected publication of this final rule in March 2020, with
implementation beginning March 2020, and with the applicability date of
April 1, 2022 unchanged. Although the implementation period is shorter
(25 months versus 36 months) the purpose of the 25-month window is to
give organizations flexibility in finding a 6-month period to perform
updates as indicated in section XII. of this final rule. Although the
flexibility window for this 6-month period is shortened (plans have
less choice of which 6 months to work in), data are lacking with which
to refine the cost estimates to reflect the shortened compliance
period.
States will have the ability to choose, in consultation with CMS,
when in the 25-month implementation period they want to make this
change, with numerous factors impacting in which year they would do so.
For the purposes of this impact analysis, we estimated a uniform
distribution beginning in March 2020 and ending in April 2022 as
calculated in Table 5.
[[Page 25625]]
Therefore, since, as noted above, the total cost impact over 25
months is $7 million, when apportioned uniformly over the 25 months,
the resulting impacts $2.8, $3.4, and $0.8 million for 2020, 2021, and
2022 respectively corresponding to 10 months, 12 months, and 3 months
in 2020, 2021 and 2022 respectively. These calculations are
transparently presented in Table 5.
3. Revisions to the Conditions of Participation for Hospitals and
Critical Access Hospitals (CAHs)
We are expanding CMS' requirements for interoperability within the
hospital and CAH CoPs by focusing on electronic patient event
notifications. We are implementing new requirements in section X. of
this final rule for hospitals at 42 CFR 482.24(d), for psychiatric
hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638(d).
Specifically, for hospitals, psychiatric hospitals, and CAHs, we are
finalizing similar requirements to revise the CoPs for Medicare- and
Medicaid-participating hospitals, psychiatric hospitals, and CAHs by
adding a new standard, ``Electronic Notifications,'' that will require
hospitals, psychiatric hospitals, and CAHs to make electronic patient
event notifications available to applicable post-acute care services
providers and suppliers, and to community practitioners, such as the
patient's established primary care practitioner, established primary
care practice group or entity, or other practitioner or practice group
or entity identified by the patient as primarily responsible for his or
her care. We are limiting this requirement to only those hospitals,
psychiatric hospitals, and CAHs that utilize electronic medical records
systems, or other electronic administrative systems, which are
conformant with the content exchange standard at 45 CFR 170.205(d)(2),
recognizing that not all Medicare- and Medicaid-participating hospitals
have been eligible for past programs promoting adoption of EHR systems.
If the hospital's (or CAH's) system conforms to the content exchange
standard at 45 CFR 170.205(d)(2), the hospital (or CAH) must then
demonstrate that its system's notification capacity is fully
operational and that it operates in accordance with all state and
federal statutes and regulations regarding the exchange of patient
health information, and that its system, to the extent permissible
under applicable federal and state law and regulations, and not
inconsistent with the patient's expressed privacy preferences, sends
the notifications either directly, or through an intermediary that
facilitates exchange of health information. It must also demonstrate
that the notifications include at least patient name, treating
practitioner name, and sending institution name.
Upon the patient's registration in the emergency department or
admission to inpatient services, and also either immediately prior to,
or at the time of, the patient's discharge or transfer (from the
emergency department or inpatient services), the hospital (or CAH) must
also demonstrate that it has made a reasonable effort to ensure that
its system sends the notifications to all applicable post-acute care
services providers and suppliers, as well as to any of the following
practitioners and entities, which need to receive notification of the
patient's status for treatment, care coordination, or quality
improvement purposes: (1) The patient's established primary care
practitioner; (2) the patient's established primary care practice group
or entity; or (3) other practitioner, or other practice group or
entity, identified by the patient as the practitioner, or practice
group or entity, primarily responsible for his or her care.
As we noted, infrastructure supporting the exchange of electronic
health information across settings has matured substantially in recent
years. Research studies have increasingly found that health information
exchange interventions can effectuate positive outcomes in health care
quality and public health outcomes, in addition to more longstanding
findings around reductions in utilization and costs. Electronic patient
event notifications from hospitals, or clinical event notifications,
are one type of health information exchange intervention that has been
increasingly recognized as an effective and scalable tool for improving
care coordination across settings, especially for patients at
discharge. This approach has been identified with a reduction in
readmissions following implementation.\85\
---------------------------------------------------------------------------
\85\ Unruh, M. A., Jung, H., Kaushal, R., & Vest, J. R. (2017).
Hospitalization event notifications and reductions in readmissions
of Medicare fee-for-service beneficiaries in the Bronx, New York.
Journal of the American Medical Informatics Association, 24(e1),
e150-e156. doi: 10.1093/jamia/ocw139.
---------------------------------------------------------------------------
In addition, the CMS Innovation Center has been partnering with
states through the State Innovation Models Initiative to advance multi-
payer health care payment and delivery system reform models. Through
this initiative 34 states have been awarded over $900 million to
implement their respective State Health Care Innovation Plans, many of
which included enhancements in HIT and HIE. While these models are
ongoing, evaluation reports thus far are reporting that many states are
experiencing favorable outcomes on ED visit rates and other quality
measures.\86\ Although patient event notifications are only a small
piece of these models, we want to continue the momentum towards
nationwide adoption.
---------------------------------------------------------------------------
\86\ Centers for Medicare and Medicaid Services. (2019, December
6). State Innovation Models Initiative: General Information.
Retrieved from https://innovation.cms.gov/initiatives/State-Innovations/.
---------------------------------------------------------------------------
These notifications are automated, electronic communications from
the provider to applicable post-acute care services providers and
suppliers, and also to community practitioners identified by the
patient. These automated communications alert the receiving provider or
practitioner that the patient has received care at a different setting.
Information included with these notifications can range from simply
conveying the patient's name, basic demographic information, and the
sending institution, to a richer set of clinical data depending upon
the level of technical implementation. Even with a minimum set of
information included, these notifications can help ensure that a
receiving provider or community practitioner is aware that the patient
has received care elsewhere. The notification triggers a receiving
provider or practitioner to reach out to the patient to deliver
appropriate follow-up care in a timely manner. By providing timely
notifications, the alert may improve post-discharge transitions and
reduce the likelihood of complications resulting from inadequate
follow-up care.
We believe that care coordination can have a significant positive
impact on the quality of life, consumer experience, and health outcomes
for patients. As we have noted in the preamble to this rule, virtually
all EHR systems (as well as older legacy electronic administrative
systems, such as electronic patient registrations systems, and which we
are including in this final rule) generate the basic messages commonly
used to support electronic patient event notifications. In addition,
while we acknowledge that some level of implementation cost would be
realized for those providers not already sending notifications, we also
note there is also substantial agreement that implementation of these
basic messaging and notification functions within such existing systems
constitutes a relatively low cost burden for providers, particularly
when such costs are considered alongside the innovative and beneficial
patient care transition
[[Page 25626]]
solutions and models for best practices they provide.
As detailed in section XI., we estimate that the total cost imposed
on hospitals, psychiatric hospitals, and CAHs by these provisions to be
approximately $5,179,863 in the first year and $1,042,426 in subsequent
years.
4. Effects of Other Policy Changes
In addition to those policy changes discussed previously that we
are able to model, we are finalizing various other changes in this
final rule. Generally, we have limited or no specific data available
with which to estimate the impacts of the policy changes. Our estimates
of the likely impacts associated with these other changes are discussed
in this section.
a. Care Coordination Across Payers
The majority of the 64 million people on Medicare are covered by
FFS, however, about 34 percent are covered in MA plans. Since 2003, the
number of beneficiaries enrolled in MA plans has increased fivefold
from 4.6 million in 2010 to 22 million in 2019.\87\ Given the growth in
MA enrollment and the ability for MA beneficiaries to change plans, we
believe it is important to supporting efficient care coordination by
requiring the sharing of key patient health information when an
enrollee requests it. Therefore, we are requiring MA organizations,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs to maintain a process for the electronic exchange
of, at a minimum, the data classes and elements included in the content
standard finalized by HHS in the ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register) at 45 CFR
170.213 (currently version 1 of the USCDI), via a payer-to-payer data
exchanged as outlined in this section V. of this final rule.
Furthermore, we are finalizing as proposed a regulatory requirement at
42 CFR 422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1)
to require MA organizations, Medicaid managed care plans, CHIP managed
care entities, and QHP issuers on the FFEs to incorporate the data they
receive into the payer's record about the enrollee. We are also
finalizing that with the approval and at the direction of an enrollee,
a payer must send the defined information set to any other payer. We
specify that a payer is only obligated to send data received from
another payer under this policy in the electronic form and format it
was received. However, we have noted that such transactions will need
to be made in compliance with any other applicable laws.
---------------------------------------------------------------------------
\87\ Medicare Payment Advisory Commission. (2019, July 19). A
Data Book: Health Care Spending and the Medicare Program--June 2019.
Retrieved from http://www.medpac.gov/docs/default-source/data-book/jun19_databook_entirereport_sec.pdf?sfvrsn=0.
---------------------------------------------------------------------------
We believe that sending and receiving these data will help both
plan enrollees and health care providers in coordinating care and
reducing administrative burden. We believe that this entails utilizing
all tools available to us to ensure that plans provide coordinated
high-quality care in an efficient and cost-effective way that protects
program integrity. Leveraging interoperability to facilitate care
coordination among plans can, with thoughtful execution, significantly
reduce unnecessary care, as well as ensure that health care providers
are able to spend their time providing care rather than performing
unnecessary administrative tasks. For instance, effective information
exchange between plans could improve care coordination by reducing the
need for health care providers to write unneeded letters of medical
necessity; by reducing instances of inappropriate step therapy; and by
reducing repeated utilization reviews, risk screenings, and
assessments.
We believe that this policy will impose minimal additional costs on
plans. We note that we are not specifying a transport standard and
anticipate that plans may opt to use APIs, such as the Patient Access
API that this final rule also requires. We also anticipate that plans
may choose to utilize a regional health information exchange. We
believe it is difficult to quantify the impact of this change because
plans will likely implement different transport methods, and we cannot
predict the selected method plans will choose.
b. Care Coordination Through Trusted Exchange Networks
In section VI. of the CMS Interoperability and Patient Access
proposed rule, we proposed requiring MA organization, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs to
participate in trust networks in order to improve interoperability. We
also listed the requirements for participation in a trusted exchange
network.
As a result of comments and re-examination of our desired policies,
we have decided not to finalize this provision. However, as pointed out
in the proposed rule, had this provision been finalized, it would
impose minimal additional costs on plans. Consequently, not finalizing
this policy does not impact this RIA.
5. Non-Mandatory Effects and Regulatory Interaction
We note in this RIA when we had difficulty quantifying costs due to
lack of applicable research or data. More specifically, the
establishment of a health care information ecosystem could only be
achieved with new actions that are conducted widely throughout the
health care field--including by entities, especially non-hospital
providers, for whom costs have not been estimated in either this RIA or
the RIA for the accompanying ONC 21st Century Cures Act final rule
(published elsewhere in this issue of the Federal Register). Although
data limitations have prevented the quantification of these costs, the
benefits of the two rules--some of which have been quantified in the
ONC RIA--and the rules' potential transfer impacts--including
reductions in fraudulent payments, as discussed by Parente et al.
(2008) \88\--are largely contingent upon such costs being incurred.
Additionally, there are ongoing regulatory and policy activities
outside of this final rule that might influence the rule's impact in an
unquantifiable manner. When possible, we acknowledge these complexities
as well.
---------------------------------------------------------------------------
\88\ Parente, Stephen T., Karen Mandelbaum, Susan P. Hanson,
Bonnie S. Cassidy and Donald W. Simborg. ``Crime and Punishment: Can
the NHIN Reduce the Cost of Healthcare Fraud?'' Journal of
Healthcare Information Management 22(3): 42-51. June 2008.
---------------------------------------------------------------------------
D. Alternatives Considered
In March 2018, the White House Office of American Innovation and
the CMS Administrator announced the launch of MyHealthEData, and CMS's
direct, hands-on role in improving patient access and advancing
interoperability. As part of the MyHealthEData initiative, we are
taking a patient-centered approach to health information access and
moving to a system in which patients have immediate access to their
electronic health information and can be assured that their health
information will follow them as they move throughout the health care
system from provider to provider, payer to payer. This final rule
contains a range of policies. It provides descriptions of the statutory
provisions that are addressed, identifies the policies, and presents
rationales for our decisions and, where relevant, alternatives that
were considered. We carefully considered alternatives to the policies
we are adopting in this final rule but concluded that none of the
[[Page 25627]]
alternatives would adequately and immediately begin to address the
critical issues of the lack of patient access and interoperability, or
the difficulty exchanging health care data within the health care
system.
As we noted in the CMS Interoperability and Patient Access proposed
rule, we believe the following three attributes of standards-based APIs
are particularly important to achieving the goal of offering
individuals convenient access, through applications they choose, to
available and relevant electronic health and health-related
information: the API technologies themselves, not just the data
accessible through them, are standardized; the APIs are technically
transparent; and the APIs are implemented in a pro-competitive manner
(84 FR 7620). The API requirements proposed and finalized in this rule
were developed to ensure these goals are met.
Some of the reasons that we selected the FHIR standard were due to
the flexibility it provides and the wide industry adoption that it
offers. The open and extensible nature of FHIR allows for health care
integration to be transparent and accessible. FHIR is open source, and
as such, it has garnered a community that includes developers and
vendors. For example, large consumer brands are becoming a driving
force behind the adoption of FHIR. Apple is implementing FHIR in Apple
Health as part of iOS 11.3, and serves as a member of the Argonaut
Project and CARIN Alliance--two HL7 FHIR Accelerators; \89\ Google
supports FHIR by partnering with HL7, as well as through its membership
in the CARIN Alliance; and Microsoft published an Azure API for FHIR to
create and deploy FHIR service health data solutions.\90\ Furthermore,
according to an ONC report, nearly 51 percent of health IT developers
appear to be using a version of FHIR combined with OAuth 2.0 to respond
to requests for patient data. Additionally, of the hospitals and Merit-
based Incentive Payment System (MIPS) eligible clinicians that use
certified products, almost 87 percent of hospitals and 69 percent of
MIPS eligible clinicians are served by health IT developers with
product(s) certified to any FHIR version.\91\
---------------------------------------------------------------------------
\89\ The HL7 FHIR Accelerator Program is designed to assist
communities and collaborative groups across the global health care
spectrum in the creation and adoption of high quality FHIR
Implementation Guides or other standard artifacts to move toward the
realization of global health data interoperability. For further
details, see https://www.hl7.org/about/fhir-accelerator/.
\90\ Shrestha, R., Mohan, S., & Grieve, G. (2018, February 14).
State of the Healthcare API Economy (An Innovation Forum Session:
Session 217). Retrieved from https://365.himss.org/sites/himss365/files/365/handouts/552739129/handout-219_FINAL.pdf. See also https://azure.microsoft.com/en-us/services/azure-api-for-fhir/ and https://www.apple.com/healthcare/health-records/.
\91\ Posnack, S. & Baker, W. (2018, October 1). Heat Wave: The
U.S. is Poised to Catch FHIR in 2019. Retrieved from https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019.
---------------------------------------------------------------------------
For additional ways to allow consumers access to their health data,
we note that we did receive comments that CMS could consider allowing
payers and providers to upload patient data directly to a patient
portal that is owned and managed by the patient. One option would allow
for HIEs and HINs to serve as a central source for patients to obtain
aggregated data in a single location. While HIEs and HINs can provide
patients with valuable information via a portal, research has indicated
that portals have not gained widespread use by patients. According to
ONC, as of 2017, 52 percent of individuals have been offered online
access to their medical records by a health provider or payer. Of the
52 percent that were offered access, only half of those viewed their
record.\92\ Additionally, we believe that there would be additional
burden associated with using portals because providers and patients
would need to access multiple portals and websites to access patient
data, instead of a single app. Unlike portals that would require
developers to link systems or ensure system-level compatibility, FHIR-
based APIs have the ability to make data available without the need to
link multiple systems or portals and would provide a patient a single-
point of access to their data. Having APIs that can be accessed by
third-party apps permits the patient to choose how they want to access
their data, and it promotes innovation in industry to find ways to best
help patients interact with their data in a way that is most meaningful
and helpful to them. Additionally, we believe it would be very
difficult to evaluate the cost impacts of making individual portals
available via an HIE or HIN because business models and process are
varied, and there is a lack of standardization in the way the
information is stored and transmitted across HIEs and HINs.
---------------------------------------------------------------------------
\92\ Patel, V. & Johnson, C. (2018, April). Individuals' Use of
Online Medical Records and Technology for Health Needs (ONC Data
Brief No. 40). Retrieved from https://www.healthit.gov/sites/default/files/page/2018-03/HINTS-2017-Consumer-Data-Brief-3.21.18.pdf.
---------------------------------------------------------------------------
Other alternatives that we considered were how broadly or narrowly
to apply the policies and requirements. For example, we could have
required health plans to provide more data elements via a standards-
based API then just data for adjudicated claims, encounters with
capitated providers, provider remittances, beneficiary cost-sharing,
clinical data including laboratory results, provider directories (and
pharmacy directories for MA-PDs), and preferred drug lists, where
applicable. In the CMS Interoperability proposed rule, we originally
required MA organizations, state Medicaid FFS programs, Medicaid
managed care plans, CHIP FFS programs, and CHIP managed care entities
to make available provider directory data through the Patient Access
API (84 FR 7633) and publicly available to current and prospective
enrollees (84 FR 7639). After consideration of public comments, we have
removed the requirements that these impacted payers make provider
directory information available through the Patient Access API. MA
organizations, state Medicaid FFS programs, Medicaid managed care
plans, CHIP FFS programs, and CHIP managed care entities will only need
to make provider directory information available via a publicly
accessible Provider Directory API. We note the Provider Directory API
does not need to conform to the security protocols finalized by HHS at
45 CFR 170.215(a)(3) and (b) that are specific to authenticating users
and confirming individuals' authorization or request to disclose their
personal information to a specific application through an API, namely
the SMART IG (using the OAuth 2.0 standard) and OpenID Connect Core
1.0. By only requiring the Provider Directory API make these otherwise
publicly accessible data available, we are seeking to avoid duplicative
effort and additional burden.
Additionally, several commenters suggested additional information
be added to the requirement for provider directory information to be
available through an API, such as NPIs for individual and group
providers, practice group name, health system name, as well as the
specific plan(s) and tiers a provider participates in ``provider
demographics;'' whether the provider is accepting new patients; and
information about which providers are in-network for a plan by
geography and/or specialty. While we agreed with commenters that this
information would be helpful to patients, we did not modify the
proposed requirements for the information that is required to be made
available by the Provider Directory API because we believe additional
data would be a cost driver. By not adding additional required
[[Page 25628]]
information we are seeking to minimize the burden for the regulated
payers that must comply with this policy. Instead we are identifying a
minimum set of provider directory information that aligns with existing
requirements applicable to MA organizations (including MA organizations
that offer MA-PD plans), state Medicaid and CHIP FFS programs, Medicaid
managed care plans, and CHIP managed care entities that beneficiaries
can currently access.
We also looked at policy alternatives related to specific aspects
of the API requirements. For instance, we considered whether to modify
the requirement to make claims and encounter data, as well as clinical
data, available through the Patient Access API no later than one (1)
business day after a payer receives it. We reviewed several suggested
alternatives such as increasing the timeframe to three (3) or five (5)
business days to account for vendor-adjudicated claims. While we
considered these alternatives, we ultimately decided not to adjust the
proposed requirements because having access to this information within
one (1) business day could empower patients to have the information
they need, when they need it to inform care coordination. Patients have
a right to see the full lifecycle of their claims and encounter
information as soon as it is available, even if the payment amounts may
change due to appeal. Additionally, as we noted in section XII. of this
final rule, the burden related to API requirements is in the initial
implementation of the system to make this information available in one
(1) business day once received. This requirement is being implemented
in the design and build phase and the system update cost for electronic
availability would be the same regardless of the number of days the
system is set up to accommodate. There is also no data on whether
providing three (3) or five (5) days, versus one (1) day, will provide
patients with more complete or accurate data.
As an alternative, we considered requiring all QHP issuers on all
Exchanges to meet the new API requirements as part of QHP
certification. Consistent with some other QHP certification
requirements, we opted not to require SBEs to include this as part of
their certification requirements, but we strongly urge them to do so to
ensure equitable treatment of issuers nationally and to allow consumers
to access their health information through a third-party application no
matter where they are insured across the country. States are the most
knowledgeable about their consumers and insurance markets and are
responsible for issuer compliance activities. While we believe that
these API requirements have the potential to provide great benefit to
consumers, complying with them will be mainly operational and SBE
states would be required to assess QHP issuer compliance. Therefore, we
believe that SBE states should be given the flexibility to determine
whether or not these requirements are required of their QHP issuers.
An additional alternative that we considered was based off one
commenter's suggestion to incentivize plans who meet the required
implementation dates through higher Healthcare Effectiveness Data and
Information Set (HEDIS) scores. Although the commenter was not clear
regarding a specific recommendation as to how to implement changes to
the HEDIS score, we evaluated options such as adding a new measure
specific to data exchange using HL7 FHIR-based APIs between payers and
third-parties on the behalf of patients, or adding bonus points to the
total score or some appropriate measure set for implementing the FHIR-
based APIs required. However, after further evaluation, we believe that
this is not a viable alternative at this time. CMS cannot give a higher
HEDIS score for using a digital specification because it would not be
an accurate measure of plan performance. To consider adding a bonus to
the highest rating if the plan meets certain standards would
necessitate requiring a new adjustment to the star rating methodology.
This would be a significant change to how the current star ratings are
calculated and would have to be proposed through notice and comment
rulemaking. Given the implementation date for the API provisions for MA
organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP
FFS programs, and CHIP managed care entities is January 1, 2021, and
for QHP issuers on the FFEs beginning with plan years beginning on or
after January 1, 2021, implementing changes to the star ratings would
not be achievable within the available timeframe to incentivize
implementation as the commenter suggested.
As we recognize that advancing interoperability is no small or
simple matter, we continue to explore alternatives and potential future
policies. In the CMS Interoperability and Patient Access proposed rule,
we requested comment for consideration in future rulemaking or
subregulatory guidance on a number of alternatives related to whether
additional policies or requirements, beyond those proposed, should be
imposed to promote interoperability. For example, the CMS Innovation
Center sought comment on general principles around promoting
interoperability as part of the design and testing of innovative
payment and service delivery models. Additionally, we sought comment on
how we may leverage our program authority to provide support to those
working on improving patient matching. For example, we requested
comment on whether CMS should require impacted payers use a particular
patient matching software solution with a proven success rate of a
certain percentage validated by HHS or a third party. We also noted
that we will continue to consider feedback received from RFIs issued in
various rules over the course of the past 2 years and incorporate those
suggestions into our strategy. We thank commenters for their input on
these RFIs. We will consider the comments received for potential future
rulemaking.
E. Accounting Statement and Table
In accordance with OMB Circular A- 4, Table 14 depicts an
accounting statement summarizing the assessment of the benefits, costs,
and transfers associated with this regulatory action.
[[Page 25629]]
Table 14--Accounting Statement
----------------------------------------------------------------------------------------------------------------
Units
Primary -----------------------------------------------
Category estimate Discount rate Period
Year dollars (percent) covered
----------------------------------------------------------------------------------------------------------------
Benefits
----------------------------------------------------------------------------------------------------------------
Qualitative..................................... API requirements will alleviative the burden for
patients to go through separate processes to obtain access to
each system, and the need to manually aggregate information
that is delivered in various, often non-standardized, formats
(not necessarily additional to the benefits assessed in the
RIA for the accompanying ONC 21st Century Cures Act final
rule, (published elsewhere in this issue of the Federal
Register)).
API requirement allows for the administration of a
more efficient and effective Medicaid program by taking
advantage of commonly used methods of information sharing and
data standardization.
API requirements would help to create a health care
information ecosystem that allows and encourages the health
care market to tailor products and services to compete for
patients, thereby increasing quality, decreasing costs,
providing potential benefits (not necessarily additional to
the benefits assessed in the RIA for the accompanying ONC
final rule), and helping them live better, healthier lives.
Privacy and security policies are being implemented
that permit payers to request third-party apps to attest to
privacy and security provisions prior to providing the app
access to the payer's API.
----------------------------------------------------------------------------------------------------------------
Costs
----------------------------------------------------------------------------------------------------------------
Annualized Monetized $ millions/year (low 85.2 2019 7 2020-2029
estimate)...................................... 80.8 2019 3 2020-2029
Annualized Monetized $ millions/year (primary 122.0 2019 7 2020-2029
estimate)...................................... 112.4 2019 3 2020-2029
Annualized Monetized $ millions/year (high 158.8 2019 7 2020-2029
estimate)...................................... 144.0 2019 3 2020-2029
----------------------------------------------------------------------------------------------------------------
Non-Quantified Costs: Non-hospital provider costs associated with development of a broad health care information
ecosystem (regulatory benefits and fraud reduction are largely contingent upon these non-mandatory costs being
incurred).
----------------------------------------------------------------------------------------------------------------
Transfers from the Federal Government to Enrollees of Commercial Plans (PTC)
----------------------------------------------------------------------------------------------------------------
Annualized Monetized $ millions................. 5.4 2019 7 2020-2029
Annualized Monetized $ millions................. 5.5 2018 3 2020-2029
----------------------------------------------------------------------------------------------------------------
Non-Quantified Transfers: Reduced fraudulent payments to providers from the federal government and other payers.
----------------------------------------------------------------------------------------------------------------
The preceding discussion was an actual cost impact (not a transfer)
since goods and computer services are being paid for. Plans have the
option of transferring their expenses to enrollees. In practice,
because of market competitive forces a plan may decide to operate at a
(partial) loss and not transfer the entire cost. It is important to
estimate the maximum the transfer could be. Some costs are transferred
to the states (for Medicaid and CHIP) and ultimately to the federal
government (for Medicare, Medicaid, and CHIP, and potentially for QHP
issuers on the FFEs in the form of higher PTCs)), mitigating the amount
transferred to enrollees. One approach to estimate impact on enrollees
was made in section XII.B. of this RIA. However, this analysis did not
take into account transfers.
We now re-estimate the potential full transfer. As noted in Tables
5 through 10, we have in 2021 through 2029 under a dollar increase in
premiums as the worst-case scenario, and we used actual costs per year.
In this alternate analysis, we use actual amounts for each of 2021
through 2029 with the initial 1-year cost amortized over 9 years. In
other words, we assume an aggregate annual cost of $84.6 million ($272
million/9 + $54.4 million), this is based on the low estimate 1st year
cost of $272 million. If we use the high estimate cost $816 million we
obtain $145 million average ($816 million/9 + $54.4 million).
We note that this premium increase could be counterbalanced by
projected savings arising from the provisions in this final rule. More
specifically, we expect the availability of portable electronic
transfer of medical data proposed by this rule will help patients have
the ability to move from payer to payer, provider to provider, and have
both their clinical and administrative information travel with them
throughout their health care journey. Allowing patients to piece
together their own information that might otherwise be lost in
disparate systems could help make better informed patients and may lead
to increase prevention of future medical illnesses due to improvements
in care coordination due to better data accessibility. The savings from
avoiding one illness or one cheaper procedure would offset the under
one-dollar impact. However, we have no way, at this point, of
estimating this aspect of the future savings of the rule.
[[Page 25630]]
We present two estimates. First, we estimate using the enrollment
figures used in Table 9 of this RIA. Table 9 shows that we have 110.5
million enrollees (17.5+73+20) in programs that will be spending about
$84.6 million per year. Ignoring federal subsidies, and assuming that
all costs will be passed on to enrollees (which is contrary to our
experience), the 110.5 million enrollees would each incur an extra 77
cents per enrollee ($84.6 million/110.5 million) a year to achieve the
$84.6 million goal. This is the low estimate cost. The corresponding
high estimate cost would be $1.31 per enrollee per year ($145 million/
110.5 million). We next estimate using premium versus enrollment as was
done in section XII.B. of this RIA.
Prior to discussing potential transfers to enrollees, we discuss
how this final rule may affect patients not covered by plans subject to
this rule. It is both possible and likely that an organization offering
a plan subject to this rule may also offer plans not subject to this
rule, and comply with the requirements of this rule for all of its
plans, including those not subject to this rule. Consequently, it is
possible that to cover the cost of complying with this rule for plans
that are subject to this rule and plans that are not subject to this
rule, organizations may raise premiums for their plans that are subject
to this rule and their plans that are not subject to this rule. It is
possible (and we contend likely) that this final rule will affect
enrollees in individual market plans other than QHPs on the FFEs, even
though there is no requirement for such coverage to comply with this
rule. Therefore, we calculate the cost impact per enrollee should
organizations offering plans not subject to this rule choose to comply
with this rule with regard to those plans. The rest of the discussion
below explores this possibility.
QHP issuers on the FFEs: Rebates are required under section
2718(b)(1)(A) of the PHSA and the implementing regulations at 45 CFR
part 158 when an issuer does not meet the applicable threshold. The
commercial market MLR is generally calculated as the percent of each
dollar of after-tax premium revenue spent by the issuer on
reimbursement for clinical services, and activities that improve the
quality of health care. If the issuer's MLR for a state market is below
the applicable threshold, then the issuer must return the difference to
policyholders. It follows, that if costs of complying with this rule
raise plan costs, and if additionally, the issuers pass on the full
cost in the form of premium and/or are able to treat these costs as
QIAs, then premiums and rebates will change. The following two highly
simplified examples are illustrative.
Suppose the MLR threshold is 80 percent (in practice it can vary by
state market), but the issuer's MLR is below the threshold at 70
percent. Then, the issuer would have to return the 10 percent as a
rebate. If the costs of complying with this rule for an issuer are on
average 6 percent of premium and the issuer treats these expenses as
QIA, the issuer will now have to rebate only 4 percent instead of 10
percent (that is, the issuer's MLR would be 76 percent rather than 70
percent). Similarly, if both the applicable threshold and issuer MLR
are 80 percent, then the issuer would not owe a rebate.
There are two effects of recognizing these costs as QIA: (1) For
issuers subject to this rule who are below the applicable MLR
threshold, the rebate from issuers to policyholders would go down by
some amount between $0 and the cost of complying with this rule; and
(2) for issuers subject to this rule who are at or above the MLR
standards, the premium transfers from enrollees to issuers will go up
by some amount between $0 and the cost of complying with this rule. We
note that both MLR and rebates are calculated by combining all of an
issuer's business (on- and off-Exchange) within a state and market.
To estimate these amounts, we used the public use 2016 MLR files on
the CMS website that were used for Tables 6 through 9 of this RIA. The
total reported 2016 premium revenue on the commercial side for
individual market plans was approximately $77 billion (See Table 7). Of
the $77 billion, the total reported 2016 premium revenue of issuers
that were below the commercial MLR standard (80 or 85 percent,
depending on the market) was approximately $4 billion.
As mentioned earlier, to proceed further we use the estimates of
the costs of complying with this rule, which are $84.6 million per
year. This cost is for all parent organizations with each parent
organization possibly dealing with up to four lines of business subject
to MLR requirements and the requirements of this rule: MA (including
Part D sponsors); Medicaid; CHIP; and QHP issuers on the FFEs. Thus, of
the $84.6 million level annual cost of complying with this rule, we
estimate $18.8 million (22.19 percent commercial proportion * $84.6
million level annual cost complying with this rule) to be the cost for
individual market plans.
In estimating the transfers to policyholders in individual market
plans, we must distinguish between the $4 billion of premium revenues
of issuers whose MLR was below the applicable threshold and the $73
billion of premium revenues ($77 billion total revenue for individual
market plans- $4 billion) of individual market issuers whose MLR was at
or above the applicable threshold. We can now calculate the estimated
aggregate transfer in the commercial health insurance market from
individual market policyholders to issuers whether through premium or
rebates as follows:
Percentage cost of complying with this rule = 0.0244
percent of revenue premium ($18.8 million cost/$77 billion total
revenue).
Reduced MLR rebates = $1 million (0.0244 percent x $4
billion premium from issuers below the applicable MLR threshold).
Increased premiums = Up to $17.8 million (0.0244 percent x
($77 billion total revenue-$4 billion premium from issuers below the
applicable MLR threshold)).
Total transfer from enrollees = Up to $418.8 million
($17.8 million increased premium + $1 million reduced rebate).
Transfer per enrollee = $1.07 ($418.8 million/17.5 million
commercial health insurance enrollees).
We note that the $1.07 (under a dollar per enrollee) is consistent
with the results obtained in Tables 6 through 10 (with exact raw
amounts by year without amortization of a large first year expense).
These calculations are summarized in Table 15. The $1.07 is the low
estimate of first year costs. The high estimate $1.85 per enrollee per
year is obtained by replacing the low estimate cost of $272 million
with $816 million.
Table 15--Transfers to Enrollee Resulting From the Final Rule
----------------------------------------------------------------------------------------------------------------
Label Item Amount Source Comments
----------------------------------------------------------------------------------------------------------------
(A).................... First year cost of 272.0 Estimated in this In millions.
interoperability (Low proposed rule.
estimate).
[[Page 25631]]
(B).................... First year cost amortized 30.2 (A) / 9............. In millions.
over 9 years.
(C).................... Continuation year cost of 54.4 Estimated in this In millions.
interoperability. proposed rule.
(D).................... Level interoperability 84.6 (B) + (C)........... In millions.
cost per year.
----------------------------------------------------------------------------------------------------------------
Commercial Percent of Premium Revenues
----------------------------------------------------------------------------------------------------------------
(E).................... Total premium revenues in 347 Table 7............. In billions.
Individual market,
Medicaid and Medicare.
(F).................... Individual market plans 77 22.19%.............. Table 7.
premium revenues (dollar
amount and percent).
(G).................... Medicare Advantage 157 45.24%.............. Table 7.
premium revenues (Dollar
amount and percent).
(H).................... Medicaid premium revenues 113 32.56%.............. Table 7.
(Dollar amount and
percent).
----------------------------------------------------------------------------------------------------------------
Annual interoperability cost as a percent of commercial individual market health insurance premium revenues
----------------------------------------------------------------------------------------------------------------
(I).................... Annual Level 84.6 (D)................. In millions.
interoperability cost.
(J).................... Percent of total 22.19% (F).................
individual market plans
revenues.
(K).................... Interoperability cost for 18.8 (I) x (J)........... In millions.
individual market plans.
(L).................... Commercial premium 77,000 (E)................. 2016 data in millions.
revenues for individual
market plans.
(M).................... Interoperability cost as 0.0244% (K) / (L)...........
a percent of total
commercial revenue for
individual market plans.
----------------------------------------------------------------------------------------------------------------
Individual market plans revenue broken out by whether above or below MLR threshold (requiring rebate)
----------------------------------------------------------------------------------------------------------------
(N).................... Total individual market 77,000 (E)................. In millions.
plan revenue.
(O).................... Revenues of individual 4,037 2016 CMS MLR Data in In millions.
market health plans millions.
whose MLR is below
regulatory threshold.
(P).................... Revenues of individual 72,963 (N)-(O)............. In millions.
market plans whose MLR
is below regulatory
threshold.
----------------------------------------------------------------------------------------------------------------
Transfer to enrollee per enrollee from decreased rebates and increased premium
----------------------------------------------------------------------------------------------------------------
(Q).................... Reduction in rebates from 1.0 (N) x (O)........... In millions.
interoperability in
those plans paying
rebates.
(R).................... Premium increase from 17.8 (N) x (P)...........
interoperability in
those plans not paying
rebates.
(S).................... Total increase to 18.8 (Q) + (R)........... In millions.
commercial individual
market plans enrollees
from interoperability.
(T).................... Number commercial 17.5 From 2016 MLR files, In millions.
enrollees in individual in millions.
market plans.
(U).................... Dollar increase in $1.07 (S) / (T)...........
premium per enrollee
(Low estimate).
(V).................... Dollar increase in $1.46 Obtained by
premium per enrollee replacing 272
(Medium Estimate). million in row (A)
with $544 million.
(W).................... Dollar increase in $1.84 Obtained by
premium per enrollee replacing 272
(High Estimate). million in row (A)
with $816 million.
----------------------------------------------------------------------------------------------------------------
F. Regulatory Reform Analysis Under E.O. 13771
Executive Order 13771, titled Reducing Regulation and Controlling
Regulatory Costs, was issued on January 30, 2017 and requires that the
costs associated with significant new regulations ``shall, to the
extent permitted by law, be offset by the elimination of existing costs
associated with at least two prior regulations.'' This final rule is
considered an E.O. 13771 regulatory action. We estimate that this rule
generates $77.8 million in annualized costs, discounted at 7 percent
relative to year 2016, over an infinite time horizon estimate. Details
on the estimated costs of this final rule can be found in the preceding
analysis.
G. Conclusion
The analysis above, together with the preceding preamble, provides
an RIA.
In accordance with the provisions of Executive Order 12866, this
regulation was reviewed by the Office of Management and Budget.
List of Subjects
42 CFR Part 406
Health facilities, Diseases, Medicare.
42 CFR Part 407
Medicare.
42 CFR Part 422
Administrative practice and procedure, Health facilities, Health
maintenance organizations (HMO), Medicare, Penalties, Privacy,
Reporting and recordkeeping requirements.
42 CFR Part 423
Administrative practice and procedure, Emergency medical services,
Health facilities, Health maintenance organizations (HMO), Medicare,
Penalties, Privacy, Reporting and recordkeeping requirements.
[[Page 25632]]
42 CFR Part 431
Grant programs--health, Health facilities, Medicaid, Privacy,
Reporting and recordkeeping requirements.
42 CFR Part 438
Grant programs--health, Medicaid, Reporting and recordkeeping
requirements.
42 CFR Part 457
Administrative practice and procedure, Grant programs--health,
Health insurance, Reporting and recordkeeping requirements.
42 CFR Part 482
Grant programs--health, Hospitals, Medicaid, Medicare, Reporting
and recordkeeping requirements.
42 CFR Part 485
Grant programs--health, Health facilities, Medicaid, Privacy,
Reporting and recordkeeping requirements.
45 CFR Part 156
Administrative practice and procedure, Advertising, Advisory
committees, Brokers, Conflict of interests, Consumer protection, Grant
programs--health, Grants administration, Health care, Health insurance,
Health maintenance organization (HMO), Health records, Hospitals,
Indians, Individuals with disabilities, Loan programs--health,
Medicaid, Organization and functions (Government agencies), Public
assistance programs, Reporting and recordkeeping requirements, State
and local governments, Sunshine Act, Technical assistance, Women,
Youth.
For the reasons set forth in the preamble, the Centers for Medicare
& Medicaid Services (CMS) amends 42 CFR chapter IV and the Office of
the Secretary (HHS) amends 45 CFR subtitle A, subchapter B, as set
forth below:
TITLE 42--PUBLIC HEALTH
CHAPTER IV--CENTERS FOR MEDICARE & MEDICAID SERVICES, DEPARTMENT OF
HEALTH AND HUMAN SERVICES
PART 406--HOSPITAL INSURANCE ELIGIBLIITY AND ENTITLEMENT
0
1. The authority citation for part 406 is revised to read as follows:
Authority: 42 U.S.C 1302 and 1395hh.
0
2. Section 406.26 is amended by adding paragraph (a)(1)(i) and adding
and reserving paragraph (a)(1)(ii) to read as follows:
Sec. 406.26 Enrollment under State buy-in.
(a) * * *
(1) * * *
(i) Any State that has a buy-in agreement in effect must
participate in daily exchanges of enrollment data with CMS.
(ii) [Reserved]
* * * * *
PART 407--SUPPLEMENTARY MEDICAL INSURANCE (SMI) ENROLLMENT AND
ENTITLEMENT
0
3. The authority citation for part 407 is revised to read as follows:
Authority: 42 U.S.C 1302 and 1395hh.
0
4. Section 407.40 is amended by adding paragraph (c)(4) to read as
follows:
Sec. 407.40 Enrollment under a State buy-in agreement.
* * * * *
(c) * * *
(4) Any State that has a buy-in agreement in effect must
participate in daily exchanges of enrollment data with CMS.
PART 422--MEDICARE ADVANTAGE PROGRAM
0
5. The authority citation for part 422 continues to read as follows:
Authority: 42 U.S.C 1302 and 1395hh.
0
6. Section 422.119 is added to read as follows:
Sec. 422.119 Access to and exchange of health data and plan
information.
(a) Application Programming Interface to support MA enrollees. A
Medicare Advantage (MA) organization must implement and maintain a
standards-based Application Programming Interface (API) that permits
third-party applications to retrieve, with the approval and at the
direction of a current individual MA enrollee or the enrollee's
personal representative, data specified in paragraph (b) of this
section through the use of common technologies and without special
effort from the enrollee.
(b) Accessible content. (1) An MA organization must make the
following information accessible to its current enrollees or the
enrollee's personal representative through the API described in
paragraph (a) of this section:
(i) Data concerning adjudicated claims, including claims data for
payment decisions that may be appealed, were appealed, or are in the
process of appeal, and provider remittances and enrollee cost-sharing
pertaining to such claims, no later than one (1) business day after a
claim is processed;
(ii) Encounter data from capitated providers, no later than one (1)
business day after data concerning the encounter is received by the MA
organization; and
(iii) Clinical data, including laboratory results, if the MA
organization maintains any such data, no later than one (1) business
day after the data is received by the MA organization.
(2) In addition to the information specified in paragraph (b)(1) of
this section, an MA organization that offers an MA-PD plan must make
the following information accessible to its enrollees through the API
described in paragraph (a) of this section:
(i) Data concerning adjudicated claims for covered Part D drugs,
including remittances and enrollee cost-sharing, no later than one (1)
business day after a claim is adjudicated; and,
(ii) Formulary data that includes covered Part D drugs, and any
tiered formulary structure or utilization management procedure which
pertains to those drugs.
(c) Technical requirements. An MA organization implementing an API
under paragraph (a) of this section:
(1) Must implement, maintain, and use API technology conformant
with 45 CFR 170.215;
(2) Must conduct routine testing and monitoring, and update as
appropriate, to ensure the API functions properly, including
assessments to verify that the API is fully and successfully
implementing privacy and security features such as, but not limited to,
those required to comply with HIPAA privacy and security requirements
in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable
law protecting the privacy and security of individually identifiable
data;
(3) Must comply with the content and vocabulary standard
requirements in paragraphs (c)(3)(i) and (ii) of this section, as
applicable to the data type or data element, unless alternate standards
are required by other applicable law:
(i) Content and vocabulary standards at 45 CFR 170.213 where such
standards are applicable to the data type or element, as appropriate;
and
(ii) Content and vocabulary standards at 45 CFR part 162 and Sec.
423.160 of this chapter where required by law or where such standards
are applicable to the data type or element, as appropriate.
(4) May use an updated version of any standard or all standards
required under paragraph (c)(1) or (3) of this section, where:
(i) Use of the updated version of the standard is required by other
applicable law; or
[[Page 25633]]
(ii) Use of the updated version of the standard is not prohibited
under other applicable law, provided that:
(A) For content and vocabulary standards other than those at 45 CFR
170.213, the Secretary has not prohibited use of the updated version of
a standard for purposes of this section or 45 CFR part 170;
(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the
National Coordinator has approved the updated version for use in the
ONC Health IT Certification Program; and
(C) Use of the updated version of a standard does not disrupt an
end user's ability to access the data described in paragraph (b) of
this section through the API described in paragraph (a) of this
section.
(d) Documentation requirements for APIs. For each API implemented
in accordance with paragraph (a) of this section, an MA organization
must make publicly accessible, by posting directly on its website or
via publicly accessible hyperlink(s), complete accompanying
documentation that contains, at a minimum the information listed in
this paragraph. For the purposes of this section, ``publicly
accessible'' means that any person using commonly available technology
to browse the internet could access the information without any
preconditions or additional steps, such as a fee for access to the
documentation; a requirement to receive a copy of the material via
email; a requirement to register or create an account to receive the
documentation; or a requirement to read promotional material or agree
to receive future communications from the organization making the
documentation available;
(1) API syntax, function names, required and optional parameters
supported and their data types, return variables and their types/
structures, exceptions and exception handling methods and their
returns;
(2) The software components and configurations an application must
use in order to successfully interact with the API and process its
response(s); and
(3) All applicable technical requirements and attributes necessary
for an application to be registered with any authorization server(s)
deployed in conjunction with the API.
(e) Denial or discontinuation of access to the API. An MA
organization may deny or discontinue any third party application's
connection to the API required under paragraph (a) of this section if
the MA organization:
(1) Reasonably determines, consistent with its security risk
analysis under 45 CFR part 164 subpart C, that allowing an application
to connect or remain connected to the API would present an unacceptable
level of risk to the security of protected health information on the MA
organization's systems; and
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all applications and
developers through which enrollees seek to access their electronic
health information, as defined at 45 CFR 171.102, including but not
limited to criteria that may rely on automated monitoring and risk
mitigation tools.
(f) Coordination among payers. (1) An MA organization must maintain
a process for the electronic exchange of, at a minimum, the data
classes and elements included in the content standard adopted at 45 CFR
170.213. Such information received by an MA organization must be
incorporated into the MA organization's records about the current
enrollee. With the approval and at the direction of a current or former
enrollee or the enrollee's personal representative, the MA organization
must:
(i) Receive all such data for a current enrollee from any other
payer that has provided coverage to the enrollee within the preceding 5
years;
(ii) At any time an enrollee is currently enrolled in the MA plan
and up to 5 years after disenrollment, send all such data to any other
payer that currently covers the enrollee or a payer the enrollee or the
enrollee's personal representative specifically requests receive the
data; and
(iii) Send data received from another payer under this paragraph
(f) in the electronic form and format it was received.
(2) [Reserved]
(g) Enrollee resources regarding privacy and security. An MA
organization must provide in an easily accessible location on its
public website and through other appropriate mechanisms through which
it ordinarily communicates with current and former enrollees seeking to
access their health information held by the MA organization,
educational resources in non-technical, simple and easy-to-understand
language explaining at a minimum:
(1) General information on steps the individual may consider taking
to help protect the privacy and security of their health information
including factors to consider in selecting an application including
secondary uses of data, and the importance of understanding the
security and privacy practices of any application to which they will
entrust their health information; and
(2) An overview of which types of organizations or individuals are
and are not likely to be HIPAA covered entities, the oversight
responsibilities of the Office for Civil Rights (OCR) and the Federal
Trade Commission (FTC), and how to submit a complaint to:
(i) The HHS Office for Civil Rights (OCR); and
(ii) The Federal Trade Commission (FTC).
(h) Applicability. (1) An MA organization must comply with the
requirements in paragraphs (a) through (e) and (g) of this section
beginning January 1, 2021, and with the requirements in paragraph (f)
beginning January 1, 2022 with regard to data:
(i) With a date of service on or after January 1, 2016; and
(ii) That are maintained by the MA organization.
(2) [Reserved]
0
7. Section 422.120 is added to read as follows:
Sec. 422.120 Access to published provider directory information.
(a) An MA organization must implement and maintain a publicly
accessible, standards-based Application Programming Interface (API)
that is conformant with the technical requirements at Sec. 422.119(c),
excluding the security protocols related to user authentication and
authorization and any other protocols that restrict the availability of
this information to particular persons or organizations, the
documentation requirements at Sec. 422.119(d), and is accessible via a
public-facing digital endpoint on the MA organization's website.
(b) The API must provide a complete and accurate directory of--
(1) The MA plan's network of contracted providers, including names,
addresses, phone numbers, and specialties, updated no later than 30
calendar days after the MA organizations receives provider directory
information or updates to provider directory information; and
(2) For an MA organization that offers an MA-PD plan, the MA-PD's
pharmacy directory, including the pharmacy name, address, phone number,
number of pharmacies in the network, and mix (specifically the type of
pharmacy, such as ``retail pharmacy'') updated no later than 30
calendar days after the MA organization receives pharmacy directory
information or updates to pharmacy directory information.
(c) This section is applicable beginning January 1, 2021.
[[Page 25634]]
0
8. Section 422.504 is amended by adding paragraph (a)(18) to read as
follows:
Sec. 422.504 Contract provisions.
* * * * *
(a) * * *
(18) To comply with the requirements for access to health data and
plan information under Sec. Sec. 422.119 and 422.120 of this chapter.
* * * * *
PART 423--VOLUNTARY MEDICARE PERSCRIPTION DRUG BENEFIT
0
9. The authority citation for part 423 is revised to read as follows:
Authority: 42 U.S.C. 1302, 1306, 1395w-101 through 1395w-152,
and 1395hh.
0
10. Section 423.910 is amended--
0
a. In paragraph (b)(1) introductory text by removing the phrase
``monthly reporting requirement for the monthly enrollment reporting''
and adding in its place the phrase ``state enrollment reporting
requirement described in paragraph (d) of this section'';
0
b. In paragraph (d) by revising the paragraph heading and by
redesignating the text of paragraph (d) introductory text as paragraph
(d)(1).
0
c. In newly redesignated paragraph (d)(1), by removing the phrase
``Effective June 2005, and each subsequent month, States must submit an
electronic file, in a manner specified by CMS'' and by adding the
following phrase ``States must submit an electronic file as specified
in paragraph (d)(2) of this section,''; and
0
d. By adding paragraph (d)(2).
The revision and addition read as follows:
Sec. 423.910 Requirements.
* * * * *
(d) * * *
(2)(i) For the period prior to April 1, 2022, States must submit
the file at least monthly and may submit updates to that file on a more
frequent basis.
(ii) For the period beginning April 1, 2022, States must submit the
file at least monthly and must submit updates to that file on a daily
basis.
* * * * *
PART 431--STATE ORGANIZATION AND GENERAL ADMINISTRATION
0
11. The authority citation for part 431 is revised to read as follows:
Authority: 42 U.S.C. 1302.
0
12. Section 431.60 is added to subpart B to read as follows:
Sec. 431.60 Beneficiary access to and exchange of data.
(a) Application Programming Interface to support Medicaid
beneficiaries. A State must implement and maintain a standards-based
Application Programming Interface (API) that permits third-party
applications to retrieve, with the approval and at the direction of a
current beneficiary or the beneficiary's personal representative, data
specified in paragraph (b) of this section through the use of common
technologies and without special effort from the beneficiary.
(b) Accessible content. A State must make the following information
accessible to its current beneficiaries or the beneficiary's personal
representative through the API described in paragraph (a) of this
section:
(1) Data concerning adjudicated claims, including claims data for
payment decisions that may be appealed, were appealed, or are in the
process of appeal, and provider remittances and beneficiary cost-
sharing pertaining to such claims, no later than one (1) business day
after a claim is processed;
(2) Encounter data no later than one (1) business day after
receiving the data from providers, other than MCOs, PIHPs, and PAHPs,
compensated on the basis of capitation payments;
(3) Clinical data, including laboratory results, if the State
maintains any such data, no later than one (1) business day after the
data is received by the State; and
(4) Information about covered outpatient drugs and updates to such
information, including, where applicable, preferred drug list
information, no later than one (1) business day after the effective
date of any such information or updates to such information.
(c) Technical requirements. A State implementing an API under
paragraph (a) of this section:
(1) Must implement, maintain, and use API technology conformant
with 45 CFR 170.215;
(2) Must conduct routine testing and monitoring, and update as
appropriate, to ensure the API functions properly, including
assessments to verify that the API is fully and successfully
implementing privacy and security features such as, but not limited to,
those required to comply with HIPAA privacy and security requirements
in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable
law protecting the privacy and security of individually identifiable
data;
(3) Must comply with the content and vocabulary standards
requirements in paragraphs (c)(3)(i) and (ii) of this section, as
applicable to the data type or data element, unless alternate standards
are required by other applicable law:
(i) Content and vocabulary standards at 45 CFR 170.213 where such
standards are applicable to the data type or element, as appropriate;
and
(ii) Content and vocabulary standards at 45 CFR part 162 and Sec.
423.160 of this chapter where required by law, or where such standards
are applicable to the data type or element, as appropriate.
(4) May use an updated version of any standard or all standards
required under paragraph (c)(1) or (3) of this section, where:
(i) Use of the updated version of the standard is required by other
applicable law, or
(ii) Use of the updated version of the standard is not prohibited
under other applicable law, provided that:
(A) For content and vocabulary standards other than those at 45 CFR
170.213, the Secretary has not prohibited use of the updated version of
a standard for purposes of this section or 45 CFR part 170;
(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the
National Coordinator has approved the updated version for use in the
ONC Health IT Certification Program; and
(C) Use of the updated version of a standard does not disrupt an
end user's ability to access the data described in paragraph (b) of
this section through the API described in paragraph (a) of this
section.
(d) Documentation requirements for APIs. For each API implemented
in accordance with paragraph (a) of this section, a State must make
publicly accessible, by posting directly on its website or via publicly
accessible hyperlink(s), complete accompanying documentation that
contains, at a minimum the information listed in this paragraph. For
the purposes of this section, ``publicly accessible'' means that any
person using commonly available technology to browse the internet could
access the information without any preconditions or additional steps,
such as a fee for access to the documentation; a requirement to receive
a copy of the material via email; a requirement to register or create
an account to receive the documentation; or a requirement to read
promotional material or agree to receive future communications from the
organization making the documentation available;
(1) API syntax, function names, required and optional parameters
supported and their data types, return
[[Page 25635]]
variables and their types/structures, exceptions and exception handling
methods and their returns;
(2) The software components and configurations an application must
use in order to successfully interact with the API and process its
response(s); and
(3) All applicable technical requirements and attributes necessary
for an application to be registered with any authorization server(s)
deployed in conjunction with the API.
(e) Denial or discontinuation of access to the API. A State may
deny or discontinue any third-party application's connection to the API
required under paragraph (a) of this section if the State:
(1) Reasonably determines, consistent with its security risk
analysis under 45 CFR part 164 subpart C, that allowing an application
to connect or remain connected to the API would present an unacceptable
level of risk to the security of protected health information on the
State's systems; and
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all applications and
developers through which beneficiaries seek to access their electronic
health information as defined at 45 CFR 171.102, including but not
limited to criteria that may rely on automated monitoring and risk
mitigation tools.
(f) Beneficiary resources regarding privacy and security. The State
must provide in an easily accessible location on its public website and
through other appropriate mechanisms through which it ordinarily
communicates with current and former beneficiaries seeking to access
their health information held by the State Medicaid agency, educational
resources in non-technical, simple and easy-to-understand language
explaining at a minimum:
(1) General information on steps the individual may consider taking
to help protect the privacy and security of their health information,
including factors to consider in selecting an application including
secondary uses of data, and the importance of understanding the
security and privacy practices of any application to which they will
entrust their health information; and
(2) An overview of which types of organizations or individuals are
and are not likely to be HIPAA covered entities, the oversight
responsibilities of the Office for Civil Rights (OCR) and the Federal
Trade Commission (FTC), and how to submit a complaint to:
(i) The HHS Office for Civil Rights (OCR); and
(ii) The Federal Trade Commission (FTC).
(g) Data availability. (1) The State must comply with the
requirements in paragraph (a) through (f) of this section beginning
January 1, 2021 with regard to data:
(i) With a date of service on or after January 1, 2016; and
(ii) That are maintained by the State.
(2) [Reserved]
0
13. Section 431.70 is added to subpart B to read as follows:
Sec. 431.70 Access to published provider directory information.
(a) The State must implement and maintain a publicly accessible,
standards-based Application Programming Interface (API) that is
conformant with the technical requirements at Sec. 431.60(c),
excluding the security protocols related to user authentication and
authorization and any other protocols that restrict the availability of
this information to particular persons or organizations, the
documentation requirements at Sec. 431.60(d), and is accessible via a
public-facing digital endpoint on the State's website.
(b) The API must provide a complete and accurate directory of--
(1) The State's provider directory information specified in section
1902(a)(83) of the Act, updated no later than 30 calendar days after
the State receives provider directory information or updates to
provider directory information.
(2) [Reserved]
(c) This section is applicable beginning January 1, 2021.
PART 438--MANAGED CARE
0
14. The authority citation for part 438 is revised to read as follows:
Authority: 42 U.S.C. 1302.
0
15. Section 438.62 is amended by adding paragraphs (b)(1)(vi) and (vii)
to read as follows:
Sec. 438.62 Continued services to enrollees.
* * * * *
(b) * * *
(1) * * *
(vi) A process for the electronic exchange of, at a minimum, the
data classes and elements included in the content standard adopted at
45 CFR 170.213. Such information received by the MCO, PIHP, or PAHP
must be incorporated into the MCO's, PIHP's, or PAHP's records about
the current enrollee. With the approval and at the direction of a
current or former enrollee or the enrollee's personal representative,
the MCO, PIHP, or PAHP must:
(A) Receive all such data for a current enrollee from any other
payer that has provided coverage to the enrollee within the preceding 5
years;
(B) At any time the enrollee is currently enrolled in the MCO,
PIHP, or PAHP and up to 5 years after disenrollment, send all such data
to any other payer that currently covers the enrollee or a payer the
enrollee or the enrollee's personal representative specifically
requests receive the data; and
(C) Send data received from another payer under this paragraph in
the electronic form and format it was received.
(vii) Applicability.
(A) The MCO, PIHP, or PAHP must comply with the requirements in
paragraph (b)(1)(vi) of this section beginning January 1, 2022 with
regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the MCO, PIHP, or PAHP.
(B) [Reserved]
* * * * *
0
16. Section 438.242 is amended by adding paragraphs (b)(5) and (6) to
read as follows:
Sec. 438.242 Health information systems.
* * * * *
(b) * * *
(5) Implement an Application Programming Interface (API) as
specified in Sec. 431.60 of this chapter as if such requirements
applied directly to the MCO, PIHP, or PAHP and include--
(i) All encounter data, including encounter data from any network
providers the MCO, PIHP, or PAHP is compensating on the basis of
capitation payments and adjudicated claims and encounter data from any
subcontractors.
(ii) [Reserved]
(6) Implement, by January 1, 2021, and maintain a publicly
accessible standards-based API described in Sec. 431.70, which must
include all information specified in Sec. 438.10(h)(1) and (2) of this
chapter.
* * * * *
PART 457--ALLOTMENTS AND GRANTS TO STATES
0
17. The authority citation for part 457 is revised to read as follows:
Authority: 42 U.S.C. 1302.
0
18. Section 457.700 is amended by--
0
a. Redesignating paragraphs (a)(1) and (2) as paragraphs (a)(2) and
(3), respectively;
0
b. Adding paragraph (a)(1); and
0
c. Revising paragraph (c).
The addition and revision reads as follows:
[[Page 25636]]
Sec. 457.700 Basis, scope, and applicability.
(a) * * *
(1) Section 2101(a) of the Act, which sets forth that the purpose
of title XXI is to provide funds to States to provide child health
assistance to uninsured, low-income children in an effective and
efficient manner that is coordinated with other sources of health
benefits coverage;
* * * * *
(c) Applicability. The requirements of this subpart apply to
separate child health programs and Medicaid expansion programs, except
that Sec. 457.730 does not apply to Medicaid expansion programs.
Separate child health programs that provide benefits exclusively
through managed care organizations may meet the requirements of Sec.
457.730 by requiring the managed care organizations to meet the
requirements of Sec. 457.1233(d)(2).
0
19. Section 457.730 is added to read as follows:
Sec. 457.730 Beneficiary access to and exchange of data.
(a) Application Programming Interface to support CHIP
beneficiaries. A State must implement and maintain a standards-based
Application Programming Interface (API) that permits third-party
applications to retrieve, with the approval and at the direction of the
current individual beneficiary or the beneficiary's personal
representative, data specified in paragraph (b) of this section through
the use of common technologies and without special effort from the
beneficiary.
(b) Accessible content. A State must make the following information
accessible to its current beneficiaries or the beneficiary's personal
representative through the API described in paragraph (a) of this
section:
(1) Data concerning adjudicated claims, including claims data for
payment decisions that may be appealed, were appealed, or are in the
process of appeal, and provider remittances and beneficiary cost-
sharing pertaining to such claims, no later than one (1) business day
after a claim is processed;
(2) Encounter data no later than 1 business day after receiving the
data from providers, other than MCOs, PIHPs, or PAHPs, compensated on
the basis of capitation payments;
(3) Clinical data, including laboratory results, if a State
maintains any such data, no later than one (1) business day after the
data is received by the State; and
(4) Information, about covered outpatient drugs and updates to such
information, including, where applicable, preferred drug list
information, no later than one (1) business day after the effective
date of the information or updates to such information.
(c) Technical requirements. A State implementing an API under
paragraph (a) of this section:
(1) Must implement, maintain, and use API technology conformant
with 45 CFR 170.215;
(2) Must conduct routine testing and monitoring, and update as
appropriate, to ensure the API functions properly, including
assessments to verify that the API technology is fully and successfully
implementing privacy and security features such as, but not limited to,
those required to comply with HIPAA privacy and security requirements
in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable
law protecting the privacy and security of individually identifiable
data;
(3) Must comply with the content and vocabulary standard
requirements in paragraphs (c)(3)(i) and (ii) of this section, as
applicable to the data type or data element, unless alternate standards
are required by other applicable law:
(i) Content and vocabulary standards at 45 CFR 170.213 where such
standards are applicable to the data type or element, as appropriate;
and
(ii) Content and vocabulary standards at 45 CFR part 162 and Sec.
423.160 of this chapter where required by law, or where such standards
are applicable to the data type or element, as appropriate.
(4) May use an updated version of any standard or all standards
required under paragraphs (c)(1) or (3) of this section, where:
(i) Use of the updated version of the standard is required by other
applicable law, or
(ii) Use of the updated version of the standard is not prohibited
under other applicable law, provided that:
(A) For content and vocabulary standards other than those at 45 CFR
170.213, the Secretary has not prohibited use of the updated version of
a standard for purposes of this section or 45 CFR part 170;
(B) For standards at 45 CFR 170.213 and 170.215, the National
Coordinator has approved the updated version for use in the ONC Health
IT Certification Program; and
(C) Use of the updated version of a standard does not disrupt an
end user's ability to access the data described in paragraph (b) of
this section through the API described in paragraph (a) of this
section.
(d) Documentation requirements for APIs. For each API implemented
in accordance with paragraph (a) of this section, a State must make
publicly accessible, by posting directly on its website or via publicly
accessible hyperlink(s), complete accompanying documentation that
contains, at a minimum the information listed in this paragraph. For
the purposes of this section, ``publicly accessible'' means that any
person using commonly available technology to browse the internet could
access the information without any preconditions or additional steps,
such as a fee for access to the documentation; a requirement to receive
a copy of the material via email; a requirement to register or create
an account to receive the documentation; or a requirement to read
promotional material or agree to receive future communications from the
organization making the documentation available;
(1) API syntax, function names, required and optional parameters
supported and their data types, return variables and their types/
structures, exceptions and exception handling methods and their
returns;
(2) The software components and configurations that an application
must use in order to successfully interact with the API and process its
response(s); and
(3) All applicable technical requirements and attributes necessary
for an application to be registered with any authorization server(s)
deployed in conjunction with the API.
(e) Denial or discontinuation of access to the API. A State may
deny or discontinue any third-party application's connection to the API
required under paragraph (a) of this section if the State:
(1) Reasonably determines, consistent with its security risk
analysis under 45 CFR part 164 subpart C, that allowing an application
to connect or remain connected to the API would present an unacceptable
level of risk to the security of protected health information on the
State's systems; and
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all applications and
developers through which beneficiaries seek to access their electronic
health information as defined at 45 CFR 171.102, including but not
limited to criteria that may rely on automated monitoring and risk
mitigation tools.
(f) Beneficiary resources regarding privacy and security. A State
must provide in an easily accessible location on its public website and
through other appropriate mechanisms through which it ordinarily
communicates with current and former beneficiaries seeking to
[[Page 25637]]
access their health information held by the State CHIP agency,
educational resources in non-technical, simple and easy-to-understand
language explaining at a minimum:
(1) General information on steps the individual may consider taking
to help protect the privacy and security of their health information,
including factors to consider in selecting an application including
secondary uses of data, and the importance of understanding the
security and privacy practices of any application to which they will
entrust their health information; and
(2) An overview of which types of organizations or individuals are
and are not likely to be HIPAA covered entities, the oversight
responsibilities of OCR and FTC, and how to submit a complaint to:
(i) The HHS Office for Civil Rights (OCR); and
(ii) The Federal Trade Commission (FTC).
(g) Data availability. (1) The State must comply with the
requirements in paragraphs (a) through (f) of this section beginning
January 1, 2021 with regard to data:
(i) With a date of service on or after January 1, 2016; and
(ii) That are maintained by the State.
(2) [Reserved]
0
20. Section 457.760 is added to subpart G to read as follows:
Sec. 457.760 Access to published provider directory information.
(a) The State must implement and maintain a publicly accessible,
standards-based Application Programming Interface (API) that is
conformant with the technical requirements at Sec. 457.730(c),
excluding the security protocols related to user authentication and
authorization and any other protocols that restrict the availability of
this information to particular persons or organizations, the
documentation requirements at Sec. 457.730(d), and is accessible via a
public-facing digital endpoint on the State's website.
(b) The API must provide a complete and accurate directory of--
(1) The State's provider directory information including provider
names, addresses, phone numbers, and specialties, updated no later than
30 calendar days after the State receives provider directory
information or updates to provider directory information.
(2) [Reserved]
(c) This section is applicable beginning January 1, 2021.
0
21. Section 457.1233 is amended by revising paragraph (d) to read as
follows:
Sec. 457.1233 Structure and operations standards.
* * * * *
(d) Health information systems. (1) The State must ensure, through
its contracts, that each MCO, PIHP, and PAHP complies with the health
information systems requirements as provided in Sec. 438.242(a),
(b)(1) through (4), (c), (d), and (e) of this chapter.
(2) Each MCO, PIHP, and PAHP must implement an Application
Programming Interface (API) as specified in Sec. 457.730 as if such
requirements applied directly to the MCO, PIHP, or PAHP, and include--
(i) All encounter data, including encounter data from any network
providers the MCO, PIHP, or PAHP is compensating on the basis of
capitation payments and adjudicated claims and encounter data from any
subcontractors.
(ii) [Reserved]
(3) Implement, by January 1, 2021, and maintain a publicly
accessible standards-based API described in Sec. 457.760, which must
include all information specified in Sec. 438.10(h)(1) and (2) of this
chapter.
* * * * *
PART 482--CONDITIONS OF PARTICIPATION: HOSPITALS
0
22. The authority citation for part 482 is revised to read as follows:
Authority: 42 U.S.C. 1302, 1395hh, and 1395rr, unless otherwise
noted.
0
23. Section 482.24 is amended by adding paragraph (d) to read as
follows:
Sec. 482.24 Conditions of participation: Medical record services.
* * * * *
(d) Standard: Electronic notifications. If the hospital utilizes an
electronic medical records system or other electronic administrative
system, which is conformant with the content exchange standard at 45
CFR 170.205(d)(2), then the hospital must demonstrate that--
(1) The system's notification capacity is fully operational and the
hospital uses it in accordance with all State and Federal statutes and
regulations applicable to the hospital's exchange of patient health
information.
(2) The system sends notifications that must include at least
patient name, treating practitioner name, and sending institution name.
(3) To the extent permissible under applicable federal and state
law and regulations, and not inconsistent with the patient's expressed
privacy preferences, the system sends notifications directly, or
through an intermediary that facilitates exchange of health
information, at the time of:
(i) The patient's registration in the hospital's emergency
department (if applicable).
(ii) The patient's admission to the hospital's inpatient services
(if applicable).
(4) To the extent permissible under applicable federal and state
law and regulations and not inconsistent with the patient's expressed
privacy preferences, the system sends notifications directly, or
through an intermediary that facilitates exchange of health
information, either immediately prior to, or at the time of:
(i) The patient's discharge or transfer from the hospital's
emergency department (if applicable).
(ii) The patient's discharge or transfer from the hospital's
inpatient services (if applicable).
(5) The hospital has made a reasonable effort to ensure that the
system sends the notifications to all applicable post-acute care
services providers and suppliers, as well as to any of the following
practitioners and entities, which need to receive notification of the
patient's status for treatment, care coordination, or quality
improvement purposes:
(i) The patient's established primary care practitioner;
(ii) The patient's established primary care practice group or
entity; or
(iii) Other practitioner, or other practice group or entity,
identified by the patient as the practitioner, or practice group or
entity, primarily responsible for his or her care.
0
24. Section 482.61 is amended by adding paragraph (f) to read as
follows:
Sec. 482.61 Condition of participation: Special medical record
requirements for psychiatric hospitals.
* * * * *
(f) Standard: Electronic notifications. If the hospital utilizes an
electronic medical records system or other electronic administrative
system, which is conformant with the content exchange standard at 45
CFR 170.205(d)(2), then the hospital must demonstrate that--
(1) The system's notification capacity is fully operational and the
hospital uses it in accordance with all State and Federal statutes and
regulations applicable to the hospital's exchange of patient health
information.
(2) The system sends notifications that must include at least
patient name, treating practitioner name, and sending institution name.
[[Page 25638]]
(3) To the extent permissible under applicable federal and state
law and regulations, and not inconsistent with the patient's expressed
privacy preferences, the system sends notifications directly, or
through an intermediary that facilitates exchange of health
information, at the time of:
(i) The patient's registration in the hospital's emergency
department (if applicable).
(ii) The patient's admission to the hospital's inpatient services
(if applicable).
(4) To the extent permissible under applicable federal and state
law and regulations, and not inconsistent with the patient's expressed
privacy preferences, the system sends notifications directly, or
through an intermediary that facilitates exchange of health
information, either immediately prior to, or at the time of:
(i) The patient's discharge or transfer from the hospital's
emergency department (if applicable).
(ii) The patient's discharge or transfer from the hospital's
inpatient services (if applicable).
(5) The hospital has made a reasonable effort to ensure that the
system sends the notifications to all applicable post-acute care
services providers and suppliers, as well as to any of the following
practitioners and entities, which need to receive notification of the
patient's status for treatment, care coordination, or quality
improvement purposes:
(i) The patient's established primary care practitioner;
(ii) The patient's established primary care practice group or
entity; or
(iii) Other practitioner, or other practice group or entity,
identified by the patient as the practitioner, or practice group or
entity, primarily responsible for his or her care.
PART 485--CONDITIONS OF PARTICIPATION: SPECIALIZED PROVIDERS
0
25. The authority citation for part 485 is revised to read as follows:
Authority: 42 U.S.C. 1302 and 1395hh.
0
26. Section 485.638 is amended by adding paragraph (d) to read as
follows:
Sec. 485.638 Conditions of participation: Clinical records.
* * * * *
(d) Standard: Electronic notifications. If the CAH utilizes an
electronic medical records system or other electronic administrative
system, which is conformant with the content exchange standard at 45
CFR 170.205(d)(2), then the CAH must demonstrate that--
(1) The system's notification capacity is fully operational and the
CAH uses it in accordance with all State and Federal statutes and
regulations applicable to the CAH's exchange of patient health
information.
(2) The system sends notifications that must include at least
patient name, treating practitioner name, and sending institution name.
(3) To the extent permissible under applicable federal and state
law and regulations, and not inconsistent with the patient's expressed
privacy preferences, the system sends notifications directly, or
through an intermediary that facilitates exchange of health
information, at the time of:
(i) The patient's registration in the CAH's emergency department
(if applicable).
(ii) The patient's admission to the CAH's inpatient services (if
applicable).
(4) To the extent permissible under applicable federal and state
law and regulations, and not inconsistent with the patient's expressed
privacy preferences, the system sends notifications directly, or
through an intermediary that facilitates exchange of health
information, either immediately prior to, or at the time of:
(i) The patient's discharge or transfer from the CAH's emergency
department (if applicable).
(ii) The patient's discharge or transfer from the CAH's inpatient
services (if applicable).
(5) The CAH has made a reasonable effort to ensure that the system
sends the notifications to all applicable post-acute care services
providers and suppliers, as well as to any of the following
practitioners and entities, which need to receive notification of the
patient's status for treatment, care coordination, or quality
improvement purposes:
(i) The patient's established primary care practitioner;
(ii) The patient's established primary care practice group or
entity; or
(iii) Other practitioner, or other practice group or entity,
identified by the patient as the practitioner, or practice group or
entity, primarily responsible for his or her care.
TITLE 45--PUBLIC WELFARE
SUBTITLE A--DEPARTMENT OF HEALTH AND HUMAN SERVICES
PART 156--HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE
CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES
0
27. The authority citation for part 156 continues to read as follows:
Authority: 42 U.S.C. 18021-18024, 18031-18032, 18041-18042,
18044, 18054, 18061, 18063, 18071, 18082, 26 U.S.C. 36B, and 31
U.S.C. 9701.
0
28. Section 156.221 is added to read as follows:
Sec. 156.221 Access to and exchange of health data and plan
information.
(a) Application Programming Interface to support enrollees. Subject
to paragraph (h) of this section, a QHP issuer on a Federally-
Facilitated Exchange must implement and maintain a standards-based
Application Programming Interface (API) that permits third-party
applications to retrieve, with the approval and at the direction of a
current individual enrollee or the enrollee's personal representative,
data specified in paragraph (b) of this section through the use of
common technologies and without special effort from the enrollee.
(b) Accessible content. (1) A QHP issuer on a Federally-facilitate
Exchange must make the following information accessible to its current
enrollees or the enrollee's personal representative through the API
described in paragraph (a) of this section:
(i) Data concerning adjudicated claims, including claims data for
payment decisions that may be appealed, were appealed, or are in the
process of appeal, and provider remittances and enrollee cost-sharing
pertaining to such claims, no later than one (1) business day after a
claim is processed;
(ii) Encounter data from capitated providers, no later than one (1)
business day after data concerning the encounter is received by the QHP
issuer; and
(iii) Clinical data, including laboratory results, if the QHP
issuer maintains any such data, no later than one (1) business day
after data is received by the issuer.
(2) [Reserved]
(c) Technical requirements. A QHP issuer on a Federally-facilitated
Exchange implementing an API under paragraph (a) of this section:
(1) Must implement, maintain, and use API technology conformant
with 45 CFR 170.215;
[[Page 25639]]
(2) Must conduct routine testing and monitoring, and update as
appropriate, to ensure the API functions properly, including
assessments to verify the API is fully and successfully implementing
privacy and security features such as, but not limited to, those
required to comply with HIPAA privacy and security requirements in
parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law
protecting privacy and security of individually identifiable data;
(3) Must comply with the content and vocabulary standard
requirements in paragraphs (c)(3)(i) and (ii) of this section, as
applicable, to the data type or data element, unless alternate
standards are required by other applicable law:
(i) Content and vocabulary standards at 45 CFR 170.213 where such
are applicable to the data type or element, as appropriate; and
(ii) Content and vocabulary standards at part 162 of this
subchapter and 42 CFR 423.160 where required by law, or where such
standards are applicable to the data type or element, as appropriate.
(4) May use an updated version of any standard or all standards
required under paragraphs (c)(1) or (3) of this section, where:
(i) Use of the updated version of the standard is required by other
applicable law, or
(ii) Use of the updated version of the standard is not prohibited
under other applicable law, provided that:
(A) For content and vocabulary standards other than those at 45 CFR
170.213, the Secretary has not prohibited use of the updated version of
a standard for purposes of this section or part 170 of this subchapter;
(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the
National Coordinator has approved the updated version for use in the
ONC Health IT Certification Program; and
(C) Use of the updated version of a standard does not disrupt an
end user's ability to access the data described in paragraph (b) of
this section through the API described in paragraph (a) of this
section.
(d) Documentation requirements for APIs. For each API implemented
in accordance with paragraph (a) of this section, a QHP issuer on a
Federally-Facilitated Exchange must make publicly accessible, by
posting directly on its website and/or via publicly accessible
hyperlink(s), complete accompanying documentation that contains, at a
minimum the information listed in this paragraph. For the purposes of
this section, ``publicly accessible'' means that any person using
commonly available technology to browse the internet could access the
information without any preconditions or additional steps, such as a
fee for access to the documentation; a requirement to receive a copy of
the material via email; a requirement to register or create an account
to receive the documentation; or a requirement to read promotional
material or agree to receive future communications from the
organization making the documentation available;
(1) API syntax, function names, required and optional parameters
supported and their data types, return variables and their types/
structures, exceptions and exception handling methods and their
returns;
(2) The software components and configurations an application must
use in order to successfully interact with the API and process its
response(s); and
(3) All applicable technical requirements and attributes necessary
for an application to be registered with any authorization server(s)
deployed in conjunction with the API.
(e) Denial or discontinuation of access to the API. A QHP issuer on
a Federally-Facilitated Exchange may deny or discontinue any third
party application's connection to the API required under paragraph (a)
of this section if the QHP issuer:
(1) Reasonably determines, consistent with its security risk
analysis under 45 CFR part 164 subpart C, that allowing an application
to connect or remain connected to the API would present an unacceptable
level of risk to the security of personally identifiable information,
including protected health information, on the QHP issuer's systems;
and
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all applications and
developers through which enrollees seek to access their electronic
health information as defined at Sec. 171.102 of this subchapter,
including but not limited to criteria that may rely on automated
monitoring and risk mitigation tools.
(f) Coordination among payers. (1) A QHP issuer on a Federally-
facilitated Exchange must maintain a process for the electronic
exchange of, at a minimum, the data classes and elements included in
the content standard adopted at 45 CFR 170.213. Such information
received by a QHP issuer on a Federally-facilitated Exchange must be
incorporated into the QHP issuer's records about the current enrollee.
With the approval and at the direction of a current or former enrollee
or the enrollee's personal representative, a QHP issuer on a Federally-
facilitated Exchange must:
(i) Receive all such data for a current enrollee from any other
payer that has provided coverage to the enrollee within the preceding 5
years;
(ii) At any time the enrollee is currently enrolled in the plan and
up to 5 years after disenrollment, send all such data to any other
payer that currently covers the enrollee or a payer the enrollee or the
enrollee's personal representative specifically requests receive the
data; and
(iii) Send data received from another payer under this paragraph
(f) in the electronic form and format it was received.
(2) [Reserved]
(g) Enrollee resources regarding privacy and security. A QHP issuer
on a Federally-facilitated Exchange must provide in an easily
accessible location on its public website and through other appropriate
mechanisms through which it ordinarily communicates with current and
former enrollees seeking to access their health information held by the
QHP issuer, educational resources in non-technical, simple and easy-to-
understand language explaining at a minimum:
(1) General information on steps the individual may consider taking
to help protect the privacy and security of their health information,
including factors to consider in selecting an application including
secondary uses of data, and the importance of understanding the
security and privacy practices of any application to which they will
entrust their health information; and
(2) An overview of which types of organizations or individuals are
and are not likely to be HIPAA covered entities, the oversight
responsibilities of the Office for Civil Rights (OCR) and the Federal
Trade Commission (FTC), and how to submit a complaint to:
(i) The HHS Office for Civil Rights (OCR); and
(ii) The Federal Trade Commission (FTC).
(h) Exception. (1) If a plan applying for QHP certification to be
offered through a Federally-facilitated Exchange believes it cannot
satisfy the requirements in paragraphs (a) through (g) of this section,
the issuer must include as part of its QHP application a narrative
justification describing the reasons why the plan cannot reasonably
satisfy the requirements for the applicable plan year, the impact of
non-compliance upon enrollees, the current or proposed means of
providing health information to enrollees, and solutions and a timeline
to achieve compliance with the requirements of this section.
[[Page 25640]]
(2) The Federally-facilitated Exchange may grant an exception to
the requirements in paragraphs (a) through (g) of this section if the
Exchange determines that making such health plan available through such
Exchange is in the interests of qualified individuals in the State or
States in which such Exchange operates.
(i) Applicability. A QHP issuer on an individual market Federally-
facilitated Exchange, not including QHP issuers offering only stand-
alone dental plans, must comply with the requirements in paragraphs (a)
through (e) and (g) of this section beginning with plan years beginning
on or after January 1, 2021, and with the requirements in paragraph (f)
of this section beginning with plan years beginning on or after January
1, 2022 with regard to data:
(1) With a date of service on or after January 1, 2016; and
(2) That are maintained by the QHP issuer for enrollees in QHPs.
Dated: January 21, 2020.
Seema Verma,
Administrator, Centers for Medicare & Medicaid Services.
Dated: March 5, 2020.
Alex M. Azar II,
Secretary, Department of Health and Human Services.
[FR Doc. 2020-05050 Filed 4-21-20; 4:15 pm]
BILLING CODE P
