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

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

We are finalizing with modifications our proposal to require MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to implement and maintain a standards-based Patient Access API. This Patient Access API must meet the technical standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.215 (currently including Health Level 7® (HL7) Fast Healthcare Interoperability Resources® (FHIR) Release 4.0.1) and the content and vocabulary standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.213, as well as content and vocabulary standards at 45 CFR part 162 and the content and vocabulary standards at 42 CFR 423.160. We are finalizing that through the Patient Access API, payers must permit 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 § 457.1216 CHIP managed care entities), and at 45 CFR 156.221(f) for QHP issuers on the FFEs, to send, at a current or former enrollee's request, specific information they maintain with a date of service on or after January 1, 2016 to any other payer identified by the current enrollee or former enrollee. This is consistent with the Patient Access API detailed in section III. of this final rule. We are also finalizing a provision that a payer is only obligated to share data received from another payer under this regulation in the electronic form and format it was received. This is intended to reduce burden on payers. We are finalizing that this payer-to-payer data exchange must be fully implemented by January 1, 2022.

In response to comments discussed more fully below, we are not finalizing our proposal to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in a trusted exchange network given the concerns commenters raised regarding the need for a mature Trusted Exchange Framework and Common Agreement (TEFCA) to be in place first, and appreciating that work on TEFCA is ongoing at this time.

We are finalizing the requirements that all states participate in daily exchange of buy-in data, which includes both sending data to CMS and receiving responses from CMS daily, and that all states submit the MMA file data to CMS daily by April 1, 2022 in accordance with 42 CFR 406.26, 407.40, and 423.910, respectively, as proposed. These requirements will improve the experience of dually eligible individuals by improving the ability of providers and payers to coordinate eligibility, enrollment, benefits, and/or care for this population.

We are finalizing our proposal to include an indicator on Physician Compare for the eligible clinicians and groups that submit a “no” response to any of the three prevention of information blocking statements for MIPS. In the event that these statements are left blank, the attestations will be considered incomplete, and we will not include an indicator on Physician Compare. The indicator will be posted on Physician Compare, either on the profile pages or in the downloadable database, starting with the 2019 performance period data available for public reporting starting in late 2020.

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.

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® (HL7) Fast Healthcare Interoperability Resources® (FHIR) for APIs

Section 106(b)(1)(B)(ii) of the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) defines health IT “interoperability” as the ability of two or more health information systems or components to exchange clinical and other information and to use the information that has been exchanged using common standards to provide access to longitudinal information for health care providers in order to facilitate coordinated care and improved patient outcomes. Interoperability is also defined in section 3000 of the Public Health Service Act (PHSA) (42 U.S.C. 300jj), as amended by section 4003 of the 21st Century Cures Act. Under that definition, “interoperability,” with respect to health IT, means such health IT that enables the secure exchange of electronic health information with, and use of electronic health information from, other health IT without special effort on the part of the user; allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state or federal law; and does not constitute information blocking as defined in section 3022(a) of the PHSA, which was added by section 4004 of the Cures Act. We believe the PHSA definition is consistent with the MACRA definition of “interoperability”. Consistent with the CMS Interoperability and Patient Access proposed rule (84 FR 7619), we will use the PHSA definition of “interoperability” for the purposes of this final rule.

We believe the PHSA definition of “interoperability” is useful as a foundational reference for our approach to advancing the interoperability and exchange of electronic health information for individuals throughout the United States, and across the entire spectrum of provider types and care settings with which health insurance issuers and administrators need to efficiently exchange multiple types of relevant data. We noted the PHSA definition of “interoperability” is not limited to a specific program or initiative, but rather can be applied to all activities under the title of the PHSA that establishes ONC's responsibilities to support and shape the health information ecosystem, including the exchange infrastructure for the U.S. health care system as a whole. The PHSA definition is also consistent with HHS's vision and strategy for achieving a health information ecosystem within which all individuals, their personal representatives, their health care providers, and their payers are able to send, receive, find, and use electronic health information in a manner that is appropriate, secure, timely, and reliable to support the health and wellness of individuals through informed, shared decision-making,^[8] as well as to support consumer choice of payers and providers.

We summarize the public comment we received on use of the PHSA definition of “interoperability” and provide our response.

Comment: One commenter specifically supported the use of the PHSA definition of “interoperability”.

Response: We appreciate the commenter's support.

A core policy principle we aim to support across all policies in this rule is that every American should be able, without special effort or advanced technical skills, to see, obtain, and use all electronically available information that is relevant to their health, care, and choices—of plans, providers, and specific treatment options. In the proposed rule, we explained this included two types of information: personal health information that health care providers and health plans, or payers, must make available to an 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]

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

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 and/or receive a copy of PHI held in designated record sets by covered entities and their business associates as detailed at 45 CFR 164.524. We specifically noted in the proposed rule that OCR had indicated in regulations and guidance, that an individual could exercise their right of access by requesting that their information be sent to a third party.^[13]

As we also noted in the proposed rule (84 FR 7622), we are aware of stakeholder concerns about which protections apply to non-covered entities, such as direct-to-consumer applications. As we explained in the proposed rule, when a non-covered entity discloses an individual's confidential information in a manner or for a purpose not consistent with the privacy notice and terms of use to which the individual agreed, the FTC has authority under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)) to investigate and take action against unfair or deceptive trade practices. The FTC has applied this authority to a wide variety of entities.^[14] The FTC also enforces the FTC Health Breach Notification Rule, which applies to certain types of entities, including vendors of personal health records and third-party service providers, that fall outside of the scope of HIPAA, and therefore, are not subject to the HIPAA Breach Notification Rule.^[15] This FTC Health Breach Notification Rule explains the process and steps third parties must follow when they discover a breach of identifiable personal health record information they maintain. Any violation of this Rule is enforced by the FTC as an unfair or deceptive act or practice under the FTC Act.

We recognized that this is a complex landscape for patients, who we anticipate will want to exercise due diligence on their own behalf in reviewing the terms of service and other information about the applications they consider selecting. Therefore, we proposed specific requirements on payers to ensure enrollees have the 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.

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 maintain, and absent patient requests to the contrary, are obligated to take reasonable measures to protect these data in transit. Once these data are transmitted and no longer under the control of the covered entity or business associate, those entities no longer have any obligations under HIPAA for the privacy and security of the PHI, because these data are no longer subject to HIPAA. We stress, as discussed in the CMS Interoperability and Patient Access proposed rule, nothing in this rule alters covered entities' or business associates' responsibilities to protect PHI under the HIPAA Privacy and Security Rules.

