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

Federal RegisterMay 1, 2020

Ask Donna

What actually matters in this document.

Text

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

42 CFR Parts 406, 407, 422, 423, 431, 438, 457, 482, and 485

Office of the Secretary

45 CFR Part 156

[CMS-9115-F]

RIN 0938-AT79

Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges, and Health Care Providers

AGENCY:

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

ACTION:

Final rule.

SUMMARY:

This final rule is intended to move the health care ecosystem in the direction of interoperability, and to signal our commitment to the vision set out in the 21st Century Cures Act and Executive Order 13813 to improve the quality and accessibility of information that Americans need to make informed health care decisions, including data about health care prices and outcomes, while minimizing reporting burdens on affected health care providers and payers.

DATES:

These regulations are effective on June 30, 2020.

FOR FURTHER INFORMATION CONTACT:

Alexandra Mugge, (410) 786-4457, for issues related to interoperability, CMS health IT strategy, and technical standards.

Denise St. Clair, (410) 786-4599, for issues related API policies and related standards.

Natalie Albright, (410) 786-1671, for issues related to Medicare Advantage.

Laura Snyder, (410) 786-3198, for issues related to Medicaid.

Rebecca Zimmermann, (301) 492-4396, for issues related to Qualified Health Plans.

Meg Barry, (410) 786-1536, for issues related to CHIP.

Thomas Novak, (202) 322-7235, for issues related to trust exchange networks and payer to payer coordination.

Sharon Donovan, (410) 786-9187, for issues related to federal-state data exchange.

Daniel Riner, (410) 786-0237, for issues related to Physician Compare.

Ashley Hain, (410) 786-7603, for issues related to hospital public reporting.

Melissa Singer, (410) 786-0365, for issues related to provider directories.

CAPT Scott Cooper, USPHS, (410) 786-9465, for issues related to hospital and critical access hospital conditions of participation.

Russell Hendel, (410) 786-0329, for issues related to the Collection of Information or the Regulation Impact Analysis sections.

SUPPLEMENTARY INFORMATION:

Table of Contents

I. Background and Summary of Provisions

A. Purpose

B. Overview

C. Executive Order and MyHealthEData

D. Past Efforts

E. Challenges and Barriers to Interoperability

F. Summary of Major Provisions

II. Technical Standards Related to Interoperability Provisions, and Analysis of and Responses to Public Comments

A. Technical Approach and Standards

B. Content and Vocabulary Standards

C. Application Programming Interface (API) Standard

D. Updates to Standards

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

A. Background on Medicare Blue Button

B. Expanding the Availability of Health Information

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

IV. API Access to Published Provider Directory Data Provisions, and Analysis of and Responses to Public Comments

A. Interoperability Background and Use Cases

B. Broad API Access to Provider Directory Data

V. The Health Information Exchange and Care Coordination Across Payers: Establishing a Coordination of Care Transaction To Communicate Between Plans Provisions, and Analysis of and Responses to Public Comments

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

VII. Improving the Medicare-Medicaid Dually Eligible Experience by Increasing the Frequency of Federal-State Data Exchanges Provisions, and Analysis of and Responses to Public Comments

A. Increasing the Frequency of Federal-State Data Exchanges for Dually Eligible Individuals

B. Request for Stakeholder Input

VIII. Information Blocking Background and Public Reporting Provisions, and Analysis of and Responses to Public Comments

A. Information Blocking Background

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

C. Public Reporting and Prevention of Information Blocking for Eligible Hospitals and Critical Access Hospitals (CAHs)

IX. Provider Digital Contact Information Provisions, and Analysis of and Responses to Public Comments

A. Background

B. Public Reporting of Missing Digital Contact Information

X. Conditions of Participation for Hospitals and Critical Access Hospitals (CAHs) Provisions, and Analysis of and Responses to Public Comments

A. Background

B. Provisions for Hospitals (42 CFR 482.24(d))

C. Provisions for Psychiatric Hospitals (42 CFR 482.61(f))

D. Provisions for CAHs (42 CFR 485.638(d))

XI. Provisions of the Final Regulations

XII. Collection of Information Requirements