The only instance per the policies proposed in this rule that would allow a payer to deny access to an app, as discussed in the proposed rule and underlying the rationale for finalizing 42 CFR 422.119(e), 431.60(e), 438.242(b)(6) (redesignated as § 438.242(b)(5) see section VI. in this rule), 457.730(e), 457.1233(d)(2), and 45 CFR 156.221(e), would be if the covered entity or its business associate's own systems would be endangered if it were to engage with a specific third-party application through an API, for instance if allowing such access would result in an unacceptable security risk. Therefore, as we also noted, covered entities and business associates are free to offer advice to patients on the potential risks involved with requesting data transfers to an application or entity not covered by HIPAA, but such efforts generally must stop at education and awareness or advice regarding concerns related to a specific app. For instance, if a payer notes that an app a patient requests receive their data does not lay out in its privacy policy specifically how the patient's personal data will be used, the payer could choose to inform the patient they may not want to share their data with that app without a clear understanding of how the app may use the data, including details about the app's secondary data use policy. If the patient still wants their data to be shared, or does not respond to the payer's warning, the payer would need to share these data via the API absent an unacceptable security risk to the payer's own system. For more information on this ability to inform patients, see section III.C.2.g. of this final rule. The requirements finalized in this rule do not impact or change obligations under the HIPAA Privacy and Security Rules in any way.

Comment: A few commenters noted discrepancies in the terminology used in the OCR FAQ mentioned in the CMS Interoperability and Patient Access proposed rule compared to terminology used throughout the CMS Interoperability and Patient Access proposed rule and the ONC 21st Century Cures Act proposed rule, and suggested that any terminology inconsistencies be addressed and harmonized. These commenters noted that the OCR FAQ pertains to “electronic protected health information” (ePHI), and uses the term “electronic health record (EHR) system developer”, which differs from terms used in the CMS Interoperability and Patient Access and the ONC 21st Century Cures Act proposed rules.

Response: We appreciate comments regarding variance in the terminology used in OCR guidance and the CMS Interoperability and Patient Access proposed rule. Regarding the relationship between ePHI and electronic health information (EHI), we refer readers to the discussion in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). OCR guidance uses the term “electronic health record system developer” ^[18] to refer to a health IT developer that develops and maintains electronic health record systems containing PHI for a covered entity, and therefore is a business associate of those covered entities. The guidance also uses “app developer” to describe the creator of the app that is designated to receive an individual's PHI. ONC uses related terms that have a specific meaning within the context of ONC programs. For instance, ONC uses the term “health IT developer” for the purposes of the ONC Health IT Certification Program to refer to a vendor, self-developer, or other entity that presents health IT for certification or has health IT certified under the program. In addition, the ONC 21st Century Cures Act proposed rule proposed to define the term “health IT developer of certified health IT” for the purposes of implementing provisions of the Cures Act (84 FR 7510). We do not use these ONC program-specific terms in this CMS rule. We simply refer to any developer of a third-party app, of which an electronic record systems developer may be one.

Comment: One commenter requested clarification on a covered entity's liability under HIPAA if a patient transfers their health information from a covered entity's mobile access portal or application to a third-party application not covered under HIPAA.

Response: As noted above, HIPAA covered entities and business associates 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. 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 § 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, 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 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® (HL7) ^[19] Fast Healthcare Interoperability Resources® (FHIR) standard,^[20] several implementation specifications specific to FHIR, and complementary security and app registration protocols, specifically the Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Implementation Guide (IG) 1.0.0 (including mandatory support for “refresh tokens,” “Standalone Launch,” and “EHR Launch” requirements), which is a profile of the OAuth 2.0 specification, as well as the OpenID Connect Core 1.0 standard, incorporating errata set 1. A further discussion of these proposals can be found in section II.C. (84 FR 7624 through 7625) and the proposals are detailed in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639). Comments received on these proposals are summarized with our responses in section III. of this final rule.

We proposed to adopt the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.215. HHS is finalizing adoption of HL7 FHIR Release 4.0.1 as the foundational standard for APIs at 45 CFR 170.215(a)(1). Instead of the Argonaut IG and server to support exchange of the USCDI proposed at 45 CFR 170.215(a)(3) and (a)(4) (84 FR 7424), HHS is finalizing the HL7 FHIR US Core IG STU 3.1.0 at 45 CFR 170.215(a)(2). The HL7 SMART Application Launch Framework IG Release 1.0.0 was proposed at 45 CFR 170.215(a)(5) (84 FR 7424). HHS is finalizing the HL7 SMART Application Launch Framework IG Release 1.0.0 (which is a profile of the OAuth 2.0 specification), including mandatory support for the “SMART on FHIR Core Capabilities,” at 45 CFR 170.215(a)(3). HHS is finalizing as proposed adoption of OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(b), as well as adoption of version 1.0.0: STU 1 of the FHIR Bulk Data Access specification at 45 CFR 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.

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

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]

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. However, a patient may request access to an X-ray image as well. Currently, the X-ray image itself is not captured under the USCDI version 1 data set, and though the necessary FHIR resources to share this information via an API like the Patient Access API are available, use is not required under this rulemaking and so a payer may not be able to share such information via the API. Therefore, under our proposal, a HIPAA covered entity would have to share this type of information in a form and format other than the Patient Access API in order to comply with our program proposals and in keeping with the HIPAA Privacy Rule right of access.

C. Standards-Based API Proposal for MA, Medicaid, CHIP, and QHP Issuers on the FFEs

1. Introduction

We proposed to add new provisions at 42 CFR 422.119, 431.60, 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.), 457.730, 457.1233(d), and 45 CFR 156.221, that would, respectively, require each MA organization, Medicaid FFS program, Medicaid managed care plan, CHIP FFS program, CHIP managed care entity, and QHP issuer on an FFE to implement, test, and monitor a standards-based API that is accessible to third-party applications and developers. We noted that states with CHIPs were not required to operate FFS systems and that some states' CHIPs were exclusively operated by managed care entities. We did not intend to require CHIPs that do not operate a FFS program to establish an API; rather, we noted that these states may rely on each of their contracted plans, referred to throughout the CMS Interoperability and Patient Access proposed rule and this final rule as CHIP managed care entities, to set up such a system.

As discussed, the API would allow enrollees and beneficiaries of MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to exercise their HIPAA right of access to certain health information specific to their plan electronically, through the use of common technologies and without special effort. We explained how “common technologies,” for purposes of the proposal, means those that are widely used and readily available, such as computers, smartphones, or tablets.

The proposals are detailed in section III.C. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639), and comments received on these proposals and our 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 state agencies and managed care plans, state CHIP agencies and managed care entities, and QHP issuers on the FFEs. We noted that the proposal for Medicaid managed care plans, at 42 CFR 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.), would require MCOs, PIHPs, and PAHPs to comply with the regulation that we proposed for Medicaid state agencies at 42 CFR 431.60 as if that regulation applied to the Medicaid managed care plan. Similarly, we intended for CHIP managed care entities to comply with the requirements we proposed at 42 CFR 457.730 via the regulations proposed at 42 CFR 457.1233(d)(2). We proposed to structure the regulations this way to avoid ambiguity and to ensure that the API proposal would result in consistent access to information for Medicaid beneficiaries and CHIP enrollees, regardless of whether they are in a FFS delivery system administered by the state or in a managed care delivery system. We noted that CHIP currently adopts the Medicaid requirements at 42 CFR 438.242 in whole. We proposed revisions to 42 CFR 457.1233(d)(1) to indicate CHIP's continued adoption of 42 CFR 438.242(a), (b)(1) through (5), (c), (d), and (e), while we proposed specific text for CHIP managed care entities to comply with the regulations proposed at 42 CFR 457.1233(d)(2) in lieu of the proposed Medicaid revision, which we noted would add 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.). In our discussion of the specifics of the proposal and how we proposed to codify it at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221, we referred in the CMS Interoperability and Patient Access proposed rule and refer in this final rule only generally to 42 CFR 438.242(b)(5) (proposed as 438.242(b)(6); see section VI.) and 457.1233(d)(2) for this reason.