A. Background

B. Wage Estimates

C. Information Collection Requirements (ICRs)

XIII. Regulatory Impact Analysis

A. Statement of Need

B. Overall Impact

C. Anticipated Effects

D. Alternatives Considered

E. Accounting Statement and Table

F. Regulatory Reform Analysis Under E.O. 13771

G. Conclusion

Regulation Text

I. Background and Summary of Provisions

In the March 4, 2019

Federal Register

, we published the “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-facilitated Exchanges and Health Care Providers” proposed rule (84 FR 7610) (hereinafter referred to as the “CMS Interoperability and Patient Access proposed rule”). The proposed rule outlined our proposed policies that were intended to move the health care ecosystem in the direction of interoperability, and to signal our commitment to the vision set out in the 21st Century Cures Act and Executive Order 13813 to improve quality and accessibility of information that Americans need to make informed

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

and 75 percent of office-based clinicians

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.

Office of the National Coordinator. (2019). Hospitals' Use of Electronic Health Records Data, 2015-2017. Retrieved from

https://www.healthit.gov/sites/default/files/page/2019-04/AHAEHRUseDataBrief.pdf.

Office of the National Coordinator. (2019, December 18). Health IT Playbook, Section 1: Electronic Health Records. Retrieved from

https://www.healthit.gov/playbook/electronic-health-records/.

Powell, K. R. & Alexander, G. L. (2019). Mitigating Barriers to Interoperability in Health Care.

Online Journal of Nursing Informatics, 23

(2). Retrieved from

https://www.himss.org/library/mitigating-barriers-interoperability-health-care.

Hochman, M., Garber, J., & Robinson, E. J. (2019, August 14). Health Information Exchange After 10 Years: Time For A More Assertive, National Approach. Retrieved from

https://www.healthaffairs.org/do/10.1377/hblog20190807.475758/full/.

Payne, T. H., Lovis, C., Gutteridge, C., Pagliari, C., Natarajan, S., Yong, C., & Zhao, L. (2019). Status of health information exchange: A comparison of six countries. Journal of Global Health, 9(2). doi: 10.7189/jogh.09.020427.

We believe patients should have the ability to move from payer to payer, provider to provider, and have both their clinical and administrative information travel with them throughout their journey. When a patient receives care from a new provider, a record of their health information should be readily available to that care provider, regardless of where or by whom care was previously provided. When a patient is discharged from a hospital to a post-acute care (PAC) setting there should be no question as to how, when, or where their data will be exchanged. Likewise, when an enrollee changes payers or ages into Medicare, the enrollee should be able to have their claims history and encounter data follow so that information is not lost. As discussed in more detail in section III. of this final rule, claims and encounter data can offer a more holistic understanding of a patient's health, providing insights into everything from the frequency and types of care provided and for what reason, medication history and adherence, and the evolution and adherence to a care plan. This information can empower patients to make better decisions and inform providers to support better health outcomes.

For providers in clinical and community settings, health information technology (health IT) should be a resource, enabling providers to deliver high quality care, creating efficiencies and allowing them to access all payer and provider data for their patients. Therefore, health IT should not detract from the clinician-patient relationship, from the patient's experience of care, or from the quality of work life for physicians, nurses, other health care professionals, and social service providers. Through standards-based interoperability and information exchange, health IT has the potential to facilitate efficient, safe, high-quality care for individuals and populations.

All payers should have the ability to exchange data seamlessly with other payers for timely benefits coordination or transitions, and with health care and social service providers to facilitate more coordinated and efficient care. Payers are in a unique position to provide enrollees with a comprehensive picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. This information can contribute to better informed decision making, helping to inform the patient's choice of coverage options and care providers to more effectively manage their own health, care, and costs.

We are committed to working with stakeholders to solve the issue of interoperability and patient access in the U.S. health care system while reducing administrative burdens on providers and are taking an active approach using all available policy levers and authorities to move participants in the health care market toward interoperability and the secure and timely exchange of health care information.

C. Executive Order and MyHealthEData