(1) Medicare Advantage

Sections 1856(b) and 1857(e) of the Social Security Act (the Act) provide CMS with the authority to add standards and requirements for MA organizations that the Secretary finds necessary and appropriate and not inconsistent with Part C of the Medicare statute. In addition, section 1852(c) of the Act requires disclosure by MA organizations of specific information about the plan, covered benefits, and the network of providers; section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information. The information required to be made 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 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), § 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 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.

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 § 438.62(b)(1)(vi) (made applicable to CHIP managed care entities through incorporation in § 457.1216), and QHP issuers on the FFEs at 45 CFR 156.221(f). Aligning the years of data available through the Patient Access API with the payer-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]

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

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 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 § 438.242(b)(6) in this final rule; see section IV. of this final rule) and for CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same timeframe, with the addition of specific provider directory information as noted in 42 CFR 438.242(b)(6)(ii) and 457.1233(d)(2)(ii). For Medicaid managed care plans and CHIP managed care entities, we proposed the provider directory information available through the API must include all information that is specified in 42 CFR 438.10(h)(1) about provider directories for disclosure to managed care enrollees. We proposed that the Patient Access API be updated with new provider directory information within 30 calendar days from when the updated information is received by the state (or the managed care plan under 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(6) in this final rule; see section IV. of this final rule) and § 457.1233(d)(2)) to be consistent with existing Medicaid managed care rules at 42 CFR 438.10(h)(3). We proposed that the API implemented by the state Medicaid agency would include the data elements specified for disclosure by Medicaid state agencies in section 1902(a)(83) of the Act; we proposed at 42 CFR 438.242(b)(6)(ii) that the Patient Access API implemented by Medicaid managed care plans would have the data elements specified for disclosure at 42 CFR 438.10(h)(1). For CHIP agencies that operate FFS systems and CHIP managed 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 the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be used as the content and vocabulary standard for the clinical data made available through the API. We intended the proposal to mean that the data required under paragraph (b)(1)(iv) be the same as the data that is specified in that content and vocabulary standard defined at 45 CFR 170.213. In effect, we proposed that at a minimum any clinical data included in the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be available through the Patient Access API if such data are maintained by the MA organization. We recognized that some MA organizations receive this information regularly, or as a part of their contracted arrangements for health services, but that not all MA organizations do. Therefore, we proposed that this requirement would apply to MA organizations, regardless of the type of MA plan offered by the MA organization, but only under circumstances when the MA organization receives and maintains this clinical data as a part of its normal operations. The proposed requirement aligned with existing regulations at 42 CFR 422.118, which required MA organizations to disclose to individual enrollees any medical records or other health or enrollment information the MA organizations maintain with respect to their enrollees. We proposed that this data be available through the API no later than one (1) business day from its receipt by the MA organization.

Similarly, the proposed regulations for Medicaid and CHIP FFS programs and managed care plans (proposed 42 CFR 431.60(b)(4) and § 457.730(b)(4)), required provision through the Patient Access API of standardized clinical data, including laboratory results, if available, no later than one (1) business day after the data are received (by the state or the managed care plan or entity). We noted that this would ensure that data provided through the API would be the most current data available, which may be critical if the data are being shared by an enrollee with a health care provider who is basing clinical decisions on these data. As noted, like proposed 42 CFR 422.119(c), the Medicaid and CHIP regulations proposed compliance with the regulations regarding the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, as the content and vocabulary standard for the clinical data available through the Patient Access API; therefore, we proposed that at a minimum any clinical data included in that USCDI standard be made available through the Patient Access API within one (1) business day of receipt. For state agencies managing Medicaid or CHIP FFS programs, we proposed that such data be made available through the API under the proposal if the state maintains clinical data. The proposed regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.) and CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same standard in terms of the scope of information and the timing of its availability through the Patient Access API; the limitation that the clinical data be maintained by the entity for it to be required to be sent via the Patient Access API would carry through to managed care plans and entities under the proposal.

Proposed 45 CFR 156.221(b)(1)(iii) would require QHP issuers on the FFEs to also make these clinical data, including laboratory results, available via the Patient Access API, with the approval and at the direction of the enrollee, if the QHP maintains such data.

We recognized not all of the entities subject to this requirement have uniform access to this type of data and sought comment on what barriers exist that would discourage them from obtaining, maintaining, and making these data available through the Patient Access API.

We summarize the public comments we received on the inclusions of clinical data, specifically the data included in the USCDI standard, via the Patient Access API and provide our responses below.

Comment: Several commenters expressed concerns that payers are typically not the original source of clinical information, including data elements that are part of the USCDI, and would not be the best source of the most accurate clinical data for patients. These commenters noted concerns with data accuracy provided by payers who are typically secondary sources of this clinical information and explained that payers do not verify this information. One commenter believed the originator should be providing the data, or that payers should be allowed to indicate the provenance of the data and where to direct questions regarding data accuracy. There was concern that the administrative burden on providers could increase due to patient inquiries and requests to correct or clarify their data.

Response: We appreciate the commenters' concerns and 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 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 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 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 § 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 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.

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

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.

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

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

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

g. Issues Related to Denial or Discontinuation of Access to the API

We believe patients have a right to their health information. However, a covered entity is not expected to tolerate unacceptable levels of risk to the PHI held by the covered entity in its systems, as determined by its own risk analysis. Accordingly, it may be appropriate for an organization to deny or terminate specific applications' connection to its API under certain circumstances in which the application poses an unacceptable risk to the PHI on its systems.

At 42 CFR 422.119(e), § 431.60(e), 438.242(b)(6) (redesignated as § 438.242(b)(5) in this rule; see section VI.), 457.730(e), 457.1233(d)(2) and 45 CFR 156.221(e) for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, respectively, we proposed to specify the circumstances under which these regulated entities, which are all HIPAA covered entities subject to HIPAA privacy and security requirements, may decline to establish or may terminate a third-party application's connection to the covered entity's API while remaining in compliance with the proposed requirement to offer patients access through standards-based APIs. We noted in the CMS Interoperability and Patient Access proposed rule that we intended for the proposal to be consistent with the HIPAA Rules, and we noted that these circumstances apply to specific applications, rather than the third party itself (84 FR 7635 through 7636).