On October 12, 2017, President Trump issued Executive Order 13813 to Promote Healthcare Choice and Competition Across the United States. Section 1(c)(iii) of Executive Order 13813 states that the Administration will improve access to, and the quality of, information that Americans need to make informed health care decisions, including information about health care

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

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

Office of the National Coordinator. (n.d.). U.S. Core Data for Interoperability (USCDI). Retrieved from

https://www.healthit.gov/isa/us-core-data-interoperability-uscdi.

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

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

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

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

Policies in this final rule that require a patient's action could be addressed by a patient's personal representative.

See OCR guidance regarding personal representatives at

https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/index.html

We also use terms such as “payer,” “plan,” and “issuer” in this final rule. Certain portions of this final rule are applicable to the Medicare Fee-for-Service (FFS) Program, the Medicaid FFS Program, the CHIP FFS program, Medicare Advantage (MA) organizations, Medicaid Managed Care plans (managed care organizations (MCOs), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs)), CHIP Managed Care entities (MCOs, PIHPs, and PAHPs), and QHP issuers on the FFEs. We use the term “payer” in the preamble of this final rule as an inclusive term for all these programs (and plan types in the case of plans), but we also use specific terms as applicable in sections of this final rule. Finally, we use the term “provider,” too, as an inclusive term comprising individuals, organizations, and institutions that provide health services, such as clinicians, hospitals, skilled nursing facilities, home health agencies, hospice settings, laboratories, suppliers of durable medical equipment, community based organizations, etc., as appropriate in the context used.

II. Technical Standards Related to Interoperability Provisions, and Analysis of and Responses to Public Comments

A. Technical Approach and Standards