Specifically, we proposed that a payer subject to our API proposal could deny access to the API if the payer reasonably determined that allowing that application to connect or remain connected to the API would present an unacceptable level of risk to the security of PHI on the payer's systems. We further proposed that this determination would be made consistent with the payer's HIPAA Security Rule obligations and based on objective, verifiable criteria that would be applied fairly and consistently across all applications through which enrollees seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.

Where we proposed to require access through standards-based APIs to otherwise publicly available information, such as provider directories, the entities subject to the proposal may also deny or terminate an 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 information on whether payers will be able to deny third-party access across the board for all patient queries and plans. A few commenters suggested that CMS should develop a clear process for app developers to follow in the event that a covered entity denies access to an API. A few commenters recommended that CMS include in the final rule a reference to ONC's information blocking definition and clarify that unacceptable levels of risk could be an exception to information blocking.

Response: We appreciate the commenters' concerns. As discussed in the CMS Interoperability and Patient Access proposed rule, the criteria and process for assessing unacceptable risk to a payer's system are part of the payer's responsibilities under the HIPAA Security Rule (84 FR 7635). The HIPAA Security Rule requires a covered entity to perform risk analysis as part of its security management processes.^[35] HHS makes a number of tools available to assess risk.^[36] Additional tools are available through the National Institute of Standards and Technology (NIST).^[37]

We note that this policy regarding denial or discontinuation of service refers to a payer's determination that allowing access to their API by a third party would result in risk to their system. As also noted previously, covered entities, in accordance with HIPAA privacy and security obligations, should take reasonable measures to protect data in transit, unless an individual expressly asks that the information be conveyed in an unsecure form or format (assuming the individual was warned of and accepted the risks associated with the unsecure transmission). As explained in this section above, it is the responsibility of payers to assess the risk to their system and act accordingly regardless of whether the data being accessed via the API is PHI or not. If the concern is the security of the payer's system, the type of data being transferred is not at issue. Absent an individual's instruction to disregard in-transit security, if while assessing the security of the app's connection to the API, the covered entity determines the data could be compromised in transit, the payer could discontinue or deny access in order to project the ePHI on its system. Again, 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, on behalf of, or in service to the payer.^[38] In addition, we reiterate that it is beyond our authority to regulate third parties directly. We do note that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it is considered a deceptive act to use a person's sensitive information without disclosing in product documentation how this information will be shared. We do, however, believe patient privacy and security are vitally important. As a result, we lay out an option for payers to ask a third-party app to attest to certain privacy provisions, to help make patients aware of the privacy risks associated with their choices, as detailed in the next section.

Comment: Several commenters had suggestions on how to further this proposal. A few commenters recommended that CMS could require apps to attest to certain privacy and security provisions, and if they did not, payers could deny access to the API. One commenter recommended that payers be required to vet third-party applications centrally, rather than requiring vetting for every payer and plan. A few commenters expressed concern that it will be significantly burdensome for payers and providers to vet every app that patients may choose to use in support of more central vetting. One commenter suggested that app developers should be able to proactively request to be vetted by a payer, even if the app developer has not received a request from a member.

Many commenters recommended CMS and/or HHS establish a certification, independent verification, or vetting process for third-party applications and vendors that would vet or test apps for certain functions, including privacy and security assurances. As an alternative, one commenter recommended CMS require apps generate an accounting of disclosures or join a trusted exchange network.

A few commenters requested CMS share its best practices with app authorization and access under the Blue Button 2.0 initiative. A few commenters recommended CMS, or the payers 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, we assert that impacted payers can, but are not required to, ask a third-party app to attest that:

• The app has a publicly available privacy policy, written in plain language,^[39] that has been affirmatively shared with the patient prior to the patient authorizing app access to their health information. To “affirmatively share” means that the patient had to take an action to indicate they saw the privacy policy, such as click or check a box or boxes.

• The app's privacy policy includes, at a minimum, the following important information:

++ How a patient's health information may be accessed, exchanged, or used by any person or other entity, including whether the patient's health information may be shared or sold at any time (including in the future);

++ A requirement for express consent from a patient before the patient's health information is accessed, exchanged, or used, including receiving express consent before a patient's health information is shared or sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction);

++ If an app will access any other information from a patient's device; or

++ How a patient can discontinue app access to their data and what the app's policy and process is for disposing of a patient's data once the patient has withdrawn consent.

Payers can look to industry best practices, including the CARIN Alliance's Code of Conduct ^[40] and the ONC Model Privacy 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.

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 § 438.242(b)(5) in this final rule; see section VI. of this final rule) and § 457.1233(d)(2).

The general information about the steps individuals can take to help protect the privacy and security of their health information should not be limited to, but should specifically include and emphasize the importance of understanding the privacy and security practices of any application to which they entrust their data. Information about submitting complaints should include both specific contact information for the OCR and FTC complaints processes and a brief overview, in simple and easy-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 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 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 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 care plans at 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.), and CHIP managed care entities at 42 CFR 457.1233(d)(2), we proposed that the API requirements would be applicable beginning July 1, 2020, regardless of when the managed care contract started. We noted that given the expected date of publication of the final rule, we believed July 1, 2020, would provide state Medicaid agencies and CHIP agencies that operate FFS systems, Medicaid managed care plans, and CHIP managed care entities sufficient time to implement. We solicited comment on the proposal and whether additional flexibility would be necessary to take into account the contract terms that states use for their Medicaid managed care plans.

For CHIP, we noted that we are aware that some states do not provide any benefits on a FFS basis, and we did not intend for those states to implement an API outside their managed care plans. Therefore, we proposed in 42 CFR 457.700(c) that separate CHIP agencies that provide benefits exclusively through managed care entities may meet the requirements of 42 CFR 457.730 by requiring the managed care entities to meet the requirements of 42 CFR 457.1233(d)(2) beginning July 1, 2020.

For QHP issuers on the FFEs, we proposed in 45 CFR 156.221(i) that these requirements would be applicable for plan years beginning on or after January 1, 2020. We sought comment on the timing of these requirements, and on how long issuers, particularly smaller issuers, anticipate it would take to come into compliance with these requirements.

We explained in the CMS Interoperability and Patient Access proposed rule our belief that these proposals would help to create a health care information ecosystem that allows and encourages the health care market to tailor products and services to compete for patients, thereby increasing quality, decreasing costs, and helping them live better, healthier lives. Additionally, under these proposals, physicians would be able to access information on their patient's current prescriptions and services by reviewing the information with the patient on the patient's personal device or by the patient sharing data with the provider's EHR system, which would save time during appointments and ultimately improve the quality of care delivered to beneficiaries. Most health care professionals and consumers have widespread access to the internet, providing many access points for viewing health care data over secure connections. These proposed 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 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 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 § 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 conditions payment on the timely receipt of encounters, states and managed care plans may find that a useful provision to include in their contracts. States must have a monitoring system in effect for their Medicaid managed care programs under § 438.66(b)(6), which also specifies “information systems, including encounter data reporting” as a required element. Similarly, we have certain program oversight responsibilities, such as the review of certain Medicaid and CHIP managed care contracts and all capitation rates, and will incorporate oversight of requirements in this final rule to the extent appropriate.