1. Use of Health Level 7® (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,

as well as to support consumer choice of payers and providers.

See, for example, Office of the National Coordinator. (2015). Connecting Health and Care for the Nation: A Shared Nationwide Interoperability Roadmap, Final Version 1.0. Retrieved from

https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf

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

Comment:

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

Response:

We appreciate the commenter's support.

A core policy principle we aim to support across all policies in this rule is that every American should be able, without special effort or advanced technical skills, to see, obtain, and use all electronically available information that is relevant to their health, care, and choices—of plans, providers, and specific treatment options. In the proposed rule, we explained this included two types of information: personal health information that health care providers and health plans, or payers, must make available to an individual, such as their current and past medical conditions and care received; and information that is of general interest and should be widely available, such as plan provider networks, the plan's formulary, and coverage policies (84 FR 7619).

We also discussed that while many consumers today can often access their own electronic health information through patient or enrollee portals and proprietary applications made available by various providers and health plans, they must typically go through separate processes to obtain access to each system, and often need to manually aggregate information that is delivered in various, often non-standardized, formats. The complex tasks of accessing and piecing together this information can be burdensome and frustrating to consumers.

An API can be thought of as a set of commands, functions, protocols, or tools published by one software developer (“A”) that enable other software developers to create programs (applications or “apps”) that can interact with A's software without needing to know the internal workings of A's software, all while maintaining consumer privacy data standards.

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.

See

https://www.hl7.org/fhir/security.html

for information on how FHIR servers and resources integrate privacy and security protocols into the data exchange via an API.

ONC has made available a succinct, non-technical overview of APIs in context of consumers' access to their own medical information across multiple providers' EHR systems, which is available at the HealthIT.gov website at

https://www.healthit.gov/api-education-module/story_html5.html

While acknowledging the limits of our authority to require use of APIs to address our goals for interoperability and data access, we proposed to use our programmatic authority to require that a variety of data be made accessible by requiring that MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP agencies, CHIP managed care entities, and QHP issuers on the FFEs, adopt and implement “openly published,” or secure, standards-based APIs. In the CMS Interoperability and Patient Access proposed rule, we used the short form terminology, “open API”. We appreciate that this term can be misunderstood to mean “open” as in “not secure”. In actuality, an “open API” is a secure, standards-based API that has certain technical information openly published to facilitate uniform use and data sharing in a secure, standardized way. To avoid this misinterpretation, we will use the term “standards-based API” in this final rule where we used “open API” in the proposed rule. This is also in better alignment with the terminology used in the ONC 21st Century Cures Act proposed rule (84 FR 7453) and final rule (published elsewhere in this issue of the

Federal Register

). We noted that having certain data available through standards-based APIs would allow impacted enrollees to use the application of their choice to access and use their own electronic health information and other related information to manage their health. See section III.C.2.a. of the CMS Interoperability and Patient Access proposed rule for further discussion (84 FR 7629).

Much like our efforts under Medicare Blue Button 2.0, also part of the MyHealthEData initiative, which made Parts A, B, and D claims and encounter data available via an API to Medicare beneficiaries, the policies in this rule extend these benefits to even more patients. As of January 2020, over 53,000 Medicare beneficiaries have taken advantage of Blue Button. Currently, there are 55 production applications and over 2,500 developers working in the Blue Button sandbox. For more information on Blue Button 2.0 see section III. of this final rule. As we noted in the CMS Interoperability and Patient Access proposed rule, we believe that our Patient Access API, in particular, will result in claims and encounter information becoming easily accessible for the vast majority of patients enrolled with payers regulated by CMS. As finalized, these policies will apply to all MA organizations, all Medicaid and CHIP FFS programs, all types of Medicaid managed care plans (MCOs, PIHPs, and PAHPs), as well as CHIP managed care entities, and QHP issuers on the FFEs. We hope that states operating Exchanges might consider adopting similar requirements for QHPs on the State-Based Exchanges (SBEs), and that other payers in the private sector might consider voluntarily offering data accessibility of the type included in the policies being finalized here so that even more patients across the American health care system can easily have and use such information to advance their choice and participation in their health care. In this way, we hope that the example being set by CMS will raise consumers' expectations and

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

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.

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

As we discussed in our Interoperability and Patient Access proposed rule (84 FR 7621), deploying API technology would offer consumers the opportunity to access their electronic health information held by covered entities (including, but not limited to MA organizations, the Medicare Part A and B programs, the Medicaid program, CHIP, QHP issuers on the FFEs, and other health insurance issuers in the private markets), and would not lessen any such covered entity's duties under HIPAA and other laws to protect the privacy and security of information it creates, receives, maintains, or transmits, including but not limited to PHI. A covered entity implementing an API to enable individuals to access their health information must take reasonable steps to ensure an individual's information is only disclosed as permitted or required by applicable law. The entity must take greater care in configuring and maintaining the security functionalities of the API and the covered entities' electronic information systems to which it connects than would be needed if it was implementing an API simply to allow easier access to widely available public information. In accordance with the HIPAA Privacy and Security Rules, the covered entity is required to implement reasonable safeguards to protect PHI while in transit. If an individual requests their PHI in an EHR be sent to the third party by unencrypted email or in another unsecure manner, which the individual has a right to request, reasonable safeguards could include, for example, carefully checking the individual's email address for accuracy and warning the individual of risks associated with the unsecure transmission. We note that the standards-based APIs discussed in this final rule are secure methods of data exchange.

HIPAA covered entities and their business associates continue to be responsible for compliance with the HIPAA Rules, the Federal Trade Commission Act (FTC Act), and all other laws applicable to their business activities including but not limited to their handling of enrollees' PHI and other data. As we stated in the CMS Interoperability and Patient Access proposed rule (84 FR 7610), nothing proposed in that rule was intended to alter or should be construed as altering existing responsibilities to protect PHI under the HIPAA Rules or any other laws that are currently applicable.

However, we acknowledged that a number of industry stakeholders may mistakenly believe that they are responsible for determining whether an application to which an individual directs their PHI employs appropriate safeguards regarding the information it receives. In the proposed rule we discussed Office for Civil Rights (OCR) guidance that noted that covered entities are not responsible under the HIPAA Rules for the security of PHI once it has been received by a third-party application chosen by an individual (84 FR 7621 through 7622).

Further, we noted in the CMS Interoperability and Patient Access proposed rule that the HIPAA Privacy Rule

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.

More information on the Privacy Rule, including related rulemaking actions and additional interpretive guidance, is available at

https://www.hhs.gov/hipaa/for-professionals/privacy/index.html

See 45 CFR 164.524(c)(2) and (3), and 164.308(a)(1), OCR HIPAA Guidance/FAQ-2036:

https://www.hhs.gov/hipaa/for-professionals/faq/2036/can-an-individual-through-the-hipaa-right/index.html,

and OCR HIPAA Guidance/FAQ-2037:

https://www.hhs.gov/hipaa/for-professionals/faq/2037/are-there-any-limits-or-exceptions-to-the-individuals-right/index.html

As we also noted in the proposed rule (84 FR 7622), we are aware of stakeholder concerns about which protections apply to non-covered entities, such as direct-to-consumer applications. As we explained in the proposed rule, when a non-covered entity discloses an individual's confidential information in a manner or for a purpose not consistent with the privacy notice and terms of use to which the individual agreed, the FTC has authority under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)) to investigate and take action against unfair or deceptive trade practices. The FTC has applied this authority to a wide variety of entities.

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.

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.

See also cases where this authority was used, such as 2012 FTC action against Facebook (see

https://www.ftc.gov/enforcement/cases-proceedings/092-3184/facebook-inc

) and 2012 FTC action against MySpace (see

https://www.ftc.gov/enforcement/cases-proceedings/102-3058/myspace-llc-matter

See 16 CFR part 318; see also

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

We recognized that this is a complex landscape for patients, who we anticipate will want to exercise due diligence on their own behalf in reviewing the terms of service and other information about the applications they consider selecting. Therefore, we proposed specific requirements on payers to ensure enrollees have the opportunity to become more informed about how to protect their PHI, important things to consider in selecting an application, and where they can submit a complaint if they believe a HIPAA covered entity or business associate may not be in compliance with their duties under the HIPAA Rules, or if they believe they have been subjected to unfair or deceptive acts or practices related to a direct-to-consumer application's privacy practices or terms of use. A full discussion of the Enrollee and Beneficiary Resources Regarding Privacy and Security provision can be found in section III.C.2.h. of this final rule.

In some circumstances, we noted that the information that we proposed to require be made available through an API per a patient's request, under the various program-specific authorities authorizing this rulemaking, were also consistent with the enrollee's right of access for their data held by a covered entity or their business associate under the HIPAA Privacy Rule. But we also noted that some data to which an individual is entitled to access under HIPAA may not be required to be transferred through the API. For instance, when the covered entity does not hold certain information electronically. In those instances, we noted that the inability to access data via an API would in no way limit or alter responsibilities and requirements under other law (including though not limited to the HIPAA Privacy, Security, and Breach Notification Rules) that apply to the organizations that would be subject to this regulation. Even as these requirements are finalized, the organization may still be called upon to respond to individuals' request for information not available through the API, or for all of their information through means other than the API. We encouraged HIPAA covered entities and business associates to review the OCR website for resources on the individual access standard at

https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html

to ensure they understand their responsibilities.

We again encourage HIPAA covered entities and business associates to review their responsibilities under HIPAA in light of the recent decision in Ciox Health, LLC v. Azar, et al., No. 18-cv-0040 (D.D.C. January 23, 2020).

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

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.

See,

https://ecf.dcd.uscourts.gov/cgi-bin/show_public_doc?2018cv0040-51

See,

https://hds.sharecare.com/wp-content/uploads/2020/01/CiOX-Health-v.-HHS-Court-Order-3-24-2020.pdf

This decision does not affect CMS' programmatic authorities, as discussed in detail in section III. of the CMS Interoperability and Patient Access proposed rule (83 FR 7629 through 7630) and section III. of this final rule, to propose and finalize the Patient Access API for the programs specified. Additionally, the court's decision did not alter individuals' right under HIPAA to request and obtain a copy of their records. Because the goal of the Patient Access API in our programs is to give patients access to their own information for their own personal use through a third-party app, we believe these policies as adopted in this rule remain consistent with the spirit of access rights under HIPAA.

As discussed in detail below, many commenters discussed the issues of privacy and security in regard to information made available to third-party applications. Here, we summarize the public comments we received on general issues and concerns around privacy and security of a standards-based API, and provide our responses.

Comment:

A few commenters supported OCR's efforts to more clearly account for use cases, or specific situations, in which apps are used to exchange patients' electronic health information. Some commenters noted support for OCR's FAQ that specifies that covered entities are not responsible or liable for the privacy and security of PHI once it is transmitted at the individual's direction to and received by a third-party application. One commenter expressed concern that CMS and ONC proposed requirements would make the safeguards of HIPAA moot if HIPAA is not extended to third-party applications that are able under this rule to display patient data. Without extending HIPAA, the commenter fears payers and providers will be liable if the third-party misuses patient data.

Response:

We appreciate the commenters' support. We reiterate that HIPAA covered entities and business associates are responsible for meeting their HIPAA privacy and security obligations to protect patient data they

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”

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.

See Office of the National Coordinator. (n.d.). Health Information Technology. Retrieved from

https://www.hhs.gov/hipaa/for-professionals/faq/health-information-technology/index.html

Comment:

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

Response:

As noted above, HIPAA covered entities and business associates are responsible for meeting their HIPAA privacy and security obligations to protect patient data they maintain, and absent patient requests to the contrary, are obligated to take reasonable measures to protect these data in transit. Once these data are received by a third-party and no longer under the control of the covered entity or its business associate, the covered entity and business associate are not liable for the privacy and security of the PHI or any electronic health information sent. While HIPAA covered entities and their business associates may notify patients of their potential concerns regarding exchanging data with a specific third-party not covered by HIPAA, they are not required to do so, and they may not substitute their own judgment for that of the patient requesting the data be transferred.

Comment:

Several commenters recommended that CMS include a safe harbor provision in the regulatory text of this final rule to indicate that plans and providers are not responsible for the downstream privacy and security of PHI.

Response:

Regarding commenters' interest in a “safe harbor” provision for covered entities when data is transmitted to a third-party app, we do not have the authority, nor do we believe it is necessary, to incorporate these principles in a safe harbor provision under the HIPAA Privacy and Security Rules. Covered entities and business associates are not responsible for the data after the data have been received by the intended recipient. This has been taken into account in developing the requirements for the Patient Access API.

Comment:

Several commenters expressed concerns that app developers are not subject to many of the current laws protecting the privacy and security of electronic health information. Several commenters requested that HHS specify what requirements non-HIPAA covered app developers will be subject to.

Response:

We appreciate the commenters' concerns. As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7622), HIPAA protections do not extend to third-party apps (that is, software applications from entities that are not covered entities or business associates). However, the FTC has the authority to investigate and take action against unfair or deceptive trade practices under the FTC Act and the FTC Health Breach Notification Rule when a third-party app does not adhere to the stated privacy policy. We have shared these comments with the FTC. State laws may provide additional protections as well.

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)

Fast Healthcare Interoperability Resources® (FHIR) standard,

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.

Health Level Seven International® (HL7) is a not-for-profit, ANSI-accredited standards development organization (SDO) focused on developing consensus standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. Learn more at “About HL7” web page, last accessed 06/27/2018.

FHIR Overview. (n.d.). Retrieved from https://www.hl7.org/fhir/overview.html

We proposed to adopt the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the

Federal Register

) at 45 CFR 170.215. HHS is finalizing adoption of HL7 FHIR Release 4.0.1 as the foundational standard for APIs at 45 CFR 170.215(a)(1). Instead of the Argonaut IG and server to support exchange of the USCDI proposed at 45 CFR 170.215(a)(3) and (a)(4) (84 FR 7424), HHS is finalizing the HL7 FHIR US Core IG STU 3.1.0 at 45 CFR 170.215(a)(2). The HL7 SMART Application Launch Framework IG Release 1.0.0 was proposed at 45 CFR 170.215(a)(5) (84 FR 7424). HHS is finalizing the HL7 SMART Application Launch Framework IG Release 1.0.0 (which is a profile of the OAuth 2.0 specification), including mandatory support for the “SMART on FHIR Core Capabilities,” at 45 CFR 170.215(a)(3). HHS is finalizing as proposed adoption of OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(b), as well as adoption of version 1.0.0: STU 1 of the FHIR Bulk Data Access specification at 45 CFR

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

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

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.

For more information on the USCDI, see

https://www.healthit.gov/USCDI

For more information on FHIR, see

https://www.hl7.org/fhir/overview.html

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

A. Background on Medicare Blue Button

As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7626), we are committed to advancing interoperability, putting patients at the center of their health care, and ensuring they have simple and easy access, without special effort, to their health information. With the establishment of the initial Medicare Blue Button® 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.

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.

To review a list of apps currently available to Blue Button 2.0 users, visit

https://

www.medicare.gov/manage-your-health/medicares-blue-button-blue-button-20/blue-button-apps

B. Expanding the Availability of Health Information

1. Patient Benefits of Information Access

As discussed in the CMS Interoperability and Patient Access proposed rule, we believe there are numerous benefits associated with individuals having simple and easy access to their health care data under a standard that is widely used. Whereas EHR data are frequently locked in closed, disparate health systems, care and treatment information in the form of claims and encounter data is comprehensively combined in a patient's claims and billing history. Claims and encounter data, used in conjunction with EHR data, can offer a broader and more holistic understanding of an individual's interactions with the health care system than EHR data alone. As one example, inconsistent benefit utilization patterns in an individual's claims data, such as a failure to fill a prescription or receive recommended therapies, can indicate that the individual has had difficulty financing a treatment regimen and may require less expensive prescription drugs or therapies, additional explanation about the severity of their condition, or other types of assistance. Identifying and finding opportunities to address the individual's non-adherence to a care plan are critical to keeping people with chronic conditions healthy and engaged so they can avoid hospitalizations. While a health plan can use claims and encounter data to help it identify which enrollees could benefit from an assessment of why they are not filling their prescriptions or who might be at risk for particular problems, putting this information into the hands of the individual's chosen care provider—such as the doctor or nurse practitioner prescribing the medications or the pharmacist who fills the prescriptions—helps them to engage the patient in shared decision making that can help address some of the reasons the individual might not be willing or able to take medications as prescribed. By authorizing their providers to access the same information through a standards-based API, individuals can further facilitate communication with their care teams. Enabling the provider to integrate claims and encounter information with EHR data gives the provider the ability to use the combined information, with relevant clinical decision support tools, as part of normal care delivery in a less burdensome way, leading to improved care. This may be particularly important during times of system surge, an event that generates a large and sudden demand for health services, for example, when access to such information may help to inform patient triage, transfer, and care decisions.