Comment: One commenter noted that CMS encourages the Medicaid and CHIP FFS programs to use the API as a means to exchange PHI with providers for treatment purposes, suggesting the data would be shared in advance of a patient's visit. But CMS also states that this proposal can empower the patient to decide how their health information is going to be used. This commenter requested additional information of the role CMS intends for the patient and the provider to have in the use of APIs.

Response: While we believe that a beneficiary's use of an API to obtain their health care data will play an important role in their health care, as proposed and finalized, this rule does not set standards for health care provider use of apps to obtain information from payers. As proposed and finalized in 42 CFR 431.60(a) and 457.730(a), the API permits third-party applications to retrieve a patient's data at the patient's request. A beneficiary may make the decision to obtain their health care data through such an app and share it with a provider in advance of a visit or otherwise.

Comment: One commenter requested clarity on whether the proposed rule requires all states' MMIS [Medicaid Management Information System] to make information available to patients within one (1) business day of receipt or adjudication of administrative data (adjudicated claims, encounters, provider remittance, etc.). This commenter expressed concern that these data could appear to conflict with data obtained by a patient directly from a managed care plan, causing confusion and increasing administrative overhead.

Response: We appreciate the commenter's request for additional information. Medicaid beneficiaries should not be receiving the information from both the state and managed care plan for the same service. If the beneficiary is receiving a service under the state's Medicaid FFS program, the requirements in § 431.60 apply; that is, the state is responsible for providing the specified data elements in § 431.60(b) through the API. If the beneficiary is enrolled in a managed care plan (receiving the service under the managed care plan's contract), the requirements in § 438.242(b)(5) (proposed as § 438.242(b)(6); see section VI.) apply; that is, the managed care plan is responsible for providing the specified data elements in § 431.60(b) through the API. The beneficiary should not receive data that is in conflict with other data that is made available through the API. The same is true for CHIP. If the beneficiary is in CHIP FFS, the requirements in § 457.730 apply; that is, the state is responsible for providing the specified data elements in § 457.730(b) through an API. If the beneficiary is enrolled in a managed care plan, the requirements in § 457.1233(d) apply; that is, the managed care plan is responsible for providing the specified data elements in § 457.730(b) through the API.

Comment: One commenter expressed concerns regarding the ongoing burden for state Medicaid and CHIP agencies to monitor the API, privacy and security features, and potential security risks posed by the numerous applications that may connect to the API. This commenter recommended that states be required to monitor the compliance of each of their managed care plans regarding the API requirements.

Response: We understand the commenter's concerns about burden related to the API, as well as the need for states to monitor the API for privacy and security. These requirements are specified at 42 CFR 431.60(c)(1) and (2) and 457.730(c)(1) and (2). While we understand that there is some burden for states and managed care plans related to the development and implementation of the API, we continue to believe that the benefits and potential for improved health outcomes outweigh the burden associated with these requirements. We also confirm for commenters that states are required to monitor compliance for their contracted managed care plans in regard to the API requirements under 42 CFR 438.242(b)(5) (proposed as 42 CFR 438.242(b)(6); see section VI.) and 457.1233(d). Since these requirements apply to managed care plans, states are required to include the requirements under their managed care contracts and must ensure that plans comply with the standards specified in 42 CFR 431.60 and 457.730 as if those requirements applied directly to the managed care plan.

Comment: Several commenters stated that the Patient Access API proposal 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 note that we do not have the authority to regulate vendors. While we agree that API vendors should have a role in educating consumers, states and managed care plans are the entities responsible for developing and implementing the API; therefore, we believe it is more appropriate for states and managed care plans to develop and provide the educational resources for beneficiaries.

Comment: A few commenters requested that CMS modify the rule to exempt Medicaid managed care plans. Commenters noted that Medicaid managed care plans are already operating with razor thin margins and the proposed rule will substantially increase the costs for Medicaid managed care plans. Further, commenters noted that due to the substantial increase in costs, plans may not be able to meet the MLR requirements in 42 CFR 438.8. Another commenter suggested that CMS explicitly exclude from the requirements of the rule long‐term services and supports (LTSS) plans. Some commenters also recommended that CMS exclude dental plans from the requirements in the proposed rule.

Response: We appreciate the commenters' concerns, however we are not exempting Medicaid or CHIP managed care plans, including LTSS or dental plans, from the requirements in this rule, as such an approach would not be consistent with our goal of ensuring that all beneficiaries across the health care market, including Medicaid FFS and managed care, have access to and can exchange specified health care data. We are finalizing the Patient Access API requirements for state Medicaid and CHIP agencies and managed care plans, including LTSS and dental plans. States and managed care plans must make adjudicated claims and encounter data available through the API for all 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 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.

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.

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 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 § 438.10(h)(3).

The Provider Directory API regulations finalized here require that state Medicaid and CHIP agencies, and managed care plans, make available through the API provider directory information no later than 30 calendar days after the state or managed care plan receives the provider directory information or updates to the provider directory information. We confirm that the state or managed care plan must make the provider directory information available through the API within 30 calendar days of receiving the information. This timeframe for managed care plans is consistent with the requirement in § 438.10(h)(3) for Medicaid managed care plans, which applies to CHIP managed care entities under § 457.1207.

We decline to require updates to provider directories in real-time as we do not believe that such a timeframe is operationally feasible for MA organizations, states or Medicaid and CHIP managed care plans at this time. We are finalizing our proposal that MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities update provider directory information made available through this API within 30 days of receiving a change as proposed.

Comment: Several commenters believe that, in order to increase the accuracy of provider directory data, CMS should take steps to hold providers responsible for the accuracy of their provider directory information. One commenter suggested CMS require health care providers to update their information with a centralized entity, for instance a trusted health information exchange, rather than looking to impacted payers to include these mandates in their contracts with 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 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 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.

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

Research indicates that the completeness of a patient record and the availability of up-to-date and relevant health information at the point of care can have a significant impact on patient outcomes.^[45] We noted that we believe the proposal for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to exchange the USCDI data set in particular scenarios would support improvement in care coordination by allowing for sharing of key patient health information when an enrollee requests it.

We proposed that the payers subject to this new requirement would be required to exchange, at a minimum, the data classes and elements included in the content standard proposed to be adopted at 45 CFR 170.213 in the ONC 21st Century Cures Act proposed rule, specifically, the USCDI (version 1) data 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) meeting the criteria described in section 2718(a)(2) of the PHSA for purposes of the Medical Loss Ratio (MLR) requirements for QHP issuers on an FFE,^[46] and similar standards for treatment of QIA standards applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP managed care entities under 42 CFR 457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490. An entity's MLR is generally calculated as the proportion of revenue spent on clinical services and QIA. There are several specific criteria an expense must meet, such as being designed to improve health quality and health outcomes through activities such as care coordination, in order to qualify as QIA.^[47] We requested comments related to this assumption and its implications.