Further, we noted that we believe patients who have immediate electronic access to their health information are empowered to make more informed decisions when discussing their health needs with providers, or when considering changing to a different health plan. We discussed that currently not all beneficiaries enrolled in MA plans have immediate electronic access to their claims and encounter data and those who do have it, cannot easily share it with providers or others. The same is true of Medicaid beneficiaries and CHIP enrollees, whether enrolled in FFS or managed care programs, and enrollees in QHPs on the FFEs. As industries outside of health care continue to integrate multiple sources of data to understand and predict their consumers' needs, we believe it is important to position MA organizations, Medicaid and CHIP FFS programs and managed care entities, and QHP issuers on the FFEs to do the same to encourage competition, innovation, and value.

We noted that CMS has programmatic authority over MA organizations, Medicaid programs (both FFS and managed care), CHIP (both FFS and managed care), and QHP issuers on the FFEs. We proposed to leverage CMS authority to make claims and encounter data available through APIs as a means to further access for patients in these programs along with other plan data (such as provider directory data) as detailed in sections III.C. and IV. of the CMS Interoperability and Patient Access proposed rule. For a complete discussion of these proposals, see the proposed rule (84 FR 7626 through 7640).

2. Alignment with the HIPAA Right of Access

As discussed in section II. of this final rule, the recent decision in

Ciox Health, LLC

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

that is maintained by or on behalf of a covered entity (a health plan or covered health care provider

) in a designated record set.

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.

See

45 CFR 160.103, definition of protected health information.

The third type of HIPAA covered entity, a health care clearinghouse, is not subject to the same requirements as other covered entities with respect to the right of access.

See

45 CFR 164.500(b).

See

45 CFR 164.501, definition of designated record set.

For more information, see

https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html

We explained that software applications using the Patient Access API proposed at 42 CFR 422.119, 431.60, 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.), 457.730, and 457.1233(d)(2), and 45 CFR 156.221, and further discussed below, would provide an additional mechanism through which the individuals who so choose could exercise the HIPAA right of access to their PHI, by giving them a simple and easy electronic way to request, receive, and share data they want and need, including with a designated third party. However, as discussed in section II. of the CMS Interoperability and Patient Access proposed rule (84 FR 7621 through 7622), due to limitations in the current availability of interoperability standards for some types of health information, or data, we noted the API requirement may not be sufficient to support access to all of the PHI subject to the HIPAA right of access because a patient's PHI may not all be transferable through the API. For instance, we proposed to require payers to make claims and encounter data as well as a specified set of clinical data (that is, clinical data maintained by the applicable payer in the form of the USCDI version 1 data set) available through the Patient Access API.

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.

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.