We summarize the public comments we received on the payer-to-payer data exchange, as well as on whether these new activities may qualify as QIA for MLR purposes, and provide our responses.

Comment: Many commenters were very supportive of this proposal and indicated their belief that these new data exchange requirements could improve care coordination by reducing burden on both beneficiaries and providers by limiting the need for duplicative letters of medical necessity, preventing inappropriate step therapy, and reducing unnecessary utilization reviews and prior authorizations.

Response: We appreciate the commenters' support for this payer-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.

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 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 Patient Access API, as finalized in section III. of this final rule.

VI. Care Coordination Through Trusted Exchange Networks: Trust Exchange Network Requirements for MA Plans, Medicaid Managed Care Plans, CHIP Managed Care Entities, and QHP Issuers on the FFEs Provisions, and Analysis of and Responses to Public Comments

We proposed to require MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in trust networks in order to improve interoperability in these programs. We noted that we would codify this requirement in, respectively, 42 CFR 422.119(f)(2), § 438.242(b)(5), and § 457.1233(d) (which cross-references the requirements in 42 CFR 438.242(b)(5)) and 45 CFR 156.221(f). In general, payers and patients' ability to communicate between themselves and with health care providers could considerably improve patient access to data, reduce provider burden, and reduce redundant and unnecessary procedures. Trusted exchange networks allow for broader interoperability beyond one health system or point to point connections among payers, providers, and patients. Such networks establish rules of the road for interoperability, and with maturing technology, such networks are scaling interoperability and gathering momentum with participants, including several federal agencies, EHR vendors, retail pharmacy chains, large provider associations, and others.

The importance of a trusted exchange framework to such interoperability is reflected in section 4003(b) of the Cures Act, which was discussed in more detail in section I.D. of the CMS Interoperability and Patient Access proposed rule (84 FR 7612 through 7614). In section VI. of the CMS Interoperability and Patient Access proposed rule (84 FR 7642), we discussed and explained our proposal to require certain payers to participate in trusted exchange networks. A trusted exchange framework allows for the secure exchange of electronic health information with, and use of electronic health information from, other health IT. Widespread payer participation in such a framework might allow for more complete access and exchange of all electronically accessible health information for authorized use under applicable state or federal law, which we believe would lead to better use of such data. We noted that while we cannot require widespread payer participation in trust networks, we proposed to use our program authority in the MA program, Medicaid managed care program, CHIP managed care program, and QHP certification program for the FFEs to increase participation in trust networks and to bring the potential benefits of participating in such programs, including improved interoperable communication and care coordination, which result in opportunities for improved patient outcomes and burden reduction.

We proposed to require, beginning January 1, 2020, that MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs participate in a trusted exchange network. The proposal was based on our authority under: Sections 1856(b) and 1857(e) of the Act to adopt standards and contract terms for MA plans; section 1902(a)(4) of the Act to adopt methods of administration for the administration state Medicaid plans, including requirements for Medicaid managed care plans (MCOs, PIHPs, and PAHPs); section 2101(a) for CHIP managed care entities (MCOs, PIHPs, and PAHPS); and section 3001(c)(9)(F)(iii) of the PHSA and section 1311(e)(1)(B) of the Affordable Care Act for QHP issuers on an FFE. Under the proposal, and consistent with section 4003(b) of the Cures Act, participation would be required in a trusted exchange framework that met the following criteria:

(1) The trusted exchange network must be able to exchange PHI, defined at 45 CFR 160.103, in compliance with all applicable state and federal laws across jurisdictions.

(2) The trusted exchange network must be capable of connecting both inpatient EHRs and ambulatory EHRs.

(3) The trusted exchange network must support secure messaging or electronic querying by and between patients, providers, and payers.

We proposed to codify these requirements for these payers at 42 CFR 422.119(f)(2) for MA organizations, § 438.242(b)(5) for Medicaid managed care plans, § 457.1233(d)(2) for CHIP managed care entities, and 45 CFR 156.221(f) for QHPs on the FFEs.

On April 19, 2019, ONC released the draft Trusted Exchange Framework and Common Agreement (TEFCA Draft 2) for public comment.^[48] Previous commenters on draft 1 of the TEFCA, particularly payers providing comments, requested that existing trust 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.

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

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

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

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.

Based on these economic realities and first-hand experience working with the health IT industry and stakeholders, ONC concluded in the Information Blocking Congressional Report that information blocking is a serious problem and recommended that the Congress prohibit information blocking and provide penalties and enforcement mechanisms to deter these harmful practices.

MACRA became law in the same month that the Information Blocking Congressional Report was published. Section 106(b)(2)(A) of MACRA amended section 1848(o)(2)(A)(ii) of the Act to require that an eligible professional must demonstrate that he or she has not knowingly and willfully taken action (such as to disable functionality) to limit or restrict the compatibility or interoperability of certified EHR technology, as part of being a meaningful EHR user. Section 106(b)(2)(B) of MACRA made corresponding amendments to section 1886(n)(3)(A)(ii) of the Act for eligible hospitals and, by extension, under section 1814(l)(3) of the Act for CAHs. Sections 106(b)(2)(A) and (B) of MACRA provide that the manner of this demonstration is to be through a process specified by the Secretary, such as the use of an attestation. To implement these provisions, as discussed further below, we established and codified attestation requirements to support the prevention of information blocking, which consist of three statements containing specific representations about a health care provider's implementation and use of CEHRT. To review our discussion of these requirements, we refer readers to the CY 2017 Quality Payment Program final rule (81 FR 77028 through 77035).

Recent empirical and economic research further underscores the complexity of the information blocking problem and its harmful effects. 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 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 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” 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 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 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.

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.

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

Electronic patient event notifications from hospitals, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings, especially for patients at discharge. This approach has been associated with a reduction in readmissions following implementation of such notifications.^[58] We noted that the evidence cited in this section to support the use of innovative health information exchange interventions and approaches, such as the patient event notifications that we proposed to require, can be applied to various types of hospitals, including psychiatric hospitals, as well as to CAHs, as discussed below.

Patient event notifications are automated, electronic communications from the discharging provider to another facility, or to another applicable community provider as identified by the patient (such as a patient's primary care practitioner or practice group, 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), 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]

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

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.

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

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

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

We appreciate commenters concerns about patient matching challenges. This is a larger issue beyond the scope of this CoP proposal and this current rule, but we will consider this issue for future revisions and updates to the CoPs. With the continued increase in the use of electronic data in health care organizations and among providers of health care services, there has been a continued need for patient matching, or patient identity management (PIM) processes, in health care organizations, including hospitals. PIM has been defined as the ability to uniquely ascertain the identity of a patient, assign that patient's record an identifier that is unique within the organization, system, or exchange network, and match that patient's record within and between systems using a number of demographic data elements, such as the patient's first name, last name, address, and date of birth. Effective PIM supports patient identity integrity, which the National Association of Healthcare Access Management defines as accurately identifying and matching the right patient with his or her complete medical record, every time, in every provider setting.^[64] Accurate patient identity management is critical to successfully delivering the right care to the correct patients.

Capturing incorrect or incomplete data can result in critical patient care issues and risk privacy breaches. Health care organizations are more likely to have their EHR system filled with duplicate patient records and inaccurate information about their patients when they are not managing an effective PIM process. Having an ineffective PIM process will most definitely negatively impact a hospital's patient event notification system, which is one of the many reasons why a rigorous PIM process is essential to patient care as health IT moves forward. Additionally, PIM has become crucial in order to (1) enable health record document consumers to obtain trusted views of their patient subjects; (2) facilitate data exchange projects; (3) abide by the current regulations concerning patient information-related transparency, privacy, disclosure, handling, and documentation; and (4) make the most efficient use of limited health care resources by reducing redundant data collection.^[65]

Nationally recognized practices and standards for ensuring patient identity integrity have been identified by organizations such as the National Association of Healthcare Access Management, American Health Information Management Association, the Agency for Healthcare Research and Quality, and ONC. These standards include standardizing demographic data fields and internally evaluating the accuracy of patient matching within health care organizations.

We believe this presents an opportunity for the health IT industry to lead the way in developing innovative solutions to patient matching, or PIM, that can benefit all facets of the health care industry. However, appreciating the importance of accurate patient matching, CMS will continue to evaluate ways to support improved patient matching solutions.

Comment: Several commenters suggested additional provider types that should receive patient event notifications. For instance, commenters suggested health plans should be included on the list of recipients for patient event notifications, noting that this information would be valuable to plans responsible for coordinating services for beneficiaries and reducing readmissions. One commenter also recommended sending notifications to public health departments. Several commenters also requested that specific health care professionals be identified as recipients. Commenters also suggested that other caregivers such as relatives be included on the list of recipients.

Response: We appreciate commenters' suggestions about adding additional recipients for patient event notifications. While there may be other entities that could benefit from receiving patient event notifications, we believe it is more appropriate for the purposes of the CoP requirements to focus on a minimal set of recipients for notifications. This approach would not preclude hospitals from sending 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 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®-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 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 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 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 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 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 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), 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 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.

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

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

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

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

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.

4. Summary of Information Collection Burdens

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

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.

Preliminary Estimates: This section provides several detailed estimates of cost by payer (Table 7); we also account for federal matching for Medicaid and payments by the Trust Fund for Medicare Advantage organizations (Table 9); we indicate remaining burden on plans (Tables 10, 11) and how they might account for it (Table 12). However, these estimates are approximate as explained in detail below.

Data Sources for Cost by Payer: To obtain allocation of cost by payer we used the CMS public use files for MLR data, for 2016.^[69] The MLR data sets are for private insurance plans but the issuers of that private insurance in many cases also have contracts to provide MA, Medicaid, and CHIP managed care plans and report revenue, expense, and enrollment data for these plans on the private insurance MLR reporting form.

Thus, these MLR data sets omit organizations that only have Medicare or Medicaid. The data from the CMS MLR files also omit: (1) The CHIP program; and (2) state Medicaid agencies. We now discuss these omissions to assess the accuracy of using these MLR files.

CHIP: Eighty-five percent of the 194 CHIP managed care plans also offer Medicaid and hence are covered by the parent entity. We believe it reasonable that the remaining CHIP plans also have commercial offerings since it would be inefficient to operate a CHIP-only plan, as the total national CHIP enrollment is currently only about 7 million. Similarly, except for one state, CHIP programs are run through the state Medicaid agency; again, there would be one interoperability cost for the one state agency since the resulting software and systems would be used both for Medicaid and CHIP. Thus, while we are leaving out CHIP programs in this analysis since they are not in the CMS MLR files, we do not believe this materially alters the overall picture.

Medicare Advantage: We compared the CMS MLR files with the CMS Trustee Report.^[70] According to the Trustee Report (Table IV.C2), total MA revenue for 2016 was $189.1 billion. Thus, the reported amount in the CMS MLR files of $157 billion for MA represents 83 percent (157/189.1) of all MA activity reflected in the Trustee Report. Therefore, we believe the proportions obtained from these MLR files are accurate.

Medicaid: For the year for which these MLR files provide data (2016), about 70 percent of Medicaid enrollees were enrolled in Medicaid managed care.^[71] Thus, although the MLR files omit state agencies, we believe that the 70 percent of Medicaid enrollees enrolled in Medicaid managed care provides a good approximation.

Individual and small group market plans: The MLR files contain data on all commercial parent organizations whether these organizations have other lines of business, such as Medicare Advantage or Medicaid, or not. In discussing commercial plans, we account for: (A) Large group market plans; (B) small group market plans, including SHOP plans; (C) individual market Exchange plans; and (D) individual market off-Exchange plans.

• We have carved out the large employer plans since the provisions of this final rule do not apply to them, and we do not believe that parent organizations would pass on costs for individual and small group market plans to large group 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 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.

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.

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]

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

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

We next discuss in Tables 11 through 13 how payers and the federal government will deal with these extra costs. We also discuss whether the costs are excessive for existing plans as well as how new plans might deal with these costs.

The further discussion of bearing these costs is illustrated by reformulating the costs in terms of costs per enrollee (per year), which is obtained by dividing the total cost to the payer for all programs in which it participates (Medicare, Medicaid, CHIP, and Individual market plans) by its total enrollment. As an example, if a payer hypothetically spent $1 billion in a year for 100,000 enrollees then the cost per enrollee per year is $10,000 ($1 billion/100,000).

As can be seen from this example, the cost per enrollee metric facilitates comparison of costs. Since program expenditures for both Medicaid and MA are typically hundreds of millions (or billions) of dollars, concepts like burden and negligibility may not have intuitive meaning, as opposed to the costs per enrollee, which are more manageable and understandable.

To provide background, the 2018 Medicare Trust Fund Report ^[73] states that costs per enrollee are projected to be roughly $12,000—$14,000 for contract years 2020—2023 (Table IV.C3). The costs per enrollee for the Medicaid program are similarly several thousand dollars. The estimates in the 2019 Medicare Trust Fund Report are identical.^[74]

For purposes of indicating the cost per enrollee, we estimate 110.5 million enrollees will be affected by these provisions since currently there are 17.5, 66,^[75] 20,^[76] and 7 ^[77] million enrollees covered by payers in the individual market, Medicaid, MA, and separate CHIP programs, respectively. Table 11 presents costs per enrollee by program for payers after reducing total costs by federal matching, while Table 12 presents costs per enrollee by program for the federal government.