Pew Research Center. (2019, June 12). Retrieved from

https://www.pewinternet.org/fact-sheet/mobile.

Ryan, C. (2018). Computer and internet Use in the United States: 2016 (American Community Survey Reports, ACS-39). Retrieved from

https://www.census.gov/content/dam/Census/library/publications/2018/acs/ACS-39.pdf.

People have a right to be able to manage their health information in this way should they choose. We appreciate that not everyone is comfortable with, has access to, or uses electronic applications in making health care decisions. Such patients will maintain the same access that they have to their personal health information today. This regulation does not change any existing patient information rights. This regulation simply adds new options to ensure patients have the information they need, when, and how they need it.

Comment:

Several commenters indicated concerns over what they believe would be a costly implementation. A few commenters questioned who would be required to bear the costs of implementation and maintenance of the APIs, with one commenter requesting CMS explicitly permit payers to charge patients and other third-party partners for the costs of API implementation and maintenance. In contrast, a few commenters recommended that payers should not be allowed to charge patients to access their information through APIs. A few commenters requested CMS provide federal grant funding to support payers in implementing the proposed APIs.

Response:

We appreciate the commenters' concerns and recommendations. As discussed in section XIII. of this final rule, we are providing updated cost estimates for implementing and maintaining the Patient Access API, moving from a single point estimate to a range—including a low, primary, and high estimate—to better take into account the many factors that impact the cost of implementation. We have revised our original estimate of $788,414 per payer, to a primary estimate of $1,576,829 per payer, increasing our original estimate by a factor of 2 to account for additional information that was provided by commenters, which we still believe is relatively minimal in relation to the overall budget of these impacted payers. We have included a low estimate of $718,414.40 per organization, and a high estimate of $2,365,243 per organization. We refer readers to sections XII. and XIII. of this final rule for a detailed discussion of our revised cost estimates.

We acknowledge that payers may pass these costs to patients via increased premiums. In this way, patients could absorb the cost of the API. However, we note the costs of “premiums” for MA, Medicaid, and CHIP enrollees are primarily borne by the government, as are some premium costs for enrollees of QHP issuers on the FFEs who receive premium tax credits. We believe that the benefits created by the Patient Access API outweigh the costs to patients if payers choose to increase premiums as a result.

At this time, we are not able to offer support for the implementation of this policy through federal grant funding. Regarding costs for Medicaid managed care plans—since the Patient Access API requirements must be contractual obligations under the Medicaid managed care contract—the state must include these costs in the development of a plan's capitation rates. These capitation rates would be matched at the state's medical assistance match rate. State Medicaid agency implementation costs would be shared by the state and federal government, based on the relevant level of Federal Financial Participation, which is 50 percent for general administrative costs and 90 percent for system development costs.

Comment:

A few commenters described concerns with the maturity of APIs for data exchange, as well as the fact that implementation of FHIR-based APIs is so new in health care, and expressed that they believed there were challenges with meeting the proposed requirement given the newness of the needed standards, particularly regarding standardizing the required data elements and vocabularies. Several

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

This text is long and has been trimmed here. Open the source document for the complete record.

This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.