For example, the 2020 (low estimate) cost per enrollee for commercial individual market plans is $3.48 (Table 11), which is obtained by dividing the total, 2020, low-estimate, non-federal, individual market plan cost of $61 million (Table 10) by 17.5 million enrollees. (This is based on the low estimate of cost for API; the high estimate of cost would be $10.38 = $181.7 million/17.5 million).

The 2022 cost per enrollee for state Medicaid agencies after federal matching is 9 cents per enrollee (Table 11), which is obtained by dividing the total non-federal cost per program after federal matching, $6.2 million (Table 10) by 73 million enrollees (66 million in Medicaid + 7 million in CHIP). Each of these three calculations restates total spending per program per stakeholder (government, state Medicaid agencies, or Medicare Advantage plans) in terms of cost per enrollee.

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.

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

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

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-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 × $139.14). Therefore, we estimate that the total cost of reviewing this regulation is $288,020 ($834.84 × 345 reviewers).

1. Requirements for Patient Access Through APIs

To promote our commitment to interoperability, we are implementing new requirements in section III. of this final rule for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, Medicaid managed care at 42 CFR 438.242, CHIP FFS at 42 CFR 457.730, CHIP managed care at 42 CFR 457.1233, and QHP issuers on the FFEs, excluding QHP issuers offering only SADPs or only FF-SHOP plans, at 45 CFR 156.221 to implement 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 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 × 345 parent organizations) minimum estimate; an initial one-time cost of $1,576,829 per organization or state or an aggregate cost of $544 million ($1,576,829 × 345 parent organizations) primary estimate; and, an initial one-time cost of $2,365,243 per organization or organization or an aggregate $816 million ($2,365,243 × 345 parent organizations) high estimate. For a detailed discussion of the 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 × $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 MyHealthEData initiative.^[84] This government-wide initiative aims to empower patients by ensuring that they have access to their own health care data and the ability to decide how their data will be used, while keeping that information safe and secure. MyHealthEData aims to break down the barriers that prevent patients from gaining electronic access to their health care data and allow them to access that data from the device or application of their choice that will connect to a plan's API, empowering patients and taking a critical step toward interoperability and patient data exchange.

Payers should have the ability to exchange data instantly with other payers for care coordination or transitions, and with providers to facilitate more efficient care. Payers are in a unique position to provide enrollees a complete picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. We are committed to solving the issue of interoperability and achieving complete patient access in the U.S. health care system and are taking an active approach using all available policy levers and authorities available to move all participants in the health care market toward interoperability and the secure exchange of health care data. The modern internet app economy thrives on a 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.

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]

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.

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

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.

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

For additional ways to allow consumers access to their health data, we note that we did receive comments that CMS could consider allowing payers and providers to upload patient data directly to a patient portal that is owned and managed by the patient. One option would allow for HIEs and HINs to serve as a central source for patients to obtain aggregated data in a single location. While HIEs and HINs can provide patients with valuable information via a portal, research has indicated that portals have not gained widespread use by patients. According to ONC, as of 2017, 52 percent of individuals have been offered online access to their medical records by a health provider or payer. Of the 52 percent that were offered access, only half of those viewed their record.^[92] Additionally, we believe that there would be additional burden associated with using portals because providers and patients would need to access multiple portals and websites to access patient data, instead of a single app. Unlike portals that would require developers to link systems or ensure system-level compatibility, FHIR-based APIs have the ability to make data available without the need to link multiple systems or portals and would provide a patient a single-point of access to their data. Having APIs that can be accessed by third-party apps permits the patient to choose how they want to access their data, and it promotes innovation in industry to find ways to best help patients interact with their data in a way that is most meaningful and helpful to them. Additionally, we believe it would be very difficult to evaluate the cost impacts of making individual portals available via an HIE or HIN because business models and process are varied, and there is a lack of standardization in the way the information is stored and transmitted across HIEs and HINs.

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

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.

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 × $4 billion premium from issuers below the applicable MLR threshold).
• Increased premiums = Up to $17.8 million (0.0244 percent × ($77 billion total revenue−$4 billion premium from issuers below the applicable MLR threshold)).
• Total transfer from enrollees = Up to $418.8 million ($17.8 million increased premium + $1 million reduced rebate).
• Transfer per enrollee = $1.07 ($418.8 million/17.5 million commercial health insurance enrollees).

We note that the $1.07 (under a dollar per enrollee) is consistent with the results obtained in Tables 6 through 10 (with exact raw amounts by year without amortization of a large first year expense). These calculations are summarized in Table 15. The $1.07 is the low estimate of first year costs. The high estimate $1.85 per enrollee per year is obtained by replacing the low estimate cost of $272 million with $816 million.

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

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

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

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

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

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

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

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

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

PART 422—MEDICARE ADVANTAGE PROGRAM

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

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

6. Section 422.119 is added to read as follows:

7. Section 422.120 is added to read as follows:

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

PART 423—VOLUNTARY MEDICARE PERSCRIPTION DRUG BENEFIT

9. The authority citation for part 423 is revised to read as follows:

Authority: 42 U.S.C. 1302, 1306, 1395w-101 through 1395w-152, and 1395hh.

10. Section 423.910 is amended—

a. In paragraph (b)(1) introductory text by removing the phrase “monthly reporting requirement for the monthly enrollment reporting” and adding in its place the phrase “state enrollment reporting requirement described in paragraph (d) of this section”;

b. In paragraph (d) by revising the paragraph heading and by redesignating the text of paragraph (d) introductory text as paragraph (d)(1).

c. In newly redesignated paragraph (d)(1), by removing the phrase “Effective June 2005, and each subsequent month, States must submit an electronic file, in a manner specified by CMS” and by adding the following phrase “States must submit an electronic file as specified in paragraph (d)(2) of this section,”; and

d. By adding paragraph (d)(2).

The revision and addition read as follows:

PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION

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

Authority: 42 U.S.C. 1302.

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

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

PART 438—MANAGED CARE

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

Authority: 42 U.S.C. 1302.

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

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

PART 457—ALLOTMENTS AND GRANTS TO STATES

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

Authority: 42 U.S.C. 1302.

18. Section 457.700 is amended by—

a. Redesignating paragraphs (a)(1) and (2) as paragraphs (a)(2) and (3), respectively;

b. Adding paragraph (a)(1); and

c. Revising paragraph (c).

The addition and revision reads as follows:

19. Section 457.730 is added to read as follows:

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

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

PART 482—CONDITIONS OF PARTICIPATION: HOSPITALS

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.

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

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

PART 485—CONDITIONS OF PARTICIPATION: SPECIALIZED PROVIDERS

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

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

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

TITLE 45—PUBLIC WELFARE

SUBTITLE A—DEPARTMENT OF HEALTH AND HUMAN SERVICES

PART 156—HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES

27. The authority citation for part 156 continues to read as follows:

Authority: 42 U.S.C. 18021-18024, 18031-18032, 18041-18042, 18044, 18054, 18061, 18063, 18071, 18082, 26 U.S.C. 36B, and 31 U.S.C. 9701.

28. Section 156.221 is added to read as follows:

Footnotes