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, 25510-25640 [2020-05050]

Download as PDF 25510 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 FederallyFacilitated Exchanges, and Health Care Providers Centers for Medicare & Medicaid Services (CMS), HHS. ACTION: Final rule. AGENCY: 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. SUMMARY: 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. DATES: VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 FederalState Data Exchanges for Dually Eligible Individuals PO 00000 Frm 00002 Fmt 4701 Sfmt 4700 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 Federallyfacilitated 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 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 Federallyfacilitated 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 caring for them are often presented with an incomplete picture of their health and care as pieces of their information are stored in various, unconnected systems and do not accompany the patient to every care setting. Although more than 95 percent of hospitals 1 and 75 percent of office-based clinicians 2 are utilizing certified health IT, challenges remain in creating a comprehensive, longitudinal view of a patient’s health history.3 4 5 This siloed nature of health care data prevents physicians, pharmaceutical companies, manufacturers, and payers from accessing and interpreting important data sets, instead, encouraging each group to make decisions based upon a part of the information rather than the whole. Without an enforced standard of interoperability, data exchanges are often complicated and time-consuming. We believe patients should have the ability to move from payer to payer, provider to provider, and have both their clinical and administrative information travel with them throughout their journey. When a patient receives care from a new provider, a record of their health information should be readily available to that care provider, regardless of where or by whom care was previously provided. When a patient is discharged from a hospital to a post-acute care (PAC) setting there should be no question as to how, when, or where their data will be exchanged. Likewise, when an enrollee changes payers or ages into Medicare, the enrollee should be able to have their claims history and encounter data follow so that information is not lost. As discussed in more detail in section III. of this final rule, claims and encounter data can offer a more holistic understanding of a 1 Office of the National Coordinator. (2019). Hospitals’ Use of Electronic Health Records Data, 2015–2017. Retrieved from https:// www.healthit.gov/sites/default/files/page/2019-04/ AHAEHRUseDataBrief.pdf. 2 Office of the National Coordinator. (2019, December 18). Health IT Playbook, Section 1: Electronic Health Records. Retrieved from https:// www.healthit.gov/playbook/electronic-healthrecords/. 3 Powell, K. R. & Alexander, G. L. (2019). Mitigating Barriers to Interoperability in Health Care. Online Journal of Nursing Informatics, 23(2). Retrieved from https://www.himss.org/library/ mitigating-barriers-interoperability-health-care. 4 Hochman, M., Garber, J., & Robinson, E. J. (2019, August 14). Health Information Exchange After 10 Years: Time For A More Assertive, National Approach. Retrieved from https:// www.healthaffairs.org/do/10.1377/hblog20190807. 475758/full/. 5 Payne, T. H., Lovis, C., Gutteridge, C., Pagliari, C., Natarajan, S., Yong, C., & Zhao, L. (2019). Status of health information exchange: A comparison of six countries. Journal of Global Health, 9(2). doi: 10.7189/jogh.09.020427. PO 00000 Frm 00003 Fmt 4701 Sfmt 4700 25511 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 E:\FR\FM\01MYR2.SGM 01MYR2 25512 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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. PO 00000 Frm 00004 Fmt 4701 Sfmt 4700 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. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 thirdparty 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 publicfacing digital endpoint on the payer’s website to ensure public discovery and access. At a minimum, these payers must make available via the Provider Directory API provider names, addresses, phone numbers, and specialties. For MA organizations that offer MA–PD plans, they must also make available, at a minimum, pharmacy directory data, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as ‘‘retail pharmacy’’). All directory information must be made available to current and prospective enrollees and the public through the Provider Directory API within 30 calendar days of a payer receiving provider directory information or an update to the provider directory information. The Provider Directory API is being finalized at 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. Here we are finalizing that access to the published Provider Directory API must be fully implemented by January 1, 2021. We do strongly encourage payers to make their Provider Directory API public as soon as possible to make and show progress toward meeting all the API requirements being finalized in this rule. We are finalizing our proposal, with certain modifications as detailed in section V. of this final rule, to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to coordinate care between payers by exchanging, at a minimum, the data elements specified in the current content and vocabulary standard finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.213 (currently the ‘‘United States Core Data for Interoperability’’ (USCDI) version 1 6). This payer-to-payer data exchange 6 Office of the National Coordinator. (n.d.). U.S. Core Data for Interoperability (USCDI). Retrieved from https://www.healthit.gov/isa/us-core-datainteroperability-uscdi. PO 00000 Frm 00005 Fmt 4701 Sfmt 4700 25513 requires these payers, as finalized at 42 CFR 422.119(f) for MA organizations, at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care plans (and by extension under § 457.1216 CHIP managed care entities), and at 45 CFR 156.221(f) for QHP issuers on the FFEs, to send, at a current or former enrollee’s request, specific information they maintain with a date of service on or after January 1, 2016 to any other payer identified by the current enrollee or former enrollee. This is consistent with the Patient Access API detailed in section III. of this final rule. We are also finalizing a provision that a payer is only obligated to share data received from another payer under this regulation in the electronic form and format it was received. This is intended to reduce burden on payers. We are finalizing that this payer-to-payer data exchange must be fully implemented by January 1, 2022. In response to comments discussed more fully below, we are not finalizing our proposal to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in a trusted exchange network given the concerns commenters raised regarding the need for a mature Trusted Exchange Framework and Common Agreement (TEFCA) to be in place first, and appreciating that work on TEFCA is ongoing at this time. We are finalizing the requirements that all states participate in daily exchange of buy-in data, which includes both sending data to CMS and receiving responses from CMS daily, and that all states submit the MMA file data to CMS daily by April 1, 2022 in accordance with 42 CFR 406.26, 407.40, and 423.910, respectively, as proposed. These requirements will improve the experience of dually eligible individuals by improving the ability of providers and payers to coordinate eligibility, enrollment, benefits, and/or care for this population. We are finalizing our proposal to include an indicator on Physician Compare for the eligible clinicians and groups that submit a ‘‘no’’ response to any of the three prevention of information blocking statements for MIPS. In the event that these statements are left blank, the attestations will be considered incomplete, and we will not include an indicator on Physician Compare. The indicator will be posted on Physician Compare, either on the profile pages or in the downloadable database, starting with the 2019 performance period data available for public reporting starting in late 2020. E:\FR\FM\01MYR2.SGM 01MYR2 25514 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 postacute care services providers and VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 suppliers, primary care practitioners and groups, and other practitioners and groups identified by the patient as primarily responsible for his or her care, and who or which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes. We are establishing that this policy will be applicable 12 months after publication of this rule for hospitals, including psychiatric hospitals, and CAHs to allow for adequate and additional time for these institutions, especially small and/or rural hospitals as well as CAHs, to come into compliance with the new requirements. Finally, we note that we included two RFIs in the proposed rule: one related to interoperability and health IT adoption in PAC settings and one related to the role of patient matching in interoperability and improved patient care. We thank commenters for the insights shared on these two topics. We are reviewing these comments and will take them into consideration for potential future rulemaking. Throughout this final rule, we refer to terms such as ‘‘patient,’’ ‘‘consumer,’’ ‘‘beneficiary,’’ ‘‘enrollee,’’ and ‘‘individual.’’ We note that every reader of this final rule is a patient and has or will receive medical care at some point in their life. In this final rule, we use the term ‘‘patient’’ as an inclusive term, but because we have historically referred to patients using the other terms noted above in our regulations, we use specific terms as applicable in sections of this final rule to refer to individuals covered under the health care programs that CMS administers and regulates. We also note that when we discuss patients, we acknowledge a patient’s personal representative. Per the HIPAA privacy regulations at 45 CFR 164.502(g), a personal representative is someone authorized under state or other applicable law to act on behalf of the individual in making health care related decisions (such as a parent, guardian, or person with a medical power of attorney).7 Policies in this final rule that require a patient’s action could be addressed by a patient’s personal representative. We also use terms such as ‘‘payer,’’ ‘‘plan,’’ and ‘‘issuer’’ in this final rule. Certain portions of this final rule are applicable to the Medicare Fee-forService (FFS) Program, the Medicaid FFS Program, the CHIP FFS program, Medicare Advantage (MA) 7 See OCR guidance regarding personal representatives at https://www.hhs.gov/hipaa/forprofessionals/faq/2069/under-hipaa-when-can-afamily-member/. PO 00000 Frm 00006 Fmt 4701 Sfmt 4700 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 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations proposed rule (84 FR 7619), we will use the PHSA definition of ‘‘interoperability’’ for the purposes of this final rule. We believe the PHSA definition of ‘‘interoperability’’ is useful as a foundational reference for our approach to advancing the interoperability and exchange of electronic health information for individuals throughout the United States, and across the entire spectrum of provider types and care settings with which health insurance issuers and administrators need to efficiently exchange multiple types of relevant data. We noted the PHSA definition of ‘‘interoperability’’ is not limited to a specific program or initiative, but rather can be applied to all activities under the title of the PHSA that establishes ONC’s responsibilities to support and shape the health information ecosystem, including the exchange infrastructure for the U.S. health care system as a whole. The PHSA definition is also consistent with HHS’s vision and strategy for achieving a health information ecosystem within which all individuals, their personal representatives, their health care providers, and their payers are able to send, receive, find, and use electronic health information in a manner that is appropriate, secure, timely, and reliable to support the health and wellness of individuals through informed, shared decision-making,8 as well as to support consumer choice of payers and providers. We summarize the public comment we received on use of the PHSA definition of ‘‘interoperability’’ and provide our response. Comment: One commenter specifically supported the use of the PHSA definition of ‘‘interoperability’’. Response: We appreciate the commenter’s support. A core policy principle we aim to support across all policies in this rule is that every American should be able, without special effort or advanced technical skills, to see, obtain, and use all electronically available information that is relevant to their health, care, and choices—of plans, providers, and specific treatment options. In the proposed rule, we explained this included two types of information: personal health information that health care providers and health plans, or payers, must make available to an 8 See, for example, Office of the National Coordinator. (2015). Connecting Health and Care for the Nation: A Shared Nationwide Interoperability Roadmap, Final Version 1.0. Retrieved from https:// www.healthit.gov/sites/default/files/hieinteroperability/nationwide-interoperabilityroadmap-final-version-1.0.pdf. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 individual, such as their current and past medical conditions and care received; and information that is of general interest and should be widely available, such as plan provider networks, the plan’s formulary, and coverage policies (84 FR 7619). We also discussed that while many consumers today can often access their own electronic health information through patient or enrollee portals and proprietary applications made available by various providers and health plans, they must typically go through separate processes to obtain access to each system, and often need to manually aggregate information that is delivered in various, often non-standardized, formats. The complex tasks of accessing and piecing together this information can be burdensome and frustrating to consumers. An API can be thought of as a set of commands, functions, protocols, or tools published by one software developer (‘‘A’’) that enable other software developers to create programs (applications or ‘‘apps’’) that can interact with A’s software without needing to know the internal workings of A’s software, all while maintaining consumer privacy data standards.9 This is how API technology enables the seamless user experiences associated with applications familiar from other aspects of many consumers’ daily lives, such as travel and personal finance. Standardized, transparent, and procompetitive API technology can enable similar benefits to consumers of health care services.10 While acknowledging the limits of our authority to require use of APIs to address our goals for interoperability and data access, we proposed to use our programmatic authority to require that a variety of data be made accessible by requiring that MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP agencies, CHIP managed care entities, and QHP issuers on the FFEs, adopt and implement ‘‘openly published,’’ or secure, standards-based APIs. In the CMS Interoperability and Patient Access proposed rule, we used the short form terminology, ‘‘open API’’. We appreciate that this term can be misunderstood to mean ‘‘open’’ as in ‘‘not secure’’. In 9 See https://www.hl7.org/fhir/security.html for information on how FHIR servers and resources integrate privacy and security protocols into the data exchange via an API. 10 ONC has made available a succinct, nontechnical 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. PO 00000 Frm 00007 Fmt 4701 Sfmt 4700 25515 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 E:\FR\FM\01MYR2.SGM 01MYR2 25516 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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: VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 • 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 procompetitive manner. In that section of the CMS Interoperability and Patient Access proposed rule, we discussed these concepts generally and how they were applicable in the health care context for all payers, and explained how these were relevant to our specific proposals, which are discussed in detail in section III. of this final rule. To revisit this full discussion, see the proposed rule (84 FR 7620 through 7621). We did not receive comments on this general discussion. Any comments on specific proposals that refer to these three attributes are discussed in this final rule in the context of the specific proposals. 2. Privacy and Security Concerns in the Context of APIs As we noted in the CMS Interoperability and Patient Access proposed rule, HHS has received a wide range of stakeholder feedback on privacy and security issues in response to prior proposals 11 about policies related to APIs that would allow consumers to use an app of their choosing to access protected health information (PHI) held by or on behalf of a HIPAA covered entity. Such feedback included concerns about potential security risks to PHI created by an API connecting to third-party applications and the implications of an individual’s data being shared with these third-party apps at the direction of the individual. As we discussed in our Interoperability and Patient Access proposed rule (84 FR 7621), deploying API technology would offer consumers the opportunity to access their electronic health information held by covered entities (including, but not limited to MA organizations, the Medicare Part A and B programs, the Medicaid program, CHIP, QHP issuers on the FFEs, and other health insurance issuers in the private markets), and would not lessen any such covered entity’s duties under HIPAA and other laws to protect the privacy and security of information it creates, receives, maintains, or transmits, including but not limited to PHI. A covered entity implementing an API to enable individuals to access their health information must take reasonable steps 11 For instance, see discussion of stakeholder comments in the 2015 Edition final rule at 80 FR 62676. PO 00000 Frm 00008 Fmt 4701 Sfmt 4700 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 thirdparty application chosen by an individual (84 FR 7621 through 7622). Further, we noted in the CMS Interoperability and Patient Access proposed rule that the HIPAA Privacy Rule 12 established the individual’s right of access, including a right to inspect 12 More information on the Privacy Rule, including related rulemaking actions and additional interpretive guidance, is available at https:// www.hhs.gov/hipaa/for-professionals/privacy/ index.html. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations and/or receive a copy of PHI held in designated record sets by covered entities and their business associates as detailed at 45 CFR 164.524. We specifically noted in the proposed rule that OCR had indicated in regulations and guidance, that an individual could exercise their right of access by requesting that their information be sent to a third party.13 As we also noted in the proposed rule (84 FR 7622), we are aware of stakeholder concerns about which protections apply to non-covered entities, such as direct-to-consumer applications. As we explained in the proposed rule, when a non–covered entity discloses an individual’s confidential information in a manner or for a purpose not consistent with the privacy notice and terms of use to which the individual agreed, the FTC has authority under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)) to investigate and take action against unfair or deceptive trade practices. The FTC has applied this authority to a wide variety of entities.14 The FTC also enforces the FTC Health Breach Notification Rule, which applies to certain types of entities, including vendors of personal health records and third-party service providers, that fall outside of the scope of HIPAA, and therefore, are not subject to the HIPAA Breach Notification Rule.15 This FTC Health Breach Notification Rule explains the process and steps third parties must follow when they discover a breach of identifiable personal health record information they maintain. Any violation of this Rule is enforced by the FTC as an unfair or deceptive act or practice under the FTC Act. We recognized that this is a complex landscape for patients, who we anticipate will want to exercise due diligence on their own behalf in reviewing the terms of service and other information about the applications they consider selecting. Therefore, we proposed specific requirements on payers to ensure enrollees have the 13 See 45 CFR 164.524(c)(2) and (3), and 164.308(a)(1), OCR HIPAA Guidance/FAQ–2036: https://www.hhs.gov/hipaa/for-professionals/faq/ 2036/can-an-individual-through-the-hipaa-right/ index.html, and OCR HIPAA Guidance/FAQ–2037: https://www.hhs.gov/hipaa/for-professionals/faq/ 2037/are-there-any-limits-or-exceptions-to-theindividuals-right/. 14 See also cases where this authority was used, such as 2012 FTC action against Facebook (see https://www.ftc.gov/enforcement/casesproceedings/092-3184/facebook-inc) and 2012 FTC action against MySpace (see https://www.ftc.gov/ enforcement/cases-proceedings/102-3058/myspacellc-matter). 15 See 16 CFR part 318; see also https:// www.healthit.gov/sites/default/files/non-covered_ entities_report_june_17_2016.pdf. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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/ 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. 18cv-0040 (D.D.C. January 23, 2020).16 The court order vacates a portion of the HIPAA Privacy Rule related to the individual right of access ‘‘insofar as it expands the HITECH Act’s third-party directive beyond requests for a copy of 16 See, https://ecf.dcd.uscourts.gov/cgi-bin/show_ public_doc?2018cv0040-51. PO 00000 Frm 00009 Fmt 4701 Sfmt 4700 25517 an electronic health record with respect to [protected health information] of an individual . . . in an electronic format.’’ 17 Generally, the court order vacates a portion of the HIPAA Privacy Rule that provides an individual the right to direct a covered entity to send protected health information that is not in an EHR to a third party identified by the individual. This decision does not affect CMS’ programmatic authorities, as discussed in detail in section III. of the CMS Interoperability and Patient Access proposed rule (83 FR 7629 through 7630) and section III. of this final rule, to propose and finalize the Patient Access API for the programs specified. Additionally, the court’s decision did not alter individuals’ right under HIPAA to request and obtain a copy of their records. Because the goal of the Patient Access API in our programs is to give patients access to their own information for their own personal use through a third-party app, we believe these policies as adopted in this rule remain consistent with the spirit of access rights under HIPAA. As discussed in detail below, many commenters discussed the issues of privacy and security in regard to information made available to thirdparty applications. Here, we summarize the public comments we received on general issues and concerns around privacy and security of a standardsbased 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 17 See, https://hds.sharecare.com/wp-content/ uploads/2020/01/CiOX-Health-v.-HHS-Court-Order3-24-2020.pdf. E:\FR\FM\01MYR2.SGM 01MYR2 25518 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Interoperability and Patient Access proposed rule and the ONC 21st Century Cures Act proposed rule, and suggested that any terminology inconsistencies be addressed and harmonized. These commenters noted that the OCR FAQ pertains to ‘‘electronic protected health information’’ (ePHI), and uses the term ‘‘electronic health record (EHR) system developer’’, which differs from terms used in the CMS Interoperability and Patient Access and the ONC 21st Century Cures Act proposed rules. Response: We appreciate comments regarding variance in the terminology used in OCR guidance and the CMS Interoperability and Patient Access proposed rule. Regarding the relationship between ePHI and electronic health information (EHI), we refer readers to the discussion in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). OCR guidance uses the term ‘‘electronic health record system developer’’ 18 to refer to a health IT developer that develops and maintains electronic health record systems containing PHI for a covered entity, and therefore is a business associate of those covered entities. The guidance also uses ‘‘app developer’’ to describe the creator of the app that is designated to receive an individual’s PHI. ONC uses related terms that have a specific meaning within the context of ONC programs. For instance, ONC uses the term ‘‘health IT developer’’ for the purposes of the ONC Health IT Certification Program to refer to a vendor, self-developer, or other entity that presents health IT for certification or has health IT certified under the program. In addition, the ONC 21st Century Cures Act proposed rule proposed to define the term ‘‘health IT developer of certified health IT’’ for the purposes of implementing provisions of the Cures Act (84 FR 7510). We do not use these ONC program-specific terms in this CMS rule. We simply refer to any developer of a third-party app, of which an electronic record systems developer may be one. Comment: One commenter requested clarification on a covered entity’s liability under HIPAA if a patient transfers their health information from a covered entity’s mobile access portal or application to a third-party application not covered under HIPAA. Response: As noted above, HIPAA covered entities and business associates 18 See Office of the National Coordinator. (n.d.). Health Information Technology. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/ health-information-technology/. PO 00000 Frm 00010 Fmt 4701 Sfmt 4700 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 thirdparty 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 thirdparty 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 thirdparty 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. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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-andGuidance/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 thirdparty. 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 thirdparty 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, VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 patientcentered 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-tounderstand, non-technical, consumerfriendly 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-andGuidance/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 PO 00000 Frm 00011 Fmt 4701 Sfmt 4700 25519 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 redocument 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, E:\FR\FM\01MYR2.SGM 01MYR2 25520 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 PO 00000 Frm 00012 Fmt 4701 Sfmt 4700 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 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 consensusbased. 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 standardsbased 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 PO 00000 Frm 00013 Fmt 4701 Sfmt 4700 25521 adoption at 45 CFR 170.215 as finalized (84 FR 7589). By requiring compliance with 45 CFR 170.215, we proposed to require use of the foundational Health Level 7® (HL7) 19 Fast Healthcare Interoperability Resources® (FHIR) standard,20 several implementation specifications specific to FHIR, and complementary security and app registration protocols, specifically the Substitutable Medical Applications, Reusable Technologies (SMART) Application Launch Implementation Guide (IG) 1.0.0 (including mandatory support for ‘‘refresh tokens,’’ ‘‘Standalone Launch,’’ and ‘‘EHR Launch’’ requirements), which is a profile of the OAuth 2.0 specification, as well as the OpenID Connect Core 1.0 standard, incorporating errata set 1. A further discussion of these proposals can be found in section II.C. (84 FR 7624 through 7625) and the proposals are detailed in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639). Comments received on these proposals are summarized with our responses in section III. of this final rule. We proposed to adopt the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.215. HHS is finalizing adoption of HL7 FHIR Release 4.0.1 as the foundational standard for APIs at 45 CFR 170.215(a)(1). Instead of the Argonaut IG and server to support exchange of the USCDI proposed at 45 CFR 170.215(a)(3) and (a)(4) (84 FR 7424), HHS is finalizing the HL7 FHIR US Core IG STU 3.1.0 at 45 CFR 170.215(a)(2). The HL7 SMART Application Launch Framework IG Release 1.0.0 was proposed at 45 CFR 170.215(a)(5) (84 FR 7424). HHS is finalizing the HL7 SMART Application Launch Framework IG Release 1.0.0 (which is a profile of the OAuth 2.0 specification), including mandatory support for the ‘‘SMART on FHIR Core Capabilities,’’ at 45 CFR 170.215(a)(3). HHS is finalizing as proposed adoption of OpenID Connect Core 1.0, incorporating errata set 1 at 45 CFR 170.215(b), as well as adoption of version 1.0.0: STU 1 of the FHIR Bulk Data Access specification at 45 CFR 19 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. 20 FHIR Overview. (n.d.). Retrieved from https:// www.hl7.org/fhir/overview.html. E:\FR\FM\01MYR2.SGM 01MYR2 25522 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 170.215(a)(4). HHS is not finalizing the adoption of FHIR Release 2 or FHIR Release 3, API Resource Collection in Health (ARCH) Version 1, or the HL7 Consent2Share FHIR Consent Profile Design that were proposed at 45 CFR 170.215(a)(1), (c)(1), (a)(2), or (c)(2), respectively (84 FR 7424). For a full discussion, see the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). The content and vocabulary standards and technical standards finalized by HHS in the ONC 21st Century Cures Act final rule provide the foundation needed to support implementation of the policies as proposed and now finalized in this rule. D. Updates to Standards In addition to efforts to align standards across HHS, we recognized in the proposed rule that while we must codify in regulation a specific version of each standard, the need for continually evolving standards development has historically outpaced our ability to amend regulatory text. To address how standards development can outpace our rulemaking schedule, we proposed in section III.C.2.b. of the CMS Interoperability and Patient Access proposed rule (84 FR 7630 through 7631) that regulated entities may use updated versions of required standards if use of the updated version is required by other applicable law. In addition, under certain circumstances, we proposed to allow use of an updated version of a standard if the standard is not prohibited under other applicable law. For content and vocabulary standards at 45 CFR part 162 or 42 CFR 423.160, we proposed to allow the use of an updated version of the content or vocabulary standard adopted under rulemaking, unless the use of the updated version of the standard: Is prohibited for entities regulated by that part or the program under that section; Is prohibited by the Secretary for purposes of these policies or for use in ONC’s Health IT Certification Program; or is precluded by other applicable law. We remind readers that other applicable law includes statutes and regulations that govern the specific entity. For the content and vocabulary standards proposed by ONC for HHS adoption at 45 CFR 170.213 (84 FR 7589) (currently, USCDI version 1),21 as well as for API technical standards proposed by ONC for HHS adoption at 45 CFR 170.215 (84 FR 7589) (including HL7 FHIR and other standards and implementation 21 For more information on the USCDI, see https://www.healthit.gov/USCDI. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7626), we are committed to advancing interoperability, putting patients at the center of their health care, and ensuring they have simple and easy access, without special effort, to their health information. With the establishment of the initial Medicare Blue Button® service in 2010, Medicare beneficiaries became able to download their Part A, Part B, and Part D health care claims and encounter data through MyMedicare.gov in either PDF or text format. While the original Blue Button effort was a first step toward liberating patient health information, we recognized that significant opportunities remain to modernize access to that health information and the ability to share health information across the health ecosystem. We believe that moving to a system in which patients have access to and use of their health information will empower them to make better informed decisions about their health care. Additionally, interoperability, and the ability for health information systems and software applications to communicate, exchange, and interpret health information in a usable and readable format, is vital to improving health care. Allowing access to health information only through PDF and text formats limit the utility of and the ability to effectively share the health information. Medicare Blue Button 2.0 is a new, modernized version of the original Blue Button service. It enables beneficiaries to access their Medicare Parts A, B, and D claims and encounter data and share that electronic health information through an Application Programming Interface (API) with applications, services, and research programs they select. As discussed in section II.A. of the CMS Interoperability and Patient Access proposed rule (see 84 FR 7618 through 7623), API technology allows software from different developers to connect with one another and exchange electronic health information in electronic formats that can be more easily compiled and leveraged by patients and their caregivers. Beneficiaries may also select third-party applications to compile and leverage their electronic health information to help them manage their health and engage in a more fully informed way in their health care. Today, Blue Button 2.0 contains 4 years of Medicare Part A, B, and D data for 53 million Medicare beneficiaries. These data are available to patients to help them make more informed decisions. Beneficiaries dictate how their data can be used and by whom, with identity and authorization controlled through MyMedicare.gov. Medicare beneficiaries can authorize sharing their information with an application using their MyMedicare.gov account information. Beneficiaries authorize each application, service, or research program they wish to share their data with individually. A beneficiary can go back to MyMedicare.gov at any time and change the way an application uses their information. Using Blue Button 2.0, beneficiaries can access their health information; share it with doctors, caregivers, or anyone they choose; and get help managing and improving their health through a wide range of apps and other computer-based services. Blue Button 2.0 is an optional service— beneficiaries choose the apps and services they want to use. Today, Medicare beneficiaries using Blue Button 2.0 can connect with apps that keep track of tests and services they need and receive reminders, track their medical claims, make appointments and send messages to their doctors, get personalized information about their symptoms and medical conditions, find health and drug plans, keep track of their medical notes and questions, and connect to research projects.23 These are 22 For more information on FHIR, see https:// www.hl7.org/fhir/overview.html. 23 To review a list of apps currently available to Blue Button 2.0 users, visit https:// guides (IGs) as discussed above),22 we proposed to allow the use of an updated version of a standard adopted by HHS, provided such updated version has been approved by the National Coordinator through the Standards Version Advancement Process described in the ONC 21st Century Cures Act proposed rule (84 FR 7424), as finalized. A further discussion of these proposals can be found in section II.D. of the CMS Interoperability and Patient Access proposed rule (84 FR 7625 through 7626). These proposals are also detailed in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639), and comments received on these proposals are summarized with our responses in section III. of this final rule. III. Provisions of Patient Access Through APIs, and Analysis of and Responses to Public Comments A. Background on Medicare Blue Button PO 00000 Frm 00014 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations just some of the ways Blue Button 2.0 is using a standards-based, FHIRenabled API to lead the charge and unleash the power of health data. B. Expanding the Availability of Health Information 1. Patient Benefits of Information Access As discussed in the CMS Interoperability and Patient Access proposed rule, we believe there are numerous benefits associated with individuals having simple and easy access to their health care data under a standard that is widely used. Whereas EHR data are frequently locked in closed, disparate health systems, care and treatment information in the form of claims and encounter data is comprehensively combined in a patient’s claims and billing history. Claims and encounter data, used in conjunction with EHR data, can offer a broader and more holistic understanding of an individual’s interactions with the health care system than EHR data alone. As one example, inconsistent benefit utilization patterns in an individual’s claims data, such as a failure to fill a prescription or receive recommended therapies, can indicate that the individual has had difficulty financing a treatment regimen and may require less expensive prescription drugs or therapies, additional explanation about the severity of their condition, or other types of assistance. Identifying and finding opportunities to address the individual’s non-adherence to a care plan are critical to keeping people with chronic conditions healthy and engaged so they can avoid hospitalizations. While a health plan can use claims and encounter data to help it identify which enrollees could benefit from an assessment of why they are not filling their prescriptions or who might be at risk for particular problems, putting this information into the hands of the individual’s chosen care provider—such as the doctor or nurse practitioner prescribing the medications or the pharmacist who fills the prescriptions—helps them to engage the patient in shared decision making that can help address some of the reasons the individual might not be willing or able to take medications as prescribed. By authorizing their providers to access the same information through a standards-based API, individuals can further facilitate communication with their care teams. Enabling the provider to integrate claims and encounter information with EHR data gives the www.medicare.gov/manage-your-health/medicaresblue-button-blue-button-20/blue-button-apps. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 provider the ability to use the combined information, with relevant clinical decision support tools, as part of normal care delivery in a less burdensome way, leading to improved care. This may be particularly important during times of system surge, an event that generates a large and sudden demand for health services, for example, when access to such information may help to inform patient triage, transfer, and care decisions. Further, we noted that we believe patients who have immediate electronic access to their health information are empowered to make more informed decisions when discussing their health needs with providers, or when considering changing to a different health plan. We discussed that currently not all beneficiaries enrolled in MA plans have immediate electronic access to their claims and encounter data and those who do have it, cannot easily share it with providers or others. The same is true of Medicaid beneficiaries and CHIP enrollees, whether enrolled in FFS or managed care programs, and enrollees in QHPs on the FFEs. As industries outside of health care continue to integrate multiple sources of data to understand and predict their consumers’ needs, we believe it is important to position MA organizations, Medicaid and CHIP FFS programs and managed care entities, and QHP issuers on the FFEs to do the same to encourage competition, innovation, and value. We noted that CMS has programmatic authority over MA organizations, Medicaid programs (both FFS and managed care), CHIP (both FFS and managed care), and QHP issuers on the FFEs. We proposed to leverage CMS authority to make claims and encounter data available through APIs as a means to further access for patients in these programs along with other plan data (such as provider directory data) as detailed in sections III.C. and IV. of the CMS Interoperability and Patient Access proposed rule. For a complete discussion of these proposals, see the proposed rule (84 FR 7626 through 7640). 2. Alignment with the HIPAA Right of Access As discussed in section II. of this final rule, the recent decision in Ciox Health, LLC v. Azar, et al. vacates a portion of the HIPAA Privacy Rule that provides an individual the right to direct a covered entity to send protected health information that is not in an EHR to a third party identified by the individual. It does not alter a patient’s right to request access to their records. In addition, the decision does not affect PO 00000 Frm 00015 Fmt 4701 Sfmt 4700 25523 CMS’ programmatic authorities, as discussed in detail in section III. of the CMS Interoperability and Patient Access proposed rule (83 FR 7629 through 7630) and later in this section of this final rule. Prior to this decision, in the CMS Interoperability and Patient Access proposed rule, we discussed that the HIPAA Privacy Rule, at 45 CFR 164.524, provides that an individual has a right of access to inspect and obtain a copy of their PHI 24 that is maintained by or on behalf of a covered entity (a health plan or covered health care provider 25) in a designated record set.26 It was noted that, at that time, a covered entity was required to provide the access in any readily producible form and format requested by the individual, and that the right of access also includes individual’s right to direct a covered entity to transmit PHI directly to a third party the individual designates to receive it.27 We explained that software applications using the Patient Access API proposed at 42 CFR 422.119, 431.60, 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.), 457.730, and 457.1233(d)(2), and 45 CFR 156.221, and further discussed below, would provide an additional mechanism through which the individuals who so choose could exercise the HIPAA right of access to their PHI, by giving them a simple and easy electronic way to request, receive, and share data they want and need, including with a designated third party. However, as discussed in section II. of the CMS Interoperability and Patient Access proposed rule (84 FR 7621 through 7622), due to limitations in the current availability of interoperability standards for some types of health information, or data, we noted the API requirement may not be sufficient to support access to all of the PHI subject to the HIPAA right of access because a patient’s PHI may not all be transferable through the API. For instance, we proposed to require payers to make claims and encounter data as well as a specified set of clinical data (that is, clinical data maintained by the applicable payer in the form of the USCDI version 1 data set) available through the Patient Access API. 24 See 45 CFR 160.103, definition of protected health information. 25 The third type of HIPAA covered entity, a health care clearinghouse, is not subject to the same requirements as other covered entities with respect to the right of access. See 45 CFR 164.500(b). 26 See 45 CFR 164.501, definition of designated record set. 27 For more information, see https:// www.hhs.gov/hipaa/for-professionals/privacy/ guidance/access/. E:\FR\FM\01MYR2.SGM 01MYR2 25524 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 PO 00000 Frm 00016 Fmt 4701 Sfmt 4700 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 standardsbased 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 standardsbased 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 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 PO 00000 Frm 00017 Fmt 4701 Sfmt 4700 25525 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 E:\FR\FM\01MYR2.SGM 01MYR2 25526 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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, lowincome 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 PO 00000 Frm 00018 Fmt 4701 Sfmt 4700 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 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 PO 00000 Frm 00019 Fmt 4701 Sfmt 4700 25527 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 standardsbased 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. E:\FR\FM\01MYR2.SGM 01MYR2 25528 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Response: We appreciate the commenters’ suggestions. The proposed rule did not specify a historical lookback 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-topayer 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 care decisions. Several commenters were concerned that certain patient groups, such as those with low technology access and/or health literacy, would not make use of electronic applications for making health care decisions. A few commenters recommended CMS not limit patient access to health information through apps alone, especially for populations with low technology access and/or literacy. Response: We appreciate the commenters’ concerns. However, more and more Americans are using portable technology like smart phones and tablets to conduct a myriad of daily activities. Approximately 81 percent of U.S. adults reported owning a smartphone and 52 percent reported owning a tablet computer in 2019.28 An American Community Survey Report from the U.S. Census Bureau reported that in 2016, 82 percent of households reported an internet subscription and 83 percent reported a cellular data plan.29 People have a right to be able to manage their health information in this way should they choose. We appreciate that not everyone is comfortable with, has access to, or uses electronic applications in making health care decisions. Such patients will maintain the same access that they have to their personal health information today. This regulation does not change any existing patient information rights. This regulation simply adds new options to ensure patients have the information they need, when, and how they need it. Comment: Several commenters indicated concerns over what they believe would be a costly implementation. A few commenters questioned who would be required to bear the costs of implementation and maintenance of the APIs, with one commenter requesting CMS explicitly permit payers to charge patients and other third-party partners for the costs of API implementation and maintenance. In contrast, a few commenters recommended that payers should not be allowed to charge patients to access their information through APIs. A few commenters requested CMS provide federal grant funding to support payers in implementing the proposed APIs. Response: We appreciate the commenters’ concerns and 28 Pew Research Center. (2019, June 12). Retrieved from https://www.pewinternet.org/factsheet/mobile. 29 Ryan, C. (2018). Computer and internet Use in the United States: 2016 (American Community Survey Reports, ACS–39). Retrieved from https:// www.census.gov/content/dam/Census/library/ publications/2018/acs/ACS-39.pdf. PO 00000 Frm 00020 Fmt 4701 Sfmt 4700 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 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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-andGuidance/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, VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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-andGuidance/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 PO 00000 Frm 00021 Fmt 4701 Sfmt 4700 25529 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 E:\FR\FM\01MYR2.SGM 01MYR2 25530 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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. PO 00000 Frm 00022 Fmt 4701 Sfmt 4700 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 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 standardsbased 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 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 such as those maintained by X12. One commenter noted that these HIPAA transaction standards were more accessible to payers to represent clinical and case management data. This commenter suggested CMS should precisely identify the specific claims data layout of the HIPAA Administrative Simplification transaction standards that payers would be required to generate and receive because the HIPAA Administrative Simplification transaction standards layout varies by payer type. However, one commenter noted that patients may not find information available through HIPAA standards useful. A few commenters suggested CMS should assist affected payers with meeting the technical implementation requirements by explaining the intent of the required use of the HIPAA Administrative Simplification transaction content and vocabulary standards with the HL7 FHIR standards. Commenters recommended that CMS review and reconcile differences between existing standards that are required for Medicaid programs, in particular. For example, commenters suggested identifying situations in which CMS has required the use of X12 Electronic Data Interchange standards and reconciling these requirements with the adoption of the HL7 FHIR standards. Response: We appreciate the commenters’ concerns and recommendations. The policies included in this final rule are not intended to alter HIPAA requirements in any way, and these electronic data exchanges are not defined transactions under HIPAA regulations, therefore there is no need to reconcile use of X12 and the HL7 FHIR standards required in this rule. We appreciate that the HIPAA standards are more known to many payers at this time; however, we believe the use of FHIR standards is important for advancing the policies finalized in this rule, which require the transmission of information beyond what is available using X12 standards alone. At the same time, as discussed in the proposed rule, we are requiring entities subject to this rule to use HIPAA content and vocabulary standards at 45 CFR part 162 where required by other applicable law, or where such standards are the only available standards for the data type or element (84 FR 7623). The use of the FHIR standard supports making this information available through an API. This is not in conflict with the use of other standards to represent the data being transmitted through the API. Instead, the FHIR standard can be thought of as defining an envelope, PO 00000 Frm 00023 Fmt 4701 Sfmt 4700 25531 while the contents of the envelope can be represented by different content and vocabulary standards used in conjunction with FHIR to make data interoperable and accessible. For additional information on FHIR standards, we direct commenters to the ONC’s 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). To support implementation of the policies included in this final rule, we are providing a link to specific implementation guides and reference implementations that provide valuable guidance to further support sharing the needed data using the required standards: https:// www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/ index. As discussed in section II.A.3. of the CMS Interoperability and Patient Access proposed rule (84 FR 7622 through 7623), we recognized that while we must codify in regulation a specific version of each standard, the need for continually evolving standards development has historically outpaced our ability to amend regulations. To address how standards development can outpace our rulemaking schedule, we offered several proposals. We proposed that regulated entities may use an updated version of a standard where required by other applicable law. We also proposed that regulated entities may use an updated version of the standard where not prohibited by other applicable law, under certain circumstances. We summarize the public comments we received on our approach to allowing voluntary adoption of updated standards and provide our responses. Comment: A few commenters expressed support for the proposal to allow plans to upgrade to newer versions of standards supporting data classes in the USCDI as standards evolve. A few commenters specifically supported the proposal to align with ONC’s proposed Standards Version Advancement Process and allow payers to adopt newer versions of FHIR once approved for use by HHS. A few commenters were concerned with backwards compatibility if implementers—payers and developers— are permitted to move to new versions of standards, while a few commenters supported the proposed requirement to maintain compatibility with adopted standards while upgrading to newer standards. One commenter expressed concerns with difficulty tracking compliance with standards as they move through different versions, generally, and requested CMS establish E:\FR\FM\01MYR2.SGM 01MYR2 25532 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations a versioning system or identifier for consistency and transparency. A few commenters specifically discussed the NCPDP SCRIPT standard; however, these comments are out of scope for this rulemaking because this rulemaking does not apply to ePrescribing transactions. Response: We appreciate the commenters’ input. We are adopting the ability to use updated standards. As proposed, implementers will need to ensure that use of the updated (or newer) standard (instead of the standard specified in the applicable regulation) does not disrupt an end user’s ability to access the data available through the API, which should address concerns raised around backward compatibility. Specifically, we are finalizing at 42 CFR 422.119(c)(4) for MA organizations, 42 CFR 431.60(c)(4) for Medicaid FFS programs, 42 CFR 438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(c)(4) for CHIP FFS programs, 42 CFR 457.1233(d)(1) for CHIP managed care entities, and 45 CFR 156.221(c)(4) for QHP issuers on the FFEs permission to use an updated version of standards adopted at 45 CFR 170.215, 45 CFR 170.213, 45 CFR part 162, or 42 CFR 423.160, subject to the conditions proposed. As long as use of the updated version of a standard is not otherwise prohibited, permitted in accordance with the conditions described, and, does not disrupt an end user’s ability to access the data per the requirements of the API, it may be used. Regarding the recommendation for CMS to establish a versioning system or identifier, we appreciate this recommendation and will review the suggestion for future consideration. c. Data Required To Be Available Through the Standards-Based API & Timeframes for Data Availability We proposed the content that must be accessible for each enrollee of an entity subject to the standards-based API proposal as set out at proposed paragraph (b) of 42 CFR 422.119, 431.60, and 457.730, and 45 CFR 156.221; as noted previously, the regulations for Medicaid managed care plans and CHIP managed care entities cross-reference and incorporate the regulations we proposed for Medicaid and CHIP FFS programs. We noted that the types of content proposed would represent the minimum threshold for compliance; at their discretion, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs would have the option to use the API required by the proposed rule to make additional types of health VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 information or plan information available, exceeding these minimum requirements. We requested comment on the data proposed to be made available as detailed in the subsections below. We proposed that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs permit third-party applications to retrieve, with the approval and at the direction of an enrollee, certain specific data: Adjudicated claims data, including provider remittances and beneficiary or enrollee cost-sharing data; encounter data from capitated providers; and clinical data, including laboratory results (but only if maintained by the payer). (1) Patient Claims and Encounter Data We proposed that the adjudicated claims data required to be provided include approved and denied claims. Under the proposal, adjudicated claims data includes that for which the plan has made an initial payment decision even when the period during which an enrollee can file an appeal is still in effect, or when the enrollee has filed an appeal and is awaiting a decision on that appeal. Such appeal decisions might be called reconsiderations, reconsidered decisions, organization determinations, or use other terms, but the term is not relevant. We specifically requested comments from plans regarding the feasibility of including such claims data, including any possible timing issues. The proposal included timeframe requirements for making these various categories of data available through the standards-based API. For MA organizations, proposed 42 CFR 422.119(b)(1)(i), (ii), and (b)(2)(i) would require standards-based API access to all claims activity pertaining to standardized adjudicated claims (including cost, specifically provider remittances and enrollee cost-sharing) and standardized encounter data for benefits covered by the plan (that is, Medicare Part A and Part B items and services, Part D prescription drugs if covered by the MA plan, and any supplemental benefits) no later than one (1) business day after a claim is processed or the encounter data are received by the MA organization. We used the terms ‘‘adjudicated’’ and ‘‘processed’’ interchangeably in this context. For Medicaid state agencies and managed care plans, we proposed that standardized claims data and encounter data would be required (specifically at PO 00000 Frm 00024 Fmt 4701 Sfmt 4700 42 CFR 431.60(b)(1) and (2)) through the API no later than one (1) business day after the claim is processed or the data are received. For State Medicaid agencies in connection with the FFS program, we explained that the API would have to include all claims data concerning adjudicated claims and encounter data from providers (other than MCOs, PIHPs or PAHPs) that are paid using capitated payments. The requirement for Medicaid managed care plans to provide encounter data is specified, in conjunction with the incorporation of the Medicaid FFS requirement into the Medicaid managed care regulations, at 42 CFR 438.242(b)(6)(i) (finalized as § 438.242(b)(5)(i) in this rule; see section VI.). Similarly, we proposed that encounter data that Medicaid managed care plans must make available through the API would include any data from subcontractors and providers compensated by the managed care plan on the basis of capitation payments, such as behavioral health organizations, dental management organizations, and pharmacy benefit managers. The API for Medicaid managed care plans would have to include all claims and, therefore, encounter data that would be included regardless if it is adjudicated or generated by the managed care plan itself, a subcontractor, or a provider compensated on the basis of capitation payments. All data would need to be obtained in a timely manner to comply with these proposed requirements that these types of data be available through the API no later than one (1) business data after a claim is processed or the encounter data are received. For CHIP agencies and managed care entities, access to standardized claims data and encounter data would be required (specifically at 42 CFR 457.730(b)(1) and (2)) through the API no later than one (1) business day after the claim is processed or the encounter data are received. The proposal for CHIP state agencies (regarding FFS programs) and CHIP managed care entities is identical to the proposal for Medicaid state agencies (regarding FFS programs) and Medicaid managed care plans. For QHP issuers on the FFEs, the proposed regulation at 45 CFR 156.221(b) would require claims and encounter data to be available through the Patient Access API no later than one (1) business day after adjudication or receipt, respectively. Specifically regarding QHP issuers on the FFEs, at 45 CFR 156.221(b)(1)(i) and (ii), we proposed to require that QHP issuers participating on the FFEs make available through the API standardized data concerning adjudicated claims (including cost) and standardized E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations encounter data. Under proposed paragraph (b)(1)(i), we proposed that QHP issuers on the FFEs would be required to make available standardized data concerning adjudicated claim, provider remittance, and enrollee costsharing data through the API within one (1) business day after the claim is processed. Under proposed paragraph (b)(1)(ii), we proposed that QHP issuers on the FFEs would be required to provide standardized encounter data through the API no later than one (1) business day after the data are received by the issuer. As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7632 through 7633), the proposed timeframe—making the data available to the third-party app with the approval and at the direction of the patient through the API no later than one (1) business day after processing a claim or receiving encounter data—would ensure that data provided to the third-party app, and ultimately the patient, through the API would be the most current data available. Providing the most current data may be critical if the data are provided by an enrollee to his or her health care provider to use in making clinical decisions. As proposed, the claims and encounter data to be disclosed would include information such as enrollee identifiers, dates of service, payment information (provider remittance if applicable and available), and enrollee cost-sharing. Our proposal did not exclude any elements from the claims and encounter—or the clinical data—required to be made available through the Patient Access API. The ability for enrollees—created and facilitated by the API required under the proposal—to access this information electronically would make it easier for them to take it with them as they move from payer to payer or among providers across the care continuum. Regarding the provision of encounter data through the API no later than one (1) business day after receiving the data, we noted that the proposal would mean that a payer must rely on capitated providers submitting their encounter data in a timely manner to ensure that patients receive a timely and complete set of data. To the extent providers do not submit in a timely manner, there would be a delay in patients having access to their data. We recommended that MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs that would need this information in order to meet the proposed API requirements in a timely manner should consider whether their contracts with VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 network providers should include timing requirements for the submission of encounter data and claims so that the payer can comply with the API requirements more timely. For Medicaid and CHIP FFS programs, we encouraged states to consider other means to ensure that necessary encounter data from providers is also provided on a timely basis. We summarize the public comments we received on making claims and encounter data available via the Patient Access API and provide our responses. Comment: A few commenters expressed concern that there are no named or mature industry FHIR-based standards available for representing and exchanging claims information. One commenter requested CMS only require a specific subset of claims information that would be most useful to patients, suggesting patient name, diagnoses codes, procedure codes, drug codes, service date(s), provider of service, and out-of-pocket costs. Response: We appreciate the commenters’ concerns and recommendations. We have been working with industry partners to ensure the necessary FHIR standard and implementation guides as specified at 45 CFR 170.215 are now available to ensure that payers can fully implement sharing claims data via a FHIR-based API, as we are finalizing our proposal to have payers impacted by this rule make claims and encounter data available via the standards-based Patient Access API no later than one (1) business day after claims processing or encounter data receipt. To further support payers as they work to build the Patient Access API and map claims and encounter data for exchange via a FHIR-based API, in partnership with industry, we have worked to ensure relevant implementation guides and reference implementations are available. A link to specific implementation guides and reference implementations for claims and encounter data have been produced and tested and can be found at https:// www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/ index. Though not mandatory, using these publicly available resources will reduce payer burden as they work to prepare their data for exchange via a FHIR-based API. We also appreciate the recommendation to only include a subset of claims information. However, we believe it is important for patients to have all of their claims information in order to facilitate informed decision making. Patients have a right to their claims data. While that information currently can be obtained through PO 00000 Frm 00025 Fmt 4701 Sfmt 4700 25533 various means, we decline to require that only a subset of the available claims information be available through the Patient Access API. Comment: One commenter noted that health plans cannot verify the accuracy of all information contained in a claim. This commenter requested CMS should state that these policies do not mandate that payers audit and correct all information furnished by health care providers beyond what is currently necessary for existing rules, regulations, and internal business purposes. Response: We appreciate the commenter’s concern. We agree that our regulations, as proposed and as finalized, for this Patient Access API do not require that payers do any additional audit or review of the claims they receive beyond current practices. To the extent that payers wish to, they may include a disclaimer or other notice to enrollees as part of the API to indicate this. Such a disclaimer would be permissible under these regulations. Comment: A few commenters recommended that further standardization work be done to improve the accuracy of the claims data field that identifies the attributed health care provider administering services. If this data element is accurate, commenters note it will help ensure patients are reaching out to the right clinician. Commenters believe this could reduce confusion when patients seek clarification or request amendments to their health information. Response: We appreciate the commenters’ recommendation and will evaluate potential future options to address this concern through our work with HL7 and other industry partners. We do note, however, this seems to be a data accuracy issue and not a standardization issue. That said, we do strongly encourage all payers and providers to work together to ensure the accuracy of these and all data. Comment: A few commenters were concerned that claims data were not accurate representations of clinical findings and therefore not valuable in assisting patients in making health care decisions. These commenters expressed fears that patients may misinterpret claims information for health care decision-making when claims data serve a payment use case. Response: We appreciate the commenters’ concerns. We do note, however, that there is valuable information on the claim relevant to a patient’s care and care history that can inform health care decision-making. For instance, this information provides patients with the names of the providers they have visited, when they visited E:\FR\FM\01MYR2.SGM 01MYR2 25534 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations certain providers for certain medical needs, when tests or procedures were conducted, and more information about these tests and procedures. This information alone is very useful to patients as they plan and discuss future care with their providers. Also, in the absence of clinical data (which is required to be provided through the Patient Access API under this rule only if the payer maintains such data), claims and encounter data provide a basis of information for patients to work with and get value from. Comment: One commenter sought clarification on the scope of Medicaidcovered services to which the requirement to make claims and encounter data available through an API applies. This commenter recommended that CMS specify that this requirement to make claims and encounter data available does not apply to long-term care waiver services, such as in-home care, meal preparation or delivery, and transportation. The commenter stated that providing claims and encounter data for these services through the API would be cumbersome for a variety of reasons including the fact that long-term care waiver services tend to have frequent (daily or weekly) utilization by each participant, which would result in an unwieldly number of claims or encounters being provided through the API for each individual. Response: We confirm that under 42 CFR 431.60(b)(1) and (2), 42 CFR 457.730(b)(1) and (2), 42 CFR 438.242(b)(5) (proposed as § 438.242(b)(6); see section VI.), and 42 CFR 457.1233(d), states and managed care plans must make adjudicated claims and encounter data available through the API for all Medicaid- or CHIP-covered services, including longterm services and supports (LTSS). This requirement extends to in-home care, transportation services, and all other Medicaid- or CHIP-covered services for which a claim or encounter is generated and adjudicated. We do not believe the number of claims generated by LTSS will make the data unwieldy or unusable by the beneficiary. We believe that the benefits of providing claims and encounter data to beneficiaries so they can make better health care decisions and know which providers have been paid for providing services to them is no less important simply because it is a frequently provided service. Some beneficiaries may find having such data on frequently rendered services more important since billing with such frequency may make it more prone to errors, fraud, waste, and abuse. Comment: Several commenters were concerned with the appropriateness of VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 sharing certain claims information, particularly specific costs such as negotiated rates that commenters believed could reveal trade secrets or be considered proprietary information. These commenters requested CMS ensure that confidential, proprietary cost information is excluded from the proposed requirements. One commenter believed that disclosure of information such as negotiated rates would lead to higher health prices in the industry and other anticompetitive behavior. Specifically, this commenter gave the example where dominant payers in a geographic or other market use this price information to deter competitors from entering into value-based payment arrangements. One commenter also requested that third-party apps be prohibited from aggregating or using any cost information for purposes other than transfer of the data to the patient. Response: We note that we take our obligations seriously to protect from disclosure information that is protected under current law. We also affirm our commitment to safeguarding data protected by law from inappropriate use and disclosure. We understand the concerns raised around sharing cost data. We appreciate the commenters’ concerns, however we reiterate that we are committed to giving patients access to their health information, and we believe the benefits of making this information available to patients through third-party apps outweigh these concerns. It is critical for patients to better understand health care costs and be able to plan and budget as well as possible. Having cost information, which is already accessible to patients, available to them in a more easy-tounderstand presentation would allow patients to get the maximum benefit from this information. If a patient uses an app to view their health information that does not clearly indicate it will not use this cost data for any other purpose, there is a chance the app could aggregate or otherwise analyze the data, assuming the single app has access to enough patient data in a given market or patients who use a particular payer or plan, to make such an analysis possible. Appreciating patients already have access to this information and understanding the possibility for secondary uses of such data, we are finalizing the policy as proposed to require plans to share adjudicated claims, including provider remittances and enrollee cost-sharing information, via the FHIR-based Patient Access API so patients can continue to access this information in ways that will be most useful to them. We reiterate, however, PO 00000 Frm 00026 Fmt 4701 Sfmt 4700 that we do not have the authority to directly regulate third-party apps. Comment: A few commenters also indicated that even if patients had access to price information, they would not have the ability to negotiate or impact health care costs. One commenter noted that patients would find prospective cost information more valuable than retrospective payment information. Response: We appreciate the commenters’ input. With access to price information, patients who would have cost sharing that is tied to such prices can be more informed consumers of their health care. Even patients who have no direct financial responsibility tied to these prices can benefit from knowing the information in the event their insurance coverage changes in the future or so they can appreciate the relationship between the services they receive and their cost to the health care system. It is important for patients to understand as much as they can about their care. For instance, understanding the costs of past services can help them plan for future services. As a result, this information has great value to patients even if it does not directly impact their ability to specifically influence what they pay for their care, or tell them exactly how much their next service will cost out of pocket. Comment: Many comments were received regarding price transparency, generally, and were beyond the scope of the discussion in this rule. Overall, these were out of scope for this final rule as they referenced other rulemaking activities within HHS. Response: We appreciate the commenters’ strong interest in greater price transparency in health care. We strongly support the Administration’s and Department’s efforts to continue to move toward greater transparency to help health care consumers make the most informed decisions. We point to the recent release of the CY 2020 Hospital Outpatient Prospective Payment System Policy Changes and Payment Rates and Ambulatory Surgical Center Payment System Policy Changes and Payment Rates. Price Transparency Requirements for Hospitals To Make Standard Charges Public final rule (84 FR 65524). This final rule establishes requirements for all hospitals operating in the United States to make their standard charges available to the public under section 2718(e) of the PHSA, as well as an enforcement scheme under section 2718(b)(3) to enforce those requirements. Specifically, sections 2718(b)(3) and 2718(e) of the PHSA require that for each year each hospital operating within the United States E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations establish (and update) and make public a list of the hospital’s standard charges for items and services provided by the hospital, including for diagnosis-related groups established under section 1886(d)(4) of the Act. This final rule requires hospitals (as defined at 45 CFR 180.20) to establish, update, and make public a list of their gross charges, payer-specific negotiated charges (including the de-identified minimum and maximum negotiated charges), and discounted cash prices for all items and services online in a single digital file that is in a machine-readable format, as well as their payer-specific negotiated charges (including the de-identified minimum and maximum negotiated charges) and discounted cash prices (or gross charges, if a discounted cash price is not offered by the hospital) for a more limited set of shoppable services online in a consumer-friendly format. We also direct commenters to the triagency Transparency in Coverage proposed rule (84 FR 65464) for additional proposals to further price transparency. Comment: Some commenters generally opposed the proposal to make claims and encounter data available through a standards-based API no later than one (1) business day after receiving it. Some commenters suggested the proposed data availability timeframe is challenging due to the timeline for sharing adjudicated claims, in particular, noting the different timeframes for payment discharge, benefit determination, and settlement of the patient account. One commenter noted the reliance on third-party contractors to adjudicate claims and the time required to migrate data from one system to another and that validation could take longer than one (1) business day. Several commenters expressed concern about the timeframe based on revised determinations or revised decisions triggered by data that arrives after the initial determination. One commenter specifically questioned the value of third-party application use of claims data when an enrollee has filed an appeal and is awaiting a reconsideration decision. One commenter recommended CMS only permit finalized claims where a determination has been made be available to be shared via the Patient Access API. Some commenters specifically referenced the reliance of MA plans on pharmacy benefit management organizations for the administration of Part D benefits as a factor in the ability to make these claims data available within one (1) business day after receiving them. Other commenters VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 referenced the Explanation of Benefit requirements that provide a timeframe for information adjustment, which means that the final information may not be available in one (1) business day. Several commenters suggested an alternative timeframe of 3 or 5 days for vendor-adjudicated claims, citing time and costs. Some commenters recommended a grace period for plans when there is a delay due to delayed provider encounter data submission. In addition, some requested an exception for specific conditions attributable to certain claims and encounter data. Other commenters recommended that CMS work with stakeholders to determine an appropriate timeframe for making claims and encounter data available via the Patient Access API. Response: We appreciate the commenters’ concerns and recommendations, including comments regarding claims that may be under appeal. We are finalizing this policy as proposed that payers make available through the Patient Access API, no later than one (1) business day after the information is received: (1) Adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and (2) encounter data. We reiterate that this is one (1) business day after the claim is adjudicated or encounter data are received. This allows for potential delays in adjudication or delays in providers submitting their encounter data. It does not require payers and providers to change their contractual relationships or current processes for receipt, though we strongly encourage payers and providers to work together to make patient data available in as timely a manner as possible. We believe it is valuable to patients to be able to have their data in as timely a manner as possible. Having access to this information within one (1) business day could empower patients to have the information they need when they need it to inform care coordination and improve patient outcomes. If a patient needs to get follow-up care, having the information relevant to their previous visit is important and valuable. API technology allows this exchange to happen more quickly and efficiently, and we believe it is important to leverage this technological opportunity to ensure patients have the most current information about their care. It is also important for patients to get this information timely even if there is the possibility of a change in determination due to appeal or other factors. We conducted research to evaluate the maturity of claims to PO 00000 Frm 00027 Fmt 4701 Sfmt 4700 25535 inform researchers using the Chronic Conditions Data Warehouse (CCW) data.30 This research indicates that nearly half of all Medicare FFS or carrier claims are submitted once and unchanged, and nearly 85 percent of inpatient claims are never adjusted. For carrier claims, 99 percent are fully mature at 10 months; and of noninpatient claims that were adjusted, 0.13 percent or less had the diagnosis code changed. What this research shows is that many claims remain unchanged, and those that do take more that 3 or 5 days after adjudication to begin to mature. This wait would not provide patients more accurate or complete data; it would only delay their ability to benefit from access to their information. Patients have a right to see the full lifecycle of their claims and encounter information, and we believe they should be able to have access to their information as soon as it is available. Even if the payment amounts may change due to appeal, for instance, the services received and the providers who rendered them are less likely to change. This is very useful information and could impact care decisions and facilitate better care coordination if available as soon as possible. We do appreciate that there are many factors that could influence when some data are available. Again, we encourage payers to work with health care providers and third-party contractors to ensure timely data processing. Comment: Several commenters expressed concern that the proposed timeframe for payers to share claims and encounter data with patients could require providers to accelerate their submissions to payers triggering additional requirements in existing contracts for the submission of claims and encounter data. Some commenters cautioned there could be potential downstream consequences such as narrowing a payer’s provider network. One commenter recommended removal of proposed rule preamble language suggesting that MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs could consider adding time requirements for submission of claims and encounter data in their contracts with providers. One commenter recommended CMS provide sample contract language or dedicate resources 30 Chronic Conditions Data Warehouse. (2017, October). CCW White Paper: Medicare Claims Maturity (Version 2.0). Retrieved from https:// protect2.fireeye.com/url?k=7bd1837b-2785aa507bd1b244-0cc47a6d17cc590a0fb580f6d595&u=https://www2.ccwdata.org/ documents/10280/19002256/medicare-claimsmaturity.pdf. E:\FR\FM\01MYR2.SGM 01MYR2 25536 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations to educating providers about the intent of these possible contract revisions. Response: We appreciate the commenters’ concerns and recommendations. As discussed in the CMS Interoperability and Patient Access proposed rule, we do appreciate that some payers may consider adding timeframes to contracts with providers to help ensure patients get timely access to their claims and encounter data. Again, we strongly encourage providers to make this information available in as timely a fashion as possible to best assist patients in having access to their health information. Adding language to contracts is one way for payers and providers to work together to ensure patients get this valuable information in as timely a manner as possible. We believe providers can benefit as well if this information is available sooner; it could be shared with them for the purposes of care coordination in a more timely manner, too. It may take some time for providers to improve internal efficiencies to meet potential new timeline requirements, but we believe the long-term benefit outweighs potential short term implementation burden. We do note, however, that the policy being finalized in this rule is specific to payers making adjudicated claims and encounter information available to patients via the Patient Access API within one (1) business day after the payer receives the information. Any additional timeframes are between the payers and their providers. (2) Provider Directory Data We proposed at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), 438.242(b)(6)(ii), 457.730(b)(3), and 457.1233(d)(2)(ii) that the required Patient Access API make available provider directory data, including updates to such data. The proposal at 45 CFR 156.221 would not require QHP issuers to permit third-party retrieval of provider directory (and preferred drug list information) because such information is already required to be provided by QHP issuers on the FFEs. For MA organizations, at proposed 42 CFR 422.119(b)(1)(iii), we proposed to specify that MA organizations make specific provider directory information for their network of contracted providers accessible through their Patient Access APIs: The names of providers; addresses; phone numbers; and specialty. This information is the same information MA organizations are already required to disclose to their enrollees under 42 CFR 422.111(b)(3) and make available online under 42 CFR 422.111(h)(2)(ii). As proposed, MA organizations would be required to VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 ensure the availability of this information through the Patient Access API for all MA plans. We noted that including this information in a standards-based API allows non-MA third-party applications to consume, aggregate, and display this data in different contexts, allowing patients to understand and compare plan information in a way that can best serve their individual needs. As proposed, MA plans would be required to update provider directory information available through the API no later than 30 business days after changes to the provider directory are made. Under proposed 42 CFR 431.60(b)(3) and 457.730(b)(3), state Medicaid and CHIP agencies respectively would be required to make provider directory information available through the Patient Access API, including updated provider information no later than 30 calendar days after the state receives this provider directory information or updates to provider directory information. The proposed regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(6) in this final rule; see section IV. of this final rule) and for CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same timeframe, with the addition of specific provider directory information as noted in 42 CFR 438.242(b)(6)(ii) and 457.1233(d)(2)(ii). For Medicaid managed care plans and CHIP managed care entities, we proposed the provider directory information available through the API must include all information that is specified in 42 CFR 438.10(h)(1) about provider directories for disclosure to managed care enrollees. We proposed that the Patient Access API be updated with new provider directory information within 30 calendar days from when the updated information is received by the state (or the managed care plan under 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(6) in this final rule; see section IV. of this final rule) and § 457.1233(d)(2)) to be consistent with existing Medicaid managed care rules at 42 CFR 438.10(h)(3). We proposed that the API implemented by the state Medicaid agency would include the data elements specified for disclosure by Medicaid state agencies in section 1902(a)(83) of the Act; we proposed at 42 CFR 438.242(b)(6)(ii) that the Patient Access API implemented by Medicaid managed care plans would have the data elements specified for disclosure at 42 CFR 438.10(h)(1). For CHIP agencies that operate FFS systems and CHIP managed PO 00000 Frm 00028 Fmt 4701 Sfmt 4700 care entities at 42 CFR 457.730(b)(3) and 457.1233(d)(2)(ii), respectively, we also proposed that provider directory data be available through the API no later than 30 calendar days after receipt of updated information. We did not propose a similar requirement for QHP issuers on the FFEs. As discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7633), these issuers are already required, under 45 CFR 156.230(c) and implementing guidance, to make provider directory information accessible in a machinereadable format. Because this information is already highly accessible in this format, we noted that we did not believe the benefits of making it also available through a standards-based API outweigh the burden for QHP issuers on the FFEs. However, we sought comment as to whether this same requirement should apply to QHP issuers, or if such a requirement would be overly burdensome for them. To avoid unnecessary duplication of effort and potential confusion, we are not finalizing the proposal to include provider directory information in the Patient Access API. Instead, we are finalizing the inclusion of this information (consistent in scope as proposed for the Patient Access API) in the public facing Provider Directory API discussed in section IV. of this final rule, which requires MA organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities to provide public access to complete and accurate provider directory information at 42 CFR 422.120, 431.70, 438.242(b)(6), 457.760, and 457.1233(d)(3). Appreciating that the comments we received on provider directory information and APIs addressed issues relevant to both including these data in the Patient Access API discussed in this section of the final rule, but more so making this information more widely available through the Provider Directory API as discussed in section IV. of this final rule, all comments and our responses related to provider directory information via APIs can be found in section IV. of this final rule. (3) Clinical Data Including Laboratory Results Regarding the provision of clinical data, including laboratory results, we proposed at 42 CFR 422.119(b)(1)(iv) that MA organizations make clinical data, such as laboratory test results, available through the API if the MA organization maintains such data. We also proposed in paragraph (c)(3)(i) that E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be used as the content and vocabulary standard for the clinical data made available through the API. We intended the proposal to mean that the data required under paragraph (b)(1)(iv) be the same as the data that is specified in that content and vocabulary standard defined at 45 CFR 170.213. In effect, we proposed that at a minimum any clinical data included in the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be available through the Patient Access API if such data are maintained by the MA organization. We recognized that some MA organizations receive this information regularly, or as a part of their contracted arrangements for health services, but that not all MA organizations do. Therefore, we proposed that this requirement would apply to MA organizations, regardless of the type of MA plan offered by the MA organization, but only under circumstances when the MA organization receives and maintains this clinical data as a part of its normal operations. The proposed requirement aligned with existing regulations at 42 CFR 422.118, which required MA organizations to disclose to individual enrollees any medical records or other health or enrollment information the MA organizations maintain with respect to their enrollees. We proposed that this data be available through the API no later than one (1) business day from its receipt by the MA organization. Similarly, the proposed regulations for Medicaid and CHIP FFS programs and managed care plans (proposed 42 CFR 431.60(b)(4) and § 457.730(b)(4)), required provision through the Patient Access API of standardized clinical data, including laboratory results, if available, no later than one (1) business day after the data are received (by the state or the managed care plan or entity). We noted that this would ensure that data provided through the API would be the most current data available, which may be critical if the data are being shared by an enrollee with a health care provider who is basing clinical decisions on these data. As noted, like proposed 42 CFR 422.119(c), the Medicaid and CHIP regulations proposed compliance with the regulations regarding the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, as the content and vocabulary standard for the clinical data available through the Patient Access API; therefore, we proposed that at a minimum any clinical data included in that USCDI VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 standard be made available through the Patient Access API within one (1) business day of receipt. For state agencies managing Medicaid or CHIP FFS programs, we proposed that such data be made available through the API under the proposal if the state maintains clinical data. The proposed regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.) and CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same standard in terms of the scope of information and the timing of its availability through the Patient Access API; the limitation that the clinical data be maintained by the entity for it to be required to be sent via the Patient Access API would carry through to managed care plans and entities under the proposal. Proposed 45 CFR 156.221(b)(1)(iii) would require QHP issuers on the FFEs to also make these clinical data, including laboratory results, available via the Patient Access API, with the approval and at the direction of the enrollee, if the QHP maintains such data. We recognized not all of the entities subject to this requirement have uniform access to this type of data and sought comment on what barriers exist that would discourage them from obtaining, maintaining, and making these data available through the Patient Access API. We summarize the public comments we received on the inclusions of clinical data, specifically the data included in the USCDI standard, via the Patient Access API and provide our responses below. Comment: Several commenters expressed concerns that payers are typically not the original source of clinical information, including data elements that are part of the USCDI, and would not be the best source of the most accurate clinical data for patients. These commenters noted concerns with data accuracy provided by payers who are typically secondary sources of this clinical information and explained that payers do not verify this information. One commenter believed the originator should be providing the data, or that payers should be allowed to indicate the provenance of the data and where to direct questions regarding data accuracy. There was concern that the administrative burden on providers could increase due to patient inquiries and requests to correct or clarify their data. Response: We appreciate the commenters’ concerns and PO 00000 Frm 00029 Fmt 4701 Sfmt 4700 25537 recommendations. We understand that payers are not the source of this clinical information; however, payers do maintain clinical data that can be of great value to patients. We note that provenance is one data class within the USCDI. As such, this information would be available to patients. We also note, that as discussed above, we intend to provide suggested content for educational information that payers will be able to tailor and use to communicate with their patients about the Patient Access API. Payers can choose to indicate the part of a data exchange that was received from an outside source so the receiving party understands where to direct questions. This will also help patients understand how to address incorrect information as it can be made clear where questions should be directed. Payers are under no obligation under this Patient Access API requirement to validate or correct clinical data received from another source; and, providers are under no obligation to submit updated data to payers should patients suggest there is an error in their data. We do encourage payers and providers to continually work to ensure the accuracy of the patient data they maintain and share to the extent possible. The Patient Access API must include all of the specified clinical information for the enrollee maintained by the payer with a date of service on or after January 1, 2016. Comment: A few commenters were concerned that payers could use clinical data to discriminate against providers, such as through discriminatory reimbursement models, for instance offering lower reimbursement rates for certain types of care that a physician deems necessary or in the best interest of the patient based on the data viewed about the doctor and the care they provide. Response: We appreciate the commenters’ concerns; however, we note the fact that some payers are already automatically accessing a physician’s EHR for other purposes, either as an elective offering or through contractual requirements. As a result, additional data than is required to meet the requirements of this final rule are already being shared between providers and payers. We reiterate that payers are not entitled to receive information from a health care provider if such information is protected by applicable federal, state, or local law from disclosure to the payer. This final rule does not change any such existing legal obligations. Comment: A few commenters expressed concerns over provider liability for the quality or accuracy of E:\FR\FM\01MYR2.SGM 01MYR2 25538 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations clinical data and for being given certain sensitive patient diagnosis and problems information, particularly if the provider is a downstream recipient of such data. Response: We appreciate the commenters’ concerns, but reiterate that the policies finalized in this regulation do not change any payer or provider’s obligations to abide by existing federal and state regulations and law, including 42 CFR part 2, which governs certain substance use disorder records, which are some of the most sensitive health information. We note, however, that the patient can direct the entity to transfer this sensitive data upon their designation of a recipient, or may provide consent or authorization for the transfer, as applicable. As a provider, and likely as a covered entity under HIPAA, providers are experienced in handling sensitive data. Access through an API will provide a new route to receiving sensitive data, not add to the burden of protecting such information, given the continued need to maintain compliance with all applicable rules and regulations. These policies just allow this information to be transmitted via an API with the approval and at the direction of the patient. Comment: Some commenters expressed concern that patients may not understand, or may be confused by, the health information that will be available, and questioned if this information will all be relevant to patients. A few commenters recommended that educational materials and resources be developed to ensure that the data are useful and do not cause alarm. Response: We appreciate the commenters’ concerns and recommendations. We appreciate that every patient may not understand every piece of information in their medical record. We intend to provide suggested content for educational materials or other patient resources that payers can tailor and use to ensure that patients have information about how to accurately and productively navigate their health care information, as further discussed below in this section. It is important for patients to have access to their records, review them, and have an opportunity to raise questions and seek clarification about the information maintained in them. Comment: One commenter requested CMS explain the requirement that MA organizations make clinical data available through the Patient Access API if the entity ‘‘manages such data,’’ particularly what is meant by ‘‘manages such data.’’ This commenter noted that providers manage clinical data and VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 requested clarification of whether the requirement applies to MA organizations. Another commenter expressed similar concerns and inquired whether ‘‘managed by the payer’’ would include only lab results or all clinical data. Commenters questioned if ‘‘manage’’ meant ‘‘electronically stored in a database under the payer’s control’’? Response: We appreciate the commenters’ request for additional information. As noted in the CMS Interoperability and Patient Access proposed rule, payers, including MA organizations, need to make these data available through the API when the payer receives and maintains these data as a part of its normal operations (84 FR 7633). We used the verb ‘‘manages’’ to communicate that this proposed requirement would apply when the payer has access to the data, control over the data, and the authority to make the data available through the API. In order to more closely align with how the relevant HIPAA Privacy Rule requirement refers to such activity, we are finalizing the regulation text at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), as well as 45 CFR 156.221(b)(1)(iii) with the verb ‘‘maintains’’ in place of the verb ‘‘manages’’. As such, we define ‘‘maintain’’ to mean the payer has access to the data, control over the data, and authority to make the data available through the API. Comment: One commenter questioned if Medicaid agencies will be required to provide clinical data regardless of the type of transaction by which the agency received the data. Response: We confirm that Medicaid and CHIP agencies, and their respective managed care plans, will be required under 42 CFR 431.60(b)(3), 457.730(b)(3), 438.242(b)(5), and 457.1233(d) to provide clinical data through the API if the state or managed care plan maintains such clinical data. Clinical data subject to this requirement includes laboratory results and other clinical data, and must be made available through the Patient Access API regardless of the type of transaction by which the state or managed care plan received the data originally. However, if the data were received under the payerto-payer data exchange requirement finalized in section V. of this final rule at 42 CFR 422.119(f), 438.62(b)(1)(vi), and 457.1216, and 45 CFR 156.221(f), then the payer would only need to share the clinical data received via the payerto-payer data exchange via the Patient Access API if the data were received from another payer via a standardsbased API. As required at 42 CFR PO 00000 Frm 00030 Fmt 4701 Sfmt 4700 422.119(f)(1)(iii), 438.62(b)(1)(vi)(C), and 457.1216 and 45 CFR 156.221(f)(1)(iii), data received via the payer-to-payer data exchange only need to be made available to share in the electronic form and format they were received from another payer. If a payer receives data specifically for the payerto-payer data exchange via an API, they can then make these data available via the Patient Access API without additional burden—the payer will not be required per this final rule to take data from another payer received as a direct result of the payer-to-payer data exchange policy and prepare it to be shared via the Patient Access FHIRbased API; the payer will only be required to incorporate that data into the enrollee’s record so that it can be shared with a new payer, if requested by the patient, in the electronic form and format received. Appreciating concerns raised around the burden of preparing data for exchange via an API, we have provided this guidance to minimize this burden. We note that Medicaid and CHIP state agencies are not subject to the payer-to-payer data exchange requirement in this rulemaking, as we did not propose this policy for these entities. Comment: A few commenters recommended that patients have access to detailed and accurate lab test and results information through the Patient Access API. A few commenters were not supportive of CMS’ proposal that laboratory information be made available only where available. One commenter recommended that these same API requirements apply to laboratories providing service to Medicare and Medicaid patients as any provider receiving reimbursement for medical services. One commenter expressed concern that lab information is not standardized and may be difficult to exchange. Response: We appreciate the commenters’ concerns and recommendations. These regulations requiring the Patient Access API and detailing the data available through the Patient Access API, as proposed and as finalized, do not apply to laboratories or to any providers—these requirements are specific to payers as detailed above, but we will review the recommendations made for potential future consideration. Regarding concerns about standardized data exchange of laboratory information, the regulations finalized in this rule provide the content and vocabulary standards at 45 CFR 170.213 needed to address sharing laboratory data through the API. Implementation guidance, now E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations available at https://www.cms.gov/ Regulations-and-Guidance/Guidance/ Interoperability/index, though not mandatory, can be used to further support sharing these data utilizing the content and vocabulary standards adopted in this rule. These implementation guides and reference implementations provide additional support to help payers implement this policy in a standardized way that facilitates interoperability. Comment: Some commenters were concerned about the proposed timeline and challenges specifically because of the nature of laboratory data, specifically laboratory results. Final results can replace preliminary results, and laboratory data coming from third parties can take time to receive. Additionally, there may be conflicting disclosure requirements that permit up to 30 days to pass before laboratory data are available to a payer. Response: We appreciate the commenters’ concerns. We do understand that there are many factors that could influence when some data are available. However, we reiterate that this Patient Access API policy requires the information to be shared no later than one (1) business day after it is received by the regulated payer. If it takes additional time for laboratory information to be provided to a payer, that does not impact the payer’s obligation to make the data available via the Patient Access API no later than one (1) business day after the receipt of the information by the payer. Therefore, we strongly encourage all payers and providers to work to make data available in as timely a fashion as possible to ensure an optimally informed health care ecosystem. Comment: Many commenters supported the proposal to require providing the information in the USCDI via the Patient Access API. Commenters supported alignment with ONC on this and encouraged additional alignment across government data sets. Commenters also supported the data classes and associated standards in the proposed ONC USCDI. One commenter specifically noted support for the pediatric vital signs proposed as part of the USCDI. A few commenters recommended the addition of data classes that are already proposed as part of the USCDI, such as clinical notes, provenance, and unique device identifiers. A few commenters strongly supported the inclusion of notes in the USCDI, citing several studies of the benefits of patients having this information including, but not limited to, patient literacy, empowerment, health care coordination, medication VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 adherence, and safety. One commenter recommended only final notes be considered applicable to the USCDI and that the imaging note be removed from the types of required notes. This commenter also indicated that notes that contain sensitive information were likely subject to a variety of state privacy laws. A few commenters noted further standardization work was needed for provenance data fields. Response: We appreciate the commenters’ support and recommendations; we have shared these comments about the USCDI with ONC for future consideration. We agree that aligning with ONC and finalizing exchange of the USCDI as defined at 45 CFR 170.213 in ONC’s 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) has many benefits and will help us reach our interoperability goals. We refer readers to ONC’s final rule for the specifics of exactly how the USCDI standard is being finalized by HHS. As finalized here, the clinical data required to be made available through the Patient Access API at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii) at a minimum are the USCDI version 1 as defined at 45 CFR 170.213 and specified in this rule at 42 CFR 422.119(c)(3)(i), 431.60(c)(3)(i), and 457.730(c)(3)(i), and 45 CFR 156.221(c)(3)(i). We do note the policies finalized in this regulation do not alter obligations under existing federal and state laws. We reiterate that we are working closely with HL7 and other partners leading the effort to develop standards to ensure helpful guidance is available for payers to consult as they work to implement the policies being finalized in this rule. Again, we note that, though not mandatory, we are providing a link to specific implementation guides and reference implementations that provide valuable guidance to support payers as they work to implement the Patient Access API: https://www.cms.gov/ Regulations-and-Guidance/Guidance/ Interoperability/index. Comment: One commenter requested that all the data elements in the USCDI be specifically enumerated in the regulation text of this final rule for clarity. A few commenters recommended CMS and ONC limit the definition of electronic health information to solely the data classes included in the USCDI. Another commenter did not believe this definition should be limited to identifiable information. One commenter suggested that the definition of electronic health information should include real price information. PO 00000 Frm 00031 Fmt 4701 Sfmt 4700 25539 Response: We appreciate the commenters’ recommendations. We are finalizing our regulation text that requires use of the standard specified at 45 CFR 170.213 in ONC’s separate rulemaking to ensure alignment and consistency across the two regulations. That specific standard is currently the USCDI version 1 and therefore the USCDI will be the initial standard applicable under this final rule. Additional information about the data classes and data elements included in USCDI can be found at https:// www.healthit.gov/USCDI. We continue to use ‘‘electronic health information’’ as defined by ONC at 45 CFR 171.102. With regard to specifically listing the data elements in the USCDI, we believe cross referencing ONC’s regulation better supports our goal of aligning with ONC’s policy regarding this information. Comment: One commenter did not support the proposed requirement to provide patients with the USCDI data because the commenter believed it was not feasible for payers. The commenter indicated that payers do not typically collect clinical data. One commenter recommended that CMS use FHIR bundles, or a collection of relevant FHIR resources, rather than the USCDI. One commenter was concerned with how free text fields would be addressed in the USCDI. One commenter expressed concern that CMS would require the use of non-HIPAA standards in the USCDI for providing data to patients. Response: We appreciate the commenters’ concerns and recommendations. We acknowledge that payers do not maintain all clinical data for all patients and our regulation text at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii), as finalized, specifically limits the obligation to make clinical data available through the Patient Access API to those payers that maintain any such data. If a payer subject to these regulations (including the Medicaid and CHIP managed care plans that are subject to regulations that incorporate these requirements) maintain the data elements specified in this final rule, these data elements must be shared as noted in this final rule using the standards indicated. If payers do maintain valuable clinical data about patients, patients have a right to these data. This is a first step in providing patients with information from their medical record in an efficient electronic format. We appreciate the recommendation to look at alternatives to the USCDI, but we believe it is critical for interoperability to align with ONC and see great value E:\FR\FM\01MYR2.SGM 01MYR2 25540 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations in the continued coordination between CMS, ONC, and partners such as HL7 to ensure helpful guidance is available for payers to consult as they work to successfully implement these final rule policies. To this end, we again note that we have provided a link to specific implementation guides and reference implementations that, though not mandatory, can be used to support consistent implementation. We refer readers to additional information on the USCDI at https://www.healthit.gov/ USCDI and available guidance at https://www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/ index to best understand how to implement all data classes and elements included in the USCDI including text fields. Regarding the use of non-HIPAA versus HIPAA standards, we do not believe there is a conflict, and we refer readers to the discussion of Administrative Simplification transaction standards in section III.C.2.b. of this final rule for more information. Comment: One commenter suggested that standards development organizations such as HL7 would be better positioned to support data standardization rather than the proposed USCDI approach. A few commenters noted there are different use cases for various data types and that coordination is required to expand the data in the USCDI. One commenter recommended CMS allow voluntary extensions to data sets outside of the USCDI to support the growth of new standards and data types from a payer perspective. Response: We appreciate the commenters’ recommendations. In addition, we appreciate the valuable role of standards development organizations, like HL7, and reiterate our commitment to working with such partners as industry develops the necessary standards and associated guidance to implement the policies being finalized in this rule. We will continue to refer to the USCDI as finalized by HHS in ONC’s 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.213 to ensure alignment and consistency across the two regulations. We further refer readers to additional information about the USCDI and the expansion process as defined by ONC at https:// www.healthit.gov/USCDI. We note that this expansion process is a consensus process that allows for public input and comment and strongly recommend stakeholders continue to engage in this valuable process. This coordination and consensus is a cornerstone of our VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 interoperability efforts. We also note that the data elements required in this final rule represent the minimum data that must be shared under our finalized policy through a payer’s Patient Access API. We strongly encourage payers to share more data as the more data that patients have access to, the more they will benefit from this access. We agree that continuing to push these limits will spur innovation and growth. Comment: A few commenters requested additional information regarding the definitions of terminology used when discussing the USCDI in the CMS Interoperability and Patient Access proposed rule. One commenter requested more information on the meaning of ‘‘state agencies,’’ in reference to ‘‘any clinical data included in the USCDI standard . . . be available through the API,’’ and if this meant that if the state agency managed an immunization registry it would be required to make the data available through an API. Another commenter requested CMS to provide more information about the use of ‘‘forward’’ (in the preamble) versus ‘‘send’’ (in the regulatory text) regarding the USCDI, including whether the information needs to be available to the receiving payer and whether use of a trusted exchange network is required. Response: We appreciate the commenters’ requests for additional information. We note that the term ‘‘state agencies’’ in this instance in the proposed rule (84 FR 7634) refers to those state agencies that manage Medicaid and CHIP programs. If a Medicaid or CHIP state agency has immunization data in connection with its Medicaid program or CHIP as defined in the USCDI, these data would be required to be available via the Patient Access API per our proposal as finalized. We note that in section V. of this final rule, we require the exchange of the USCDI between payers subject to this regulation; this payer-to-payer data exchange does not require the use of an API. As finalized, our policies do not require the use of a trusted exchange network. Regarding the use of terms ‘‘forward’’ and ‘‘send,’’ we note this means that the data must be exchanged with the patient as specified here in section III. of this final rule or between payers as discussed in section V. of this final rule. (4) Drug Benefit Data, Including Pharmacy Directory, and Formulary Data We proposed that drug benefit data, including pharmacy directory information and formulary or preferred drug list data, also be available through PO 00000 Frm 00032 Fmt 4701 Sfmt 4700 the Patient Access API at proposed 42 CFR 422.119(b)(2)(ii) and (iii), 431.60(b)(5), and 457.730(b)(5). (Our proposal for providing prescription drug claims through this API is discussed in section III.C.2.c.(1) of the CMS Interoperability and Patient Access proposed rule (84 FR 7632).) As previously discussed, Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.) to comply with the requirement at 42 CFR 431.60(b)(5), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(b)(5). We proposed at 42 CFR 422.119(b)(2)(ii) and (iii) that MA organizations offering MA–PD plans must make available through the API the following pharmacy benefit data: (1) Pharmacy directory data, including the number, mix (specifically the type of pharmacy, such as ‘‘retail pharmacy’’), and addresses of pharmacies in the plan network; and (2) formulary data including covered Part D drugs and any tiered formulary structure or utilization management procedure which pertains to those drugs. The pharmacy directory information is the same information that MA–PD plans—like all Part D plans— must provide on their websites under 42 CFR 423.128(b)(5) and (d)(2). While prescription drug claims would have to be made available through the Patient Access API no later than one (1) business day after the MA–PD plan’s receipt of that information, we did not propose a specific timeframe for pharmacy directory or formulary information to be available (or updated) through the API. We noted that we intended that the requirements in 42 CFR part 423 requiring when and how information related to pharmacy directories be updated would apply to the provision of this information through the API; we solicited comment whether we should address this in the regulation text or otherwise impose a timeframe for this information to be made available through the API. At 42 CFR 431.60(b)(5), for Medicaid FFS programs, and at 42 CFR 457.730(b)(5) for CHIP FFS programs, we proposed that states would be required to include and update information about covered outpatient drugs and updates to such information, including, where applicable, preferred drug list information, no later than one (1) business day after the effective date of any such information or updates to such information. We did not propose a similar requirement for QHP issuers on the FFEs because, like the provider E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations directory information, QHP issuers are required to make drug formulary data accessible in a machine-readable format. As discussed above for the provider directory information, to avoid unnecessary duplication of effort and potential confusion, we are also not finalizing the proposal to include pharmacy directory information in the Patient Access API. Instead, we are only finalizing the inclusion of this information as proposed and explained above be included in the public facing Provider Directory API discussed in section IV. of this final rule, which requires MA organizations that offer MA–PD plans to provide public access to pharmacy directory information at 42 CFR 422.120(b). Relevant comments are also discussed in section IV. of this final rule. We summarize the public comments received on our proposal that information about drug coverage and pharmacy benefit coverage be available through the Patient Access API and provide our responses. Comment: One commenter recommended CMS require that MA plans make information about patients’ step therapy available for sharing electronically. This commenter opposes step therapy and recommended that it not be used in MA or Part D. Response: The use of step therapy is beyond the scope of this rule. However, because step therapy is a utilization management procedure, it is included among the types of information MA– PDs must make available about Part D drugs through the API. In regard to information about utilization management that pertains to basic benefits, which was not addressed in this rule, we appreciate the commenter’s recommendations and will evaluate them for potential future consideration. Comment: One commenter strongly recommended the inclusion and standardization of prescription drug monitoring program data (PDMP) for exchange through APIs, although this commenter referred more to exchange between providers for downstream clinical decision support and analytics rather than for patient access. A few commenters were not in favor of sharing PDMP data through APIs. A few commenters were not supportive of PDMP data being available to other providers and payers. Response: We appreciate the commenters’ recommendations and concerns. However, we note that this information is not required to be available through the Patient Access API as it is not within the scope of 422.119(b)(2). VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Comment: Several commenters expressed concern that the proposals in 42 CFR 431.60(b)(5), 457.730(b)(5), 438.242(b)(6) (finalized as 42 CFR 431.60(b)(4), 457.730(b)(4), and 438.242(b)(5) in this rule), and 45 CFR 457.1233(d) to provide information on covered outpatient drugs and preferred drug lists through an API within one (1) business day after the effective date of the information or updates to the information may be a challenge for state Medicaid and CHIP agencies and Medicaid and CHIP managed care entities. One commenter recommended to first require state Medicaid pharmacy programs to focus on developing interoperable standards for API development and only require managed care entities to adopt the standards once the API has been tested and scaled at the state level. Response: We appreciate the commenters’ concerns. We understand that our proposed timeframe of one (1) business day may be operationally challenging for states and managed care plans but continue to believe that this timeframe is critical in order for beneficiaries and prescribers to have this information as soon as the information is applicable to coverage or in near real time since this information could improve care and health outcomes. We believe that timely data are particularly important during urgent or emergency situations. We note that having access to this information as soon as, or even before, it is effective is necessary for patients and their providers to make important decisions about which medications should be included in a patient’s care plan. This is particularly important for patients who may not be able to cover a medication out of pocket if it is not covered by their plan. Therefore, we are finalizing the timeframe. We decline to only apply these requirements to state Medicaid programs (and decline to postpone application of the timeframe to managed care plans until a future time as recommended by the commenter) because this approach would not be consistent with our goal of ensuring that the patients covered by the payers impacted by this requirement have access to the specified data. We also note that we are providing a link to specific implementation guidance and reference implementations for all payers to further support sharing the needed data using the required standards: https://www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/ index. We are finalizing these requirements for the API to include formulary information for MA PO 00000 Frm 00033 Fmt 4701 Sfmt 4700 25541 organizations offering MA–PD plans, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities. In addition to comments about the specific types of information we proposed be made available through the Patient Access API, we also received comments on additional types of information stakeholders would like to see included. We summarize the public comments we received on this topic and provide our responses. Comment: Commenters made a number of suggestions for additional data to be made available to patients via the Patient Access API. Some of the data requested is already included in the proposal and being finalized for inclusion as proposed. In addition to these requests, a few commenters recommended CMS also require the inclusion of information regarding prior authorization decisions, drug pricing, and a direct phone number for patients to call providers and their staff about prior authorization issues. A few commenters specifically requested prior authorization decision information, including active prior authorizations, be made accessible to patients; a few other commenters suggested this prior authorization information be available to providers. Commenters recommended future versions of the USCDI include additional data so that these data would be available via the Patient Access API. A few commenters recommended the USCDI include social determinants of health data. One commenter recommended CMS and ONC include additional immunization data elements from the CDC endorsed data elements for immunization and the American Immunization Registry Association’s Functional Guide. One commenter recommended Care Team Data Class as well as Data Class Provenance ‘‘Author Health Profession’’ be added. One commenter recommended including coverage and explanation of benefit data to the USCDI per the CARIN Alliance’s Implementation Guide. Another commenter recommended CMS include data elements related to administrative transactions. One commenter recommended the USCDI include Digital Imaging and Communications in Medicine (DICOM) images in addition to the already included imaging notes. A few commenters requested CMS specifically require the use of Systematized Nomenclature of Dentistry (SNODENT) for dentistry findings, disorders, and diagnoses, versus making SNODENT optional as part of the proposed USCDI. E:\FR\FM\01MYR2.SGM 01MYR2 25542 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations A few commenters recommended that additional care settings or provider types are considered for additional USCDI data classes in the future. These included anesthesiology, registered dietitian nutritionists, and post-acute care settings (including hospice). One commenter recommended that the USCDI include additional FHIR-based pharmacy benefit standard-based formulary and drug benefit data. Another commenter requested that Admission, Discharge, and Transfer (ADT) data classes and data elements be included in the USCDI. One commenter recommended CMS work with the industry to standardize unstructured encounter data. One commenter was concerned that the USCDI includes data traditionally collected in EHRs and that data/standards for non-health care transactions are not included (for example, home modifications). One commenter expressed concerns that the USCDI does not include the entire designated record set, such as images and genomic test reports and recommends this be included. Response: We appreciate the commenters’ recommendations and will work with ONC to evaluate these recommendations for possible future consideration, as appropriate and feasible. We also received comments detailing concerns with the volume of data being proposed to be made available through the Patient Access API. We summarize the public comments we received on this topic and provide our responses. Comment: A few commenters were concerned with the potential volume of data that will be made available to patients through the Patient Access API. A few commenters requested CMS provide more information regarding the minimum information required to be shared under our policies. One commenter suggested that an advisory panel determine the volume and types of information that patients should receive. Response: We appreciate the commenters’ concerns and recommendations. Regarding the data to be made available to patients, as noted in section III.C.2.b. of this final rule, to ensure consistent implementation and minimize the burden on payers, we are finalizing in the applicable regulations additional text to specify that MA organizations at 42 CFR 422.119(h), state Medicaid FFS programs at 42 CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii), CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at 42 CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221(i), beginning VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 January 1, 2021 (or beginning with plan years beginning on or after January 1, 2021 for QHPs on the FFEs), must make available through the Patient Access API data they maintain with a date of service on or after January 1, 2016. We are also finalizing the same years of data be available through the Patient Access API and for the payer-to-payer data exchange requirement discussed in section V. of this final rule. These policies support the ultimate goal to provide patients access to their cumulative health information. We are finalizing as proposed the minimum content required to be accessible through the Patient Access API in the regulation text at 42 CFR 422.119(b), 431.60(b), 438.242(b)(5), and 457.730(b), and 45 CFR 156.221(b). This specifically includes adjudicated claims (including cost); encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data (including laboratory results) (where maintained by the applicable payer), as well as formularies or preferred drug lists for all impacted payers except QHP issuers on the FFEs. As discussed above, these data must be shared using the content and vocabulary standards at 45 CFR 170.213, finalized by HHS in ONC’s 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register), and in 45 CFR part 162 and 42 CFR 423.160. We believe that patients have a right to their health care information so they can use and share this information to best inform their health care decisions. We appreciate the recommendation to create an advisory panel, and will evaluate it for potential future consideration. d. Documentation Requirements for APIs We proposed that the specific business and technical documentation necessary to interact with the proposed APIs be made freely and publicly accessible. As discussed in section II.A.1 of the CMS Interoperability and Patient Access proposed rule (84 FR 7620), we believed transparency about API technology is needed to ensure that any interested third-party application developer can easily obtain the information needed to develop applications technically compatible with the organization’s API. Transparency is also needed so that third-parties can understand how to successfully interact with an organization’s API. This includes how to satisfy any requirements the organization may establish for verifying a developer’s identity and their applications’ authenticity, consistent PO 00000 Frm 00034 Fmt 4701 Sfmt 4700 with the payer’s security risk analysis and related organizational policies and procedures. In this way payers can ensure they maintain an appropriate level of privacy and security protection for data on their systems. Specifically, at 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 CFR 156.221(d), we proposed virtually identical text to require the regulated entities to make complete accompanying documentation regarding the API publicly accessible by posting this documentation directly on the applicable entity’s website or via a publicly accessible hyperlink. As previously discussed, Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.) to comply with the requirement at 42 CFR 431.60(d), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(d). In requiring that this documentation be made ‘‘publicly accessible,’’ we noted that we expected that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps beyond downloading and using a third-party application to access data through the API. We also noted that this was not intended to preclude use of links the user would click to review the full text of lengthy documents or access sources of additional information, such as if the technology’s supplier prefers to host technical documentation at a centralized location. Rather, we meant ‘‘additional steps’’ to include actions such as: Collecting a fee for access to the documentation; requiring the reader to receive a copy of the material via email; or requiring the user to read promotional material or agree to receive future communications from the organization making the documentation available. We summarize the public comments received on our proposal regarding API documentation and provide our responses. Comment: Some commenters opposed the API documentation proposal indicating payers and providers will be required to provide data without a charge, but the freely and publicly accessible documentation would enable applications to collect data and possibly sell the data back to payers and providers if needed for secondary uses such as provider directories. Some commenters supported fees for documentation noting the funds required to create and maintain data for sharing between payers and enrollees. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Commenters believed third parties should be charged a fee to maintain the API. One commenter expressed concern that the business model of the thirdparty applications hinges on their ability to sell the data they collect for secondary uses while payers and providers would be required to provide information to vendors absent a fee. This commenter argued that charging third-party vendors a fee for documentation could be one way for vendors to absorb some of the cost of maintaining the API in exchange for the data they could potentially use to make a profit. Response: We also appreciate the concerns raised around the secondary uses of data shared with third-parties. We note that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it is considered a deceptive act to use a person’s sensitive information without disclosing in product documentation how this information will be shared.31 In addition, we do not believe that charging a fee to access API documentation is appropriate to offset secondary data use concerns. We refer readers to the additional discussion below regarding informing patients about potential secondary uses of data. The data that must be shared via the API under this policy are data that the payers have and must currently share with patients under existing law. The public directory data is already public information. We do not believe it is appropriate to charge a fee for documentation required to access such available data. Taking the example of provider directory data raised by commenters, currently there are vendors that collect the publicly available directory data, clean these data, supplement these data, and offer this enhanced data product back to payers and providers. It is not the data the vendors are charging for as much as it is the service of cleaning and enhancing these data. Vendors may generate revenue from their third-party apps, but a major component of this is the service they are providing—building the app, making the data the patient directs to them most usable and valuable—that generates the revenue. Payers must already make these data available to patients. These data alone may also drive revenue, but it is the patient’s 31 See also cases where this authority was used, such as 2012 FTC action against Facebook (see https://www.ftc.gov/enforcement/casesproceedings/092-3184/facebook-inc), the 2012 FTC action against MySpace (see https://www.ftc.gov/ enforcement/cases-proceedings/102-3058/myspacellc-matter), and the 2017 FTC action against VIZIO (see https://www.ftc.gov/enforcement/casesproceedings/162-3024/vizio-inc-vizio-inscapeservices-llc). VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 prerogative to provide their data to a third-party in order to get a service in exchange. Being sure patients are as informed as possible about secondary uses of data and how this may impact them is important. As a result, we discuss this issue more below. Comment: Some commenters indicated support for permitting access to documentation without access fees, citing concern that the fees would be extended to consumers as well as logistical concerns for how they would be paid. A few commenters specifically recommended alignment with the ONC 21st Century Cures Act proposed rule API documentation requirement by using the language included in the discussion of the proposed requirement at 45 CFR 170.315(g)(10) stating that the documentation should be ‘‘accessible to the public via a hyperlink without additional access requirements, including, without limitation, any form of registration, account creation, ‘clickthrough’ agreements, or requirement to provide contact details or other information prior to accessing the documentation’’ (84 FR 7484). Response: We do appreciate the requests to explicitly state what we mean by ‘‘public access’’ and ensure it is clear this does not permit any additional restrictions or fees. As a result, to further align with the discussion in the ONC 21st Century Cures Act proposed rule (84 FR 7477), and the CMS Interoperability and Patient Access proposed rule (84 FR 7620), we are finalizing regulation text stating that ‘‘publicly accessible’’ means we expect that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available. We are finalizing this requirement at 42 CFR 422.119(d), 431.60(d), 438.242(b)(5) (through crossreference to Medicaid FFS), 457.730(d), 457.1233(d)(2) (through cross-reference to CHIP FFS), and 45 CFR 156.221(d). Comment: One commenter did not support this documentation proposal for security reasons as the commenter believed that if the documentation was public, any third-party or organization could potentially call, or connect to, a payer’s API. This commenter preferred an alternate approach where CMS stipulates in order to call an API, there PO 00000 Frm 00035 Fmt 4701 Sfmt 4700 25543 would need to be appropriate security tokens in place between the two parties engaged in the data exchange. Response: We appreciate the commenters’ concerns. We note, however, that making the documentation available publicly does not impact the security of the standardsbased API itself. This level of transparency is common in other industries and across standards, and has been shown to lead to innovation and competition. HL7 is built on free and open documentation to ensure that all developers can equally access information. Reviewing the documentation available for FHIR is one way of appreciating the value of this information and how having it freely accessible can allow innovators to engage with health care data in the most meaningful ways.32 Having access to the documentation is not the same as access to the actual API for the purposes of data exchange. Appreciating the comments received and the need to have documentation available to ensure successful implementation and use of the Patient Access API, we are finalizing our proposal to make publicly accessible documentation that includes, at a minimum: (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/ structures, exceptions and exception handling methods and their returns; (2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and (3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API. As noted, we have made one modification by adding the definition of ‘‘publicly accessible’’ to the relevant regulation text. e. Routine Testing and Monitoring of Standards-Based APIs At 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2) for MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers on the FFEs, respectively, we proposed that the API must be routinely tested and monitored to ensure it is functioning properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as but not limited to those required to 32 HL7 International. (n.d.). FHIR Overview. Retrieved from https://www.hl7.org/fhir/ overview.html. E:\FR\FM\01MYR2.SGM 01MYR2 25544 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations comply with the HIPAA Privacy and Security Rules, 42 CFR parts 2 and 3, and other applicable law protecting privacy and security of individually identifiable health information. As proposed, Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) (redesignated as 438.242(b)(5) in this final rule; see section VI. of this final rule) to comply with the requirement at 42 CFR 431.60(c), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(c). Additionally, we noted that while federal laws that regulate MA organizations and MA plans supersede any state law except where noted under section 1856(b)(3) of the Act, some state, local, or tribal laws that pertain to privacy and security of individually identifiable information generally, and that are not specific to health insurance, may also apply to MA organizations and MA plans in the context of the proposal. For the other entities regulated under the proposals in these various programs, we noted that we also intended the phrase ‘‘other applicable law’’ to include federal, state, tribal or local laws that apply to the entity. We proposed this requirement to establish and maintain processes to routinely test and monitor the standards-based APIs to ensure they are functioning properly, especially with respect to their privacy and security features. We explained in the preamble of the proposed rule that under the proposal, MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs would have to implement, properly maintain, update (as appropriate), and routinely test authentication features that will be used to verify the identity of individual enrollees who seek to access their claims and encounter data and other PHI through the API. Similarly, as discussed, compliance with the proposed requirements would mean that these entities must implement, maintain, update (as appropriate), and routinely test authorization features to ensure an individual enrollee or their personal representative can only access claims and encounter data or other PHI that belongs to that enrollee. As is the case under existing HIPAA Privacy Rule requirements, where an individual is also a properly designated personal representative of another enrollee, the HIPAA covered entity must provide the personal representative appropriate access to the information about the enrollee that has designated them as VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 their personal representative, just as they would if the personal representative were the enrollee. We summarize the public comments we received on routine testing and monitoring and provide our responses. Comment: Several commenters supported the proposal to require that payers routinely test and monitor the standards-based API needed to meet the requirements of this proposal. One commenter recommended that this be self-regulated rather than mandated, however. A few commenters expressed concern with the requirement to test and monitor the API. A few additional commenters expressed concern that there is no consensus on a common testing environment. One commenter believed that testing and monitoring will be costly. Several commenters urged CMS to provide additional information and guidance on any requirements for testing and monitoring APIs, including the expected frequency of testing. A few commenters requested additional information on whether payers will be required to demonstrate compliance by submitting or reporting on testing plans. One commenter requested clarification on the process if an issue is found during testing or monitoring. One commenter requested that CMS specify what ‘‘routine’’ means. Response: We appreciate the commenters’ concerns and recommendations. We did not specify exactly at what intervals or frequency testing should be done, and thus did not quantify ‘‘routine,’’ as we believe it is important that payers put a process in place that works best for them to conduct testing and monitoring at regular intervals to ensure the required API remains in compliance and is working as expected. We will provide best practice information, including information on available API testing tools to support payers with this required activity. In our review of the proposed regulation text, we realized that the regulation text at 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2) did not specify the requirement to also update (as appropriate) the API to ensure it functions properly and includes assessments to verify an individual enrollee or their personal representative can only access claims and encounter data or other PHI that belongs to that enrollee. We are finalizing additional text to this effect. We are also removing the word ‘‘minimally’’ from this regulation text in order to ensure it is clear that privacy and security features must be reasonable and appropriate, consistent with the PO 00000 Frm 00036 Fmt 4701 Sfmt 4700 requirements of the HIPAA Security Rule. We note that this testing requirement is accounted for in sections XII. and XIII. of this final rule as one of the expected steps of implementing and maintaining an API. This is part of the cost factored into implementation of the API and is a necessary part of using an API. It is also part of current software development best practices. Payers implementing APIs can incorporate testing tools into a comprehensive testing plan and continuous integration (CI) system, which can automatically validate adherence to the implementation guide when changes are made to further mitigate this cost. f. Compliance With Existing Privacy and Security Requirements In the hands of a HIPAA covered entity or its business associate, individually identifiable health information, including information in patient claims and encounter data, is PHI and protected by the HIPAA Rules. Ensuring the privacy and security of the claims, encounter, and other health information when it is transmitted through the API is important. Therefore, in the CMS Interoperability and Patient Access proposed rule (84 FR 7635), we reminded MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs that mechanisms and practices to release PHI, including but not limited to authorization and authentication protocols and practices, must provide protection sufficient to comply with the HIPAA Rules and other privacy and security law (whether federal, state, tribal, or local) that may apply based on the specific circumstances. As proposed, the entities subject to these requirements would need to continuously ensure that all authorization and authentication mechanisms provide sufficient protections to enrollee PHI and that they function as intended. We specifically requested public comment on whether existing privacy and security standards, including but not limited to those in 45 CFR part 164, are sufficient with respect to these proposals, or whether additional privacy and security standards should be required by CMS as part of the proposal. We note that comments and our responses related to privacy and security issues, generally, can be found in section II.A.2. of this final rule. Here, we summarize the public comments we received on privacy and security as it relates to consent, authentication, and identity verification and provide our responses. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Comment: A few commenters expressed concerns with using the proposed FHIR standards for obtaining patient consent, with some noting the lack of mature consent mechanisms supported through FHIR. A few commenters expressed concerns that there are no mature or widely accepted standards for documenting patient consent electronically, generally. One commenter suggested that the patient be able to see their consent preferences and the types of data that have been authorized for sharing from a central location. One commenter recommended that CMS or OCR develop a standardized data sharing patient consent form that payers, providers, and health IT vendors can use to ensure appropriate consent. A few commenters recommended that CMS require payers and/or apps to use ONC’s Model Privacy Notice. One commenter recommended that CMS and FTC should develop plain language consumer notifications that could be used by app developers. One commenter recommended that CMS require payers to include in their enrollment process an efficient ‘‘check off’’ authorization for an enrollee to release their information to their providers. A few commenters noted that it should be the responsibility of the app to verify the patient’s ability to provide consent. Response: We appreciate the commenters concerns and recommendations, and we have shared these with ONC for consideration. Regarding FHIR standards for consent, we refer readers to discussion in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register), which considers the status of current development efforts around consent resources. We will continue to work with ONC and industry partners to monitor the development of FHIR resources to support consent management. We believe that the security protocols at 45 CFR 170.215 are sufficient to authenticate users and authorize individuals to access their data maintained by payers in accordance with the requirements described in this rule and, therefore, provide the necessary consent mechanisms for payers to implement the policies in this rule. We appreciate the additional recommendations made regarding developing consent materials for all payers to use, as well as recommendations around the use of the ONC Model Privacy Notice. More information on available consent options can be found at https:// VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 gforge.hl7.org/gf/project/cbcc/frs/, and ONC’s Model Privacy Notice is available at https://www.healthit.gov/topic/ privacy-security-and-hipaa/modelprivacy-notice-mpn, which interested payers or app vendors can use. We will evaluate recommendations made that would add requirements on payers that we had not proposed, including any centralized solution, for possible future rulemaking. Comment: Several commenters supported efforts to verify if an entity is authorized to access the data they are seeking. One commenter supported the proposed use of the OAuth standard. One commenter believes that the use of OAuth 2.0 for client application authorization and OpenID Connect for client application authentication should include authenticity, integrity, and nonrepudiation standards. Another commenter suggested CMS permit flexibility in the implementation of security standards. A few commenters expressed concerns with using the proposed FHIR standards for identity proofing alone and supported additional measures, such as biometrics, be employed as well. A few commenters expressed concern about open-ended token access once initially authenticated and instead recommended CMS implement a 90-day timeframe for the authentication token to remain open. One commenter suggested that encryption of authentication credentials is not sufficient. One commenter believed that the only true means by which an individual can assert their identity is through a government-issued ID, and if this cannot be produced, the commenter noted several limitations that should be put in place to prohibit data sharing until further authentication can be done. Another commenter suggested CMS look into biometrics as a means for improving identity proofing. A few commenters recommended the use of multi-factor authentication to verify the identification of an individual. A few commenters recommended requiring payers give their members an online way to self-enroll for the necessary credentials to access their health information via an API. One commenter stated that this will reduce the time it takes for an organization to verify a request. One commenter recommended that this should apply to any of a payer’s patients who have been a member in the past 5 years. One commenter expressed concern that without clear guidelines for how patients can access their data, patients may face barriers such as trying to get authentication credentials, and trying to get an app authorized. PO 00000 Frm 00037 Fmt 4701 Sfmt 4700 25545 A few commenters recommended CMS develop a common method to validate the identity and authority of the requesting party. One commenter recommended CMS issue guidance on authenticating the requestor that offers a simple, secure method to obtain authentication across all entities. A few commenters supported efforts to develop methods to verify a caregiver for a patient and allow that caregiver to access all health information systems. Response: We appreciate the commenters’ concerns and recommendations. We are finalizing as proposed to require compliance with 45 CFR 170.215 as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). This requires use of HL7 FHIR Release 4.0.1, and complementary security and app registration protocols, specifically the SMART Application Launch Implementation Guide (SMART IG) 1.0.0 (including mandatory support for the ‘‘SMART on FHIR Core Capabilities’’), which is a profile of the OAuth 2.0 specification, and the OpenID Connect Core 1.0 standard, incorporating errata set 1). Additional information and implementation guidance can be found at https://hl7.org/ fhir/smart-app-launch/. The goal of using these resources is to make authorization electronic, efficient, and secure so that patients can access their health information as effortlessly as possible. We agree that multifactor authentication represents a best practice for privacy and security in health care settings, and we note that an important benefit of the OAuth 2.0 standard HHS is finalizing is that it provides robust support for multifactor authentication. By requiring that payers subject to our Patient Access API requirement use an API that is conformant with 45 CFR 170.215, where HHS has finalized the SMART IG, we are supporting the use of multifactor authentication. We also note that as part of ONC’s 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register), HHS is finalizing a new provision in the ONC certification program that would require health IT developers to attest as to whether they support multifactor authentication, further encouraging adoption of such security practices. We also strongly encourage payers subject to the requirements in this final rule to employ robust privacy and security protocols, and use multifactor authentication, where appropriate. Multifactor authentication is industry accepted, routinely used across many sectors, E:\FR\FM\01MYR2.SGM 01MYR2 25546 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations known to patients, and a low burden option that could significantly increase security. Though we appreciate commenters’ requests to leave flexibility here, we do believe adopting the standards as finalized by HHS in ONC’s 21st Century Cures Act final rule regarding the use of the SMART IG (using the OAuth 2.0 standard) and OpenID Connect Core 1.0 is an important starting point. In addition, we note that the technical standards at 45 CFR 170.215 address the comments regarding tokens, as HHS is finalizing use of tokens at 45 CFR 170.215 as part of the SMART IG. We note that ONC is requiring that a token be valid for at least 3 months for certified health IT; we encourage payers subject to this final rule to align with this best practice. We appreciate recommendations for a centralized solution to patient authentication and identity proofing, and caregiver access, and will take these under consideration as appropriate. Comment: Many commenters expressed that patients should have ultimate authority and the ability to consent to what type of information can be shared as well as who can access their health information. One commenter recommended CMS require that patients have the ability to filter or request only the specific data that they want to be shared. One commenter requested that payers be able to access the specific types of data a patient authorized the app to access. One commenter added patients should also have an accounting of disclosures or access to their data. A few commenters expressed concerns over the sharing of patient electronic health information with health care providers that the patient has not consented to share with. A few commenters expressed specific concerns with sharing electronic health information beyond the immediate health care provider, such as with providers with which a patient may be seeking a second opinion or additional care. One commenter was concerned with the sharing of family health history data particularly for family members who have not consented. A few commenters recommended that providers be able to pre-filter or select which data can be made available to the patient, citing concerns with the sensitivity of some provider notes or patient confusion in interpreting certain information. A few commenters also suggested that providers be able to select which information can be made available to the payer. Response: We appreciate the commenters’ concerns and suggestions. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Collectively, HHS has been working to evaluate various technical specifications for data segmentation to enhance privacy protections and comply with applicable law (such as laws regarding privacy for minors or 42 CFR part 2). Both HHS and the industry as a whole are currently evaluating future use cases related to segmenting data at the patient request. At this time, however, the policies as they are being finalized under this rule require that the payers, with the approval and at the direction of the patient, provide all of the data as specified in the applicable regulation text. Beyond this, payers, providers, and patients cannot direct specific segments of data be made available via this Patient Access API. The necessary technical specifications to allow a patient to request some data elements be shared but not others are not widely adopted.33 If the patient requests their data via the Patient Access API from a payer, the payer must make available all of the data allowed per current law, such as 42 CFR part 2 and relevant state laws, including the data as specified in this final rule. We reiterate, however, that the data that are available to be shared are only to be shared at the patient’s request. If there are data elements the patient does not want to be shared, they can choose not to make the request. In addition, we note that this policy allows data to be exchanged from the payer to a third-party app of the patient’s choice for their personal use. This rule does not require any data exchange directly between or with providers. Specifically regarding the comment on sharing family history, we note that the health information required to be shared under this policy includes claims and encounter data as well as the data included in the USCDI version 1. At this time, ‘‘family history’’ is not a specific data class within the USCDI. As a result, we do not believe this should be an issue under this current policy. We will, however, take this into consideration as we consider future policy options. We appreciate the recommendation for patients to have a full record of disclosures or access to their health information via the API. At present, the HIPAA Privacy Rule requires accountings of certain disclosures. Consistent with the spirit of this accounting of disclosures, we encourage payers to consider setting up functionality to allow patients to view a 33 For information on adoption levels for technical specifications related to data segmentation, see the Interoperability Standards Advisory at https://www.healthit.gov/isa/datasegmentation-sensitive-information. PO 00000 Frm 00038 Fmt 4701 Sfmt 4700 record of when and with whom their data have been shared via the API. Comment: Many commenters expressed concerns over the complexity with parsing or segmenting electronic health information that is considered sensitive and/or is subject to 42 CFR part 2 rules. Commenters requested CMS take into account these situations with these API proposals and cited use cases such as women’s health, sexual health, young adult health, mental health, and substance abuse treatment. A few commenters noted concerns that some health care providers may discriminate or treat a patient differently if they were able to access certain patient’s health information. A few commenters recommended that HHS align part 2 and HIPAA regulations. One commenter recommended the use of the Consent2Share (C2S) FHIR Consent Profile developed by SAMHSA. Another commenter suggested CMS defer adoption of the Data Segmentation for Privacy standards until an API FHIR standard version is finalized and the Consent2Share guide is revised to conform to that version. Response: We appreciate the commenters concerns and recommendations. We are currently evaluating future options around parsing or segmenting data, generally, using the API. As noted above, HHS is collectively working to explore standards and technical supports for data segmentation for privacy and consent management and point commenters to the ONC 21st Century Cures Act final rule for additional discussion on this. We also note that using the appropriate FHIR profiles, such as those being finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) for API technical standards, including the SMART IG (using the OAuth 2.0 standard) and OpenID Connect as finalized at 45 CFR 170.215, can be leveraged to support this. Again, we note that additional information and implementation guidance can be found at https://hl7.org/fhir/smart-app-launch/. However, we reiterate that payers’ privacy and security obligations under the HIPAA Rules and 42 CFR part 2 are not impacted by this final rule. Comment: A few commenters expressed particular concern for appropriate authorization of parent/ guardian proxies for minor patients. One commenter recommended CMS align the CMS Interoperability and Patient Access proposed rule with the Children’s Online Privacy Protection Act (COPPA), which was created to E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations protect the privacy of children under 13 and has been in effect since 2000. Response: We appreciate the commenters concerns and recommendations, which we are reviewing for future possible consideration in regulation. We note that this current regulation does not change any existing privacy relationships between minors and parents. If, for instance, a teenage minor has asserted their protections to not have their guardians see their Explanation of Benefits, the payer would be obligated to maintain these protections when sharing data via the API. For non-minor dependents, again the existing policies hold true. Regarding privacy in an enrollment group, at this time, a policyholder can see the claims for all members of their enrollment group unless there is an agreed upon privacy provision available and in place. The HIPAA Privacy Rule states at 45 CFR 164.522 that individuals have a right to request restrictions on how a covered entity will use and disclose protected health information about them for treatment, payment, and health care operations. However, a covered entity is not generally required to agree to an individual’s request for a restriction unless certain limited exceptions are met 34, but is bound by any restrictions to which it does agree. After the Affordable Care Act extended the age that group health plans and issuers of health insurance coverage in the group or individual market that offer dependent coverage of children must continue to make such coverage available to adult children until age 26, some states, including California, Colorado, Washington, Oregon, and Maryland, have enacted stricter protections regarding privacy rights, and although all of these states operate their own SBEs and issuers on these Exchanges are not implicated in this rule, to the extent issuers are operating in both these and FFE states and have applied their privacy policies across markets, consumers in FFE states may also benefit from these stricter protections. This final rule does not alter obligations under any existing federal, state, local, or tribal law. Again, we note that this data sharing is currently ongoing; the API just provides an additional way to facilitate this exchange. 34 See 45 CFR 154.522(a)(1)(vi) for a discussion of the limited exceptions. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 g. Issues Related to Denial or Discontinuation of Access to the API We believe patients have a right to their health information. However, a covered entity is not expected to tolerate unacceptable levels of risk to the PHI held by the covered entity in its systems, as determined by its own risk analysis. Accordingly, it may be appropriate for an organization to deny or terminate specific applications’ connection to its API under certain circumstances in which the application poses an unacceptable risk to the PHI on its systems. At 42 CFR 422.119(e), § 431.60(e), 438.242(b)(6) (redesignated as § 438.242(b)(5) in this rule; see section VI.), 457.730(e), 457.1233(d)(2) and 45 CFR 156.221(e) for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, respectively, we proposed to specify the circumstances under which these regulated entities, which are all HIPAA covered entities subject to HIPAA privacy and security requirements, may decline to establish or may terminate a third-party application’s connection to the covered entity’s API while remaining in compliance with the proposed requirement to offer patients access through standards-based APIs. We noted in the CMS Interoperability and Patient Access proposed rule that we intended for the proposal to be consistent with the HIPAA Rules, and we noted that these circumstances apply to specific applications, rather than the third party itself (84 FR 7635 through 7636). Specifically, we proposed that a payer subject to our API proposal could deny access to the API if the payer reasonably determined that allowing that application to connect or remain connected to the API would present an unacceptable level of risk to the security of PHI on the payer’s systems. We further proposed that this determination would be made consistent with the payer’s HIPAA Security Rule obligations and based on objective, verifiable criteria that would be applied fairly and consistently across all applications through which enrollees seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. Where we proposed to require access through standards-based APIs to otherwise publicly available information, such as provider directories, the entities subject to the proposal may also deny or terminate an PO 00000 Frm 00039 Fmt 4701 Sfmt 4700 25547 application’s connection to the API when it makes a similar determination about risk to its systems. However, depending on how the organization’s systems are designed and configured, we recognize that the criteria and tolerable risk levels appropriate to assessing an application for connection to an API for access to publicly available information may differ from those required for API access to nonpublished personally identifiable information (PII). We also anticipated that, where an application’s connection has been terminated under these circumstances, it might be feasible in some instances for the organization to allow the application to reconnect to the API if and when the flaw or compromise of the application has been addressed sufficiently that the organization can no longer fairly say the application’s API connection continues to pose an unacceptable risk. We summarize the public comments we received on denial or discontinuation of service and provide our responses. Comment: Several commenters supported the proposal to allow payers to deny or discontinue access to apps that pose security risks. One commenter specifically supported that the proposal does not allow payers to deny requests based on concerns about the worthiness of the third-party as a recipient of PHI, because patients have the right to share their health information with the app they choose. Several commenters encouraged CMS to develop and/or further define guidelines for identifying ‘‘unacceptable risk’’ and establish a clearer standard for acceptable circumstances when API access can be restricted or denied. A few commenters expressed concerns that the proposed requirements may be interpreted differently among payers, apps, users, and providers. One commenter expressed concern because payers are liable for breaches that occur during data exchange and the commenter does not believe the proposal provides clear authority to deny access based on such security concerns. A few commenters requested that CMS provide more information regarding whether payers may delay and/or deny certain apps that are suspected, or proven to be bad actors. One commenter requested that CMS make the distinction between the risk posed by providing PHI and providing other widely available payer data. A few commenters requested CMS define a time period for how long the ban on access may remain in place. One commenter sought additional E:\FR\FM\01MYR2.SGM 01MYR2 25548 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations information on whether payers will be able to deny third-party access across the board for all patient queries and plans. A few commenters suggested that CMS should develop a clear process for app developers to follow in the event that a covered entity denies access to an API. A few commenters recommended that CMS include in the final rule a reference to ONC’s information blocking definition and clarify that unacceptable levels of risk could be an exception to information blocking. Response: We appreciate the commenters’ concerns. As discussed in the CMS Interoperability and Patient Access proposed rule, the criteria and process for assessing unacceptable risk to a payer’s system are part of the payer’s responsibilities under the HIPAA Security Rule (84 FR 7635). The HIPAA Security Rule requires a covered entity to perform risk analysis as part of its security management processes.35 HHS makes a number of tools available to assess risk.36 Additional tools are available through the National Institute of Standards and Technology (NIST).37 We note that this policy regarding denial or discontinuation of service refers to a payer’s determination that allowing access to their API by a third party would result in risk to their system. As also noted previously, covered entities, in accordance with HIPAA privacy and security obligations, should take reasonable measures to protect data in transit, unless an individual expressly asks that the information be conveyed in an unsecure form or format (assuming the individual was warned of and accepted the risks associated with the unsecure transmission). As explained in this section above, it is the responsibility of payers to assess the risk to their system and act accordingly regardless of whether the data being accessed via the API is PHI or not. If the concern is the security of the payer’s system, the type of data being transferred is not at issue. Absent an individual’s instruction to disregard in-transit security, if while assessing the security of the app’s connection to the API, the covered entity determines the data could be compromised in transit, the payer could discontinue or deny access in order to project the ePHI on its system. Again, 35 45 CFR 164.308(a)1)(ii)(A). more information, see https:// www.hhs.gov/hipaa/for-professionals/security/ index.html. 37 Brooks, S., Garcia, M., Lefkovitz, Ligthman, S., & Nadeau, E. (2017, January). NISTIR 8062 An Introduction to Privacy Engineering and Risk Management in Federal Systems. Retrieved from https://nvlpubs.nist.gov/nistpubs/ir/2017/ NIST.IR.8062.pdf. 36 For VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 this assessment must be based on objective, verifiable criteria in accordance with obligations under the HIPAA Security Rule. Having considered comments, we are finalizing that payers may deny or discontinue any third-party application’s connection to their API if the payer reasonably determines, consistent with its security analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the payer’s systems or in transit in instances in which the individual did not tell the payer to disregard in-transit risk. For example, where an individual requests that their unencrypted ePHI be transmitted to an app, the payer would not be responsible for unauthorized access to the individual’s ePHI while in transmission to the app. When access has been denied or discontinued due to security concerns, we encourage payers and third parties to work together to address the concerns if and as possible to best serve patients. We are not able to set a specific time period or process for this as it is beyond our authority, however, we do note that the HIPAA Privacy Rule requires access to be provided to the individual in a timely manner. Regarding information blocking, we refer readers to the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). Comment: One commenter requested that CMS indicate whether third-party applications will be subject to HIPAA or FTC regulations. One commenter requested information about whether patients will be able to terminate thirdparty access to their health data. Response: We appreciate the commenters’ request for more information. We refer commenters to OCR and FTC for additional information about jurisdiction over third-party apps. We do note, as discussed earlier, that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), the FTC does regulate such third-party apps. Regarding a patient’s ability to terminate third-party access, this would be something determined in the terms and conditions of each app. Comment: A few commenters recommended that covered payers should have the flexibility to establish additional terms and conditions when denying third-party applications access to their systems. One commenter stated that payers should be able to develop their own validation process for enrollees and have the right to not release the data where the full scope PO 00000 Frm 00040 Fmt 4701 Sfmt 4700 cannot be validated. One commenter stated the payers should be able to refuse to connect to non-vetted apps. Another commenter stated that payers should be able to restrict access if the information exchanged is not permitted under the HIPAA Privacy Rule or if the exchange or use would compromise the confidentiality, integrity, and availability of the information. One commenter recommended that CMS allow covered entities to remove an app from their system if the app does not follow the approved privacy policy. One commenter recommended that providers should be allowed to require a business associate agreement (BAA) with third-party app developers that connect to the API required under this final rule. One commenter suggested allowing restrictions on data mining. However, one commenter expressed concern that payers may place unnecessary barriers and burdens on third-party app developers. The commenter encouraged CMS to ensure that payers cannot place additional constraints on apps, such as requiring a BAA, additional security audits, or requiring that apps make commitments about how it will or will not use the information patients store on it. Response: We appreciate the commenters’ recommendations. Specifically, regarding the ability to deny access to a third-party app, we are finalizing this policy as proposed with one modification to add additional clarity around what it means to reasonably determine risk. As such, and as noted above, we are finalizing that payers may deny or discontinue any third-party application’s connection to their API if the payer reasonably determines, consistent with its security analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the payer’s systems and the payer makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers. As patients have a right to their data and this proposal provides the payers the ability to appropriately protect their systems and the data they hold on it, we do not believe any additional restrictions are needed at this time. We also note it would not be appropriate to require a patient-designated third party to enter into a BAA with a payer as the API-facilitated exchange is taking place per the request of the patient and not by, E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations on behalf of, or in service to the payer.38 In addition, we reiterate that it is beyond our authority to regulate third parties directly. We do note that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it is considered a deceptive act to use a person’s sensitive information without disclosing in product documentation how this information will be shared. We do, however, believe patient privacy and security are vitally important. As a result, we lay out an option for payers to ask a third-party app to attest to certain privacy provisions, to help make patients aware of the privacy risks associated with their choices, as detailed in the next section. Comment: Several commenters had suggestions on how to further this proposal. A few commenters recommended that CMS could require apps to attest to certain privacy and security provisions, and if they did not, payers could deny access to the API. One commenter recommended that payers be required to vet third-party applications centrally, rather than requiring vetting for every payer and plan. A few commenters expressed concern that it will be significantly burdensome for payers and providers to vet every app that patients may choose to use in support of more central vetting. One commenter suggested that app developers should be able to proactively request to be vetted by a payer, even if the app developer has not received a request from a member. Many commenters recommended CMS and/or HHS establish a certification, independent verification, or vetting process for third-party applications and vendors that would vet or test apps for certain functions, including privacy and security assurances. As an alternative, one commenter recommended CMS require apps generate an accounting of disclosures or join a trusted exchange network. A few commenters requested CMS share its best practices with app authorization and access under the Blue Button 2.0 initiative. A few commenters recommended CMS, or the payers preapprove and/or maintain a list of approved apps in order for them to access data. Several commenters supported CMS’ proposal to allow patients to select any app of their choice. One commenter recommended that providers and payers be required to authenticate the apps their patients choose to use to gain access. One commenter recommended that third-party application should be clear 38 See 45 CFR 164.103 Definitions, regarding functions of business associate. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 in their terms and conditions when a consumer downloads an app, and if they are not, a payer should not be required to interface with the app. One commenter recommended that the proposal for payers to deny or terminate specific applications from connecting to its API if the risk posed to its systems is unacceptable should be extended to hospitals, health systems, and other health care providers. One commenter suggested that payers should be required to consider the security risks related to provider EHR systems when determining whether to deny or terminate a third-party application. One commenter recommended that CMS develop three options for denial of an application: denial at each API endpoint, centralized application denial, or no denial. One commenter suggested that CMS could consider allowing providers to voluntarily seek assurances or certifications that thirdparties are abiding by the API’s terms. Response: We appreciate the commenters’ recommendations, and we appreciate the concerns raised around privacy and security and the discussion regarding additional steps we can take to protect patient health information. We note that hospitals, health systems, and other health care providers are considered covered entities under HIPAA, and the HIPAA Privacy and Security Rules apply. We do appreciate that app vetting, in particular, is an issue of great interest to payers and providers. We note that we strongly value the role that industry can play in this capacity, and we support efforts within industry to facilitate efficient and effective, publicly accessible information on vetted apps and vendors. We believe industry is in the best position to collectively find the best ways to identify those apps with strong privacy and security practices. We also appreciate the commenters’ request for best practices learned through our experience with Blue Button 2.0. You can find this information at https://www.cms.gov/ Regulations-and-Guidance/Guidance/ Interoperability/index. We are not going to pursue the recommendation to develop a CMS or HHS app certification program. Under our current authorities, we do not believe we have the ability to require a third-party app to take part in such a certification program. We do appreciate that, above all else, stakeholders commented on privacy and security and the need to do more to protect patient health information. Throughout this rule we have noted the limitations to our authority to directly regulate third-party applications. We PO 00000 Frm 00041 Fmt 4701 Sfmt 4700 25549 have also explained that we are finalizing that payers can deny API access to a third-party app that a patient wishes to use only if the payer assesses that such access would pose a risk to the PHI on their system. We appreciate, however, that more needs to be done. In the ONC 21st Century Cures Act final rule (published elsewhere in this Federal Register), ONC notes that it is not information blocking to inform a patient about the advantages and disadvantages and any associated risks with sharing their health information with a third party. In this rule, we are finalizing that impacted payers must share educational resources with patients to help them be informed stewards of their health information and understand the possible risk of sharing their data with third-party apps. As discussed above, commenters believe it is a risk when patients do not understand what happens after their data leaves the protection of HIPAA and are transmitted to a third-party app. Commenters were specifically concerned about secondary uses of data. A clear, plain language privacy policy is the primary way a patient can be informed about how their information will be protected and how it will be used once shared with a third-party app. Taking into consideration comments indicating strong public support for additional privacy and security measures, we are further building off of the privacy and security policies we are finalizing in this rule by asserting that MA organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities, and QHP issuers on the FFEs are encouraged, but are not required, to request third-party apps attest to having certain privacy and security provisions included in their privacy policy prior to providing the app access to the payer’s API. If a payer chooses, they can ask that the apps requesting access to their API with the approval and at the direction of the patient to attest that important provisions that can help keep a patient’s data private and secure are in place. Explaining certain practices around privacy and security in a patientfriendly, easy-to-read privacy policy helps inform patients about an app’s practices for handling their data. It helps patients understand if and how the app will protect their health information and how they can be an active participant in the protection of their information. Also, as explained earlier in this final rule, if an app has a written privacy policy and does not follow the policies as written, the FTC has authority to intervene. As a result, E:\FR\FM\01MYR2.SGM 01MYR2 25550 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations we assert that impacted payers can, but are not required to, ask a third-party app to attest that: • The app has a publicly available privacy policy, written in plain language,39 that has been affirmatively shared with the patient prior to the patient authorizing app access to their health information. To ‘‘affirmatively share’’ means that the patient had to take an action to indicate they saw the privacy policy, such as click or check a box or boxes. • The app’s privacy policy includes, at a minimum, the following important information: ++ How a patient’s health information may be accessed, exchanged, or used by any person or other entity, including whether the patient’s health information may be shared or sold at any time (including in the future); ++ A requirement for express consent from a patient before the patient’s health information is accessed, exchanged, or used, including receiving express consent before a patient’s health information is shared or sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction); ++ If an app will access any other information from a patient’s device; or ++ How a patient can discontinue app access to their data and what the app’s policy and process is for disposing of a patient’s data once the patient has withdrawn consent. Payers can look to industry best practices, including the CARIN Alliance’s Code of Conduct 40 and the ONC Model Privacy Notice41 for other provisions to include in their attestation request that best meet the needs of their patient population. If a payer chooses to request third-party apps provide this attestation, the payer must not discriminate in its implementation, including for the purposes of competitive advantage. Specifically, if a payer requests this attestation of one app, it must request it of all apps that seek to obtain data. If the third-party app does not attest that their privacy policy meets the provisions indicated by the payer, the payer may inform patients that the app did not attest and advise them to reconsider using this third-party app. The notification to the patient 39 Plain Language Action and Information Network. (2011, May). Federal Plain Language Guidelines. Retrieved from https:// www.plainlanguage.gov/media/FederalPL Guidelines.pdf. 40 See https://www.carinalliance.com/our-work/ trust-framework-and-code-of-conduct/. 41 See https://www.healthit.gov/topic/privacysecurity-and-hipaa/model-privacy-notice-mpn. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 should make it clear that the app has not attested to having the basic privacy and security protections and indicate what those are, and that the patient should exercise caution before opting to disclose their information to the app. If the patient still requests the payer make their data available to the third-party app, the payer must provide API access to the app unless doing so would endanger the security of PHI on the payer’s systems. This process should not overly delay the patient’s access. If the app does not attest positively or at all, the payer must work to quickly inform the patient and provide a short window for the patient to cancel their request the data be shared. If the patient does not actively respond, the payer must move forward as the patient has already directed their data be shared and this initial request must be honored. We believe it is important for patients to have a clear understanding of how their health information may be used by a third-party, as well as how to stop sharing their health information with a third-party, if they so choose. We believe the use of this attestation, in combination with patient education, will help patients be as informed as possible while providing payers with a lower burden vetting option. We believe this will better help protect patient privacy and security and mitigate many of the concerns raised. Together, this framework and the requirement for payers to provide patients with educational resources will help continue to move us toward a safer data exchange environment. This is a critical focus for CMS, and we look forward to continuing to work with stakeholders to keep patient privacy and data security a top priority. h. Enrollee and Beneficiary Resources Regarding Privacy and Security As discussed in section II.A. of the CMS Interoperability and Patient Access proposed rule (84 FR 7618 through 7623), we are committed to maximizing enrollees’ access to and control over their health information. We noted that we believed this calls for providing enrollees that would access data under the proposal with essential information about the privacy and security of their information, and what to do if they believe they have been misled or deceived about an application’s terms of use or privacy policy. At 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g), we proposed to require MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, to make available to their PO 00000 Frm 00042 Fmt 4701 Sfmt 4700 current and former enrollees certain information about: factors to consider in selecting a health information management application, practical strategies to help them safeguard the privacy and security of their data, and how to submit complaints to OCR or FTC. The proposed obligations would apply to Medicaid managed care plans and CHIP managed care entities through cross-references proposed in 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this final rule; see section VI. of this final rule) and § 457.1233(d)(2). The general information about the steps individuals can take to help protect the privacy and security of their health information should not be limited to, but should specifically include and emphasize the importance of understanding the privacy and security practices of any application to which they entrust their data. Information about submitting complaints should include both specific contact information for the OCR and FTC complaints processes and a brief overview, in simple and easy-tounderstand language, of: What organizations are HIPAA covered entities, OCR’s responsibility to oversee compliance with HIPAA, and FTC’s complementary responsibility to take action against unfair or deceptive practices, including by non-covered entities that may offer direct-toconsumer health information management applications. We proposed that this information must be made available on the website of the payers subject to the proposed requirement, and through other appropriate mechanisms through which the payer ordinarily communicates with enrollees that are seeking to access their health information held by the payer. This could include customer portals, online customer service help desks, and other locations, such as any portals through which enrollees and former enrollees might request disclosure of their data to a third-party application through the payer’s API. We also proposed that the payer must make this information available in non-technical, simple, and easy to understand language. We explained in the proposed rule how we anticipate that payers could meet the requirement to provide information to current and former enrollees in whole or in part using materials designed for consumer audiences that are available on the HHS website. However, we noted that whether the organization chooses to draft its own resource materials to provide the required information or to E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations rely on governmental or other sources for such materials, the organization will be responsible for ensuring that the content of the materials is adequate to inform the patient regarding the privacy and security risks, and that it remains current as relevant law and policy may evolve over time. We sought comment on the proposal, and we invited additional comments on what specific information resources in addition to those already available on the websites noted above would be most useful to entities in meeting this requirement. We anticipated using this feedback to help inform HHS planning and prioritization of informational resource development work in addition to making a decision on the final rule regarding the proposal. We summarize the public comments we received on enrollee resources and provide our responses. Comment: Several commenters supported the enrollee resources proposal that would require payers to make information available to consumers about selecting an app, safeguarding data, and submitting complaints. Several commenters supported the recommendation that the resources be available in consumerfriendly language and be presented in a way that is easy for consumers to understand. One commenter requested more information about whether payers may make the educational information available through electronic disclosures, such as emailing the information to enrollees, in addition to making the information available online. Response: We appreciate the commenters’ support. We do note that payers may share the information through other appropriate mechanisms usually used to communicate with patients, such as secure email, as well as include the information on a payer website. Comment: A few commenters recommended that CMS provide patient education resources to help patients understand the information available to them through the payers’ APIs. These commenters expressed concerns that patients may not fully understand the context of the data, such as detailed claims information that may not be intuitive to understand. Several commenters expressed concern with consumers’ lack of knowledge about the privacy and security of their health information as it relates to third-party applications. Several commenters expressed concern that consumers may not understand that their health information is not protected by HIPAA once the information is sent to a noncovered third-party app or how an app may use their health information. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Many commenters recommended that CMS develop and/or support education for consumers. Several commenters stated that CMS should have the responsibility to develop educational materials, rather than the payers or providers. Many commenters recommended that CMS collaborate with other regulatory agencies, including OCR and the FTC, to provide consumer education and notification materials. Several commenters recommended that CMS and other HHS agencies develop a campaign to educate patients about the privacy and security of health information, including the risks and challenges when connecting to third-party apps as well as differences between HIPAA and non-HIPAA covered entities and how the differences may affect how their data are used, stored, and shared. Specifically, a few commenters recommended that CMS and FTC should require that third-party app developers inform consumers that HIPAA privacy rules will not apply when they agree to share their data with apps and describe how they will use the consumer’s data. One commenter recommended that educational materials include information on the differences between HIPAA and FTC protections. One commenter recommended that CMS, OCR, or FTC publish the resources on their website and maintain a complaint portal. A few commenters stated that it is the responsibility of all stakeholders to inform consumers of their rights and use of PHI. One commenter recommended that the responsibility of providing educational materials to the consumer should fall on an organization where the patient may have a longer-term, nontransactional relationship, such as an HIE. Several commenters expressed concern that educational resources will not be enough to promote privacy and security. Several commenters recommended that CMS and ONC should require third-party apps to provide notifications on how they may use, share, or sell their health information. One commenter expressed concern that there will not be enough oversight over third-party apps. The commenter recommended that CMS use HIPAA as a framework for developing a privacy structure for third-party apps. Response: We appreciate the commenters’ concerns and recommendations. We agree it is important to help ensure patients fully understand their health information, their rights, and the implications of sharing their information. It is also important patients know what to do if PO 00000 Frm 00043 Fmt 4701 Sfmt 4700 25551 there is a breach of their health information. We appreciate that it would eliminate some burden from payers and providers if we assist with the production of the educational materials needed for the purposes of the requirements in this final rule. As a result, CMS is providing suggested content for educational materials that payers can use to tailor to their patient population and share with patients. We are finalizing the requirement with modification that payers must publish on their websites the necessary educational information, but we will help supply the content needed to meet this requirement. The suggested content we are providing for the educational materials will be shared through our normal communication channels including via listservs and is available via our website: https://www.cms.gov/ Regulations-and-Guidance/Guidance/ Interoperability/index. The modification we are making is to refine the language in the regulation text to expressly state that payers must include a discussion about a third-party app’s secondary uses of data when providing factors to consider in selecting an application at 42 CFR 422.119(g)(1), 431.60(f)(1), and 457.730(f)(1), and 45 CFR 156.221(g)(1). In addition, at 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g), we are modifying the regulation text to state the payer must make these materials available in an easily accessible location on its public website. We note, however, that our authority is limited to helping payers educate patients about their privacy and security rights and where they can go for additional information. We have shared commenter feedback with our federal partners and will continue to work with all stakeholders to ensure patients, providers, and payers have the information they need to address privacy and security issues relevant to the regulations finalized in this rule. We will also continue coordinating with ONC and all of our federal partners through the Federal Health IT Coordinating Council and other federal partnering opportunities to ensure we are tracking the impact of this final rule together, as appropriate. Privacy and security, however, is a much larger issue, and we remind commenters that CMS does not have authority to regulate third-party apps or their developers or develop privacy frameworks that exceed the scope of our authority or this final rule. Comment: Several commenters provided additional recommendations related to patient resources. One commenter recommended requiring E:\FR\FM\01MYR2.SGM 01MYR2 25552 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations payers to include information on how the consumer can contact the payer directly to report a privacy or security breach. One commenter recommended that CMS develop an easy-to-understand questionnaire for third-party applications to fill out that included information about how the app plans to use the data. This questionnaire could be available to patients. One commenter recommended that educational information about tools be available to family members and clinicians and not just the patient. One commenter suggested including educational content for specific conditions or patient populations, such as for pediatric care. Several commenters recommended that CMS include a requirement that the educational materials developed for consumers should also include materials for consumers who may be limited English proficient or have low health literacy. A few commenters recommended that educational materials should be developed with special considerations for vulnerable populations. One commenter recommended that consistent information be available across multiple settings to accommodate varying levels of technology literacy. Response: We appreciate the commenters’ recommendations. As indicated above, we will be providing suggested content for educational materials to assist payers in meeting their educational obligations under this final rule as detailed at 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g). We note that this would also be available to caregivers and family members as we are requiring this material to be posted on the payer’s website. Payers can tailor these materials to best meet the needs of their patient populations, including literacy levels, languages spoken, conditions, etc. Regarding recommendations to have patients contact the payer directly in the event of a breach, that is the patient’s prerogative; a payer is required by the HIPAA Privacy Rule to have procedures for individuals to submit complaints, and to provide directions for doing so in its Notice of Privacy Practices. Individuals may also submit complaints to the OCR and FTC, in the appropriate situations, to address these concerns. Finally, we reiterate that we do not have the authority to regulate apps, so we cannot ask apps to fill out a questionnaire or facilitate sharing that information with patients. We do note that we are making available a document containing best practices for app developers to follow, with a special emphasis on ways to protect the privacy VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 and security of patient data: https:// www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/ index. i. Exceptions or Provisions Specific to Certain Programs or Sub-Programs We proposed certain exceptions or specific additional provisions as part of the CMS Interoperability and Patient Access proposed rule (84 FR 7637) for certain QHP issuers on the FFEs. We also proposed specifics about how MA organizations subject to the regulations finalized here would have to include certain information about the Part D benefit if the MA organization also offered Part D benefits; those aspects of the proposals are addressed in section III.C.2.c(1) of this final rule. Related to QHP issuers, we specifically proposed two exceptions. First, we proposed that the requirements proposed in 45 CFR 156.221(a) not apply to issuers offering only SADPs on the FFEs. In contrast to QHP issuers of medical plans, issuers offering only SADPs offer enrollees access to a unique and specialized form of medical care. We believed the proposed standards and health IT investment would be overly burdensome for SADP issuers as related to their current enrollment and premium intake and could result in SADP issuers no longer participating in FFEs, which would not be in the best interest of enrollees. Additionally, we believed much of the benefit to enrollees from requiring issuers of QHPs to make patient data more easily available through a standard format depends upon deployment of standardsbased API technology that conforms to standards proposed by ONC for HHS adoption at 45 CFR 170.215 (84 FR 7589) and a corresponding energetic response by the developer community in developing innovative, useful, usable, and affordable consumer-facing applications through which plan enrollees can conveniently access, use, and share their information as they choose. Based on the proposals to require implementation of standardsbased API technology in the Medicare, Medicaid and CHIP programs, as well as by QHP issuers on the FFEs, we would anticipate significantly expanding the implementation of standards-based APIs by medical plans. However, we noted that we did not anticipate similar widespread usage with respect to SADPs. Therefore, we believed that the utility of access to issuers’ data is less applicable to dental coverage, and did not believe it would be in the interest of qualified individuals and qualified employers in the states in which an FFE operates to not certify SADPs because PO 00000 Frm 00044 Fmt 4701 Sfmt 4700 they do not provide patient access to their data through a standards-based API. We sought comment on whether we should apply this policy to SADP issuers in the future. We also proposed to provide an exceptions process through which the FFEs may certify health plans that do not provide patient access through a standards-based API, but otherwise meet the requirements for QHP certification. We proposed in 45 CFR 156.221(h)(1) that if a plan applying for QHP certification that is to be offered through an FFE does not provide patient access to their data through a standardsbased API, the issuer must include as part of its QHP application a narrative justification outlining the reasons why the plan cannot reasonably satisfy the requirements in proposed 45 CFR 156.221(a), (b), or (c), the impact of noncompliance upon enrollees, the current or proposed means of providing health information to enrollees, and proposed solutions and timeline to achieve API compliance. In 45 CFR 156.221(h)(2), we proposed that the FFE may grant an exception to the requirement to provide enrollees access to data through standards-based API technology, if the FFE determines that making available such health plan is in the interest of qualified individuals and qualified employers in a particular FFE state. We anticipated that this exception would be provided in limited situations. For example, we would consider providing an exception for small issuers, issuers who are only in the individual or small group market, financially vulnerable issuers, or new entrants to the FFEs who demonstrate that deploying standardsbased API technology consistent with the required interoperability standards would pose a significant barrier to the issuer’s ability to provide coverage to consumers, and not certifying the issuer’s QHP or QHPs would result in consumers having few or no plan options in certain areas. We sought comment on other circumstances in which the FFE should consider providing an exception. We summarize the public comments we received on QHP exemptions and provide our responses. Comment: Several commenters supported CMS’ proposal to exempt SADPs from the requirements to provide a patient API. These commenters agreed with the justification offered that dental information may not be as useful to patients, as well as the resource burden concern for SADPs. A few commenters did not support the proposal to exempt SADPs from the patient API proposed requirements, suggesting it may help dentists and their patients make more E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations informed decisions and that dental information may help other health care providers for patient treatment. Response: We appreciate the commenters support, as well as the concerns raised. We believe the financial impact on SADP issuers may result in fewer SADPs available in the FFEs. We may consider the application of this policy to SADP issuers in future rulemaking. We are finalizing this policy as proposed and exempting SADPs from the Patient Access API at this time. Comment: A few commenters expressed support for the proposal to allow CMS to review a QHP issuer’s justification for an exception to the Patient Access API proposal. One commenter recommended CMS require QHPs that are granted an exception to notify potential enrollees that they will not be compliant with the requirement to provide enrollees access to data through standards-based API technology. A few commenters did not support or expressed concern with CMS’ proposal to grant QHPs an exception process, fearing an impact to patient care and uneven patient access to health data. One commenter did not want plans and entities to function solely as data consumers or aggregators. One commenter suggested that exceptions should be rare, limited, and for a defined duration. A few commenters recommended CMS establish or work with plans to make clear the evaluation criteria for reviewing exception requests to ensure parity. One commenter recommended CMS define a standard for expected alternative API implementation timeline. This commenter also recommended CMS establish a timeline for evaluating exception requests. One commenter requested CMS specify how justifications will be submitted as well as guidance in its annual Letter to Issuers in the FFEs to assist providers in understanding the requirements of the exception application process. Response: We appreciate the commenters’ concerns and recommendations. Regarding concerns that this exception would impact care and access to health data, we believe it is more important to ensure patients have access to QHPs, and if an exception can provide consumers continued coverage, the exception is the preferable approach. We are evaluating the additional recommendations provided for future consideration. Further, in order to better clarify the applicability of the API-related requirements, we are revising 45 CFR 156.221(h) to expand the exceptions process to encompass all requirements VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 in paragraphs (a) through (g), rather than (a) through (c) in the proposed rule. This will ensure that QHP issuers on the FFEs that are not able to meet any of the standards will be subject to the exceptions process. Again, we believe that ensuring patients have access to QHPs is paramount. We also note that additional guidance will be provided to QHP issuers in the future in order to specify how issuers will demonstrate compliance with these standards. Comment: Several commenters recommended that CMS expand the proposal to provide exemptions to the Patient Access API proposal to other types of plans for similar reasons including implementation burden and potential unintended consequences, such as driving plans out of the market. The types of payers that the commenters recommended be provided exemptions include MA, Medicaid (including MCOs, Medicare-Medicaid Plans, Fully Integrated Dual-Eligible Special Needs Plan, Long-Term Services and Supports), CHIP, public health agencies, smaller QHPs and small plans, and new and current QHP issuers. A few commenters recommended CMS include ‘‘local plans’’ in the definition of ‘‘small issuer.’’ One commenter recommended that tribes also be exempt from this policy. Response: We appreciate the commenters’ recommendations, and we appreciate the concerns that certain payers may have unique circumstances making new requirements potentially more challenging. We note that these policies only apply to Medicare Advantage organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. We are only finalizing one exemption, the exception noted below, not identified in the proposed rule, however. We do not believe the burden or potential unintended consequences outweigh the immense benefit to patients and the potential for improved health outcomes these policies can facilitate. As noted earlier in this final rule, we are modifying the scope of the applicability of the regulations to QHP issuers on an individual market FFE. In considering the application to issuers offering plans through the FF–SHOPs, we believe that, like the exception for issuers of SADPs discussed above, the financial burden to implement these policies may result in fewer issuers offering plans through the FF–SHOPs and could result in small employers and consumers having fewer or no FF–SHOP plan options. Further, we believe that most FF–SHOP issuers likely would qualify for exclusion via the exceptions PO 00000 Frm 00045 Fmt 4701 Sfmt 4700 25553 process we are finalizing. We have modified 45 CFR 156.221(h)(2) to remove the reference to ‘‘qualified employers’’ and paragraph (i) to include applicability to individual market FFEs. j. Applicability and Timing At 42 CFR 422.119(h) and 45 CFR 156.221(i), we proposed specific provisions regarding applicability and timing for MA organizations and QHP issuers on the FFEs that would be subject to the proposal. We did not propose specific regulation text for 42 CFR 431.60 or 438.242 because we intended to make the regulation text effective on the applicable date, as discussed below. We noted that we expected that state Medicaid and CHIP agencies would be aware of upcoming new regulations and planning for compliance with them when they are applicable, even if the new regulation is not yet codified in the CFR; we similarly expected that such agencies will ensure that their managed care plans/entities will be prepared for compliance. Unlike Medicaid state agencies and managed care plans and state CHIP agencies and managed care entities, MA organizations and QHP issuers on the FFEs generally are subject to rules regarding bid and application submissions to CMS in advance of the coverage period; for example, MA organizations must submit bids to CMS by the first Monday in June of the year before coverage starts in order to be awarded an MA contract. In an abundance of caution and to ensure that these requirements for MA organizations and QHP issuers on the FFEs are enforceable and reflected in the bids and applications these entities submit to us in advance of when the actual requirements must be met, we proposed to codify the actual compliance and applicability dates of these requirements. We solicited comment on this approach. For MA organizations, under 42 CFR 422.119(h), we proposed that the requirements would be applicable beginning January 1, 2020. Under the proposal, the requirements at 42 CFR 422.119 would be applicable for all MA organizations with contracts to offer any MA plan on that date and thereafter. We requested feedback about the proposed timing from the industry. In particular, we solicited information and requested comment from MA organizations about their current capability to implement an API consistent with the proposal and the costs associated with compliance by January 1, 2020, versus compliance by a future date. For Medicaid FFS at 42 CFR 431.60, CHIP agencies that operate FFS systems at 42 CFR 457.730, Medicaid managed E:\FR\FM\01MYR2.SGM 01MYR2 25554 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations care plans at 42 CFR 438.242(b)(6) (finalized as § 438.242(b)(5) in this rule; see section VI.), and CHIP managed care entities at 42 CFR 457.1233(d)(2), we proposed that the API requirements would be applicable beginning July 1, 2020, regardless of when the managed care contract started. We noted that given the expected date of publication of the final rule, we believed July 1, 2020, would provide state Medicaid agencies and CHIP agencies that operate FFS systems, Medicaid managed care plans, and CHIP managed care entities sufficient time to implement. We solicited comment on the proposal and whether additional flexibility would be necessary to take into account the contract terms that states use for their Medicaid managed care plans. For CHIP, we noted that we are aware that some states do not provide any benefits on a FFS basis, and we did not intend for those states to implement an API outside their managed care plans. Therefore, we proposed in 42 CFR 457.700(c) that separate CHIP agencies that provide benefits exclusively through managed care entities may meet the requirements of 42 CFR 457.730 by requiring the managed care entities to meet the requirements of 42 CFR 457.1233(d)(2) beginning July 1, 2020. For QHP issuers on the FFEs, we proposed in 45 CFR 156.221(i) that these requirements would be applicable for plan years beginning on or after January 1, 2020. We sought comment on the timing of these requirements, and on how long issuers, particularly smaller issuers, anticipate it would take to come into compliance with these requirements. We explained in the CMS Interoperability and Patient Access proposed rule our belief that these proposals would help to create a health care information ecosystem that allows and encourages the health care market to tailor products and services to compete for patients, thereby increasing quality, decreasing costs, and helping them live better, healthier lives. Additionally, under these proposals, physicians would be able to access information on their patient’s current prescriptions and services by reviewing the information with the patient on the patient’s personal device or by the patient sharing data with the provider’s EHR system, which would save time during appointments and ultimately improve the quality of care delivered to beneficiaries. Most health care professionals and consumers have widespread access to the internet, providing many access points for viewing health care data over secure connections. These proposed VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 requirements would significantly improve beneficiaries’ experiences by providing a secure mechanism through which they can access their data in a standardized, computable format. We noted that these proposals were designed to empower patients by making sure that they have access to health information about themselves in a usable digital format and can make decisions about how, with whom, and for what uses they will share it. By making claims data readily available and portable to the enrollee, these initiatives supported efforts to move our health care system away from a FFS payment system that pays for volume and toward a payment system that pays for value and quality by reducing duplication of services, adding efficiency to patient visits to providers; and, facilitating identification of fraud, waste, and abuse. Data interoperability is critical to the success of new payment models and approaches that incentivize high quality, efficient care. All of the health care providers for a patient need to coordinate their care for a valuebased system to work, and that requires information to be securely shareable in standardized, computable formats. Moreover, we noted that patients needed to understand and be actively involved in their care under a valuebased framework. We committed to supporting requirements that focus on these goals, and we noted we believe that the specific proposals supported these efforts. We summarize the public comments we received on applicability and timing of the Patient Access API and provide our responses. Comment: A few commenters supported the proposed timeline for implementing APIs. One commenter believes that payers have sufficient time to prepare APIs and recommended that CMS maintain the proposed timeline. One commenter suggested that to address payer concerns CMS could reward plans, such as through higher HEDIS scores, who are able to meet the January 1, 2020 date. Many commenters expressed concern with the proposed implementation timelines. Many commenters believed that payers and developers will need more time to implement the requirements and encouraged CMS to delay the implementation date. A few commenters were concerned that without sufficient time and resources to implement security protocols, payers will be unable to meet the proposed requirements. Many commenters believed that additional time will allow health IT vendors and payers to develop, test, and implement the PO 00000 Frm 00046 Fmt 4701 Sfmt 4700 necessary systems. Several commenters expressed concern with the costs needed to implement the proposals under the proposed timelines. Several commenters recommended an implementation deadline no earlier than 2021, while several other commenters recommended a proposed implementation date of January 1, 2022. One commenter each suggested January 1, 2023 and January 1, 2024, while another recommended 12 months after the publication of the rule. Many commenters recommended a timeline of at least 18 to 24 months after publication of the final rule. Several commenters recommended aligning the CMS timelines with the ONC timelines, therefore recommending CMS implement policies in this final rule 2 years after the publication of this final rule. A few commenters recommended a 36-month timeline for all proposed policy implementation dates included in this rulemaking. A few commenters did not support proposing a timeline yet. The commenters noted that the standards and the infrastructure should be more mature before implementation dates are set. One commenter suggested that CMS and ONC convene a planning group to establish a more appropriate timeline. Several commenters encouraged CMS take a phased approach, which some explained as creating a ‘‘glide path’’ from ‘‘proof of concept’’ to more advanced use cases and a more expansive set of data. Commenters had a few different recommendations for which data elements could be included in which phase of the implementation in such a scenario. A few commenters suggested an approach where smaller plans meet fewer requirements initially and phase-in to full adoption. One commenter requested that CMS exempt small issuers from the requirements of the rule. A few commenters recommended delaying any disincentives and/or penalties until 2 years after implementation. One commenter expressed concern that the different implementation dates for different payers may create confusion, particularly for dual eligible beneficiaries. Response: We appreciate the commenters’ concerns and recommendations. We understand that payers need time to be able to develop, test, and implement the APIs being finalized in this rule. We appreciate that it will take time to map and prepare historic data for sharing via the standards-based FHIR API. We want to be sure that payers have the time and guidance needed to fully and accurately E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations implement the policies being finalized in this rulemaking. We do not agree, however, that it is necessary to convene a planning group to develop a timeline for implementation. The public has had the opportunity to provide feedback on this issue as part of this rulemaking. As a result, we are finalizing the implementation date of the Patient Access API as January 1, 2021 for all payers impacted by this rulemaking, except for QHP issuers on the FFEs, for which the rule will be applicable beginning with plan years beginning on or after January 1, 2021. We strongly encourage payers to implement these policies as soon as they are capable, but the Patient Access API will not be required until January 1, 2021. For Medicaid managed care, we remind states that should they determine that obligations in this rule warrant a retroactive adjustment to capitation rates, those adjustments must be certified by an actuary in a revised rate certification and submitted to CMS as a contract amendment, pursuant to 42 CFR 438.7(c). We do appreciate the commenters’ suggestion to evaluate a phased implementation approach. As a result, you will see in section IV. of this final rule how we are using the Provider Directory API proposal as a way for payers to show they are making progress toward API development and access. k. Request for Information on Information Sharing Between Payers and Providers Through APIs We proposed the implementation of standards-based APIs for making accessible data that a third party could use to create applications for patients to access data in order to coordinate and better participate in their medical treatment. While in some instances, direct provider to health plan transmission of health information may be more appropriate than sharing data through a standards-based API, in other instances a patient may wish to send a provider a copy of their health information via another health care provider’s API. In such cases, patients could direct the payer to transmit the health information to an application (for example, an application offered by a health care provider to obtain patient claims and encounter data, as well as lab test results (if applicable)) on a oneoff and as-needed basis. To the extent a HIPAA covered entity offers patients access to their records via a standardsbased application, another HIPAA covered entity may be able to obtain an individual’s health information from the app for treatment, payment, or certain health care operations purposes, VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 without need of an individual’s authorization, consistent with the HIPAA Rules (see 45 CFR 164.506). Under other laws, providers may need to obtain specific individual consent to obtain health information related to care provided by a behavioral health provider, treatment received at a substance use disorder treatment facility, certain 42 CFR part 2-covered diagnoses or other claims-related information, or labs that suggest a part 2 diagnosis. We explained in the CMS Interoperability and Patient Access proposed rule how we did not intend to expand any scope of authority to access patient data nor to contravene existing requirements related to disclosure of PHI under the HIPAA Rules and other legal standards, but instead specified a new and additional mechanism by which to share health information as directed by the individual, through the use of API technology in compliance with all existing federal, state, local, and tribal privacy and security laws. We explained how, in the future, we anticipate payers and providers may seek to coordinate care and share information in such a way as to request data on providers’ or a payer’s patient/ insured overlapping population(s) in one transaction. We sought comment for possible consideration in future rulemaking on the feasibility of providers being able to request a download on a shared patient population using a standards-based API. We thank commenters for their insights and are reviewing the comments received for inclusion in potential future rulemaking. In addition to the comments we received about the specific sections of this Patient Access API proposal, we also received a number of comments that were specific to the types of payers impacted by the proposal, generally. We summarize these public comments by payer type and provide our responses. We received these public comments related to Medicare Advantage. Comment: One commenter suggested CMS require that MA organizations make patient data maintained in connection with the organizations’ various individual and small group market plans available for access and exchange through the Patient Access API. Response: We appreciate the commenter’s suggestion. However, in light of the limits on CMS’s authority over MA organizations, commercial insurance, and group health plans, we are not adopting requirements to apply as broadly as the commenter suggested. We note that QHP issuers on the individual market FFEs are required PO 00000 Frm 00047 Fmt 4701 Sfmt 4700 25555 under this final rule to implement the Patient Access API, and we encourage other individual markets, as well as small group market plans and group health plans to do so, as well. Comment: One commenter recommended CMS specify the expectations of MA organizations regarding supplemental benefits in relation to the Patient Access API. One commenter recommended CMS evaluate whether the standards proposed for this API are appropriate for the dental care space. Response: We appreciate the commenter’s request for additional information. We note that MA claims data, encounter data, and clinical data related to supplemental benefits, including dental services, are subject to the API requirement, even if issuers only offering SADPs on FFEs are not subject to the requirement. Comment: One commenter requested additional information on whether Medicare Advantage D–SNPs would be required to provide patients an API. Response: We appreciate the commenter’s request for additional information. We note D–SNPs are MA plans offered by MA organizations and therefore subject to the API requirement adopted at 42 CFR 422.119. Comment: One commenter requested additional information of whether data shared via an API would be subject to member communication rules, such as Medicare Communications and Marketing Guidelines. Response: We appreciate the commenter’s request for additional information. Whether or not data shared via the Patient Access API being finalized at 42 CFR 422.119(b) falls under the purview of CMS’s communication and marketing rules would be dependent on factors such as the relationship of the developer and the MA plan(s), the content accompanying the API data, and the intended outcome of the application using the API data. MA plans must continue to follow the provisions of 42 CFR part 422 (such as but not limited to 42 CFR 422.118(d), 422.2260 through 422.2268), including in circumstances when their communications and marketing materials include data that is retrieved through an API. For example, if a field marketing organization (FMO) uses API data to create a software application that compares the provider networks for the plans the FMO is contracted to sell, the application would fall under the MA marketing and communications regulations and CMS’s oversight. Conversely, if a developer uses API data to create an independent application that provides an alternative E:\FR\FM\01MYR2.SGM 01MYR2 25556 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations means of scheduling provider appointments, the application would fall outside of CMS’s purview. We received these public comments related to Medicaid and CHIP. Comment: Several commenters requested additional information on which Medicaid programs would be required to implement and maintain a standards-based API. One commenter wanted additional information as to whether all state’s Medicaid Management Information Systems (MMIS) would be required to develop APIs. This commenter stated that while it seemed clear that the rule does not require health plans to use Health IT modules to make administrative data available, the role of a payer’s claims adjudication system (including MMIS) is unclear. Response: We appreciate the commenters’ request for information. In proposed 42 CFR 431.60 and 457.730, we specified that states would have to implement and maintain an API for FFS Medicaid programs and CHIP; we also proposed in 42 CFR 438.242(b)(6) (finalized as 42 CFR 438.242(b)(5) in this rule; see section VI.) and 457.1233(d) that states would have to require each MCO, PIHP, and PAHP to comply with 42 CFR 431.60 (under Medicaid managed care contracts) and 457.730 (under CHIP managed care contracts) as if such requirements applied directly to them. We are finalizing these policies as proposed. Sections 431.60 and 457.730 do not require a specific system to be used for the implementation and maintenance of the API, thus we defer to each state and Medicaid managed care plan to determine which of their systems would be the most appropriate. Comment: One commenter requested that CMS clarify if an arrangement in which a state provided beneficiaries access to their FFS data by delegating the API function to a managed care plan would be sufficient to satisfy the rule, or if each entity in the chain is required to implement their own systems, portals, and/or API interfaces. This commenter questioned if CMS envisioned the creation of a national network to exchange Medicare/ Medicaid records that would satisfy these requirements in a centralized fashion. Response: We appreciate the commenter’s request for information. We are, however, somewhat unclear what the commenter meant by ‘‘delegating the API function to a managed care plan.’’ We believe the commenter may be questioning if a state could utilize a managed care plan to implement the API required for the VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 state’s FFS beneficiaries in lieu of the state implementing the API required in 42 CFR 431.60. If so, the proposed rule did not anticipate nor prohibit that type of an arrangement. As such, this final rule could permit such an arrangement, but we remind a state contemplating using such an arrangement that it must meet the all of the requirements in this final rule, including the timelines and scope specified for data accessibility in § 431.60(b). There is no plan for a national network to exchange Medicare/ Medicaid records in lieu of the APIs being finalized in this rule at this time. Comment: One commenter suggested that CMS establish a stakeholder workgroup to identify best practices in data-sharing with Medicaid beneficiaries. Response: We appreciate this suggestion and encourage states and Medicaid managed care plans to work with their stakeholders to identify best practices for data-sharing with Medicaid beneficiaries in their states. Comment: A commenter expressed concern that reimbursing states for modification of their IT systems at an enhanced match rate while reimbursing managed care plans for their system modifications at the state’s standard match rate creates an uneven playing field for Medicaid managed care plans and a disparity of funding. This commenter noted that in states that make extensive use of managed care, the bulk of system modifications needed to carry out and maintain the proposed interoperability capabilities for Medicaid enrollees will be borne by Medicaid managed care plans and requested that CMS revise its proposal to reflect that all costs attributable to design, development, installation, enhancement, or ongoing operation of both state and Medicaid managed care plan systems will receive the appropriate enhanced federal match. Finally, this commenter requested that CMS take a more rigorous approach and update its methodology for review of state MCO capitation rates to ensure that proposed rates include reasonable allowances for costs of IT systems work performed by the state’s Medicaid managed care plans in furtherance of the proposals in this regulation. Response: We appreciate the commenter’s concern. However, we do not agree that the difference in the federal match rate creates an uneven playing field. Capitation rates must be actuarially sound independent of the federal matching rate that applies to the payment of those rates. The provision of enhanced federal match rate is addressed in section 1903(a)(3)(A) of the Act and provides a 90 percent match PO 00000 Frm 00048 Fmt 4701 Sfmt 4700 rate for ‘‘. . . the sums expended during such quarter as are attributable to the design, development, or installation of such mechanized claims processing and information retrieval systems as the Secretary determines are likely to provide more efficient, economical, and effective administration of the plan . . .’’ It does not specifically provide an enhanced match rate for the portion of a capitation rate that may be included for information technology expenditures, and we do not have the authority to extend the enhanced match rate beyond the conditions specified in statute. We already have a very rigorous capitation rate review process and will review any changes noted by the states in those rates, including any specifically noted for IT system enhancements specific to the requirements finalized in this rule. Comment: One commenter requested that the new requirement to implement and maintain an API must be uniform across the system and non-negotiable to Medicaid managed care plans, state government, and providers. One commenter noted that CMS should address situations where states may choose to adopt additional or conflicting data sharing requirements in Medicaid or CHIP managed care contracts. This commenter further stated that it is critical that covered health plans be subject to uniform standards for data accessed through an API and that CMS should work with state Medicaid and CHIP programs to ensure that any state mandated requirements for data accessed through an API are harmonized with the new federal standards. This commenter suggested that submission of the encounters in a timely manner by all involved with the new rule must be a non-negotiable condition for the receipt of Medicare or Medicaid reimbursement. In addition, the commenter noted that enforcement cannot be left to plans based on variable contract terms but must be provided by federal agencies. Response: We agree with the commenter that implementation of standards-based APIs should be consistent across states and Medicaid and CHIP managed care plans and have codified the requirements for APIs in 42 CFR 431.60(b), 457.730(b), 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see section VI.), and 457.1233(d) to ensure an appropriate level of uniformity and consistency while still providing states with an adequate level of flexibility to go beyond the minimum standards included in this final rule when they believe doing so benefits their beneficiaries. While we do not have a specific provisions that E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations conditions payment on the timely receipt of encounters, states and managed care plans may find that a useful provision to include in their contracts. States must have a monitoring system in effect for their Medicaid managed care programs under § 438.66(b)(6), which also specifies ‘‘information systems, including encounter data reporting’’ as a required element. Similarly, we have certain program oversight responsibilities, such as the review of certain Medicaid and CHIP managed care contracts and all capitation rates, and will incorporate oversight of requirements in this final rule to the extent appropriate. Comment: One commenter noted that CMS encourages the Medicaid and CHIP FFS programs to use the API as a means to exchange PHI with providers for treatment purposes, suggesting the data would be shared in advance of a patient’s visit. But CMS also states that this proposal can empower the patient to decide how their health information is going to be used. This commenter requested additional information of the role CMS intends for the patient and the provider to have in the use of APIs. Response: While we believe that a beneficiary’s use of an API to obtain their health care data will play an important role in their health care, as proposed and finalized, this rule does not set standards for health care provider use of apps to obtain information from payers. As proposed and finalized in 42 CFR 431.60(a) and 457.730(a), the API permits third-party applications to retrieve a patient’s data at the patient’s request. A beneficiary may make the decision to obtain their health care data through such an app and share it with a provider in advance of a visit or otherwise. Comment: One commenter requested clarity on whether the proposed rule requires all states’ MMIS [Medicaid Management Information System] to make information available to patients within one (1) business day of receipt or adjudication of administrative data (adjudicated claims, encounters, provider remittance, etc.). This commenter expressed concern that these data could appear to conflict with data obtained by a patient directly from a managed care plan, causing confusion and increasing administrative overhead. Response: We appreciate the commenter’s request for additional information. Medicaid beneficiaries should not be receiving the information from both the state and managed care plan for the same service. If the beneficiary is receiving a service under the state’s Medicaid FFS program, the requirements in § 431.60 apply; that is, VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 the state is responsible for providing the specified data elements in § 431.60(b) through the API. If the beneficiary is enrolled in a managed care plan (receiving the service under the managed care plan’s contract), the requirements in § 438.242(b)(5) (proposed as § 438.242(b)(6); see section VI.) apply; that is, the managed care plan is responsible for providing the specified data elements in § 431.60(b) through the API. The beneficiary should not receive data that is in conflict with other data that is made available through the API. The same is true for CHIP. If the beneficiary is in CHIP FFS, the requirements in § 457.730 apply; that is, the state is responsible for providing the specified data elements in § 457.730(b) through an API. If the beneficiary is enrolled in a managed care plan, the requirements in § 457.1233(d) apply; that is, the managed care plan is responsible for providing the specified data elements in § 457.730(b) through the API. Comment: One commenter expressed concerns regarding the ongoing burden for state Medicaid and CHIP agencies to monitor the API, privacy and security features, and potential security risks posed by the numerous applications that may connect to the API. This commenter recommended that states be required to monitor the compliance of each of their managed care plans regarding the API requirements. Response: We understand the commenter’s concerns about burden related to the API, as well as the need for states to monitor the API for privacy and security. These requirements are specified at 42 CFR 431.60(c)(1) and (2) and 457.730(c)(1) and (2). While we understand that there is some burden for states and managed care plans related to the development and implementation of the API, we continue to believe that the benefits and potential for improved health outcomes outweigh the burden associated with these requirements. We also confirm for commenters that states are required to monitor compliance for their contracted managed care plans in regard to the API requirements under 42 CFR 438.242(b)(5) (proposed as 42 CFR 438.242(b)(6); see section VI.) and 457.1233(d). Since these requirements apply to managed care plans, states are required to include the requirements under their managed care contracts and must ensure that plans comply with the standards specified in 42 CFR 431.60 and 457.730 as if those requirements applied directly to the managed care plan. Comment: Several commenters stated that the Patient Access API proposal PO 00000 Frm 00049 Fmt 4701 Sfmt 4700 25557 places a significant burden on Medicaid and CHIP beneficiaries to monitor the privacy and security of their own health information while it is being accessed by non-HIPAA covered entities. One commenter recommended that CMS consider how educational efforts could be uniquely tailored to specific populations, such as Medicaid beneficiaries, particularly given the need for special considerations when attempting to engage with vulnerable populations. This commenter recommended that CMS amend or revise the current language in its proposed rule to explicitly require that API vendors be responsible for the education of consumers. Another commenter noted that many Medicaid and CHIP beneficiaries are children and that app developers, states, and managed care plans will also need to develop resources for minor access and control over health information and educate members accordingly. Response: We appreciate the commenters’ concerns, and we acknowledge that some Medicaid beneficiaries may find negotiating the privacy and security app landscape burdensome. Any patient, including one who is not comfortable with technology, may choose not to use this method of data exchange. However, we would like all beneficiaries to be able to benefit from these apps. One way we are looking to mitigate this burden is through education. We believe that it is important for beneficiaries to have the educational resources to be able to best evaluate their third-party options. States and managed care plans must comply with the requirements 42 CFR 431.60(f) and 457.730(f) that require states and managed care plans to develop and provide on a public website beneficiary resources regarding privacy and security, including information on how beneficiaries can protect the privacy and security of their health information in non-technical, simple and easy-tounderstand language. We note in section III.C.2.h. of this final rule, that CMS will provide suggested content for educational material payers can use to meet this requirement. States, Medicaid managed care plans, and CHIP managed care entities have vast experience with techniques for creating effective communications for their beneficiaries and we encourage states and managed care plans to tailor these resources for their Medicaid and CHIP populations. We also agree that states and managed care plans will need to develop or refine resources to address patient access for minor populations and for populations based on health literacy levels. We do E:\FR\FM\01MYR2.SGM 01MYR2 25558 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations note that we do not have the authority to regulate vendors. While we agree that API vendors should have a role in educating consumers, states and managed care plans are the entities responsible for developing and implementing the API; therefore, we believe it is more appropriate for states and managed care plans to develop and provide the educational resources for beneficiaries. Comment: A few commenters requested that CMS modify the rule to exempt Medicaid managed care plans. Commenters noted that Medicaid managed care plans are already operating with razor thin margins and the proposed rule will substantially increase the costs for Medicaid managed care plans. Further, commenters noted that due to the substantial increase in costs, plans may not be able to meet the MLR requirements in 42 CFR 438.8. Another commenter suggested that CMS explicitly exclude from the requirements of the rule long-term services and supports (LTSS) plans. Some commenters also recommended that CMS exclude dental plans from the requirements in the proposed rule. Response: We appreciate the commenters’ concerns, however we are not exempting Medicaid or CHIP managed care plans, including LTSS or dental plans, from the requirements in this rule, as such an approach would not be consistent with our goal of ensuring that all beneficiaries across the health care market, including Medicaid FFS and managed care, have access to and can exchange specified health care data. We are finalizing the Patient Access API requirements for state Medicaid and CHIP agencies and managed care plans, including LTSS and dental plans. States and managed care plans must make adjudicated claims and encounter data available through the API for all Medicaidcovered services, including LTSS and dental. This requirement extends to all Medicaid-covered services for which a claim, or encounter claim, is generated and adjudicated. Regarding costs for managed care plans—since the Patient Access API requirements must be contractual obligations under the managed care contract—the state must include these costs in the development of a plan’s capitation rates. Final Action: After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing with modifications our proposal to require MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 plans, CHIP managed care entities, and QHP issuers on the FFEs to implement and maintain a standards-based Patient Access API that meets the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.215, content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and finalized by HHS at 45 CFR 170.213 (USCDI version 1), unless alternate standards are required by other applicable law; includes the data elements specified in this final rule, and permits third-party applications to retrieve, with the approval and at the direction of the enrollee, data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221. Specifically, we are finalizing that the Patient Access API must, at a minimum, make available adjudicated claims; encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results (where maintained by the impacted payer). Data must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received by the impacted payer. We are not finalizing a requirement for the Patient Access API to make provider directory and pharmacy directory information available. Instead, to limit burden, we are only requiring provider and, in the case of MA–PD plans, pharmacy directory information be included in the Provider Directory API discussed in section IV. of this final rule. We are finalizing the proposed documentation requirements noting business and technical documentation necessary to interact with the API must be made freely and publicly accessible. We note that the APIs need to comply with all existing federal and state privacy and security laws. We are finalizing, consistent with the HIPAA Rules that a payer may deny access to the Patient Access API if the payer reasonably determines that allowing a specific third-party application to connect or remain connected to the API would present an unacceptable level of risk to the security of PHI on the payer’s systems based on objective and verifiable criteria. We are also finalizing that payers need to make available to enrollees resources explaining factors to consider in selecting an app for their health information, practical strategies to safeguard their privacy and security, and how to submit complaints to OCR or FTC. We do note that we are providing payers with suggested content they can use and tailor to meet this PO 00000 Frm 00050 Fmt 4701 Sfmt 4700 requirement, available here: https:// www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/ index. We also note that impacted payers are allowed to request that thirdparty apps attest to having certain information included in their privacy policy, and inform patients about this attestation, to help ensure patients are aware of the privacy risks associated with their choices. We are finalizing this policy with the following technical corrections and additional information. At 42 CFR 422.119(a) and (b)(1); 42 CFR 431.60(a) and (b); 42 CFR 457.730(a) and (b); and, 45 CFR 156.221(a) and (b) we specify these policies apply to current patients and their personal representatives. At 42 CFR 422.119(b)(1)(i), (1)(ii), and (2)(i); 42 CFR 431.60(b)(1) and (2); 42 CFR 457.730(b)(1) and (2); and, 45 CFR 156.221(b)(1)(i) and (ii) we are removing the word ‘‘standardized’’ to avoid confusion as the standards are specified elsewhere. We are finalizing the regulation text at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), with the verb ‘‘maintains’’ in place of the verb ‘‘manages’’ in order to more closely align with the relevant HIPAA Privacy Rule requirement. We are finalizing a technical correction at 42 CFR 431.60(b)(2) and 42 CFR 457.730(b)(2) to replace ‘‘within one (1) business day’’ with ‘‘no later than 1 business day after’’ to be consistent across payers. We have added text to specifically indicate that the technical requirements at 42 CFR 422.119(c), 431.60(c), and 457.730(c), and 45 CFR 156.221(c) apply to the API under paragraph (a) of the respective sections. We are finalizing at 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2), to include additional text to explicitly require, as described in the CMS Interoperability and Patient Access proposed rule (84 FR 7635) the requirement to also update (as appropriate) the API to ensure it functions properly and includes assessments to verify an individual enrollee or their personal representative can only access claims and encounter data or other PHI that belongs to that enrollee. In addition, we are removing the word ‘‘minimally’’ from this regulation text in order to ensure it is clear that privacy and security features must be reasonable and appropriate, consistent with the requirements of HIPAA Privacy and Security Rules, 42 CFR parts 2 and 3, and other applicable law protecting privacy and security of individually identifiable health information. We are making a technical E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations change for readability only at 42 CFR 422.119(c)(3) and (4)(ii)(C), 431.60(c)(3) and (4)(ii)(C), 438.242(b)(5), 457.730(c)(3) and (4)(ii)(C), 457.1233(d)(1), and 45 CFR 156.221(c)(3) and (4)(ii)(C). In addition, we have refined the language at 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g) to state the payer must make education materials available ‘‘in an easily accessible location on its public website,’’ and at 42 CFR 422.119(g)(1), 431.60(f)(1), and 457.730(f)(1), and 45 CFR 156.221(g)(1) to include a reference to ‘‘secondary uses of data.’’ At 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 CFR 156.221(d), we are finalizing additional text to specify that ‘‘publicly accessible’’ means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available. In the CMS Interoperability and Patient Access proposed rule, the criteria and process for assessing unacceptable risk to a payers system was explained as part of the payer’s responsibilities under the HIPAA Security Rule (84 FR 7635). At 42 CFR 422.119(e)(1), 431.60(e)(1), 438.242(b)(5), 457.730(e)(1), and 457.1233(d), as well as 45 CFR 156.221(e)(1) we are finalizing additional text to note that payers should determine risk consistent with its security risk analysis under 45 CFR part 164 subpart C to indicate the specific section of the HIPAA Security Rule implicated here. We are modifying 45 CFR 156.221(h)(2) to remove the reference to ‘‘qualified employers’’ and 45 CFR 156.221(i) to include applicability to ‘‘individual market’’ FFEs to exclude issuers offering plans through the FF–SHOPs. Finally, we are finalizing for MA organizations at 42 CFR 422.119(h), Medicaid FFS programs at 42 CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii), CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at 42 CFR 457.1233(d), that beginning January 1, 2021, and for QHP issuers on the FFEs at 45 CFR 156.221(i) beginning with plan years beginning on or after January 1, 2021, these payers must make available through the Patient Access API data they maintain with a date of service VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 on or after January 1, 2016, consistent with the payer-to-payer data exchange requirement discussed in section V. of this final rule. IV. API Access to Published Provider Directory Data Provisions, and Analysis of and Responses to Public Comments A. Interoperability Background and Use Cases In section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7626 through 7639), we focused on patient access to their own data through a standardized, transparent API—the Patient Access API. As part of this proposal, we discussed and sought comment on requiring payers at 42 CFR 422.119(b)(1)(iii) and (b)(2)(ii) for MA organizations, 42 CFR 431.60(b)(3) for Medicaid FFS programs, 42 CFR 438.242(b)(6)(ii) for Medicaid managed care plans, 42 CFR 457.730(b)(3) for CHIP FFS programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed care entities to provide their provider directory information through that same Patient Access API. In addition, the proposed rule sought comment on making the provider directory information available through a publicfacing standards-based API. As we discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7639), making provider directory information available through a publicfacing API raised different issues than API access proposals related to patient data. Based on our consideration of public comments summarized and responded to below, and in an effort to avoid duplicative effort and additional burden resulting from having the provider directory information included in both the Patient Access API and the Provider Directory API, we are finalizing the requirement for a publicfacing Provider Directory API at 42 CFR 422.120 for MA organizations, 42 CFR 431.70 for Medicaid FFS programs, 42 CFR 438.242(b)(6) for Medicaid managed care plans, 42 CFR 457.760 for CHIP FFS programs, and 42 CFR 457.1233(d)(3) for CHIP managed care entities, but we will not finalize our proposal to also provide access to this provider directory information through the Patient Access API at 422.119, 42 CFR 431.60, 42 CFR 438.242(b)(6), 42 CFR 457.730, and 42 CFR 457.1233(d)(2), respectively. Provider directories make key information about health care professionals and organizations available to help consumers identify a provider when they enroll in an insurance plan or as new health needs PO 00000 Frm 00051 Fmt 4701 Sfmt 4700 25559 arise. For example, such information might include hours of operation, languages spoken, specialty/services, and availability for new patients. Provider directories also function as a resource used by the provider community to discover contact information of other providers to facilitate referrals, transitions of care, and care coordination for enrollees. As discussed in the CMS Interoperability and Patient Access proposed rule, the current applicable regulations for MA plans (42 CFR 422.111) and Medicaid and CHIP managed care plans (42 CFR 438.10(e)(2)(vi) and (h) and 457.1207, respectively) already require that provider directories be made available to enrollees and potential enrollees in hard copy and on the plan’s website. Section 1902(a)(83) of the Act requires state Medicaid agencies to publish a directory of certain physicians on the public website of the State agency. A regulation for QHP issuers (45 CFR 156.230(b)) requires public access to the QHP’s provider directory in addition to distribution and access for enrollees. In addition to mandating that this information be accessible, the current regulations also address the content of such directories and the format and manner in which MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs must make the information available. Making this required provider directory information available to enrollees and prospective enrollees through an API could support development of third-party software applications, or apps, (whether standalone or integrated with providers’ EHR technology) that would pull in current information about available providers to meet enrollees’ current needs. Broad availability of provider directory data through interoperable API technology would also allow for innovation in applications or other services that help enrollees and prospective enrollees to more easily compare provider networks while they are considering their options for changing health plans. Finally, we noted in our proposal that a consistent, FHIR-based API-driven approach to making provider directory data accessible could reduce provider burden by enabling payers to more widely share basic information about the providers in their networks, such as provider type, specialty, contact information, and whether or not they are accepting new patients. E:\FR\FM\01MYR2.SGM 01MYR2 25560 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations B. Broad API Access to Provider Directory Data In sections III.C. and IV. of the CMS Interoperability and Patient Access proposed rule (84 FR 7633, 7639 through 7642), we proposed to require at 42 CFR 422.119(b)(1)(iii) for MA organizations, 42 CFR 431.60(b)(3) for Medicaid FFS programs, 42 CFR 438.242(b)(6)(ii) for Medicaid managed care plans, 42 CFR 457.730(b)(3) for CHIP FFS programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed care entities that payers subject to the proposed rule make standardized information about their provider networks available through API technology, so that the public, including third-party app developers and patients, could access and use that information, including republishing the information or information derived from that information in a user-friendly way. As discussed in the preamble of the CMS Interoperability and Patient Access proposed rule, we sought comment on making provider directory information more generally available (84 FR 7639 through 7642). We discussed requiring that the API technology conform to the API standards proposed by ONC for HHS adoption at 45 CFR 170.215 (84 FR 7589). Currently, because QHP issuers on the FFEs are already required to make provider directory information available in a specified, machinereadable format,42 we did not propose that QHP issuers would have to make provider directory information available through an API. However, we requested information regarding whether this same requirement should apply to QHP issuers, or if such a requirement would be overly burdensome for them. We thank commenters for their insights on this request for information and are reviewing the comments received for inclusion in potential future rulemaking. We noted in the preamble of the proposed rule that, since this provider directory information is already available and accessible to enrollees without cost to them under existing law, this information should be as accessible through the API as it is required to be when posted on the organization’s websites. Therefore, we proposed that the technical standards proposed (now finalized) by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.215 (specifically at paragraphs (a)(3) and (b)) that are specific to authenticating users and 42 Available at https://cmsgov.github.io/QHPprovider-formulary-APIs/developer/. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 confirming individuals’ authorization or request to disclose their personal information to a specific application through an API, namely the SMART IG (using the OAuth 2.0 standard) and OpenID Connect Core 1.0, should not apply to our proposed public access to provider directory information through APIs (84 FR 7639). We noted that while we were aware the organization will nevertheless need to take appropriate steps to mitigate the potential security risks of allowing any application to connect to the API through which it offers provider directory access, we emphasized that these steps should be appropriate to the level of risk associated with the specific use case of accessing otherwise public information through API technology. We also noted that those wishing to access these data should not be unduly burdened by security protocols that are not necessary to provide the appropriate degree of protection for the organization’s systems and data. As referenced in sections II. and III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7618 through 7639), we intended to develop additional guidance, incorporating feedback from industry that provides implementation best practices relevant to FHIR-conformant standards-based APIs to help organizations subject to the requirements proposed in this rulemaking. To that end, we solicited comment on what specific resources would be most helpful to organizations implementing APIs under requirements proposed in the proposed rule. We summarize all public comments we received on making provider directory information available through an API—in terms of requiring a dedicated, publicly accessible Provider Directory API and more generally sharing provider directory information via an API, including as proposed under the Patient Access API discussed in section III. of this final rule and provide our responses. Comment: Many commenters supported a requirement for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to make standardized information about their provider networks available through API technology to current enrollees, prospective enrollees, and possibly the general public. Commenters stated that they believe accurate provider directory data will improve transparency and accessibility of information regarding a provider’s network status, which will help with efforts to address surprise billing and PO 00000 Frm 00052 Fmt 4701 Sfmt 4700 other coverage issues related to whether providers are in or out-of-network. Response: We thank commenters for their support. Appreciating that provider information is already publicly available, and unlike the other information included in the Patient Access API discussed in section III. of this final rule, is of a less sensitive nature, to avoid potential confusion and reduce burden resulting from having the provider directory information included in both the Patient Access API and the Provider Directory API, we are only requiring that one API—the Provider Directory API—provide access to provider directory information. As a result, we are finalizing additional regulation text to require the Provider Directory API at 42 CFR 422.120 for MA organizations; at 42 CFR 431.70 for Medicaid state agencies; at 42 CFR 438.242(b)(6) for managed care plans; at 42 CFR 457.760 for CHIP state agencies; and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. This Provider Directory API must include the same information about the provider directory as originally proposed for the Patient Access API. Specifically, the Provider Directory API must include provider directory data on a payer’s network of contracted providers, including names, addresses, phone numbers, and specialties, updated no later than 30 calendar days after a payer receives provider directory information or updates to provider directory information. We are finalizing the applicable regulation text with the phrase ‘‘complete and accurate’’ to emphasize our intent that the directory data meet this standard. For MA organizations that offer MA–PD plans, the Provider Directory API must also make available pharmacy directory data, we are specifying that the plans must make available, at a minimum, pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as ‘‘retail pharmacy’’). As with the provider directory information, we are finalizing that pharmacy directory information must be updated no later than 30 calendar days after the MA organization that offers the MA–PD plan receives pharmacy directory information or updates to pharmacy directory information. Comment: Some commenters disagreed with the proposal. They stated that payers are already required to make this information available and this proposal could result in unnecessary duplication of effort and additional costs. One commenter suggested CMS provide an exemption for payers that are E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations already providing this information in a manner that aligns with the requirements in the proposed rule. Response: We appreciate the commenters’ concern about potentially duplicative effort. While we understand that different payers are already required to make this information available in a machine readable format or on a public website according to the different rules associated with each program, we believe that making this information available through a standardized API will bring additional benefits to enrollees and prospective enrollees by making it easier for developers to incorporate this information into consumer-facing applications. We note that we did not propose to extend the requirement regarding provider directory information to QHP issuers on the FFEs, as these issuers are already required to make provider directory information available according to a specific standard for the electronic transfer of this information, as discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7633). Comment: Many commenters raised concerns about the accuracy of provider directory information that would be available through the API, and how these inaccuracies can have a negative impact on consumers. One commenter stated that there is a high prevalence of inaccurate provider directories issued by MA organizations, in particular, and for other public and private payers, generally, and that this can bring into question the adequacy and validity of a network. Another noted that inaccurate provider directories have also resulted in patients receiving surprise bills as a result of seeing an out-of-network physician. Commenters expressed concern that making provider directory information more accessible through an API could exacerbate the impact of inaccuracies resulting in conflicting and confusing information for consumers, for instance, where an enrollee participates in two plans and receives different information about the same provider from each. Commenters discussed a variety of steps that CMS should take in concert with the proposal to ensure that provider directory information made available through the API is tested to ensure it is current, correct, and accurate. One commenter suggested CMS require payers to provide API vendors with accurate provider directory information. Response: We appreciate commenters’ concerns and thank the commenters for their suggestions. We have taken a number of steps to improve the accuracy VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 of provider directory information for plans subject to direct regulation by CMS, such as implementing a process to audit directory information with MA organizations to identify deficiencies in an effort to increase data accuracy (for more information see https:// www.cms.gov/Medicare/Health-Plans/ ManagedCareMarketing/Downloads/ Provider_Directory_Review_Industry_ Report_Round_3_11-28-2018.pdf). We will take the suggestions provided into consideration as we continue this effort. We encourage all enrollees to check with a new provider about network participation to avoid surprises and continue to explore ways to work with the payers that we directly regulate (like MA organizations) to improve the accuracy of directories. We are finalizing regulation text on the Provider Directory API at 42 CFR 422.120(b), 431.70(b), 438.242(b)(6), 457.760(b), and 457.1233(d)(3) to require that accurate and complete provider directory information be made available through the API. We believe that this language will clarify our expectation that payers take steps to ensure provider directory information made available through the API accurately reflects the current providers within the payer’s network. Commenter: Several commenters responded to our proposal that impacted payers update provider directory information made available through the API to current and prospective enrollees within 30 days of receiving an update to their directory information. The commenters suggested that CMS should decrease the amount of time allowed for updates; for instance, one commenter suggested that CMS should require that provider directory information is updated within 48 hours of a change, while another recommended directory updates occur in real time, or on a regular basis as frequently as possible. Some commenters who supported the requirement that provider directories be publicly available through API technology specifically expressed concerns with how frequently directories must be updated in the case of Medicaid and CHIP programs. One commenter recommended that the clock for the 30-day requirement begins from the date the state provides the information to the Medicaid or CHIP managed care plan. Another commenter recommended that entities should be required to update provider directories in real-time. Response: We appreciate commenters’ suggestions, and agree that more frequent updates of the provider directory information made available PO 00000 Frm 00053 Fmt 4701 Sfmt 4700 25561 through the API could help to increase the accuracy of this information. Our proposed 30-day time frame was not intended to preclude payers from updating the information available via the API on a shorter timeframe, or from making updates in real time. However, we understand that payers may have different operational processes for making updates to their provider directories and are seeking to set a minimum floor for how frequently information available through the API must be updated. This is consistent with timeframes for other updates some of these payers are required to make. For instance, Medicaid managed care plans must update paper provider directories monthly and electronic provider directories no later than 30 days after the plan receives the updated information under § 438.10(h)(3). The Provider Directory API regulations finalized here require that state Medicaid and CHIP agencies, and managed care plans, make available through the API provider directory information no later than 30 calendar days after the state or managed care plan receives the provider directory information or updates to the provider directory information. We confirm that the state or managed care plan must make the provider directory information available through the API within 30 calendar days of receiving the information. This timeframe for managed care plans is consistent with the requirement in § 438.10(h)(3) for Medicaid managed care plans, which applies to CHIP managed care entities under § 457.1207. We decline to require updates to provider directories in real-time as we do not believe that such a timeframe is operationally feasible for MA organizations, states or Medicaid and CHIP managed care plans at this time. We are finalizing our proposal that MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities update provider directory information made available through this API within 30 days of receiving a change as proposed. Comment: Several commenters believe that, in order to increase the accuracy of provider directory data, CMS should take steps to hold providers responsible for the accuracy of their provider directory information. One commenter suggested CMS require health care providers to update their information with a centralized entity, for instance a trusted health information exchange, rather than looking to impacted payers to include these mandates in their contracts with E:\FR\FM\01MYR2.SGM 01MYR2 25562 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations providers. Another suggested that CMS should require providers to submit rosters to CMS each month indicating which health plans they contract with, enabling CMS to validate information provided through the proposed API. Another commenter suggested CMS ensure that CMS-regulated payers are provided with updated provider information in a timely manner by making such reporting requirements a condition of participation in Medicare. Response: We appreciate commenters’ suggestions, and agree that providers have an important role to play in ensuring that provider directory information about them, provided to, and used by the payers with which they contract or participate, is up-to-date. While we did not include any proposals in this rulemaking specifically focused on provider responsibility for updating the information to be made available through the proposed API, we will continue to work with federal and industry partners to identify opportunities to improve the accuracy of provider directory information across the health care system. Comment: Several commenters noted that a centralized repository that can serve as a ‘‘source of truth’’ for provider directory information is needed to ensure accuracy, and urged CMS to support work across stakeholders for such an approach. One commenter noted that health information exchanges (HIEs) could help payers to update their information through access to the directories that HIEs use for clinical data exchange. Response: We thank commenters for their input. Our policy is focused around payers making provider directory information available through APIs to provide greater access to specific information on the providers in their networks. However, we believe entities focused on aggregating provider directory information can serve an important role, and we encourage payers to work with partners that maintain this information to improve accuracy. Comment: Several commenters suggested additional information for inclusion as part of the provider directory information made available through the API for current and prospective enrollees (in addition to provider names, addresses, phone numbers, and specialties), such as NPIs for individual and group providers, practice group name, health system name, as well as the specific plan(s) and tiers a provider participates in. One commenter also suggested including minimum provider demographics to be included in the clinical and VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 administrative transactions to ensure accurate provider matching; whether the provider is accepting new patients; information about which providers are in-network for a plan by geography and/ or specialty regardless of whether the individual is a member of a particular plan or is researching plan options; and which clinicians are in-network for care coordination and plan switching purposes. Response: We appreciate commenters’ suggestions and agree that this additional information may be helpful to consumers. However, at this time we are seeking to minimize the burden for the regulated payers that must comply with this proposal, and have sought to identify a minimum set of provider directory information that aligns with existing requirements applicable to MA organizations (including MA organizations that offer MA–PD plans), state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities regarding such directories. We do encourage payers to explore how they can make additional provider directory data available through the API to most benefit current and prospective enrollees. Also, we note that the requirements in this final rule set out the minimum requirements; payers are strongly encouraged to go beyond that minimum, if and as possible, to make useful information available for their enrollees and beneficiaries. Comment: One commenter who supported our proposal also urged CMS to take additional steps to make provider directories more accessible to enrollees, for instance by integrating a provider directory in future iterations of Plan Finder for MA plans, and ensuring the directory data is accurate and up to date. Response: We thank the commenter for the suggestions. We will take these suggestions into consideration. Comment: Several commenters addressed issues with technical standards for provider directory information, with several stating that appropriate standards for making this information available through an API are still emerging. For instance, one commenter noted that current provider directory standards were written for FHIR Release 3 and that the standard has not been adopted by the field. The commenter stated that before CMS requires payers to make provider directory information available via a standards-based API, more work is needed to build the provider directory specification in FHIR Release 4. Several commenters suggested that CMS should delay implementing this PO 00000 Frm 00054 Fmt 4701 Sfmt 4700 proposal, proposed to be applicable starting January 1, 2020, until stakeholders have been able to establish consensus-based standards for the creation and display of directory information. One commenter encouraged CMS to develop a voluntary, multi-stakeholder partnership to establish data content FHIR-based standards related to provider directories and then wait to establish the timeframe for provider directory data updates until the development of these FHIR-based standards are completed. Response: We appreciate commenters’ concerns, and agree that updated FHIRbased provider directory implementation guidance is important for implementation of this policy. We confirm here that HL7 FHIR Release 4.0.1—the API standard adopted at 45 CFR 170.215 and which must be used under our Provider Directory API requirement—provides a base standard for moving information through an API. The basic information (name, phone number, address, and specialty) required for this Provider Directory API can all be represented through FHIR Release 4.0.1. Additional implementation guidance will provide additional information for how to use the FHIR Release 4.0.1 base standard to make provider directory information available and ensure greater uniformity in implementation and reduce implementation burden for payers. As noted in section III. of this final rule, we have been working with HL7 and partners to ensure the necessary consensus-based standards and associated guidance are available so that impacted payers can consistently implement all of the requirements included in this final rule. We are providing a link to a specific FHIR Release 4.0.1 implementation guide and reference implementation for all interested payers for the Provider Directory API that provide valuable guidance to further support sharing the needed data using the required standards: https://www.cms.gov/ Regulations-and-Guidance/Guidance/ Interoperability/index. Though not mandatory, using this guidance will lower payer burden and support consistent implementation of the FHIR Release 4.0.1 APIs. Appreciating the time needed for payers to build, implement, and test these APIs, we are providing additional time for implementation, and are finalizing January 1, 2021 as the implementation date for the Provider Directory API for all payers subject to this requirement. Appreciating the value of making this information publicly accessible, we do encourage payers to E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations implement this Provider Directory API as soon as they are able. We are requiring at 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities that these payers make the Provider Directory API accessible via a public-facing digital endpoint on their website. We will check a random sample of payer websites for links to these publicly accessible APIs, starting in January 2021 to evaluate compliance. Comment: One commenter suggested that, as CMS already requires provider directory information to be made available online by payers subject to this rule, for interoperability transactions CMS should require use of a standard described as ‘‘the HIPAA 274 transaction.’’ The commenter stated that the metadata defined within this transaction can drive a consistent payload for an API to support provider directory information sharing. Response: We appreciate the commenter’s suggestion, but at this time we are finalizing requirements for provider directory information to be available through an API using the standards at 45 CFR 170.215, including, FHIR Release 4.0.1 standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) to consistently align all various API formats throughout the rule with a single modern standard capable of meeting all requirements. CMS understands that some information within the X12 274 Transaction (Healthcare Provider Information Transaction Set for use within the context of an Electronic Data Interchange (EDI) environment) may provide the basic provider information to support an API. HHS, however, has not adopted the X12 274 transaction standard under HIPAA or for any other use. Moreover, the required availability of a plan’s entire provider directory via an API is not a HIPAA transaction that has been defined or associated with a specific transaction under HIPAA. We believe that using FHIR Release 4.0.1 for the purpose of this Provider Directory API will provide greater long term flexibility for payers subject to this rule, allowing them the ability to meet minimum requirements, and extend beyond these requirements based on the industry’s diverse and evolving needs surrounding provider directories, while reducing impact on those who may not be ready to receive additional VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 information beyond the minimum set of data required by this final rule. Comment: One commenter requested that CMS ensure public health agencies are also able to access provider directory information made available through the API, while another commenter requested that approved agents and brokers be granted access to this information. Response: Under this final rule, the Provider Directory API must be publicly accessible, so that any third party can access an impacted payer’s provider directory information. Our regulation text reflects this by requiring that the Provider Directory API be accessible via a public-facing digital endpoint on the applicable payer’s website. The value of making this information available via an API is that third-party developers will be able to access it to make it available in valuable and useful ways for all interested stakeholders. We therefore anticipate that public health agencies, agents, and brokers, and any other member of the public would be able to access these data via third-party apps. Comment: Several commenters suggested CMS require payers to include other types of non-physician professionals within their provider directories, such as nurse practitioners, certified registered nurse anesthetists, physical therapists, and post-acute care providers. Commenters stated that including additional qualified licensed non-physician providers could help increase patient access to care. Response: We appreciate commenters’ suggestions. We did not propose to change the parameters of the information required to be included in provider directories for the payers subject to the Provider Directory API requirement here. Existing requirements for paper and on-line provider directories, such as those in 42 CFR 422.111 and 438.10(h), are not changed or limited by this final rule. Instead, our API proposals and this final rule focus on making certain payers (that is, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities) share provider directory information through an API. How ‘‘provider’’ is defined in this context is outside the scope of this regulation. Comment: One commenter recommended that CMS amend the API requirement to also include FHIR endpoint information for providers as part of provider directory information, to ensure access to regional/national directories in addition to the current partial ones. Response: We agree with commenters that FHIR endpoint information is PO 00000 Frm 00055 Fmt 4701 Sfmt 4700 25563 important to improve interoperability across providers. We discuss FHIR endpoints in section IX. of this final rule. For this Provider Directory API, we have focused on a minimum set of information of primary interest to patients and typically found in provider directories. However, we encourage payers to consider including other data elements that may add value to the Provider Directory API. We may consider expanding this minimum set of information in potential future rulemaking. Comment: One commenter suggested that CMS impose penalties on plans that do not comply with the provider directory requirement. Response: We thank the commenter for this suggestion. We did not propose to establish additional penalties for noncompliance with the requirement to make provider directory information available through an API; however, we note that the requirement to make provider directory information available through an API will be a requirement for MA organizations, Medicaid managed care plans and CHIP managed care entities to fulfill under their contracts in their respective programs. Therefore, existing enforcement authority for ensuring compliance with those contracts will apply. Further, the API requirements, including the provider directory components of the required API(s) will be required for state Medicaid and CHIP agencies operating FFS Medicaid programs and CHIPs. Final Action: After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing regulations to require that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities make standardized information about their provider networks available via a FHIR-based API conformant with the standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.215 (including FHIR Release 4.0.1), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to anyone wishing to access it. At a minimum, these payers must make available via the Provider Directory API provider names, addresses, phone numbers, and specialties. For MA organizations that offer MA–PD plans, we are specifying that they must make available, at a minimum, pharmacy E:\FR\FM\01MYR2.SGM 01MYR2 25564 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations directory data, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as ‘‘retail pharmacy’’), updating the regulation text from the proposed rule, which simply stated ‘‘number, mix, and addresses of network pharmacies’’. All directory information must be available through the API within 30 calendar days of a payer receiving the directory information or an update to the directory information. We note we have also revised the proposed regulation text for making directory information available through an API to specify consistently that the directory information must be complete and accurate and that updates must be made in ‘‘calendar’’ days. The Provider Directory API is being finalized at 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. We are finalizing that access to the published Provider Directory API must be fully implemented by January 1, 2021 for all payers subject to this new requirement. We encourage payers to implement this Provider Directory API as soon as they are able to make and show progress toward the API requirements in this final rule and to signal their commitment to making the information that will empower their patients easily accessible and usable. Under this final rule, MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must make the Provider Directory API accessible via a public-facing digital endpoint on their website to ensure public discovery and access. V. The Health Information Exchange and Care Coordination Across Payers: Establishing a Coordination of Care Transaction To Communicate Between Plans Provisions, and Analysis of and Responses To Public Comments We proposed a new requirement for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to require these payers to maintain a process to coordinate care between payers by exchanging, at a minimum, the USCDI at the enrollee’s request as specified in the proposed regulation text. Instead of specifically proposing use of the USCDI, we proposed use of a content standard adopted by ONC at 45 CFR 170.213, which was proposed in a companion proposed rule, the ONC 21st Century VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Cures Act proposed rule as the USCDI (version 1) (84 FR 7441 through 7444). Understanding that enrollees’ information is already exchanged between plans for use in carrying out various plan functions,43 payers have experience exchanging, receiving, and incorporating data from other plans into an enrollee’s record. We proposed requiring the USCDI data set be exchanged at the enrollee’s direction, and when received by a payer, incorporated into the recipient payer’s data system. As proposed, upon request from an enrollee, the USCDI data set would have to be sent to another payer that covers the enrollee or a payer identified by the enrollee at any time during coverage or up to 5 years after coverage ends, and the payer would have to receive the USCDI data set from any payer that covered the enrollee within the preceding 5 years. These proposals were intended to support patient directed coordination of care; that is, each of the payers subject to the requirement would be required to, upon an enrollee’s request: (1) Receive the data set from another payer that had covered the enrollee within the previous 5 years; (2) send the data set at any time during an enrollee’s enrollment and up to 5 years later, to another payer that currently covers the enrollee; and (3) send the data set at any time during enrollment or up to 5 years after enrollment has ended to a recipient identified by the enrollee. We identified in the proposed rule that this proposal is based on our authority under sections 1856(b) and 1857(e) of the Act to adopt standards and contract terms for MA plans; section 1902(a)(4) of the Act to adopt methods of administration for state Medicaid plans, including requirements for Medicaid managed care plans (MCOs, PIHPs, and PAHPs); section 2101(a) of the Act for CHIP managed care entities (MCOs, PIHPs, and PAHPs); and section 1311(e)(1)(B) of the Affordable Care Act for QHP issuers on the FFEs. We explained in the CMS Interoperability and Patient Access proposed rule our belief that the proposal will help to reduce provider burden and improve patient access to their health information through coordination of care between payers (84 FR 7640 through 7642). We also noted that the CHIP regulations incorporate and apply, through an existing cross43 See Office for Civil Rights. (2016, August 16). 3014–HIPAA and Health Plans—Uses and Disclosures for Care Coordination and Continuity of Care. Retrieved from https://www.hhs.gov/hipaa/ for-professionals/faq/3014/uses-and-disclosuresfor-care-coordination-and-continuity-of-care/ index.html. PO 00000 Frm 00056 Fmt 4701 Sfmt 4700 reference at 42 CFR 457.1216, the Medicaid managed care plan requirements codified at 42 CFR 438.62(b)(1)(vi). Therefore, the proposal for Medicaid managed care plans described also applied to CHIP managed care entities even though we did not propose new regulation text in part 457. We proposed that this new requirement would be applicable starting January 1, 2020 for MA organizations, Medicaid managed care plans, CHIP managed care entities, and beginning with plan years beginning on or after January 1, 2020 for QHP issuers on the FFEs. Among other topics related to the proposal, we solicited comments on the proposed date these policies would be applicable. We proposed to codify this new requirement at 42 CFR 422.119(f) for MA organizations; at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care plans (and by extension under existing rules at 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(f) for QHP issuers on the FFEs. The proposed new requirement was virtually identical for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, with modifications in the proposal necessary for specific payer types to account for the program needs of each. The proposed regulation text references the content standard adopted at 45 CFR 170.213, which ONC proposed as the USCDI (version 1) data set (84 FR 7441 through 7444). We noted we believed that exchanging this data set would help both enrollees and health care providers coordinate care and reduce administrative burden to ensure that payers provide coordinated high-quality care in an efficient and cost-effective way that protects program integrity. For a full discussion of the benefits we anticipate from this data exchange requirement, see the discussion in the CMS Interoperability and Patient Access proposed rule (84 FR 7640). In addition to the benefits for care coordination at the payer level and reduced provider burden, we noted that once the requested information, as specified by the USCDI standard, was made available to the patient’s current plan, the enrollee would have access to multiple years of their health information through the proposed Patient Access API, discussed in section III.C. of the CMS Interoperability and Patient Access proposed rule and in this final rule. This is the case because the proposal required the receiving payer to incorporate the received data into its records about the patient, therefore making these data the payer maintains, and data available to share with the E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations patient via the Patient Access API. The USCDI data set includes clinical data points essential for care coordination. Access to these data would provide the patient with a more comprehensive history of their medical care, helping them to make better informed health care decisions. We sought comment on how plans might combine records and address error reconciliation or other factors in establishing a more longitudinal record for each patient. We proposed to allow multiple methods for electronic exchange of the information, including use of the APIs proposed in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7627 through 7639), to allow for patient-mediated exchange of payer information or direct payer-to-payer communication, subject to HIPAA requirements, 42 CFR part 2, and other applicable federal and state laws. We noted that we considered requiring the use of the FHIR-based API discussed in section III. of the proposed rule for this information exchange; however, we understood that some geographic areas might have a regional health information exchange (HIE) that could coordinate such data transfers for any HIE-participating MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs that are subject to the proposal. We sought comment on whether it would be beneficial to interoperability and patient care coordination for us to require the use of the FHIR-based API otherwise proposed, and whether this should be the only mechanism allowed for this exchange, or whether multiple methods for electronic exchange of the information should be allowed under the proposed policy and whether CMS might be able to leverage its program authority to facilitate the data exchanges contemplated by the proposal. We expected enrollees to have constant access to requesting an exchange of data as the proposal would require exchange of the USCDI data set whenever an enrollee makes such a request, which may occur at times other than enrollment or disenrollment. We acknowledged that in some cases payers subject to the proposed requirement may be exchanging patient health information with other payers that are not similarly required to exchange USCDI data sets for enrollees, for example, if a consumer changes their health coverage from a QHP on an FFE to employer-sponsored coverage, and we requested comment on how to support patients and providers in those situations. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 We also proposed that a patient should be able to request his or her information from their prior payer up to 5 years after dis-enrollment, which is considerably less than existing data retention policies for some of the payers.44 Further, we proposed that the health information received as part of the USCDI (version 1) data set under our proposal would have to be incorporated into the IT and data systems of each payer that receives the USCDI data set under the proposed requirement, such that the enrollee’s data would be cumulative and move with the enrollee as he or she changes enrollment. For example, if a patient is enrolled in Plan 1 in 2020 and Plan 2 in 2021, then requests the data from Plan 1 to be sent to Plan 2, Plan 2 would have at least 2 years (2020 and 2021) of health information for that patient. If the patient moves to Plan 3 in 2022, Plan 3 should receive both 2020 and 2021 data from Plan 2 at the patient’s request. While the proposal would require compliance (and thus exchange of these data sets) only by MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, we noted that we hoped that compliance by these payers could be the first step toward adoption and implementation of these standards on a voluntary basis by other payers throughout the health care system. Research indicates that the completeness of a patient record and the availability of up-to-date and relevant health information at the point of care can have a significant impact on patient outcomes.45 We noted that we believe the proposal for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to exchange the USCDI data set in particular scenarios would support improvement in care coordination by allowing for sharing of key patient health information when an enrollee requests it. We proposed that the payers subject to this new requirement would be required to exchange, at a minimum, the data classes and elements included in the content standard proposed to be adopted at 45 CFR 170.213 in the ONC 21st Century Cures Act proposed rule, specifically, the USCDI (version 1) data 44 Under 42 CFR 422.504(d) and 438.3(u), MA organizations and Medicaid managed care plans, and CHIP plans must retain records for at least 10 years. Under 45 CFR 156.705; 45 CFR 155.1210(b)(2), (3) and (5), QHP issuers on the FFEs must also retain records for 10 years. 45 Office of the National Coordinator. (2019, June 4). Improved Diagnostics & Patient Outcomes. Retrieved from https://www.healthit.gov/topic/ health-it-and-health-information-exchange-basics/ improved-diagnostics-patient-outcomes. PO 00000 Frm 00057 Fmt 4701 Sfmt 4700 25565 set. On behalf of HHS, ONC proposed to adopt the USCDI as a standard (84 FR 7441 through 7444), to be codified at 45 CFR 170.213, and the proposed regulation text cross-references this regulation. These data exchanges would provide the enrollee’s new payer with a core set of data that could be used to support better care coordination and improved outcomes for the enrollee. We considered requiring plans to exchange all the data that we proposed be available through an API (see section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7627 through 7639)) but we understood that ingesting data and reconciling errors has challenges and proposed this more limited data set to address those concerns. We sought comment on whether the USCDI data set would be comprehensive enough to facilitate the type of care coordination and patient access described in the proposal, or whether additional data fields and data elements that would be available under the API proposal in section III. of the CMS Interoperability and Patient Access proposed rule (84 FR 7627 through 7639) should also be required. For a full discussion of the benefits of the USCDI for this data exchange, see the CMS Interoperability and Patient Access proposed rule (84 FR 7641). We stated that we believed that the proposed requirement would also support dually eligible individuals who are concurrently enrolled in MA plans and Medicaid managed care plans. Under the proposal, both of the dually eligible individual’s payers would be subject to the requirement to exchange that individual’s data in the form of the USCDI, which should improve the ability of both payers to coordinate care based on that data, as discussed in the CMS Interoperability and Patient Access proposed rule (84 FR 7642). We sought comment on how payers should coordinate care and exchange information for dually eligible individuals. We also sought comment on the associated burden on plans to exchange the USCDI data set under the proposal. In addition, we noted that we were interested in comments about potential legal barriers to exchanging the USCDI data set as would be required under the proposal; for example, whether there were federal, state, local, and tribal laws governing privacy for specific use cases (such as in the care of minors or for certain behavioral health treatments) that would raise additional considerations that we should address in this regulation or in guidance. We stated that activities related to the proposed requirement could qualify as a quality improvement activity (QIA) E:\FR\FM\01MYR2.SGM 01MYR2 25566 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations meeting the criteria described in section 2718(a)(2) of the PHSA for purposes of the Medical Loss Ratio (MLR) requirements for QHP issuers on an FFE,46 and similar standards for treatment of QIA standards applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP managed care entities under 42 CFR 457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490. An entity’s MLR is generally calculated as the proportion of revenue spent on clinical services and QIA. There are several specific criteria an expense must meet, such as being designed to improve health quality and health outcomes through activities such as care coordination, in order to qualify as QIA.47 We requested comments related to this assumption and its implications. We summarize the public comments we received on the payer-to-payer data exchange, as well as on whether these new activities may qualify as QIA for MLR purposes, and provide our responses. Comment: Many commenters were very supportive of this proposal and indicated their belief that these new data exchange requirements could improve care coordination by reducing burden on both beneficiaries and providers by limiting the need for duplicative letters of medical necessity, preventing inappropriate step therapy, and reducing unnecessary utilization reviews and prior authorizations. Response: We appreciate the commenters’ support for this payer-topayer data exchange proposal. We are finalizing this proposal with some modifications as detailed below. Under this final rule, payers subject to this requirement must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.213, which is currently version 1 of the USCDI. We are also finalizing that payers must use this process to exchange the USCDIdefined data set with the approval and at the direction of a current or former enrollee, or the enrollee’s personal representative, to align with the language used for the API requirements. Furthermore, we are finalizing the 46 While this rulemaking is specific to QHP issuers participating on the FFEs, we note that to the extent other commercial market issuers incur similar costs for coverage sold in the individual or group markets, those expenses may similarly qualify as QIA. 47 See, for example, 45 CFR 158.150 and 45 CFR 158.151. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 proposal that upon receipt, the receiving payer must incorporate the data set into the payer’s own records about the enrollee with a clarification that this obligation applies to records about current enrollees. We clarify here that incorporating the data into the payer’s records under this specific regulation would not require that the payer treat or rely on these data as its own, but that the payer must include these data in the record it maintains for each enrollee. While the obligation to incorporate data received from other payers into the receiving payer’s records applies only for data about current enrollees, once incorporated, these data must be maintained even after a current enrollee leaves the payer’s coverage. We do not want to be overly prescriptive about how these data are used by each payer at this time. Initially, we are only requiring that these data are incorporated into the existing record to facilitate the creation and maintenance of a patient’s cumulative health record with their current payer. In subsequent rulemaking, however, we may be more specific, depending on proposed use cases, and propose more prescriptive use of specific data. Comment: Some commenters expressed concern about each payer’s increased access to clinical information impacting coverage decision-making. Commenters noted that while historically physicians have controlled the patient’s clinical data in determining what to submit to obtain reimbursement for care provided, payers would now have access to information outside of the scope of the specific service being billed by a provider. Commenters noted that a payer may access the exchanged health data from a prior payer and determine that a patient has already received treatment for a condition and deny, delay, and/or require prior authorization for allegedly duplicative treatment. Additionally, a few commenters expressed concern that payers may use prior information to restrict coverage for medically necessary care that a patient may have received previously. A few commenters recommended that CMS require that payers must attest that the exchanged data cannot be used to deny or delay treatment, increase rates, or implement step therapy. Response: We appreciate the commenters’ concerns. We note that this regulation does not make any changes to when payers can deny coverage. The data received via this data exchange must be used per all applicable law, regulation, and in accordance with payer contracts as it relates to coverage decisions and, specifically, coverage PO 00000 Frm 00058 Fmt 4701 Sfmt 4700 denial. Nothing in this regulation changes any existing obligations or policies related to coverage or services. Further, as proposed and finalized, the regulations regarding the exchange of data among payers is triggered by an enrollee’s request that the information be sent or received and incorporated. The individual enrollee retains control in this situation and can refrain from requesting information be sent to a new or current payer. We do note, however, that there are currently scenarios where payers can exchange data without an enrollee’s request, such as for payment and health care operations. Comment: Several commenters were concerned about the responsibility of MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to forward information from other payers or information from outside their organization where they did not control data integrity. Also, commenters were concerned there might be information that is contradictory and were unsure of each payer’s responsibilities in that case. Response: We appreciate the commenters’ concerns. We do believe that patients have a right to their data. In addition, they have a right to request that their health data follow them throughout their health care journey. It is only when patients are able to facilitate the sharing of their data, and even see it themselves, such as via the Patient Access API, that they will be able to understand where there may be opportunities to work with their previous and current providers and payers to ensure they have an accurate health record. Today, to the extent permitted by law, payers may exchange patient data without the patient’s consent for various purposes including payment and health care operations. The policy we are finalizing here will allow the patient to facilitate that exchange of their health information. In using this process, patients can ensure their payers and providers have the most accurate and up-to-date information about them. Payers can choose to indicate which data being exchanged were received from a previous payer so the receiving payer, or even a patient, understands where to direct questions and is aware of the scope of control over data integrity. This will also help receiving payers and patients understand how to reconcile contradictory information as it can be made clear where questions should be directed. Payers are under no obligation under this regulation to update, validate, or correct data received from another payer. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Comment: Several commenters agreed with the proposed suggestion that activities related to this proposal may qualify as QIA meeting the criteria described in section 2718(a)(2) of the PHSA for purposes of the MLR requirements for QHP issuers on the FFEs, and similar standards for treatment of quality improvement standards applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP managed care entities under 42 CFR 457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490. Response: We confirm that we continue to believe that expenses for the care coordination data exchanges required by this final rule may qualify as QIA for purposes of calculating the MLR for payers that engage in such exchanges. As noted above, while this rulemaking is specific to QHP issuers participating on the FFEs, to the extent other commercial market issuers incur similar costs for coverage sold in the individual or group markets, those expenses may similarly qualify as QIA. We appreciate the commenters’ support and will consider recognizing the expenses related to this data exchange as QIA in future rulemaking or guidance, as may be necessary. Comment: Many commenters were concerned about the time frame to implement this provision and were concerned making this policy applicable in 2020 would not provide enough time to operationalize this policy. Response: We appreciate the commenters’ concerns and understand that it will take time to fully and properly implement this policy. We are finalizing this payer-to-payer data exchange requirement with an applicability date of January 1, 2022 with respect to the exchange of the USCDI data set. Although we did not propose to require payers to use an API to exchange the USCDI under this payer-to-payer data exchange proposal, we appreciate and support that some payers would like to leverage the Patient Access API (discussed in section III. of this final rule) to meet the requirements of this payer-to-payer data exchange. The Patient Access API requirement makes USCDI data available to the patient or a third party at the patient’s direction. Because the Patient Access API is facilitating the exchange of the USCDI, some of the work to develop an API to exchange these data and the work to map the relevant USCDI data will be completed by January 1, 2021, when the Patient Access API must be made available as finalized in section III. of this rule. In addition, if a payer receives VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 data via an API, the payer could then incorporate it into a patient’s record and in turn share it with the patient via the Patient Access API with little additional work needed. We appreciate the value of using an API for this data exchange, and we understand the efficiencies that it can add to both this payer-to-payer data exchange as well as the Patient Access API policy. We also appreciate that incorporating data from other payers received via an API will be a new experience for payers, however. For instance, payers will need to develop a process to incorporate data from other payers into their systems, including potentially processes for tagging these data as originating with another payer so they can efficiently share that information with patients and future payers. These are additional processing steps that take time to implement. In evaluating the comments on the proposals in this rule, and appreciating the value of sharing and exchanging data via APIs, we see the benefit of having all data exchanged via APIs. Therefore, we may consider for future rulemaking an API-based payer-to-payer data exchange. At this time, we believe that an applicability date of January 1, 2022 for compliance with this requirement is appropriate. This provides time for payers to get experience with the Patient Access API, and provides payers with additional time to fully and successfully implement this payer-to-payer data exchange requirement. To support a more seamless data exchange and to further clarify this payer-to-payer data exchange requirement, we are finalizing some modifications of the proposed regulation text at 42 CFR 422.119(f)(1)(ii) and (iii) for MA organizations; at 42 CFR 438.62(b)(1)(vi)(B) and (C) for Medicaid managed care plans (and by crossreference from 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(f)(1)(ii) and (iii) for QHP issuers on the FFEs to clearly indicate payers are obligated under this proposal to, with the approval and at the direction of a current or former enrollee, exchange data with any other payer identified by the enrollee. The proposed regulation text used both the term ‘‘recipient’’ and ‘‘any other health care plan’’ to identify where these data would be sent at an enrollee’s request; the term ‘‘recipient’’ could have been interpreted more broadly than we intended. In the final regulation text, we are using ‘‘payer’’ instead and consolidating the proposed provisions that would require the payer that is PO 00000 Frm 00059 Fmt 4701 Sfmt 4700 25567 subject to these rules to send data at the enrollee’s request at any time during enrollment or up to 5 years after enrollment ends. As discussed in section III. of this final rule, we are also specifying in the final regulations that a payer is only required to send data received under this payer-to-payer data exchange requirement in the electronic form and format it was received. In this way, a payer would not be asked to receive paper records from another payer under this policy and then in turn share those paper records with another payer in the future at the patient’s direction. If the payer received a patient’s information via an API, the payer must share it via an API if the payer they are sending to has the capacity to receive it. If a patient requests that a former payer send their information to their new payer and then requests that their new payer make their data accessible via that new payer’s Patient Access API, the new payer would only be required to include the information received from the former payer at the patient’s direction if this newly acquired information was received via a FHIR-based API. Otherwise, the new payer is only required to share data via the Patient Access API that the payer already maintains and has prepared to be shared via a FHIR-based API. We are also finalizing new regulation text, at 42 CFR 422.119(h) for MA organizations; at 42 CFR 438.62(b)(1)(vii) for Medicaid managed care plans (and by cross-reference from 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(i) for QHP issuers on the FFEs, that these regulated payers will need to comply with the payer-to-payer data exchange requirements beginning January 1, 2022 (or beginning with plan years beginning on or after January 1, 2022 for QHP issuers on the FFEs). In addition, this requirement, as finalized, provides that payers are required to exchange data they maintain with a date of service on or after January 1, 2016. In this way, payers only have to prepare a defined initial historical set of data for sharing via this payer-to-payer data exchange policy, as also required under the Patient Access API policy discussed in section III. of this final rule. We believe that delaying implementation to January 1, 2022 and specifying that only data with a date of service on or after January 1, 2016 must be exchanged under the new requirement addresses concerns about the timing and level of burden involved in meeting this requirement. This also clarifies that if certain information is not maintained by the E:\FR\FM\01MYR2.SGM 01MYR2 25568 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations payer, the payer is not obligated to seek out and obtain the data. We also sought comment on how this policy might impact dually eligible individuals. We summarize the public comments we received on this payer-topayer data exchange specifically regarding our request for comment for how this policy might impact dually eligible individuals who are concurrently enrolled in MA plans and Medicaid managed care plans and provide our responses. Comment: A few commenters supported the proposal because it could improve care coordination for dually eligible beneficiaries. One commenter noted that because of this proposal, MA plans and Medicaid MCO plans would have the same data and health history for an individual. One commenter believed that this could help states that do not have an easily accessible source of data for knowing when their Medicaid beneficiaries are enrolled for Medicare. This commenter recommended including enrollment source and enrollment and disenrollment dates in the data exchanged between payers. Response: We appreciate the commenters’ support and the suggestion noted. We will further evaluate this suggestion for future consideration. Comment: One commenter requested additional information regarding how plans should account for gaps in plan coverage over the course of 5 years. The commenter believed this will be particularly important for dual eligible and Medicaid beneficiaries who may move in and out of a health plan program as their status may change due to changing circumstances. Response: We appreciate the commenter’s request for information. We note that one payer would only be obligated to send another payer information that the payer maintains (which could include data received from other payers under this final rule that must be incorporated into the current payer’s records). If in the 5 years prior to January 1, 2022, a patient was in a Medicaid managed care plan for 1 year in 2019 and then there was a break in service with the patient returning for 1 year in 2021, this Medicaid managed care plan would be required to share data from 2019 and 2021 if requested by the patient. It would not be the managed care plan’s responsibility to address the gaps in the data that the plan maintains. Assuming that the patient was enrolled in an MA plan or another Medicaid managed care plan in 2020, the patient could request that the plan they had in 2020 independently send their data to the payer they have indicated. In this VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 way, the indicated payer is now the holder of the comprehensive information, as under this requirement a payer must incorporate the data received from other payers under this policy into their data system. If the patient leaves to go to a new payer in 2023, the one payer that now maintains their data from 2019 to 2022 would be the one payer that could forward the data to the new payer, in the electronic form and format it was received. We acknowledge that this may be complex for dually eligible beneficiaries. Comment: A few commenters noted advantages, burdens, and complexities associated with plans serving dually eligible beneficiaries continuously aggregating real-time member data from multiple plans. One commenter noted that each payer should only be responsible for their own data set and the coordination of data across multiple plans and providers would be more ideally done through a Trusted Exchange Framework and Common Agreement (TEFCA). This commenter noted that additional technical capabilities will be required due to the possibility of overlapping coverage when combining and incorporating records. Response: We appreciate these thoughtful comments. We note that this payer-to-payer data exchange is only required when initiated by an enrollee’s request, and only applies to the payers who are subject to our final regulations at 42 CFR 422.119(f)(1) and (h) for MA organizations; 42 CFR 438.62(b)(1)(vi) and (vii) for Medicaid managed care plans (and by cross-reference from 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(f) and (i) for QHP issuers on the FFEs. The enrollee may request this payer-to-payer exchange just once, or more frequently. We did not propose, and are not finalizing, any requirement for continuous data exchange, however. Final Action: After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing with modifications our proposal at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213 (currently version 1 of the USCDI), as outlined in section III. of this final rule. Specifically, we are finalizing as PO 00000 Frm 00060 Fmt 4701 Sfmt 4700 proposed that the payers subject to these regulations incorporate the data they receive into the enrollee’s record. In the final regulation text, we are using the language ‘‘with the approval and at the direction’’ of the enrollee versus ‘‘at the request’’ of the enrollee to align with the language used for the API requirements. We are finalizing modifications to the proposed regulation text to streamline the text and best specify the scope of the policy as intended, as well as to align the text for all payer types as appropriate. Specifically, at 42 CFR 422.119(f)(1)(i), 438.62(b)(1)(vi)(A) (and by cross-reference from 42 CFR 457.1216), and at 45 CFR 156.221(f)(1)(i), the regulation text states that relevant payers ‘‘receive’’ versus ‘‘accept’’ data for current enrollees. At 42 CFR 422.119(f)(1)(ii), 438.62(b)(1)(vi)(B) (and by crossreference from 42 CFR 457.1216), and at 45 CFR 156.221(f)(1)(ii), the final regulations provide that a payer must send the defined information set to any other payer. In addition, at 42 CFR 422.119(f)(1)(iii), 438.62(b)(1)(vi)(C) (and by cross-reference from 42 CFR 457.1216), and at 45 CFR 156.221(f)(1)(iii), we specify that a payer is only obligated to send data received from another payer under this policy in the electronic form and format it was received. This is intended to reduce burden on payers. We note the final regulations do use the term ‘‘payer’’ in place of ‘‘health care plan’’ to clarify that the scope of the obligations are for all payers impacted by this regulation. Also at 45 CFR 156.221(f)(1), we updated the title of the paragraph to align with the parallel regulations for other payers types, and we corrected an incomplete sentence. Finally, we specify that this policy also applies to an enrollee’s personal representative. We are also finalizing regulation text to address when these regulated payers must comply with these new requirements at 42 CFR 422.119(h) for MA organizations; at 42 CFR 438.62(b)(1)(vii) for Medicaid managed care plans (and at 42 CFR 457.1216, to CHIP managed care entities); and at 45 CFR 156.221(i) for QHP issuers on the FFEs. Starting January 1, 2022, and for QHP issuers on the FFEs starting with plan years beginning on or after January 1, 2022, the finalized regulation requires these payers to exchange data with a date of service on or after January 1, 2016 that meets the requirements of this section and which the payer maintains. In this way, payers only have to prepare an initial historical set of data for sharing via this payer-to-payer data exchange policy that is consistent with the data set to be available through the E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Patient Access API, as finalized in section III. of this final rule. VI. Care Coordination Through Trusted Exchange Networks: Trust Exchange Network Requirements for MA Plans, Medicaid Managed Care Plans, CHIP Managed Care Entities, and QHP Issuers on the FFEs Provisions, and Analysis of and Responses to Public Comments We proposed to require MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in trust networks in order to improve interoperability in these programs. We noted that we would codify this requirement in, respectively, 42 CFR 422.119(f)(2), § 438.242(b)(5), and § 457.1233(d) (which cross-references the requirements in 42 CFR 438.242(b)(5)) and 45 CFR 156.221(f). In general, payers and patients’ ability to communicate between themselves and with health care providers could considerably improve patient access to data, reduce provider burden, and reduce redundant and unnecessary procedures. Trusted exchange networks allow for broader interoperability beyond one health system or point to point connections among payers, providers, and patients. Such networks establish rules of the road for interoperability, and with maturing technology, such networks are scaling interoperability and gathering momentum with participants, including several federal agencies, EHR vendors, retail pharmacy chains, large provider associations, and others. The importance of a trusted exchange framework to such interoperability is reflected in section 4003(b) of the Cures Act, which was discussed in more detail in section I.D. of the CMS Interoperability and Patient Access proposed rule (84 FR 7612 through 7614). In section VI. of the CMS Interoperability and Patient Access proposed rule (84 FR 7642), we discussed and explained our proposal to require certain payers to participate in trusted exchange networks. A trusted exchange framework allows for the secure exchange of electronic health information with, and use of electronic health information from, other health IT. Widespread payer participation in such a framework might allow for more complete access and exchange of all electronically accessible health information for authorized use under applicable state or federal law, which we believe would lead to better use of such data. We noted that while we cannot require widespread payer participation in trust networks, we VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 proposed to use our program authority in the MA program, Medicaid managed care program, CHIP managed care program, and QHP certification program for the FFEs to increase participation in trust networks and to bring the potential benefits of participating in such programs, including improved interoperable communication and care coordination, which result in opportunities for improved patient outcomes and burden reduction. We proposed to require, beginning January 1, 2020, that MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs participate in a trusted exchange network. The proposal was based on our authority under: Sections 1856(b) and 1857(e) of the Act to adopt standards and contract terms for MA plans; section 1902(a)(4) of the Act to adopt methods of administration for the administration state Medicaid plans, including requirements for Medicaid managed care plans (MCOs, PIHPs, and PAHPs); section 2101(a) for CHIP managed care entities (MCOs, PIHPs, and PAHPS); and section 3001(c)(9)(F)(iii) of the PHSA and section 1311(e)(1)(B) of the Affordable Care Act for QHP issuers on an FFE. Under the proposal, and consistent with section 4003(b) of the Cures Act, participation would be required in a trusted exchange framework that met the following criteria: (1) The trusted exchange network must be able to exchange PHI, defined at 45 CFR 160.103, in compliance with all applicable state and federal laws across jurisdictions. (2) The trusted exchange network must be capable of connecting both inpatient EHRs and ambulatory EHRs. (3) The trusted exchange network must support secure messaging or electronic querying by and between patients, providers, and payers. We proposed to codify these requirements for these payers at 42 CFR 422.119(f)(2) for MA organizations, § 438.242(b)(5) for Medicaid managed care plans, § 457.1233(d)(2) for CHIP managed care entities, and 45 CFR 156.221(f) for QHPs on the FFEs. On April 19, 2019, ONC released the draft Trusted Exchange Framework and Common Agreement (TEFCA Draft 2) for public comment.48 Previous commenters on draft 1 of the TEFCA, particularly payers providing comments, requested that existing trust 48 See https://www.healthit.gov/sites/default/ files/page/2019-04/FINALTEFCA QTF41719508version.pdf. For additional information about TEFCA, see https:// www.healthit.gov/topic/interoperability/trustedexchange-framework-and-common-agreement. PO 00000 Frm 00061 Fmt 4701 Sfmt 4700 25569 networks that are operating successfully be leveraged in further advancing interoperability; thus, we considered a possible future approach to payer-topayer and payer-to-provider interoperability that leverages existing trust networks to support care coordination and improve patient access to their data. We requested comments on this approach and how it might be aligned in the future with section 4003(b) of the Cures Act. We also requested comments on the applicability date we proposed for the trusted exchange network participation requirement and what benefits and challenges the payers subject to our proposal might face meeting this requirement for additional consideration in future rulemaking. We summarize the public comments we received on this topic and provide our responses. Comment: Although many stakeholders supported the concept of this proposal, there were strong exceptions. Many commenters, particularly payers, indicated that it was premature for CMS to finalize a proposal related to trusted exchange network participation before the first version of the Common Agreement under ONC’s TEFCA was finalized. Commenters noted that, even though they supported using a trusted exchange network, it would not be advisable until after TEFCA as outlined in section 4003 of the 21st Century Cures Act was available to facilitate this proposal. Response: We appreciate that although commenters supported the general concept of trusted exchange network participation and how it could advance interoperability and data exchange, the true value of this concept might be best realized via TEFCA in the future. We agree that trusted exchange networks can play a positive role, but given the concerns commenters raised regarding the need for a mature TEFCA, and appreciating the ongoing work on TEFCA being done at this time, we are not finalizing this policy at this time. Comment: Some commenters noted that more detail would be needed to understand how this proposal would be operationalized. These commenters also indicated more information would be needed to understand how this policy would relate to existing Health Information Exchanges (HIEs) and Health Information Networks (HINs) and whether these entities would qualify as trusted exchange networks. A few commenters indicated this policy may be redundant appreciating the existing role of HIEs and HINs. Response: We appreciate the commenters’ concerns and requests for E:\FR\FM\01MYR2.SGM 01MYR2 25570 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations additional information. We will keep these in mind as we consider possible future proposals around participation in trusted exchange networks. Comment: Many commenters expressed concerns with the proposed implementation timeline. They did not believe this policy could be implemented by January 1, 2020. Commenters indicated it would take more time to meet the necessary requirements and fully understand the implications of the policy, particularly for HIEs and HINs. Many commenters suggested a delay ranging from 12 to 24 months. Other commenters suggested CMS align the timeline of this proposal with TEFCA implementation milestones. In addition to a delay, some commenters suggested an exemption process. Response: We appreciate the commenters concerns, and based on these concerns and those summarized from other commenters, we are not finalizing this proposal at this time. To reflect this in this final rule, the regulation text proposed for all impacted payers is not being finalized. In addition, as 42 CFR 438.242(b)(5) is not being finalized, the regulation text proposed at 42 CFR 438.242(b)(6) is being redesignated as 42 CFR 438.242(b)(5). Final Action: After consideration of the comments received, and for the reasons outlined in our response to these comments, we are not finalizing this proposal to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in a trusted exchange network. VII. Improving the Medicare-Medicaid Dually Eligible Experience by Increasing the Frequency of FederalState Data Exchanges Provisions, and Analysis of and Responses to Public Comments A. Increasing the Frequency of FederalState Data Exchanges for Dually Eligible Individuals 1. Background The Medicare and Medicaid programs were originally created as distinct programs with different purposes. The programs have different rules for eligibility, covered benefits, and payment. The programs have operated as separate and distinct systems despite a growing number of people who depend on both programs (known as dually eligible individuals) for their health care. There is an increasing need to align these programs—and the data and systems that support them—to improve care delivery and the VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 beneficiary experience for dually eligible individuals, while reducing administrative burden for providers, health plans, and states. The interoperability of state and CMS eligibility and Medicaid Management Information System (MMIS) systems is a critical part of modernizing the programs and improving beneficiary and provider experiences. Improving the accuracy of data on dual eligibility by increasing the frequency of federalstate data exchanges is a strong first step in improving how these systems work together. 2. Data Exchanges To Support State Buy-In for Medicare Parts A and B States and CMS routinely exchange data on who is enrolled in Medicare and Medicaid, and which parties are liable for paying that beneficiary’s Parts A and B premiums. These data exchanges support state, CMS, and Social Security Administration (SSA) premium accounting, collections, and enrollment functions. Section 1843 of the Act permits states to enter into an agreement with the Secretary to facilitate state ‘‘buy-in,’’ that is, payment of Medicare premiums, in this case Part B premiums, on behalf of certain individuals. For those beneficiaries covered under the agreement, the state pays the beneficiary’s monthly Part B premium. Section 1818(g) of the Act establishes the option for states to amend their buyin agreement to include enrollment and payment of the Part A premium for certain specified individuals. All states and the District of Columbia have a Part B buy-in agreement; 36 states and the District of Columbia have a Part A buyin agreement. To effectuate the state payment of Medicare Part A or Part B premiums, a state submits data on a buy-in file to CMS via an electronic file transfer (EFT) exchange setup. The state’s input file includes a record for each Medicare beneficiary for whom the state is adding or deleting coverage, or changing buy-in status. In response, CMS returns an updated transaction record that provides data identifying, for each transaction on the state file, whether CMS accepted, modified, or rejected it, as well a Part A or Part B billing record showing the state’s premium responsibility. In addition, the CMS file may ‘‘push’’ new updates obtained from SSA to the state, for example, changes to the Medicare Beneficiary Identifier number or a change of address. We have issued regulations for certain details of the state buy-in processes. For Medicare Part A, 42 CFR 407.40 describes the option for states to amend the buy-in agreement to cover Part A PO 00000 Frm 00062 Fmt 4701 Sfmt 4700 premiums for Qualified Medicare Beneficiaries (QMBs). For Medicare Part B, 42 CFR 406.26 codifies the process for modifying the buy-in agreement to identify the eligibility groups covered. CMS subregulatory guidance, specifically Chapter 3 of the State Buyin Manual,49 specifies that states should exchange buy-in data with CMS at least monthly, but describes the option for states to exchange buy-in data with CMS daily or weekly. Likewise, states can choose to receive the CMS response data file daily or monthly. We note that 35 states and the District of Columbia are now submitting buy-in data to CMS daily; 31 states and the District of Columbia are now receiving buy-in response files from CMS daily. While many states submit and receive buy-in files daily, some continue to only do so on a monthly basis. We have become increasingly concerned about the limitations of monthly buy-in data exchanges with states. The relatively long lag in updating buy-in data means that the state is not able to terminate or activate buy-in coverage sooner, so the state or beneficiary may be paying premiums for longer than appropriate. In most cases, funds must be recouped and redistributed—a burdensome administrative process involving debits and payments between the beneficiary, state, CMS, and SSA. Additionally, transaction errors do occur in the current data exchange processes. In a monthly exchange, it can take multiple months to correct and resubmit an improperly processed transaction, exacerbating the delays in appropriately assigning premium liability, leading to larger mispayment, recoupment, and redistribution of premiums. Exchanging the buy-in data with greater frequency supports more timely access to coverage. All states’ systems already have the capacity to exchange buy-in data. We acknowledge that states that do not already exchange data daily will need an initial, one-time systems change to do so. However, moving to a daily data exchange would result in a net reduction of burden for states, and further, reduce administrative complexity for beneficiaries and providers. More frequent submission of updates to individuals’ buy-in status positively impacts all involved. For a full discussion of the benefits, see the CMS Interoperability and Patient Access 49 Centers for Medicare and Medicaid Services. (2003). State Buy-In Manual: Chapter 3—Data Exchange. Retrieved from https://www.cms.gov/ Regulations-and-Guidance/Guidance/Manuals/ downloads/buyin_c03.pdf. (Last accessed June 24, 2019). E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations proposed rule (84 FR 7643 through 7644). While there exist opportunities to modernize the platform for buy-in data exchange, we believe that an important first step is to promote the exchange of the most current available data. Section 1843(f) of the Act specifies that Part B buy-in agreements shall contain such provisions as will facilitate the financial transactions of the State and the carrier with respect to deductions, coinsurance, and otherwise, and as will lead to economy and efficiency of operation. Further, section 1818(g)(2)(A) of the Act on Part A buy-in identifies this section 1843(f) requirement as applicable to Part A buy-in. While the regulations governing buy-in agreements (see 42 CFR 406.26 and 407.40) are silent on the frequency of buy-in data exchanges, current guidance articulates that the required buy-in data may be submitted daily, weekly, or monthly. Therefore, we proposed to establish frequency requirements in the regulations at 42 CFR 406.26(a)(1) and 407.40(c) to require all states to participate in daily exchange of buy-in data with CMS, with ‘‘daily’’ meaning every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. We noted that we believe these requirements will improve the economy and efficiency of operation of the buyin process. We proposed that states would be required to begin participating in daily exchange of buy-in data with CMS by April 1, 2022. We noted that we believe this applicability date would allow states to phase in any necessary operational changes or bundle them with any new systems implementation. In the CMS Interoperability and Patient Access proposed rule, we estimated that 19 states would need to make a system change to send buy-in data to CMS daily and 22 states would need to make a system change to receive buy-in data from CMS daily (84 FR 7668). Based on more recent data, we estimate that 26 and 19 states would require such system changes, respectively. We updated our estimates to determine the one-time cost to be $85,000 per state, per change, so a state that needs to make systems updates to both send buy-in data daily, and receive buy-in data daily would have a one-time cost of just over $170,000. We sought comment on the proposals. We summarize the public comments we received on data exchanges to support state buy-in for Medicare Parts A and B and provide our responses. Comment: Almost all those who commented on these provisions supported the proposal to require that VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 all states participate in daily exchange of buy-in data with CMS by April 1, 2022. Commenters stated that the changes would improve the timeliness and accuracy of eligibility and enrollment data, and enhance capability for coordination of benefits. Response: We appreciate the strong support for the proposed change to the regulation. Comment: One commenter supported the change, but also encouraged CMS to modify its own processes and systems to effectively leverage daily data exchanges to support enhanced care for dually eligible individuals. Another commenter requested clarification if the daily state submission of the buy-in file encompasses a reciprocal daily response from CMS to the states. Response: We agree that CMS and states both play important roles in implementing systems changes to support the state buy-in process. Currently, states can choose to exchange buy-in data with CMS daily, weekly, or monthly; and separately, they can choose to receive the CMS response data file daily, weekly, or monthly. We proposed that all states both send data to CMS and receive responses from CMS on a daily basis. We will continue to look for opportunities to optimize CMS systems and processes to support better care for dually eligible individuals. Comment: One commenter supported requiring frequent exchanges of this data as a way to eliminate current inefficiencies and improve benefit coordination for the dually eligible population so long as this requirement does not impose additional reporting requirements on clinicians. Response: We appreciate the support for our proposal. We confirm that the regulation as proposed does not create additional reporting requirements on clinicians. As noted in the preamble to the CMS Interoperability and Patient Access proposed rule, we estimate that the change to a daily submission would result in a net reduction of burden for states, and further, reduce administrative complexity for beneficiaries and providers. Comment: One commenter noted that the proposed applicability date of April 1, 2022 will be sufficient for this change, but for overall unity in the rule’s proposed changes, encouraged CMS to consider aligning the applicability date of this proposal with an overall extended implementation time frame of at least 2 years—and ideally 5 years—for the remainder of the rule’s provisions. Response: We appreciate the value in aligned implementation timelines. However, given that other provisions in PO 00000 Frm 00063 Fmt 4701 Sfmt 4700 25571 this rule for health plans and states are distinct from this requirement, and will be required beginning in 2020, we continue to believe that the April 1, 2022 implementation timeline proposed for daily exchange of buy-in data is appropriate. Comment: Commenters recommended that CMS establish a process for states to provide Medicare dual eligible special needs plans (D–SNPs) with, at a minimum, data on beneficiaries’ Medicaid coverage. Commenters requested CMS align the eligibility and enrollment information that health plans receive with the information being shared between states and the federal government so there is a single ‘‘source of truth’’ on these data. Commenters noted this consistency is critical to improving care coordination for dually eligible individuals. Response: D–SNPs have an important role in supporting their enrollees’ access to Medicaid benefits. We understand that in many states D–SNPs have limited access to timely data on Medicaid enrollment. We note that we do provide data to D–SNPs and other MA plans on the Medicaid status of their members. While we appreciate the value of D–SNPs getting additional Medicaid coverage data such as Medicaid plan enrollment, we decline to modify the regulations to require states to do so as it is beyond the scope of this proposal. However, we continue to explore opportunities to provide plans with data that would assist them in better coordinating benefits and coverage for their dually eligible enrollees. Comment: One commenter noted that the CMS Interoperability and Patient Access proposed rule does not require states to input the latest eligibility data in a specific timeframe on their claims platforms. The commenter noted that not having this clarity means that there could be a potential for inconsistent data. The commenter recommended that CMS require state Medicaid programs to update their claims platforms daily to assist with accurate data exchanges. Response: We appreciate the point the commenter is making. Our proposal did not explicitly address how states incorporate eligibility data with claims and other systems. We will consider this recommendation for the future as we gain additional experience with daily data exchange. Comment: Two commenters stated that daily exchange of buy-in data would require significant systems changes and costs. One of these commenters recommended that CMS revise the proposal to update the frequency of exchange from monthly to E:\FR\FM\01MYR2.SGM 01MYR2 25572 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations weekly, rather than daily. The commenter noted that it would seldom have new information to send on a daily basis, but that determining on a daily basis whether there was any new information to send would be a large effort. Finally, the commenter requested if CMS finalized the regulation to require daily updates, that provisions be made for states whose systems cycles are other than within a calendar day, for example, 6 p.m. to 6 a.m. Response: We appreciate the costs that the state may bear to make the systems changes necessary to implement these provisions. We will provide technical assistance and opportunities for shared learning through webinars and training to support states’ transition. We also note that federal matching funds at the standard rate of 50 percent for administration will reduce the states’ costs. States may also be eligible for enhanced 90 percent federal matching funds for the costs of developing and implementing any necessary system changes required by regulation, and enhanced 75 percent federal matching funds for their system’s maintenance and operation costs. These enhanced federal matching funds would be available for their Eligibility and Enrollment (E&E) systems (and, if necessary, their Medicaid Management Information System (MMIS)). States would request enhanced funding through the Advance Planning Document (APD) process. Even though there are costs to the states in implementing daily exchange of buy-in data, other commenters uniformly supported the value of daily exchanges in improving the experience of dually eligible individuals, and in reducing burden on states, providers, and plans to reconcile payment. As a result, we decline to make the suggested change. With respect to the point that there would often not be updates on a daily basis, we reiterate that no file would be required on business days where there were no updates. We expect that states would be able to automate their systems so that they check daily for changes to buy-in status that would need to be submitted to CMS on the buy-in file, but also automate a process by which the system only generates a buy-in file upon identifying such a change. We appreciate the additional coding required to implement this logic but expect that once implemented, no additional interventions would be needed. We will work with states that have implemented these changes to identify and share best practices in VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 identifying data changes to trigger daily submissions. Finally, in response to the concern about whether states that have an overnight processing cycle would be permitted to continue doing so, we affirm that the proposed regulation would permit this. After consideration of the public comments and for the reasons articulated in the CMS Interoperability and Patient Access proposed rule and our responses to comments, we are finalizing changes to 42 CFR 406.26 and 407.40 as proposed. 3. Exchange of State MMA Data Files States submit data on files at least monthly to CMS to identify all dually eligible individuals, including fullbenefit and partial-benefit dually eligible individuals (that is, those who get Medicaid help with Medicare premiums, and often for cost-sharing). The file is called the ‘‘MMA file,’’ but is occasionally referred to as the ‘‘State Phasedown file.’’ The MMA file was originally developed to meet the need to timely identify dually eligible individuals for the then-new Medicare Part D prescription drug benefit. The Medicare Modernization Act (MMA) established that, beginning January 1, 2006, Medicare would be primarily responsible for prescription drug coverage for full-benefit dually eligible individuals; established auto-enrollment of full-benefit dually eligible individuals into Medicare prescription drug plans (with regulations further establishing facilitated enrollment into prescription drug plans for partialbenefit dually eligible individuals), provided that dually eligible individuals are treated as eligible for the Medicare Part D Low Income Subsidy (LIS), sometimes called Extra Help; defined phased down state contributions to partly finance Part D costs for dually eligible individuals; and required riskadjusting capitation payments for LIS (which include dually eligible) enrollees of Part D plans. To support these new requirements, we issued 42 CFR 423.910, establishing monthly reporting by states, in which states would submit, at least monthly, a data file identifying dually eligible individuals in their state. Over time, we used these files’ data on dual eligibility status to support Part C capitation risk-adjustment, and most recently, to feed dual eligibility status to Part A and B eligibility and claims processing systems so providers, suppliers, and individuals have accurate information on beneficiary cost-sharing obligations. Currently, regulations require states to submit at least one MMA file each PO 00000 Frm 00064 Fmt 4701 Sfmt 4700 month. However, states have the option to submit multiple MMA files throughout the month (up to one per day). Most states submit MMA data files at least weekly. In the CMS Interoperability and Patient Access proposed rule, we estimated that 37 states and DC would need to make a system change to send MMA data to CMS daily (84 FR 7668). Based on more recent data, we estimate that 36 states and DC would require such system changes. As CMS now leverages MMA data on dual eligibility status into systems supporting all four parts of the Medicare program, it is becoming even more essential that dual eligibility status is accurate and up-to-date. Dual eligibility status can change at any time in a month. Waiting up to a month for status updates can negatively impact access to the correct level of benefit at the correct level of payment. Based on our experience with states that exchange data daily, more frequent MMA file submissions benefit states, individuals, and providers, in a number of ways. For a full discussion of the benefits, see the CMS Interoperability and Patient Access proposed rule (84 FR 7644). As noted, current regulation requires that each state submit an MMA file at least monthly. We have implemented ‘‘work-arounds’’ for lags in dual eligibility status for Part D, including the ‘‘Best Available Evidence’’ policy (see 42 CFR 423.800(d)), as well as the Limited Income Newly Eligible Transition demonstration, which provides short term drug coverage for dually eligible individuals with no Part D plan enrollment in a given month (see Medicare Prescription Drug Benefit Manual, Chapter 3, Section 40.1.4).50 While these work-arounds provide needed protections, more frequent data exchanges would mitigate the need for them. Ensuring information on dual eligibility status is accurate and up-todate by increasing the frequency of federal-state data exchange is an important step in the path to interoperability. As a result, we proposed to update the frequency requirements in 42 CFR 423.910(d) to require that, starting April 1, 2022, all states submit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily would mean every 50 Centers for Medicare and Medicaid Services. (2017). Medicare Prescription Drug Benefit Manual: Chapter 3—Eligibility, Enrollment and Disenrollment. Retrieved from https:// www.cms.gov/Medicare/Eligibility-and-Enrollment/ MedicarePresDrugEligEnrol/Downloads/CY_2018_ PDP_Enrollment_and_Disenrollment_Guidance_615-17.pdf. (Last accessed June 24, 2019). E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations business day, but that if no new transactions are available to transmit, states would not need to submit data on a given business day. We proposed requiring that states begin submitting these data daily to CMS by April 1, 2022 because we believed this applicability date would allow states to phase in any necessary operational changes or bundle them with any new systems implementation. We estimated an updated one-time cost for a state to be $85,000 for this MMA data systems change. For a detailed discussion of the costs associated with these requirements, we refer readers to section XVI. of the CMS Interoperability and Patient Access proposed rule (84 FR 7660 through 7673), as well as section XVI of this final rule. We sought comment on these proposals. We summarize the public comments we received on exchange of state MMA data files and provide our responses. Comment: Almost all those who commented on this provision supported the proposal to require all states to participate in daily submission of MMA file data with CMS by April 1, 2022. Commenters noted that the changes would improve the timeliness and accuracy of eligibility and enrollment data, enhance coordination of benefits, and support greater integration of care. Response: We appreciate the strong support for the proposed change to the regulation. Comment: One commenter supported the proposed change, but requested CMS consider standardizing which file types and data sets will be acceptable to support standardized daily submissions, for the overall purpose of improving the state and CMS data exchanges. Response: We understand the suggestion that we standardize which upstream data sets (for example, CMS finder files, state eligibility data) states should use to support daily MMA file submissions. To that end, we will provide technical assistance to states that need to make changes to submit the file daily. As part of that effort, we will work with states that already submit MMA files daily to understand and share information on best practices on the upstream data sets necessary to implement daily MMA file submissions. Comment: One commenter noted that the proposed applicability date of April 1, 2022 will be sufficient for this change, but for overall unity in the rule’s proposed changes, encouraged CMS to consider aligning the effective date of this proposal with an overall extended implementation time frame of at least 2 years—and ideally 5 years— for the remainder of the rule’s provisions. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Response: We appreciate the value in aligned implementation timelines. However, given that other provisions in this rule for health plans and states are distinct from this requirement, and will be required beginning in 2020, we continue to believe that the April 1, 2022 implementation timeline proposed for daily MMA file submissions is appropriate. Comment: A few commenters noted the value of the data in the MMA file to Medicaid managed care organizations (MCO), Medicare dual eligible special needs plans (D–SNPs), Health Information Exchanges, and providers for the purposes of coordinating enrollment, benefits, and/or care for dually eligible individuals. These commenters requested access to the daily MMA file. One commenter noted that some states are sharing Medicare plan enrolment data from these files with their Medicaid MCOs while also providing batch inquiry data sharing mechanisms to D–SNPs on Medicaid plan enrollment. This commenter recommended that CMS encourage or require all states to follow this process at a minimum. Commenters also encouraged CMS to leverage the MMA file to support parties complying with the D–SNP integration standards recently issued in 42 CFR 422.2. Response: We appreciate these suggestions to promote access to data for plans and providers serving dually eligible individuals, and we will explore these ideas further for potential future consideration. However, we decline to modify the regulation as suggested, as the recommended changes are beyond the scope of the proposal, which is limited to the frequency of the file exchange. Comment: A few commenters made additional suggestions for streamlining data exchanges. In addition to making the MMA files accessible to plans and providers, some commenters recommended adding Medicaid plan enrollment information to MMA files to create a single source of MedicareMedicaid enrollment data for dually eligible individuals. Another commenter suggested a potential pathway to streamlining data exchanges would be for CMS to allow state Transformed Medicaid Statistical Information System (T–MSIS) files to serve as the beneficiary data source for third-party applications. Response: We appreciate the value of streamlining data exchanges, including access to a consistent data source on eligibility and enrollment. We also acknowledge the overlap of certain data exchanged in the MMA and T–MSIS PO 00000 Frm 00065 Fmt 4701 Sfmt 4700 25573 file, though we note we would need to carefully explore the implications and impacts of merging operational data exchanges such as the MMA file— which result in changes to an individual’s Medicare benefit—with informational exchanges such as T– MSIS. We will consider exploring these opportunities further for potential future consideration. However, we decline to modify the regulation as suggested, as the recommended changes are beyond the scope of the proposal, which is limited to the frequency of the file exchange. Comment: Several commenters noted significant system changes and cost to update the frequency of exchanging MMA files to daily. One commenter stated that they believe HHS has underestimated the cost to upgrade the MMA system to support daily exchange. The commenter encouraged CMS to provide an updated estimate for the costs to upgrade the system that include additional operational costs. This commenter and others encouraged CMS to consider providing additional funding to state Medicaid programs that will need to upgrade their data systems. One commenter questioned if CMS would consider increasing the FMAP states receive for interoperability activities that support dual eligible plans integrations and in particular, for programmatic or systems changes to come into compliance with D–SNP integration. The commenter noted that this increase could exceed existing enhanced matches, for example allowing the 90 percent match to apply for ongoing systems operations that facilitate care coordination. Response: We appreciate the input on the level of effort needed to submit the MMA file daily. As noted elsewhere, we will provide technical assistance and opportunities for shared learning through webinars and training to support states’ transition. We also note that federal matching funds of 50 percent for administration will reduce the states’ costs. States may also be eligible for enhanced 90 percent federal matching funds for the costs of developing and implementing any necessary system changes required by regulation, and enhanced 75 percent federal matching funds for their system’s maintenance and operation costs. These enhanced federal matching funds would be available for their Eligibility and Enrollment systems (and, if necessary, their Medicaid Management Information System (MMIS)). States would request enhanced funding through the Advance Planning Document (APD) process. E:\FR\FM\01MYR2.SGM 01MYR2 25574 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations As commenters did not provide specific information on the costs in excess of our assessment, we find that we have no basis to make a reasonable adjustment. As such, we are maintaining our estimate of the number of hours required, as detailed in sections XII. and XIII. of this final rule. Comment: One commenter opposed increasing states submission of the MMA file from monthly to daily, recommending instead that the frequency be increased to weekly. The commenter stated that determining on a daily basis whether there was any new information to send would be a significant effort, as multiple upstream systems may have to be changed, and further, that there would seldom be new data to send on a daily basis. The commenter requested that if CMS finalized the regulation to require daily exchanges that states be permitted to continue to existing processing cycles that cross business, for example, run overnight between 6:00 p.m. to 6:00 a.m. Response: We acknowledge the commenter’s concerns about resources, but note that other commenters—even those who echoed concerns about resources—uniformly supported the value of daily exchanges in improving the experience of dually eligible individuals and the ability of providers and plans to coordinate eligibility, enrollment, benefits, and/or care for this population. As we note above, we are committed to providing technical assistance and federal matching funds to support needed systems changes at the state. As a result, we decline to make the recommended change. With respect to the point that there would not be updates on a daily basis, we reiterate that no file would be required on business days when there were no updates. We expect that states would be able to automate their systems so that they check daily for changes to data that would need to be submitted to CMS on the MMA file, but also automate a process by which the system only generates an MMA file upon identifying such a change. We appreciate the additional coding required to implement this logic but that that once implemented, no additional interventions would be needed. We will work with states that have implemented these changes to identify and share best practices in identifying data changes to trigger daily submissions. Finally, in response to the concern about states that have an overnight processing cycle to continue so to meet the definition of ‘‘daily,’’ the proposed regulation would permit this. After consideration of the public comments and for the reasons VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 articulated in the CMS Interoperability and Patient Access proposed rule and our responses to comments, we are finalizing 42 CFR 423.910 as proposed. B. Request for Stakeholder Input In addition to the proposals discussed above, we sought public comment for consideration in potential future rulemaking on how we can achieve greater interoperability of federal-state data for dually eligible individuals, including in the areas of program integrity and care coordination, coordination of benefits and crossover claims, beneficiary eligibility and enrollment, and their underlying data infrastructure. For more information on our request for comment, see the CMS Interoperability and Patient Access proposed rule (84 FR 7645). We thank commenters for their input. We will consider the information received for potential future rulemaking. Final Action: We will require all states to participate in daily exchange of buy-in data, which includes both sending data to CMS and receiving responses from CMS daily, and require all states submit the required MMA file data to CMS daily by April 1, 2022. These policies are being finalized in 42 CFR 406.26, 407.40, and 423.910, respectively, as proposed. These requirements will improve the experience of dually eligible individuals and the ability of providers and payers to coordinate eligibility, enrollment, benefits, and/or care for this population. Federal matching funds of 50 percent for administration are available to support states’ costs. States may also be eligible for enhanced 90 percent federal matching funds for the costs of developing and implementing any necessary system changes required by this regulation, and enhanced 75 percent federal matching funds for their system’s maintenance and operation costs. CMS will provide technical assistance to the states that need to make changes to submit their files daily, including best practices on the upstream data sets necessary to implement daily MMA file submissions. VIII. Information Blocking Background and Public Reporting Provisions, and Analysis of and Responses to Public Comments A. Information Blocking Background 1. Legislative Background and Policy Considerations The nature and extent of information blocking has come into focus in recent years. In 2015, at the request of the Congress, ONC submitted a Report on PO 00000 Frm 00066 Fmt 4701 Sfmt 4700 Health Information Blocking 51 (hereinafter referred to as the ‘‘Information Blocking Congressional Report’’), in which ONC commented on the then current state of technology, health IT, and health care markets. Notably, ONC observed that prevailing market conditions create incentives for some individuals and entities to exercise their control over electronic health information in ways that limit its availability and use. Since that time, ONC and other divisions of HHS have continued to receive feedback from patients, clinicians, health care executives, payers, app developers and other technology companies, registries and health information exchanges, professional and trade associations, and many other stakeholders regarding practices which may constitute information blocking. Despite significant public and private sector efforts to improve interoperability and data liquidity, engagement with stakeholders confirms that adverse incentives remain and continue to undermine progress toward a more connected health system. Based on these economic realities and first-hand experience working with the health IT industry and stakeholders, ONC concluded in the Information Blocking Congressional Report that information blocking is a serious problem and recommended that the Congress prohibit information blocking and provide penalties and enforcement mechanisms to deter these harmful practices. MACRA became law in the same month that the Information Blocking Congressional Report was published. Section 106(b)(2)(A) of MACRA amended section 1848(o)(2)(A)(ii) of the Act to require that an eligible professional must demonstrate that he or she has not knowingly and willfully taken action (such as to disable functionality) to limit or restrict the compatibility or interoperability of certified EHR technology, as part of being a meaningful EHR user. Section 106(b)(2)(B) of MACRA made corresponding amendments to section 1886(n)(3)(A)(ii) of the Act for eligible hospitals and, by extension, under section 1814(l)(3) of the Act for CAHs. Sections 106(b)(2)(A) and (B) of MACRA provide that the manner of this demonstration is to be through a process specified by the Secretary, such as the use of an attestation. To implement these provisions, as discussed further 51 Office of the National Coordinator. (2015, April 9). Report to Congress on Health Information Blocking. Retrieved from https://www.healthit.gov/ sites/default/files/reports/info_blocking_ 040915.pdf. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations below, we established and codified attestation requirements to support the prevention of information blocking, which consist of three statements containing specific representations about a health care provider’s implementation and use of CEHRT. To review our discussion of these requirements, we refer readers to the CY 2017 Quality Payment Program final rule (81 FR 77028 through 77035). Recent empirical and economic research further underscores the complexity of the information blocking problem and its harmful effects. For a full discussion of the research, see the CMS Interoperability and Patient Access proposed rule (84 FR 7645 through 7646). In December 2016, section 4004 of the Cures Act added section 3022 of the PHSA (the ‘‘PHSA information blocking provision’’), which defines conduct by health care providers, health IT developers, and health information exchanges and networks that constitutes information blocking. The PHSA information blocking provision was enacted in response to ongoing concerns that some individuals and entities are engaging in practices that unreasonably limit the availability and use of electronic health information for authorized and permitted purposes (see the definition of electronic health information proposed by ONC for HHS adoption at 45 CFR 171.102 (84 FR 7588)). These practices undermine public and private sector investments in the nation’s health IT infrastructure and frustrate efforts to use modern technologies to improve health care quality and efficiency, accelerate research and innovation, and provide greater value and choice to health care consumers. The information blocking provision defines and creates possible penalties and disincentives for information blocking in broad terms, working to deter the entire spectrum of practices likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information. The PHSA information blocking provision applies to health care providers, health IT developers, exchanges, and networks. The information blocking provision also provides that the ‘‘Secretary, through rulemaking, shall identify reasonable and necessary activities that do not constitute information blocking for purposes of the definition at section 3022(a)(1) of the PHSA.’’ ONC’s 21st Century Cures Act proposed rule proposed ‘‘exceptions’’ to the information blocking provision. These exceptions are reasonable and necessary VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 activities that would not constitute information blocking. In addition to the attestation discussed in this section, all health care providers would also be subject to the separate information blocking regulations proposed by ONC for HHS adoption at 45 CFR part 171 (84 FR 7601 through 7605). B. Public Reporting and Prevention of Information Blocking on Physician Compare Physician Compare (https:// www.medicare.gov/physiciancompare) draws its operating authority from section 10331(a)(1) of the Affordable Care Act. Consistent with section 10331(a)(2) of the Affordable Care Act, Physician Compare initiated a phased approach to publicly reporting performance scores that provide comparable information on quality and patient experience measures. A complete history of public reporting on Physician Compare is detailed in the CY 2016 Physician Fee Schedule (PFS) final rule with comment period (80 FR 71117 through 71122). More information about Physician Compare, including the history of public reporting and regular updates about what information is currently available, can also be accessed on the Physician Compare Initiative website at https://www.cms.gov/ medicare/quality-initiatives-patientassessment-instruments/physiciancompare-initiative/. As discussed in the CY 2018 Quality Payment Program final rule (82 FR 53820), Physician Compare has continued to pursue a phased approach to public reporting under MACRA in accordance with section 1848(q)(9) of the Act. For a discussion of public reporting on Physician Compare, see the CMS Interoperability and Patient Access proposed rule (84 FR 7646 through 7647). Building upon the continuation of our phased approach to public reporting and understanding the importance of preventing information blocking, promoting interoperability, and the sharing of information, we proposed to make certain data about the attestation statements on the prevention of information blocking referenced in the CMS Interoperability and Patient Access proposed rule (84 FR 7645) available for public reporting on Physician Compare, drawing upon our authority under section 10331(a)(2) of Affordable Care Act, which required us to make publicly available on Physician Compare information on physician performance that provides comparable information for the public on quality and patient experience measures. Section 10331(a)(2) of the Affordable Care Act PO 00000 Frm 00067 Fmt 4701 Sfmt 4700 25575 provided that to the extent scientifically sound measures that are developed consistent with the requirements of section 10331 of the Affordable Care Act are available, such information shall include, to the extent practicable, an assessment of the coordination of care and other information as determined appropriate by the Secretary. We noted our belief that section 10331(a)(2) of the Affordable Care Act provided the statutory authority to publicly report certain data about the prevention of information blocking attestation statements as an assessment of care coordination and as other information determined appropriate by the Secretary. Furthermore, the prevention of information blocking attestation statements are required for a clinician to earn a Promoting Interoperability performance category score, which is then incorporated into the final score for MIPS, and we are required to publicly report both of these scores under section 1848(q)(9)(A) of the Act. Publicly posting this information as an indicator is consistent with our finalized policy to publicly report, either on the profile pages or in the downloadable database, other aspects of the Promoting Interoperability performance category, such as objectives, activities, or measures specified in the CY 2018 Quality Payment Program final rule (82 FR 53826 through 53827). We note that we finalized at 42 CFR 414.1395(b), that, with the exception of data that must be mandatorily reported on Physician Compare, for each program year, we rely on the established public reporting standards to guide the information available for inclusion on Physician Compare. The public reporting standards require data included on Physician Compare to be statistically valid, reliable, and accurate; be comparable across submission mechanisms; and, meet the reliability threshold. To be included on the public facing profile pages, the data must also resonate with website users, as determined by CMS. There are three prevention of information blocking attestation statements under 42 CFR 414.1375(b)(3)(ii)(A) through (C) to which eligible clinicians reporting on the Promoting Interoperability performance category of MIPS must attest. To report successfully on the Promoting Interoperability performance category, in addition to satisfying other requirements, an eligible clinician must submit an attestation response of ‘‘yes’’ for each of these statements. For more information about these statements, we refer readers to the preamble discussion E:\FR\FM\01MYR2.SGM 01MYR2 25576 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 81 FR 77035). The Promoting Interoperability performance category weight comprises 25 percent of a MIPS eligible clinician’s final score for each MIPS payment year, as specified at 42 CFR 414.1375(a). As specified at 42 CFR 414.1405(b)(2), MIPS eligible clinicians with a final score below the performance threshold receive a negative MIPS payment adjustment factor on a linear sliding scale. Certain MIPS eligible clinicians who submit data for the Promoting Interoperability performance category may be eligible for reweighting, as specified under 42 CFR 414.1380(c)(2). As specified at 42 CFR 414.1405(a), (b)(1), and (b)(2), MIPS eligible clinicians may receive a positive, neutral, or negative MIPS payment adjustment factor. As specified at 42 CFR 414.1405(c), the applicable percent for MIPS payment year 2021 is 7 percent. For MIPS payment year 2022, and each subsequent MIPS payment year, it is 9 percent. For more information about the MIPS, we refer readers to the preamble discussion in the CY 2020 Quality Payment Program final rule (84 FR 62946 through 63083). We noted our belief that it would benefit the public to know if eligible clinicians have attested negatively to the statements under 42 CFR 414.1375(b)(3)(ii) as this may assist the patient in selecting a clinician or group who collaborates with other clinicians, groups, or other types of health care providers by sharing information electronically, and does not withhold information that may result in better care. Therefore, we proposed to include an indicator on Physician Compare for the eligible clinicians and groups that submit a ‘‘no’’ response to any of the three statements under 42 CFR 414.1375(b)(3)(ii)(A) through (C). In the event that these statements are left blank, that is, a ‘‘yes’’ or a ‘‘no’’ response is not submitted, the attestations would be considered incomplete, and we would not include an indicator on Physician Compare. We also proposed to post this indicator on Physician Compare, either on the profile pages or the downloadable database, as feasible and appropriate, starting with the 2019 performance period data available for public reporting starting in late 2020. We refer readers to the 2019 Promoting Interoperability Information Blocking Factsheet at https://qpp-cmprod-content.s3.amazonaws.com/ uploads/282/2019% 20PI%20Information%20Blocking%20 Fact%20Sheet.pdf for more information about the attestation statements. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Under 42 CFR 414.1395(b), these data must meet our established public reporting standards, including that to be included on the public facing profile pages, the data must resonate with website users, as determined by CMS. In previous testing with patients and caregivers, we learned that effective use of CEHRT is important to them when making informed health care decisions. For more information about previous testing with patients and caregivers, we refer readers to the Physician Compare Technical Expert Panel (TEP) Summary Report at https://www.cms.gov/ Medicare/Quality-Initiatives-PatientAssessment-Instruments/physiciancompare-initiative/Downloads/ Physician-Compare-TEP-Summary2018.pdf. To determine how to best display and meaningfully communicate the indicator on the Physician Compare website, the exact wording and, if applicable, profile page indicator would be determined after user testing and shared with stakeholders through the Physician Compare Initiative page, listservs, webinars, and other available communication channels. We noted that the proposal was contingent upon the availability of and technical feasibility to use the data for public reporting. We summarize the public comments we received on this topic and provide our responses. Comment: Most commenters supported our proposal to publicly report an indicator on the Physician Compare website for the eligible clinicians and groups that submit a ‘‘no’’ response to any of the three prevention of information blocking attestation statements, noting that the indicator would discourage clinicians and groups from information blocking and help Medicare patients and caregivers make informed health care decisions. Response: We thank commenters for their support and agree that publicly reporting an indicator on Physician Compare will discourage clinicians and groups from information blocking and help Medicare patients and caregivers make informed decisions. Comment: Some commenters expressed concern for various reasons about publicly reporting an indicator on the Physician Compare website for the eligible clinicians and groups that submit a ‘‘no’’ response to any of the three prevention of information blocking attestation statements. Several of these commenters thought the indicator would be redundant, since there is already an incentive for clinicians to attest to the prevention of information blocking statements in order to earn a MIPS Promoting PO 00000 Frm 00068 Fmt 4701 Sfmt 4700 Interoperability performance category score. Some commenters were concerned that an indicator may not accurately reflect whether a clinician or group is knowingly or willfully information blocking, since they may be confused about the attestation statements’ meanings. A few commenters suggested delaying Physician Compare’s indicator implementation in order to give clinicians and groups, particularly small and rural practices, time to become more familiar with the attestations. Other commenters expressed concern as to whether Medicare patients and caregivers would find the indicator useful; one of these commenters suggested conducting a pilot study to make such a determination. Finally, several commenters suggested an appeal process or an opportunity for clinicians and groups to review their information prior to public reporting. Response: We appreciate the commenters’ concerns. We believe publicly reporting an indicator on Physician Compare for the eligible clinicians and groups that submit a ‘‘no’’ response to any of the three prevention of information blocking attestation statements is not redundant, as Medicare patients and caregivers do not currently have access to this type of information, which could aid them in making informed health care decisions. Regarding concerns about clinicians, including small and rural practices, needing time to become familiar with the attestations, we believe there has been sufficient time for clinicians to become familiar with them, since these attestation statements have been a MIPS Promoting Interoperability performance category requirement since the 2017 performance period. We also believe that webinars and educational materials that CMS has made available have provided clinicians and groups an opportunity to become familiar with the information blocking attestation statements. We will also continue to support small and rural practices by offering free and customized resources available within local communities, including direct, one-on-one support from the Small, Underserved, and Rural Support Initiative along with our other no-cost technical assistance (83 FR 59720). Regarding whether an information blocking indicator would be meaningful to patients and caregivers, we note that under 42 CFR 414.1395(b), these data must meet our established public reporting standards, including that to be posted on public facing profile pages, the data must resonate with website users, as determined by CMS. Such user testing to date has shown that E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations effective CEHRT usage is important to patients when making health care decisions. In addition, as specified at 42 CFR 414.1375(b)(3)(ii), MIPS eligible clinicians must attest to the prevention of information blocking statements. For more information about these statements, we refer readers to the preamble discussion in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 81 FR 77035). In addition, we note that section 4004 of the Cures Act added section 3022 of the PHSA, which directs HHS to identify reasonable and necessary activities conducted by health care providers, health IT developers, and health information exchanges and networks that would not constitute information blocking as defined in section 3022. For more information, see the information blocking discussion in ONC’s 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). While we appreciate the commenter’s suggestion to conduct a pilot study, we believe that further user testing will allow us to gain the additional understanding necessary. Regarding the comments requesting an opportunity to review or an appeal process, we note that, under 42 CFR 414.1395(d), for each program year, CMS provides a 30-day preview period for any clinician or group with Quality Payment Program data before the data are publicly reported on Physician Compare. Although at this time we do not preview indicator information, clinicians and groups will be able to preview their Promoting Interoperability performance category information, including their attestation responses to the three statements during the MIPS targeted review process. All performance data publicly reported on Physician Compare will reflect the scores eligible clinicians and groups receive in their MIPS performance feedback, which will be available for review and potential correction during the targeted review process (83 FR 59912). Comment: Many commenters recommended additional actions to prevent information blocking, beyond publicly reporting an indicator on Physician Compare. Some commenters recommended implementing additional penalties for clinicians and groups that attest ‘‘no’’ to the prevention of information blocking attestations, such as corrective action. Other commenters suggested CMS offer more positive incentives. Several commenters suggested having additional indicators, such a positive one for those who attest ‘‘yes.’’ Another commenter VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 recommended treating a blank response to the three attestation statements as a ‘‘no’’ response. A few commenters recommended that the proposed indicator not be used for clinicians and groups that participate in trusted exchange networks. Response: We appreciate commenters’ suggestions and will consider them for potential future rulemaking, to the extent permitted by our authority. To the extent of our authority, we will consider treatment of attestation statements that are left blank, use of a positive indicator on the Physician Compare profile pages or downloadable database, and the use of the proposed indicator for clinicians and groups that participate in trusted exchange networks for potential future rulemaking. Regarding commenters’ suggestions for additional penalties, we note that section 4004 of the Cures Act identifies potential penalties and disincentives for information blocking. Health care providers determined by the Inspector General to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable federal law, as the Secretary sets forth through notice and comment rulemaking. In the ONC 21st Century Cures Act proposed rule, a request for information regarding disincentives for health care providers was included (84 FR 7553). Comment: Some commenters requested additional information on the proposed information blocking indicator. A few of these commenters requested additional information on the attestation requirements for clinicians and groups participating in other programs, such as Medicare Advantage. Several commenters requested additional guidance on exceptions to the attestations. Another commenter requested more information on the implications for clinicians and groups who leave the attestation statements blank and do not attest ‘‘yes’’ or ‘‘no.’’ Several commenters questioned how clinicians’ responses to the three attestation statements would be verified for accuracy. Response: The three attestation statements are required under the MIPS, which is a Medicare FFS program. We note that 42 CFR 414.1310(b) and (c) provide that Qualifying APM Participants (QPs) and Partial QPs who do not report on applicable measures and activities that are required to be reported under MIPS for any given performance period in a year are excluded from this definition at 42 CFR 414.1305 of a MIPS eligible clinician per PO 00000 Frm 00069 Fmt 4701 Sfmt 4700 25577 the statutory exclusions defined in section 1848(q)(1)(C)(ii) and (v) of the Act. Therefore, the prevention of information blocking indicator would be applicable only to MIPS eligible clinicians and groups under Medicare FFS and not to other programs, such as MA. Under MIPS, the attestation statements are required for all eligible clinicians under the Promoting Interoperability performance category of MIPS, as specified at 42 CFR 414.1375(b)(3)(ii) (81 FR 77035). If the attestation statements are left blank, that is, a ‘‘yes’’ or ‘‘no’’ response is not submitted, the attestations would be considered incomplete and the clinician or group would not receive a Promoting Interoperability performance category score. In this situation, we would not have an affirmative or negative response to the three attestation statements from the clinician or group, and we would not have enough information to determine whether the clinician or group is knowingly and willfully information blocking. Regarding exceptions to the attestation requirements, under 42 CFR 414.1380(c)(2) the Promoting Interoperability performance category may be reweighted to zero percent of the final score for a MIPS eligible clinician in certain circumstances, and clinicians who receive reweighting would not have to submit data for the Promoting Interoperability performance category, including their responses to the attestation statements. Regarding verification of clinicians’ attestation statements, we note that we finalized in prior rulemaking that we will perform ongoing monitoring of MIPS eligible clinicians and groups on an ongoing basis for data validation, auditing, program integrity issues, and instances of non-compliance with MIPS requirements. If a MIPS eligible clinician or group is found to have submitted inaccurate data for MIPS, we finalized that we would reopen and revise the determination in accordance with the rules set forth at 42 CFR 405.980 through 405.986 (81 FR 77362). Final Action: After consideration of the comments received, and for the reasons outlined in our responses to these comments, we are finalizing this policy as proposed. Specifically, we are finalizing to include an indicator on Physician Compare for the eligible clinicians and groups that submit a ‘‘no’’ response to any of the three prevention of information blocking attestation statements for MIPS under 42 CFR 414.1375(b)(3)(ii)(A) through (C), as proposed. In the event that these statements are left blank, that is, a ‘‘yes’’ E:\FR\FM\01MYR2.SGM 01MYR2 25578 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations or a ‘‘no’’ response is not submitted, the attestations will be considered incomplete, and we will not include an indicator on Physician Compare. We will post this indicator on Physician Compare, either on the profile pages or in the downloadable database, as feasible and appropriate, starting with the 2019 performance period data available for public reporting starting in late 2020. C. Public Reporting and Prevention of Information Blocking for Eligible Hospitals and Critical Access Hospitals (CAHs) Section 1886(n)(4)(B) of the Act requires the Secretary to post in an easily understandable format a list of the names and other relevant data, as determined appropriate by the Secretary, of eligible hospitals and CAHs who are meaningful EHR users under the Medicare FFS program, on a CMS website. In addition, that section requires the Secretary to ensure that an eligible hospital or CAH has the opportunity to review the other relevant data that are to be made public with respect to the eligible hospital or CAH prior to such data being made public. We noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7647) that we believed certain information related to the prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) would constitute other relevant data under section 1886(n)(4)(B) of the Act. Specifically, we referred to the three prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) to which eligible hospitals and CAHs must attest for purposes of the Promoting Interoperability Program. As part of successfully demonstrating that an eligible hospital or CAH is a meaningful EHR user for purposes of the Promoting Interoperability Program, the eligible hospital or CAH must submit an attestation response of ‘‘yes’’ for each of these statements. For more information about these statements, we referred readers to the preamble discussion in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 77035). We noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7647) that we believed it would be relevant to the public to know if eligible hospitals and CAHs have attested negatively to the statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) as it could indicate that they are knowingly and unreasonably interfering with the exchange or use of electronic health information in ways that limit its VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 availability and use to improve health care. As we stated in the CY 2017 Quality Payment Program final rule, we believed that addressing issues related to information blocking would require additional and more comprehensive measures (81 FR 77029). In addition, publicly posting this information would reinforce our commitment to focus on increased interoperability and the appropriate exchange of health information. We proposed to post information on a CMS website available to the public indicating that an eligible hospital or CAH attesting under the Medicare FFS Promoting Interoperability Program submitted a ‘‘no’’ response to any of the three statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3). In the event that these statements are left blank, that is, a ‘‘yes’’ or a ‘‘no’’ response is not submitted, we proposed the attestations would be considered incomplete, and we would not post any information related to these attestation statements for that hospital or CAH. We proposed to post this information starting with the attestations for the EHR reporting period in 2019, and we expected the information would be posted in late 2020. In accordance with section 1886(n)(4)(B) of the Act, we proposed to establish a process for each eligible hospital and CAH to review the information related to their specific prevention of information blocking attestation statements before it is publicly posted on a CMS website. Specifically, for each program year, we proposed a 30-day preview period for an eligible hospital or CAH to review this information before it is publicly posted. During the 30-day preview period, we proposed that all of the information that we would publicly post would be available for the eligible hospital or CAH to review, and we would consider making changes to the information on a case-by-case basis (for example, in the event the eligible hospital or CAH identifies an error, and we subsequently determine that the information is not accurate). Additional information on the review process would be provided outside of the rulemaking process through the usual communication channels for the program. We summarize the public comments we received on this topic and provide our responses. Comment: Many commenters indicated their strong support for this proposal and suggested that we finalize the proposal, as commenters believe it is necessary in building an interoperable health system. One commenter believes that maintaining accountability and enforcing penalties is critical to PO 00000 Frm 00070 Fmt 4701 Sfmt 4700 maintaining individual health and safety. Another commenter agreed, stating that information blocking is detrimental to the health, safety, and welfare of patients. Many commenters indicated that information blocking should not be tolerated for competitive or financial reasons, further indicating that consumers and stakeholders should be made aware of those who participate in information blocking practices, as this transparency can prevent potential medical errors and improve the overall quality of care. Response: We thank commenters for their support for the proposal. We agree with the commenters and believe that the proposed policy would be both appropriate and effective in reinforcing our commitment to focus on increasing interoperability and the appropriate exchange of health information. Knowingly or willfully preventing, avoiding, or withholding information limits interoperability and prevents the sharing of important health information. Comment: Many commenters indicated support for the promotion of health information exchange and the prevention of information blocking, generally, but expressed several concerns about the implementation of this proposal. A couple of commenters were concerned that there is not enough time to develop the policies and procedures needed to streamline the proposed process, and in response, suggested building in a period of nonenforcement (a practice period without posting any information publicly). Several commenters expressed concern that there will not be an opportunity to dispute information prior to publication, and requested including a guarantee of the proposed 30-day preview period prior to the publication of certain information on a CMS website. Finally, commenters had concerns about how policies related to information blocking and changes to the 2015 Edition of certified health IT proposed in ONC’s 21st Century Cures Act proposed rule may impact the prevention of information blocking attestations under the Promoting Interoperability Program. Response: We appreciate the commenters’ concerns and suggestions. We are finalizing the proposal to post this information starting with the attestations for the EHR reporting period in 2019, and we are targeting for this information to be posted in late 2020. Although we will not have a period of non-enforcement (postponing posting of information publicly), we are building in a 30-day preview period during which any discrepancies or concerns may be addressed on a case-by-case E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations basis prior to posting. Additional information on the preview period will be provided outside of the rulemaking process through the usual communication channels for the program. With regard to ONC’s 21st Century Cures Act rule, the prevention of information blocking attestation statements under the Promoting Interoperability Program are not affected by ONC’s final rule policies and remain unchanged. Comment: A number of commenters supported the prevention of information blocking, but had concerns about the additional burden this proposal may add. One commenter requested reassurance that this process will not increase burden, while a few other commenters shared concerns that this process will increase burden. Response: We appreciate the commenters’ concerns. As eligible hospitals and CAHs are already required to respond to these three attestation statements under the Promoting Interoperability Program, we do not believe this proposal would require additional reporting effort, or thereby increase burden. We do not believe the 30-day preview period would increase burden as it will be an opportunity for eligible hospitals and CAHs to ensure the accuracy of the information that will be posted publicly, should they choose to take advantage of this opportunity. Comment: Many commenters stated that there should be an audit or spot check process to validate the responses provided to the three attestation statements. Commenters indicated concern that those who knowingly participate in information blocking practices will answer ‘yes’ to the three attestation statements simply to complete the question/answer sequencing in the reporting system. Further, commenters expressed concern regarding how easy it could be for their peers to respond dishonestly, and requested more stringent auditing practices from CMS. A number of commenters requested additional information on how a ‘‘blank’’ response would be treated for purposes of this proposal; one commenter believed that a ‘‘blank’’ should be considered a ‘‘no’’, and another commenter believed that a ‘‘blank’’ should simply be considered as a ‘‘blank.’’ Response: We appreciate the commenters’ concerns. We do not have a specific auditing practice in place for these specific attestation statements. Instead, all eligible hospitals and CAHs are required to submit responses to the attestation statements under the Promoting Interoperability Program and must respond accurately, as any eligible VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 hospital or CAH participating in the Promoting Interoperability Program may be subject to an audit. In the event that an eligible hospital or CAH leaves a ‘‘blank’’ response to an attestation statement, where a ‘‘yes’’ or a ‘‘no’’ response is not submitted, the response would be considered incomplete, and no information would be posted related to these attestation statements at this time. Comment: Many commenters supported the effort to prevent information blocking, though several believed that posting certain information on a CMS website of those who attest ‘no’ to the prevention of information blocking statements may not strongly impact the issue. Of the reasons given, one commenter remained agnostic on whether such a policy would have tangible success in deterring information blocking, several commenters stated that the information posted on a CMS website will have little meaning to consumers, and others believed that this process would not promote interoperability nor would it improve patient access to information. Response: We appreciate all of the commenters’ concerns. As discussed in the CY 2017 Quality Payment Program Final Rule (81 FR 77029), the act of information blocking is a systemic problem that Congress has expressed concerns about. Growing evidence has established that there is a strong incentive for health care providers to unreasonably interfere with the exchange of health information. We believe that publicly posting certain information on a CMS website is one valuable tool in our continued effort to deter these information blocking practices. As patients gain access to more data, they become more empowered and more informed decision makers. Knowing if a physician may be information blocking could influence their decision to see that physician. In addition, knowing patients can see this information may deter physicians from engaging in this behavior. For these reasons, we do believe that this effort will have an impact and be meaningful to consumers. We do also believe that this policy will promote interoperability and improve patient access to information. With patients becoming more empowered, this drives health care providers to move toward information sharing rather than information blocking, which directly leads to improved patient access to information. Comment: A couple commenters suggested moving away from posting public information, and instead focusing on creating positive incentive PO 00000 Frm 00071 Fmt 4701 Sfmt 4700 25579 programs, enhancing guidance, providing more education, and fostering change through encouraging the prevention of information blocking. Some commenters agreed with the approach, but believed CMS could develop more concrete measures that would have a stronger justification for posting information on a CMS website versus using the three attestation statements. Response: Thank you for these comments and suggestions. To the extent that the commenters are requesting that we create positive incentive programs that include incentive payments to eligible hospitals and CAHs, we note that we can only do so to the extent authorized by law. We will take into consideration the suggestions for enhancing prevention of information blocking guidance, providing more education, and fostering change through encouragement in potential future rulemaking. Comment: A few commenters were in favor of posting certain information on eligible hospitals and/or CAHs that provide a ‘‘no’’ response to the prevention of information blocking attestation statements, but have requested additional ways to discourage this practice. Commenters requested that those who are knowingly and willfully blocking the transfer of information also be fined, per instance or per patient, as a way of disincentivizing this practice. A couple commenters suggested strengthening this provision by establishing an easy way for stakeholders to report potential information blocking activities. Response: We appreciate the commenters’ suggestions regarding additional ways to discourage information blocking. We refer commenters to section 3022(b)(2)(B) of the PHSA, which provides that any health care provider determined by the Office of the Inspector General (OIG) to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable federal law, as the Secretary sets forth through notice and comment rulemaking. Health care providers would also be subject to the separate information blocking regulations proposed by ONC for HHS adoption at 45 CFR part 171 (84 FR 7601 through 7605). Further, we note that ONC’s 21st Century Cures Act proposed rule included a request for information regarding disincentives for health care providers (84 FR 7553). Comment: Many commenters, while in agreement with publicly posting certain information related to E:\FR\FM\01MYR2.SGM 01MYR2 25580 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations information blocking, had concerns that eligible hospitals and CAHs are being held accountable for the practices of health IT vendors. Many commenters were concerned that vendors are restricting the transfer of data by data embargoing, actively blocking, and refusing or prohibiting the transfer of data. Further, there were concerns that vendors are requiring complex programs, the purchase of many costly programs, and requiring excessive fees to conduct data transfer. Last, several commenters requested that vendors be penalized equally, and in the same manner, as eligible hospitals and CAHs. Response: We appreciate the commenters’ support for the proposal, and we also appreciate their concerns. We emphasize that the information blocking provision (section 4004 of the Cures Act) applies to health IT developers of certified health IT. Section 3022(a)(1) of the PHSA, in defining information blocking, refers to four classes of individuals and entities that may engage in information blocking and which include: Health care providers, health IT developers of certified health IT, networks, and exchanges. In the ONC 21st Century Cures Act proposed rule, ONC proposed to adopt definitions of these terms to provide clarity regarding the types of individuals and entities to whom the information blocking provision applies (84 FR 7601 through 7602). Regarding penalties, section 4004 of the Cures Act identifies potential penalties and disincentives for information blocking. Health IT developers, health information networks, and health information exchanges that the Inspector General, following an investigation, determines to have committed information blocking shall be subject to a civil monetary penalty determined by the Secretary for all such violations identified through such investigation, which may not exceed $1,000,000 per violation. Such determination shall take into account factors such as the nature and extent of the information blocking and harm resulting from such information blocking, including, where applicable, the number of patients affected, the number of providers affected, and the number of days the information blocking persisted. Health care providers determined by the Inspector General to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable Federal law, as the Secretary sets forth through notice and comment rulemaking. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Comment: One commenter suggested a collaboration between CMS, ONC, and OIG in order to address information blocking together, to combat information blocking consistently and from all angles. Response: We appreciate the commenter’s suggestion, and note that CMS, ONC, and OIG are consistently working together on issues such as information blocking so that our policies are complementary and work together to address the issue. Final Action: After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing this policy as proposed. We will include information on a CMS website available to the public indicating that an eligible hospital or CAH attesting under the Medicare FFS Promoting Interoperability Program submitted a ‘‘no’’ response to any of the three prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3). We will post this information starting with the attestations for the EHR reporting period in 2019, and expect the information will be posted in late 2020. In the event that an eligible hospital or CAH leaves a ‘‘blank’’ response to an attestation statement, where a ‘‘yes’’ or a ‘‘no’’ response is not submitted, the attestations will be considered incomplete, and no information will be posted related to these attestation statements. We will establish a process for each eligible hospital and CAH to review the information related to their specific prevention of information blocking attestation statements before it is publicly posted on the CMS website. For each program year, we will have a 30-day preview period for an eligible hospital or CAH to review this information before it is publicly posted. During the 30-day preview period, all of the information that we will publicly post will be available for the eligible hospital or CAH to review, and we will consider making changes to the information on a case-by-case basis. IX. Provider Digital Contact Information Provisions, and Analysis of and Responses to Public Comments A. Background Congress required the Secretary to create a provider digital contact information index in section 4003 of the Cures Act. This index must include all individual health care providers and health care facilities, or practices, in order to facilitate a comprehensive and PO 00000 Frm 00072 Fmt 4701 Sfmt 4700 open exchange of patient health information. Congress gave the Secretary the authority to use an existing index or to facilitate the creation of a new index. In comments received on the FY 2019 IPPS proposed rule RFI, there was strong support for a single, public directory of provider digital contact information. Commenters noted that digital communication could improve interoperability by facilitating efficient exchange of patient records, eliminating the burden of working with scanned paper documents, and ultimately enhancing care coordination. To ensure the index is accessible to all clinicians and facilities, we updated the National Plan and Provider Enumeration System (NPPES) 52 to be able to capture digital contact information for both individuals and facilities. It is important to note that the aforementioned updates to the NPPES entailed the addition of two additional data fields. However, due to an administrative oversight, the data elements which allow for the digital capture of contact information are not OMB approved. CMS acknowledges this violation of the Paperwork Reduction Act of 1995 (PRA) and is currently working to remediate the issue by creating a new PRA package and thereby come into compliance with the PRA. Prior to its submission for OMB approval, the new information collection request will be made available for public review and comment as required by the PRA. NPPES currently supplies National Provider Identifier (NPI) numbers to health care providers (both individuals and facilities), maintains their NPI record, and publishes the records online. The Secretary adopted the NPI as the HIPAA administrative simplification standard identifier for health care providers (69 FR 3434). HIPAA covered entities, including health care providers, health plans, and health care clearinghouses, must use the NPI in HIPAA transactions. All health care providers that transmit health information in electronic form in connection with a HIPAA transaction must obtain an NPI. Health care providers are required to communicate to the NPPES any information that has changed within 30 days of the change (45 CFR 162.410(a)(4)). We review NPPES to ensure a provider has a valid NPI as part of the Medicare enrollment process, as well as the revalidation process, which occurs every 3 to 5 years depending on the provider or supplier type. 52 The NPPES website at https:// nppes.cms.hhs.gov/. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Information in NPPES is publicly accessible via both an online search option and a downloadable database option. As a result, adding digital contact information to this existing index is an efficient and effective way to meet the Congressional requirement to establish a digital contact information index and to promote the sharing of information. As of June 2018, NPPES has been updated to include the capability to capture one or more pieces of digital contact information that can be used to facilitate secure sharing of health information. For instance, providers can submit a Direct address, which functions similar to a regular email address, but includes additional security measures to ensure that messages are only accessible to the intended recipient in order to keep the information confidential and secure. ‘‘Direct’’ is a technical standard for exchanging health information. Direct addresses are available from a variety of sources, including EHR vendors, State Health Information Exchange entities, regional and local Health Information Exchange entities, as well as private service providers offering Direct exchange capabilities called Health Information Service Providers (HISPs) (https://www.healthit.gov/sites/default/ files/directbasicsforprovidersqa_ 05092014.pdf). NPPES can also capture information about a wide range of other types of endpoints that providers can use to facilitate secure exchange of health information, for instance a FHIR server URL or query endpoint associated with a health information exchange. We strongly encourage the inclusion of this FHIR endpoint information in NPPES in support of the Patient Access API policy discussed in section III. of this final rule and the Provider Directory API policy discussed in section IV. of this final rule. Using NPPES as one way to make these endpoints publicly known will significantly support interoperability throughout the health care system. In addition, NPPES can now maintain information about the type of contact information providers and organizations are associated with, along with the preferred uses for each address. Each provider in NPPES can maintain their own unique information or associate themselves with information shared among a group of providers. Finally, in March 2019, NPPES added a public API which can be used to obtain the digital contact information stored in the database. Although NPPES is now better equipped to maintain provider digital contact information, many providers have not submitted this information. In the 2015 final rule, ‘‘Medicare and VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Medicaid Programs; Electronic Health Record Incentive Program-Stage 3 and Modifications to Meaningful Use in 2015 Through 2017’’ (80 FR 62901), we finalized a policy to collect information in NPPES about the electronic addresses of participants in the EHR Incentive Program (specifically, a Direct address and/or other ‘‘electronic service information’’ as available). However, this policy was not fully implemented at the time, in part due to the limitations of the NPPES system which have since been addressed. As a result, many providers have not yet added their digital contact information to NPPES and digital contact information is frequently out of date. In light of these updates to the NPPES system, all individual health care providers and facilities can take immediate action to update their NPPES record online to add digital contact information. This simple step will significantly improve interoperability by making valuable contact information easily accessible. For those providers who continue to rely on the use of cumbersome, fax-based modes of sharing information, we hope that greater availability of digital contact information will help to reduce barriers to electronic communication with a wider set of providers with whom they share patients. Ubiquitous, public availability of digital contact information for all providers is a crucial step towards eliminating the use of fax machines for the exchange of health information. We urged all providers to take advantage of this resource to implement Congress’ requirement that the Secretary establish a digital contact information index. B. Public Reporting of Missing Digital Contact Information Entities seeking to engage in electronic health information exchange need accurate information about the electronic addresses (for example, Direct address, FHIR server URL, query endpoint, or other digital contact information) of potential exchange partners. A common directory of the electronic addresses of health care providers and organizations could enhance interoperability and information exchange by providing a resource where users can obtain information about how to securely transmit electronic health information to a provider. We proposed to increase the number of providers with valid and current digital contact information available through NPPES by publicly reporting the names and NPIs of those providers who do not yet have their digital contact PO 00000 Frm 00073 Fmt 4701 Sfmt 4700 25581 information included in the NPPES system. We proposed to begin this public reporting in the second half of 2020, to allow individuals and facilities time to review their records in NPPES and update the system with appropriate digital contact information. We also requested comment from stakeholders on the most appropriate way to pursue this public reporting initiative, including where these names should be posted, with what frequency, and any other information stakeholders believed would be helpful. We noted that we believed this information would be extremely valuable to facilitate interoperability, and we appreciated Congress’ leadership in requiring the establishment of this directory. We requested stakeholder comment on additional possible enforcement authorities to ensure that individuals and facilities make their digital contact information publicly available through NPPES. For example, we questioned if Medicare reporting programs, such as MIPS, should require eligible clinicians to update their NPPES data with their digital contact information? Should CMS require this information to be included as part of the Medicare enrollment and revalidation process? How can CMS work with states to promote adding information to the directory through state Medicaid programs and CHIP? Should CMS require providers to submit digital contact information as part of program integrity processes related to prior authorization and submission of medical record documentation? We noted that we would review comments for possible consideration in future rulemaking on these questions. We summarize the public comments we received on this topic and provide our responses. Comment: Many stakeholders shared our goal of improving the accuracy and completeness of data in the NPPES. Response: We thank commenters for their support and are finalizing this policy as proposed. Comment: Many commenters, while supporting the ultimate goal of the proposal, noted doubts about whether the proposal would be effective at increasing the accuracy and completeness of digital contact information in NPPES. Commenters believed that a public reporting mechanism would not serve as a meaningful deterrent to providers leaving their information blank. One commenter stated that they believed, even with the implementation of this proposal, high rates of inaccuracies would persist in NPPES, and E:\FR\FM\01MYR2.SGM 01MYR2 25582 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations stakeholders would continue to rely on internal sources of information. Several commenters stated that, given the likelihood that this proposal would not result in meaningful improvements, this proposal would represent unnecessary administrative burden for providers. Response: We thank commenters for their feedback on the potential effectiveness of this proposal. While we believe that this proposal is an important initial step toward increasing the accuracy of information in NPPES, we appreciate that this proposal may not be sufficient to fully realize the goal of NPPES serving as a comprehensive index of provider digital contact information. To this end, we requested comment on other programs that CMS could leverage to improve the completeness and accuracy of information in NPPES. The responses to this comment solicitation are discussed in more detail below. Comment: Many commenters recommended that, instead of pursuing a policy based on ‘‘public shaming,’’ it would be more effective for CMS to consider incentive-based policies for updating their digital contact information in NPPES. Response: We thank commenters for their recommendations. While we believe the proposed policy is an important step toward increasing the completeness and accuracy of information in NPPES, we believe that other policy initiatives using incentives may be effective as well, such as leveraging opportunities under the MIPS program, and we will consider these approaches for potential inclusion in future rulemaking. Comment: In the proposed rule, CMS requested comment on additional possible enforcement authorities to ensure that individuals and facilities make their digital contact information publicly available through NPPES. Many commenters supported the use of other authorities to increase the accuracy and completeness of digital contact information in NPPES, stating that they believe these authorities were more likely to be effective than the proposed policy for publicly reporting the names and NPIs of those providers that have not included digital contact information in NPPES. For instance, many commenters believed that including this requirement in the MIPS program would be a more effective strategy for achieving the goals of the policy. Commenters believed this would be more effective due to the incentives available through the MIPS program. Commenters also believed that use of the MIPS program would be more effective since the Promoting VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Interoperability category of MIPS already includes requirements to electronically exchange health information, and the goal of increasing availability of digital contact information would align with those features of the program. Commenters also believed that tying this policy to the MIPS program would help to ensure annual updates of digital contact information as part of required MIPS data submissions. Several commenters also supported the use of the Medicare enrollment or revalidation process and the use of program integrity processes as ways to promote updating of digital contact information in NPPES. Response: We thank commenters for their input on additional enforcement mechanisms. We will take these comments under consideration as we consider potential future rulemaking or operational changes to these programs that are consistent with each program’s statutory authority. Comment: Many commenters suggested that CMS provide additional education and guidance about the benefits of adding their digital contact information to NPPES. These commenters recommended that CMS engage in public education as a necessary step before proceeding with public reporting in order to build awareness among providers of the importance of updating this information. For instance, one commenter noted that many hospitalbased physicians are not aware of their digital contact information, currently relying on their institution’s informatics division to manage this data. Others suggested that providers are not aware of the new functionality in NPPES allowing for submission of digital contact information and that education will be needed to familiarize providers with this feature. Commenters recommended that public education initiatives be targeted at those providers least likely to be familiar with the new functionality, and that CMS should work with specialty societies and other provider representatives to ensure education reaches a wide variety of providers. Some commenters also stated that a public education initiative alone would be a more appropriate alternative to public reporting of providers’ names and NPIs. Response: We appreciate commenters’ recommendations around the need for public education. Since updating the functionality in NPPES starting in 2018, we have taken steps to familiarize the provider community with these updates and plan to continue and expand this outreach. We agree that education PO 00000 Frm 00074 Fmt 4701 Sfmt 4700 efforts will be important to ensure that providers are aware of their responsibilities and that they may be at risk of having their names and NPIs publicly reported if they do not update their digital contact information in NPPES in a timely manner. While recognizing the importance of public education, we also believe that more aggressive steps are needed to accelerate the accuracy of completeness of information within NPPES, therefore we are finalizing the policy to publicly report the names and NPIs of providers that do not include digital contact information in NPPES. Comment: CMS proposed to begin public reporting in the second half of 2020. A number of commenters suggested that CMS delay this timeframe to allow providers more time to be made aware of the policy, review their NPPES record, and add missing information. One commenter believed that this timeline was not consistent with the time that would be required for CMS to reach small providers with information about the new policy, and recommended a delay of at least an additional 12 months before public reporting begins. Response: We appreciate commenters’ concerns and suggestions regarding the appropriate timeframe for public reporting under this proposal. However, we believe that the proposed timeline allows sufficient time for outreach and education to make providers aware of the requirement. We are therefore finalizing this timeframe as proposed. Comment: Many commenters expressed concerns about the accuracy of information in NPPES, stating that inaccurate information imposes a burden on both providers and consumers who may try to collect and use this information only to find out that it is incorrect. These commenters noted inaccurate contact information also poses a problem for providers who are concerned with sending protected health information to the wrong recipient. One commenter stated that these challenges raise questions about whether a public file is appropriate to serve as the basis for increasing interoperability across provider systems. Commenters suggested steps CMS could take to improve the accuracy of information in NPPES. One commenter suggested that CMS establish a requirement that providers update their information within a set time period. Another commenter suggested that NPPES post the date that information associated with a given NPI was last updated so that individuals reviewing the database could assess its accuracy. Several commenters urged CMS to E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations conduct direct outreach to providers to confirm their information, or to validate provider information with other sources, such as state licensing boards, in order to increase accuracy. Response: We appreciate commenters’ concerns about the accuracy of provider contact information within NPPES. The ‘‘Last Updated’’ date is posted on the ‘‘NPI View’’ page for records in the public NPPES NPI Registry. It should also be noted that providers are required to update information included in NPPES within 30 days of a change (45 CFR 162.410(a)(4)). However, we understand from commenters that in practice these updates often do not occur, contributing to historical challenges with the accuracy of NPPES data. We appreciate commenters’ suggestions for ways to improve the accuracy of data within NPPES, and we will take these suggestions into consideration. Comment: Several commenters noted that providers who have not participated in the Promoting Interoperability Program (formerly the EHR Incentive Programs) are more likely to not have digital contact information available than those that have participated and received incentives for adoption of health information. Commenters stated that these providers would be at a disadvantage under the proposed policy, and that identifying these providers as noncompliant through a public reporting mechanism would be unfair. Commenters stated that this group likely includes smaller practices, rural clinicians, hospitalbased clinicians, and clinicians employed at a variety of settings which were not eligible for EHR incentives, such as rehabilitation centers. Response: We appreciate commenters’ concerns regarding those clinicians that are less likely to have existing digital contact information. While we understand that it may take more time for these clinicians to obtain and submit digital contact information to NPPES, we believe that the timeframe for implementing this proposal will provide sufficient notice to clinicians. We also believe that obtaining digital contact information, such as a Direct address, is now widely available to clinicians, including those who do not have certified EHR systems. Accordingly, we believe that these providers will be able to obtain digital contact information and add it to their NPPES record with relatively minimal burden. Comment: Many commenters suggested that CMS establish a process for offering providers a chance to review their information and correct any issues VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 prior to the implementation of public reporting. Commenters stated that CMS should issue communication to providers informing them of the status of their digital contact information, and that communications should include mechanisms which allow the provider to make corrections. One commenter recommended that CMS institute a 60day review period prior to public reporting similar to the review period established for data included on the Physician Compare website. Response: We appreciate commenters’ suggestions regarding opportunities for clinicians to review their information prior to the implementation of this public reporting policy. We have already implemented multiple methods for providers to review their information allowing them to correct any issues with their NPPES record. Providers can review their information using the NPPES NPI Registry (https://npiregistry. cms.hhs.gov/), the NPPES NPI Registry API (https://npiregistry.cms.hhs.gov/ registry/help-api), or the NPPES Data Dissemination file (https:// www.cms.gov/Regulations-andGuidance/AdministrativeSimplification/NationalProvIdentStand/ DataDissemination). Each source currently contains all the information that will allow providers to determine the correctness of their information. As discussed above, we will also engage in continued public education efforts to ensure providers are aware of the benefits of including digital contact information in NPPES, as well as the associated public reporting policy. Comment: Several commenters requested additional information about what kind of digital contact information would satisfy this requirement. One commenter recommended that providers should be able to specify other digital endpoints besides a Direct address. Another commenter requested clarity on whether the digital fax numbers would qualify as digital contact information. Response: As discussed in the proposed rule, NPPES is able to capture a variety of different digital endpoints. A digital fax number is not considered a digital endpoint for the purposes of this proposal. For more information on the digital contact information which can be added to NPPES, see https:// nppes.cms.hhs.gov/webhelp/nppeshelp/ HEALTH%20INFORMATION%20 EXCHANGE.html. Comment: Several commenters recommended that CMS partner with other centralized authorities that collect provider information. Commenters stated that relying on providers alone to update their information will not PO 00000 Frm 00075 Fmt 4701 Sfmt 4700 25583 provide the levels of accuracy necessary for other providers to utilize NPPES for routine exchange of electronic health information. Commenters noted that today, directory services that employ appropriate identify proofing processes and other means for ensuring records are up-to-date are much more likely to possess accurate information than NPPES, and CMS should seek to improve the quality of NPPES by working with these partners. Commenters believed that by working with these entities, CMS could greatly reduce provider burden associated with entering information into and updating information in NPPES. Response: We appreciate commenters’ input regarding other strategies to improve the accuracy of the digital contact information within NPPES. Comment: Several commenters requested additional guidance on how the public reporting mechanism would operate. One commenter sought information on where the names would be publicly reported. Another commenter questioned how CMS would address public reporting of providers that have an NPI but do not have active practice locations where they are providing services under Medicare or engaging in communication with patients. Response: We thank commenters for these questions. Following the publication of the final rule, we will release additional information around the public reporting mechanism including where we intend to publish the names and NPIs of providers that do not have digital contact information in NPPES, as well as information about whether certain providers would be exempt from public reporting. Comment: One commenter questioned how providers would be expected to know their digital contact information as this information may not be visible to providers in many EHR systems. Response: We encourage providers, especially clinicians, to work with health IT administrators in their organization or directly with their health IT vendor if they are unclear on where their digital contact information can be found. We also note that NPPES now provides for bulk uploading of information to multiple NPI records, and encourage clinicians to work with health IT administrators in their organization to develop streamlined processes for updating this information in a way that imposes minimal burden on clinicians. Comment: Several commenters noted the Provider Enrollment, Chain, and Ownership System (PECOS) system E:\FR\FM\01MYR2.SGM 01MYR2 25584 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations would be the most appropriate location for storing digital contact information. Response: While we understand the interest in using PECOS as the location for storing digital contact information, we are not considering this as an option at this time. PECOS collects information specific to provider and supplier enrollment in the Medicare program and the system is limited to the fields on the CMS 855 Enrollment forms. Any other data outside of this is optional. There are also many operational and systematic issues that prevent PECOS from being utilized to implement the digital contact information requirement. Comment: Several commenters raised questions about what entities would have access to the information in NPPES. One commenter stated that any entity should be able to gain access to NPPES in order to advance interoperability. Another noted that making digital endpoints publicly accessible via an API that may be accessible to third parties could pose a risk to the security of protected health information available through those APIs, and recommended that CMS make this information available to other entities only if the third-party entity requests access from the API owner. Response: NPPES already furnishes a public downloadable data dissemination file as well as a public API that provides the public information available in the NPI Registry. Both files are publicly accessible. Please note that this proposal is not related to the Patient Access API discussed in section III. of this final rule that can include patient protected health information. Comment: A number of commenters requested additional information on issues related to NPPES functionality, and sought guidance on how to enter digital contact information. For instance, numerous commenters believed that the NPPES does not allow for a provider to enter information for multiple practice and billing locations. Several commenters sought information about whether a provider could enter multiple digital endpoints, for instance if they employ different endpoints for different types of communication. One commenter requested information on whether a provider could enter digital contact information for his or her employer, rather than individual information. Response: For more information on how information is captured in NPPES, we encourage commenters to review information available on the NPPES website at https://nppes.cms.hhs.gov/ webhelp/nppeshelp/HEALTH%20 INFORMATION%20EXCHANGE.html. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Comment: Several commenters suggested that CMS develop a digital contact information interoperability standard for facilitating efficient exchange of patient records. Response: We appreciate commenters’ suggestions, and note that we continue to collaborate with ONC, other federal partners, and industry stakeholders, to develop more robust provider directory standards that can support exchange of this information. We also direct commenters to the discussion of the Provider Directory API in section IV. of this final rule. Final Action: After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing to publicly report the names and NPIs of those providers who do not have digital contact information included in the NPPES system beginning in the second half of 2020 as proposed. Additionally, we will engage in continued public education efforts to ensure providers are aware of the benefits of including digital contact information in NPPES, including FHIR API endpoints, and when and where this information will be posted. X. Conditions of Participation for Hospitals and Critical Access Hospitals (CAHs) Provisions, and Analysis of and Responses to Public Comments A. Background As noted in the CMS Interoperability and Patient Access proposed rule (84 FR 7649 through 7653), we appreciate the pathways Congress has created for action on interoperability and have been working diligently with ONC to implement them. In order to ensure broad stakeholder input to inform the proposals, we published a Request for Information (RFI) on interoperability in several proposed rules, including the FY 2019 IPPS proposed rule (83 FR 20550). Specifically, we published the RFI entitled, ‘‘Promoting Interoperability and Electronic Healthcare Information Exchange Through Possible Revisions to the CMS Patient Health and Safety Requirements for Hospitals and Other Medicare- and Medicaid-Participating Providers and Suppliers.’’ We requested stakeholders’ input on how we could use the CMS health and safety standards that are required for providers and suppliers participating in the Medicare and Medicaid programs (that is, the Conditions of Participation (CoPs), Conditions for Coverage (CfCs), and Requirements for long term care facilities) to further advance electronic PO 00000 Frm 00076 Fmt 4701 Sfmt 4700 exchange of information that supports safe, effective transitions of care between hospitals and community providers. Specifically, we requested comment on revisions to the current CMS CoPs for hospitals such as: Requiring that hospitals transferring medically necessary information to another facility upon a patient transfer or discharge do so electronically; requiring that hospitals electronically send required discharge information to a community provider via electronic means if possible and if a community provider can be identified; and requiring that hospitals make certain information available to patients or a specified third-party application (for example, required discharge instructions) via electronic means if requested. The RFI discussed several steps we have taken in recent years to update and modernize the CoPs and other health and safety standards to reflect current best practices for clinical care, especially in the area of care coordination and discharge planning. For a complete discussion of this work, see the proposed rule (84 FR 7649 through 7650). In the September 30, 2019 Federal Register, we published a final rule, ‘‘Medicare and Medicaid Programs; Revisions to Requirements for Discharge Planning’’ (84 FR 51836) (‘‘Discharge Planning final rule’’), that revises the discharge planning requirements that hospitals (including psychiatric hospitals, long-term care hospitals, and inpatient rehabilitation facilities), critical access hospitals (CAHs), and home health agencies, must meet to participate in Medicare and Medicaid programs. The rule supports CMS’ interoperability efforts by promoting the exchange of patient information between health care settings, and by ensuring that a patient’s necessary medical information is transferred with the patient after discharge from a hospital, CAH, or post-acute care services provider. By requiring that all of the patient’s necessary medical information, including his or her postdischarge goals of care and treatment preferences, must be documented in the patient’s medical record and transferred along with the patient at the time of discharge to an appropriate receiving health care facility, such as a PAC service provider or agency, and to other outpatient service providers and practitioners responsible for the patient’s follow-up or ancillary care, the rule aims to better prepare patients and their caregivers to be active partners and advocates for their health care and community support needs upon E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations discharge from the hospital or postacute care setting. While we finalized a broad requirement for sending necessary medical information in accordance with all applicable laws, rather than listing specific data elements (such as those explicitly aligned with the data referenced as part of the Common Clinical Data Set (CCDS) that was finalized in the 2015 final rule, ‘‘Medicare and Medicaid Programs; Electronic Health Record Incentive Program—Stage 3 and Modifications to Meaningful Use in 2015 Through 2017’’ (80 FR 62762), we also ensured that the revisions to the CoPs did not conflict with the CCDS, or future standards proposed for adoption for electronic exchange of health information, specifically the USCDI. The discharge planning CoPs do not bar providers from sending all additional appropriate medical information regarding the patient’s current course of illness and treatment, post-discharge goals of care, and treatment preferences in accordance with applicable laws. However, we note here that the Discharge Planning final rule does not require hospitals, CAHs, and HHAs to transfer the necessary patient medical information exclusively by electronic means nor does it require that providers notify the appropriate providers, suppliers, and practitioners receiving the necessary medical information of the patient’s discharge as we are now requiring in this final rule. Additionally, the Discharge Planning final rule further supports interoperability and a patient’s access to his or her own medical records by updating the hospital Patient Rights CoP to now state that the patient has the right to access his or her medical records in the form and format requested (including in an electronic form or format when such medical records are maintained electronically). Therefore, the hospital CoPs now include an explicit requirement that, as a condition of participation, hospitals must provide patients with access to their medical records in an electronic format upon the patient’s request if the hospital has the capacity to do so. In response to the RFI in the FY 2019 IPPS proposed rule, many stakeholders supported our goals of increasing interoperability, and acknowledged the important role that hospital settings play in supporting care coordination. Stakeholders agreed that use of electronic technology was an important factor in ensuring safe transitions. Multiple stakeholders emphasized that electronic data exchange between hospitals and physician offices, as well as with hospices, HHAs, SNFs, and VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 other post-acute care services providers, was especially important during care transitions when maintaining access to patient health information, including medication information, and is extremely relevant to the patient’s next phase of care. Additionally, stakeholders noted that giving patients and their caregivers access to important health information (such as discharge information along with accurately reconciled lists of discharge medications) created a more patientcentered health care system, and reduced the risk of errors and hospital readmissions. But many stakeholders also expressed concerns about implementing policy changes within the CoPs that might increase the compliance burden on hospitals. However, several stakeholders also strongly recommended that CMS add details to the CoPs, and require that hospitals share not only medically necessary information with physician offices, HHAs, and SNFs (such as pending tests and discharge summaries), but also notifications of when patients were admitted to the hospital as well as discharged or transferred from the hospital and admitted to the care of applicable PAC services providers and suppliers. Given responses to the RFI, as well as previous rulemaking activities, we sought to further expand CMS requirements for interoperability within the hospital and CAH CoPs as part of the CMS Interoperability and Patient Access proposed rule by focusing on electronic patient event notifications. In addition, we noted that we were committed to taking further steps to ensure that facilities that are electronically capturing information are electronically exchanging that information with providers who have the capacity to accept it. Infrastructure supporting the exchange of electronic health information across settings has matured substantially in recent years. Research studies have increasingly found that health information exchange interventions can affect positive outcomes in health care quality and public health, in addition to more longstanding findings around reductions in utilization and costs. A recent review of how health information exchange interventions can improve cost and quality outcomes identified a growing body of high-quality studies showing that these interventions are associated with beneficial results.53 The 53 Menachemi, N., Rahurkar, S., Harle, C.A., & Vest, J.R. (2018). The benefits of health information exchange: An updated systematic review. Journal of PO 00000 Frm 00077 Fmt 4701 Sfmt 4700 25585 authors identified a number of studies demonstrating positive effects on outcomes associated with better care coordination, such as reductions in 30day readmissions,54 55 56 and improved medication reconciliation.57 Electronic patient event notifications from hospitals, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings, especially for patients at discharge. This approach has been associated with a reduction in readmissions following implementation of such notifications.58 We noted that the evidence cited in this section to support the use of innovative health information exchange interventions and approaches, such as the patient event notifications that we proposed to require, can be applied to various types of hospitals, including psychiatric hospitals, as well as to CAHs, as discussed below. Patient event notifications are automated, electronic communications from the discharging provider to another facility, or to another applicable community provider as identified by the patient (such as a patient’s primary care practitioner or practice group, postacute care services providers and suppliers, and other practitioners and providers that need the notification for post-acute care coordination, treatment, and/or quality improvement purposes), the American Medical Informatics Association, 25(9), 1259–1265. doi: 10.1093/jamia/ocy035. 54 Yeaman, B., Ko, K., del Castillo, R. (2015). Care transitions in long-term care and acute care: Health information exchange and readmission rates. The Online Journal of Issues in Nursing, 20(3). doi: 10.3912/OJIN.Vol20No03Man05. 55 Vest, J.R., Kern, L.M., Silver, M.D., & Kaushal, R. (2015). The potential for community-based health information exchange systems to reduce hospital readmissions. Journal of the American Medical Informatics Association, 22(2), 435–442. doi: 10.1136/amiajnl-2014–002760. 56 Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest, J.R. (2017). Hospitalization event notifications and reductions in readmissions of Medicare fee-forservice beneficiaries in the Bronx, New York. Journal of the American Medical Informatics Association, 24(e1), e150–e156. doi: 10.1093/jamia/ ocw139. 57 Boockvar, K.S., Ho, W., Pruskowski, J., Dipalo, K.E., Wong, J.J., Patel, J., . . . Hung, W. (2017). Effect of health information exchange on recognition of medication discrepancies is interrupted when data charges are introduced: Results of a cluster-randomized controlled trial. Journal of the American Medical Informatics Association, 24(6), 1095–1101. doi: 10.1093/jamia/ ocx044. 58 Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest, J.R. (2017). Hospitalization event notifications and reductions in readmissions of Medicare fee-forservice beneficiaries in the Bronx, New York. Journal of the American Medical Informatics Association, 24(e1), e150–e156. doi: 10.1093/jamia/ ocw139. E:\FR\FM\01MYR2.SGM 01MYR2 25586 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations which alerts the receiving provider that the patient has received care at a different setting. Depending on the implementation, information included with these notifications can range from conveying the patient’s name, other basic demographic information, and the sending institution to a richer set of clinical data on the patient. Even with a minimum set of information included, these notifications can help ensure that a receiving provider, facility, or practitioner is aware that the patient has received care elsewhere. The notification triggers a receiving provider, facility, or practitioner to reach out to the patient and deliver appropriate follow-up care in a timely manner. By notifying the individuals and entities that need notification of the patient’s status for treatment, care coordination, or quality improvement purposes, the notification can help to improve post-discharge transitions and reduce the likelihood that a patient would face complications from inadequate follow-up care. In addition to their effectiveness in supporting care coordination, virtually all EHR systems generate the basic messages commonly used to support electronic patient event notifications. These notifications are based on admission, discharge, and transfer (ADT) messages, a standard message used within an EHR as the vehicle for communicating information about key changes in a patient’s status as they are tracked by the system (more information about the current standard supporting these messages is available at https:// www.hl7.org/implement/standards/ product_brief.cfm?product_id=144). As noted in the Interoperability Standards Advisory (ISA) published by ONC, this messaging standard has been widely adopted across the health care system (see https://www.healthit.gov/isa/ sending-a-notification-a-patientsadmission-discharge-andor-transferstatus-other-providers). ADT messages provide each patient’s personal or demographic information (such as the patient’s name, insurance, next of kin, and attending physician), when that information has been updated, and also indicate when an ADT status has changed. To create an electronic patient event notification, a system can use the change in ADT status to trigger a message to a receiving provider or to a health information exchange system that can then route the message to the appropriate provider. In addition to the basic demographic information contained in the ADT message, some patient event notification implementations attach more detailed information to the message regarding VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 the patient’s clinical status and care received from the sending provider. B. Provisions for Hospitals (42 CFR 482.24(d)) We proposed to revise the CoPs for Medicare- and Medicaid-participating hospitals at 42 CFR 482.24 by adding a new standard at paragraph (d), ‘‘Electronic Notifications,’’ that would require hospitals to send electronic patient event notifications of a patient’s admission, discharge, and/or transfer to another health care facility or to another community provider or practitioner. We proposed to require hospitals to convey, at a minimum, the patient’s basic personal or demographic information, as well as the name of the sending institution (that is, the hospital), and, if not prohibited by other applicable law, the patient’s diagnosis. In proposing that patient event notifications sent by a hospital’s medical records system include diagnosis, where not prohibited by other applicable law, we requested comment on the technical feasibility of this proposal, noting that we recognize some existing ADT messages might not include diagnosis, as well as the challenges in appropriately segmenting this information in instances where the diagnosis may not be permitted for disclosure under other applicable laws. We also encouraged hospitals, as their systems and those of the receiving providers allowed, to work with patients and their practitioners to offer more robust patient information and clinical data upon request in accordance with applicable law. For a hospital that currently possesses an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event notifications, we proposed that compliance with the proposed standard within the Medical records services CoP (42 CFR 482.24) would be determined by the hospital demonstrating to the surveyor or accrediting organization that its system: (1) Is fully operational and that it operates in accordance with all state and federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i); (3) sends notifications that would have to include the minimum patient health information (which, as noted above, would be the patient’s name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at PO 00000 Frm 00078 Fmt 4701 Sfmt 4700 the time of the patient’s admission to the hospital and either immediately prior to or at the time of the patient’s discharge and/or transfer from the hospital. We proposed to limit this requirement to only those hospitals which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications as discussed below, recognizing that not all Medicare- and Medicaidparticipating hospitals have been eligible for past programs promoting adoption of EHR systems. We noted our goal in proposing the requirement was to ensure that hospital EHR systems have a basic capacity to generate messages that can be utilized for notifications by a wide range of receiving providers, enabled by common standards. We believed that a system that utilizes the ADT messaging standard, which is widely used as the basis for implementing these notifications and other similar use cases, would meet this goal by supporting the availability of information that can be used to generate information for patient event notifications. Specifically, we proposed that the system utilize the ADT messaging standard incorporated by reference at 45 CFR 170.205(a)(4)(i).59 We noted that, while there are no criteria under the ONC Health IT Certification Program which certifies health IT to create and send electronic patient event notifications, the ADT standard is referenced by other certification criteria under the program. Specifically, this standard supports certification criteria related to transferring information to immunization registries, as well as transmission of laboratory results to public health agencies as described at 45 CFR 170.315(f) under the 2015 Edition certification criteria, and at 45 CFR 170.314(f) under the 2014 Edition. Thus, we expect systems that include Health IT Modules certified to meet criteria which reference this standard will possess the basic capacity to generate information for notification messages. We further noted that adopting certified health IT that meets these criteria has been required for any hospital seeking to qualify for the Promoting Interoperability Programs (formerly the EHR Incentive Programs). We recognized that there is currently significant variation in how hospitals have utilized the ADT messages to 59 Health Level Seven Messaging Standard Version 2.5.1 (HL7 2.5.1), an Application Protocol for Electronic Data Exchange in Healthcare Environments, February 21, 2007. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations support implementation of patient event notifications. We also recognized that many hospitals, which have already implemented notifications, may be delivering additional information beyond the basic information included in the ADT message (both automatically when a patient’s status changes and then upon request from receiving providers) to receiving practitioners, patient care team members, and postacute care services providers and suppliers with whom they have established patient care relationships and agreements for patient health information exchange as allowed by law. We believe consensus standards for ADT-based notifications may become more widely adopted in the future (we refer readers to ONC’s ISA 60 for more information about standards under consideration). However, at this time, we stated that we did not wish to restrict hospitals from pursuing more advanced content as part of patient notifications, nor to create redundant requirements where hospitals already have a suitable notification system in place. Accordingly, while we specified that hospitals subject to the proposal possess a system utilizing this standard, we proposed that hospitals could utilize other standards or features to support their notification systems. We requested comment on the proposal, including whether this requirement would achieve the goal of setting a baseline for hospitals’ capacity to generate information for electronic notifications, while still allowing for innovative approaches that would potentially increase the effectiveness of these notifications toward improving patient outcomes and safety during transitions in care. We further proposed that the hospital would need to demonstrate that the system’s notification capacity was fully operational, that it operated in accordance with all state and federal statutes and regulations regarding the exchange of patient health information. We intended for these notifications to be required, at minimum, for inpatients admitted to, and discharged and/or transferred from the hospital. However, we also noted that patient event notifications are an effective tool for coordinating care across a wider set of patients that may be cared for by a hospital. For instance, a patient event notification could ensure that a primary care physician was aware that his or her patient had received care at the 60 Office of the National Coordinator. (n.d.). Admission, Discharge, and Transfer. Retrieved from https://www.healthit.gov/isa/admission-dischargeand-transfer. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 emergency room, and initiate outreach to the patient to ensure that appropriate follow-up for the emergency visit was pursued. While we encouraged hospitals to extend the coverage of their notification systems to serve additional patients, outside of those admitted and seen as inpatients, we also sought comment on whether we should identify a broader set of patients to whom this requirement would apply, and if so, how we should implement such a requirement in a way that minimizes administrative burden on hospitals. Additionally, we proposed that the hospital would have to demonstrate that its system sends notifications that include the minimum patient health information (specifically, patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis). We proposed that the hospital would also need to demonstrate that the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of the patient’s hospital admission, discharge, or transfer, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) the hospital has reasonable certainty that such notifications are received. We noted that we believed the proposal would allow for a diverse set of strategies that hospitals might use when implementing patient event notifications. Through these provisions, we sought to allow for different ways that a hospital might identify those practitioners, other patient care team members, and PAC services providers and suppliers that are most relevant to both the pre-admission and postdischarge care of a patient. We proposed that hospitals send notifications to those practitioners or providers that had an established care relationship with the patient relevant to his or her care. We recognized that hospitals and their partners may identify appropriate recipients through various methods. For instance, hospitals might identify appropriate practitioners by requesting this information from patients or caregivers upon arrival, or by obtaining information about care team members from the patient’s record. We expected hospitals might develop or optimize processes to capture information about established care relationships directly, PO 00000 Frm 00079 Fmt 4701 Sfmt 4700 25587 or work with an intermediary that maintains information about care relationships. In other cases, we noted that hospitals may, directly or through an intermediary, identify appropriate notification recipients through the analysis of care patterns or other attribution methods that seek to determine the provider most likely to be able to effectively coordinate care postdischarge for a specific patient. The hospital or intermediary might also develop processes to allow a provider to specifically request notifications for a given patient for whom they are responsible for care coordination as confirmed through conversations with the patient. Additionally, we expected hospitals, psychiatric hospitals, and CAHs to comply with the HIPAA Rules set out at 45 CFR parts 160 and 164 if these proposed CoP requirements for patient event notifications were finalized. As required at 42 CFR 482.11 for hospitals and psychiatric hospitals and at 42 CFR 485.608 for CAHs, these providers must comply with all pertinent currently existing federal laws, including the HIPAA Privacy and Security Rules. The Privacy Rule permits patient event notifications as disclosures for treatment purposes (the proposed required notifications, when finalized, also may be treated as disclosures required by law (see 45 CFR 164.502(a)). We also recognized that factors outside of the hospital’s control might determine whether or not a notification was successfully received and utilized by a practitioner. Accordingly, we proposed that a hospital would only need to send notifications to those practitioners for whom the hospital has reasonable certainty of receipt. While we stated that we expected hospitals would, to the best of their ability, seek to ensure that notification recipients were able to receive notifications (for instance, by obtaining a recipient’s Direct address 61), we understood that technical issues beyond the hospital’s control could prevent successful receipt and use of a notification. Finally, we noted that hospitals have an existing responsibility under the CoPs at 42 CFR 482.43(d) to ‘‘transfer or refer patients, along with necessary medical information, to appropriate facilities, agencies, or outpatient services, as needed, for follow-up or ancillary care.’’ We emphasized that the proposal regarding patient event notifications would be separate from the 61 For more information about obtaining a Direct addresses, see https://www.healthit.gov/sites/ default/files/directbasicsforprovidersqa_ 05092014.pdf. E:\FR\FM\01MYR2.SGM 01MYR2 25588 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations requirement regarding necessary medical information at 42 CFR 482.43(d). However, we recognized that processes to implement the proposal, if finalized, could intersect with the hospital’s discharge planning process. We noted that nothing in the proposal would affect the hospital’s responsibilities under 42 CFR 482.43(d). However, we noted if the proposal was finalized, hospitals might wish to consider ways to fulfill these requirements in ways that reduce redundancy while still remaining compliant with existing requirements. For instance, where appropriate and allowed by law, hospitals might seek to include required necessary medical information within the same message as a patient event notification. C. Provisions for Psychiatric Hospitals (42 CFR 482.61(f)) Medicare- and Medicaid-participating psychiatric hospitals must comply with all of the hospital CoPs at 42 CFR 482.1 through 482.23 and at 42 CFR 482.25 through 482.57. They also must adhere to special provisions regarding medical records at 42 CFR 482.61 and staffing requirements at 42 CFR 482.62. Since the medical records requirements are different for psychiatric hospitals, and since these hospitals do not have to comply with the regulations at 42 CFR 482.24, we proposed a new electronic notification standard at 42 CFR 482.61(f) within the special provisions for psychiatric hospitals in this section. Similar to the proposal for hospitals at 42 CFR 482.24(d), we proposed a new standard at 42 CFR 482.61(f), ‘‘Electronic Notifications,’’ that would require psychiatric hospitals to send electronic patient event notifications of a patient’s admission, discharge, and/or transfer to another health care facility or to another community provider. As we proposed for hospitals, we proposed to limit this requirement to only those psychiatric hospitals which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications, defined as systems that utilize the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i). We proposed that that for a psychiatric hospital that currently possessed an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event (ADT) notifications, compliance with the proposed standard within the Special medical records requirements for psychiatric hospitals CoP (42 CFR 482.61) would be determined by the hospital demonstrating that its system: VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 (1) Is fully operational and that it operated in accordance with all state and federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i); (3) sends notifications that would have to include the minimum patient health information (specifically, patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient’s admission to the hospital and either immediately prior to or at the time of the patient’s discharge and/or transfer from the hospital. We requested comment on the policy as part of this hospital proposal in section X.B. of the CMS Interoperability and Patient Access proposed rule (84 FR 7650 through 7652). We also proposed that the hospital would need to demonstrate that the system sends notifications directly, or through an intermediary that facilitates exchange of health information, and either immediately prior to or at the time of the patient’s hospital admission, discharge, or transfer, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) the hospital is reasonably certain will receive such notifications. We referred readers to the extended discussion of the proposals in sections X.A. and B. of the CMS Interoperability and Patient Access proposed rule (84 FR 7649 through 7652). We sought comment on these proposals. D. Provisions for CAHs (42 CFR 485.638(d)) We believe implementation of patient event notifications are also important for CAHs to support improved care coordination from these facilities to other providers in their communities. Therefore, similar to the proposals for the hospital and psychiatric hospital medical records requirements as discussed in the preceding sections, we proposed to revise 42 CFR 485.638, by adding a new standard to the CAH Clinical records CoP at paragraph (d), ‘‘Electronic Notifications.’’ As discussed, the proposed standard would require CAHs to send electronic patient event notifications of a patient’s PO 00000 Frm 00080 Fmt 4701 Sfmt 4700 admission, discharge, and/or transfer to another health care facility or to another community provider. We proposed to limit this requirement to only those CAHs which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications, defined as systems that utilize the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i). We proposed that for a CAH that currently possessed an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event (ADT) notifications, compliance with the proposed standard within the Clinical records services CoP (42 CFR 485.638) would be determined by the CAH demonstrating that its system: (1) Is fully operational and that it operates in accordance with all state and federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i); (3) sends notifications that would have to include the minimum patient health information (specifically, patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient’s admission to the CAH and either immediately prior to or at the time of the patient’s discharge and/or transfer from the CAH. We requested comment on the policy as part of the hospital proposal in section X.B. of the CMS Interoperability and Patient Access proposed rule (84 FR 7650 through 7652). Additionally, we proposed that the CAH would need to demonstrate that the system sends notifications directly, or through an intermediary that facilitated exchange of health information, and at or immediately prior to the time of the patient’s CAH admission, discharge, or transfer, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) the CAH is reasonably certain will receive such notifications. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations E. Comments and Responses on the Provisions of the Proposed Rule; Final Actions and Provisions of the Final Rule for Hospitals (42 CFR 482.24(d)), Psychiatric Hospitals (42 CFR 482.61(f)); and CAHs (42 CFR 485.638(d)) We requested comments on the proposals including stakeholder feedback about how the proposals should be operationalized. Additionally, we sought comment on how CMS should implement these proposals as part of survey and certification guidance in a manner that minimizes compliance burden on hospitals, psychiatric hospitals, and CAHs while ensuring adherence with the standards. We also sought stakeholder input about a reasonable timeframe for implementation of these proposals for hospitals, psychiatric hospitals, and CAHs, respectively. We received more than 600 public comments on this section that were specific to the patient event notification requirements proposed for inclusion in the CoPs, but which generally did not distinguish among the requirements individually proposed for hospitals, psychiatric hospitals, and CAHs at 42 CFR 482.24(d), 482.61(f), and 485.638(d), respectively. We summarize the public comments we received on our proposals related to the Conditions of Participation and provide our responses in this section. This summary of the public comments and our responses apply equally to all three provider types included under this proposed requirement and the specific provisions proposed for each unless otherwise noted. We provide the final actions and the provisions of the final rule at the end of this section. Comment: Many commenters supported the proposals to require hospitals (including psychiatric hospitals) and CAHs to send electronic patient event notifications of a patient’s admission, discharge, and/or transfer to another health care facility or to another community provider. Commenters stated that they believed implementing patient event notifications would be a highly effective tool to improve care transitions for patients moving between a hospital and other settings, including returning home. Commenters believed that increasing the sharing of patient event notifications at admission and discharge can lead to improved outcomes, higher quality, and lower cost care. Commenters also pointed to many instances in which these notifications are being utilized today, stating that they believe that patient event notifications had effectively contributed to improved care coordination. For VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 instance, one commenter pointed to the statewide requirement for hospitals in Maryland to transmit notifications, noting that this has been an important policy supporting care coordination in the state. Several commenters noted that the availability of notification information is especially important for the success of value-based payment models, such as ACO initiatives, where participants may be financially at risk for costs associated with poor care transitions. Response: We appreciate commenters’ support for the proposal and are finalizing our proposal with modifications as discussed below. Comment: While many commenters agreed that patient event notifications are an important way to improve care coordination, some disagreed that the CoPs were the appropriate vehicle for advancing their use. Many commenters stated that by placing the patient event notification requirements in the CoPs, CMS is putting hospitals’ participation in Medicare at risk, which they stated would be an excessive penalty for failure to implement patient event notifications in accordance with the proposed requirements. Commenters also stated that the survey and certification process was not well-suited to determining compliance with the proposed CoP ‘‘Electronic notifications’’ standard. These commenters questioned how surveyors would assess compliance with the requirements, including one commenter who questioned how a hospital would demonstrate that its system sent notifications that improve the coordination of care, and not just show that its system is merely functioning as required. They further stated that a survey team would need clear guidance on how to assess providers for compliance to ensure that hospitals are transmitting patient information to, and receiving it from, other providers. Additionally, one commenter stated that hospital accreditation programs are not the appropriate entities to assess compliance, due to the technical nature of the requirements. Commenters also expressed concern that tying these requirements to the CoPs could lead to hospitals sending more information than is necessary to ensure compliance, further increasing excessive information received by providers. Response: We appreciate the commenters’ concerns regarding use of the CoPs to advance the use of patient notifications; however, we disagree that the CoPs are an inappropriate vehicle for this purpose. We believe that the capability to send patient event PO 00000 Frm 00081 Fmt 4701 Sfmt 4700 25589 notifications should be a fundamental feature of hospital medical record systems to support effective care transitions and promote patient safety during transitions. This belief is consistent with the statutory authority for establishing and appropriately updating the CoPs as that authority is contained in section 1861(e) of the Act, which defines institutions that meet the definition of a hospital for Medicare purposes. Specifically, section 1861(e)(2) of the Act requires that a hospital ‘‘maintains clinical records on all patients,’’ and section 1861(e)(9) of the Act requires that a hospital ‘‘meets such other requirements as the Secretary finds necessary in the interest of the health and safety of individuals who are furnished services in the institution.’’ As discussed in the proposed rule (84 FR 7650), we believe patient event notifications can help to improve care coordination for patients discharged from the hospital and reduce the incidence of events such as hospital readmissions that could have been avoided through more timely follow-up care. Further, including a CoP requirement for patient event notifications at the time of a patient’s discharge or transfer as we have proposed and are finalizing in this rule is also consistent with section 1861(ee)(2) of the Act, which states that the Secretary shall develop guidelines and standards for the discharge planning process in order to ensure a timely and smooth transition to the most appropriate type of and setting for post-hospital or rehabilitative care. We believe patient event notifications are an effective tool for ensuring that the settings responsible for follow-up care are made aware that their patients have been discharged in an expeditious manner. We believe that these notifications can be utilized to more effectively trigger care coordination activities that promote timely transitions. We have chosen to include these requirements in the CoPs for medical records services, and not those for discharge planning, because we believe that the medical records CoPs provide a more global approach to the notifications than do the discharge planning CoPs, especially since we are requiring notifications for inpatient admissions as well as ED and outpatient observation admissions or registrations in addition to patient discharges and transfers. Therefore, given this statutory authority, we maintain that the CoPs are an appropriate vehicle for advancing the use of patient event notifications. We also disagree that the CoPs are an inappropriate vehicle for this policy due to what the commenters’ characterize as E:\FR\FM\01MYR2.SGM 01MYR2 25590 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations the disproportionate penalties associated with noncompliance with this CoP. We note that while the CoPs are a significant regulatory mechanism, noncompliance with one subordinate standard under one CoP must be considered relative to a hospital’s compliance or noncompliance with the many other CoPs and standards as well as the severity of the noncompliance and the risk it poses to patient health and safety. Under the heading, ‘‘Determining the Severity of Deficiencies,’’ the State Operations Manual (SOM), Appendix A—Survey Protocol, Regulations and Interpretive Guidelines for Hospitals cites the regulations at 42 CFR 488.26 (‘‘The decision as to whether there is compliance with a particular requirement, condition of participation, or condition for coverage, depends upon the manner and degree to which the provider or supplier satisfies the various standards within each condition.’’) as the basis for determining the various levels of noncompliance with the CoPs during a survey (https://www.cms.gov/ Regulations-andGuidance/Guidance/ Manuals/downloads/som107ap_a_ hospitals.pdf; p.19). From page 19 of the SOM, Appendix A: ‘‘When noncompliance with a condition of participation is noted, the determination of whether a lack of compliance is at the Standard or Condition level depends upon the nature (how severe, how dangerous, how critical, etc.) and extent (how prevalent, how many, how pervasive, how often, etc.) of the lack of compliance. The cited level of the noncompliance is determined by the interrelationship between the nature and extent of the noncompliance. ‘‘A deficiency at the Condition level may be due to noncompliance with requirements in a single standard or several standards within the condition, or with requirements of noncompliance with a single part (tag) representing a severe or critical health or safety breach. Even a seemingly small breach in critical actions or at critical times can kill or severely injure a patient, and represents a critical or severe health or safety threat. ‘‘A deficiency is at the Standard level when there is noncompliance with any single requirement or several requirements within a particular standard that are not of such character as to substantially limit a facility’s capacity to furnish adequate care, or which would not jeopardize or adversely affect the health or safety of patients if the deficient practice recurred.’’ VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Regarding the comments questioning how surveyors, either state surveyors or those from one of the hospital accreditation programs, would determine compliance with the notification requirements, we will issue, as we do with all new or revised CoP requirements, new interpretive guidelines, which include survey procedures, for the State Operations Manual, following finalization of this rule and prior to the rule’s effective date. We will advise and train state surveyors on the new requirements as is the normal procedure when new and/or revised CoPs and standards are finalized. For example, the current Medical Record Services CoP requirements, contained at 42 CFR 482.24, and in which we are finalizing these new patient event notification requirements, primarily contain provisions for administrative systems or processes where the hospital is responsible for demonstrating that the various components of its medical records system or process are in place and operational in order to comply with the overall requirements of the CoP. Surveyors would then approach these new requirements in a similar fashion and apply similar survey procedures and methods that do not require surveyors to have deep technical knowledge of various systems in order to determine compliance. As with the survey of the hospital’s total medical records system, surveyors would utilize basic and effective survey procedures and methods such as: • Review of the organizational structure and policy statements and an interview with the person responsible for the medical records service to first ascertain that the hospital has a system that meets the initial requirements for patient event notifications in order to determine whether or not the hospital is exempt from the specific patient event notification requirements that follow. • Review of a sample of active and closed medical records for completeness and accuracy, including any patient event notifications, in accordance with federal and state laws and regulations and hospital policy. • Interview of medical records and other hospital staff, including physicians and other practitioners, to determine understanding of the patient events notification function of the system. • Conducting observations and interviews with medical records staff and leadership to determine if requirements for patient event notifications are being met. CMS-approved accreditation organizations (AOs) with hospital PO 00000 Frm 00082 Fmt 4701 Sfmt 4700 programs are required, at a minimum, to enforce standards that meet or exceed hospital CoP requirements, so each AO will be responsible for training its survey and accreditation staff on the patient event notification requirements finalized in this rule ahead of the applicable date established by CMS. Finally, the patient event notification requirements that we are finalizing require a hospital to send only a minimal amount of patient information in order to be in compliance with the provisions. These requirements are consistent with our belief that existing patient event notification systems have demonstrated that a minimal set of information can achieve the desired effect of improving care coordination while imposing minimal burden on providers. However, hospitals are not prohibited from sending more detailed information under these requirements and we would expect each hospital is fully aware of its own capacity to send additional patient information, other applicable laws governing this, and the capacities of the intended recipients to receive additional patient information, and would base its decisions to send additional information on these factors as well as on what is best for the patient. Based on our experience with hospitals, we disagree with the commenter that a hospital would unnecessarily send ‘‘excessive’’ amounts of patient information in an attempt to ensure a determination that the hospital was in compliance. To prevent such confusion, we have clearly delineated the patient information requirements in this final rule. Comment: Many commenters stated that the CoPs were not appropriate for advancing goals related to interoperability and the use of health IT. Commenters stated that CMS currently regulates provider use of technology through a variety of other avenues, such as the Promoting Interoperability Programs, and that adding the proposed requirements under the CoPs would add an unnecessary additional mechanism for addressing these issues. Commenters believed this could lead to additional provider burden and confusion, as stakeholders would be required to navigate duplicative requirements around the electronic exchange of information. Several commenters stated that, by shifting focus to compliance with the proposed requirements, and requiring hospitals to engage in duplicative reporting on information exchange, this proposal could divert funding and attention from necessary investments in interoperable health information exchange. Commenters stated that they believed using the CoPs E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations in this fashion was inconsistent with congressional intent for how HHS should regulate the use of health IT. Commenters also noted that HHS is currently seeking to establish a range of new policies designed to advance the interoperable exchange of health information. Commenters believed these policies could have a significant impact on the sharing of health information, including the sharing of patient event notifications, and that CMS should refrain from rulemaking through the CoPs until these polices have been finalized. One commenter also noted that, at the time the comment period on the CMS Interoperability and Patient Access proposed rule closed, CMS’ Discharge Planning rule (80 FR 68125) had not yet been finalized, and that it would be premature to add this requirement in advance of finalizing related revisions to the discharge planning section of the CoPs. Commenters further stated that HHS has a variety of other mechanisms for advancing electronic information exchange and improving the infrastructure for exchange that would be more effective than adding requirements to the CoPs. Several commenters expressed concern that using the CoPs would set static requirements that are ill-suited to an evolving technology environment and the innovation needed to increase adoption of notifications across providers. Response: We appreciate commenters’ input. As noted above, we disagree with commenters who stated that the CoPs are not an appropriate mechanism for policy related to interoperability or the use of health IT. Existing CoPs address requirements related to medical records systems as well as the transfer of health information, and we believe there is no reason that these regulations should not address technology issues where the use of technology may be relevant to patient health and safety, provided that such references to technology in the CoPs do not lead to ‘‘static requirements’’ as noted by the commenter, and which we believe we have avoided doing in both the proposed and final rules. Furthermore, while a 2017 review of the current available scientific evidence on the impact of different health information technologies on improving patient safety outcomes, warned that health care organizations ‘‘need to be selective in which technology to invest in, as literature shows that some technologies have limited evidence in improving patient safety outcomes,’’ the review also stated that there ‘‘should be no doubt that health information technology is an important tool for VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 improving healthcare quality and safety.’’ 62 According to the authors of the review, evidence from a number of studies shows that health IT offers numerous opportunities for improving and transforming health care that includes the potential to reduce human errors, improve clinical outcomes, facilitate care coordination, improve practice efficiencies, and track data over time. Based on this evidence as well as the evidence directly related to patient event notifications that we cited previously, we believe that the requirements for patient event notifications that we have proposed and that we are finalizing in this rule will have a positive impact on many of these same areas, especially regarding the facilitation of care coordination for patients, leading to improved outcomes and enhanced patient health and safety. While we appreciate the importance of aligning policies across different programs to minimize provider burden, we believe that the proposed requirements are not addressed elsewhere and are appropriate for inclusion in the CoPs. Additionally, we disagree with commenters who stated that the proposed requirements will require hospitals to engage in duplicative reporting on information exchange since the proposed requirements do not require hospitals and CAHs to do any type of reporting to CMS in order to comply with the requirements. We also understand that other proposed or recently finalized policies may be relevant to the proposed requirements in this rule; however, we believe these policies will complement one another and serve to enable the proposed requirements around patient event notifications. As we noted above regarding the final rule published on September 30, 2019, Discharge Planning final rule (84 FR 51836), the revised discharge planning CoPs do not require hospitals, CAHs, and HHAs to transfer necessary patient medical information exclusively by electronic means, nor do they require that providers notify the appropriate providers, suppliers, and practitioners receiving the necessary medical information of the patient’s discharge (or admission) as we are now are requiring in this final rule. We believe that the two rules, as written and finalized, do not conflict, but instead complement and support each other in CMS’ goal of improving patient care transitions. Therefore, we disagree with the comments stating that the 62 Alotaibi, Y., & Federico, F. (2017). The impact of health information technology on patient safety. Saudi Medical Journal, 38(12), 1173–1180. doi: 10.15537/smj.2017.12.20631. PO 00000 Frm 00083 Fmt 4701 Sfmt 4700 25591 patient event notification requirements are premature or duplicative in relation to the final discharge planning requirements for hospitals, CAHs, and HHAs. Regarding concerns that it will be challenging to update the CoPs to reflect changing technology requirements, our proposal sought to focus primarily on functional requirements that will allow hospitals the flexibility to pursue innovation and adapt their systems over time, similar to other functional requirements under the Medical Records Services CoP. Where we do reference a specific standard, in order to determine whether or not a hospital’s system would be subject to the proposed ‘‘Electronic notifications’’ standard, we reference a content exchange standard at 45 CFR 170.205(d)(2) common to many EHRs that we believe is unlikely to undergo changes that would require frequent updates. Comment: Commenters stated that including these requirements under the CoPs would significantly increase the compliance burden for providers. Commenters believed that the proposed policy was contrary to other recent HHS burden reduction initiatives for providers. Commenters also believed that this proposal would add additional layers of regulation to what is a common practice for many hospitals today, further increasing provider burden. Several commenters stated that CMS had underestimated the burden associated with this proposal. They disagreed that implementing patient event notifications would be largely limited to a one-time cost, and stated that there would be substantial work required prior to implementing the proposal and continuous work around receiving notifications from other providers. Commenters suggested that CMS pursue other initiatives to alleviate costs, such as standardizing the data set for patient event notifications. Stakeholders also urged CMS to ensure that providers have cost-effective choices for required technology solutions, and to not create an environment that encourages overpricing of solutions. Response: We appreciate commenters’ concerns about additional provider burden. While we understand that this new requirement may impose some additional implementation burden on hospitals, commenters also expressed that there are many ways for hospitals to minimize this burden through the use of existing technologies and services, such as health information exchanges and other service providers which capture notification information from a hospital’s EHR and route it to E:\FR\FM\01MYR2.SGM 01MYR2 25592 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations appropriate recipients. We believe that there is sufficient flexibility in the current proposal to ensure hospitals have a broad range of options for implementation and will be able to comply in a way that aligns with their existing capabilities. We believe that care coordination can have a significant positive impact on the quality of life, consumer experience, and health outcomes for patients. However, we acknowledge that though such activities can have positive impact, they will likely generate some costs. We believe it is difficult to quantify the impact of these changes because EHR implementation across care settings varies in maturity rates, leading to potential variance in cost and impact across such settings. Nonetheless, we have attempted to estimate the burden for those hospitals and CAHs that currently utilize electronic medical records systems or other electronic administrative systems that are conformant with the content exchange standard at 45 CFR 170.205(d)(2), and which generate information to support the basic messages commonly used for electronic patient event notifications, but which are not currently transmitting notifications. The cost of implementing these changes will include a one-time cost related to initial implementation of the notification system. Additionally, we have also estimated recurring maintenance costs for either those hospitals or CAHs that use hospital or CAH IT services staff to perform this recurring maintenance, or for those hospitals and CAHs that contract with third party outside services providers to perform this maintenance. We also stress that the requirements that we are finalizing here do not mandate that a hospital or CAH must purchase and implement a new EHR system. Rather, as finalized here, the provisions require a hospital or a CAH to demonstrate compliance with all of the provisions contained at 42 CFR 482.24(d), 482.61(f), and 485.638(d) only if it utilizes an electronic medical records system or other electronic administrative system that is conformant with the content exchange standard at 45 CFR 170.205(d)(2). We note here then that a hospital or a CAH that does not meet the basic requirements denoted in the standard language at paragraphs 42 CFR 482.24(d), 482.61(f), and 485.638(d) is exempt from demonstrating compliance with the requirements that follow and will not be surveyed for those specific provisions once a surveyor determines that the system used by the hospital or VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 CAH is not conformant with the content exchange standard discussed here. Comment: Many commenters supported the proposal to limit the application of the proposed requirements to hospitals that possess a system capable of generating information for patient event notifications, while several disagreed with CMS and thought that CMS should not limit these requirements to only certain hospitals. Numerous commenters also sought additional information on how CMS will determine whether a hospital’s system is subject to the proposed CoP standard. Commenters stated that the proposed rule did not indicate how surveyors would determine which electronic records systems possess required attributes, and that surveyors would not have the technical expertise required to make this determination. Response: In the CMS Interoperability and Patient Access proposed rule, we proposed to limit this requirement to only those hospitals which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications. We defined a system with this capacity as one that utilizes the ADT messaging standard, Health Level Seven (HL7®) Messaging Standard Version 2.5.1 (HL7 2.5.1)) incorporated by reference at 45 CFR 170.205(a)(4)(i). We noted that this standard is referenced by certification criteria related to transferring information to immunization registries, as well as transmission of laboratory results to public health agencies as described at 45 CFR 170.315(f), and that adoption of certified health IT that meets these criteria has been required for any hospital seeking to qualify for the Promoting Interoperability Program. We believe hospitals and surveyors will be able to determine whether an EHR system possesses the capacity to generate information for electronic patient event notifications, defined for the purposes of the CoP as a system conformant with the specified ADT messaging standard (HL7 2.5.1), based on existing requirements for other programs, such as the Promoting Interoperability Program. In general, we believe that information about whether a system complies with this provision will be easy to obtain from a hospital’s health IT developer. As discussed below, we are finalizing a citation to the ADT messaging standard (HL7 2.5.1) at 45 CFR 170.205(d)(2). Comment: A commenter noted that in some instances a hospital’s patient event notification system is connected to the hospital’s registration system PO 00000 Frm 00084 Fmt 4701 Sfmt 4700 rather than its EHR system, which is used for clinical purposes only. Response: We appreciate the comment and the opportunity to note here that the ‘‘electronic medical records system’’ described in the CoPs is not limited to the EHR system used for the management of clinical data. Hospitals would also be permitted to send patient event notifications using their registration system. Based on this comment, we are revising the language at 42 CFR 482.24(d), 482.61(f), and 485.638(d) in this final rule to now state that if the hospital (or psychiatric hospital or CAH), ‘‘. . . utilizes an electronic medical records system or other electronic administrative system,’’ then the hospital (or psychiatric hospital or CAH) would need to demonstrate that its system complies with the provisions that follow in this section. Comment: In the proposed rule we sought comment on whether we should identify a broader set of patients to whom this requirement would apply, beyond those admitted and treated as inpatients. For instance, we noted that a patient event notification could ensure a primary care physician is aware that their patient has received care at the emergency room, and initiate outreach to the patient to ensure that appropriate follow-up for the emergency visit is pursued (84 FR 7651). Many stakeholders responded to this request for comment by stating that they supported extending this policy to also include patients seen in a hospital’s emergency department (ED). Commenters stated that requiring systems to be able to send these notifications would be an important way to support better care coordination and prevent unnecessary repeat visits to the emergency department. Commenters also suggested that this requirement should include patients seen in the hospital for ‘‘observational’’ stays, but who are not admitted as inpatients. Response: We agree with the commenters that ED patients should be included in the patient event notification system, and have revised the regulatory text at 42 CFR 482.24(3)(i) and (4)(i), 482.61(3)(i) and (4)(i), and 485.638(3)(i) and (4)(i) to include these patients. Many patients registered in the ED are eventually discharged home after being treated, while others are either held for observation in a hospital bed as outpatients or admitted as inpatients to the hospital. The revisions we are finalizing here would require a hospital’s system to send patient event notifications for patients who are registered in the ED, if applicable, and then also for patients admitted as E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations inpatients, regardless if the patient was admitted from the ED, from an observation stay, or as a direct admission from home, from their practitioner’s office, or as a transfer from some other facility. We agree with the commenters and believe that if we were not to include ED patients in the notification requirements in this final rule, we would miss an important opportunity for positively impacting the care transitions and the continuing care of a significant number of patients seen in the nation’s hospital emergency departments. Including ED patients in the patient event notification requirements is consistent with the purpose of the CoPs as a regulatory means of promoting and protecting the overall health and safety of all hospital patients, regardless of their physical location in the hospital. To illustrate when a patient event notification is, and is not, required, we would like to point out the following scenarios. A hospital’s system would be expected to send one notification when a patient is first registered in a hospital’s ED or as an observational stay (that is, in both of these cases, the patient would be considered an outpatient and not an inpatient at this point in time), and a second notification if the same patient was then later admitted to a hospital inpatient services unit (for example, medical unit, labor and delivery unit, telemetry unit, neurology unit, surgical unit, intensive care unit (ICU), etc.), or if the same patient was admitted for inpatient services, but was being boarded in the ED while waiting for an inpatient unit bed. In contrast, a second patient event notification would not be required if an already admitted inpatient was transferred from one inpatient services unit of the hospital to another (for example, if the patient was admitted to the hospital’s ICU, but was then later transferred to the hospital’s ‘‘step-down’’ or ‘‘intermediate care’’ unit or to a medical unit, in which case, the patient continued to remain an inpatient of the hospital), or if an already admitted patient was being boarded in the ED and then was transferred to an inpatient unit when a bed became available. However, while the requirements do not prohibit a hospital from electing to send a patient event notification when a patient is transferred to one inpatient services unit of the hospital to another, the requirements finalized in this rule are based on a change in the patient’s status from outpatient to inpatient, and not necessarily on the physical location of the patient. Finally, in all cases, a patient’s discharge or transfer from the hospital, VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 either from the ED or an observational stay or an inpatient services unit, would still require the hospital to send another and separate patient event notification to the applicable entities as required under this rule. Comment: We proposed that hospitals should send notifications to those practitioners or providers that have an established care relationship with the patient relevant to his or her care (84 FR 7652). Many commenters sought additional information about the term ‘‘established care relationship’’ and how hospitals should discern who has an established care relationship with a patient. Commenters noted that the list of providers who have an ‘‘established care relationship’’ with a patient could be very extensive and requested more information on the extent of the specialization of care team members covered by the requirement. One commenter suggested CMS indicate that the term ‘‘established care relationship’’ only applies to one that is current and directly related to the patient’s diagnosis for which the notification is sent. Another commenter suggested that CMS define ‘‘established care relationship’’ as the principle physician identified by the patient and any institution that the patient identifies. Several commenters suggested that CMS replace the term ‘‘established care relationship’’ with ‘‘active relationship,’’ and noted that this would also ensure payers received the notifications, as their relationship with a patient may not be included under the definition of a ‘‘care’’ relationship. One commenter suggested that CMS note that hospitals have the latitude to choose the recipient of the notification. Commenters also sought direction on how hospitals should approach a situation in which a patient does not have a primary care provider, or in which a provider who has an established care relationship with the patient cannot be easily identified. Several commenters noted that effective notification systems are often organized around a subscription model, in which receiving providers are responsible for identifying those patients for whom they would like to receive notifications. Response: We appreciate commenters’ input. We agree that the term ‘‘established care relationship’’ could be subject to an overly broad interpretation that is not consistent with our goal to set a minimum floor for these requirements under the CoPs. Accordingly, we are finalizing a more limited set of recipients to whom a hospital’s system must send patient event notifications for the purposes of meeting this CoP. We are finalizing at 42 CFR 482.24(d)(5), PO 00000 Frm 00085 Fmt 4701 Sfmt 4700 25593 482.61(f)(5), and 485.638(d)(5) requirements that the hospital’s system send notifications to the following recipients as applicable: The patient’s established primary care practitioner; the patient’s established primary care practice group or entity; or other practitioners or practice groups or entities, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care. We believe that the use of the modifier ‘‘established,’’ as finalized here in the context of a patient’s established primary care practitioner or his or her established primary care practice group or entity, more clearly signifies a care relationship that the patient recognizes as primary or one that is evidenced by documentation of the relationship in the patient’s medical record. As an example, if the patient’s established primary care practitioner refers the patient to the hospital, this primary care practitioner should receive the event notification. We believe this language improves upon the proposed term ‘‘established care relationship,’’ which commenters correctly noted is too vague in meaning, too broad in scope, and too open to various interpretations, all of which could prove burdensome for hospitals to demonstrate compliance with the requirements here. We note that this final policy does not prevent a hospital from sending patient event notifications to other practitioners, in accordance with all applicable laws, who may be relevant to a patient’s postdischarge care and would benefit from receiving patient event notifications, nor would it prevent a hospital from seeking to identify these other practitioners. However, we believe this more limited set of recipients is more appropriate to our goal of setting baseline requirements and will provide hospitals with sufficient specificity to comply with the requirements. In cases where a hospital is not able to identify a primary care practitioner for a patient, the patient has not identified a provider to whom they would like information about their care to be sent, or there is no applicable PAC provider or supplier identified, we would not expect a hospital to send a patient event notification for that patient. We note that under the CoP, a hospital would be required to demonstrate that its system sends notifications to appropriate recipients. We expect that hospitals would demonstrate this capability in variety of ways, for instance, by demonstrating that the hospital has processes and policies in place to identify patients’ primary care practitioners and E:\FR\FM\01MYR2.SGM 01MYR2 25594 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations incorporate this information into the patient event notification system, or through recording information received from patients about their providers. Comment: Commenters stated that obtaining information about providers who have an ‘‘established care relationship’’ with a given patient and maintaining lists of these providers and contact information for delivery of patient event notifications would impose significant burden on hospitals. One commenter noted that patients may not reliably provide information about their providers, and recommended that in those cases the recipient of the patient event notification should identify their relationship with a patient in advance. Several commenters noted that, to the extent hospitals already have operational processes and infrastructure in place to determine destinations for notifications, these processes should be left in place. Several commenters noted that, in order to successfully route messages to the appropriate provider, hospitals would need to be able to overcome challenges associated with patient matching: The ability for a hospital to accurately match records about a patient with the records held by a receiving provider. Commenters stated that challenges with patient matching could inhibit patient event notifications from being received by the correct provider and will lead to frequent pushback from providers about receiving notifications regarding patients they are not affiliated with. Commenters also noted the importance of community-wide directories that map the address of a provider to their electronic endpoint destination, which would allow a hospital to query a directory and find the destination of the patient’s choice. Response: As noted, we are finalizing a more limited minimum set of recipients for patient event notifications than originally proposed. This set of recipients is focused on a patient’s established primary care practitioner (or established primary care practice group or entity) or any other practitioner (or practice group or entity) identified by the patient as primarily responsible for his or her care. However, we are retaining inclusion in this final rule of PAC providers and suppliers as required recipients of notifications as originally proposed. In order to clarify the PAC services providers and suppliers that are required recipients, we are modifying this proposal to refer to ‘‘all applicable PAC services providers and suppliers.’’ For purposes of this policy, applicable PAC services providers and suppliers would be those PAC services providers VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 and suppliers with whom the patient has an established care relationship prior to admission or to whom the patient is being transferred or referred. Similar to our modification to reference the patient’s established primary care practitioner, these PAC services providers and suppliers would be those with an established care relationship immediately preceding the hospital registration or admission (such as a PAC services provider or supplier from which the patient was transferred to the hospital) or those with which a relationship is being established for purposes of treatment and/or care coordination post-discharge from the hospital. The potential recipients of patient event notifications will be limited to only those that need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes. We believe that this final policy will reduce potential operational burden associated with a broader ‘‘established care relationship’’ definition. We believe that increasing numbers of hospitals now commonly seek to identify patients’ primary care practitioners and their contact information, including any digital contact information, or partner with intermediaries that identify primary care practitioners, and that many hospitals will be able to continue to use their existing processes to satisfy the CoP. If a hospital has processes in place for identifying patients’ primary care practitioners and other applicable providers, but is not able to identify an appropriate recipient for a patient event notification for a specific patient, the hospital would not be expected to send a notification for that patient. Research using CMS data on readmission rates in Medicareparticipating hospitals from 2007 to 2015 shows that the readmission rates for targeted conditions (that is, a set of specific diagnoses measured by Medicare) declined from 21.5 percent to 17.8 percent, and rates for non-targeted conditions declined from 15.3 percent to 13.1 percent.63 While this decline in readmissions rates is attributable to multiple factors, we believe that one of the significant factors driving down avoidable patient readmissions is identification by the hospital of the patient’s established primary care practitioner (or practice group) and his or her contact information prior to discharge and/or transfer. Increased and early identification of the patient’s 63 Alper, E., O’Malley, T.A., & Greenwald, J. (n.d.). Hospital discharge and readmission. Retrieved from https://www.uptodate.com/ contents/hospital-discharge-and-readmission. PO 00000 Frm 00086 Fmt 4701 Sfmt 4700 primary care practitioner is more likely to lead to more accurate and timely transfer of patient health information from hospital-based practitioners to community-based primary care practitioners. Additionally, early identification of a patient’s primary care practitioner along with the patient event notification to the practitioner that his or her patient is about to be discharged from the hospital is most likely to have a net positive effect on scheduled postdischarge follow-up rates for patients most at risk for avoidable readmissions. We appreciate commenters concerns about patient matching challenges. This is a larger issue beyond the scope of this CoP proposal and this current rule, but we will consider this issue for future revisions and updates to the CoPs. With the continued increase in the use of electronic data in health care organizations and among providers of health care services, there has been a continued need for patient matching, or patient identity management (PIM) processes, in health care organizations, including hospitals. PIM has been defined as the ability to uniquely ascertain the identity of a patient, assign that patient’s record an identifier that is unique within the organization, system, or exchange network, and match that patient’s record within and between systems using a number of demographic data elements, such as the patient’s first name, last name, address, and date of birth. Effective PIM supports patient identity integrity, which the National Association of Healthcare Access Management defines as accurately identifying and matching the right patient with his or her complete medical record, every time, in every provider setting.64 Accurate patient identity management is critical to successfully delivering the right care to the correct patients. Capturing incorrect or incomplete data can result in critical patient care issues and risk privacy breaches. Health care organizations are more likely to have their EHR system filled with duplicate patient records and inaccurate information about their patients when they are not managing an effective PIM process. Having an ineffective PIM process will most definitely negatively impact a hospital’s patient event notification system, which is one of the many reasons why a rigorous PIM process is essential to patient care as health IT moves forward. Additionally, PIM has become crucial in order to (1) 64 National Association of Healthcare Access Management. (2016, March 17). NAHAM Public Policy Statement on Patient Identity Integrity. Retrieved from https://nahamnews.blogspot.com/ 2016/03/naham-public-policy-statement-on.html. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations enable health record document consumers to obtain trusted views of their patient subjects; (2) facilitate data exchange projects; (3) abide by the current regulations concerning patient information-related transparency, privacy, disclosure, handling, and documentation; and (4) make the most efficient use of limited health care resources by reducing redundant data collection.65 Nationally recognized practices and standards for ensuring patient identity integrity have been identified by organizations such as the National Association of Healthcare Access Management, American Health Information Management Association, the Agency for Healthcare Research and Quality, and ONC. These standards include standardizing demographic data fields and internally evaluating the accuracy of patient matching within health care organizations. We believe this presents an opportunity for the health IT industry to lead the way in developing innovative solutions to patient matching, or PIM, that can benefit all facets of the health care industry. However, appreciating the importance of accurate patient matching, CMS will continue to evaluate ways to support improved patient matching solutions. Comment: Several commenters suggested additional provider types that should receive patient event notifications. For instance, commenters suggested health plans should be included on the list of recipients for patient event notifications, noting that this information would be valuable to plans responsible for coordinating services for beneficiaries and reducing readmissions. One commenter also recommended sending notifications to public health departments. Several commenters also requested that specific health care professionals be identified as recipients. Commenters also suggested that other caregivers such as relatives be included on the list of recipients. Response: We appreciate commenters’ suggestions about adding additional recipients for patient event notifications. While there may be other entities that could benefit from receiving patient event notifications, we believe it is more appropriate for the purposes of the CoP requirements to focus on a minimal set of recipients for notifications. This approach would not preclude hospitals from sending 65 Gliklich, R., Dreyer, N., & Leavy, M. (Eds.). (2014). Registries for Evaluating Patient Outcomes: A User’s Guide (3rd ed.). Rockville, MD: AHRQ Publication. Retrieved from https:// www.ncbi.nlm.nih.gov/books/NBK208616/. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 notifications to other entities, including health plans, provided hospitals comply with applicable laws and regulations regarding sharing of patient data. Comment: Many commenters suggested that CMS should consider approaches that aim to incentivize providers to implement patient event notifications, rather than requiring hospitals to do so through the CoPs. Commenters stated that adding this requirement would result in unnecessary and burdensome duplication of requirements that hospitals are already subject to as part of existing programs focused on advancing health information exchange. Specifically, many commenters recommended that CMS seek to advance these goals through the Promoting Interoperability Program. Commenters suggested CMS consider adding a measure to the program based on patient event notifications, noting that such a measure could mirror the ‘‘active engagement’’ concept currently used for public health measures under the program or be assessed through an attestation similar to current attestations related to information blocking. Several commenters also noted our discussion of potentially establishing a set of ‘‘health IT activities’’ under the Promoting Interoperability Program (84 FR 7618) that would not be linked to performance measures, noting that such a concept would be well-suited to advancing patient event notifications. One commenter noted that the Promoting Interoperability Program, with its annual performance assessment, is more appropriate to supporting progress on technology goals than the CoPs, and that a measure reported annually could better assess the degree to which providers are improving their usage of patient event notifications. Commenters also recommended other alternative strategies that CMS could engage in to incentivize use of patient event notifications, such as models established under Innovation Center authority. Commenters believed that highlighting the use of patient event notifications in connection with alternative payment models could help to strengthen the business case for this intervention. Another commenter recommended that the use of patient event notifications could be incentivized through an offset or bonus in a hospital-focused quality program, or through offering regulatory flexibility (for instance around telehealth) to hospitals that choose to implement a system for notifications. Response: We appreciate commenters’ suggestions to encourage the use of patient event notifications through the PO 00000 Frm 00087 Fmt 4701 Sfmt 4700 25595 Promoting Interoperability Program. In order for an action to serve as the basis for a measure under the Promoting Interoperability Program, the action must require the use of certified health IT. As discussed in the CMS Interoperability and Patient Access proposed rule, at this time there is no certification criterion included in ONC’s certification program for the creation and transmission of patient event notifications (84 FR 7651). As discussed elsewhere in this final rule, ONC does not believe there is a widely adopted consensus standard for patient event notifications at this time. ONC will continue to monitor adoption of standards for this use case and consider whether it would be appropriate to develop a certification criterion for this functionality. Accordingly, we believe it would not be feasible to add a measure related to patient event notifications to the Promoting Interoperability Program at this time. We appreciate commenters input about other programs that could advance the use of patient event notifications, such as models established under Innovation Center authority, and will take these under consideration. Comment: Several commenters addressed the use of the ADT standard for patient event notifications. One commenter noted that the ADT messaging standard is very broad and that implementations are subject to significant variability and customization. Commenters highlighted the fact that there is significant variation in the implementation of the ADT standard, limiting interoperability across interfaces using this standard, and suggested that CMS clarify specific content and triggering events for ADT data exchange. Another commenter noted that the lack of an implementation guide for the use of ADT messages for notifications is challenging, as this guidance is essential for understanding what information must be sent and how. Commenters who believed that the reference to the ADT standard would require the establishment of new interfaces for exchanging ADT messages stated that recipient providers would not be able to receive ADT messages if they do not have an inbound ADT interface in place. Many commenters believed that specifying the HL7 2.5.1 ADT message standard would be overly restrictive and recommended that CMS not specify a specific standard for these transactions at this time. Commenters urged CMS to focus on creating functional requirements rather than identifying specific mechanisms or standards for E:\FR\FM\01MYR2.SGM 01MYR2 25596 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations the data. Other commenters stated that any standard should be required as a floor, rather than a ceiling. One stakeholder recommended that CMS compile stakeholder feedback to better understand which standard would be preferred by the industry. Several commenters supported adoption of the ADT message standard (HL7 2.5.1), stating that it is the most frequently used standard for the transmission of patient event notifications. One commenter urged CMS to avoid policies that allow a hospital to deviate from a required standard, and to align with standards proposed by ONC to ensure consistency across different types of data exchange. One commenter suggested that CMS explore moving to later versions of the HL7 2.5.1 standard, which provide additional message types, segments, and codes while others noted that additional work will be needed by standards setting bodies such as HL7 to develop a more robust standard in the future. Other commenters supported the flexibility discussed in the CMS Interoperability and Patient Access proposed rule with respect to using other standards and features to support sending patient event notifications. One commenter supported the flexibility provided in the proposed rule, but believed that this flexibility may introduce challenges for those providers receiving and incorporating information provided by a hospital. Several commenters urged CMS to not require the use of certified EHR technology (CEHRT) to send ADT messages, noting that hospitals currently use a variety of solutions to send patient event notifications. One commenter noted that the HL7 protocol cannot be sent using Direct messaging or other exchanges used for continuity of care documents. One commenter noted that ADT information is not available in real time, and that an open API for both the hospital and receiving provider would be needed to enable real-time notifications. Commenters recommended that CMS instead focus on the use of standards-based feeds from the hospital’s technology of choice. Response: We appreciate commenters’ feedback. We recognized in the CMS Interoperability and Patient Access proposed rule that there is currently significant variation in how hospitals have utilized ADT messages to support implementation of patient event notifications (84 FR 7651). In recognition of this current state, we proposed to require that a hospital would be subject to this CoP if its system complied with the ADT messaging standard, but we did not VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 propose to require that hospitals use a specific standard to format or deliver patient event notifications. We believe this flexibility is necessary due to significant variation in how HL7 2.5.1 messages have been used to support notifications, and allows providers to use other standards for structuring and delivering this information that they may be currently using to implement patient event notifications, or may prefer to use for other reasons. As noted, our intent is to allow flexibility; therefore, we have refrained from specifying a standard for delivery of patient event notifications that could be overly limiting for hospitals. We are finalizing revised regulation text at 42 CFR 482.24(d), 482.61(f), and 485.638(d) that specifies that a hospital system’s conformance with the ADT standard will be used solely to determine whether a hospital is subject to the CoP. Requirements regarding the content and format of the patient event notifications, which a hospital’s system must send to satisfy the CoP, are limited to the minimal information elements described elsewhere in this final rule. We are not specifying a standard for the content, format, or delivery of these notifications. We also note that we did not specify that hospitals must use a specific technology to send patient event notifications; for instance, we did not specify that a hospital must use the capabilities of certified health IT to send notifications, nor that hospitals must send notifications via an interface adhering to the HL7 messaging standard. We hope that this response addresses commenters’ concerns, and clarifies that the reference to the HL7 messaging standard in these requirements does not preclude use of other standards for transporting patient event notifications. In addition, we note that our understanding is that many successful patient event notification implementations have used the content of HL7 messages in conjunction with other forms of transport, such as Direct messages. While we agree with commenters that common usage of a single, strictly defined standard would increase interoperability for these transactions, we do not believe that this is possible at this time. At the same time, we strongly encourage hospitals, and any intermediaries a hospital may partner with, to adopt standards-based approaches to the structure and transmission of patient event notifications, including the many standards-based solutions described by commenters. We acknowledge that, at this time, the use of different standards PO 00000 Frm 00088 Fmt 4701 Sfmt 4700 may result in decreased ability for certain providers to receive notifications from sending hospitals, depending on the attributes of their respective systems. We will consider whether there are additional ways we can encourage hospitals to move towards increased interoperability for these transactions in the future. We also wish to address and clarify a discrepancy in the way we referenced the ADT messaging standard in the proposed rule. Specifically, in the preamble of the proposed rule we cited 45 CFR 170.299(f)(2), where the HL7 2.5.1 messaging standard is listed for incorporation by reference. However, in the regulation text of the proposed rule, we erroneously cited to 45 CFR 170.205(a)(4)(i), which contains the C– CDA standard instead of HL7 2.5.1. The C–CDA standard is referenced in certification criteria related to summary of care records (84 FR 7678). As discussed above, we are finalizing our policy that a hospital will be subject to the requirements in this section if it uses a system conformant with the HL7 2.5.1 content exchange standard, which indicates a system has the basic capacity to generate information for patient event notifications. In this final rule, we are revising the regulation text and finalizing a citation to the HL7 2.5.1 content exchange standard where it is currently referenced at 45 CFR 170.205(d)(2). We believe that this citation is the most appropriate way to reference the HL7 2.5.1 standard. Comment: Several commenters requested that CMS indicate whether it would be acceptable to transmit information using other standards than the ADT message, specifically delivering messages using the C–CDA standard, which providers must use to satisfy the requirements of the transitions of care measures under the Promoting Interoperability Programs. Several commenters stated that they would prefer to format messages using this standard, which they already use for the Promoting Interoperability Program, and that a requirement to deliver messages according to the HL7 ADT messaging standard would result in duplicative work. Others questioned whether transmitting notifications via a FHIR®-based API would be permissible. Response: In the proposed rule, we stated that a hospital’s medical records system is a compliant system if it utilizes the ADT messaging standard. However, we did not propose a specific format or standard for the patient event notification that a hospital would be required to send under the proposed CoP. Thus, hospitals would be allowed to transmit patient event notifications E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations using other standards, such as the C– CDA or via a FHIR-based API. Comment: Many commenters supported the inclusion of diagnosis in patient event notifications where permitted by law, stating that this information is helpful for supporting care coordination between a hospital and other providers. One commenter noted that this information can be included by leveraging certain segments of the HL7 ADT feed, and that this segment can also be filtered for sensitive diagnoses that are prohibited for transmission under certain state or federal laws. A number of commenters expressed concerns about requiring the inclusion of diagnosis, noting that hospitals may not have this information at the time of admission, when only the presenting symptom may be available, or immediately at discharge. Other commenters noted that while this is important information for improving care coordination, diagnosis is not included in the most basic versions of the HL7 ADT messaging standard. Other commenters noted that clinical data is more appropriate for transfer through other standards for sharing clinical data, such as the C–CDA standard, which is specified to support the exchange of clinical summaries using certified health IT. These commenters noted that rather than requiring the inclusion of diagnosis in the patient event notification, it would make more sense to allow hospitals to transfer this information by attaching a clinical summary to the notification, or by providing this information upon request from a receiving provider. Response: We agree with commenters that diagnosis is an important data element to share during care transitions. However, our intention for this proposal has been to set a minimal floor for patient event notifications, allowing for significant flexibility, in recognition of the wide variety of ways that providers are currently implementing patient event notifications. We are concerned that the proposed requirement to include diagnosis could introduce unnecessary burden for hospitals that will be seeking to satisfy this requirement utilizing the most basic information available in an ADT message to support patient event notifications. As a result, we are not finalizing a requirement that diagnosis must be included in patient event notifications at 42 CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2). We wish to reiterate that this final policy in no way precludes hospitals from including additional information, such as diagnosis, in a patient event VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 notification. We also note that hospitals are required to send other necessary medical information to receiving providers under the hospital CoP on Discharge Planning at 42 CFR 482.43. In addition, certain clinical information such as diagnosis is included in the summary of care record which hospitals must be capable of transferring electronically in order to meet the health information exchange measures under the Promoting Interoperability Program. Comment: Several commenters suggested CMS require hospitals to include additional informational elements in patient event notifications, such as: Discharge disposition; chief complaint; medication profile; insurance policy coverage information; additional information about the hospital, such as address and tax ID; contact information for a variety of resources such as social services agencies and legal assistance providers; and other information that can be used for patient matching. Commenters believe that additional information would have a positive impact on care coordination. Other commenters supported the proposal to require only a limited data set. One commenter recommended that CMS impose additional parameters on the information included as part of patient event notifications, including a requirement that data must be recent and relevant to patient care. Response: We appreciate commenters’ suggestions, and agree that this additional information can have a positive impact on care coordination, patient matching, and other requirements. However, we do not believe that this information should be required within the CoPs for patient event notifications. We have heard from many stakeholders that even patient event notifications with extremely limited information can have a positive effect on care coordination when they are delivered in a timely manner. In addition, we understand that hospitals are currently delivering patient event notifications with widely varying sets of information. Finally, we note that hospitals are required to send other necessary medical information to receiving providers under the hospital CoP on Discharge Planning at 42 CFR 482.43. While we decline to require additional data at this time, to ensure that hospitals are able to satisfy the requirement with minimal effort, we encourage hospitals to consider other information that can be added to patient event notifications to support care coordination. PO 00000 Frm 00089 Fmt 4701 Sfmt 4700 25597 Comment: Many commenters suggested that CMS work with ONC to add a certification criterion or a condition of certification related to the transmission of patient event notifications under ONC’s certification program. Many commenters stated that hospitals should not be required to comply with the proposed requirements until they have had an opportunity to adopt certified technology supporting these requirements. Commenters believed this would assure hospitals that their systems are compliant with the proposed requirements. Moreover, commenters expressed concern that without complementary regulation directed toward health IT developers, the burden for ensuring these technical capabilities would rest on hospital providers alone. Some commenters suggested that ONC should also include data elements related to patient event notifications in the USCDI, or seek to standardize notification data elements in another way, to ensure that notifications can be received by other EHR systems. Commenters also pointed to a variety of emerging initiatives which focus on barriers to information exchange, such as TEFCA, policies to address information blocking, and updates to API technology under the ONC certification program. Commenters urged CMS to leverage these initiatives to advance the use of patient event notifications, for instance, by incorporating patient event notification functionality through the networks established as part of TEFCA. Response: We appreciate commenters’ input. As we noted in the CMS Interoperability and Patient Access proposed rule, there is currently no certification criterion specific to creating and sending electronic patient event notifications included in ONC’s certification program (84 FR 7651). While ONC monitors the development of consensus standards for patient event notifications as part of its ISA (https:// www.healthit.gov/isa/admissiondischarge-and-transfer), ONC has not yet proposed to develop a certification criterion based on any of these standards. Instead of focusing on the use of a specific certification criterion, we have sought to allow hospitals flexibility in how they satisfy the proposed CoP. We believe this is consistent with current practices around patient event notifications that have been implemented in a wide variety of ways across hospitals. We appreciate that many other policy initiatives may intersect with how hospitals implement patient event notification requirements. While we believe that providers will be E:\FR\FM\01MYR2.SGM 01MYR2 25598 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations able to implement patient event notifications based on existing systems and infrastructure, we believe that many of the initiatives commenters mentioned will help to enable and enhance notification capabilities as they are introduced. Comment: A number of commenters stated that the proposal would disproportionately burden rural and critical access hospitals. Commenters noted that providers in these settings may not have an EHR system, or may be unable to upgrade to the newest edition of certified technology. For small and rural providers that do have an EHR system, commenters expressed concern about the implementation costs providers would need to incur as they work with their EHR vendors to deploy new functionality. Commenters noted that, while working with an intermediary could substantially reduce the burden associated with this proposal, many small and rural hospitals are operating in geographic areas that are not yet served by entities such as health information exchanges that could serve as intermediaries, requiring these hospitals to dedicate significant resources to developing a compliant solution. This lack of access to appropriate infrastructure would put small and rural hospitals at disproportionate risk of noncompliance with the CoP standard, despite the significant effects penalties for noncompliance may have on underserved communities. Several commenters raised concerns about these providers’ ability to shoulder compliance costs with the proposed requirements, and suggested CMS provide funding opportunities to these hospitals to mitigate the potential burden associated with the proposal. Response: We appreciate commenters’ concerns about the impact of this proposal on small, rural, and critical access hospitals (CAHs). We note that those hospitals without an EHR system with the technical capacity to generate information for electronic patient event notifications, defined as a system conformant with the ADT messaging standard (HL7 2.5.1), will not be subject to this final rule. Furthermore, we believe that changes finalized in this rule will ease some of the potential compliance burden associated with the rule, and make it easier for these hospitals to comply successfully with the CoP standard. For example, our final policy extends the applicable date for the requirements as well as defining a more limited set of a recipients to whom hospitals must send notifications for the purposes of compliance with the CoP. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Comment: Many commenters noted that patient event notifications are most effective when they take into account receiving providers’ preferences. Commenters noted that recipients need flexibility to determine the information that they want to be notified about, the frequency of notification delivery, and how they would like notifications delivered; otherwise providers may experience ‘‘signal fatigue’’ due to receiving an excessive number of messages that do not contain information the provider finds useful. Commenters expressed concern that, under the proposed requirements, hospitals would not have flexibility to take into account receiving providers’ preferences for receiving patient event notifications. They further believed that the proposed requirements would result in hospitals sending information to all providers regardless of their interest in receiving notifications, while implementation experience has shown that notifications are more successful when receiving providers can request the information they would like to receive. Response: We appreciate commenters’ concerns about the importance of incorporating provider recipients’ preferences when implementing patient notification systems. We understand from stakeholders that a key feature of successful patient event notification implementations is flexibility with respect to the manner in which notifications are delivered, to allow for better alignment with individual providers’ workflows. Without such flexibility, providers are more likely not to find notification systems useful, reducing their effectiveness to improve care coordination. We note that under the proposed requirement, hospital systems must send patient notifications in accordance with the proposed requirements. However, this would not preclude hospitals, working either directly with providers or through an intermediary, from tailoring the delivery of patient notifications in a manner consistent with individual provider preferences. For instance, while a hospital’s system must be able to send notifications at both admission and discharge, as well as at the time of registration in the emergency department, if a specific provider prefers only to receive notifications upon discharge, nothing would prevent the hospital from limiting the notifications sent to that provider accordingly. We note that our revised regulation text states that hospitals must send notifications to those recipients that ‘‘need to receive notification of the PO 00000 Frm 00090 Fmt 4701 Sfmt 4700 patient’s status for treatment, care coordination, or quality improvement purposes.’’ We believe that this standard will allow hospitals the discretion to determine which recipients need to receive notifications, for instance, by declining to send certain notifications where a practitioner has stated that such notifications are not necessary or effective for supporting care coordination. In cases where the hospital has partnered with an intermediary to deliver notifications, the intermediary may exercise this discretion on behalf of a hospital. Comment: Many commenters supported the proposal to allow use of an intermediary to deliver patient event notifications. Commenters stated that use of an intermediary could reduce operational burden on hospitals by maintaining recipient information, supporting more effective patient matching, and delivering notifications in accordance with receiving providers’ preferences. Commenters pointed to numerous examples of how intermediaries, such as health information exchanges, are successfully facilitating the delivery of more complete and accurate patient event notifications from today. Response: We thank commenters for their support and agree that the use of intermediaries to deliver patient notifications can reduce burden on hospitals and support effective notification systems. Comment: Several commenters sought additional information on our proposals with respect to the use of an intermediary, and whether exclusive use of an intermediary, provided other requirements are met, would satisfy the CoP. Commenters stated that they believe hospitals should be able to exclusively make use of an intermediary. Other commenters suggested that CMS should ‘‘deem’’ a hospital compliant with the CoP if they demonstrate that they are using an intermediary to deliver notifications, as long as the intermediary has not been found to violate information blocking rules. Response: In the CMS Interoperability and Patient Access proposed rule, we stated that, if finalized, hospitals would be required to send notifications ‘‘directly or through an intermediary that facilitates exchange of health information.’’ We believe this would allow exclusive use of either method, or a combination of these methods, provided other requirements of the CoP are met. For instance, if a hospital makes exclusive use of an intermediary to satisfy the CoP, the hospital would still be subject to the requirement that E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations notifications must be sent to the set of recipients we are finalizing in this rule, specifically all applicable post-acute care services providers and suppliers as well as a patients’ primary care practitioners or practice groups and entities primarily responsible for a patient’s care, as well as practitioners identified by the patient. Given this requirement, exclusive use of an intermediary with a limited ability to deliver notifications to the specified set of recipients, for instance an intermediary which restricts its delivery to only those providers within a specific integrated health care system, would not satisfy the CoP. Alternatively, if a hospital demonstrates that an intermediary connects to a wide range of recipients and does not impose restrictions on which recipients are able to receive notifications through the intermediary, exclusive use of such an intermediary would satisfy the CoP. Comment: Commenters sought additional information on whether it would be permissible for a hospital to delegate responsibility for making a determination about the existence of a patient’s care relationships to an intermediary that facilitates delivery of a patient notification. Response: In the CMS Interoperability and Patient Access proposed rule we discussed a variety of methods through which hospitals can identify recipients for patient notifications, including through partnering with intermediaries such as health information exchanges (84 FR 7652). We reiterate that we believe this is one way that hospitals are currently identifying recipients for notifications, and that using an intermediary to do so may reduce operational burden for hospitals. Thus, hospitals would be permitted to delegate this authority. Comment: Several commenters requested additional information on whether ACOs would be entitled to receive patient event notifications. Commenters stated that ACOs represent groups of providers and suppliers and work directly on their behalf. Therefore, it was unclear whether they would be considered intermediaries or providers and suppliers for the purposes of the proposed CoP. Commenters stated that patient event notifications are used by many ACOs today, and that ACOs both receive notifications directly from hospitals and through other intermediaries such as health information exchanges. Response: We note that the proposed CoP does not create an entitlement for any specific provider or intermediary to receive patient event notifications. Rather, it requires hospitals to VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 demonstrate that their medical records system sends patient event notifications in a manner compliant with the proposed requirements. We believe there is nothing in the proposed requirements that would prevent ACOs that have business associate relationships with the intended primary care practitioner or practice group or entity from receiving patient event notifications on behalf of that practitioner, group, or entity so long as their business associate agreement allows them to fulfill that role. Comment: Several commenters suggested that CMS should develop a mechanism for allowing community providers to report that they have not received notifications from a given hospital, or that the notifications received are incomplete or unreasonably delayed. Commenters believe that such a mechanism would ensure patient event notification systems are functional and help to establish delivery parameters across a community. Response: We appreciate commenters’ input, but are unclear here as to whether the commenters are requesting that we develop a regulatory mechanism within the CoP provisions to allow for a community provider to report to a hospital any issues it may be experiencing with the hospital’s notification system or if the request is for CMS to develop some other type of mechanism to accomplish this, such as an incentive-based payment mechanism as a means of encouraging a hospital to include this reporting function as part of its notification system. If it is the latter type of request, then such a mechanism would be outside the scope of the CoPs and this section of the rule. However, if it is the former type of request, we will consider these ideas as we evaluate future updates and revisions to the CoPs with regard to patient event notifications. Comment: We proposed that a hospital would only need to send notifications to those practitioners for whom the hospital has reasonable certainty of receipt (84 FR 7652). We further explained that we expected hospitals would, to the best of their ability, seek to ensure that notification recipients were able to receive notifications, but that we recognized that factors outside of the hospital’s control may determine whether or not a notification was successfully received and utilized by a practitioner. Many commenters stated that a standard of ‘‘reasonable certainty’’ would hold hospitals responsible for factors outside of their control that prevent delivery of notifications, and that hospitals should only be held PO 00000 Frm 00091 Fmt 4701 Sfmt 4700 25599 accountable for transmission of information, not receipt. Commenters stated that it would be very difficult for hospitals to obtain reasonable certainty given the limitations of the infrastructure that is currently available for sharing health information. Several commenters believed that the phrase ‘‘reasonable certainty’’ would impose a new affirmative duty to validate receipt of notifications, which would result in significant additional administrative burden for hospitals. Several commenters suggested that CMS replace the term ‘‘reasonable certainty’’ with alternatives such as ‘‘reasonable effort’’ or ‘‘reasonable confidence.’’ They believed these alternative standards would better reflect actions within the hospital’s control. Response: We appreciate commenters’ feedback. In proposing that hospitals send notifications to those practitioners for whom the hospital has reasonable certainty of receipt, we sought to adapt a similar standard currently identified in guidance for the Promoting Interoperability Program (see https:// www.cms.gov/Regulations-andGuidance/Legislation/EHRIncentive Programs/Downloads/MedicareEH_ 2019_Obj2-.pdf) regarding the expectations of participants in that program when they transfer a summary of care record to another provider. However, we concur with commenters that a standard of ‘‘reasonable certainty,’’ while appropriate for the Promoting Interoperability Program, in which participants are required to use certified technology for the transmission and receipt of summary of care documents, may not be appropriate in the context of this proposal, which permits flexibility in both the technology used to send and receive patient event notifications and the format of the notification itself. We agree that a standard that better reflects actions within the hospital’s control would be much more appropriate in this circumstance. Accordingly, we are revising our final policy (at 42 CFR 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5)) to now require that a hospital (or a CAH) must demonstrate that it ‘‘has made a reasonable effort to ensure that’’ the system sends the notifications to any of the following that need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes to all applicable post-acute care services providers and suppliers and: (1) The patient’s established primary care practitioner; (2) the patient’s established primary care practice group or entity; or (3) other E:\FR\FM\01MYR2.SGM 01MYR2 25600 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care. We believe that this modified standard will provide hospitals and CAHs with appropriate flexibility and can account for the constraints of providers’ existing systems. We also believe that this modified standard takes into account the fact that some recipients may not be able to receive patient event notifications, or may not be able to receive notifications in a manner consistent with a hospital system’s capabilities, and the fact that hospitals and CAHs may not be able to identify provider recipients for some patients. We expect that surveyors will evaluate whether a hospital is making a reasonable effort to send patient event notifications while working within the constraints of its existing technology infrastructure. Comment: Several commenters offered their assessments of readiness across hospitals to implement patient event notifications. One commenter pointed to hospitals’ high levels of engagement in some form of health information exchange as an indication that hospitals are well-positioned to distribute patient event notifications, and stated that establishing ADT-based notification feeds did not impose significant burdens on hospitals. Another commenter agreed that the technical capabilities to implement notifications exists today, and stated that the primary challenge for hospitals would be in updating business and operational practices to comply. Other commenters stated that functionality to use ADT message information for patient event notifications is not part of certified electronic health record technology and that not all EHRs are capable of generating notifications. They stated that EHRs are not able to automatically send and receive notifications and cautioned CMS against oversimplifying the development burden associated with implementation. One commenter suggested that CMS should provide supplemental funding to support hospitals’ costs, workflow changes, and technical expertise associated with implementation. Response: We thank commenters for their insights. We share the assessment of commenters who stated that most hospitals will be able to implement patient event notifications with minimal burden due to the widespread adoption of technology systems that can be utilized to support generating and sending these notifications. Patient event notifications have been widely VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 recognized as an important way to support patient safety, by enabling providers and suppliers responsible for the post-discharge care of a patient to quickly initiate care coordination protocols that can mitigate the risk of deterioration of a patient’s condition following a hospital stay. We understand some commenters’ concerns that the ability to send patient event notifications has not been included as a capability certified under the ONC certification program, and that there is no widely adopted, uniform approach to sending patient event notifications at this time. However, as noted by many commenters, we believe there are a wide variety of available, low-cost solutions that providers can adopt to fulfill the minimal requirements described in this final rule. Accordingly, we have provided significant flexibility for providers to meet these requirements by not including additional technical specifications about how patient event notifications must be formatted and shared. We believe that this approach allows flexibility for hospitals to establish patient event notifications that meet the requirements in ways that minimize implementation burden; however, we recognize that the lack of a uniform approach may lead to instances where a provider is unable to receive notifications sent by a hospital in a seamless, interoperable fashion. Comment: Commenters stated that national infrastructure for health information exchange was not yet mature enough to support the widespread implementation of patient event notifications and that successful implementation of notifications requires the ability to acquire data feeds and a rules engine to support alerting routing and delivery, as well as a patient index function to create and verify patient panels. While many commenters believed that this infrastructure might be available in the future, for instance, through establishment of the TEFCA, they stated that it is not ubiquitous today. Without this infrastructure, commenters noted that providers would be required to support a large number of point-to-point interfaces with other providers that lack scalability, and will be highly costly, inefficient, and burdensome to develop and maintain. One commenter recommended that CMS establish that, for compliance purposes, a hospital would only be required to demonstrate a notification has been sent for a single patient. This would allow surveyors to confirm that the system is functional while allowing for variation across hospitals depending on their capabilities to send PO 00000 Frm 00092 Fmt 4701 Sfmt 4700 notifications under different circumstances. One commenter suggested that CMS should focus on incentivizing providers to participate in existing scalable networks that support health information exchange, including patient event notifications. Response: We agree with commenters that the national health information exchange infrastructure to support patient event notifications is not yet ubiquitous. However, we believe that the health information infrastructure that exists today will be sufficient to provide substantial support for the requirements we are finalizing in this rule. As other commenters noted, organizations such as health information exchanges are supporting the sharing of patient event notifications in many areas today. While we understand there is variation in availability of this infrastructure, we believe there are options increasingly available for hospitals to implement basic patient event notifications that will allow hospitals to demonstrate they have made a ‘‘reasonable effort’’ to ensure their system sends the required notifications, as per the policy finalized in this final rule. We appreciate the suggestion that the CoP should specify a hospital could achieve compliance through demonstrating that a notification has been sent for a single patient, and that this would ease compliance concerns expressed by stakeholders. However, we believe that these concerns are addressed through the more limited standard in our final policy that requires a hospital (or CAH) to make a ‘‘reasonable effort’’ to ensure that its system sends these notifications. In addition, and as previously noted, survey and certification interpretive guidelines utilize a variety of approaches to evaluate whether a hospital has satisfied the CoP, and in this final rule we decline to employ overly prescriptive regulatory language that might significantly limit options for surveyors as they assess compliance. Comment: Many commenters identified challenges related to the proposal that a hospital demonstrate that its system sends notifications to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers meeting certain conditions (84 FR 7651). Commenters stated that the proposal seemed to require a hospital to be able to send a notification to any other health care provider and assumed that the receiving provider would have the technological capabilities to receive this information. Commenters stated that this is not realistic given the current E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations state of technology adoption among receiving providers, and that recipients would need to develop capabilities to receive, incorporate, and use these notifications for the proposal to be effective. Commenters stated that, today, notifications would only be likely to reach recipients only a percentage of the time citing many factors related to the limitations of EHR technology that prevent providers and clinicians from incorporating electronic information into their EHRs. For instance, commenters noted that EHRs must be able to confidentially match transferred data to a patient, incorporate the notification into the EHR, and ensure that it is reviewed and stored in a clinically appropriate way to ensure it is effectively used. Commenters stated that CMS should consider complementary requirements and/or supports for ambulatory and other facilities to ensure they are able to receive patient event notifications provided by hospitals. Commenters requested additional information on the expectations for receiving providers to successfully receive and incorporate patient event notifications, and noted they may face significant burden associated with technical development if expected to be able to receive these notifications. Moreover, commenters expressed concerns about the capacity of specific providers, including small and rural physician practices and post-acute care providers and suppliers, to receive patient event notifications. Commenters specifically noted that post-acute care providers were not provided financial incentives under the HITECH, and therefore many post-acute care providers are not using EHRs or are using EHRs that are not able to exchange information with hospital EHRs. Several commenters recommended that CMS not hold hospitals accountable for delivering patient event notifications to post-acute care suppliers, given the difficulties these suppliers would have in receiving these notifications. Others stated that the inability of these providers to receive notifications would limit the effectiveness of the proposed requirements. Response: We appreciate commenters input on this issue. In the CMS Interoperability and Patient Access proposed rule, we stated that a hospital subject to the proposed requirements must demonstrate that its system sends notifications to certain recipients. We do not expect that a hospital would ‘‘demonstrate’’ that its system meets these requirements through meeting a comprehensive measure of performance. Likewise, we would not expect a VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 hospital’s system to be capable of electronically communicating with every possible provider, facility, or practitioner system, or of satisfying every possible preference for delivery of patient event notifications that a provider, facility, or practitioner might attempt to impose on the hospital. As noted above, we are modifying our proposal to require that a hospital makes a ‘‘reasonable effort’’ to ensure that its system sends patient event notifications to the specified recipients. Under the survey and certification process we would expect a hospital to demonstrate its system’s compliance with the CoP in a variety of ways, subject to the system’s capabilities. For instance, if a given system sends notifications via Direct messaging, we might expect surveyors to review whether the hospital has a process in place for capturing Direct addresses of patients’ primary care practitioners to enable the system to send patient event notifications to these recipients. Finally, with regard to comments about PAC services providers and suppliers that were not eligible for incentives for EHR adoption under the EHR Incentive Programs established by the HITECH Act, we again note that the requirements in this final rule are limited to only those hospitals and CAHs that possess and utilize EHR or other administrative systems with the technical capacity to generate information for electronic patient event notifications. Moreover, a hospital or CAH with such a system must only demonstrate that it has made a ‘‘reasonable effort’’ to ensure that its system sends notifications to any of the specified recipients, including all applicable post-acute care services providers and suppliers (that is, to those PAC services providers and suppliers to whom the patient is being transferred or referred). Comment: In the CMS Interoperability and Patient Access proposed rule, we did not explicitly address the effective implementation date for the proposed revisions to the CoPs. However, we note that revisions to the CoPs are generally applicable 60 days from the publication of a final rule. Many commenters recommended CMS allow additional time for implementation beyond the usual applicable date of these revisions. Commenters stated that additional time was required to allow providers to complete technical upgrades and train staff on new workflows. One commenter suggested that CMS finalize different timeframes based on whether hospitals are in an area with existing infrastructure for transmitting patient PO 00000 Frm 00093 Fmt 4701 Sfmt 4700 25601 event notifications. Another commenter suggested that CMS develop working groups to determine appropriate timelines for implementation. Response: We agree with commenters that additional time would be appropriate for hospitals and CAHs to implement the proposed requirements. Therefore, we are finalizing that the requirements will be applicable 12 months after the publication date of this final rule. Comment: Multiple commenters addressed privacy implications of the proposed requirements. Commenters sought clarity on whether patient consent would be required to send a patient event notification, or whether hospitals would be able to honor a patient’s request to opt-out of sharing information with providers in the form of a patient event notification. Commenters urged CMS to issue further guidance about privacy and security challenges associated with sending patient event notifications, for instance, how hospitals should address cases where they cannot confirm the identity of a provider, and/or where transmission could risk improper disclosure of protected health information. Several commenters suggested that concerns about noncompliance could lead some hospitals to be overly hasty in sending patient event notifications without considering the privacy impact of the transmission, potentially leading to inappropriate disclosures of information. Response: We appreciate commenters’ concerns about preserving patient privacy. Nothing in this proposed rule should be construed to supersede hospitals’ compliance with HIPAA or other state or federal laws and regulations related to the privacy of patient information. We note that hospitals would not be required to obtain patient consent for sending a patient event notification for treatment, care coordination, or quality improvement purposes as described in this final policy. However, we also recognize that it is important for hospitals to be able to honor patient preferences to not share their information. While the CoP would require hospitals to demonstrate that their systems can send patient event notifications, we do not intend to prevent a hospital from recording a patient’s request to not share their information with another provider, and, where consistent with other law, restrict the delivery of notifications as requested by the patient and consistent with the individual right to request restriction of uses and disclosures established in the E:\FR\FM\01MYR2.SGM 01MYR2 25602 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations HIPAA Privacy Rule. Similarly, if a hospital is working with an intermediary to deliver patient event notifications, the intermediary may record information about a patient’s preferences for how their information is shared, and, where consistent with other law, restrict the delivery of notifications accordingly. Based on commenters’ concerns regarding a patient’s ability to request that his or her medical information (in the form of a patient event notification) is not shared with other settings, we are revising and finalizing a requirement in this rule that a hospital (or CAH) must demonstrate that its notification system sends notifications, ‘‘to the extent permissible under applicable federal and state law and regulations and not inconsistent with the patient’s expressed privacy preferences.’’ Regarding improper disclosure of health information where a hospital cannot confirm the identity of a receiving provider, we note that under this policy a hospital would not be under any obligation to send a patient event notification in this case. Under our final policy, hospitals would be required to make a ‘‘reasonable effort’’ to ensure their systems send notifications to the specified recipients. We believe this standard will account for instances in which a hospital (or its intermediary) cannot identify an appropriate recipient for a patient event notification despite establishing processes for identifying recipients, and thus is unable to send a notification for a given patient. Comment: Many commenters raised concerns about how hospitals would be able to implement the proposed patient event notifications while complying with state and federal laws and regulations around the transmission of sensitive data. Commenters noted these issues are particularly relevant for psychiatric hospitals included in the proposal. Commenters noted that some states have more stringent privacy and consent requirements that apply to individuals treated in mental health facilities which may impact the sending of patient event notifications. One commenter noted that hospitals with behavioral health units do not disclose patient event information as part of their primary system data feed due to requirements that disclosure of this information must be accompanied by written consent. Commenters also noted that appropriately segregating this data is expensive and time consuming. Response: Nothing in this requirement should be construed as conflicting with hospitals’ ability to comply with laws and regulations VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 restricting the sharing of sensitive information. While hospitals subject to the CoP would need to demonstrate their system sends notifications to appropriate recipients, hospitals would not be expected to share patient information through a notification unless they have obtained any consents necessary to comply with existing laws and regulations. Comment: Many commenters supported the proposal to require a hospital’s system demonstrate that it sends patient event notifications at the time of admission, and at, or just prior to, the time of discharge. Commenters emphasized that it is important for notification information to be timely in order for it to be effective in improving care coordination. One commenter stated that some providers find that notifications triggered by an ADT message are triggered too early, prior to the availability of a discharge summary, and sought additional information about whether hospitals may use other triggers for a patient event notification. Response: We appreciate commenters’ support for the proposal. We believe patient event notifications are most useful when tied to admission (or registration, as is the term generally used for patients seen in the ED) and discharge events, as receiving near-real time information about a patient’s hospitalization can ensure receiving providers, facilities, and practitioners are able to act quickly to ensure successful care coordination. While we agree that sending available clinical information along with a patient event notification can be helpful, we believe that delaying notifications until all of the information about a patient’s hospitalization is available would likely decrease the value of the notification. Comment: Several commenters suggested that the requirements should be limited to external providers and not include providers that may share the same EHR as the hospital as part of an integrated delivery system. Commenters noted that organizations may have other ways to notify these providers about a discharge, and that hospitals should be exempt from sending notifications to these providers. Response: Under the proposed requirements, we are not specifying a format or transport method for patient event notifications. Accordingly, hospitals could use a mix of approaches to deliver patient event notifications, for instance, by partnering with an intermediary to deliver notifications to external providers, while using features internal to a shared EHR system to transmit information to providers that are part of the same organization. PO 00000 Frm 00094 Fmt 4701 Sfmt 4700 Comment: Several commenters sought clarity on how the patient event notifications would relate to information blocking policy, and urged CMS to ensure that any new CoP requirements are aligned with other policies around information blocking. Several commenters suggested that, as an alternative to the proposed requirements, CMS should establish a standard under the CoPs that states hospitals will not engage in information blocking, to be aligned with policies established by ONC in the 21st Century Cures Act final rule. Response: We note that there are currently three prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) to which eligible hospitals and CAHs must attest for purposes of the Promoting Interoperability Program. As part of successfully demonstrating that an eligible hospital or CAH is a meaningful EHR user for purposes of the Promoting Interoperability Program, the eligible hospital or CAH must submit an attestation response of ‘‘yes’’ for each of these statements. These attestations are discussed further in section VIII. of this final rule. We also refer commenters to section 3022(b)(2)(B) of the Public Health Service Act (PHSA), which provides that any health care provider determined by the OIG to have committed information blocking shall be referred to the appropriate agency to be subject to appropriate disincentives using authorities under applicable federal law, as set forth by the Secretary through notice and comment rulemaking. Further, we refer commenters to the ONC 21st Century Cures Act proposed rule for additional discussion on disincentives (84 FR 7553). Final Action: After consideration of the comments received, and for the reasons outlined in our response to these comments and in the CMS Interoperability and Patient Access proposed rule, we are finalizing these proposals with some modifications and reorganization of the provisions. These policies are being finalized at 42 CFR 482.24(d), 482.61(f), and 485.638(d) for Conditions of Participation for hospitals, psychiatric hospitals, and specialized providers (CAHs). Based on public comments, and to further advance electronic exchange of information that supports effective transitions of care for patients between hospitals and CAHs and their community PAC services providers and suppliers as well as their primary care practitioners, the following requirements at 42 CFR 482.24(d), E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 482.61(f), and 485.638(d) are being finalized here with modifications and reorganization from the proposed requirements (84 FR 7678): • We are revising 42 CFR 482.24(d) by deleting the reference to ‘‘paragraph (d)(2) of this section’’; • We are revising 42 CFR 482.61(f) by deleting the reference to ‘‘paragraph (d)(2) of this section’’; • We are revising 42 CFR 485.638(d) by deleting the reference to ‘‘paragraph (d)(2) of this section’’; • We are revising 42 CFR 482.24(d) by adding new language to the regulatory text so that it now includes ‘‘or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2),’’; • We are revising 42 CFR 482.61(f) by adding new language to the regulatory text so that it now includes ‘‘or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2),’’; • We are revising 42 CFR 485.638(d) by adding new language to the regulatory text so that it now includes ‘‘or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2),’’; • We are deleting all of the regulatory text proposed at 42 CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2), including the inaccurate references to ‘‘45 CFR 170.205(a)(4)(i);’’ • We are redesignating 42 CFR 482.24(d)(3), 482.61(f)(3), and 485.638(d)(3) as 42 CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2), respectively, and also revising the regulatory text to now state that the system sends notifications that must include at least patient name, treating practitioner name, and sending institution name; • We are redesignating 42 CFR 482.24(d)(4), 482.61(f)(4), and 485.638(d)(4) as 42 CFR 482.24(d)(3), 482.61(f)(3), and 485.638(d)(3), respectively, and also revising the regulatory text to now state that, ‘‘to the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient’s expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of: the patient’s registration in the hospital’s [or CAH’s] emergency department (if applicable); or the patient’s admission to the hospital’s [or CAH’s] inpatient services (if applicable).’’ VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 • We are redesignating 42 CFR 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5) as 42 CFR 482.24(d)(4), 482.61(f)(4), and 485.638(d)(4), respectively, and also revising the regulatory text to state that, ‘‘to the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient’s expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of: the patient’s discharge or transfer from the hospital’s [or CAH’s] emergency department (if applicable): or the patient’s discharge or transfer from the hospital’s [or CAH’s] inpatient services (if applicable).’’ • We are deleting the regulatory text proposed at 42 CFR 482.24(d)(5), 482.61(f)(5), and 485.638(d)(5) and adding new regulatory text to state that, ‘‘the hospital [or CAH] has made a reasonable effort to ensure that the system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes: the patient’s established primary care practitioner; the patient’s established primary care practice group or entity; or other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care.’’ Finally, recognizing that hospitals, including psychiatric hospitals and CAHs, are on the front lines of the COVID–19 public health emergency, and in response to the number of comments received regarding concerns with the applicability date for this rule, we are establishing an applicability date of 12 months after finalization of this rule for hospitals, including psychiatric hospitals, and CAHs to allow for adequate and additional time for these institutions, especially small and/or rural hospitals as well as CAHs, to come into compliance with the new requirements. XI. Provisions of the Final Regulations Generally, this final rule incorporates the provisions of the CMS Interoperability and Patient Access proposed rule as proposed. The following provisions of this final rule differ from the proposed rule. We are finalizing four proposals with modifications. 1. We are requiring MA organizations, Medicaid managed care plans, CHIP PO 00000 Frm 00095 Fmt 4701 Sfmt 4700 25603 managed care entities, and QHP issuers on the FFEs to maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content and vocabulary standard finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.213 (currently version 1 of the USCDI), via a payer-to-payer data exchanged as outlined in this section V. of this final rule. Specifically, we are finalizing as proposed that impacted payers incorporate the data they receive into the enrollee’s record. We are finalizing that with the approval and at the direction of a current or former enrollee, a payer must send the defined information set to any other payer. In addition, we specify that a payer is only obligated to send data received from another payer under this policy in the electronic form and format it was received. Starting January 1, 2022, and for QHP issuers on the FFEs starting with plan years beginning on or after January 1, 2022, the finalized regulation requires these payers to make data available with a date of service on or after January 1, 2016 that meets the requirements of this section and which the payer maintains. In this way, payers only have to prepare an initial historical set of data for sharing via this payer-to-payer data exchange policy that is consistent with the data set to be available through the Patient Access API, as finalized in section III. of this final rule. 2. Regarding the Patient Access API, we are finalizing requirements for MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to implement and maintain a standards-based Patient Access API that meets the technical standards as finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.215, that include the data elements specified in this final rule, and that permit thirdparty applications to retrieve, with the approval and at the direction of a current enrollee, data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221. Specifically, we are finalizing that the Patient Access API must, at a minimum, make available adjudicated claims; encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results (where maintained by the impacted payer). We are not finalizing a requirement to include Provider Directory information as part of the E:\FR\FM\01MYR2.SGM 01MYR2 25604 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Patient Access API. Instead, to limit burden, we are only requiring provider and, in the case of MA–PD plans, pharmacy directory information, be included in the Provider Directory API discussed in section IV. of this final rule. Data via the Patient Access API must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received by the impacted payer. We are finalizing that MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP state agencies, and CHIP managed care entities must make available the date they maintain with a date of service on or after January 1, 2016 beginning January 1, 2021, and for QHP issuers on the FFEs beginning with plan years beginning on or after January 1, 2021. 3. We are finalizing a Provider Directory API for MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP state agencies, and CHIP managed care entities making standardized information about their provider networks available via a FHIR-based API conformant with the technical standards finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.215 (which include HL7 FHIR Release 4.0.1), excluding the security protocols related to user authentication and authorization, or any other protocols that restrict the availability of this information to anyone wishing to access it. At a minimum, these payers must make available via the Provider Directory API provider names, addresses, phone numbers, and specialties. For MA organizations that offer MA–PD plans, they must also make available, at a minimum, pharmacy directory data, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as ‘‘retail pharmacy’’). This Provider Directory API must be fully implemented by January 1, 2021 for all payers subject to this new requirement. Under this final rule, MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities must make the Provider Directory API accessible via a publicfacing digital endpoint on their website to ensure public discovery and access. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Modifications being finalized for the timelines for these policies will provide impacted payers ample time to build and test the required standards-based APIs to meet the new API requirements. In addition, providing more time for payer-to-payer data exchange between impacted payers will ensure successful implementation, and better enable plans to use a standards-based API to meet this requirement if they so choose. We are not finalizing the Care Coordination through Trusted Exchange Networks proposal. Although some commenters did show support for the proposal, others raised strong concerns. Given the concerns commenters raised specifically regarding the need for a mature TEFCA to be in place first, and appreciating the ongoing work on the TEFCA being done at this time, we are not finalizing this trusted exchange proposal in this rule. 4. We are finalizing the Revisions to the Conditions of Participation for Hospitals and Critical Access Hospitals proposal with modifications that are based on public comments. Additionally, and based on strong support from commenters, we are including patient event notification requirements for any patient who accesses services in a hospital (or CAH) emergency department. In response to the number of comments received regarding concerns with the applicable date for this policy, we are finalizing an applicability date of 12 months after publication of this rule for hospitals, including psychiatric hospitals, and CAHs to allow for adequate time for these institutions, especially small and/ or rural hospitals as well as CAHs, to come into compliance with the new requirements. All other policies are being substantially finalized as proposed. XII. Collection of Information Requirements Under the Paperwork Reduction Act of 1995, we are required to provide 30day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. In order to fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act of 1995 requires that we solicit comment on the following issues: • The need for the information collection and its usefulness in carrying out the proper functions of our agency. PO 00000 Frm 00096 Fmt 4701 Sfmt 4700 • The accuracy of our estimate of the information collection burden. • The quality, utility, and clarity of the information to be collected. • Recommendations to minimize the information collection burden on the affected public, including automated collection techniques. We solicited public comment on each of these issues for the following sections of this document that contain information collection requirements (ICRs): A. Background Payers should have the ability to exchange data instantly with other payers for care and payment coordination or transitions, and with providers to facilitate more efficient care. Payers are in a unique position to provide patients a complete picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. To advance our commitment to interoperability, we are finalizing our proposals for the Patient Access API, the Provider Directory API, and the payer-to-payer data exchange as discussed above. We noted that these proposals were designed to empower patients by making sure that they have access to health information about themselves in a usable digital format and can make decisions about how, with whom, and for what uses they will share it. By making claims data readily available and portable to the enrollee, these initiatives supported efforts to reduce burden and cost and improve patient care by reducing duplication of services, adding efficiency to patient visits to providers; and, facilitating identification of fraud, waste, and abuse. B. Wage Estimates To derive average costs, we used data from the U.S. Bureau of Labor Statistics’ (BLS) May 2018 National Occupational Employment and Wage Estimates (https://www.bls.gov/oes/current/oes_ nat.htm). Table 1 presents the mean hourly wage, the cost of fringe benefits (calculated at 100 percent of salary), and the adjusted hourly wage. In the CMS Interoperability and Patient Access proposed rule, Table 1 was based on the latest 2017 wage data (84 FR 7658). In this final rule, we have updated Table 1 to reflect 2018 wage data, which is now the latest available data. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25605 TABLE 1—OCCUPATION TITLES AND WAGE RATES Occupation code Occupation title Administrators and Network Architects ............................................................ Security Engineer ............................................................................................ Computer and Information Analysts ................................................................ General Operations Manager .......................................................................... Operations Research Analysts ........................................................................ Software Developers, Applications .................................................................. Computer and Information Systems Managers ............................................... Designers ......................................................................................................... Technical Writer ............................................................................................... Computer Systems Analysts ............................................................................ Network and Computer Systems Administrators ............................................. Medical Records and Health Information Technician ...................................... Medical and Health Service Managers ............................................................ As indicated, we are adjusting the employee hourly wage estimates by a factor of 100 percent. This is necessarily a rough adjustment, both because fringe benefits and overhead costs vary significantly from employer to employer, and because methods of estimating these costs vary widely from study to study. Nonetheless, there is no practical alternative and we believe that doubling the hourly wage to estimate total cost is a reasonable accurate estimation method. C. Information Collection Requirements (ICRs) 1. ICRs Regarding MMA File Requirements (42 CFR 423.910) States transmit system generated data files, at least monthly, to CMS to identify all dually eligible individuals, including full-benefit and partial-benefit dually eligible beneficiaries (that is, those who get Medicaid help with Medicare premiums, and often for costsharing). The file is called the MMA file, but is occasionally referred to as the ‘‘State Phasedown file.’’ Section 423.910(d) requires states to transmit at least one MMA file each month. However, states have the option to transmit multiple MMA files throughout the month (up to one per day). Most states transmit at least weekly. This information collection activity is currently approved under OMB control number 0938–0958. Ensuring information on dual eligibility status is accurate and up-todate by increasing the frequency of federal-state data exchange is an important step toward interoperability. As a result, we proposed to update the frequency requirements in 42 CFR 423.910(d) to require that starting April 1, 2022, all states transmit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 15–1140 17–2199 15–1120 11–1021 15–2031 15–1132 11–3021 27–1020 27–3042 15–1121 15–1142 29–2071 11–9111 423.910(b)(1). Daily would mean every business day, but if no new transactions are available to transmit, data would not need to be transmitted on a given business day. We estimate it would take a computer systems analyst about 6 months (approximately 960 hours) to complete the systems updates necessary to process and transmit the MMA data daily. After completion of system updates, these system generated reports would be set to run and transmitted to CMS on an automated production schedule. As a result of updated information, we are revising the number of states currently transmitting MMA daily data from 13 states, as stated in the CMS Interoperability and Patient Access proposed rule, to 15 states. Consequently, we estimate a one-time aggregate burden for 36 entities (51 total entities (50 states and the District of Columbia) minus the 15 states currently transmitting MMA daily data) to comply with the requirement of transmission of daily MMA data at an aggregate burden of $3,111,091 (36 entities * 960 hours * $90.02 per hour for a computer system analyst to perform the updates). We have only estimated the cost of system updates since the system transfers are done automatically and this has no additional cost. We will be revising the information collection request currently approved under 0938–0958 to include the requirements discussed in this section. 2. ICRs Regarding API Proposals (42 CFR 422.119, 422.120, 431.60, 431.70, 438.242, 457.730, 457.760, 457.1233, and 45 CFR 156.221) To promote our commitment to interoperability, we are finalizing new requirements for a Patient Access API for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, CHIP PO 00000 Frm 00097 Fmt 4701 Sfmt 4700 Mean hourly wage ($/hr) Fringe benefit ($/hr) $45.09 47.80 45.67 59.56 42.48 51.96 73.49 24.05 36.30 45.01 41.86 21.16 54.68 $45.09 47.80 45.67 59.56 42.48 51.96 73.49 24.05 36.30 45.01 41.86 21.16 54.68 Adjusted hourly wage ($/hr) $90.18 95.60 91.34 119.12 84.96 103.92 146.98 48.10 72.60 90.02 83.72 42.32 109.36 FFS at 42 CFR 457.730, Medicaid managed care at 42 CFR 438.242(b)(5), CHIP managed care at 42 CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221. Additionally, we are finalizing a publicly available Provider Directory API for MA organizations at 42 CFR 422.120, at 42 CFR 431.70 for Medicaid FFS, at 42 CFR 438.242(b)(6) for Medicaid managed care, at 42 CFR 457.760 for CHIP FFS, and at 42 CFR 457.1233(d)(3) for CHIP managed care. We proposed to require these entities to establish standardsbased APIs that permit third-party applications to retrieve standardized data for adjudicated claims, encounters with capitated providers, provider remittances, beneficiary cost-sharing, reports of lab test results, provider directories (and pharmacy directories for MA–PDs), and preferred drug lists, where applicable. We finalized the requirement for a Patient Access API and a Provider Directory API; this final rule requires generally the same information as proposed to be available through APIs but we are finalizing the requirement for two APIs. Additionally, we proposed and are finalizing at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213 (currently version 1 of the USCDI). To implement the new requirements for APIs and payer to payer data exchange, we estimate that plans and states will conduct three major work phases: Initial design, development and testing, and long-term support and maintenance. In the proposed rule, we provided detailed E:\FR\FM\01MYR2.SGM 01MYR2 25606 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations estimations of the required labor categories and number of hours required to implement the API provisions (84 FR 7659). We originally estimated a onetime burden of $789,356.00 per organization or state per implementation, with an ongoing maintenance cost $158,359.00 per organization or state (84 FR 7659). We noted that, in the initial design phase, we believed tasks would include: Determining available resources (personnel, hardware, cloud space, etc.); assessing whether to use in-house resources to facilitate an API connection or contract the work to a third party; convening a team to scope, build, test, and maintain the API; performing a data availability scan to determine any gaps between internal data models and the data required for the necessary FHIR resources; and, mitigating any gaps discovered in the available data. During the development and testing phase, we noted that plans and states would need to conduct the following: Map existing data to HL7 66 FHIR standards, which would constitute the bulk of the work required for implementation; allocate hardware for the necessary environments (development, testing, production); build a new FHIR server or leverage existing FHIR servers; determine the frequency and method by which internal data are populated on the FHIR server; build connections between the databases and FHIR server; perform capability and security testing; and vet third-party applications, which includes potentially asking third-party applications to attest to certain privacy provisions. After the completion of the API development, plans and states would need to conduct the following throughout each year: Allocate resources to maintain the FHIR server, which includes the cost of maintaining the necessary patient data, and perform capability and security testing. In the proposed rule, we proposed a new requirement for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process to coordinate care between plans by exchanging, at a minimum, the USCDI at the enrollee’s request (84 FR 7640). Originally, we noted that we would 66 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 June 27, 2018. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 allow multiple methods for electronic exchange of the information, including use of the APIs. Although we considered requiring the use of the FHIR-based API, we understood that some geographic areas might have a regional health information exchange that could coordinate such transactions. We also noted other ways to exchange this data, such as: Direct plan-to-plan exchange; leveraging connections to HIEs, or beneficiary-facing third-party applications. Since the requirements for the payer-to-payer data exchange and the API provisions share a content and vocabulary standard and because plans will be investing in the development of the APIs in this final rule, we believe that plans would overwhelmingly use these APIs to meet the payer to payer data exchange requirements. As we had no reliable way to determine which plans would utilize any of the available methods to meet the payer-to-payer data exchange requirement or how to determine the cost of each of these methods, given that each plan could be at a different technology maturity level, we accounted for costs for all impacted payers assuming the use of a newly developed API to implement the payerto-payer data exchange requirements, as this would account for a higher effort options, and included this in our original estimates for the API provisions. We summarize the public comments we received on concerns raised regarding our proposed cost of implementing and maintaining the APIs and provide our responses. Comment: Some commenters expressed concern that CMS underestimated the complexity of implementing the API requirements and did not agree with the agency’s estimation that the API implementation is a one-time cost. These commenters noted that additional costs include: The costs to contract with third-party applications, the costs of ongoing education, and the cost of answering questions from members about data and errors. Commenters argued that the proposed API requirements significantly add to overhead costs and will increase costs for providers and payers, rather than facilitate information exchange and better care for patients. One commenter estimated a range of between $1 million and $1.5 million to implement the API requirements, with an additional $200,000 to maintain the API. Another commenter argued that the costs of implementation could be as high as four times the estimates CMS provided. Response: We thank commenters for their input and understand their concerns associated with the cost PO 00000 Frm 00098 Fmt 4701 Sfmt 4700 required to implement the requirements of this final rule. We understand that our estimates regarding the implementation of the API provisions may vary depending on a number of factors, including, but not limited to a payer’s current knowledge of and experience with implementing FHIRbased APIs, and whether an impacted payer will develop this technology inhouse or seek a third party contractor to support this effort. To further develop our cost estimates, we reviewed the cost estimates associated with updating Blue Button from Blue Button 1.0 to 2.0 to include a standards-based API, similar to the requirements of this final rule. This update was estimated at $2 million. However, we believe that the estimates associated with updating the existing Blue Button 1.0 to a standards-based API for Blue Button 2.0 do not accurately represent the costs for payers impacted by this final rule. Blue Button 1.0 was developed across several federal agencies, including the Departments of Defense, Health and Human Services, and Veterans Affairs, with a capability to allow beneficiaries online access to their own personal health records, such as the ability to download PDF documents. Unlike the standards-based APIs required under this final rule, Blue Button 1.0 was not originally developed with a prescribed set of standards that allow for third-party apps to connect and retrieve data via an API. The estimates for Blue Button account for upgrading an existing technology platform that was not originally developed to allow third-party app access via an API, which we believe adds additional cost that may not impact all payers under this final rule. Additionally, we note that costs related to federal procurement and the need to engage multiple contractors to implement the updates to Blue Button, while at the same time maintaining access to the original system, caused the cost of implementing standards-based APIs for Blue Button 2.0 to be higher than those costs for payers impacted by this final rule. Therefore, we believe that the estimates for upgrading Blue Button from 1.0 to 2.0 are not truly representative of the cost to implement the standards-based API required by this final rule, but nonetheless are valuable in further informing our cost estimates. As noted above, we did receive one comment that suggested a cost range between $1 million and $1.5 million to implement the API requirements of this final rule, with another commenter indicating a four-fold increase in costs relative to the estimates included in the proposed rule. While disagreeing with E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations our bottom line, these commenters did not provide where in our detailed analysis we underestimated costs. For example, it is unclear if the commenters were including voluntary provider costs, or other costs when calculating the dollar amounts for compliance. Therefore, without specific examples of additional costs that need to be accounted for in this impact analysis, we believe that our estimates are reasonable. To address commenters’ concerns regarding ongoing costs, we remind readers that we specifically are accounting for a cost of $157,656 per organization, for costs throughout the year to include: Allocating resources to maintain the FHIR server, which includes the cost of maintaining the necessary patient data, and perform capability and security testing. However, in an effort to take into account the additional information that commenters presented regarding our costs estimates, and understanding there are many factors that may influence the cost of implementing these policies, as noted above, we are adjusting our cost estimates to reflect a range instead of a point estimate. We believe that our cost projections for an initial one-time cost to implement the API requirements of this final rule of $718,414 per organization, reflecting 6 months of work by a team of ten professionals, can now serve as a minimum estimate; in other words, we do not believe it is technically feasible to implement the requirements of this final rule in less than 6 months. For a primary estimate, we have increased our cost estimates by a factor of 2 to account for cost variation. We note that using this factor of 2, the cost per organization is consistent with the commenter stating a $1 million to $1.5 million per organization cost. For a high estimate we have increased our cost estimates by a factor of 3. Although, one commenter noted a factor of 4 should be included, all other information available to us, including the commenter who noted a range between $1 million and $1.5 million, and our estimates for upgrading Blue Button, a factor of 4 does not appear to be reflective of the costs for implementation and represents more of an outlier for cost estimating purposes. As shown in section XIII. of this final rule, we have revised down our estimate of affected individual market enrollees from 76 million (all commercial market enrollees) to 17.5 million (those VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 individual market enrollees directly affected by this final rule). This reduction by a factor of 4 (76 million former estimate/17.5 million revised estimate) raises the cost per individual market enrollee per year by a factor of 4 consistent with the commenter’s suggested factor of 4. This factor of 4, however, only affects cost per enrollee per year; it does not affect total costs as calculated in Table 2. Additionally, we note that as part of our original estimated costs associated with the annual burden of the requirements of this final rule, we accounted for additional capability testing and long-term support of the APIs, increased data storage needs, such as additional servers, or cloud storage to store any additional patient health information, and allocation of resources to maintain the FHIR server, and perform capability and security testing. Therefore, our estimates related to the annual burden account for the ongoing cost, and we are not providing additional estimates for maintenance as this is already factored in. The burden estimate related to the new requirements for implementing and maintaining the APIs reflects the time and effort needed to collect the information described above and disclose this information. We now estimate: • An initial set one-time costs associated with the implementing the API requirements. • An ongoing maintenance cost after the system is set up, and the costs associated with additional data storage, system testing, and maintenance. Consistent with our discussion above, we now regard this as a low or minimum estimate, the argument being that a complex system cannot be designed in less than 6 months. Our high estimate now reflects 18 months of work (4,320 hours) for administrators and network architects. This is obtained by using a factor of 3 (4,320 hours (high estimate) = 3*1440 hours, the original estimate). For a primary estimate, we estimate 12 months of work or 2,880 hours (1,440 hours * 2) for administrators and network architects. The use of a factor of 2 is consistent with a $2 million cost per entity and consistent with the commenter who estimated an implementation cost of $1 million to $1.5 million. We note that, in terms of actual implementation, this assumption is focused on the 2,880 PO 00000 Frm 00099 Fmt 4701 Sfmt 4700 25607 hours of work that could be conducted in less than 12 months through necessary personnel or third-party contractor allocation, if needed. As a result, the ‘‘12-month’’ assumption is also consistent with the implementation of the new API requirements, which must be implemented by January 1, 2021. As can be seen from the bottom rows of Table 2: • For a low estimate, first year implementation will require a total of 8,400 hours per organization at a cost of $718,414.40 per organization (this number is obtained by adding the products of hourly wages and hours required in each row, for example 1440*$90.18 + 960*$95.60, etc.). • For a high estimate, first year implementation will require a total of 25,200 hours per organization at a cost of $2,365,243 per organization (this number is obtained by adding the products of hourly wages and hours required in each row). • For a primary estimate, first year implementation will require a total of 16,800 hours of work per organization at a cost of $1,576,829 per organization. • Therefore, the aggregate burden of the first year implementation across 345 parent organizations 67 is 2,898,000 hours (8400 * 345) at a cost of $272 million ($718,414 * 345) for the low estimate. Similar calculations show that the primary estimate is 5,796,000 hours at an aggregate cost of $544,005,936 million, and the high estimate is 8,694,000 hours at a cost of $816,008,904. • Similarly, ongoing maintenance after the first year will require a total of 1,710 hours per organization at a cost of $157,656.60 per organization. • Therefore, the aggregate burden of ongoing implementation across 345 parent organizations is $54.4 million ($157,656.60 * 345). We explicitly note that a low and high estimate were only provided for the first year, but not for subsequent years. 67 We provide a detailed rationale for how we determined the number of parent organizations in section XIII.C.1. of this final rule. In that analysis we determined that 288 issuers and 56 states, territories, and U.S. commonwealths, which operate FFS programs, will be subject to the API provisions for Medicare, Medicaid, and the commercial market. To this we added the one state that operates its CHIP and Medicaid separately. Thus, we have a total of 345 parent entities (288+56+1). E:\FR\FM\01MYR2.SGM 01MYR2 25608 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations TABLE 2—FIRST YEAR AND MAINTENANCE COST OF THE API PROVISIONS Occupation title Administrators and Network Architects Security Engineer ..... Computer and Information Analysts .... General Operations Manager ............... Operations Research Analysts ................ Software Developers, Applications .......... Computer and Information Systems Managers .............. Designers ................. Technical Writer ....... Computer Systems Analysts ................ Network and Computer Systems Administrators ........... Total Hours per System .......... Total Cost per system (Dollars) (millions) Total hours for 345 Organizations (hours) .. Total Cost for 345 Organizations (millions $) ................... Occupation code Mean hourly wage ($/hr) Adjusted hourly wage ($/hr) First year hours (low estimate) First year hours (primary estimate) First year hours (high estimate) Maintenance hours 15–1140 17–2199 $45.09 47.80 $45.09 47.80 $90.18 95.60 1440 960 2880 1920 4320 2880 180 240 15–1120 45.67 45.67 91.34 480 960 1440 60 11–1021 59.56 59.56 119.12 720 1440 2160 90 15–2031 42.48 42.48 84.96 960 1920 2880 120 15–1132 51.96 51.96 103.92 960 1920 2880 240 11–3021 27–1020 27–3042 73.49 24.05 36.30 73.49 24.05 36.30 146.98 48.10 72.60 720 960 240 1440 1920 480 2160 2880 720 90 120 30 15–1121 45.01 45.01 90.02 960 1920 2880 120 15–1142 41.86 41.86 83.72 ........................ 0 0 420 .................. .................. .................. .................. 8,400 16,800 25,200 1,710 .................. .................. .................. .................. 788,414 1,576,829 2,365,243 157,657 .................. .................. .................. .................. 2,898,000 5,796,000 8,694,000 589,950 .................. .................. .................. .................. 272,002,968 544,005,936 816,008,904 54,391,527 3. ICRs Regarding Conditions of Participation for Hospitals and Critical Access Hospitals (42 CFR 482.24(d), 482.61(f), 485.638(d)) We are expanding our requirements for interoperability within the hospital and CAH CoPs by focusing on electronic patient event notifications. We are implementing new requirements in section X. of this final rule for hospitals at 42 CFR 482.24(d), for psychiatric hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638(d). Specifically, for hospitals, psychiatric hospitals, and CAHs, we are finalizing similar requirements to revise the CoPs for Medicare- and Medicaidparticipating hospitals, psychiatric hospitals, and CAHs by adding a new standard, ‘‘Electronic Notifications,’’ that will require hospitals, psychiatric hospitals, and CAHs to make electronic patient event notifications available to applicable post-acute care services providers and suppliers, and to community practitioners such as the patient’s established primary care practitioner, established primary care practice group or entity, or other VerDate Sep<11>2014 Fringe benefit ($/hr) 08:09 May 01, 2020 Jkt 250001 practitioner or practice group or entity identified by the patient as primarily responsible for his or her care. We are limiting this requirement to only those hospitals, psychiatric hospitals, and CAHs that utilize electronic medical records systems, or other electronic administrative systems, which are conformant with the content exchange standard at 45 CFR 170.205(d)(2), recognizing that not all Medicare- and Medicaid-participating hospitals have been eligible for past programs promoting adoption of EHR systems. If the hospital’s (or CAH’s) system conforms to the content exchange standard at 45 CFR 170.205(d)(2), the hospital (or CAH) must then demonstrate that its system’s notification capacity is fully operational and that the hospital (or CAH) uses it in accordance with all state and federal statutes and regulations applicable to the hospital’s (or CAH’s) exchange of patient health information, and that its system (to the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient’s expressed privacy preferences) sends the notifications PO 00000 Frm 00100 Fmt 4701 Sfmt 4700 either directly, or through an intermediary that facilitates exchange of health information. It must also demonstrate that the notifications include at least patient name, treating practitioner name, and sending institution name. Upon the patient’s registration in the emergency department or admission to inpatient services, and also either immediately prior to, or at the time of, the patient’s discharge or transfer (from the emergency department or inpatient services), the hospital (or CAH) must also demonstrate that it has made a reasonable effort to ensure that its system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes: (1) The patient’s established primary care practitioner; (2) the patient’s established primary care practice group or entity; or (3) other practitioner, or other practice group or entity, identified by the patient as the E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations practitioner, or practice group or entity, primarily responsible for his or her care. These requirements will help support coordination of a patient’s care between settings or with services received through different care settings. Electronic patient event notifications from these care settings, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings. These notifications are typically automated, electronic communications from the admitting or discharging provider to applicable postacute care services providers and suppliers, and also to community practitioners identified by the patient, that alert the receiving providers or community practitioners that a patient is receiving, or has received, care at a different setting. These notifications are frequently based on ‘‘admission, discharge, and transfer (ADT)’’ messages, a standard message used within an EHR as the vehicle for communicating information about key changes in a patient’s status as they are tracked by the system (more information about the current standard supporting these messages is available at https://www.hl7.org/implement/ standards/product_brief.cfm?product_ id=144). As noted in the ISA published by ONC, this messaging standard has been widely adopted across the health care system (see https://www.healthit. gov/isa/sending-a-notification-apatients-admission-discharge-andortransfer-status-other-providers). We continue to believe that care coordination can have a significant positive impact on the quality of life, consumer experience, and health outcomes for patients. As we have noted in the preamble to this rule, virtually all EHR systems (as well as older legacy electronic administrative systems, such as electronic patient registrations systems, and which we are including in this final rule) generate information to support the basic messages commonly used for electronic patient event notifications. While we acknowledge that some level of implementation cost would be realized for those providers not already transmitting notifications, VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 we also note there is substantial agreement that implementation of these basic messaging and notification functions within such existing systems constitutes a relatively low cost burden for providers, particularly when such costs are considered alongside the innovative and beneficial patient care transition solutions and models for best practices they provide. Although we do not have current data on how many facilities are already transmitting electronic patient event notifications, 59 percent of hospitals were found to be routinely electronically notifying a patient’s primary care provider upon his or her entry to the hospital’s emergency department in 2015, which is an over 50 percent increase since 2012.68 By using this historical data to plot a power trend line (R-Squared: 0.9928), we estimate that approximately 71 percent of hospitals may have been routinely transmitting patient event notifications by 2018; therefore, we assume that 29 percent of hospitals, or approximately 1,392, will incur costs associated with updating or configuring their respective EHR systems for electronic patient event notifications. While we do not have parallel data for CAHs, we assume that a similar percentage, or approximately 394 CAHs, will incur this burden. We note that this upwards trend of patient event notification adoption may continue to some unknown extent absent this final rule; however, we are limiting our projection of hospitals that are most affected by these requirements to 2018 due to the amount of uncertainty involved in quantifying this burden. We assume that this process will primarily require the services of two medical records and health information technicians at approximately $42.32/ hour for 16 hours each, and 3 hours of time from a medical and health services manager at approximately $109.36/hour, including the costs of overhead and fringe benefits. Thus, the total burden 68 Office of the National Coordinator. (n.d.). Hospital Routine Electronic Notification: Percent of U.S. Hospitals that Routinely Electronically Notify Patient’s Primary Care Provider upon Emergency Room Entry, 2015. Retrieved from https:// dashboard.healthit.gov/quickstats/pages/FIGHospital-Routine-Electronic-Notification.php. PO 00000 Frm 00101 Fmt 4701 Sfmt 4700 25609 per facility is anticipated to be 35 hours, or approximately $1,682.32 ((16 hours * $42.32/hour * 2 health information technicians) + (3 hours * $109.36/hour * 1 manager)). We assume that the ongoing burden associated with maintenance of these systems would be approximately one quarter of these amounts for the 2 medical records and health information technicians, or 4 hours each, for a total of 8 hours and $338.56 per facility (4 hours * $42.32/ hour * 2 health information technicians). In this lower-bound scenario, we estimate that the total first-year burden for hospitals and psychiatric hospitals is approximately 48,720 hours (35 hours * 1,392 hospitals) or $2,341,789 ($1,682.32 * 1,392 hospitals). In subsequent years, we estimate the burden is approximately 11,136 hours (8 hours * 1,392 hospitals) or $471,276 ($338.56 * 1,392 hospitals). For CAHs we estimate that the total first-year burden is approximately 13,790 hours (35 hours * 394 CAHs) or $662,834 ($1,682.32 * 394 CAHs). In subsequent years, we estimate the burden for CAHs is approximately 3,152 hours (8 hours * 394 CAHs) or $133,393 ($338.56 * 394 CAHs). Due to the amount of uncertainty involved in these estimates, we are also presenting estimates for a scenario in which the number of hospitals that routinely electronically notify primary care providers both inside and outside of the hospital’s system is assumed to have remained static at the 2015 rate of 29 percent. This upper-bound scenario would indicate that in 2018 approximately 3,407 hospitals and 964 CAHs did not routinely utilize patient event notification, and therefore several thousand additional providers would incur the previously estimated burden per facility. For the purposes of the PRA, we are assuming the midpoint of this range of effects. In this scenario 2,400 hospitals and psychiatric hospitals, and 679 CAHs would incur the estimated burden. The burden estimates associated with the revised CoPs are detailed in Table 3. This information collection will be submitted to OMB under OMB Control Number 0938–New. E:\FR\FM\01MYR2.SGM 01MYR2 25610 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations TABLE 3—SUMMARY OF HOUR AND DOLLAR BURDEN BY NUMBER OF AFFECTED PROVIDERS Hospitals and psychiatric hospitals Subsequent years Year 1 Lower Bound ............................ Affected Providers .................... 48,720 $2,341,789.44 Affected Providers .................... Upper Bound ............................ 394 11,136 $471,275.52 13,790 $662,834.08 2,400 Total Burden (hours) ................ Total Cost ................................. 84,000 $4,037,568.00 Affected Providers .................... 19,200 $812,544.00 119,245 $5,731,664.24 3,152 $133,392.64 679 23,765 $1,142,295.28 3,407 Total Burden (hours) ................ Total Cost ................................. Subsequent years Year 1 1,392 Total Burden (hours) ................ Total Cost ................................. Primary Estimate ...................... CAHs 5,432 $229,882.24 964 27,256 $1,153,473.92 33,740 $1,621,756.48 7,712 $326,371.84 4. Summary of Information Collection Burdens TABLE 4—SUMMARY OF PRIMARY INFORMATION COLLECTION BURDENS Hourly labor cost of reporting ($) 960 16,800 34,560 5,796,000 $90.02 Varies 3,111,091 544,005,936 3,111,091 0 345 1,710 589,950 Varies .................... 54,391,527 2,400 2,400 35 84,000 Varies 4,037,568 .................... 0938–New ............ 2,400 2,400 8 19,200 Varies .................... 812,544 0938–New ............ 0938–New ............ 679 679 679 679 35 8 23,765 5,432 Varies Varies 1,142,295 .................... .................... 229,882.24 ............................... .................... 6,884 Varies 6,552,907 Varies 552,296,890 58,545,044 Number of respondents Number of responses OMB control No. § 423.910 ............... § 422.119, § 431.60, § 457.730, § 438.242, § 457.1233 and § 156.221. § 422.119, § 431.60, § 457.730, § 438.242, § 457.1233, and § 156.221. § 482.24(d) and § 482.61(f). § 482.24(d) and § 482.61(f). § 485.638(d) .......... § 485.638(d) .......... 0938–0958 * .......... 0938–New ............ 36 345 36 345 0938–New ............ 345 0938–New ............ Total ............... Burden per response (hours) Total labor cost 1st year ($) Total labor cost subsequent years ($) Total annual burden (hours) Regulation section(s) * This currently approved ICR will be revised to include the burden discussed in this rule. XIII. Regulatory Impact Analysis A. Statement of Need As described in detail in section III. of this rule, the changes to 42 CFR parts 422, 431, 438, 457, and 45 CFR part 156 are part of the agency’s broader efforts to empower patients by ensuring that they have full access to their own health care data, through common technologies and without special effort, while keeping that information safe and secure. Interoperability and the capability for health information systems and software applications to VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 communicate, exchange, and interpret data in a usable and readable format, such as PDF or text, is vital, but allowing access to health care data through PDF and text format also limits the utility and sharing of data. Moving to a system in which patients have access to their health care data will help empower them to make informed decisions about their health care, as well as share their data with providers who can assist these patients with their health care. The policies are designed to move Medicare, MA, Medicaid, CHIP, and QHP issuers on the FFEs further to PO 00000 Frm 00102 Fmt 4701 Sfmt 4700 that ultimate goal of empowering their enrollees. As technology has advanced, we have encouraged states, payers, and providers to adopt various forms of technology to improve the accurate and timely exchange of standardized health care information. The policies in this final rule enable patients to be active partners in the exchange of electronic health care data by easily monitoring or sharing their data. States and CMS routinely exchange data on who is enrolled in Medicare, and which parties are liable for paying that beneficiary’s Parts A and B E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations premiums. These ‘‘buy-in’’ data exchanges support state, CMS, and SSA premium accounting, collections, and enrollment functions. We have become increasingly concerned about the limitations of monthly buy-in data exchanges with states. The relatively long lag in updating buy-in data means that the state is not able to terminate or activate buy-in coverage sooner, so the state or beneficiary may be paying premiums for longer than appropriate. We note that once the data catch up, states and CMS reconcile the premiums by recouping and re-billing, so premiums collected are ultimately accurate, but only with an administratively burdensome process involving debits and payments between the beneficiary, state, CMS, SSA, and potentially providers. Daily buy-in data exchange will reduce this administrative burden. States submit data on files at least monthly to CMS to identify all dually eligible individuals, including fullbenefit and partial-benefit dually eligible beneficiaries (that is, those who get Medicaid help with Medicare premiums, and often for cost-sharing). The MMA file was originally developed to meet the need to timely identify dually eligible beneficiaries for the thennew Medicare Part D prescription drug benefit. Over time, we use these files’ data on dual eligibility status to support Part C capitation risk-adjustment, and most recently, feeding dual eligibility status to Part A and B eligibility and claims processing systems so providers, suppliers, and beneficiaries have accurate information on beneficiary cost-sharing obligations. As CMS now utilizes MMA data on dual eligibility status in systems supporting all four parts of the Medicare program, it is becoming even more essential that dual eligibility status is accurate and up-todate. Dual eligibility status can change at any time in a month. Waiting up to a month for status updates can negatively impact access to the correct level of benefit at the correct level of payment. As described in detail in section VII. of this rule, the changes to 42 CFR parts 406, 407, and 423 establish frequency requirements that necessitate all states to participate in daily exchange of buy-in data, and updates frequency requirements to require all states to participate in daily exchange of VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 MMA file data, with CMS by April 1, 2022. B. Overall Impact We have examined the impacts of this final rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96–354), section 1102(b) of the Social Security Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995; Pub. L. 104–4), Executive Order 13132 on Federalism (August 4, 1999), the Congressional Review Act (5 U.S.C. 804(2)), and Executive Order 13771 on Reducing Regulation and Controlling Regulatory Costs (January 30, 2017). Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Section 3(f) of Executive Order 12866 defines a ‘‘significant regulatory action’’ as an action that is likely to result in a rule: (1) Having an annual effect on the economy of $100 million or more in any 1 year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local or tribal governments or communities (also referred to as ‘‘economically significant’’); (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raising novel legal or policy issues arising out of legal mandates, the President’s priorities, or the principles set forth in the Executive Order. A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). We estimate that this rulemaking is ‘‘economically significant’’ as measured PO 00000 Frm 00103 Fmt 4701 Sfmt 4700 25611 by the $100 million threshold, and hence also a major rule under the Congressional Review Act. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of the rulemaking. Table 5 summarizes the estimated costs presented in section XII. of this final rule. In the proposed rule, we provided detailed estimations of the required labor categories and number of hours required to implement standards-based APIs (84 FR 7659). We originally estimated a one-time burden of $789,356 per organization or state, per implementation, with an ongoing maintenance cost $158,359.80 per organization or state (84 FR 7659). As we detailed in section XII., to account for additional information commenters presented regarding our costs estimates, we are adjusting our original cost estimates to reflect a range, instead of a point estimate. Our original estimate for the initial one-time cost to implement the API requirements of this final rule of $788,414 per organization will now serve as a minimum estimate. We have increased our primary cost estimate by a factor of 2 to an initial one-time cost of $1,576,829 per organization or state. Additionally, we are increasing our original cost estimate by a factor of 3 for an initial one-time cost of $2,365,243 per organization or state to serve as a high estimate (detailed cost estimates are located in Table 5). Table 5 reflects updated wages for 2018, the latest available from the Bureau of Labor Statistics (BLS) website; the CMS Interoperability and Patient Access proposed rule used 2017 wage estimates. Nevertheless, the change in total impact was small. We note that estimates below do not account for enrollment growth or higher costs associated with medical care. This is because the cost of requirements to implement patient access through APIs and for states to comply with data exchange requirements are not impacted by enrollment growth or higher costs associated with medical care. Per OMB guidelines, the projected estimates are expressed in constant-year dollars (in this case, using 2018 prices and wages). Table 5 forms the basis for allocating costs by year and program to the federal government, state Medicaid agencies, and parent organizations. E:\FR\FM\01MYR2.SGM 01MYR2 25612 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations TABLE 5—ESTIMATED COSTS (MILLIONS) OF FINAL RULE BY PROVISION Provision Dual eligible care coordination Regulatory text 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 § 406.26, § 407.40, § 423.910 Patient access API (low estimate) § 422.119, § 431.60, § 438.242, § 457.730, § 457.123, § 156.221 Patient access API (primary estimate) Patient access API (high estimate) Total cost (low estimate) Total cost (primary estimate) Total cost (high estimate) Months in year for compliance for dual eligible provisions Percent of 25 month window for compliance with dual eligible provisions ......... ......... ......... ......... ......... ......... ......... ......... ......... ......... 2.8 3.4 0.8 0.0 0 0.0 0.0 0.0 0.0 0.0 272.0 54.4 54.4 54.4 54.4 54.4 54.4 54.4 54.4 54.4 544.0 54.4 54.4 54.4 54.4 54.4 54.4 54.4 54.4 54.4 816.0 54.4 54.4 54.4 54.4 54.4 54.4 54.4 54.4 54.4 274.8 57.8 55.2 54.4 54.4 54.4 54.4 54.4 54.4 54.4 546.8 57.8 55.2 54.4 54.4 54.4 54.4 54.4 54.4 54.4 818.8 57.8 55.2 54.4 54.4 54.4 54.4 54.4 54.4 54.4 10 12 3 .................... .................... .................... .................... .................... .................... .................... 40 48 12 .................... .................... .................... .................... .................... .................... .................... Total .. 7.0 761.5 1033.5 1305.5 768.5 1040.5 1312.5 25.0 100 Note: Totals may not equal sum of parts due to rounding. Allocation of Cost Impact by Payer: As stated in section XII. of this final rule, cost estimates have been aggregated at the parent organization level because we believe that an organization that offers QHPs on the FFEs, Medicare, Medicaid, and CHIP products would create one system that would be used by all ‘‘plans’’ to whom it offers access to data via APIs. We note that due to the implementation of APIs across multiple business lines, there is no straightforward method to immediately estimate parent organization expenditures on how much of the cost is born by each payer. Although this section provides such estimates it is important to understand how they are arrived at. A summary by Table in this section is provided in Table 6. As shown in Table 6: • We first ascertain total costs of implementing this final rule by provision in (Table 5); • As indicated earlier, we have no straightforward way of ascertaining total costs by payer since we do not have internal data for each parent organization on how it allocates costs by program; • Therefore, to approximate costs we developed approximated proportions of total cost of each parent organization by payer (Medicare, Medicaid, CHIP, and Individual market, including individual market plans sold on and off the Exchanges, as we expect that, among parent organizations of issuers that offer QHPs on the FFEs, costs will be passed on through all plans the issuers offer in the individual market. Since this rule does not apply to QHP issuers offering QHPs only on Federally-facilitated Small Business Health Options Program Exchanges (FF–SHOPs) they were not included in our analysis. • Our use of available data includes many approximations due to data limitations discussed in detail below (Table 7); • Table 7 then allows us to obtain proportions of total costs for this final rule by payer (Table 8); • Since we know the way federal payments for both Medicare and Medicaid are calculated, we can then obtain total costs by payer incurred by the federal government (Table 9); • We next subtracted federal payments by payer (Table 9) from total costs by payer (Table 8) to obtain the non-federal costs of this final rule by payer (Table 10); • Table 11 presents the same data as Table 10; Table 10 presents total nonfederal costs per payer, while Table 11 presents average non-federal costs per enrollee per payer; • Table 12 presents the same data as Table 9; while Table 9 presents total costs to the federal government by payer, Table 12 presents average federal costs per enrollee by payer; and • Table 13 lists potential means for payers to deal with new costs. TABLE 6—OUTLINE OF THE FLOW OF LOGIC BY TABLE FOR THIS IMPACT ANALYSIS Table Content of table Comments on table 5 ........................................... Total costs by provision (API, Dual) ............................... 7 ........................................... Proportion of premiums by program (2016–2018) used, in later tables, as a proxy for proportion of cost by program. 8 ........................................... API costs total cost by year and Program (Medicare, Medicaid, Individual market plans, and CHIP). This total cost is divided by cost to the federal government (Table 9) and non-federal costs to plans and enrollees (Table 10). Costs are fully developed in the Collection of Information section of this final rule (section XII. of this final rule). There is no straightforward way to directly assess parent organization cost by payer. Therefore, for each payer we develop approximate percentages of cost per payer. We obtain the total API costs for this final rule per program by multiplying the API costs (for all programs) of this final rule (Table 5) by the proportion of premiums presented in Table 7. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00104 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25613 TABLE 6—OUTLINE OF THE FLOW OF LOGIC BY TABLE FOR THIS IMPACT ANALYSIS—Continued Table Content of table Comments on table 9 ........................................... Total costs incurred by the federal government by program and year. 10 ......................................... Non-federal total costs for API by program by year ....... 11 ......................................... Average non-federal cost per enrollee per year by program for plans. 12 ......................................... Average federal cost per enrollee per year by program for the federal government. 13 ......................................... How payers would defray the remaining costs ............... Based on how federal payments are calculated in Medicare and Medicaid, we have projected federal proportions of the total cost and these are applied to Table 8 to obtain Table 9. Table 9 = Table 8–Table 10—non-federal costs are obtained by subtracting federal costs (Table 9) from total costs (Table 8). Tables 11 and 10 present the same data in different forms. Table 10 presents total non-federal cost by program for states and plans, while Table 11 presents average non-federal costs per enrollee per year for states and plans. Tables 12 and 9 present the same data in different forms. Table 9 presents total cost to the federal government (due to matching programs), while Table 12 presents average cost per enrollee to the federal government. This table lists potential means for a plan to deal with extra costs. We have no way of predicting what will actually happen. Preliminary Estimates: This section provides several detailed estimates of cost by payer (Table 7); we also account for federal matching for Medicaid and payments by the Trust Fund for Medicare Advantage organizations (Table 9); we indicate remaining burden on plans (Tables 10, 11) and how they might account for it (Table 12). However, these estimates are approximate as explained in detail below. Data Sources for Cost by Payer: To obtain allocation of cost by payer we used the CMS public use files for MLR data, for 2016.69 The MLR data sets are for private insurance plans but the issuers of that private insurance in many cases also have contracts to provide MA, Medicaid, and CHIP managed care plans and report revenue, expense, and enrollment data for these plans on the private insurance MLR reporting form. Thus, these MLR data sets omit organizations that only have Medicare or Medicaid. The data from the CMS MLR files also omit: (1) The CHIP program; and (2) state Medicaid agencies. We now discuss these omissions to assess the accuracy of using these MLR files. CHIP: Eighty-five percent of the 194 CHIP managed care plans also offer Medicaid and hence are covered by the parent entity. We believe it reasonable that the remaining CHIP plans also have commercial offerings since it would be inefficient to operate a CHIP-only plan, 69 Center for Consumer Information and Insurance Oversight. (n.d.). Medical Loss Ratio Data and System Resources. Retrieved from https:// www.cms.gov/CCIIO/Resources/Data-Resources/ mlr.html. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 as the total national CHIP enrollment is currently only about 7 million. Similarly, except for one state, CHIP programs are run through the state Medicaid agency; again, there would be one interoperability cost for the one state agency since the resulting software and systems would be used both for Medicaid and CHIP. Thus, while we are leaving out CHIP programs in this analysis since they are not in the CMS MLR files, we do not believe this materially alters the overall picture. Medicare Advantage: We compared the CMS MLR files with the CMS Trustee Report.70 According to the Trustee Report (Table IV.C2), total MA revenue for 2016 was $189.1 billion. Thus, the reported amount in the CMS MLR files of $157 billion for MA represents 83 percent (157/189.1) of all MA activity reflected in the Trustee Report. Therefore, we believe the proportions obtained from these MLR files are accurate. Medicaid: For the year for which these MLR files provide data (2016), about 70 percent of Medicaid enrollees were enrolled in Medicaid managed care.71 Thus, although the MLR files 70 See Table IV.C2 in, Boards of Trustees (Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds). (2018, June 5). The 2018 Annual Report of The Boards of Trustees of the Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds. Retrieved from https://www.cms.gov/ResearchStatistics-Data-and-Systems/Statistics-Trends-andReports/ReportsTrustFunds/Downloads/ TR2018.pdf. 71 Centers for Medicare and Medicaid Services. (2018, November 8). CMS Proposes Changes to Streamline and Strengthen Medicaid and CHIP Managed Care Regulations. Retrieved from https:// www.cms.gov/newsroom/press-releases/cmsproposes-changes-streamline-and-strengthenmedicaid-and-chip-managed-care-regulations. PO 00000 Frm 00105 Fmt 4701 Sfmt 4700 omit state agencies, we believe that the 70 percent of Medicaid enrollees enrolled in Medicaid managed care provides a good approximation. Individual and small group market plans: The MLR files contain data on all commercial parent organizations whether these organizations have other lines of business, such as Medicare Advantage or Medicaid, or not. In discussing commercial plans, we account for: (A) Large group market plans; (B) small group market plans, including SHOP plans; (C) individual market Exchange plans; and (D) individual market off-Exchange plans. • We have carved out the large employer plans since the provisions of this final rule do not apply to them, and we do not believe that parent organizations would pass on costs for individual and small group market plans to large group employersponsored plans. • We have noted that the provisions of this final rule do not apply to QHP issuers offering QHPs only on FF– SHOPs, so we are not including small group market plans in this analysis. • We believe it is reasonable, that even though the provisions of this final rule do not apply to off-Exchange individual market plans, issuers subject to this rule offering QHPs on the FFEs will spread the cost to all plans issuers offer in the individual market. They will also likely offer the benefits of the APIs to all covered lives, as they can be marketed as a value add service, and it is logistically more challenging to offer a service to only a limited number of enrollees. • We estimate that off-Exchange plans offered by issuers who offer no QHPs on E:\FR\FM\01MYR2.SGM 01MYR2 25614 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations FFEs are about 7 percent of total individual market enrollment. Therefore, to the extent that we are including off-Exchange plans, the calculations below will be an approximation, but given this low proportion of off-Exchange-only issuers, we do not believe including them in this approximation will have a major impact. Best Estimates of Impact per Program and Payer: We present two methods to obtain an estimate of cost by program and payer, both for purposes of assessing impact on: (1) Small entities; (2) the federal government; (3) payers (states and plans); and (4) enrollees. We could assume costs proportional to current enrollment, or alternatively, we could assume costs proportional to total premium. For purposes of analyzing impact on small entities and impacts of the provision on the federal government, payers, plans, and enrollees we are using the method of assuming costs proportional to total premium (the method of assuming costs proportional to current enrollment will be used below to assess impact on transfers to enrollees). The CMS Interoperability and Patient Access proposed rule used 2016 CMS MLR files (84 FR 7662). Since its publication, 2017 and 2018 data have become available. However, we are only using these data to obtain proportions and, as Table 7 shows, the proportions for premiums have not changed significantly (only one quarter to one third percent for Medicare and Medicaid). Therefore, we retain and continue to use the 2016 proportions for purposes of this analysis with a note that they generally have remained constant. These proportions of premiums are being used as a proxy to approximate total cost. In the proposed rule we used the full $370 billion in commercial premium in determining our proportions (84 FR 7662). As discussed above, we are revising the estimates because upon further consideration, we have concluded that issuers in the commercial group markets are unlikely to spread the costs through increasing premium rates on those types of plans because issuers are not required to implement and maintain the API requirements of this final rule in the group markets and there are no indications that employer groups in these markets would be willing to pay for this provision through increased premium rates. Consequently, the $370 billion commercial premium is being reduced to $77 billion and the 76 million enrollees are being reduced to 17.5 million. As discussed above, the $370 billion (and 76 million enrollees) represented both individual and small group and large group market plans; the $77 billion and 17.5 million enrollees represent all individual market plans whether they are sold on and/or off-Exchange. We note that this reduction from our original estimate is due to the fact that most plans are large employer plans, and the individual market is only 20 to 23 percent of the full health insurance market. This refinement better aligns with the proportion of the market impacted by this final rule. Among issuers with products in both the individual market and MA or the individual market and Medicaid, the 2016 CMS MLR files show $77 billion reported in premium for individual market plans, $157 billion reported for MA, and $113 billion reported for Medicaid. Consequently, the proportion of interoperability cost for each of the programs is 22.19 percent (77/ (77+157+113)), 45.24 percent (157/ (77+157+113)), and 32.56 percent (113/ (77+157+113)) for individual market plans, MA, and Medicaid respectively. Table 7 shows similar proportions for 2017 and 2018. TABLE 7—PROPORTION OF PREMIUMS (IN BILLIONS) FOR MEDICARE, MEDICAID, AND INDIVIDUAL MARKET PLANS Year 2016 Premium (billions) ................................................................................... 2017 Premium (billions) ................................................................................... 2018 Premium (billions) ................................................................................... 2016 Percentage (used in this RIA in all estimates) of total costs by program ............................................................................................................. 2017 Percentage ............................................................................................. 2018 Percentage ............................................................................................. As indicated earlier, since cost allocation at the parent organization level and the allocations of each parent organization may differ by program (Medicare, Medicaid, CHIP, and Individual market plans) and is an Individual market plans Medicare Advantage Medicaid Totals 113 119.5 127 157 170.3 184 77 86 91 347 376 402 32.56% 31.78% 31.62% 45.24% 45.29% 45.81% 22.19% 22.93% 22.56% 100.00% 100.00% 100.00% internal business decision, we cannot directly assess per-payer costs. However, using the MLR tables, we can assess the proportions of cost by program. We can then multiply these proportions (as presented in Table 7) by the total costs of this final rule as presented in Table 5 to obtain Table 8, which breaks out the total column in Table 5, the total cost by year of implementing and maintaining the API, to offer API costs by year and program. TABLE 8—API COSTS (IN MILLIONS) BY YEAR AND PROGRAM Full implementation and maintenance costs (millions) (from Table 5) for API provision Year 2020 2020 2020 2021 2022 (Low estimate) ........................................................................ (Primary estimate) .................................................................. (High Estimate) ....................................................................... ................................................................................................. ................................................................................................. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00106 Fmt 4701 272.0 544.0 816.0 54.4 54.4 Sfmt 4700 Individual market plans (22.19%) Medicaid and CHIP (32.56%) 60.4 120.7 181.1 12.1 12.1 E:\FR\FM\01MYR2.SGM 88.6 177.2 265.7 17.7 17.7 01MYR2 Medicare Advantage (45.24%) 123.1 246.1 369.2 24.6 24.6 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25615 TABLE 8—API COSTS (IN MILLIONS) BY YEAR AND PROGRAM—Continued Full implementation and maintenance costs (millions) (from Table 5) for API provision Year 2023 2024 2025 2026 2027 2028 2029 Individual market plans (22.19%) Medicaid and CHIP (32.56%) Medicare Advantage (45.24%) ................................................................................................. ................................................................................................. ................................................................................................. ................................................................................................. ................................................................................................. ................................................................................................. ................................................................................................. 54.4 54.4 54.4 54.4 54.4 54.4 54.4 12.1 12.1 12.1 12.1 12.1 12.1 12.1 17.7 17.7 17.7 17.7 17.7 17.7 17.7 24.6 24.6 24.6 24.6 24.6 24.6 24.6 Total (Low Estimate) ................................................................ Total (Primary Estimate) ........................................................... Total (High Estimate) ................................................................ 761.5 1033.5 1305.5 169.0 229.3 289.7 248.0 336.6 425.1 344.6 467.6 590.7 Methods of Bearing Cost by Payer QHPs on the FFEs: Individual market plans have the option to deal with increased costs by either temporarily absorbing them (for purposes of market competitiveness), increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that issuers increase premiums for individual market plans on the FFEs, there would be federal premium tax credit (PTC) impacts. The purpose of the PTC is to assist enrollees in paying premium costs. Since PTCs are only available if an individual purchases an individual market plan on an Exchange, the PTC estimates apply only to Exchange plans. In the PTC estimate, we have accounted for the fact that some issuers have both Exchange and nonExchange plans, and some issuers have only non-Exchange plans. We reflected these assumptions with global adjustments, so we believe the estimates are reasonable in aggregate. Medicare Advantage: MA organizations may increase bids to reflect the costs of this final rule. Some of these expected increased bid costs may increase Medicare Trust Fund payments. For those (most) MA organizations whose bid amount is below the benchmark, the Trust Fund provides total expenditures to the MA organizations consisting of: (1) Full payment of the bid amount; and (2) the rebate, a portion of the difference between the benchmark and the bid amount. Since MA organizations are increasing their bid amounts to reflect the costs of this final rule, it follows that the rebate, equaling the difference between the benchmark and bid, is decreased, resulting in less rebates paid to the MA organizations. Based on our past experience and projections for the future, the rebate is estimated as 34 VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 percent of the difference between benchmark and bid. Thus, although the Trust Fund pays the bid in full, nevertheless, 66 percent of the increased bid costs arising from this final rule, are reduced from the rebates. The MA organizations in its submitted bid, can address this reduction of rebates by either: (1) Temporarily, for marketing purposes, absorbing the loss by reducing its profit margin; (2) reducing the supplemental benefits it provides the enrollee paid for by the rebate; or (3) raising enrollee premiums in order to provide supplemental benefits for which premiums are not paid by the rebate. The decision of what approach to use is an internal business decision in part motivated by unforeseen forces of marketing; we therefore have no way of predicting what will happen. Medicaid: State Medicaid agencies may be allowed to allocate the costs of state information retrieval systems between the costs attributable to design, development, installation, or enhancement of the system—at a 90 percent federal match—and for ongoing operations of the system—at a 75 percent federal match. For Medicaid managed care entities, we assume an MCO, PIHP, and PAHP cost for implementing the standardsbased API provisions would be built into the capitation rates and paid for by the state Medicaid agency, with the state Medicaid agency being reimbursed at the state’s medical assistance match rate. For purposes of these estimates we use the weighted FMAP, 58.44, which is based on our past experience with this program. Medicaid managed care costs constitute 52 percent of the Medicaid program costs.72 Consequently, for the first year (implementation year), the federal matching is (0.48*0.90+0.52*0.5844) of the total program costs, reflecting the 90 percent first year implementation matching for state agencies which comprise 48 percent of the program cost plus 58.44 percent matching for the Medicaid managed care plans which comprise 52 percent of the program costs. Similarly, for years after the first the federal costs are (0.48*0.75+0.52*0.5844) of total program costs. CHIP: Most states operate Medicaid and CHIP from the same state agency. One state is a notable exception in that it has a separate Medicaid and CHIP agency. The federal government pays an enhanced federal medical assistance percentage (EFMAP) to states for all costs associated with CHIP, including systems costs (this is unlike Medicaid where there are different FMAPs for different types of costs). For federal FY 2019, the EFMAPs will range from 88 to 100 percent. For federal FY 2020, the EFMAPs will range from approximately 76.5 to 93 percent. After federal FY 2020, the EFMAPs will range from approximately 65 to 81.5 percent. Since the CHIP program federal rebate ranges include the 90 percent and 75 percent federal matching proportions of the Medicaid program, we are applying the 90 percent and 75 percent from Medicaid to the CHIP programs. Since the CHIP program is small relative to the Medicaid program, we believe this approach reasonable. Table 9 uses these proportions to estimate the impact of the API on the federal government. For example, the $65.2 million cost to the federal government for Medicaid/CHIP for 2020 72 Allen, K. (2019, April 18). Medicaid Managed Care Spending in 2018. Retrieved from https:// www.healthmanagement.com/blog/medicaidmanaged-care-spending-in-2018/. PO 00000 Frm 00107 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25616 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations (low estimate), the implementation year of the API, is obtained by multiplying the total $88.6 million (low estimate) cost listed in Table 8 by (0.48*0.90+0.52*0.5844) the ratio indicated in the previous paragraphs. These assumptions on all first-year federal expenses are reflected in Table 9 which includes PTC payments as well as federal matching in Medicaid and Medicare. For PTC and Medicare we have assumed Federal payment in 2021. We note that we are not discussing at this point how parent organizations will bear these costs. This will be discussed below. However, the basis for the discussion is the calculation of nonfederal cost born by enrollees and plans which is obtained by subtracting federal costs from total costs. TABLE 9—COSTS INCURRED BY FEDERAL GOVERNMENT PROGRAM AND YEAR [In Millions] For individual market plans Year 2020 2020 2020 2021 2021 2022 2022 2023 2024 2025 2026 2027 2028 2029 For Medicaid CHIP For Medicare Advantage (Low estimate) .................................................................................................................... (Primary estimate) .............................................................................................................. (High Estimate) ................................................................................................................... (Low estimate) .................................................................................................................... (Primary Estimate) .............................................................................................................. (High Estimate) ................................................................................................................... ............................................................................................................................................. ............................................................................................................................................. ............................................................................................................................................. ............................................................................................................................................. ............................................................................................................................................. ............................................................................................................................................. ............................................................................................................................................. ............................................................................................................................................. 0.0 0.0 0.0 6.1 6.1 6.1 6.2 6.2 6.3 6.3 6.3 6.3 6.3 6.4 65.2 130.4 195.5 11.8 11.8 11.8 11.8 11.8 11.8 11.8 11.8 11.8 11.8 11.8 0.0 0.0 0.0 50.2 92.1 133.9 8.4 8.4 8.4 8.4 8.4 8.4 8.4 8.4 Total (Low Estimate) ............................................................................................................ 56.4 171.0 117.1 Total (Primary Estimate) ....................................................................................................... 56.4 236.2 159.0 Total (High Estimate) ............................................................................................................ 56.4 301.4 200.8 Note: The following percentages were applied to Table 8 to obtain Table 9: 0 percent for individual market plans, 34 percent for Medicare advantage plans and 0.48*0.90+0.52*0.5844 (1st year) and 0.48*0.75+0.52*0.5844 (later years) for Medicaid. Furthermore, as discussed above, federal payments to Medicare Advantage for implementation occurs fully in 2021. By taking the difference between the respective cells in Tables 8 (total costs by program) and 9 (total matching by the federal government), we obtain the remaining costs for the API for Medicare Advantage plans and for state Medicaid agencies. To this amount (which only deals with the API provisions) must be added the coordination cost for the dual eligible (column 3 of Table 5) multiplied by the proportion of costs presented in Table 7. This remaining cost born by Medicare Advantage plans and state Medicaid agencies is presented in Table 10. Since the federal government does not match QHP costs, the total cost for QHPs on the FFEs is born in its entirety by the plans. This also is listed in Table 10; however, in subtracting Table 9 from Table 8, we exclude PTC costs. These are federal costs, but unlike Medicare Advantage and Medicaid, the QHPs on the FFEs must account for the full cost of implementation. These PTC costs are not used to defray API costs. For example, Table 10 lists for 2020 (low estimate), Medicaid/CHIP a remaining cost to states of $24.3 million ($88.6 million total (low estimate) cost for 2020 (Table 8)¥$65.2 million matched by the federal government (Table 9) + ($2.8 million total cost for coordination of dual eligibles (Table 5) * 32.56 percent (proportion of total costs incurred by Medicaid/CHIP (Table 7)). (There are minor differences due to rounding.) TABLE 10—REMAINING COSTS BY PROGRAM FOR API BY YEAR [In millions] For individual market plans Year 2020 (Low estimate) .................................................................................................................... 2020 (Primary estimate) .............................................................................................................. 2020 (High Estimate) ................................................................................................................... 2021 (Low estimate) .................................................................................................................... 2021(Primary Estimate) ............................................................................................................... 2021 (High Estimate) ................................................................................................................... 2022 ............................................................................................................................................. 2023 ............................................................................................................................................. 2024 ............................................................................................................................................. 2025 ............................................................................................................................................. 2026 ............................................................................................................................................. 2027 ............................................................................................................................................. 2028 ............................................................................................................................................. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00108 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 61.0 121.3 181.7 12.8 12.8 12.8 12.3 12.1 12.1 12.1 12.1 12.1 12.1 01MYR2 For Medicaid/ CHIP 24.3 47.7 71.1 7.0 7.0 7.0 6.2 6.0 6.0 6.0 6.0 6.0 6.0 For Medicare Advantage 124.3 247.4 370.1 -24.1 -65.9 -107.8 16.6 16.2 16.2 16.2 16.2 16.2 16.2 25617 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations TABLE 10—REMAINING COSTS BY PROGRAM FOR API BY YEAR—Continued [In millions] For individual market plans Year For Medicaid/ CHIP For Medicare Advantage 2029 ............................................................................................................................................. 12.1 6.0 16.2 Total (Low Estimate) ............................................................................................................ 170.5 79.3 230.6 Total (Primary Estimate) ....................................................................................................... 230.9 102.6 311.8 Total (High Estimate) ............................................................................................................ 291.3 126.0 392.7 We next discuss in Tables 11 through 13 how payers and the federal government will deal with these extra costs. We also discuss whether the costs are excessive for existing plans as well as how new plans might deal with these costs. The further discussion of bearing these costs is illustrated by reformulating the costs in terms of costs per enrollee (per year), which is obtained by dividing the total cost to the payer for all programs in which it participates (Medicare, Medicaid, CHIP, and Individual market plans) by its total enrollment. As an example, if a payer hypothetically spent $1 billion in a year for 100,000 enrollees then the cost per enrollee per year is $10,000 ($1 billion/ 100,000). As can be seen from this example, the cost per enrollee metric facilitates comparison of costs. Since program expenditures for both Medicaid and MA are typically hundreds of millions (or billions) of dollars, concepts like burden and negligibility may not have intuitive meaning, as opposed to the costs per enrollee, which are more manageable and understandable. To provide background, the 2018 Medicare Trust Fund Report 73 states that costs per enrollee are projected to be roughly $12,000—$14,000 for contract years 2020—2023 (Table IV.C3). The costs per enrollee for the Medicaid program are similarly several thousand dollars. The estimates in the 2019 Medicare Trust Fund Report are identical.74 For purposes of indicating the cost per enrollee, we estimate 110.5 million enrollees will be affected by these provisions since currently there are 17.5, 66,75 20,76 and 7 77 million enrollees covered by payers in the individual market, Medicaid, MA, and separate CHIP programs, respectively. Table 11 presents costs per enrollee by program for payers after reducing total costs by federal matching, while Table 12 presents costs per enrollee by program for the federal government. For example, the 2020 (low estimate) cost per enrollee for commercial individual market plans is $3.48 (Table 11), which is obtained by dividing the total, 2020, low-estimate, non-federal, individual market plan cost of $61 million (Table 10) by 17.5 million enrollees. (This is based on the low estimate of cost for API; the high estimate of cost would be $10.38 = $181.7 million/17.5 million). The 2022 cost per enrollee for state Medicaid agencies after federal matching is 9 cents per enrollee (Table 11), which is obtained by dividing the total non-federal cost per program after federal matching, $6.2 million (Table 10) by 73 million enrollees (66 million in Medicaid + 7 million in CHIP). Each of these three calculations restates total spending per program per stakeholder (government, state Medicaid agencies, or Medicare Advantage plans) in terms of cost per enrollee. TABLE 11—AVERAGE COST PER ENROLLEE PER YEAR (DOLLARS AND CENTS) BY PROGRAM FOR PAYERS Individual market plans (17.5) Current enrollment by payer (millions) 2020 (Low estimate) .................................................................................................................... 2020 (Primary estimate) .............................................................................................................. 2020 (High Estimate) ................................................................................................................... 2021 (Low estimate) .................................................................................................................... 2021(Primary Estimate) ............................................................................................................... 2021 (High Estimate) ................................................................................................................... 2022 ............................................................................................................................................. 2023 ............................................................................................................................................. 2024 ............................................................................................................................................. 2025 ............................................................................................................................................. 73 Boards of Trustees (Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds). (2018, June 5). The 2018 Annual Report of The Boards of Trustees of the Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds. Retrieved from https://www.cms.gov/Research-Statistics-Data-andSystems/Statistics-Trends-and-Reports/Reports TrustFunds/Downloads/TR2018.pdf. 74 See page 154 in, Boards of Trustees (Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds). (2019, April 22). The 2019 Annual Report of The Boards of Trustees of the Federal Hospital Insurance and Federal VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Supplementary Medical Insurance Trust Funds. Retrieved from https://www.cms.gov/ResearchStatistics-Data-and-Systems/Statistics-Trends-andReports/ReportsTrustFunds/Downloads/ TR2019.pdf. 75 Centers for Medicare and Medicaid Services. (n.d.). October 2019 Medicaid & CHIP Enrollment Data Highlights. Retrieved from https:// www.medicaid.gov/medicaid/program-information/ medicaid-and-chip-enrollment-data/reporthighlights/. 76 Centers for Medicare and Medicaid Services. (n.d.). Monthly Contract Summary Report—August PO 00000 Frm 00109 Fmt 4701 Sfmt 4700 3.48 6.93 10.38 0.73 0.73 0.73 0.70 0.69 0.69 0.69 Medicaid plans (73) 0.33 0.65 0.97 0.10 0.10 0.10 0.09 0.08 0.08 0.08 Medicare Advantage plans (20) 6.22 12.37 18.51 -1.20 -3.30 -5.39 0.83 0.81 0.81 0.81 2018. Retrieved from https://www.cms.gov/ Research-Statistics-Data-and-Systems/StatisticsTrends-and-Reports/MCRAdvPartDEnrolData/ Monthly-Contract-and-Enrollment-SummaryReport-Items/Contract-Summary-2018-08.html? DLPage=1&DLEntries=10& DLSort=1&DLSortDir=descending. 77 Centers for Medicare and Medicaid Services. (n.d.). October 2019 Medicaid & CHIP Enrollment Data Highlights. Retrieved from https:// www.medicaid.gov/medicaid/program-information/ medicaid-and-chip-enrollment-data/reporthighlights/. E:\FR\FM\01MYR2.SGM 01MYR2 25618 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations TABLE 11—AVERAGE COST PER ENROLLEE PER YEAR (DOLLARS AND CENTS) BY PROGRAM FOR PAYERS—Continued Individual market plans (17.5) Current enrollment by payer (millions) Medicaid plans (73) Medicare Advantage plans (20) 2026 ............................................................................................................................................. 2027 ............................................................................................................................................. 2028 ............................................................................................................................................. 2029 ...................................................................................................................................... 0.69 0.69 0.69 0.69 0.08 0.08 0.08 0.08 0.81 0.81 0.81 0.81 Total (Low Estimate) ............................................................................................................ 9.7 1.1 11.5 Total (Primary Estimate) ....................................................................................................... 13.2 1.4 15.6 Total (High Estimate) ............................................................................................................ 16.6 1.7 19.6 TABLE 12—AVERAGE COST PER ENROLLEE PER YEAR (DOLLARS AND CENTS) BY PROGRAM FOR FEDERAL GOVERNMENT Individual market plans (17.5) Current enrollment by payer (millions) Medicaid plans (73) Medicare Advantage plans (20) 2020 (Low estimate) .................................................................................................................... 2020 (Primary estimate) .............................................................................................................. 2020 (High Estimate) ................................................................................................................... 2021 (Low estimate) .................................................................................................................... 2021(Primary Estimate) ............................................................................................................... 2021 (High Estimate) ................................................................................................................... 2022 ............................................................................................................................................. 2023 ............................................................................................................................................. 2024 ............................................................................................................................................. 2025 ............................................................................................................................................. 2026 ............................................................................................................................................. 2027 ............................................................................................................................................. 2028 ............................................................................................................................................. 2029 ............................................................................................................................................. 0.00 0.00 0.00 0.35 0.35 0.35 0.35 0.35 0.36 0.36 0.36 0.36 0.36 0.37 0.89 1.79 2.68 0.16 0.16 0.16 0.16 0.16 0.16 0.16 0.16 0.16 0.16 0.16 0.00 0.00 0.00 2.51 4.60 6.69 0.42 0.42 0.42 0.42 0.42 0.42 0.42 0.42 Total (Low Estimate) ............................................................................................................ 3.2 2.3 5.9 Total (Primary Estimate) ....................................................................................................... 3.2 3.2 7.9 Total (High Estimate) ............................................................................................................ 3.2 4.1 10.0 In Table 13, we explain possible ways payers may deal with these extra costs. We emphasize that Table 13 lists potential legal possibilities. What actually happens will depend on market dynamics and internal business decisions, and we have no straightforward way of predicting what these actual behaviors and responses will be. Individual Market Plans: As noted above, individual market plans have the option of absorbing costs or passing costs to enrollees either in the form of higher premiums or reduced benefits that are non-essential health benefits (EHBs). The average estimated cost per enrollee in 2021 through 2028 is under a dollar, which we assume issuers VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 would pass on to enrollees. However, for purposes of market competitiveness, it is possible that some of the 2020 average estimated cost of $3.48 per enrollee (low estimate) or $10.38 per enrollee per year (high estimate) would be absorbed by each QHP issuer on an FFE. Medicaid: State Medicaid agencies and CHIP are adding a cost under 10 cents per enrollee for 2021 through 2029. Total costs per enrollee for the Medicaid program are several thousand dollars. We note, the federal government is incurring costs capped at $2.68 per enrollee per year in 2020 and at 16 cents per enrollee per year in 2021 through 2029. Medicare Advantage: In their bids (submitted the June prior to the PO 00000 Frm 00110 Fmt 4701 Sfmt 4700 beginning of the coverage year), Medicare Advantage plans would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by either: (1) Temporarily absorbing costs by reducing profit margins; (2) reducing the supplemental benefits paid for by the rebates; or (3) raising enrollee cost sharing or premiums (however, we believe many plans for competitive reasons would chose to remain zero premium and either absorb losses for one year or reduce rebate-funded supplemental benefits in the amount per enrollee shown in Table 9). Table 13 summarizes these methods of bearing the remaining costs. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25619 TABLE 13—HOW PAYERS WOULD DEFRAY REMAINING COSTS Individual Market Plans ....................................... Medicaid/CHIP .................................................... Medicare Advantage (MA) .................................. PTC Impact: First, we note that there will be no impact on the expected 2020 PTC payment because 2020 premium rates were finalized last year, so even if issuers incur expenses that they did not anticipate when setting rates, they will not be able to reflect those expenses in the premium rates, and therefore, the expected PTC payments for 2020 will not change. Table 10 shows that for 2021 through 2029 the estimated impact to QHPs on the FFEs is a $12 million expense. This estimated $12 million expense burden represents an increase to annual FFE premium of approximately 0.03 percent. Within the FFE states, the estimated expense burden will impact premium rates in the individual market, and is spread across both Exchange and nonExchange QHPs. PTCs are only paid for QHPs offered through Exchanges, and are calculated as a function of the second lowest cost silver plan. Because of the wide variability of Exchange plans we make the simplifying assumption that the industry would increase the second-lowest-cost silver plan premium rate in the same amount as the overall premium rate increase as a result of the RIA expense estimate. We can then apply the overall rate increase to the projected PTC payments in the FFE states to estimate the impact to PTC payments. Therefore, we estimate that impact to PTCs in the FFE states will be approximately $6 million per year starting in 2021, which is about 0.02 percent of the total 2021 expected PTC payment in FFE states. Again, the calculated PTC impacts in 2021 through 2029 are included with all federal impacts in Table 9. We next summarize the public comments we received on our estimated impacts and provide our responses. Comment: Some commenters requested that the government share VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 Individual market plans generally have the option of absorbing costs (for example, for reasons of market competitiveness), increasing premiums to enrollees, or modifying cost-sharing or non-EHB covered benefits. Cost would be spread over all parent organization enrollees in a specified state and the individual market in FFE states. Small commercial individual market issuers seeking certification of plans as QHPs on the FFEs may request an exception to the API provisions. State Medicaid agencies would bear the cost (under 10 cents per enrollee). Medicaid plans are fully capitated but may have to defer first year costs. MA plans in their June-submitted bids would address the reduced rebates (arising from increased bid costs due to the increased costs of this final rule being included in the bid) by either: (1) Temporarily absorbing costs by reducing profit margins; (2) reducing additional benefits paid for by the rebates; or (3) raising enrollee cost sharing (however, many plans for competitive reasons would chose to remain zero premium and either absorb losses for one year or reduce additional, rebate-funded benefits in the amount per enrollee shown in Table 9). Tax deferment and amortization as applicable ameliorates cost. Capital costs are spread over entire parent organization enrollees. New plans are allowed to enter with initial negative margins with the expectation that they will stabilize over the first few years. more in the associated costs of the open, standards-based API implementation for both MA and Medicaid plans. These commenters noted that additional financial sharing by the federal government would help remedy offsets potentially being absorbed by the health plan that may result in decreased benefits and/or increase premiums. Medicare Advantage: Some commenters requested that the costs be included in MA bids. Other commenters recommended that if CMS is going to make specific technological requirements around implementation of the CMS Interoperability and Patient Access proposed rule then health plans should be allowed to include a percentage of these costs in their MA bids. One commenter recommended that CMS could consider adding a fixed dollar amount to MA bids if health plans complied with the requirements of the proposed rule, or CMS could add it into the bid tool. Medicaid: Similar comments were made for Medicaid plans. One commenter recommended that CMS provide states with a 100 percent federal matching to facilitate implementation and that state Medicaid agencies be required to include plan implementation costs into capitation rates. Another commenter requested that CMS require state Medicaid agencies to include a fixed amount of dollars or a percentage of implementation costs into plan administrative costs to remedy the cost impact of implementation. Response: We appreciate the commenters’ concerns and suggestions. As noted previously in this RIA, we have assumed traditional federal sharing of costs for both the MA and Medicaid programs. The results have been presented in Tables 9 through 12 with Table 13 indicating how payers and the federal government would defray costs. PO 00000 Frm 00111 Fmt 4701 Sfmt 4700 In Tables 11 and 12 the average estimated costs per enrollee (under $15) is compared with overall costs per enrollee (several thousand dollars). Additionally, we have been careful in our analysis to distinguish between federal matching to state Medicaid entities in the first year, federal matching to state Medicaid entities in later years, and federal matching of state payment of capitation rates to state Medicaid agencies. We take note that the commenter’s concerns for specific federal matching for the provisions of this final rule would require legislative action. Consequently, when writing the CMS Interoperability and Patient Access proposed rule, we did not believe it was necessary to propose additional federal spending beyond the already existing federal reimbursement to MA, Medicaid plans, and state agencies. Comment: A few commenters expressed concern that the CMS Interoperability and Patient Access proposed rule was not clear with regard to whether or not state Medicaid agencies would be allowed to allocate the costs of this implementation—at a 90 percent federal match—and for ongoing operations of the system—at a 75 percent federal match. Commenters requested that CMS provide clarity around the use of such language and exactness of ‘‘pay fors’’ since this is vital for state Medicaid agencies’ cost estimates in implementing the requirements of this rule. Response: We agree with the commenters. We therefore have revised the calculations to Table 10 to reflect the following more precise accounting of costs: (1) 90 percent of state Medicaid costs are paid or matched by the federal government in the first year of implementing new systems; (2) 75 percent of Medicaid costs are matched for maintenance costs; and (3) on average, state Medicaid agencies are E:\FR\FM\01MYR2.SGM 01MYR2 25620 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations matched 58.44 percent. We believe this heightened level of detail should satisfy commenter concerns. The revised numbers are reflected in Tables 10 and Table 11. Comment: One commenter noted that the developers of APIs may want additional fees to implement or provide access to their APIs. The commenter noted that these fees severely limit innovation in the marketplace for health IT solutions for storing and utilizing patient data, both on the patient and provider side of the equation. Response: The data that must be shared via the API under this policy are data that the payers have and must currently make available to patients. We also anticipate that many payers will develop the APIs in-house. If this commenter is more referencing the vendors creating apps, versus APIs for payers, we also do not believe it is appropriate to charge a fee, as discussed in section III. of this final rule. If fees are charged for certain apps, it is not the data that are generating the fee, it is the product or services; indeed, there is a logical connection between the potential benefits of this rule (facilitated by new or enhanced services) and nonquantified potential costs (possibly including those associated with the development or improvement of such services). Currently there are vendors that collect the publicly available directory data, clean these data, supplement these data, and offer this enhanced data product back to payers and providers. It is not the data the vendors are charging for as much as it is the service of cleaning and enhancing these data. Vendors may generate revenue from their third-party apps, but a major component of this is the service they are providing—building the app, making the data the patient directs to them most usable and valuable—that generates the revenue. Payers must already make these data available to patients. These data alone may also drive revenue, but it is the patient’s prerogative to provide their data to a third party in order to get a service in exchange Comment: A few commenters noted that RIA does not contain any costs for provider EHR connectivity. One commenter noted that EHR developers’ contracts with providers and health systems do not include the cost of system updates that will be required to comply with this proposal. Another commenter was concerned that EHR developers will charge providers significant fees to perform the updates required to comply with CMS’ proposals, and providers will likely need to make additional investments to VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 learn how to use standards-based APIs and other new technologies. Another commenter believes that for the clinical data to be available in any API, the CEHRT used by providers needs to be connected to a trusted exchange network. For many clinicians, the commenter noted the costs for connecting their CEHRT to a trusted network continues to remain a barrier. Response: To address commenters’ concerns with API connectivity to an EHR, we note that there is no requirement for a payer to link the Patient Access API to an EHR in this final rule, and there are associated challenges, as discussed elsewhere in this RIA, with attributing impacts to various interacting regulatory and other policies. Indeed, we do note that if a provider does elect to connect an EHR to the APIs finalized in this rule, they would be required to meet all the requirements of ONC’s Health IT Certification Program.78 As part of that program, the 2015 CEHRT includes, for example, ‘‘application access’’ certification criteria that requires health IT to demonstrate it can provide application access to the Common Clinical Data Set (CCDS) via an API.79 Furthermore, nearly a third of EHR vendors are also using the FHIR standard to meet 2015 CEHRT requirements.80 C. Anticipated Effects The RFA, as amended, requires agencies to analyze options for regulatory relief of small businesses, if a rule has a significant impact on a substantial number of small entities. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small governmental jurisdictions. The API requirements in this final rule affect: 1) QHP issuers on the FFEs, 2) MA organizations, including those that are also Part D sponsors of MA–PD plans, as well as 3) Medicaid MCOs with a minimum threshold for small business size of $41.5 million (https:// www.sba.gov/federal-contracting/ contracting-guide/size-standards). 78 Office of the National Coordinator. (2019, March 27). About the ONC Health IT Certification Program. Retrieved from https://www.healthit.gov/ topic/certification-ehrs/about-onc-health-itcertification-program. 79 Centers for Medicare and Medicaid Services. (n.d.). 2019 Promoting Interoperability Programs: 2015 Edition Certified EHR Technology Fact Sheet. Retrieved from https://www.cms.gov/Regulationsand-Guidance/Legislation/EHRIncentivePrograms/ Downloads/CEHRT2015Ed_FactSheet-.pdf. 80 Posnack, S. & Baker, W. (2018, October 1). Heat Wave: The U.S. is Poised to Catch FHIR in 2019. Retrieved from https://www.healthit.gov/buzz-blog/ interoperability/heat-wave-the-u-s-is-poised-tocatch-fhir-in-2019. PO 00000 Frm 00112 Fmt 4701 Sfmt 4700 Assessment of impact is complicated by the fact that costs have been aggregated at the parent organization level. A typical parent organization might have products with QHP issuers on the FFEs, MA, or Medicaid/CHIP programs. We have no way of directly assessing the size of parent organizations. Therefore, as a proxy, we analyze each payer separately. Medicare Advantage: We first assess the impact on MA plans. To clarify the flow of payments between these entities and the federal government, we note that MA organizations submit proposed plan designs and estimates of the amount of revenue necessary to cover the cost of those plan designs (called bids) by the first Monday in June of the year preceding the coverage year. Regulations governing this process are in 42 CFR part 422, subpart F. These bids must be broken down in the following: (1) The revenue requirements for providing Medicare Part A and Part B benefits with actuarially equivalent cost sharing (this is the ‘‘basic benefit bid’’); (2) The revenue requirements for providing supplemental benefits; (3) The revenue requirements for NonBenefit Expenses such as Sales & Marketing, Direct and Indirect Administration, Net Cost of Reinsurance, and Insurance Fees; and (4) For MA–PD plans, a Part D bid consistent with Part D regulations in 42 CFR part 423. These bids project payments to hospitals, providers and staff for covered benefits, as well as the cost of plan administration and profits. Because the API requirements finalized in this rule will apply to every MA plan and each MA plan must furnish at least the Medicare Part A and Part B benefits, the cost of the API will be built into the administrative component of the basic benefit bid. These bids in turn determine one component of the payments of the Medicare Trust Fund to the MA organizations who reimburse providers and subcontractors for their services. A second component of the Trust Fund payment to MA organizations are the rebates, which are a portion of the difference between the basic benefit bid compared to an administratively-set benchmark for the MA plan’s service area (currently, based on our past and projected experience, rebates vary by plan and are approximately 66 percent). Benchmarks are based on a formula using an estimate of the Medicare FFS per capita cost for the geographic area, which are adjusted to reflect the per capita cost of each county in the U.S. and its territories and adjusted for the enrollees’ health status E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations which is also known as the risk score. Payments from the Medicare Trust Funds for monthly capitation rates (for basic benefits) are capped at the benchmark; for basic benefit bids under the benchmark, a portion, currently approximately 66 percent, of the difference between the bid and benchmark is made available to the MA organization to either: (1) Pay for additional supplemental benefits; (2) include reductions in cost sharing in the plan design; or (3) provide buy-downs of Part B or Part D premiums. Basic benefit bids that are at or above the benchmark receive payment from the Trust Funds of the benchmark amount, with any excess charged to the enrollee as a premium. MA organizations are made aware of the benchmark through the annual CMS publication, ‘‘Announcement of Calendar Year [X] Medicare Advantage Capitation Rates and Medicare Advantage and Part D Payment Policies,’’ which, consistent with section 1853 of the Act, is released prior to MA organizations submission of bids. This publication of the benchmark when coupled with plan awareness that they will receive rebates if their plan bids fall below the benchmark facilitates that bids of most MA organizations are below the benchmark and consequently most MA organizations receive from the Trust Fund a total expenditure equaling payment for the bid plus the rebate. Because of these API provisions, we assume that MA organizations will be raising the June-submitted bid amount to reflect additional administrative costs. While the Trust Fund pays these bid amounts in full, the rebate goes down as the bid increases: That is, since the bid amount goes up, the rebate, equaling the difference between the benchmark and bid, decreases and results in less rebate payment to the MA organization. The MA organization has several options of dealing with these increased bid costs and reduced rebates: The MA organization might decide to: (1) Temporarily absorb the loss by reducing its profit margin (so as to reduce the bid amount and thereby increase the rebates); (2) reduce additional benefits paid to the enrollee from the rebates; or (3) raise enrollee premiums so as to compensate for the reduction of enrollee premium that would have happened if the bid had not been increased (note: for marketing purposes, many plans operate at zero premium, and we do not consider this third option a likely possibility). In this RIA, we have referred to options (2) and (3) (reduction of additional benefits and raising of enrollee premiums) as ‘‘passing the costs to the enrollee’’ so VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 that the ‘‘effect’’ of reduced rebates is fewer supplemental benefits or higher enrollee premiums than would have happened had the cost of the complying with the API provisions of this final rule not been imposed. There are various types of Medicare health plans, including MA HMOs, POS plans, and PPOs; Demonstration plans; Cost Plans; Prescription Drug Plans (PDP); and Programs of All-Inclusive Care for the Elderly (PACE) organization plans. This final rule affects MA HMOs, MA POS plans, and MA PPOs including those that are MA–PDs, but does not affect Cost Plans, stand-alone Prescription Drug Plans, nor PACE organizations. There are a variety of ways to assess whether MA organizations meet the $41.5 million threshold for small businesses. The assessment can be done by examining net worth, net income, cash flow from operations and projected claims as indicated in their bids. Using projected monetary requirements and projected enrollment for 2018 from submitted bids, approximately 30 percent of the MA organizations fell below the $41.5 million threshold for small businesses. Additionally, an analysis of 2016 data, the most recent year for which we have actual data on MA organization net worth, shows that approximately 30 percent of all MA organizations fall below the minimum threshold for small businesses. Medicaid: We next assess the impact on Medicaid managed care plans. Since Medicaid managed care plans receive 100 percent capitation from the state, we generally expect that the costs associated with the API provisions of this final rule, will be included in their capitation rates and may be reasonable, appropriate, and attainable costs whether they are a small business or not. QHP issuers on the FFEs: Based on the 2016 CMS MLR data, approximately 85 out of 494, or 17 percent of companies (that either had only individual market business, or had individual market plus Medicare and/or Medicaid business) had total premium revenue of less than $41,500,000. In other words, for MA, Medicaid, and QHP issuers on the FFEs, a significant number of small plans are affected. The RFA requires us to assess whether the rule has a significant impact on the plans, which we do next. If a rule has a substantial impact on a substantial number of small entities, the rule must discuss steps taken, including alternatives, to minimize burden on small entities. While a significant number (more than 5 percent) of not-for-profit organizations PO 00000 Frm 00113 Fmt 4701 Sfmt 4700 25621 and small businesses are affected by this final rule, the impact is not significant. To assess impact, we use the data in Table 5, which shows that the total raw (not discounted) net effect of this final rule over 10 years is $714 million. Medicare Advantage: We first assess impact on MA plans. Comparing the $714 million number to the total monetary amounts projected to be needed just for 2018, the most recent year on which we have finalized plan submitted bid data (and which is expected to be less than the need in future years including 2019), we find that that the impact of this final rule is significantly below the 3 percent–5 percent threshold for significant impact for MA plans. Medicaid: We next assess impact on Medicaid managed care plans. The total projected capitation payment and premiums for 2019 is projected to be $337.6 billion.81 Hence, the total cost of this final rule over 10 years, $714 million, is significantly below the 3 percent–5 percent threshold for significant impact to Medicaid managed care plans. QHP issuers on the FFEs: As discussed prior to Table 6 based on data in the public CMS MLR files, commercial health insurance issuers had premium revenue of $77 billion for individual market plan coverage in 2016. Therefore, the aggregate raw cost of this final rule over 10 years, $762 million (low estimate) and $1.3 billion (high estimate), is significantly below the 3 percent to 5 percent threshold for significant impact to commercial plans. We believe, that although a significant number of small plans under each program are affected by this rule, on average this impact is not significant. Additionally, we note that for those small entities that do find the cost of the provisions of this final rule burdensome, an exception process has been described in section III.C. of this final rule. Specifically, we note that we may provide an exceptions process through which the FFEs may certify health plans that do not provide patient access through a standards-based API, but otherwise meet the requirements for QHP certification. This process could apply for small issuers, issuers who are only in the individual or small group market, financially vulnerable issuers, or new entrants to the FFEs who demonstrate that deploying standards81 See ‘‘Capitation payments & premiums’’ in Table 17 of Appendix D in, Office of the Actuary (Centers for Medicare and Medicaid Services). (2016). 2016 Actuarial Report on the Financial Outlook for Medicaid. Retrieved from https:// www.medicaid.gov/medicaid/finance/downloads/ medicaid-actuarial-report-2016.pdf. E:\FR\FM\01MYR2.SGM 01MYR2 25622 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations based API technology consistent with the required interoperability standards would pose a significant barrier to the issuer’s ability to provide coverage to consumers, and not certifying the issuer’s QHP or QHPs would result in consumers having few or no plan options in certain areas. Consequently, the Secretary has determined that this final rule will not have a significant economic impact on a substantial number of small entities and the requirements of the RFA have been met. Please see our detailed analysis of apportionment of costs per payer in Tables 6 through 13 and section XIII.H. of this final rule for further details. In addition, section 1102(b) of the Act requires CMS to prepare an RIA if a rule may have a significant impact on the operations of a substantial number of small rural hospitals. This analysis must conform to the provisions of section 604 of the RFA. For purposes of section 1102(b) of the Act, we define a small rural hospital as a hospital that is located outside a Metropolitan Statistical Area and has fewer than 100 beds. We are not preparing an analysis for section 1102(b) of the Act because we have determined, and the Secretary certifies, that this final rule would not have a significant impact on the operations of a substantial number of small rural hospitals. Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (Pub. L. 104–04, enacted March 22, 1995) also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates, except those that are conditions of federal program participation, require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2020, that is approximately $156 million. This rule does not impose any such unfunded mandates. Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on state and local governments, preempts state law, or otherwise has federalism implications. This final rule will not have a substantial direct effect on state or local governments, preempt state law, or otherwise have a federalism implication. Therefore, the requirements of Executive Order 13132 are not applicable. If regulations impose administrative costs, such as the time needed to read and interpret this final rule, we should estimate the cost associated with regulatory review. There are currently VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 288 organizations and 56 states and territories. We assume each organization will have one designated staff member who will read the entire rule. Using the wage information from the BLS for medical and health service managers (Code 11–9111), we estimate that the cost of reviewing this rule is $139.14 per hour, including overhead and fringe benefits (https://www.bls.gov/ oes/current/naics5_524114.htm). Assuming an average reading speed, we estimate that it would take approximately 6 hours for each person to review this final rule. For each payer that reviews the rule, the estimated cost is $834.84 (6 hours × $139.14). Therefore, we estimate that the total cost of reviewing this regulation is $288,020 ($834.84 × 345 reviewers). 1. Requirements for Patient Access Through APIs To promote our commitment to interoperability, we are implementing new requirements in section III. of this final rule for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, Medicaid managed care at 42 CFR 438.242, CHIP FFS at 42 CFR 457.730, CHIP managed care at 42 CFR 457.1233, and QHP issuers on the FFEs, excluding QHP issuers offering only SADPs or only FF–SHOP plans, at 45 CFR 156.221 to implement standardsbased APIs for making certain data available to current enrollees. The Patient Access API will permit thirdparty applications to retrieve data concerning adjudicated claims, encounters with capitated providers, provider remittances, patient costsharing, a subset of clinical data including lab test results, if maintained by the payer, and, preferred drug lists, and for MA–PD plans only, formulary data that includes covered Part D drugs, and any tiered formulary structure or utilization management procedure, which pertains to those drugs for MA– PD plans. At 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for state Medicaid agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed care entities, we are finalizing the Provider Directory API. We believe that these policies are designed to empower patients by requiring that impacted payers take steps—by implementing the two required APIs—to enable enrollees to have access to their data in a usable digital format and have (potentially) easier means to share that data. By making these data readily available and portable to the patient, these initiatives PO 00000 Frm 00114 Fmt 4701 Sfmt 4700 may help patients have the ability to move from payer to payer, provider to provider, and have both their clinical and administrative information travel with them throughout their health care journey. Payers are in a unique position to provide enrollees with a comprehensive picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. This information can contribute to better informed decision making, helping to inform the patient’s choice of coverage options and care providers to more effectively manage their own health, care, and costs. By encouraging them to take charge of and better manage their health and having access to their health information, patients will have the ability to share this information with their other providers, which may reduce duplication of services, add efficiency to provider visits, and facilitate identification of fraud, waste, and abuse. To estimate the number of impacted payers, we reviewed parent organizations of health plans across MA organizations, Medicaid MCOs, and QHP issuers on the FFEs to remove organizations that would not be subject to the policy, such as issuers that offer only SADPs; transportation plans, and brokers such as non-emergency medical transportation (NEMTs) brokers; PACE; visiting nurse and home health care organizations; senior organizations such as Area Agencies on Aging; and other organizations such as community action programs. After removing these organizations, we then reviewed the remaining names of parent organizations and health plans in the National Association of Insurance Commissioners (NAIC) Consumer Information Support (CIS) system to determine the legal name of the entity and whether the entity was registered with the NAIC. We also used the 2018 NAIC Listing of Companies to determine whether various health plans had associated parent organizations using the NAIC’s Group coding and numbering system. If the health plan or parent organization did not appear in the NAIC CIS or in the 2018 NAIC Listing of Companies, we then reviewed the name of the entity in the Securities and Exchange online Edgar system to locate the entity’s Form 10–K filing, which includes an Exhibit (Exhibit 21) that requires the entity to list its subsidiaries. If the health plan or organization did not appear in these online systems or listings, an online internet search using Google search E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations engine was conducted. After review, we have determined that 288 issuers and 56 states, territories, and U.S. commonwealths, which operate FFS programs, will be subject to the API provisions for Medicare, Medicaid, and QHP issuers on the FFEs. To this we add the one state that operates its CHIP and Medicaid separately. Thus, we have a total of 345 parent organizations (288+56+1). We note that although 42 states have some lower-income children in an expansion of Medicaid, and some higher-income children or pregnant women in a separate CHIP, all but one of these programs are operated out of the same agency. Although the CHIP programs may be distinct, we believe they will use the same infrastructure built for Medicaid. Thus, the addition of 1 parent organization for CHIP is reasonable and plausible. As noted in section XII.C.3. of this final rule, to implement the Patient Access API together with the payer-topayer data exchange policies to facilitate a payer maintaining a cumulative health record for their current enrollees, we estimated that organizations and states would conduct three major work phases: Initial design; development and testing; and long-term support of the APIs, including increased data storage, such as additional servers, or cloud storage to store patient health information and maintain it, and allocation of resources to maintain the FHIR server, and perform capability and security testing. (For a detailed description of these phases, see section XII.C.3. of this final rule.) As part of our research into the regulatory impact, we reviewed a sample of health plan organizations offering MA plans to determine whether any currently offer patient portal functionality with the MA plan. If yes, we reviewed whether they offered the opportunity to connect to Medicare’s Blue Button 2.0. Health plan organizations offering MA plans were identified from June 2018 data and statistics compiled at https:// www.cms.gov/Research-Statistics-Dataand-Systems/Statistics-Trends-andReports/MCRAdvPartDEnrolData/ index.html. We initially reviewed the functionality offered by three organizations, which together enroll over half of MA members through review of publicly-available information such as press releases and website informational materials. We found from this review that these organizations not only offered patient portals primarily focused on claims and user-entered data on their website, but that all three also offered enrollees the opportunity to connect to Blue Button. We then VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 identified a selection of other health plan organizations at random and conducted the same evaluation. Results indicate that the majority of the health plan organizations we reviewed offer patients a way to access claims data and other information via their websites and sometimes via applications. We also cross-referenced health plan organizations offering MA plans with health plan organizations that offer plans in the Federal Employees Health Benefits (FEHB) Program because a percentage of those organizations offer plans with patient portal access and Blue Button functionality. The FEHB Program, administered by the Office of Personnel Management (OPM), reported in 2014 that 90 percent of its participating plans offered enrollees access to a personal health record on the organization’s website. In addition, OPM reported that over half of the FEHB participating plans expected to offer Blue Button functionality by January 1, 2016. We sought to learn whether there was any overlap between these two lists of organizations to gauge whether additional organizations may already have the capability to offer either patient portals or Blue Button, albeit in a different business arm, as having internal capability may assuage some of the cost of building out a new API to support patient access to claims data. While we found significant overlap between UnitedHealthcare and the Blue Cross Blue Shield Affiliates, we also were able to identify other organizations that offer both MA plans and plans included in the FEHB. While not definitive, this data allows us to draw the conclusion that a number of health plan organizations have the technology in place to offer patient portals to MA enrollees and, further, also have the ability to offer MA enrollees Blue Button functionality. As detailed in section XII. of this final rule and summarized in Table 5, given the current state of interoperability, we estimate the burden related to the new requirements for APIs to have an initial set one-time costs of $788,414 per implementation or an aggregate cost of $272 million ($788,414 × 345 parent organizations) minimum estimate; an initial one-time cost of $1,576,829 per organization or state or an aggregate cost of $544 million ($1,576,829 × 345 parent organizations) primary estimate; and, an initial one-time cost of $2,365,243 per organization or organization or an aggregate $816 million ($2,365,243 × 345 parent organizations) high estimate. For a detailed discussion of the onetime costs associated with implementing the API requirements we refer readers to section XII.C.3. of this PO 00000 Frm 00115 Fmt 4701 Sfmt 4700 25623 final rule. Once the API is established, we believe that there will be an annual cost for performing necessary capability and security testing, performing necessary upgrades, vetting of thirdparty applications, and maintaining patient health information. We estimate the burden related to the requirements for APIs to have an annual cost of $157,657 per implementation or an aggregate cost of $54 million (345 parent organizations × $157,657). For a detailed discussion of the annual costs associated with implementing the API requirements, we refer readers to section XII.C.3. of this final rule. We are committed to fulfilling our role in promoting interoperability, putting patients first and ensuring they have access to their health care data. We recognize that there are significant opportunities to modernize access to patient data and its ability to share across the health ecosystem. We realize the importance of interoperability and the capability for health information systems and software applications to communicate, exchange, and interpret data in a usable and readable format. Although allowing access to health care data through pdf and text format is vital, it limits the utility of the data, and its ability to be easily accessed and shared. Additionally, we realize that moving to a system in which patients have access to their health care data will ultimately empower them to make informed decisions about their health care. Our policies here do not go as far as our goals for how patients will be ultimately empowered, but take steps in that direction. We note that the federal government has spent over $35 billion under the EHR Incentive Programs 82 to incentivize the adoption of EHR systems; however, despite the fact that 78 percent of physicians and 96 percent of hospitals now use an EHR system,83 progress on system-wide data sharing has been limited. Previous attempts to advance interoperability have made incremental progress but have failed to align the necessary stakeholders to drive momentum in a single direction. In 2018, the Administration launched the 82 Centers for Medicare and Medicaid Services. (2018, May). EHR Incentive Program, Payment Summary Report. Retrieved from https:// www.cms.gov/Regulations-and-Guidance/ Legislation/EHRIncentivePrograms/Downloads/ May2018_SummaryReport.pdf. 83 Office of the National Coordinator. (2015). Health IT Dashboard—Office-based Physician Health IT Adoption: State rates of physician EHR adoption, health information exchange & interoperability, and patient engagement. Retrieved from https://dashboard.healthit.gov/apps/ physician-health-it-adoption.php. E:\FR\FM\01MYR2.SGM 01MYR2 25624 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations MyHealthEData initiative.84 This government-wide initiative aims to empower patients by ensuring that they have access to their own health care data and the ability to decide how their data will be used, while keeping that information safe and secure. MyHealthEData aims to break down the barriers that prevent patients from gaining electronic access to their health care data and allow them to access that data from the device or application of their choice that will connect to a plan’s API, empowering patients and taking a critical step toward interoperability and patient data exchange. Payers should have the ability to exchange data instantly with other payers for care coordination or transitions, and with providers to facilitate more efficient care. Payers are in a unique position to provide enrollees a complete picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. We are committed to solving the issue of interoperability and achieving complete patient access in the U.S. health care system and are taking an active approach using all available policy levers and authorities available to move all participants in the health care market toward interoperability and the secure exchange of health care data. The modern internet app economy thrives on a standardsbased API software environment. Part of the health care API evolution is incorporating many of the current protocols from leading standards development organizations with the newer FHIR web developer-friendly way of representing clinical data. 2. Increasing the Frequency of FederalState Data Exchanges for Dually Eligible Individuals We routinely exchange data with states on who is enrolled in Medicare, and which parties are liable for paying that beneficiary’s Part A and B premiums. These buy-in data exchanges support state, CMS, and SSA premium accounting, collections, and enrollment functions. CMS subregulatory guidance, specifically Chapter 3 of the State Buyin Manual, specifies that states should exchange buy-in data with CMS at least monthly, but provides the option for states to exchange buy-in data with CMS daily or weekly. Likewise, states can 84 Centers for Medicare and Medicaid Services. (2018, May 6). Trump Administration Announces MyHealthEData Initiative to Put Patients at the Center of the US Healthcare System. Retrieved from https://www.cms.gov/Newsroom/MediaRelease Database/Press-releases/2018-Press-releases-items/ 2018-03-06.html. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 choose to receive the CMS response data on a file daily or monthly. We are establishing the frequency requirements in the regulation itself to require all states to participate in daily exchange of buy-in data to CMS, with ‘‘daily’’ meaning every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. States will be required to begin participating in daily exchange of buyin data with CMS by April 1, 2022. To estimate impact, we first note that there are a total of 51 entities, consisting of the 50 states and the District of Columbia that can be affected by buy-in. Currently, 25 entities (24 states and the District of Columbia) now submit buyin data files to CMS daily and 32 entities (31 states and the District of Columbia) receive buy-in data files from CMS daily. Consequently, we expect a one-time burden for 26 states (51 total entities minus 25 entities currently submitting daily buy-in data) to comply with the daily buy-in data submissions, and a similar one-time burden for 19 states (51 total entities minus 32 entities currently receiving buy-in data) to comply with the receipt of daily buy-in data. These numbers changed from those in the CMS Interoperability and Patient Access proposed rule to reflect the most current data available to CMS as of July 1, 2019. Between July 1 and publication of the final rule it is likely that the numbers may change more. However, as can be seen from Table 5, this aspect of the rule has minor impact (only a few million dollars) compared with the overall impact of the rule (several hundred million). Consequently, we are using these July 1 numbers in the final rule. We estimate that each required change, whether to submit buy-in data or receive buy-in data, would take 6 months of work (approximately 960 hours) by a programmer working at an hourly rate of $90.02 per hour. Since there are 45 required changes (19 states that need to comply with receiving data plus 26 states that need to comply with submitting data) we estimate an aggregate burden of $3,888,864 (45 changes * 960 hours of programming work * $90.02/hour). The cost per state per change is approximately $85,000 (960 * $90.02 = $86,419 exactly) and the costs for both changes (to both send and receive buyin data daily would be approximately $170,000 (2 * $85,000). We did not estimate any savings related to exchanging buy-in data with greater frequency, as data lags only delay when states are billed for PO 00000 Frm 00116 Fmt 4701 Sfmt 4700 premium costs; delays do not impact the applicability date and total costs. While we did not estimate premium savings (since premium collection is ultimately correct), we anticipate that states may experience longer term reduction in administrative burden of making those corrections. As noted in section XII.C. of this final rule, we are updating the frequency requirements in 42 CFR 423.910(d) to require that starting April 1, 2022, all states submit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily would mean every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. As noted in section XII.C. of this final rule, the estimated burden across impacted states is $3,111,091. Thus, the total burden to comply with increased frequency of submission of MMA files and increased frequency of submission and receipt of daily buy-in data files is $7 million ($3,888,864 total cost for the buy-in provision plus $3,111,091 total cost for the MMA file requirements). We estimate a 25-month implementation period for these system updates, from March 2020 to and including March 2022. In the CMS Interoperability and Patient Access proposed rule, we assumed a 3-year implementation period reflecting a May 1st start date and an April 1, 2022 applicability date. The revised 25month implementation period reflects an expected publication of this final rule in March 2020, with implementation beginning March 2020, and with the applicability date of April 1, 2022 unchanged. Although the implementation period is shorter (25 months versus 36 months) the purpose of the 25-month window is to give organizations flexibility in finding a 6month period to perform updates as indicated in section XII. of this final rule. Although the flexibility window for this 6-month period is shortened (plans have less choice of which 6 months to work in), data are lacking with which to refine the cost estimates to reflect the shortened compliance period. States will have the ability to choose, in consultation with CMS, when in the 25-month implementation period they want to make this change, with numerous factors impacting in which year they would do so. For the purposes of this impact analysis, we estimated a uniform distribution beginning in March 2020 and ending in April 2022 as calculated in Table 5. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Therefore, since, as noted above, the total cost impact over 25 months is $7 million, when apportioned uniformly over the 25 months, the resulting impacts $2.8, $3.4, and $0.8 million for 2020, 2021, and 2022 respectively corresponding to 10 months, 12 months, and 3 months in 2020, 2021 and 2022 respectively. These calculations are transparently presented in Table 5. 3. Revisions to the Conditions of Participation for Hospitals and Critical Access Hospitals (CAHs) We are expanding CMS’ requirements for interoperability within the hospital and CAH CoPs by focusing on electronic patient event notifications. We are implementing new requirements in section X. of this final rule for hospitals at 42 CFR 482.24(d), for psychiatric hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638(d). Specifically, for hospitals, psychiatric hospitals, and CAHs, we are finalizing similar requirements to revise the CoPs for Medicare- and Medicaidparticipating hospitals, psychiatric hospitals, and CAHs by adding a new standard, ‘‘Electronic Notifications,’’ that will require hospitals, psychiatric hospitals, and CAHs to make electronic patient event notifications available to applicable post-acute care services providers and suppliers, and to community practitioners, such as the patient’s established primary care practitioner, established primary care practice group or entity, or other practitioner or practice group or entity identified by the patient as primarily responsible for his or her care. We are limiting this requirement to only those hospitals, psychiatric hospitals, and CAHs that utilize electronic medical records systems, or other electronic administrative systems, which are conformant with the content exchange standard at 45 CFR 170.205(d)(2), recognizing that not all Medicare- and Medicaid-participating hospitals have been eligible for past programs promoting adoption of EHR systems. If the hospital’s (or CAH’s) system conforms to the content exchange standard at 45 CFR 170.205(d)(2), the hospital (or CAH) must then demonstrate that its system’s notification capacity is fully operational and that it operates in accordance with all state and federal statutes and regulations regarding the exchange of patient health information, and that its system, to the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient’s expressed privacy preferences, sends the notifications either directly, or through an VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 intermediary that facilitates exchange of health information. It must also demonstrate that the notifications include at least patient name, treating practitioner name, and sending institution name. Upon the patient’s registration in the emergency department or admission to inpatient services, and also either immediately prior to, or at the time of, the patient’s discharge or transfer (from the emergency department or inpatient services), the hospital (or CAH) must also demonstrate that it has made a reasonable effort to ensure that its system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes: (1) The patient’s established primary care practitioner; (2) the patient’s established primary care practice group or entity; or (3) other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care. As we noted, infrastructure supporting the exchange of electronic health information across settings has matured substantially in recent years. Research studies have increasingly found that health information exchange interventions can effectuate positive outcomes in health care quality and public health outcomes, in addition to more longstanding findings around reductions in utilization and costs. Electronic patient event notifications from hospitals, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings, especially for patients at discharge. This approach has been identified with a reduction in readmissions following implementation.85 In addition, the CMS Innovation Center has been partnering with states through the State Innovation Models Initiative to advance multi-payer health care payment and delivery system reform models. Through this initiative 34 states have been awarded over $900 million to implement their respective State Health Care Innovation Plans, many of which included enhancements 85 Unruh, M. A., Jung, H., Kaushal, R., & Vest, J. R. (2017). Hospitalization event notifications and reductions in readmissions of Medicare fee-forservice beneficiaries in the Bronx, New York. Journal of the American Medical Informatics Association, 24(e1), e150–e156. doi: 10.1093/jamia/ ocw139. PO 00000 Frm 00117 Fmt 4701 Sfmt 4700 25625 in HIT and HIE. While these models are ongoing, evaluation reports thus far are reporting that many states are experiencing favorable outcomes on ED visit rates and other quality measures.86 Although patient event notifications are only a small piece of these models, we want to continue the momentum towards nationwide adoption. These notifications are automated, electronic communications from the provider to applicable post-acute care services providers and suppliers, and also to community practitioners identified by the patient. These automated communications alert the receiving provider or practitioner that the patient has received care at a different setting. Information included with these notifications can range from simply conveying the patient’s name, basic demographic information, and the sending institution, to a richer set of clinical data depending upon the level of technical implementation. Even with a minimum set of information included, these notifications can help ensure that a receiving provider or community practitioner is aware that the patient has received care elsewhere. The notification triggers a receiving provider or practitioner to reach out to the patient to deliver appropriate follow-up care in a timely manner. By providing timely notifications, the alert may improve post-discharge transitions and reduce the likelihood of complications resulting from inadequate follow-up care. We believe that care coordination can have a significant positive impact on the quality of life, consumer experience, and health outcomes for patients. As we have noted in the preamble to this rule, virtually all EHR systems (as well as older legacy electronic administrative systems, such as electronic patient registrations systems, and which we are including in this final rule) generate the basic messages commonly used to support electronic patient event notifications. In addition, while we acknowledge that some level of implementation cost would be realized for those providers not already sending notifications, we also note there is also substantial agreement that implementation of these basic messaging and notification functions within such existing systems constitutes a relatively low cost burden for providers, particularly when such costs are considered alongside the innovative and beneficial patient care transition 86 Centers for Medicare and Medicaid Services. (2019, December 6). State Innovation Models Initiative: General Information. Retrieved from https://innovation.cms.gov/initiatives/StateInnovations/. E:\FR\FM\01MYR2.SGM 01MYR2 25626 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations solutions and models for best practices they provide. As detailed in section XI., we estimate that the total cost imposed on hospitals, psychiatric hospitals, and CAHs by these provisions to be approximately $5,179,863 in the first year and $1,042,426 in subsequent years. 4. Effects of Other Policy Changes In addition to those policy changes discussed previously that we are able to model, we are finalizing various other changes in this final rule. Generally, we have limited or no specific data available with which to estimate the impacts of the policy changes. Our estimates of the likely impacts associated with these other changes are discussed in this section. a. Care Coordination Across Payers The majority of the 64 million people on Medicare are covered by FFS, however, about 34 percent are covered in MA plans. Since 2003, the number of beneficiaries enrolled in MA plans has increased fivefold from 4.6 million in 2010 to 22 million in 2019.87 Given the growth in MA enrollment and the ability for MA beneficiaries to change plans, we believe it is important to supporting efficient care coordination by requiring the sharing of key patient health information when an enrollee requests it. Therefore, we are requiring MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard finalized by HHS in the ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register) at 45 CFR 170.213 (currently version 1 of the USCDI), via a payer-to-payer data exchanged as outlined in this section V. of this final rule. Furthermore, we are finalizing as proposed a regulatory requirement at 42 CFR 422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to require MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to incorporate the data they receive into the payer’s record about the enrollee. We are also finalizing that with the approval and at the direction of an enrollee, a payer must send the defined information set to any other payer. We specify that a payer 87 Medicare Payment Advisory Commission. (2019, July 19). A Data Book: Health Care Spending and the Medicare Program—June 2019. Retrieved from https://www.medpac.gov/docs/default-source/ data-book/jun19_databook_entirereport_ sec.pdf?sfvrsn=0. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 is only obligated to send data received from another payer under this policy in the electronic form and format it was received. However, we have noted that such transactions will need to be made in compliance with any other applicable laws. We believe that sending and receiving these data will help both plan enrollees and health care providers in coordinating care and reducing administrative burden. We believe that this entails utilizing all tools available to us to ensure that plans provide coordinated high-quality care in an efficient and cost-effective way that protects program integrity. Leveraging interoperability to facilitate care coordination among plans can, with thoughtful execution, significantly reduce unnecessary care, as well as ensure that health care providers are able to spend their time providing care rather than performing unnecessary administrative tasks. For instance, effective information exchange between plans could improve care coordination by reducing the need for health care providers to write unneeded letters of medical necessity; by reducing instances of inappropriate step therapy; and by reducing repeated utilization reviews, risk screenings, and assessments. We believe that this policy will impose minimal additional costs on plans. We note that we are not specifying a transport standard and anticipate that plans may opt to use APIs, such as the Patient Access API that this final rule also requires. We also anticipate that plans may choose to utilize a regional health information exchange. We believe it is difficult to quantify the impact of this change because plans will likely implement different transport methods, and we cannot predict the selected method plans will choose. b. Care Coordination Through Trusted Exchange Networks In section VI. of the CMS Interoperability and Patient Access proposed rule, we proposed requiring MA organization, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs to participate in trust networks in order to improve interoperability. We also listed the requirements for participation in a trusted exchange network. As a result of comments and reexamination of our desired policies, we have decided not to finalize this provision. However, as pointed out in the proposed rule, had this provision been finalized, it would impose minimal additional costs on plans. PO 00000 Frm 00118 Fmt 4701 Sfmt 4700 Consequently, not finalizing this policy does not impact this RIA. 5. Non-Mandatory Effects and Regulatory Interaction We note in this RIA when we had difficulty quantifying costs due to lack of applicable research or data. More specifically, the establishment of a health care information ecosystem could only be achieved with new actions that are conducted widely throughout the health care field—including by entities, especially non-hospital providers, for whom costs have not been estimated in either this RIA or the RIA for the accompanying ONC 21st Century Cures Act final rule (published elsewhere in this issue of the Federal Register). Although data limitations have prevented the quantification of these costs, the benefits of the two rules— some of which have been quantified in the ONC RIA—and the rules’ potential transfer impacts—including reductions in fraudulent payments, as discussed by Parente et al. (2008) 88—are largely contingent upon such costs being incurred. Additionally, there are ongoing regulatory and policy activities outside of this final rule that might influence the rule’s impact in an unquantifiable manner. When possible, we acknowledge these complexities as well. D. Alternatives Considered In March 2018, the White House Office of American Innovation and the CMS Administrator announced the launch of MyHealthEData, and CMS’s direct, hands-on role in improving patient access and advancing interoperability. As part of the MyHealthEData initiative, we are taking a patient-centered approach to health information access and moving to a system in which patients have immediate access to their electronic health information and can be assured that their health information will follow them as they move throughout the health care system from provider to provider, payer to payer. This final rule contains a range of policies. It provides descriptions of the statutory provisions that are addressed, identifies the policies, and presents rationales for our decisions and, where relevant, alternatives that were considered. We carefully considered alternatives to the policies we are adopting in this final rule but concluded that none of the 88 Parente, Stephen T., Karen Mandelbaum, Susan P. Hanson, Bonnie S. Cassidy and Donald W. Simborg. ‘‘Crime and Punishment: Can the NHIN Reduce the Cost of Healthcare Fraud?’’ Journal of Healthcare Information Management 22(3): 42–51. June 2008. E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations alternatives would adequately and immediately begin to address the critical issues of the lack of patient access and interoperability, or the difficulty exchanging health care data within the health care system. As we noted in the CMS Interoperability and Patient Access proposed rule, we believe the following three attributes of standards-based APIs are particularly important to achieving the goal of offering individuals convenient access, through applications they choose, to available and relevant electronic health and health-related information: the API technologies themselves, not just the data accessible through them, are standardized; the APIs are technically transparent; and the APIs are implemented in a procompetitive manner (84 FR 7620). The API requirements proposed and finalized in this rule were developed to ensure these goals are met. Some of the reasons that we selected the FHIR standard were due to the flexibility it provides and the wide industry adoption that it offers. The open and extensible nature of FHIR allows for health care integration to be transparent and accessible. FHIR is open source, and as such, it has garnered a community that includes developers and vendors. For example, large consumer brands are becoming a driving force behind the adoption of FHIR. Apple is implementing FHIR in Apple Health as part of iOS 11.3, and serves as a member of the Argonaut Project and CARIN Alliance—two HL7 FHIR Accelerators; 89 Google supports FHIR by partnering with HL7, as well as through its membership in the CARIN Alliance; and Microsoft published an Azure API for FHIR to create and deploy FHIR service health data solutions.90 Furthermore, according to an ONC report, nearly 51 percent of health IT developers appear to be using a version of FHIR combined with OAuth 2.0 to respond to requests for patient data. Additionally, of the hospitals and Meritbased Incentive Payment System (MIPS) eligible clinicians that use certified 89 The HL7 FHIR Accelerator Program is designed to assist communities and collaborative groups across the global health care spectrum in the creation and adoption of high quality FHIR Implementation Guides or other standard artifacts to move toward the realization of global health data interoperability. For further details, see https:// www.hl7.org/about/fhir-accelerator/. 90 Shrestha, R., Mohan, S., & Grieve, G. (2018, February 14). State of the Healthcare API Economy (An Innovation Forum Session: Session 217). Retrieved from https://365.himss.org/sites/ himss365/files/365/handouts/552739129/handout219_FINAL.pdf. See also https:// azure.microsoft.com/en-us/services/azure-api-forfhir/ and https://www.apple.com/healthcare/healthrecords/. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 products, almost 87 percent of hospitals and 69 percent of MIPS eligible clinicians are served by health IT developers with product(s) certified to any FHIR version.91 For additional ways to allow consumers access to their health data, we note that we did receive comments that CMS could consider allowing payers and providers to upload patient data directly to a patient portal that is owned and managed by the patient. One option would allow for HIEs and HINs to serve as a central source for patients to obtain aggregated data in a single location. While HIEs and HINs can provide patients with valuable information via a portal, research has indicated that portals have not gained widespread use by patients. According to ONC, as of 2017, 52 percent of individuals have been offered online access to their medical records by a health provider or payer. Of the 52 percent that were offered access, only half of those viewed their record.92 Additionally, we believe that there would be additional burden associated with using portals because providers and patients would need to access multiple portals and websites to access patient data, instead of a single app. Unlike portals that would require developers to link systems or ensure system-level compatibility, FHIR-based APIs have the ability to make data available without the need to link multiple systems or portals and would provide a patient a single-point of access to their data. Having APIs that can be accessed by third-party apps permits the patient to choose how they want to access their data, and it promotes innovation in industry to find ways to best help patients interact with their data in a way that is most meaningful and helpful to them. Additionally, we believe it would be very difficult to evaluate the cost impacts of making individual portals available via an HIE or HIN because business models and process are varied, and there is a lack of standardization in the way the information is stored and transmitted across HIEs and HINs. Other alternatives that we considered were how broadly or narrowly to apply the policies and requirements. For example, we could have required health 91 Posnack, S. & Baker, W. (2018, October 1). Heat Wave: The U.S. is Poised to Catch FHIR in 2019. Retrieved from https://www.healthit.gov/buzz-blog/ interoperability/heat-wave-the-u-s-is-poised-tocatch-fhir-in-2019. 92 Patel, V. & Johnson, C. (2018, April). Individuals’ Use of Online Medical Records and Technology for Health Needs (ONC Data Brief No. 40). Retrieved from https://www.healthit.gov/sites/ default/files/page/2018-03/HINTS-2017-ConsumerData-Brief-3.21.18.pdf. PO 00000 Frm 00119 Fmt 4701 Sfmt 4700 25627 plans to provide more data elements via a standards-based API then just data for adjudicated claims, encounters with capitated providers, provider remittances, beneficiary cost-sharing, clinical data including laboratory results, provider directories (and pharmacy directories for MA–PDs), and preferred drug lists, where applicable. In the CMS Interoperability proposed rule, we originally required MA organizations, state Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities to make available provider directory data through the Patient Access API (84 FR 7633) and publicly available to current and prospective enrollees (84 FR 7639). After consideration of public comments, we have removed the requirements that these impacted payers make provider directory information available through the Patient Access API. MA organizations, state Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities will only need to make provider directory information available via a publicly accessible Provider Directory API. We note the Provider Directory API does not need to conform to the security protocols finalized by HHS at 45 CFR 170.215(a)(3) and (b) that are specific to authenticating users and confirming individuals’ authorization or request to disclose their personal information to a specific application through an API, namely the SMART IG (using the OAuth 2.0 standard) and OpenID Connect Core 1.0. By only requiring the Provider Directory API make these otherwise publicly accessible data available, we are seeking to avoid duplicative effort and additional burden. Additionally, several commenters suggested additional information be added to the requirement for provider directory information to be available through an API, such as NPIs for individual and group providers, practice group name, health system name, as well as the specific plan(s) and tiers a provider participates in ‘‘provider demographics;’’ whether the provider is accepting new patients; and information about which providers are in-network for a plan by geography and/or specialty. While we agreed with commenters that this information would be helpful to patients, we did not modify the proposed requirements for the information that is required to be made available by the Provider Directory API because we believe additional data would be a cost driver. By not adding additional required E:\FR\FM\01MYR2.SGM 01MYR2 25628 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations information we are seeking to minimize the burden for the regulated payers that must comply with this policy. Instead we are identifying a minimum set of provider directory information that aligns with existing requirements applicable to MA organizations (including MA organizations that offer MA–PD plans), state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities that beneficiaries can currently access. We also looked at policy alternatives related to specific aspects of the API requirements. For instance, we considered whether to modify the requirement to make claims and encounter data, as well as clinical data, available through the Patient Access API no later than one (1) business day after a payer receives it. We reviewed several suggested alternatives such as increasing the timeframe to three (3) or five (5) business days to account for vendor-adjudicated claims. While we considered these alternatives, we ultimately decided not to adjust the proposed requirements because having access to this information within one (1) business day could empower patients to have the information they need, when they need it to inform care coordination. Patients have a right to see the full lifecycle of their claims and encounter information as soon as it is available, even if the payment amounts may change due to appeal. Additionally, as we noted in section XII. of this final rule, the burden related to API requirements is in the initial implementation of the system to make this information available in one (1) business day once received. This requirement is being implemented in the design and build phase and the system update cost for electronic availability would be the same regardless of the number of days the system is set up to accommodate. There is also no data on whether providing three (3) or five (5) days, versus one (1) day, will provide patients with more complete or accurate data. As an alternative, we considered requiring all QHP issuers on all Exchanges to meet the new API requirements as part of QHP VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 certification. Consistent with some other QHP certification requirements, we opted not to require SBEs to include this as part of their certification requirements, but we strongly urge them to do so to ensure equitable treatment of issuers nationally and to allow consumers to access their health information through a third-party application no matter where they are insured across the country. States are the most knowledgeable about their consumers and insurance markets and are responsible for issuer compliance activities. While we believe that these API requirements have the potential to provide great benefit to consumers, complying with them will be mainly operational and SBE states would be required to assess QHP issuer compliance. Therefore, we believe that SBE states should be given the flexibility to determine whether or not these requirements are required of their QHP issuers. An additional alternative that we considered was based off one commenter’s suggestion to incentivize plans who meet the required implementation dates through higher Healthcare Effectiveness Data and Information Set (HEDIS) scores. Although the commenter was not clear regarding a specific recommendation as to how to implement changes to the HEDIS score, we evaluated options such as adding a new measure specific to data exchange using HL7 FHIR-based APIs between payers and third-parties on the behalf of patients, or adding bonus points to the total score or some appropriate measure set for implementing the FHIR-based APIs required. However, after further evaluation, we believe that this is not a viable alternative at this time. CMS cannot give a higher HEDIS score for using a digital specification because it would not be an accurate measure of plan performance. To consider adding a bonus to the highest rating if the plan meets certain standards would necessitate requiring a new adjustment to the star rating methodology. This would be a significant change to how the current star ratings are calculated and would have to be proposed through PO 00000 Frm 00120 Fmt 4701 Sfmt 4700 notice and comment rulemaking. Given the implementation date for the API provisions for MA organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, and CHIP managed care entities is January 1, 2021, and for QHP issuers on the FFEs beginning with plan years beginning on or after January 1, 2021, implementing changes to the star ratings would not be achievable within the available timeframe to incentivize implementation as the commenter suggested. As we recognize that advancing interoperability is no small or simple matter, we continue to explore alternatives and potential future policies. In the CMS Interoperability and Patient Access proposed rule, we requested comment for consideration in future rulemaking or subregulatory guidance on a number of alternatives related to whether additional policies or requirements, beyond those proposed, should be imposed to promote interoperability. For example, the CMS Innovation Center sought comment on general principles around promoting interoperability as part of the design and testing of innovative payment and service delivery models. Additionally, we sought comment on how we may leverage our program authority to provide support to those working on improving patient matching. For example, we requested comment on whether CMS should require impacted payers use a particular patient matching software solution with a proven success rate of a certain percentage validated by HHS or a third party. We also noted that we will continue to consider feedback received from RFIs issued in various rules over the course of the past 2 years and incorporate those suggestions into our strategy. We thank commenters for their input on these RFIs. We will consider the comments received for potential future rulemaking. E. Accounting Statement and Table In accordance with OMB Circular A– 4, Table 14 depicts an accounting statement summarizing the assessment of the benefits, costs, and transfers associated with this regulatory action. E:\FR\FM\01MYR2.SGM 01MYR2 25629 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations TABLE 14—ACCOUNTING STATEMENT Units Primary estimate Category Year dollars Discount rate (percent) Period covered Benefits Qualitative ........................................................................................................ • API requirements will alleviative the burden for patients to go through separate processes to obtain access to each system, and the need to manually aggregate information that is delivered in various, often non-standardized, formats (not necessarily additional to the benefits assessed in the RIA for the accompanying ONC 21st Century Cures Act final rule, (published elsewhere in this issue of the Federal Register)). • API requirement allows for the administration of a more efficient and effective Medicaid program by taking advantage of commonly used methods of information sharing and data standardization. • API requirements would help to create a health care information ecosystem that allows and encourages the health care market to tailor products and services to compete for patients, thereby increasing quality, decreasing costs, providing potential benefits (not necessarily additional to the benefits assessed in the RIA for the accompanying ONC final rule), and helping them live better, healthier lives. • Privacy and security policies are being implemented that permit payers to request third-party apps to attest to privacy and security provisions prior to providing the app access to the payer’s API. Costs Annualized Monetized $ millions/year (low estimate) ..................................... Annualized Monetized $ millions/year (primary estimate) ............................... Annualized Monetized $ millions/year (high estimate) .................................... 85.2 80.8 122.0 112.4 158.8 144.0 2019 2019 2019 2019 2019 2019 7 3 7 3 7 3 2020–2029 2020–2029 2020–2029 2020–2029 2020–2029 2020–2029 Non-Quantified Costs: Non-hospital provider costs associated with development of a broad health care information ecosystem (regulatory benefits and fraud reduction are largely contingent upon these non-mandatory costs being incurred). Transfers from the Federal Government to Enrollees of Commercial Plans (PTC) Annualized Monetized $ millions ..................................................................... Annualized Monetized $ millions ..................................................................... 5.4 5.5 2019 2018 7 3 2020–2029 2020–2029 Non-Quantified Transfers: Reduced fraudulent payments to providers from the federal government and other payers. The preceding discussion was an actual cost impact (not a transfer) since goods and computer services are being paid for. Plans have the option of transferring their expenses to enrollees. In practice, because of market competitive forces a plan may decide to operate at a (partial) loss and not transfer the entire cost. It is important to estimate the maximum the transfer could be. Some costs are transferred to the states (for Medicaid and CHIP) and ultimately to the federal government (for Medicare, Medicaid, and CHIP, and potentially for QHP issuers on the FFEs in the form of higher PTCs)), mitigating the amount transferred to enrollees. One approach to estimate impact on enrollees was made in section XII.B. of this RIA. However, this analysis did not take into account transfers. VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 We now re-estimate the potential full transfer. As noted in Tables 5 through 10, we have in 2021 through 2029 under a dollar increase in premiums as the worst-case scenario, and we used actual costs per year. In this alternate analysis, we use actual amounts for each of 2021 through 2029 with the initial 1-year cost amortized over 9 years. In other words, we assume an aggregate annual cost of $84.6 million ($272 million/9 + $54.4 million), this is based on the low estimate 1st year cost of $272 million. If we use the high estimate cost $816 million we obtain $145 million average ($816 million/9 + $54.4 million). We note that this premium increase could be counterbalanced by projected savings arising from the provisions in this final rule. More specifically, we expect the availability of portable PO 00000 Frm 00121 Fmt 4701 Sfmt 4700 electronic transfer of medical data proposed by this rule will help patients have the ability to move from payer to payer, provider to provider, and have both their clinical and administrative information travel with them throughout their health care journey. Allowing patients to piece together their own information that might otherwise be lost in disparate systems could help make better informed patients and may lead to increase prevention of future medical illnesses due to improvements in care coordination due to better data accessibility. The savings from avoiding one illness or one cheaper procedure would offset the under one-dollar impact. However, we have no way, at this point, of estimating this aspect of the future savings of the rule. E:\FR\FM\01MYR2.SGM 01MYR2 25630 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations We present two estimates. First, we estimate using the enrollment figures used in Table 9 of this RIA. Table 9 shows that we have 110.5 million enrollees (17.5+73+20) in programs that will be spending about $84.6 million per year. Ignoring federal subsidies, and assuming that all costs will be passed on to enrollees (which is contrary to our experience), the 110.5 million enrollees would each incur an extra 77 cents per enrollee ($84.6 million/110.5 million) a year to achieve the $84.6 million goal. This is the low estimate cost. The corresponding high estimate cost would be $1.31 per enrollee per year ($145 million/110.5 million). We next estimate using premium versus enrollment as was done in section XII.B. of this RIA. Prior to discussing potential transfers to enrollees, we discuss how this final rule may affect patients not covered by plans subject to this rule. It is both possible and likely that an organization offering a plan subject to this rule may also offer plans not subject to this rule, and comply with the requirements of this rule for all of its plans, including those not subject to this rule. Consequently, it is possible that to cover the cost of complying with this rule for plans that are subject to this rule and plans that are not subject to this rule, organizations may raise premiums for their plans that are subject to this rule and their plans that are not subject to this rule. It is possible (and we contend likely) that this final rule will affect enrollees in individual market plans other than QHPs on the FFEs, even though there is no requirement for such coverage to comply with this rule. Therefore, we calculate the cost impact per enrollee should organizations offering plans not subject to this rule choose to comply with this rule with regard to those plans. The rest of the discussion below explores this possibility. QHP issuers on the FFEs: Rebates are required under section 2718(b)(1)(A) of the PHSA and the implementing regulations at 45 CFR part 158 when an issuer does not meet the applicable threshold. The commercial market MLR is generally calculated as the percent of each dollar of after-tax premium revenue spent by the issuer on reimbursement for clinical services, and activities that improve the quality of health care. If the issuer’s MLR for a state market is below the applicable threshold, then the issuer must return the difference to policyholders. It follows, that if costs of complying with this rule raise plan costs, and if additionally, the issuers pass on the full cost in the form of premium and/or are able to treat these costs as QIAs, then premiums and rebates will change. The following two highly simplified examples are illustrative. Suppose the MLR threshold is 80 percent (in practice it can vary by state market), but the issuer’s MLR is below the threshold at 70 percent. Then, the issuer would have to return the 10 percent as a rebate. If the costs of complying with this rule for an issuer are on average 6 percent of premium and the issuer treats these expenses as QIA, the issuer will now have to rebate only 4 percent instead of 10 percent (that is, the issuer’s MLR would be 76 percent rather than 70 percent). Similarly, if both the applicable threshold and issuer MLR are 80 percent, then the issuer would not owe a rebate. There are two effects of recognizing these costs as QIA: (1) For issuers subject to this rule who are below the applicable MLR threshold, the rebate from issuers to policyholders would go down by some amount between $0 and the cost of complying with this rule; and (2) for issuers subject to this rule who are at or above the MLR standards, the premium transfers from enrollees to issuers will go up by some amount between $0 and the cost of complying with this rule. We note that both MLR and rebates are calculated by combining all of an issuer’s business (on- and offExchange) within a state and market. To estimate these amounts, we used the public use 2016 MLR files on the CMS website that were used for Tables 6 through 9 of this RIA. The total reported 2016 premium revenue on the commercial side for individual market plans was approximately $77 billion (See Table 7). Of the $77 billion, the total reported 2016 premium revenue of issuers that were below the commercial MLR standard (80 or 85 percent, depending on the market) was approximately $4 billion. As mentioned earlier, to proceed further we use the estimates of the costs of complying with this rule, which are $84.6 million per year. This cost is for all parent organizations with each parent organization possibly dealing with up to four lines of business subject to MLR requirements and the requirements of this rule: MA (including Part D sponsors); Medicaid; CHIP; and QHP issuers on the FFEs. Thus, of the $84.6 million level annual cost of complying with this rule, we estimate $18.8 million (22.19 percent commercial proportion * $84.6 million level annual cost complying with this rule) to be the cost for individual market plans. In estimating the transfers to policyholders in individual market plans, we must distinguish between the $4 billion of premium revenues of issuers whose MLR was below the applicable threshold and the $73 billion of premium revenues ($77 billion total revenue for individual market plans– $4 billion) of individual market issuers whose MLR was at or above the applicable threshold. We can now calculate the estimated aggregate transfer in the commercial health insurance market from individual market policyholders to issuers whether through premium or rebates as follows: • Percentage cost of complying with this rule = 0.0244 percent of revenue premium ($18.8 million cost/$77 billion total revenue). • Reduced MLR rebates = $1 million (0.0244 percent × $4 billion premium from issuers below the applicable MLR threshold). • Increased premiums = Up to $17.8 million (0.0244 percent × ($77 billion total revenue¥$4 billion premium from issuers below the applicable MLR threshold)). • Total transfer from enrollees = Up to $418.8 million ($17.8 million increased premium + $1 million reduced rebate). • Transfer per enrollee = $1.07 ($418.8 million/17.5 million commercial health insurance enrollees). We note that the $1.07 (under a dollar per enrollee) is consistent with the results obtained in Tables 6 through 10 (with exact raw amounts by year without amortization of a large first year expense). These calculations are summarized in Table 15. The $1.07 is the low estimate of first year costs. The high estimate $1.85 per enrollee per year is obtained by replacing the low estimate cost of $272 million with $816 million. TABLE 15—TRANSFERS TO ENROLLEE RESULTING FROM THE FINAL RULE Label Item (A) .................. First year cost of interoperability (Low estimate) ................... VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Amount Frm 00122 Fmt 4701 Sfmt 4700 272.0 Source Estimated in this proposed rule. E:\FR\FM\01MYR2.SGM 01MYR2 Comments In millions. 25631 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations TABLE 15—TRANSFERS TO ENROLLEE RESULTING FROM THE FINAL RULE—Continued Label Item Amount Source (B) .................. (C) .................. First year cost amortized over 9 years .................................. Continuation year cost of interoperability ............................... 30.2 54.4 (D) .................. Level interoperability cost per year ........................................ 84.6 Comments (A) / 9 ..................................... Estimated in this proposed rule. (B) + (C) ................................. In millions. In millions. 347 Table 7 ................................... In billions. 77 22.19% ................................... Table 7. 157 45.24% ................................... Table 7. 113 32.56% ................................... Table 7. In millions. Commercial Percent of Premium Revenues (E) .................. (F) .................. (G) .................. (H) .................. Total premium revenues in Individual market, Medicaid and Medicare. Individual market plans premium revenues (dollar amount and percent). Medicare Advantage premium revenues (Dollar amount and percent). Medicaid premium revenues (Dollar amount and percent) ... Annual interoperability cost as a percent of commercial individual market health insurance premium revenues (I) .................... (J) ................... (K) .................. (L) ................... Annual Level interoperability cost .......................................... Percent of total individual market plans revenues ................. Interoperability cost for individual market plans ..................... Commercial premium revenues for individual market plans .. 84.6 22.19% 18.8 77,000 (M) .................. Interoperability cost as a percent of total commercial revenue for individual market plans. 0.0244% (D) .......................................... (F). (I) × (J) ................................... (E) .......................................... In millions. In millions. 2016 data in millions. (K) / (L). Individual market plans revenue broken out by whether above or below MLR threshold (requiring rebate) (N) .................. (O) .................. (P) .................. Total individual market plan revenue ..................................... Revenues of individual market health plans whose MLR is below regulatory threshold. Revenues of individual market plans whose MLR is below regulatory threshold. 77,000 4,037 72,963 (E) .......................................... 2016 CMS MLR Data in millions. (N)¥(O) ................................. In millions. In millions. In millions. Transfer to enrollee per enrollee from decreased rebates and increased premium (Q) .................. (T) .................. Reduction in rebates from interoperability in those plans paying rebates. Premium increase from interoperability in those plans not paying rebates. Total increase to commercial individual market plans enrollees from interoperability. Number commercial enrollees in individual market plans ..... (U) .................. (V) .................. Dollar increase in premium per enrollee (Low estimate) ....... Dollar increase in premium per enrollee (Medium Estimate) $1.07 $1.46 (W) ................. Dollar increase in premium per enrollee (High Estimate) ...... $1.84 (R) .................. (S) .................. 1.0 (N) × (P). 18.8 (Q) + (R) ................................ In millions. 17.5 From 2016 MLR files, in millions. (S) / (T). Obtained by replacing 272 million in row (A) with $544 million. Obtained by replacing 272 million in row (A) with $816 million. In millions. on the estimated costs of this final rule can be found in the preceding analysis. Executive Order 13771, titled Reducing Regulation and Controlling Regulatory Costs, was issued on January 30, 2017 and requires that the costs associated with significant new regulations ‘‘shall, to the extent permitted by law, be offset by the elimination of existing costs associated with at least two prior regulations.’’ This final rule is considered an E.O. 13771 regulatory action. We estimate that this rule generates $77.8 million in annualized costs, discounted at 7 percent relative to year 2016, over an infinite time horizon estimate. Details G. Conclusion VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 The analysis above, together with the preceding preamble, provides an RIA. In accordance with the provisions of Executive Order 12866, this regulation was reviewed by the Office of Management and Budget. List of Subjects 42 CFR Part 406 Health facilities, Diseases, Medicare. 42 CFR Part 422 Administrative practice and procedure, Health facilities, Health maintenance organizations (HMO), Medicare, Penalties, Privacy, Reporting and recordkeeping requirements. 42 CFR Part 423 Administrative practice and procedure, Emergency medical services, Health facilities, Health maintenance organizations (HMO), Medicare, Penalties, Privacy, Reporting and recordkeeping requirements. Medicare. PO 00000 Frm 00123 Fmt 4701 Sfmt 4700 In millions. 17.8 F. Regulatory Reform Analysis Under E.O. 13771 42 CFR Part 407 (N) × (O) ................................. E:\FR\FM\01MYR2.SGM 01MYR2 25632 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 42 CFR Part 431 Grant programs—health, Health facilities, Medicaid, Privacy, Reporting and recordkeeping requirements. 42 CFR Part 438 Grant programs—health, Medicaid, Reporting and recordkeeping requirements. PART 407—SUPPLEMENTARY MEDICAL INSURANCE (SMI) ENROLLMENT AND ENTITLEMENT 42 CFR Part 457 Administrative practice and procedure, Grant programs—health, Health insurance, Reporting and recordkeeping requirements. 3. The authority citation for part 407 is revised to read as follows: ■ Authority: 42 U.S.C 1302 and 1395hh. 4. Section 407.40 is amended by adding paragraph (c)(4) to read as follows: ■ 42 CFR Part 482 Grant programs—health, Hospitals, Medicaid, Medicare, Reporting and recordkeeping requirements. § 407.40 Enrollment under a State buy-in agreement. 42 CFR Part 485 Grant programs—health, Health facilities, Medicaid, Privacy, Reporting and recordkeeping requirements. 45 CFR Part 156 Administrative practice and procedure, Advertising, Advisory committees, Brokers, Conflict of interests, Consumer protection, Grant programs—health, Grants administration, Health care, Health insurance, Health maintenance organization (HMO), Health records, Hospitals, Indians, Individuals with disabilities, Loan programs—health, Medicaid, Organization and functions (Government agencies), Public assistance programs, Reporting and recordkeeping requirements, State and local governments, Sunshine Act, Technical assistance, Women, Youth. For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services (CMS) amends 42 CFR chapter IV and the Office of the Secretary (HHS) amends 45 CFR subtitle A, subchapter B, as set forth below: TITLE 42—PUBLIC HEALTH CHAPTER IV—CENTERS FOR MEDICARE & MEDICAID SERVICES, DEPARTMENT OF HEALTH AND HUMAN SERVICES PART 406—HOSPITAL INSURANCE ELIGIBLIITY AND ENTITLEMENT 1. The authority citation for part 406 is revised to read as follows: ■ Authority: 42 U.S.C 1302 and 1395hh. 2. Section 406.26 is amended by adding paragraph (a)(1)(i) and adding and reserving paragraph (a)(1)(ii) to read as follows: ■ § 406.26 Enrollment under State buy-in. (a) * * * (1) * * * VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 (i) Any State that has a buy-in agreement in effect must participate in daily exchanges of enrollment data with CMS. (ii) [Reserved] * * * * * * * * * * (c) * * * (4) Any State that has a buy-in agreement in effect must participate in daily exchanges of enrollment data with CMS. PART 422—MEDICARE ADVANTAGE PROGRAM 5. The authority citation for part 422 continues to read as follows: ■ Authority: 42 U.S.C 1302 and 1395hh. 6. Section 422.119 is added to read as follows: ■ § 422.119 Access to and exchange of health data and plan information. (a) Application Programming Interface to support MA enrollees. A Medicare Advantage (MA) organization must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of a current individual MA enrollee or the enrollee’s personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the enrollee. (b) Accessible content. (1) An MA organization must make the following information accessible to its current enrollees or the enrollee’s personal representative through the API described in paragraph (a) of this section: (i) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and enrollee cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed; PO 00000 Frm 00124 Fmt 4701 Sfmt 4700 (ii) Encounter data from capitated providers, no later than one (1) business day after data concerning the encounter is received by the MA organization; and (iii) Clinical data, including laboratory results, if the MA organization maintains any such data, no later than one (1) business day after the data is received by the MA organization. (2) In addition to the information specified in paragraph (b)(1) of this section, an MA organization that offers an MA–PD plan must make the following information accessible to its enrollees through the API described in paragraph (a) of this section: (i) Data concerning adjudicated claims for covered Part D drugs, including remittances and enrollee cost-sharing, no later than one (1) business day after a claim is adjudicated; and, (ii) Formulary data that includes covered Part D drugs, and any tiered formulary structure or utilization management procedure which pertains to those drugs. (c) Technical requirements. An MA organization implementing an API under paragraph (a) of this section: (1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215; (2) Must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data; (3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law: (i) Content and vocabulary standards at 45 CFR 170.213 where such standards are applicable to the data type or element, as appropriate; and (ii) Content and vocabulary standards at 45 CFR part 162 and § 423.160 of this chapter where required by law or where such standards are applicable to the data type or element, as appropriate. (4) May use an updated version of any standard or all standards required under paragraph (c)(1) or (3) of this section, where: (i) Use of the updated version of the standard is required by other applicable law; or E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations (ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that: (A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170; (B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and (C) Use of the updated version of a standard does not disrupt an end user’s ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section. (d) Documentation requirements for APIs. For each API implemented in accordance with paragraph (a) of this section, an MA organization must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum the information listed in this paragraph. For the purposes of this section, ‘‘publicly accessible’’ means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available; (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns; (2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and (3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API. (e) Denial or discontinuation of access to the API. An MA organization may deny or discontinue any third party application’s connection to the API required under paragraph (a) of this section if the MA organization: (1) Reasonably determines, consistent with its security risk analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 connected to the API would present an unacceptable level of risk to the security of protected health information on the MA organization’s systems; and (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which enrollees seek to access their electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. (f) Coordination among payers. (1) An MA organization must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213. Such information received by an MA organization must be incorporated into the MA organization’s records about the current enrollee. With the approval and at the direction of a current or former enrollee or the enrollee’s personal representative, the MA organization must: (i) Receive all such data for a current enrollee from any other payer that has provided coverage to the enrollee within the preceding 5 years; (ii) At any time an enrollee is currently enrolled in the MA plan and up to 5 years after disenrollment, send all such data to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee’s personal representative specifically requests receive the data; and (iii) Send data received from another payer under this paragraph (f) in the electronic form and format it was received. (2) [Reserved] (g) Enrollee resources regarding privacy and security. An MA organization must provide in an easily accessible location on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former enrollees seeking to access their health information held by the MA organization, educational resources in non-technical, simple and easy-tounderstand language explaining at a minimum: (1) General information on steps the individual may consider taking to help protect the privacy and security of their health information including factors to consider in selecting an application including secondary uses of data, and the importance of understanding the security and privacy practices of any application to which they will entrust their health information; and PO 00000 Frm 00125 Fmt 4701 Sfmt 4700 25633 (2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how to submit a complaint to: (i) The HHS Office for Civil Rights (OCR); and (ii) The Federal Trade Commission (FTC). (h) Applicability. (1) An MA organization must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning January 1, 2021, and with the requirements in paragraph (f) beginning January 1, 2022 with regard to data: (i) With a date of service on or after January 1, 2016; and (ii) That are maintained by the MA organization. (2) [Reserved] ■ 7. Section 422.120 is added to read as follows: § 422.120 Access to published provider directory information. (a) An MA organization must implement and maintain a publicly accessible, standards-based Application Programming Interface (API) that is conformant with the technical requirements at § 422.119(c), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations, the documentation requirements at § 422.119(d), and is accessible via a public-facing digital endpoint on the MA organization’s website. (b) The API must provide a complete and accurate directory of— (1) The MA plan’s network of contracted providers, including names, addresses, phone numbers, and specialties, updated no later than 30 calendar days after the MA organizations receives provider directory information or updates to provider directory information; and (2) For an MA organization that offers an MA–PD plan, the MA–PD’s pharmacy directory, including the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as ‘‘retail pharmacy’’) updated no later than 30 calendar days after the MA organization receives pharmacy directory information or updates to pharmacy directory information. (c) This section is applicable beginning January 1, 2021. E:\FR\FM\01MYR2.SGM 01MYR2 25634 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations § 431.60 Beneficiary access to and exchange of data. 8. Section 422.504 is amended by adding paragraph (a)(18) to read as follows: ■ § 422.504 Contract provisions. * * * * * (a) * * * (18) To comply with the requirements for access to health data and plan information under §§ 422.119 and 422.120 of this chapter. * * * * * PART 423—VOLUNTARY MEDICARE PERSCRIPTION DRUG BENEFIT 9. The authority citation for part 423 is revised to read as follows: ■ Authority: 42 U.S.C. 1302, 1306, 1395w– 101 through 1395w–152, and 1395hh. 10. Section 423.910 is amended— a. In paragraph (b)(1) introductory text by removing the phrase ‘‘monthly reporting requirement for the monthly enrollment reporting’’ and adding in its place the phrase ‘‘state enrollment reporting requirement described in paragraph (d) of this section’’; ■ b. In paragraph (d) by revising the paragraph heading and by redesignating the text of paragraph (d) introductory text as paragraph (d)(1). ■ c. In newly redesignated paragraph (d)(1), by removing the phrase ‘‘Effective June 2005, and each subsequent month, States must submit an electronic file, in a manner specified by CMS’’ and by adding the following phrase ‘‘States must submit an electronic file as specified in paragraph (d)(2) of this section,’’; and ■ d. By adding paragraph (d)(2). The revision and addition read as follows: ■ ■ § 423.910 Requirements. * * * * * (d) * * * (2)(i) For the period prior to April 1, 2022, States must submit the file at least monthly and may submit updates to that file on a more frequent basis. (ii) For the period beginning April 1, 2022, States must submit the file at least monthly and must submit updates to that file on a daily basis. * * * * * PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION 11. The authority citation for part 431 is revised to read as follows: ■ Authority: 42 U.S.C. 1302. 12. Section 431.60 is added to subpart B to read as follows: ■ VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 (a) Application Programming Interface to support Medicaid beneficiaries. A State must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of a current beneficiary or the beneficiary’s personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the beneficiary. (b) Accessible content. A State must make the following information accessible to its current beneficiaries or the beneficiary’s personal representative through the API described in paragraph (a) of this section: (1) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and beneficiary cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed; (2) Encounter data no later than one (1) business day after receiving the data from providers, other than MCOs, PIHPs, and PAHPs, compensated on the basis of capitation payments; (3) Clinical data, including laboratory results, if the State maintains any such data, no later than one (1) business day after the data is received by the State; and (4) Information about covered outpatient drugs and updates to such information, including, where applicable, preferred drug list information, no later than one (1) business day after the effective date of any such information or updates to such information. (c) Technical requirements. A State implementing an API under paragraph (a) of this section: (1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215; (2) Must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data; PO 00000 Frm 00126 Fmt 4701 Sfmt 4700 (3) Must comply with the content and vocabulary standards requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law: (i) Content and vocabulary standards at 45 CFR 170.213 where such standards are applicable to the data type or element, as appropriate; and (ii) Content and vocabulary standards at 45 CFR part 162 and § 423.160 of this chapter where required by law, or where such standards are applicable to the data type or element, as appropriate. (4) May use an updated version of any standard or all standards required under paragraph (c)(1) or (3) of this section, where: (i) Use of the updated version of the standard is required by other applicable law, or (ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that: (A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170; (B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and (C) Use of the updated version of a standard does not disrupt an end user’s ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section. (d) Documentation requirements for APIs. For each API implemented in accordance with paragraph (a) of this section, a State must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum the information listed in this paragraph. For the purposes of this section, ‘‘publicly accessible’’ means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available; (1) API syntax, function names, required and optional parameters supported and their data types, return E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations variables and their types/structures, exceptions and exception handling methods and their returns; (2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and (3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API. (e) Denial or discontinuation of access to the API. A State may deny or discontinue any third-party application’s connection to the API required under paragraph (a) of this section if the State: (1) Reasonably determines, consistent with its security risk analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the State’s systems; and (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which beneficiaries seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. (f) Beneficiary resources regarding privacy and security. The State must provide in an easily accessible location on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former beneficiaries seeking to access their health information held by the State Medicaid agency, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum: (1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application including secondary uses of data, and the importance of understanding the security and privacy practices of any application to which they will entrust their health information; and (2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how to submit a complaint to: (i) The HHS Office for Civil Rights (OCR); and (ii) The Federal Trade Commission (FTC). VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 (g) Data availability. (1) The State must comply with the requirements in paragraph (a) through (f) of this section beginning January 1, 2021 with regard to data: (i) With a date of service on or after January 1, 2016; and (ii) That are maintained by the State. (2) [Reserved] ■ 13. Section 431.70 is added to subpart B to read as follows: § 431.70 Access to published provider directory information. (a) The State must implement and maintain a publicly accessible, standards-based Application Programming Interface (API) that is conformant with the technical requirements at § 431.60(c), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations, the documentation requirements at § 431.60(d), and is accessible via a public-facing digital endpoint on the State’s website. (b) The API must provide a complete and accurate directory of— (1) The State’s provider directory information specified in section 1902(a)(83) of the Act, updated no later than 30 calendar days after the State receives provider directory information or updates to provider directory information. (2) [Reserved] (c) This section is applicable beginning January 1, 2021. PART 438—MANAGED CARE 14. The authority citation for part 438 is revised to read as follows: ■ Authority: 42 U.S.C. 1302. 15. Section 438.62 is amended by adding paragraphs (b)(1)(vi) and (vii) to read as follows: ■ § 438.62 Continued services to enrollees. * * * * * (b) * * * (1) * * * (vi) A process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213. Such information received by the MCO, PIHP, or PAHP must be incorporated into the MCO’s, PIHP’s, or PAHP’s records about the current enrollee. With the approval and at the direction of a current or former enrollee or the enrollee’s personal representative, the MCO, PIHP, or PAHP must: (A) Receive all such data for a current enrollee from any other payer that has PO 00000 Frm 00127 Fmt 4701 Sfmt 4700 25635 provided coverage to the enrollee within the preceding 5 years; (B) At any time the enrollee is currently enrolled in the MCO, PIHP, or PAHP and up to 5 years after disenrollment, send all such data to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee’s personal representative specifically requests receive the data; and (C) Send data received from another payer under this paragraph in the electronic form and format it was received. (vii) Applicability. (A) The MCO, PIHP, or PAHP must comply with the requirements in paragraph (b)(1)(vi) of this section beginning January 1, 2022 with regard to data: (1) With a date of service on or after January 1, 2016; and (2) That are maintained by the MCO, PIHP, or PAHP. (B) [Reserved] * * * * * ■ 16. Section 438.242 is amended by adding paragraphs (b)(5) and (6) to read as follows: § 438.242 Health information systems. * * * * * (b) * * * (5) Implement an Application Programming Interface (API) as specified in § 431.60 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP and include— (i) All encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating on the basis of capitation payments and adjudicated claims and encounter data from any subcontractors. (ii) [Reserved] (6) Implement, by January 1, 2021, and maintain a publicly accessible standards-based API described in § 431.70, which must include all information specified in § 438.10(h)(1) and (2) of this chapter. * * * * * PART 457—ALLOTMENTS AND GRANTS TO STATES 17. The authority citation for part 457 is revised to read as follows: ■ Authority: 42 U.S.C. 1302. 18. Section 457.700 is amended by— a. Redesignating paragraphs (a)(1) and (2) as paragraphs (a)(2) and (3), respectively; ■ b. Adding paragraph (a)(1); and ■ c. Revising paragraph (c). The addition and revision reads as follows: ■ ■ E:\FR\FM\01MYR2.SGM 01MYR2 25636 § 457.700 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations Basis, scope, and applicability. (a) * * * (1) Section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to States to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage; * * * * * (c) Applicability. The requirements of this subpart apply to separate child health programs and Medicaid expansion programs, except that § 457.730 does not apply to Medicaid expansion programs. Separate child health programs that provide benefits exclusively through managed care organizations may meet the requirements of § 457.730 by requiring the managed care organizations to meet the requirements of § 457.1233(d)(2). ■ 19. Section 457.730 is added to read as follows: § 457.730 Beneficiary access to and exchange of data. (a) Application Programming Interface to support CHIP beneficiaries. A State must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of the current individual beneficiary or the beneficiary’s personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the beneficiary. (b) Accessible content. A State must make the following information accessible to its current beneficiaries or the beneficiary’s personal representative through the API described in paragraph (a) of this section: (1) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and beneficiary cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed; (2) Encounter data no later than 1 business day after receiving the data from providers, other than MCOs, PIHPs, or PAHPs, compensated on the basis of capitation payments; (3) Clinical data, including laboratory results, if a State maintains any such data, no later than one (1) business day after the data is received by the State; and (4) Information, about covered outpatient drugs and updates to such VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 information, including, where applicable, preferred drug list information, no later than one (1) business day after the effective date of the information or updates to such information. (c) Technical requirements. A State implementing an API under paragraph (a) of this section: (1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215; (2) Must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly, including assessments to verify that the API technology is fully and successfully implementing privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data; (3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law: (i) Content and vocabulary standards at 45 CFR 170.213 where such standards are applicable to the data type or element, as appropriate; and (ii) Content and vocabulary standards at 45 CFR part 162 and § 423.160 of this chapter where required by law, or where such standards are applicable to the data type or element, as appropriate. (4) May use an updated version of any standard or all standards required under paragraphs (c)(1) or (3) of this section, where: (i) Use of the updated version of the standard is required by other applicable law, or (ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that: (A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170; (B) For standards at 45 CFR 170.213 and 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and (C) Use of the updated version of a standard does not disrupt an end user’s ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section. (d) Documentation requirements for APIs. For each API implemented in PO 00000 Frm 00128 Fmt 4701 Sfmt 4700 accordance with paragraph (a) of this section, a State must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum the information listed in this paragraph. For the purposes of this section, ‘‘publicly accessible’’ means that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available; (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns; (2) The software components and configurations that an application must use in order to successfully interact with the API and process its response(s); and (3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API. (e) Denial or discontinuation of access to the API. A State may deny or discontinue any third-party application’s connection to the API required under paragraph (a) of this section if the State: (1) Reasonably determines, consistent with its security risk analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the State’s systems; and (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which beneficiaries seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. (f) Beneficiary resources regarding privacy and security. A State must provide in an easily accessible location on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former beneficiaries seeking to E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations access their health information held by the State CHIP agency, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum: (1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application including secondary uses of data, and the importance of understanding the security and privacy practices of any application to which they will entrust their health information; and (2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of OCR and FTC, and how to submit a complaint to: (i) The HHS Office for Civil Rights (OCR); and (ii) The Federal Trade Commission (FTC). (g) Data availability. (1) The State must comply with the requirements in paragraphs (a) through (f) of this section beginning January 1, 2021 with regard to data: (i) With a date of service on or after January 1, 2016; and (ii) That are maintained by the State. (2) [Reserved] ■ 20. Section 457.760 is added to subpart G to read as follows: Jkt 250001 * * * * * (d) Health information systems. (1) The State must ensure, through its contracts, that each MCO, PIHP, and PAHP complies with the health information systems requirements as provided in § 438.242(a), (b)(1) through (4), (c), (d), and (e) of this chapter. (2) Each MCO, PIHP, and PAHP must implement an Application Programming Interface (API) as specified in § 457.730 as if such requirements applied directly to the MCO, PIHP, or PAHP, and include— (i) All encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating on the basis of capitation payments and adjudicated claims and encounter data from any subcontractors. (ii) [Reserved] (3) Implement, by January 1, 2021, and maintain a publicly accessible standards-based API described in § 457.760, which must include all information specified in § 438.10(h)(1) and (2) of this chapter. * * * * * PART 482—CONDITIONS OF PARTICIPATION: HOSPITALS 22. The authority citation for part 482 is revised to read as follows: (a) The State must implement and maintain a publicly accessible, standards-based Application Programming Interface (API) that is conformant with the technical requirements at § 457.730(c), excluding the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations, the documentation requirements at § 457.730(d), and is accessible via a public-facing digital endpoint on the State’s website. (b) The API must provide a complete and accurate directory of— (1) The State’s provider directory information including provider names, addresses, phone numbers, and specialties, updated no later than 30 calendar days after the State receives provider directory information or updates to provider directory information. (2) [Reserved] (c) This section is applicable beginning January 1, 2021. 08:09 May 01, 2020 § 457.1233 Structure and operations standards. ■ § 457.760 Access to published provider directory information. VerDate Sep<11>2014 21. Section 457.1233 is amended by revising paragraph (d) to read as follows: ■ Authority: 42 U.S.C. 1302, 1395hh, and 1395rr, unless otherwise noted. 23. Section 482.24 is amended by adding paragraph (d) to read as follows: ■ § 482.24 Conditions of participation: Medical record services. * * * * * (d) Standard: Electronic notifications. If the hospital utilizes an electronic medical records system or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2), then the hospital must demonstrate that— (1) The system’s notification capacity is fully operational and the hospital uses it in accordance with all State and Federal statutes and regulations applicable to the hospital’s exchange of patient health information. (2) The system sends notifications that must include at least patient name, treating practitioner name, and sending institution name. (3) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with PO 00000 Frm 00129 Fmt 4701 Sfmt 4700 25637 the patient’s expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of: (i) The patient’s registration in the hospital’s emergency department (if applicable). (ii) The patient’s admission to the hospital’s inpatient services (if applicable). (4) To the extent permissible under applicable federal and state law and regulations and not inconsistent with the patient’s expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, either immediately prior to, or at the time of: (i) The patient’s discharge or transfer from the hospital’s emergency department (if applicable). (ii) The patient’s discharge or transfer from the hospital’s inpatient services (if applicable). (5) The hospital has made a reasonable effort to ensure that the system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes: (i) The patient’s established primary care practitioner; (ii) The patient’s established primary care practice group or entity; or (iii) Other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care. ■ 24. Section 482.61 is amended by adding paragraph (f) to read as follows: § 482.61 Condition of participation: Special medical record requirements for psychiatric hospitals. * * * * * (f) Standard: Electronic notifications. If the hospital utilizes an electronic medical records system or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR 170.205(d)(2), then the hospital must demonstrate that— (1) The system’s notification capacity is fully operational and the hospital uses it in accordance with all State and Federal statutes and regulations applicable to the hospital’s exchange of patient health information. (2) The system sends notifications that must include at least patient name, treating practitioner name, and sending institution name. E:\FR\FM\01MYR2.SGM 01MYR2 25638 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations (3) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient’s expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of: (i) The patient’s registration in the hospital’s emergency department (if applicable). (ii) The patient’s admission to the hospital’s inpatient services (if applicable). (4) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient’s expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, either immediately prior to, or at the time of: (i) The patient’s discharge or transfer from the hospital’s emergency department (if applicable). (ii) The patient’s discharge or transfer from the hospital’s inpatient services (if applicable). (5) The hospital has made a reasonable effort to ensure that the system sends the notifications to all applicable post-acute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes: (i) The patient’s established primary care practitioner; (ii) The patient’s established primary care practice group or entity; or (iii) Other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care. PART 485—CONDITIONS OF PARTICIPATION: SPECIALIZED PROVIDERS 25. The authority citation for part 485 is revised to read as follows: ■ Authority: 42 U.S.C. 1302 and 1395hh. 26. Section 485.638 is amended by adding paragraph (d) to read as follows: ■ § 485.638 Conditions of participation: Clinical records. * * * * * (d) Standard: Electronic notifications. If the CAH utilizes an electronic medical records system or other electronic administrative system, which is conformant with the content exchange standard at 45 CFR VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 170.205(d)(2), then the CAH must demonstrate that— (1) The system’s notification capacity is fully operational and the CAH uses it in accordance with all State and Federal statutes and regulations applicable to the CAH’s exchange of patient health information. (2) The system sends notifications that must include at least patient name, treating practitioner name, and sending institution name. (3) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient’s expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, at the time of: (i) The patient’s registration in the CAH’s emergency department (if applicable). (ii) The patient’s admission to the CAH’s inpatient services (if applicable). (4) To the extent permissible under applicable federal and state law and regulations, and not inconsistent with the patient’s expressed privacy preferences, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, either immediately prior to, or at the time of: (i) The patient’s discharge or transfer from the CAH’s emergency department (if applicable). (ii) The patient’s discharge or transfer from the CAH’s inpatient services (if applicable). (5) The CAH has made a reasonable effort to ensure that the system sends the notifications to all applicable postacute care services providers and suppliers, as well as to any of the following practitioners and entities, which need to receive notification of the patient’s status for treatment, care coordination, or quality improvement purposes: (i) The patient’s established primary care practitioner; (ii) The patient’s established primary care practice group or entity; or (iii) Other practitioner, or other practice group or entity, identified by the patient as the practitioner, or practice group or entity, primarily responsible for his or her care. PO 00000 Frm 00130 Fmt 4701 Sfmt 4700 TITLE 45—PUBLIC WELFARE SUBTITLE A—DEPARTMENT OF HEALTH AND HUMAN SERVICES PART 156—HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES 27. The authority citation for part 156 continues to read as follows: ■ Authority: 42 U.S.C. 18021–18024, 18031– 18032, 18041–18042, 18044, 18054, 18061, 18063, 18071, 18082, 26 U.S.C. 36B, and 31 U.S.C. 9701. 28. Section 156.221 is added to read as follows: ■ § 156.221 Access to and exchange of health data and plan information. (a) Application Programming Interface to support enrollees. Subject to paragraph (h) of this section, a QHP issuer on a Federally-Facilitated Exchange must implement and maintain a standards-based Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of a current individual enrollee or the enrollee’s personal representative, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the enrollee. (b) Accessible content. (1) A QHP issuer on a Federally-facilitate Exchange must make the following information accessible to its current enrollees or the enrollee’s personal representative through the API described in paragraph (a) of this section: (i) Data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and enrollee cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed; (ii) Encounter data from capitated providers, no later than one (1) business day after data concerning the encounter is received by the QHP issuer; and (iii) Clinical data, including laboratory results, if the QHP issuer maintains any such data, no later than one (1) business day after data is received by the issuer. (2) [Reserved] (c) Technical requirements. A QHP issuer on a Federally-facilitated Exchange implementing an API under paragraph (a) of this section: (1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215; E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations (2) Must conduct routine testing and monitoring, and update as appropriate, to ensure the API functions properly, including assessments to verify the API is fully and successfully implementing privacy and security features such as, but not limited to, those required to comply with HIPAA privacy and security requirements in parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law protecting privacy and security of individually identifiable data; (3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable, to the data type or data element, unless alternate standards are required by other applicable law: (i) Content and vocabulary standards at 45 CFR 170.213 where such are applicable to the data type or element, as appropriate; and (ii) Content and vocabulary standards at part 162 of this subchapter and 42 CFR 423.160 where required by law, or where such standards are applicable to the data type or element, as appropriate. (4) May use an updated version of any standard or all standards required under paragraphs (c)(1) or (3) of this section, where: (i) Use of the updated version of the standard is required by other applicable law, or (ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that: (A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or part 170 of this subchapter; (B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and (C) Use of the updated version of a standard does not disrupt an end user’s ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section. (d) Documentation requirements for APIs. For each API implemented in accordance with paragraph (a) of this section, a QHP issuer on a FederallyFacilitated Exchange must make publicly accessible, by posting directly on its website and/or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum the information listed in this paragraph. For the purposes of this section, ‘‘publicly accessible’’ means that any person using VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 commonly available technology to browse the internet could access the information without any preconditions or additional steps, such as a fee for access to the documentation; a requirement to receive a copy of the material via email; a requirement to register or create an account to receive the documentation; or a requirement to read promotional material or agree to receive future communications from the organization making the documentation available; (1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns; (2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and (3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API. (e) Denial or discontinuation of access to the API. A QHP issuer on a FederallyFacilitated Exchange may deny or discontinue any third party application’s connection to the API required under paragraph (a) of this section if the QHP issuer: (1) Reasonably determines, consistent with its security risk analysis under 45 CFR part 164 subpart C, that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of personally identifiable information, including protected health information, on the QHP issuer’s systems; and (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which enrollees seek to access their electronic health information as defined at § 171.102 of this subchapter, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. (f) Coordination among payers. (1) A QHP issuer on a Federally-facilitated Exchange must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at 45 CFR 170.213. Such information received by a QHP issuer on a Federally-facilitated Exchange must be incorporated into the QHP issuer’s records about the current enrollee. With the approval and at the direction of a current or former enrollee or the enrollee’s personal representative, a PO 00000 Frm 00131 Fmt 4701 Sfmt 4700 25639 QHP issuer on a Federally-facilitated Exchange must: (i) Receive all such data for a current enrollee from any other payer that has provided coverage to the enrollee within the preceding 5 years; (ii) At any time the enrollee is currently enrolled in the plan and up to 5 years after disenrollment, send all such data to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee’s personal representative specifically requests receive the data; and (iii) Send data received from another payer under this paragraph (f) in the electronic form and format it was received. (2) [Reserved] (g) Enrollee resources regarding privacy and security. A QHP issuer on a Federally-facilitated Exchange must provide in an easily accessible location on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former enrollees seeking to access their health information held by the QHP issuer, educational resources in non-technical, simple and easy-tounderstand language explaining at a minimum: (1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application including secondary uses of data, and the importance of understanding the security and privacy practices of any application to which they will entrust their health information; and (2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of the Office for Civil Rights (OCR) and the Federal Trade Commission (FTC), and how to submit a complaint to: (i) The HHS Office for Civil Rights (OCR); and (ii) The Federal Trade Commission (FTC). (h) Exception. (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraphs (a) through (g) of this section, the issuer must include as part of its QHP application a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of noncompliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section. E:\FR\FM\01MYR2.SGM 01MYR2 25640 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations (2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraphs (a) through (g) of this section if the Exchange determines that making such health plan available through such Exchange is in the interests of qualified individuals in the State or States in which such Exchange operates. (i) Applicability. A QHP issuer on an individual market Federally-facilitated Exchange, not including QHP issuers VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 offering only stand-alone dental plans, must comply with the requirements in paragraphs (a) through (e) and (g) of this section beginning with plan years beginning on or after January 1, 2021, and with the requirements in paragraph (f) of this section beginning with plan years beginning on or after January 1, 2022 with regard to data: (1) With a date of service on or after January 1, 2016; and (2) That are maintained by the QHP issuer for enrollees in QHPs. PO 00000 Frm 00132 Fmt 4701 Sfmt 9990 Dated: January 21, 2020. Seema Verma, Administrator, Centers for Medicare & Medicaid Services. Dated: March 5, 2020. Alex M. Azar II, Secretary, Department of Health and Human Services. [FR Doc. 2020–05050 Filed 4–21–20; 4:15 pm] BILLING CODE P E:\FR\FM\01MYR2.SGM 01MYR2

Agencies

[Federal Register Volume 85, Number 85 (Friday, May 1, 2020)]
[Rules and Regulations]
[Pages 25510-25640]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2020-05050]



[[Page 25509]]

Vol. 85

Friday,

No. 85

May 1, 2020

Part II





Department of Health and Human Services





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





Centers for Medicare & Medicaid Services





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





42 CFR Parts 406, 407, 422, Et al.

45 CFR Part 156





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

Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and 
Regulations

[[Page 25510]]


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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

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

Office of the Secretary

45 CFR Part 156

[CMS-9115-F]
RIN 0938-AT79


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

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

ACTION: Final rule.

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

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

DATES: These regulations are effective on June 30, 2020.

FOR FURTHER INFORMATION CONTACT: 
    Alexandra Mugge, (410) 786-4457, for issues related to 
interoperability, CMS health IT strategy, and technical standards.
    Denise St. Clair, (410) 786-4599, for issues related API policies 
and related standards.
    Natalie Albright, (410) 786-1671, for issues related to Medicare 
Advantage.
    Laura Snyder, (410) 786-3198, for issues related to Medicaid.
    Rebecca Zimmermann, (301) 492-4396, for issues related to Qualified 
Health Plans.
    Meg Barry, (410) 786-1536, for issues related to CHIP.
    Thomas Novak, (202) 322-7235, for issues related to trust exchange 
networks and payer to payer coordination.
    Sharon Donovan, (410) 786-9187, for issues related to federal-state 
data exchange.
    Daniel Riner, (410) 786-0237, for issues related to Physician 
Compare.
    Ashley Hain, (410) 786-7603, for issues related to hospital public 
reporting.
    Melissa Singer, (410) 786-0365, for issues related to provider 
directories.
    CAPT Scott Cooper, USPHS, (410) 786-9465, for issues related to 
hospital and critical access hospital conditions of participation.
    Russell Hendel, (410) 786-0329, for issues related to the 
Collection of Information or the Regulation Impact Analysis sections.

SUPPLEMENTARY INFORMATION: 

Table of Contents

I. Background and Summary of Provisions
    A. Purpose
    B. Overview
    C. Executive Order and MyHealthEData
    D. Past Efforts
    E. Challenges and Barriers to Interoperability
    F. Summary of Major Provisions
II. Technical Standards Related to Interoperability Provisions, and 
Analysis of and Responses to Public Comments
    A. Technical Approach and Standards
    B. Content and Vocabulary Standards
    C. Application Programming Interface (API) Standard
    D. Updates to Standards
III. Provisions of Patient Access Through APIs, and Analysis of and 
Responses to Public Comments
    A. Background on Medicare Blue Button
    B. Expanding the Availability of Health Information
    C. Standards-based API Proposal for MA, Medicaid, CHIP, and QHP 
Issuers on the FFEs
IV. API Access to Published Provider Directory Data Provisions, and 
Analysis of and Responses to Public Comments
    A. Interoperability Background and Use Cases
    B. Broad API Access to Provider Directory Data
V. The Health Information Exchange and Care Coordination Across 
Payers: Establishing a Coordination of Care Transaction To 
Communicate Between Plans Provisions, and Analysis of and Responses 
to Public Comments
VI. Care Coordination Through Trusted Exchange Networks: Trust 
Exchange Network Requirements for MA Plans, Medicaid Managed Care 
Plans, CHIP Managed Care Entities, and QHPs on the FFEs Provisions, 
and Analysis of and Responses to Public Comments
VII. Improving the Medicare-Medicaid Dually Eligible Experience by 
Increasing the Frequency of Federal-State Data Exchanges Provisions, 
and Analysis of and Responses to Public Comments
    A. Increasing the Frequency of Federal-State Data Exchanges for 
Dually Eligible Individuals
    B. Request for Stakeholder Input
VIII. Information Blocking Background and Public Reporting 
Provisions, and Analysis of and Responses to Public Comments
    A. Information Blocking Background
    B. Public Reporting and Prevention of Information Blocking on 
Physician Compare
    C. Public Reporting and Prevention of Information Blocking for 
Eligible Hospitals and Critical Access Hospitals (CAHs)
IX. Provider Digital Contact Information Provisions, and Analysis of 
and Responses to Public Comments
    A. Background
    B. Public Reporting of Missing Digital Contact Information
X. Conditions of Participation for Hospitals and Critical Access 
Hospitals (CAHs) Provisions, and Analysis of and Responses to Public 
Comments
    A. Background
    B. Provisions for Hospitals (42 CFR 482.24(d))
    C. Provisions for Psychiatric Hospitals (42 CFR 482.61(f))
    D. Provisions for CAHs (42 CFR 485.638(d))
XI. Provisions of the Final Regulations
XII. Collection of Information Requirements
    A. Background
    B. Wage Estimates
    C. Information Collection Requirements (ICRs)
XIII. Regulatory Impact Analysis
    A. Statement of Need
    B. Overall Impact
    C. Anticipated Effects
    D. Alternatives Considered
    E. Accounting Statement and Table
    F. Regulatory Reform Analysis Under E.O. 13771
    G. Conclusion
Regulation Text

I. Background and Summary of Provisions

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

[[Page 25511]]

health care decisions, including data about health care prices and 
outcomes, while minimizing reporting burdens on affected health care 
providers and payers. We solicited public comments on the CMS 
Interoperability and Patient Access proposed rule. In this final rule, 
we address those public comments and outline our final policies in the 
respective sections of this rule.

A. Purpose

    This final rule is the first phase of policies centrally focused on 
advancing interoperability and patient access to health information 
using the authority available to the Centers for Medicare & Medicaid 
Services (CMS). We believe this is an important step in advancing 
interoperability, putting patients at the center of their health care, 
and ensuring they have access to their health information. We are 
committed to working with stakeholders to solve the issue of 
interoperability and getting patients access to information about their 
health care, and we are taking an active approach to move participants 
in the health care market toward interoperability and the secure and 
timely exchange of health information by adopting policies for the 
Medicare and Medicaid programs, the Children's Health Insurance Program 
(CHIP), and qualified health plan (QHP) issuers on the individual 
market Federally-facilitated Exchanges (FFEs). For purposes of this 
rule, references to QHP issuers on the FFEs excludes issuers offering 
only stand-alone dental plans (SADPs), unless otherwise noted for a 
specific proposed or finalized policy. Likewise, we are also excluding 
QHP issuers only offering QHPs in the Federally-facilitated Small 
Business Health Options Program Exchanges (FF-SHOPs) from the 
provisions of this rule and so, for purposes of this rule references to 
QHP issuers on the FFEs excludes issuers offering QHPs only on the FF-
SHOPs. We note that, in this final rule, FFEs include FFEs in states 
that perform plan management functions. State-Based Exchanges on the 
Federal Platform (SBE-FPs) are not FFEs, even though consumers in these 
states enroll in coverage through HealthCare.gov, and QHP issuers in 
SBE-FPs are not subject to the requirements in this rule.

B. Overview

    We are dedicated to enhancing and protecting the health and well-
being of all Americans. One critical issue in the U.S. health care 
system is that people cannot easily access their health information in 
interoperable forms. Patients and the health care providers caring for 
them are often presented with an incomplete picture of their health and 
care as pieces of their information are stored in various, unconnected 
systems and do not accompany the patient to every care setting. 
Although more than 95 percent of hospitals \1\ and 75 percent of 
office-based clinicians \2\ are utilizing certified health IT, 
challenges remain in creating a comprehensive, longitudinal view of a 
patient's health history.3 4 5 This siloed nature of health 
care data prevents physicians, pharmaceutical companies, manufacturers, 
and payers from accessing and interpreting important data sets, 
instead, encouraging each group to make decisions based upon a part of 
the information rather than the whole. Without an enforced standard of 
interoperability, data exchanges are often complicated and time-
consuming.
---------------------------------------------------------------------------

    \1\ Office of the National Coordinator. (2019). Hospitals' Use 
of Electronic Health Records Data, 2015-2017. Retrieved from https://www.healthit.gov/sites/default/files/page/2019-04/AHAEHRUseDataBrief.pdf.
    \2\ Office of the National Coordinator. (2019, December 18). 
Health IT Playbook, Section 1: Electronic Health Records. Retrieved 
from https://www.healthit.gov/playbook/electronic-health-records/.
    \3\ Powell, K. R. & Alexander, G. L. (2019). Mitigating Barriers 
to Interoperability in Health Care. Online Journal of Nursing 
Informatics, 23(2). Retrieved from https://www.himss.org/library/mitigating-barriers-interoperability-health-care.
    \4\ Hochman, M., Garber, J., & Robinson, E. J. (2019, August 
14). Health Information Exchange After 10 Years: Time For A More 
Assertive, National Approach. Retrieved from https://www.healthaffairs.org/do/10.1377/hblog20190807.475758/full/.
    \5\ Payne, T. H., Lovis, C., Gutteridge, C., Pagliari, C., 
Natarajan, S., Yong, C., & Zhao, L. (2019). Status of health 
information exchange: A comparison of six countries. Journal of 
Global Health, 9(2). doi: 10.7189/jogh.09.020427.
---------------------------------------------------------------------------

    We believe patients should have the ability to move from payer to 
payer, provider to provider, and have both their clinical and 
administrative information travel with them throughout their journey. 
When a patient receives care from a new provider, a record of their 
health information should be readily available to that care provider, 
regardless of where or by whom care was previously provided. When a 
patient is discharged from a hospital to a post-acute care (PAC) 
setting there should be no question as to how, when, or where their 
data will be exchanged. Likewise, when an enrollee changes payers or 
ages into Medicare, the enrollee should be able to have their claims 
history and encounter data follow so that information is not lost. As 
discussed in more detail in section III. of this final rule, claims and 
encounter data can offer a more holistic understanding of a patient's 
health, providing insights into everything from the frequency and types 
of care provided and for what reason, medication history and adherence, 
and the evolution and adherence to a care plan. This information can 
empower patients to make better decisions and inform providers to 
support better health outcomes.
    For providers in clinical and community settings, health 
information technology (health IT) should be a resource, enabling 
providers to deliver high quality care, creating efficiencies and 
allowing them to access all payer and provider data for their patients. 
Therefore, health IT should not detract from the clinician-patient 
relationship, from the patient's experience of care, or from the 
quality of work life for physicians, nurses, other health care 
professionals, and social service providers. Through standards-based 
interoperability and information exchange, health IT has the potential 
to facilitate efficient, safe, high-quality care for individuals and 
populations.
    All payers should have the ability to exchange data seamlessly with 
other payers for timely benefits coordination or transitions, and with 
health care and social service providers to facilitate more coordinated 
and efficient care. Payers are in a unique position to provide 
enrollees with a comprehensive picture of their claims and encounter 
data, allowing patients to piece together their own information that 
might otherwise be lost in disparate systems. This information can 
contribute to better informed decision making, helping to inform the 
patient's choice of coverage options and care providers to more 
effectively manage their own health, care, and costs.
    We are committed to working with stakeholders to solve the issue of 
interoperability and patient access in the U.S. health care system 
while reducing administrative burdens on providers and are taking an 
active approach using all available policy levers and authorities to 
move participants in the health care market toward interoperability and 
the secure and timely exchange of health care information.

C. Executive Order and MyHealthEData

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

[[Page 25512]]

prices and outcomes, while minimizing reporting burdens on impacted 
providers, and payers, meaning providers and payers subject to this 
rule.
    In support of Executive Order 13813, the Administration launched 
the MyHealthEData initiative. This government-wide initiative aims to 
empower patients by ensuring that they have access to their own health 
information and the ability to decide how their data will be used, 
while keeping that information safe and secure. MyHealthEData aims to 
break down the barriers that prevent patients from gaining electronic 
access to their health information from the device or application of 
their choice, empowering patients and taking a critical step toward 
interoperability and patient data exchange.
    In March 2018, the White House Office of American Innovation and 
the CMS Administrator announced the launch of MyHealthEData, and CMS's 
direct, hands-on role in improving patient access and advancing 
interoperability. As part of the MyHealthEData initiative, we are 
taking a patient-centered approach to health information access and 
moving to a system in which patients have immediate access to their 
computable health information such that they can be assured that their 
health information will follow them as they move throughout the health 
care system from provider to provider, payer to payer. To accomplish 
this, we have launched several initiatives related to data sharing and 
interoperability to empower patients and encourage payer and provider 
competition. We continue to advance the policies and goals of the 
MyHealthEData initiative through various provisions included in this 
final rule.
    As finalized in this rule, our policies are wide-reaching and will 
have an impact on all facets of the health care system. Several key 
touch points of the policies in this rule include:
     Patients: Enabling patients to access their health 
information electronically without special effort by requiring the 
payers subject to this final rule to make data available through an 
application programming interface (API) to which third-party software 
applications connect to make data available to patients for their 
personal use. This encourages patients to take charge of and better 
manage their health care, and thus these initiatives are imperative to 
improving a patient's long-term health outcomes.
     Clinicians and Hospitals: Ensuring that health care 
providers have ready access to health information about their patients, 
regardless of where the patient may have previously received care. We 
are also implementing policies to prevent health care providers from 
inappropriately restricting the flow of information to other health 
care providers and payers. Finally, we are working to ensure that 
better interoperability reduces the burden on health care providers.
     Payers: Implementing requirements to ensure that payers 
(that is, entities and organizations that pay for health care), such as 
payers in Medicare Advantage, Medicaid, and CHIP, make enrollee 
electronic health information held by the payer available through an 
API such that, with use of software expected to be developed by payers 
and third parties, the information becomes easily accessible to the 
enrollee and data flow seamlessly with the enrollee as such enrollees 
change health care and social service providers and payers. 
Additionally, our policies ensure that payers make it easy for current 
and prospective enrollees to identify which providers are within a 
given plan's network in a way that is simple and easy for enrollees to 
access and understand, and thus find the providers that are right for 
them.
    As a result of our efforts to standardize data and technical 
approaches to advance interoperability, we believe health care 
providers and their patients, as well as other key participants within 
the health care ecosystem such as payers, will have appropriate access 
to the information necessary to coordinate individual care; analyze 
population health trends, outcomes, and costs; and manage benefits and 
the health of populations, while tracking progress through quality 
improvement initiatives. We are working with other federal partners 
including the Office of the National Coordinator for Health Information 
Technology (ONC) on this effort with the clear objectives of improving 
patient access and care, alleviating provider burden, and reducing 
overall health care costs, all while taking steps to protect the 
privacy and security of patients' personal health information. As 
evidence of this partnership, ONC is releasing the ONC 21st Century 
Cures Act final rule (published elsewhere in this issue of the Federal 
Register) in tandem with this final rule. It is this coordinated 
federal effort, in conjunction with strong support and innovation from 
our stakeholders, that will help us move ever closer to true 
interoperability.

D. Past Efforts

    The Department of Health and Human Services (HHS) has been working 
to advance the interoperability of electronic health information for 
over 15 years. For a detailed explanation of past efforts, see the CMS 
Interoperability and Patient Access proposed rule (84 FR 7612 through 
7614).

E. Challenges and Barriers to Interoperability

    Through significant stakeholder feedback, we understand that there 
are many barriers to interoperability, which have obstructed progress 
over the years. We have conducted stakeholder meetings and roundtables; 
solicited comments via RFIs; and received additional feedback through 
letters and rulemaking. All of this input together contributed to the 
policies in our Interoperability and Patient Access proposed rule, and 
when combined with the comments we received on the proposed rule, the 
content of this final rule. Some of the main barriers shared with us, 
specifically patient identification, lack of standardization, 
information blocking, the lack of adoption and use of certified health 
IT among post-acute care (PAC) providers, privacy concerns, and 
uncertainty about the requirements of the Health Insurance Portability 
and
    Accountability Act of 1996 (HIPAA) Privacy, Security, and Breach 
Notification Rules, were discussed in the proposed rule (84 FR 7614 
through 7617). While we have made efforts to address some of these 
barriers in this final rule and through prior rules and actions, we 
believe there is still considerable work to be done to overcome some of 
these challenges toward achieving interoperability, and we will 
continue this work as we move forward with our interoperability 
efforts.

F. Summary of Major Provisions

    This final rule empowers patients in MA organizations, Medicaid and 
CHIP FFS programs, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs, by finalizing several 
initiatives that will break down those barriers currently keeping 
patients from easily accessing their electronic health care 
information. Additionally, the rule creates and implements new 
mechanisms to enable patients to access their own health care 
information through third-party software applications, thereby 
providing them with the ability to decide how, when, and with whom to 
share their information.

[[Page 25513]]

    We are finalizing with modifications our proposal to require MA 
organizations, Medicaid and CHIP FFS programs, Medicaid managed care 
plans, CHIP managed care entities, and QHP issuers on the FFEs to 
implement and maintain a standards-based Patient Access API. This 
Patient Access API must meet the technical standards finalized by HHS 
in the ONC 21st Century Cures Act final rule (published elsewhere in 
this issue of the Federal Register) at 45 CFR 170.215 (currently 
including Health Level 7[supreg] (HL7) Fast Healthcare Interoperability 
Resources[supreg] (FHIR) Release 4.0.1) and the content and vocabulary 
standards finalized by HHS in the ONC 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register) at 45 CFR 
170.213, as well as content and vocabulary standards at 45 CFR part 162 
and the content and vocabulary standards at 42 CFR 423.160. We are 
finalizing that through the Patient Access API, payers must permit 
third-party applications to retrieve, with the approval and at the 
direction of a current enrollee, data specified at 42 CFR 422.119, 
431.60, 457.730, and 45 CFR 156.221. Specifically, we are requiring 
that the Patient Access API must, at a minimum, make available 
adjudicated claims (including provider remittances and enrollee cost-
sharing); encounters with capitated providers; and clinical data, 
including laboratory results (when maintained by the impacted payer). 
Data must be made available no later than one (1) business day after a 
claim is adjudicated or encounter data are received. We are requiring 
that beginning January 1, 2021, impacted payers make available through 
the Patient Access API the specified data they maintain with a date of 
service on or after January 1, 2016. This is consistent with the 
requirements for the payer-to-payer data exchange detailed in section 
V. of this final rule. Together these policies facilitate the creation 
and maintenance of a patient's cumulative health record with their 
current payer.
    We are finalizing regulations to require that MA organizations, 
Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP 
managed care entities make standardized information about their 
provider networks available through a Provider Directory API that is 
conformant with the technical standards finalized by HHS in the ONC 
21st Century Cures Act final rule (published elsewhere in this issue of 
the Federal Register) at 45 CFR 170.215, excluding the security 
protocols related to user authentication and authorization and any 
other protocols that restrict availability of this information to 
particular persons or organizations. Authentication and authorization 
protocols are not necessary when making publicly available data 
accessible via an API. We are finalizing that the Provider Directory 
API must be accessible via a public-facing digital endpoint on the 
payer's website to ensure public discovery and access. At a minimum, 
these payers must make available via the Provider Directory API 
provider names, addresses, phone numbers, and specialties. For MA 
organizations that offer MA-PD plans, they must also make available, at 
a minimum, pharmacy directory data, including the pharmacy name, 
address, phone number, number of pharmacies in the network, and mix 
(specifically the type of pharmacy, such as ``retail pharmacy''). All 
directory information must be made available to current and prospective 
enrollees and the public through the Provider Directory API within 30 
calendar days of a payer receiving provider directory information or an 
update to the provider directory information. The Provider Directory 
API is being finalized at 42 CFR 422.120 for MA organizations, at 42 
CFR 431.70 for Medicaid state agencies, at 42 CFR 438.242(b)(6) for 
Medicaid managed care plans, at 42 CFR 457.760 for CHIP state agencies, 
and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. Here we 
are finalizing that access to the published Provider Directory API must 
be fully implemented by January 1, 2021. We do strongly encourage 
payers to make their Provider Directory API public as soon as possible 
to make and show progress toward meeting all the API requirements being 
finalized in this rule.
    We are finalizing our proposal, with certain modifications as 
detailed in section V. of this final rule, to require MA organizations, 
Medicaid managed care plans, CHIP managed care entities, and QHP 
issuers on the FFEs to coordinate care between payers by exchanging, at 
a minimum, the data elements specified in the current content and 
vocabulary standard finalized by HHS in the ONC 21st Century Cures Act 
final rule (published elsewhere in this issue of the Federal Register) 
at 45 CFR 170.213 (currently the ``United States Core Data for 
Interoperability'' (USCDI) version 1 \6\). This payer-to-payer data 
exchange requires these payers, as finalized at 42 CFR 422.119(f) for 
MA organizations, at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care 
plans (and by extension under Sec.  457.1216 CHIP managed care 
entities), and at 45 CFR 156.221(f) for QHP issuers on the FFEs, to 
send, at a current or former enrollee's request, specific information 
they maintain with a date of service on or after January 1, 2016 to any 
other payer identified by the current enrollee or former enrollee. This 
is consistent with the Patient Access API detailed in section III. of 
this final rule. We are also finalizing a provision that a payer is 
only obligated to share data received from another payer under this 
regulation in the electronic form and format it was received. This is 
intended to reduce burden on payers. We are finalizing that this payer-
to-payer data exchange must be fully implemented by January 1, 2022.
---------------------------------------------------------------------------

    \6\ Office of the National Coordinator. (n.d.). U.S. Core Data 
for Interoperability (USCDI). Retrieved from https://www.healthit.gov/isa/us-core-data-interoperability-uscdi.
---------------------------------------------------------------------------

    In response to comments discussed more fully below, we are not 
finalizing our proposal to require MA organizations, Medicaid managed 
care plans, CHIP managed care entities, and QHP issuers on the FFEs to 
participate in a trusted exchange network given the concerns commenters 
raised regarding the need for a mature Trusted Exchange Framework and 
Common Agreement (TEFCA) to be in place first, and appreciating that 
work on TEFCA is ongoing at this time.
    We are finalizing the requirements that all states participate in 
daily exchange of buy-in data, which includes both sending data to CMS 
and receiving responses from CMS daily, and that all states submit the 
MMA file data to CMS daily by April 1, 2022 in accordance with 42 CFR 
406.26, 407.40, and 423.910, respectively, as proposed. These 
requirements will improve the experience of dually eligible individuals 
by improving the ability of providers and payers to coordinate 
eligibility, enrollment, benefits, and/or care for this population.
    We are finalizing our proposal to include an indicator on Physician 
Compare for the eligible clinicians and groups that submit a ``no'' 
response to any of the three prevention of information blocking 
statements for MIPS. In the event that these statements are left blank, 
the attestations will be considered incomplete, and we will not include 
an indicator on Physician Compare. The indicator will be posted on 
Physician Compare, either on the profile pages or in the downloadable 
database, starting with the 2019 performance period data available for 
public reporting starting in late 2020.

[[Page 25514]]

    We are finalizing our proposal to include information on a publicly 
available CMS website indicating that an eligible hospital or critical 
access hospital (CAH) attesting under the Medicare FFS Promoting 
Interoperability Program had submitted a ``no'' response to any of the 
three attestation statements related to the prevention of information 
blocking. In the event that an eligible hospital or CAH leaves a 
``blank'' response, the attestations will be considered incomplete, and 
no information will be posted related to these attestation statements. 
We will post this information starting with the attestations for the 
EHR reporting period in 2019 and expect this information will be posted 
in late 2020.
    Additionally, as detailed in section IX. of this final rule, we are 
finalizing our proposal to publicly report the names and NPIs of those 
providers who do not have digital contact information included in the 
National Plan and Provider Enumeration System (NPPES) system beginning 
in the second half of 2020 as proposed. Additionally, we will continue 
to ensure providers are aware of the benefits of including digital 
contact information in NPPES, and when and where their names and NPIs 
will be posted if they do not include this information. We do strongly 
encourage providers to include FHIR endpoint information in NPPES if 
and when they have the information, as well.
    To further advance electronic exchange of information that supports 
effective transitions of care we are finalizing the requirement for a 
hospital, psychiatric hospital, and CAH, which utilizes an electronic 
medical records system or other electronic administrative system that 
is conformant with the content exchange standard at 45 CFR 
170.205(d)(2) to demonstrate that: (1) Its system's notification 
capacity is fully operational and that it operates in accordance with 
all state and federal statutes and regulations regarding the exchange 
of patient health information; (2) its system sends notifications that 
must include the minimum patient health information specified in 
section X. of this final rule; and (3) its system sends notifications 
directly, or through an intermediary that facilitates exchange of 
health information, and at the time of a patient's registration in the 
emergency department or admission to inpatient services, and also prior 
to, or at the time of, a patient's discharge and/or transfer from the 
emergency department or inpatient services, to all applicable post-
acute care services providers and suppliers, primary care practitioners 
and groups, and other practitioners and groups identified by the 
patient as primarily responsible for his or her care, and who or which 
need to receive notification of the patient's status for treatment, 
care coordination, or quality improvement purposes. We are establishing 
that this policy will be applicable 12 months after publication of this 
rule for hospitals, including psychiatric hospitals, and CAHs to allow 
for adequate and additional time for these institutions, especially 
small and/or rural hospitals as well as CAHs, to come into compliance 
with the new requirements.
    Finally, we note that we included two RFIs in the proposed rule: 
one related to interoperability and health IT adoption in PAC settings 
and one related to the role of patient matching in interoperability and 
improved patient care. We thank commenters for the insights shared on 
these two topics. We are reviewing these comments and will take them 
into consideration for potential future rulemaking.
    Throughout this final rule, we refer to terms such as ``patient,'' 
``consumer,'' ``beneficiary,'' ``enrollee,'' and ``individual.'' We 
note that every reader of this final rule is a patient and has or will 
receive medical care at some point in their life. In this final rule, 
we use the term ``patient'' as an inclusive term, but because we have 
historically referred to patients using the other terms noted above in 
our regulations, we use specific terms as applicable in sections of 
this final rule to refer to individuals covered under the health care 
programs that CMS administers and regulates. We also note that when we 
discuss patients, we acknowledge a patient's personal representative. 
Per the HIPAA privacy regulations at 45 CFR 164.502(g), a personal 
representative is someone authorized under state or other applicable 
law to act on behalf of the individual in making health care related 
decisions (such as a parent, guardian, or person with a medical power 
of attorney).\7\ Policies in this final rule that require a patient's 
action could be addressed by a patient's personal representative.
---------------------------------------------------------------------------

    \7\ See OCR guidance regarding personal representatives at 
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/.
---------------------------------------------------------------------------

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

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

A. Technical Approach and Standards

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

[[Page 25515]]

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

    \8\ See, for example, Office of the National Coordinator. 
(2015). Connecting Health and Care for the Nation: A Shared 
Nationwide Interoperability Roadmap, Final Version 1.0. Retrieved 
from https://www.healthit.gov/sites/default/files/hie-interoperability/nationwide-interoperability-roadmap-final-version-1.0.pdf.
---------------------------------------------------------------------------

    We summarize the public comment we received on use of the PHSA 
definition of ``interoperability'' and provide our response.
    Comment: One commenter specifically supported the use of the PHSA 
definition of ``interoperability''.
    Response: We appreciate the commenter's support.
    A core policy principle we aim to support across all policies in 
this rule is that every American should be able, without special effort 
or advanced technical skills, to see, obtain, and use all 
electronically available information that is relevant to their health, 
care, and choices--of plans, providers, and specific treatment options. 
In the proposed rule, we explained this included two types of 
information: personal health information that health care providers and 
health plans, or payers, must make available to an individual, such as 
their current and past medical conditions and care received; and 
information that is of general interest and should be widely available, 
such as plan provider networks, the plan's formulary, and coverage 
policies (84 FR 7619).
    We also discussed that while many consumers today can often access 
their own electronic health information through patient or enrollee 
portals and proprietary applications made available by various 
providers and health plans, they must typically go through separate 
processes to obtain access to each system, and often need to manually 
aggregate information that is delivered in various, often non-
standardized, formats. The complex tasks of accessing and piecing 
together this information can be burdensome and frustrating to 
consumers.
    An API can be thought of as a set of commands, functions, 
protocols, or tools published by one software developer (``A'') that 
enable other software developers to create programs (applications or 
``apps'') that can interact with A's software without needing to know 
the internal workings of A's software, all while maintaining consumer 
privacy data standards.\9\ This is how API technology enables the 
seamless user experiences associated with applications familiar from 
other aspects of many consumers' daily lives, such as travel and 
personal finance. Standardized, transparent, and pro-competitive API 
technology can enable similar benefits to consumers of health care 
services.\10\
---------------------------------------------------------------------------

    \9\ See https://www.hl7.org/fhir/security.html for information 
on how FHIR servers and resources integrate privacy and security 
protocols into the data exchange via an API.
    \10\ ONC has made available a succinct, non-technical overview 
of APIs in context of consumers' access to their own medical 
information across multiple providers' EHR systems, which is 
available at the HealthIT.gov website at https://www.healthit.gov/api-education-module/story_html5.html.
---------------------------------------------------------------------------

    While acknowledging the limits of our authority to require use of 
APIs to address our goals for interoperability and data access, we 
proposed to use our programmatic authority to require that a variety of 
data be made accessible by requiring that MA organizations, Medicaid 
state agencies, Medicaid managed care plans, CHIP agencies, CHIP 
managed care entities, and QHP issuers on the FFEs, adopt and implement 
``openly published,'' or secure, standards-based APIs. In the CMS 
Interoperability and Patient Access proposed rule, we used the short 
form terminology, ``open API''. We appreciate that this term can be 
misunderstood to mean ``open'' as in ``not secure''. In actuality, an 
``open API'' is a secure, standards-based API that has certain 
technical information openly published to facilitate uniform use and 
data sharing in a secure, standardized way. To avoid this 
misinterpretation, we will use the term ``standards-based API'' in this 
final rule where we used ``open API'' in the proposed rule. This is 
also in better alignment with the terminology used in the ONC 21st 
Century Cures Act proposed rule (84 FR 7453) and final rule (published 
elsewhere in this issue of the Federal Register). We noted that having 
certain data available through standards-based APIs would allow 
impacted enrollees to use the application of their choice to access and 
use their own electronic health information and other related 
information to manage their health. See section III.C.2.a. of the CMS 
Interoperability and Patient Access proposed rule for further 
discussion (84 FR 7629).
    Much like our efforts under Medicare Blue Button 2.0, also part of 
the MyHealthEData initiative, which made Parts A, B, and D claims and 
encounter data available via an API to Medicare beneficiaries, the 
policies in this rule extend these benefits to even more patients. As 
of January 2020, over 53,000 Medicare beneficiaries have taken 
advantage of Blue Button. Currently, there are 55 production 
applications and over 2,500 developers working in the Blue Button 
sandbox. For more information on Blue Button 2.0 see section III. of 
this final rule. As we noted in the CMS Interoperability and Patient 
Access proposed rule, we believe that our Patient Access API, in 
particular, will result in claims and encounter information becoming 
easily accessible for the vast majority of patients enrolled with 
payers regulated by CMS. As finalized, these policies will apply to all 
MA organizations, all Medicaid and CHIP FFS programs, all types of 
Medicaid managed care plans (MCOs, PIHPs, and PAHPs), as well as CHIP 
managed care entities, and QHP issuers on the FFEs. We hope that states 
operating Exchanges might consider adopting similar requirements for 
QHPs on the State-Based Exchanges (SBEs), and that other payers in the 
private sector might consider voluntarily offering data accessibility 
of the type included in the policies being finalized here so that even 
more patients across the American health care system can easily have 
and use such information to advance their choice and participation in 
their health care. In this way, we hope that the example being set by 
CMS will raise consumers' expectations and

[[Page 25516]]

encourage other payers in the market to take similar steps to advance 
patient access and empowerment outside the scope of the requirements 
being finalized in this rule.
    We explained in the CMS Interoperability and Patient Access 
proposed rule (84 FR 7620) that those seeking further information 
regarding what a standards-based API is are encouraged to review the 
discussion of the standardized API criterion and associated policy 
principles and technical standards included in ONC's 21st Century Cures 
Act proposed rule (84 FR 7424) and final rule (published elsewhere in 
this issue of the Federal Register). These rules provide more detailed 
information on API functionality and interoperability standards 
relevant to electronic health information. We noted that while that 
discussion was specific to health IT, including Electronic Health 
Records (EHR) systems, certified under ONC's Health IT Certification 
Program rather than the information systems generally used by payers 
and plan issuers for claims, encounters, or other administrative or 
plan operational data, it included information applicable to 
interoperability standards, as well as considerations relevant to 
establishing reasonable and non-discriminatory terms of service for 
applications seeking to connect to the standards-based API discussed in 
this rule. While we reiterate that we did not propose to require payers 
to use Health IT Modules certified under ONC's program to make 
administrative data such as claims history or provider directory 
information available to enrollees, we believe that the discussion of 
APIs and related standards in the ONC 21st Century Cures Act rules will 
be of use to those seeking to better understand the role of APIs in 
health care information exchange.
    We also discussed in our proposed rule how other industries have 
advanced the sort of standards-based API-driven interoperability and 
innovation that we seek in the health system (84 FR 7620). We have 
sought to collaborate and align with ONC's proposed and final policies 
specifically related to APIs under the Cures Act as we developed and 
finalized these policies. In general, as we noted in our proposed rule, 
we believe the following three attributes of standards-based APIs are 
particularly important to achieving the goal of offering individuals 
convenient access, through applications they choose, to available and 
relevant electronic health and health-related information:
     The API technologies themselves, not just the data 
accessible through them, are standardized;
     The APIs are technically transparent; and
     The APIs are implemented in a pro-competitive manner.
    In that section of the CMS Interoperability and Patient Access 
proposed rule, we discussed these concepts generally and how they were 
applicable in the health care context for all payers, and explained how 
these were relevant to our specific proposals, which are discussed in 
detail in section III. of this final rule. To revisit this full 
discussion, see the proposed rule (84 FR 7620 through 7621). We did not 
receive comments on this general discussion. Any comments on specific 
proposals that refer to these three attributes are discussed in this 
final rule in the context of the specific proposals.
2. Privacy and Security Concerns in the Context of APIs
    As we noted in the CMS Interoperability and Patient Access proposed 
rule, HHS has received a wide range of stakeholder feedback on privacy 
and security issues in response to prior proposals \11\ about policies 
related to APIs that would allow consumers to use an app of their 
choosing to access protected health information (PHI) held by or on 
behalf of a HIPAA covered entity. Such feedback included concerns about 
potential security risks to PHI created by an API connecting to third-
party applications and the implications of an individual's data being 
shared with these third-party apps at the direction of the individual.
---------------------------------------------------------------------------

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

    As we discussed in our Interoperability and Patient Access proposed 
rule (84 FR 7621), deploying API technology would offer consumers the 
opportunity to access their electronic health information held by 
covered entities (including, but not limited to MA organizations, the 
Medicare Part A and B programs, the Medicaid program, CHIP, QHP issuers 
on the FFEs, and other health insurance issuers in the private 
markets), and would not lessen any such covered entity's duties under 
HIPAA and other laws to protect the privacy and security of information 
it creates, receives, maintains, or transmits, including but not 
limited to PHI. A covered entity implementing an API to enable 
individuals to access their health information must take reasonable 
steps to ensure an individual's information is only disclosed as 
permitted or required by applicable law. The entity must take greater 
care in configuring and maintaining the security functionalities of the 
API and the covered entities' electronic information systems to which 
it connects than would be needed if it was implementing an API simply 
to allow easier access to widely available public information. In 
accordance with the HIPAA Privacy and Security Rules, the covered 
entity is required to implement reasonable safeguards to protect PHI 
while in transit. If an individual requests their PHI in an EHR be sent 
to the third party by unencrypted email or in another unsecure manner, 
which the individual has a right to request, reasonable safeguards 
could include, for example, carefully checking the individual's email 
address for accuracy and warning the individual of risks associated 
with the unsecure transmission. We note that the standards-based APIs 
discussed in this final rule are secure methods of data exchange.
    HIPAA covered entities and their business associates continue to be 
responsible for compliance with the HIPAA Rules, the Federal Trade 
Commission Act (FTC Act), and all other laws applicable to their 
business activities including but not limited to their handling of 
enrollees' PHI and other data. As we stated in the CMS Interoperability 
and Patient Access proposed rule (84 FR 7610), nothing proposed in that 
rule was intended to alter or should be construed as altering existing 
responsibilities to protect PHI under the HIPAA Rules or any other laws 
that are currently applicable.
    However, we acknowledged that a number of industry stakeholders may 
mistakenly believe that they are responsible for determining whether an 
application to which an individual directs their PHI employs 
appropriate safeguards regarding the information it receives. In the 
proposed rule we discussed Office for Civil Rights (OCR) guidance that 
noted that covered entities are not responsible under the HIPAA Rules 
for the security of PHI once it has been received by a third-party 
application chosen by an individual (84 FR 7621 through 7622).
    Further, we noted in the CMS Interoperability and Patient Access 
proposed rule that the HIPAA Privacy Rule \12\ established the 
individual's right of access, including a right to inspect

[[Page 25517]]

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

    \12\ More information on the Privacy Rule, including related 
rulemaking actions and additional interpretive guidance, is 
available at https://www.hhs.gov/hipaa/for-professionals/privacy/.
    \13\ See 45 CFR 164.524(c)(2) and (3), and 164.308(a)(1), OCR 
HIPAA Guidance/FAQ-2036: https://www.hhs.gov/hipaa/for-professionals/faq/2036/can-an-individual-through-the-hipaa-right/, 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/.
---------------------------------------------------------------------------

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

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

    We recognized that this is a complex landscape for patients, who we 
anticipate will want to exercise due diligence on their own behalf in 
reviewing the terms of service and other information about the 
applications they consider selecting. Therefore, we proposed specific 
requirements on payers to ensure enrollees have the opportunity to 
become more informed about how to protect their PHI, important things 
to consider in selecting an application, and where they can submit a 
complaint if they believe a HIPAA covered entity or business associate 
may not be in compliance with their duties under the HIPAA Rules, or if 
they believe they have been subjected to unfair or deceptive acts or 
practices related to a direct-to-consumer application's privacy 
practices or terms of use. A full discussion of the Enrollee and 
Beneficiary Resources Regarding Privacy and Security provision can be 
found in section III.C.2.h. of this final rule.
    In some circumstances, we noted that the information that we 
proposed to require be made available through an API per a patient's 
request, under the various program-specific authorities authorizing 
this rulemaking, were also consistent with the enrollee's right of 
access for their data held by a covered entity or their business 
associate under the HIPAA Privacy Rule. But we also noted that some 
data to which an individual is entitled to access under HIPAA may not 
be required to be transferred through the API. For instance, when the 
covered entity does not hold certain information electronically. In 
those instances, we noted that the inability to access data via an API 
would in no way limit or alter responsibilities and requirements under 
other law (including though not limited to the HIPAA Privacy, Security, 
and Breach Notification Rules) that apply to the organizations that 
would be subject to this regulation. Even as these requirements are 
finalized, the organization may still be called upon to respond to 
individuals' request for information not available through the API, or 
for all of their information through means other than the API. We 
encouraged HIPAA covered entities and business associates to review the 
OCR website for resources on the individual access standard at https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/ 
to ensure they understand their responsibilities.
    We again encourage HIPAA covered entities and business associates 
to review their responsibilities under HIPAA in light of the recent 
decision in Ciox Health, LLC v. Azar, et al., No. 18-cv-0040 (D.D.C. 
January 23, 2020).\16\ The court order vacates a portion of the HIPAA 
Privacy Rule related to the individual right of access ``insofar as it 
expands the HITECH Act's third-party directive beyond requests for a 
copy of an electronic health record with respect to [protected health 
information] of an individual . . . in an electronic format.'' \17\ 
Generally, the court order vacates a portion of the HIPAA Privacy Rule 
that provides an individual the right to direct a covered entity to 
send protected health information that is not in an EHR to a third 
party identified by the individual.
---------------------------------------------------------------------------

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

    This decision does not affect CMS' programmatic authorities, as 
discussed in detail in section III. of the CMS Interoperability and 
Patient Access proposed rule (83 FR 7629 through 7630) and section III. 
of this final rule, to propose and finalize the Patient Access API for 
the programs specified. Additionally, the court's decision did not 
alter individuals' right under HIPAA to request and obtain a copy of 
their records. Because the goal of the Patient Access API in our 
programs is to give patients access to their own information for their 
own personal use through a third-party app, we believe these policies 
as adopted in this rule remain consistent with the spirit of access 
rights under HIPAA.
    As discussed in detail below, many commenters discussed the issues 
of privacy and security in regard to information made available to 
third-party applications. Here, we summarize the public comments we 
received on general issues and concerns around privacy and security of 
a standards-based API, and provide our responses.
    Comment: A few commenters supported OCR's efforts to more clearly 
account for use cases, or specific situations, in which apps are used 
to exchange patients' electronic health information. Some commenters 
noted support for OCR's FAQ that specifies that covered entities are 
not responsible or liable for the privacy and security of PHI once it 
is transmitted at the individual's direction to and received by a 
third-party application. One commenter expressed concern that CMS and 
ONC proposed requirements would make the safeguards of HIPAA moot if 
HIPAA is not extended to third-party applications that are able under 
this rule to display patient data. Without extending HIPAA, the 
commenter fears payers and providers will be liable if the third-party 
misuses patient data.
    Response: We appreciate the commenters' support. We reiterate that 
HIPAA covered entities and business associates are responsible for 
meeting their HIPAA privacy and security obligations to protect patient 
data they

[[Page 25518]]

maintain, and absent patient requests to the contrary, are obligated to 
take reasonable measures to protect these data in transit. Once these 
data are transmitted and no longer under the control of the covered 
entity or business associate, those entities no longer have any 
obligations under HIPAA for the privacy and security of the PHI, 
because these data are no longer subject to HIPAA. We stress, as 
discussed in the CMS Interoperability and Patient Access proposed rule, 
nothing in this rule alters covered entities' or business associates' 
responsibilities to protect PHI under the HIPAA Privacy and Security 
Rules.
    The only instance per the policies proposed in this rule that would 
allow a payer to deny access to an app, as discussed in the proposed 
rule and underlying the rationale for finalizing 42 CFR 422.119(e), 
431.60(e), 438.242(b)(6) (redesignated as Sec.  438.242(b)(5) see 
section VI. in this rule), 457.730(e), 457.1233(d)(2), and 45 CFR 
156.221(e), would be if the covered entity or its business associate's 
own systems would be endangered if it were to engage with a specific 
third-party application through an API, for instance if allowing such 
access would result in an unacceptable security risk. Therefore, as we 
also noted, covered entities and business associates are free to offer 
advice to patients on the potential risks involved with requesting data 
transfers to an application or entity not covered by HIPAA, but such 
efforts generally must stop at education and awareness or advice 
regarding concerns related to a specific app. For instance, if a payer 
notes that an app a patient requests receive their data does not lay 
out in its privacy policy specifically how the patient's personal data 
will be used, the payer could choose to inform the patient they may not 
want to share their data with that app without a clear understanding of 
how the app may use the data, including details about the app's 
secondary data use policy. If the patient still wants their data to be 
shared, or does not respond to the payer's warning, the payer would 
need to share these data via the API absent an unacceptable security 
risk to the payer's own system. For more information on this ability to 
inform patients, see section III.C.2.g. of this final rule. The 
requirements finalized in this rule do not impact or change obligations 
under the HIPAA Privacy and Security Rules in any way.
    Comment: A few commenters noted discrepancies in the terminology 
used in the OCR FAQ mentioned in the CMS Interoperability and Patient 
Access proposed rule compared to terminology used throughout the CMS 
Interoperability and Patient Access proposed rule and the ONC 21st 
Century Cures Act proposed rule, and suggested that any terminology 
inconsistencies be addressed and harmonized. These commenters noted 
that the OCR FAQ pertains to ``electronic protected health 
information'' (ePHI), and uses the term ``electronic health record 
(EHR) system developer'', which differs from terms used in the CMS 
Interoperability and Patient Access and the ONC 21st Century Cures Act 
proposed rules.
    Response: We appreciate comments regarding variance in the 
terminology used in OCR guidance and the CMS Interoperability and 
Patient Access proposed rule. Regarding the relationship between ePHI 
and electronic health information (EHI), we refer readers to the 
discussion in the ONC 21st Century Cures Act final rule (published 
elsewhere in this issue of the Federal Register). OCR guidance uses the 
term ``electronic health record system developer'' \18\ to refer to a 
health IT developer that develops and maintains electronic health 
record systems containing PHI for a covered entity, and therefore is a 
business associate of those covered entities. The guidance also uses 
``app developer'' to describe the creator of the app that is designated 
to receive an individual's PHI. ONC uses related terms that have a 
specific meaning within the context of ONC programs. For instance, ONC 
uses the term ``health IT developer'' for the purposes of the ONC 
Health IT Certification Program to refer to a vendor, self-developer, 
or other entity that presents health IT for certification or has health 
IT certified under the program. In addition, the ONC 21st Century Cures 
Act proposed rule proposed to define the term ``health IT developer of 
certified health IT'' for the purposes of implementing provisions of 
the Cures Act (84 FR 7510). We do not use these ONC program-specific 
terms in this CMS rule. We simply refer to any developer of a third-
party app, of which an electronic record systems developer may be one.
---------------------------------------------------------------------------

    \18\ See Office of the National Coordinator. (n.d.). Health 
Information Technology. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/health-information-technology/.
---------------------------------------------------------------------------

    Comment: One commenter requested clarification on a covered 
entity's liability under HIPAA if a patient transfers their health 
information from a covered entity's mobile access portal or application 
to a third-party application not covered under HIPAA.
    Response: As noted above, HIPAA covered entities and business 
associates are responsible for meeting their HIPAA privacy and security 
obligations to protect patient data they maintain, and absent patient 
requests to the contrary, are obligated to take reasonable measures to 
protect these data in transit. Once these data are received by a third-
party and no longer under the control of the covered entity or its 
business associate, the covered entity and business associate are not 
liable for the privacy and security of the PHI or any electronic health 
information sent. While HIPAA covered entities and their business 
associates may notify patients of their potential concerns regarding 
exchanging data with a specific third-party not covered by HIPAA, they 
are not required to do so, and they may not substitute their own 
judgment for that of the patient requesting the data be transferred.
    Comment: Several commenters recommended that CMS include a safe 
harbor provision in the regulatory text of this final rule to indicate 
that plans and providers are not responsible for the downstream privacy 
and security of PHI.
    Response: Regarding commenters' interest in a ``safe harbor'' 
provision for covered entities when data is transmitted to a third-
party app, we do not have the authority, nor do we believe it is 
necessary, to incorporate these principles in a safe harbor provision 
under the HIPAA Privacy and Security Rules. Covered entities and 
business associates are not responsible for the data after the data 
have been received by the intended recipient. This has been taken into 
account in developing the requirements for the Patient Access API.
    Comment: Several commenters expressed concerns that app developers 
are not subject to many of the current laws protecting the privacy and 
security of electronic health information. Several commenters requested 
that HHS specify what requirements non-HIPAA covered app developers 
will be subject to.
    Response: We appreciate the commenters' concerns. As discussed in 
the CMS Interoperability and Patient Access proposed rule (84 FR 7622), 
HIPAA protections do not extend to third-party apps (that is, software 
applications from entities that are not covered entities or business 
associates). However, the FTC has the authority to investigate and take 
action against unfair or deceptive trade practices under the FTC Act 
and the FTC Health Breach Notification Rule when a third-party app does 
not adhere to the stated privacy policy. We have shared these comments 
with the FTC. State laws may provide additional protections as well.

[[Page 25519]]

Although CMS cannot regulate the third-party apps directly, and thus 
cannot establish specific requirements for them, we are sharing best 
practices and lessons learned from our experience with Blue Button 2.0, 
as applicable, with app developers to further support strong privacy 
and security practices: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Also, as previously noted, payers will 
be required to share educational resources with patients regarding how 
to choose a third-party application while protecting their health 
information. Further, as discussed in section III. of this final rule, 
we are providing payers with a framework they can use to request that 
third-party apps attest to covering certain criteria in their privacy 
policy, such as information about secondary data use, which payers can 
use to educate patients about their options.
    In addition, there are technical requirements for APIs defined in 
the ONC 21st Century Cures Act proposed rule, and finalized by HHS in 
ONC's final rule (published elsewhere in this issue of the Federal 
Register) at 45 CFR 170.215, that enable and support persistent user 
authentication and app authorization processes. It is important to 
clarify that any app accessing the Patient Access API would be doing so 
only with the approval and at the direction of the specific patient. 
While these technical standards at 45 CFR 170.215 establish the 
requirements for the API itself, when implemented, these technical 
standards in turn set requirements on the app developer for the app's 
identity proofing and authentication processes that must be met in 
order to connect to the API and access the specific patient's data 
through the API, as further discussed in section III. of this final 
rule. These technical requirements do not, however, address concerns 
around data security and use once data are with the third-party. This 
level of privacy and security would be addressed in the app's terms and 
conditions or privacy notice.
    Comment: Many commenters expressed concern regarding the secondary 
use of health information by business partners of third-party 
applications. A few commenters noted that consumers may not always be 
aware of the business partners of third-party apps, especially as this 
information is typically part of a lengthy privacy notice or dense or 
difficult to understand terms and conditions.
    Response: We appreciate the commenters' concerns. As noted, we do 
not have the authority to directly regulate third-party apps. As a 
result, we cannot dictate how an app uses or shares data. We have 
chosen to require payers to educate patients about how to choose a 
third-party app that best mitigates potentially risks related to 
secondary data uses. One way we will address these concerns is to offer 
payers and app developers best practices from our own experiences using 
a patient-centered privacy policy, particularly related to Blue Button 
2.0. As we discuss in section III.C.2.h. of this final rule, we 
recognize that the payers that will be subject to the API provisions of 
this final rule are in the best position to ensure that patients have 
the information that they need to critically assess the privacy and 
security of their designated third-party options, and may be best 
situated to identify for patients the potential implications of sharing 
data and to advise a patient if there is a breach of their data. This 
is why we proposed and are finalizing a requirement at 42 CFR 
422.119(g), 431.60(f), 457.730(f), 438.242(b)(5) (proposed as Sec.  
438.242(b)(6) see section VI. in this rule), and 457.1233(d)(2), and 45 
CFR 156.221(g), detailing the beneficiary and enrollee resources 
regarding consumer-friendly, patient facing privacy and security 
information that must be made available on the websites of the payers 
subject to this final rule. As discussed in greater detail in section 
III.C.2.h. of this final rule, CMS will be providing payers with 
suggested content they can consult and tailor as they work to produce 
the required patient resource document. We are also sharing best 
practices and links to model language of an easy-to-understand, non-
technical, consumer-friendly privacy policy, again building off of our 
lessons learned with Blue Button 2.0, to support payers and developers 
in this effort: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Also, as noted above, we discuss in section 
III. of this final rule, a framework payers can use to request that 
third-party apps attest to covering certain criteria in their privacy 
policy, such as information about secondary data use. It will be 
important to encourage patients' understanding of app privacy policies, 
including secondary use policies. The policies we are finalizing in 
this rule help us support payers and developers as they work to make 
sure patients are informed consumers through education and awareness, 
and that patients understand their rights.
    Comment: Several commenters expressed concerns over the complexity 
of overlapping federal and state privacy laws, which they noted would 
be perpetuated by uncertainty in privacy and security requirements when 
apps become more widely used in the health care space. These commenters 
requested work be done to harmonize state and federal privacy laws. 
Another commenter recommended that Congress enact comprehensive 
consumer privacy protections.
    Response: We appreciate these commenters' concerns and 
recommendations. However, these comments are beyond the scope of this 
regulation.
    Comment: Several commenters recommended that CMS work closely with 
other HHS agencies and the FTC to establish a transparent regulatory 
framework for safeguarding the privacy and security of patient 
electronic health information shared with apps. A few commenters 
recommended CMS establish workgroups to share experiences and technical 
assistance for implementing privacy and security approaches.
    Response: We appreciate the commenters' suggestions. As noted 
above, we have shared commenter's concerns with the FTC and relevant 
HHS Operating Divisions, such as OCR.
3. Specific Technical Approach and Standards
    Achieving interoperability throughout the health system is 
essential to achieving an effective, value-conscious health system 
within which consumers are able to choose from an array of health plans 
and providers. An interoperable system should ensure that consumers can 
both easily access their electronic health information held by plans 
and routinely expect that their claims, encounter, and other relevant 
health history information will follow them smoothly from plan to plan 
and provider to provider without burdensome requirements for them or 
their providers to reassemble or re-document the information. Ready 
availability of health information can be especially helpful when an 
individual cannot access their usual source of care, for instance if 
care is needed outside their regular provider's business hours, while 
traveling, or in the wake of a natural disaster.
    The proposals described in section III.C.2. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7628 through 
7639) would impose new requirements on MA organizations, Medicaid and 
CHIP FFS programs, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs (excluding issuers offering only 
SADPs or issuers in the FF-SHOP,

[[Page 25520]]

unless otherwise noted) to implement standardized, transparent APIs. 
Using the API, these entities would be required to provide current 
enrollees with specified claims and encounter data and certain clinical 
information if such information is maintained. We proposed that these 
entities would also be required to make available through the API 
information already required to be widely available, including provider 
directory and plan coverage information, such as formulary information. 
In developing the proposal delineating the information that would be 
required to be made available through an API, consistent with the 
proposed technical requirements, we were guided by an intent to have 
available through the API all of the individual's electronic health 
information held by the payer in electronic format that is compatible 
with the API or that can, through automated means, be formatted to be 
accurately rendered through the API. We were also guided by an intent 
to make available through standardized, secure API technology all of 
the provider directory and formulary information maintained by the 
impacted payers that can be made compatible with the API.
    Both the API technology itself and the data it makes available must 
be standardized to support true interoperability. Therefore, as 
discussed in detail in the proposed rule, we proposed to require 
compliance with both (1) ONC's 21st Century Cures Act rule proposed 
regulations regarding content and vocabulary standards for representing 
electronic health information as finalized and (2) technical standards 
for an API by which the electronic health information would be required 
to be made available as finalized. For the proposals described in 
section III.C.2.b. of the CMS Interoperability and Patient Access 
proposed rule (which addressed transmissions for purposes other than 
those covered by HIPAA transaction standards, with which all the payers 
subject to this final rule will continue to be required to comply under 
45 CFR part 162), we proposed requiring compliance with the 
interoperability standards proposed for HHS adoption in the ONC 21st 
Century Cures Act proposed rule (84 FR 7424) as finalized.
    In proposing to require that regulated entities comply with ONC-
proposed regulations for non-HIPAA covered transactions (84 FR 7424) 
and therefore, requiring the use of specified standards, we noted that 
we intended to preclude regulated entities from implementing API 
technology using alternative technical standards to those ONC proposed 
for HHS adoption at 45 CFR 170.215, which details the API technical 
standards, including the use of FHIR. Other technical standards that 
would be precluded include, but are not limited to, those not widely 
used to exchange electronic health information in the U.S. health 
system. We further noted that we intended to preclude entities from 
using earlier versions of the technical standards adopted at 45 CFR 
170.215 by requiring compliance with only specified provisions of 45 
CFR part 170, and deliberately excluding others. We also discussed how 
by proposing to require use of the proposed content and vocabulary 
standards as finalized by requiring compliance with 42 CFR 423.160 and 
45 CFR part 162, and proposed at 45 CFR 170.213, we intended to 
prohibit use of alternative standards that could potentially be used 
for these same data classes and elements, as well as earlier versions 
of the adopted standards named in 42 CFR 423.160, 45 CFR part 162, and 
proposed at 45 CFR 170.213.
    While we generally intended to preclude regulated entities from 
using content and vocabulary standards other than those described in 42 
CFR 423.160, 45 CFR part 162, or proposed 45 CFR 170.213 (and technical 
standards at 45 CFR 170.215), we recognized there may be circumstances 
that render the use of other content and vocabulary alternatives 
necessary. As discussed below, we proposed to allow the use of 
alternative content and vocabulary standards in two circumstances. 
First, where other content or vocabulary standards are expressly 
mandated by applicable law, we proposed to permit use of those other 
mandated standards. Second, where no appropriate content or vocabulary 
standard exists within 45 CFR part 162, 42 CFR 423.160, or proposed 45 
CFR 170.213 and 170.215, we proposed we would permit use of any 
suitable gap-filling options, as may be applicable to the specific 
situation.
    We used two separate rulemakings because the 21st Century Cures Act 
proposed rule (84 FR 7424), which included API interoperability 
standards proposed for HHS adoption, would have broader reach than the 
scope of the CMS Interoperability and Patient Access proposed rule (84 
FR 7610). At the same time, we wished to assure stakeholders that the 
API standards required of MA organizations, state Medicaid agencies, 
state CHIP agencies, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs under the proposal would be 
consistent with the API standards proposed by ONC for HHS adoption 
because we would require that the regulated entities follow specified, 
applicable provisions of the ONC-proposed requirements as finalized.
    Requiring that CMS-regulated entities comply with the regulations 
regarding standards finalized by HHS in ONC's 21st Century Cures Act 
rule will support greater interoperability across the health care 
system, as health IT products and applications that would be developed 
for different settings and use cases would be developed according to a 
consistent base of standards that supports more seamless exchange of 
information. In the CMS Interoperability and Patient Access proposed 
rule, we welcomed public comment on our proposal to require compliance 
with the standards proposed for adoption by HHS through ONC's 21st 
Century Cures Act proposed rule, as well as on the best method to 
provide support in identifying and implementing the applicable content 
and vocabulary standards for a given data element.
    Finally, while noting that we believed that the proposal to require 
compliance with the standards proposed by ONC for HHS adoption was the 
best approach, we sought public comment on any alternative by which CMS 
would separately adopt the standards proposed for adoption in the ONC 
21st Century Cures Act proposed rule and identified throughout the CMS 
Interoperability and Patient Access proposed rule, as well as future 
interoperability, content, and vocabulary standards. We stated that we 
anticipated any alternative would include incorporating by reference 
the FHIR R2, R3, and/or R4 based on comments and OAuth 2.0 technical 
standards and the USCDI version 1 content and vocabulary standard 
(described in sections II.A.3.b. and II.A.3.a. of the CMS 
Interoperability and Patient Access proposed rule, respectively) in CMS 
regulation to replace the proposed references to ONC regulations at 45 
CFR 170.215, 170.213, and 170.205, respectively. However, we 
specifically sought comment on whether this alternative would present 
an unacceptable risk of creating multiple regulations requiring 
standards or versions of standards across HHS' programs, and an 
assessment of the benefits or burdens of separately adopting new 
standards and incorporating updated versions of standards in CFR text 
on a program by program basis. Furthermore, we sought comment on: How 
such an option might impact health IT development timelines; how 
potentially creating multiple regulations regarding standards over time 
across HHS might impact system implementation; and other

[[Page 25521]]

factors related to the technical aspect of implementing these 
requirements.
    We summarize the public comments we received regarding separately 
adopting standards in this CMS rule and provide our responses.
    Comment: Many commenters supported CMS' proposed alignment with the 
standards proposed in ONC's 21st Century Cures Act proposed rule to be 
adopted by HHS to promote interoperability, noting it was the most 
effective and efficient approach. Commenters explained that this 
alignment was critical to ensure interoperability across the health 
care industry, and overwhelmingly preferred ``one source of truth'' for 
all standards referenced in the CMS Interoperability and Patient Access 
proposed rule. These commenters explained having highly technical 
standards, including content and vocabulary standards, in different CMS 
and ONC regulations would create the potential for error and 
misalignment of standards or versions of standards across HHS programs. 
Commenters supported alignment across agencies, and indicated concern 
that if the standards were adopted in different regulations, it would 
complicate the process of updating the standards when necessary, and 
increase the cost and burden of data capture, data management, and data 
exchange. Commenters did note opportunities for even greater alignment 
across the CMS and ONC rulemakings at the data element level, 
indicating that the ONC rule should include all data elements required 
in the CMS rule, specifically calling out data elements in an 
Explanation of Benefits (EOB) not specifically included in the USCDI 
(proposed for codification at 45 CFR 170.213).
    Response: We appreciate the commenters' support for alignment of 
the regulations adopted in this final rule with the standards as 
finalized by HHS in the ONC 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register). We agree 
that the best way to ensure continued alignment is to have the 
regulations we are adopting here--governing MA organizations, state 
Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, 
CHIP managed care entities, and QHP issuers on the FFEs--cross 
reference the specific regulations codifying the standards adopted by 
HHS in the ONC 21st Century Cures Act final rule. Our intent is to 
ensure alignment and consistent standards across the regulated 
programs. We agree that this will help support interoperability across 
the health care industry and help set clear and consistent goals for 
all payers, providers, vendors, and developers. CMS and ONC will 
continue to coordinate closely on standards, including content and 
vocabulary standards and impacted data elements and use cases, and we 
will continue to work closely with all stakeholders to ensure that this 
process is consensus-based. Regarding the recommendation to add data 
elements from the EOB not yet included in the USCDI, we have shared 
these recommendations with ONC, and we refer readers to the discussion 
in ONC's 21st Century Cures Act final rule on the USCDI and the 
Standards Version Advancement Process (published elsewhere in this 
issue of the Federal Register).

B. Content and Vocabulary Standards

    The content and vocabulary standards HHS ultimately adopts 
applicable to the data provided through the standards-based API will, 
by necessity, vary by use case and within a use case. For instance, 
content and vocabulary standards supporting consumer access vary 
according to what specific data elements MA organizations, Medicaid and 
CHIP FFS programs, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs have available electronically. 
Where another law does not require use of a specific standard, we 
proposed to require use of, in effect, a catalogue of content and 
vocabulary standards from which the regulated entities may choose in 
order to satisfy the proposed requirements in 42 CFR 422.119, 431.60, 
457.730, 438.252, and 457.1233, and 45 CFR 156.221. A further 
discussion of these proposals can be found in section II.B. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7623 through 
7624). These proposals are detailed in section III.C.2.b. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7626 through 
7639), and comments received on these proposals are summarized with our 
responses in section III.C.2.b. of this final rule. Specifically, we 
note that we proposed to adopt the content and vocabulary standards as 
finalized by HHS in ONC's 21st Century Cures Act final rule (published 
elsewhere in this issue of the Federal Register) at 45 CFR 170.213. 
This standard is currently the USCDI version 1.

C. Application Programming Interface (API) Standard

    In section III.C.2.b. of the CMS Interoperability and Patient 
Access proposed rule, we proposed to require compliance with the API 
technical standard proposed by ONC for HHS adoption at 45 CFR 170.215 
as finalized (84 FR 7589). By requiring compliance with 45 CFR 170.215, 
we proposed to require use of the foundational Health Level 7[supreg] 
(HL7) \19\ Fast Healthcare Interoperability Resources[supreg] (FHIR) 
standard,\20\ several implementation specifications specific to FHIR, 
and complementary security and app registration protocols, specifically 
the Substitutable Medical Applications, Reusable Technologies (SMART) 
Application Launch Implementation Guide (IG) 1.0.0 (including mandatory 
support for ``refresh tokens,'' ``Standalone Launch,'' and ``EHR 
Launch'' requirements), which is a profile of the OAuth 2.0 
specification, as well as the OpenID Connect Core 1.0 standard, 
incorporating errata set 1. A further discussion of these proposals can 
be found in section II.C. (84 FR 7624 through 7625) and the proposals 
are detailed in section III. of the CMS Interoperability and Patient 
Access proposed rule (84 FR 7626 through 7639). Comments received on 
these proposals are summarized with our responses in section III. of 
this final rule.
---------------------------------------------------------------------------

    \19\ Health Level Seven International[supreg] (HL7) is a not-
for-profit, ANSI-accredited standards development organization (SDO) 
focused on developing consensus standards for the exchange, 
integration, sharing, and retrieval of electronic health information 
that supports clinical practice and the management, delivery and 
evaluation of health services. Learn more at ``About HL7'' web page, 
last accessed 06/27/2018.
    \20\ FHIR Overview. (n.d.). Retrieved from https://www.hl7.org/fhir/overview.html.
---------------------------------------------------------------------------

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

[[Page 25522]]

170.215(a)(4). HHS is not finalizing the adoption of FHIR Release 2 or 
FHIR Release 3, API Resource Collection in Health (ARCH) Version 1, or 
the HL7 Consent2Share FHIR Consent Profile Design that were proposed at 
45 CFR 170.215(a)(1), (c)(1), (a)(2), or (c)(2), respectively (84 FR 
7424). For a full discussion, see the ONC 21st Century Cures Act final 
rule (published elsewhere in this issue of the Federal Register). The 
content and vocabulary standards and technical standards finalized by 
HHS in the ONC 21st Century Cures Act final rule provide the foundation 
needed to support implementation of the policies as proposed and now 
finalized in this rule.

D. Updates to Standards

    In addition to efforts to align standards across HHS, we recognized 
in the proposed rule that while we must codify in regulation a specific 
version of each standard, the need for continually evolving standards 
development has historically outpaced our ability to amend regulatory 
text. To address how standards development can outpace our rulemaking 
schedule, we proposed in section III.C.2.b. of the CMS Interoperability 
and Patient Access proposed rule (84 FR 7630 through 7631) that 
regulated entities may use updated versions of required standards if 
use of the updated version is required by other applicable law. In 
addition, under certain circumstances, we proposed to allow use of an 
updated version of a standard if the standard is not prohibited under 
other applicable law.
    For content and vocabulary standards at 45 CFR part 162 or 42 CFR 
423.160, we proposed to allow the use of an updated version of the 
content or vocabulary standard adopted under rulemaking, unless the use 
of the updated version of the standard: Is prohibited for entities 
regulated by that part or the program under that section; Is prohibited 
by the Secretary for purposes of these policies or for use in ONC's 
Health IT Certification Program; or is precluded by other applicable 
law. We remind readers that other applicable law includes statutes and 
regulations that govern the specific entity. For the content and 
vocabulary standards proposed by ONC for HHS adoption at 45 CFR 170.213 
(84 FR 7589) (currently, USCDI version 1),\21\ as well as for API 
technical standards proposed by ONC for HHS adoption at 45 CFR 170.215 
(84 FR 7589) (including HL7 FHIR and other standards and implementation 
guides (IGs) as discussed above),\22\ we proposed to allow the use of 
an updated version of a standard adopted by HHS, provided such updated 
version has been approved by the National Coordinator through the 
Standards Version Advancement Process described in the ONC 21st Century 
Cures Act proposed rule (84 FR 7424), as finalized. A further 
discussion of these proposals can be found in section II.D. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7625 through 
7626). These proposals are also detailed in section III. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7626 through 
7639), and comments received on these proposals are summarized with our 
responses in section III. of this final rule.
---------------------------------------------------------------------------

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

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

A. Background on Medicare Blue Button

    As discussed in the CMS Interoperability and Patient Access 
proposed rule (84 FR 7626), we are committed to advancing 
interoperability, putting patients at the center of their health care, 
and ensuring they have simple and easy access, without special effort, 
to their health information. With the establishment of the initial 
Medicare Blue Button[supreg] service in 2010, Medicare beneficiaries 
became able to download their Part A, Part B, and Part D health care 
claims and encounter data through MyMedicare.gov in either PDF or text 
format. While the original Blue Button effort was a first step toward 
liberating patient health information, we recognized that significant 
opportunities remain to modernize access to that health information and 
the ability to share health information across the health ecosystem. We 
believe that moving to a system in which patients have access to and 
use of their health information will empower them to make better 
informed decisions about their health care. Additionally, 
interoperability, and the ability for health information systems and 
software applications to communicate, exchange, and interpret health 
information in a usable and readable format, is vital to improving 
health care. Allowing access to health information only through PDF and 
text formats limit the utility of and the ability to effectively share 
the health information.
    Medicare Blue Button 2.0 is a new, modernized version of the 
original Blue Button service. It enables beneficiaries to access their 
Medicare Parts A, B, and D claims and encounter data and share that 
electronic health information through an Application Programming 
Interface (API) with applications, services, and research programs they 
select. As discussed in section II.A. of the CMS Interoperability and 
Patient Access proposed rule (see 84 FR 7618 through 7623), API 
technology allows software from different developers to connect with 
one another and exchange electronic health information in electronic 
formats that can be more easily compiled and leveraged by patients and 
their caregivers. Beneficiaries may also select third-party 
applications to compile and leverage their electronic health 
information to help them manage their health and engage in a more fully 
informed way in their health care.
    Today, Blue Button 2.0 contains 4 years of Medicare Part A, B, and 
D data for 53 million Medicare beneficiaries. These data are available 
to patients to help them make more informed decisions. Beneficiaries 
dictate how their data can be used and by whom, with identity and 
authorization controlled through MyMedicare.gov. Medicare beneficiaries 
can authorize sharing their information with an application using their 
MyMedicare.gov account information. Beneficiaries authorize each 
application, service, or research program they wish to share their data 
with individually. A beneficiary can go back to MyMedicare.gov at any 
time and change the way an application uses their information. Using 
Blue Button 2.0, beneficiaries can access their health information; 
share it with doctors, caregivers, or anyone they choose; and get help 
managing and improving their health through a wide range of apps and 
other computer-based services. Blue Button 2.0 is an optional service--
beneficiaries choose the apps and services they want to use.
    Today, Medicare beneficiaries using Blue Button 2.0 can connect 
with apps that keep track of tests and services they need and receive 
reminders, track their medical claims, make appointments and send 
messages to their doctors, get personalized information about their 
symptoms and medical conditions, find health and drug plans, keep track 
of their medical notes and questions, and connect to research 
projects.\23\ These are

[[Page 25523]]

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

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

B. Expanding the Availability of Health Information

1. Patient Benefits of Information Access
    As discussed in the CMS Interoperability and Patient Access 
proposed rule, we believe there are numerous benefits associated with 
individuals having simple and easy access to their health care data 
under a standard that is widely used. Whereas EHR data are frequently 
locked in closed, disparate health systems, care and treatment 
information in the form of claims and encounter data is comprehensively 
combined in a patient's claims and billing history. Claims and 
encounter data, used in conjunction with EHR data, can offer a broader 
and more holistic understanding of an individual's interactions with 
the health care system than EHR data alone. As one example, 
inconsistent benefit utilization patterns in an individual's claims 
data, such as a failure to fill a prescription or receive recommended 
therapies, can indicate that the individual has had difficulty 
financing a treatment regimen and may require less expensive 
prescription drugs or therapies, additional explanation about the 
severity of their condition, or other types of assistance. Identifying 
and finding opportunities to address the individual's non-adherence to 
a care plan are critical to keeping people with chronic conditions 
healthy and engaged so they can avoid hospitalizations. While a health 
plan can use claims and encounter data to help it identify which 
enrollees could benefit from an assessment of why they are not filling 
their prescriptions or who might be at risk for particular problems, 
putting this information into the hands of the individual's chosen care 
provider--such as the doctor or nurse practitioner prescribing the 
medications or the pharmacist who fills the prescriptions--helps them 
to engage the patient in shared decision making that can help address 
some of the reasons the individual might not be willing or able to take 
medications as prescribed. By authorizing their providers to access the 
same information through a standards-based API, individuals can further 
facilitate communication with their care teams. Enabling the provider 
to integrate claims and encounter information with EHR data gives the 
provider the ability to use the combined information, with relevant 
clinical decision support tools, as part of normal care delivery in a 
less burdensome way, leading to improved care. This may be particularly 
important during times of system surge, an event that generates a large 
and sudden demand for health services, for example, when access to such 
information may help to inform patient triage, transfer, and care 
decisions.
    Further, we noted that we believe patients who have immediate 
electronic access to their health information are empowered to make 
more informed decisions when discussing their health needs with 
providers, or when considering changing to a different health plan. We 
discussed that currently not all beneficiaries enrolled in MA plans 
have immediate electronic access to their claims and encounter data and 
those who do have it, cannot easily share it with providers or others. 
The same is true of Medicaid beneficiaries and CHIP enrollees, whether 
enrolled in FFS or managed care programs, and enrollees in QHPs on the 
FFEs. As industries outside of health care continue to integrate 
multiple sources of data to understand and predict their consumers' 
needs, we believe it is important to position MA organizations, 
Medicaid and CHIP FFS programs and managed care entities, and QHP 
issuers on the FFEs to do the same to encourage competition, 
innovation, and value.
    We noted that CMS has programmatic authority over MA organizations, 
Medicaid programs (both FFS and managed care), CHIP (both FFS and 
managed care), and QHP issuers on the FFEs. We proposed to leverage CMS 
authority to make claims and encounter data available through APIs as a 
means to further access for patients in these programs along with other 
plan data (such as provider directory data) as detailed in sections 
III.C. and IV. of the CMS Interoperability and Patient Access proposed 
rule. For a complete discussion of these proposals, see the proposed 
rule (84 FR 7626 through 7640).
2. Alignment with the HIPAA Right of Access
    As discussed in section II. of this final rule, the recent decision 
in Ciox Health, LLC v. Azar, et al. vacates a portion of the HIPAA 
Privacy Rule that provides an individual the right to direct a covered 
entity to send protected health information that is not in an EHR to a 
third party identified by the individual. It does not alter a patient's 
right to request access to their records. In addition, the decision 
does not affect CMS' programmatic authorities, as discussed in detail 
in section III. of the CMS Interoperability and Patient Access proposed 
rule (83 FR 7629 through 7630) and later in this section of this final 
rule. Prior to this decision, in the CMS Interoperability and Patient 
Access proposed rule, we discussed that the HIPAA Privacy Rule, at 45 
CFR 164.524, provides that an individual has a right of access to 
inspect and obtain a copy of their PHI \24\ that is maintained by or on 
behalf of a covered entity (a health plan or covered health care 
provider \25\) in a designated record set.\26\ It was noted that, at 
that time, a covered entity was required to provide the access in any 
readily producible form and format requested by the individual, and 
that the right of access also includes individual's right to direct a 
covered entity to transmit PHI directly to a third party the individual 
designates to receive it.\27\
---------------------------------------------------------------------------

    \24\ See 45 CFR 160.103, definition of protected health 
information.
    \25\ The third type of HIPAA covered entity, a health care 
clearinghouse, is not subject to the same requirements as other 
covered entities with respect to the right of access. See 45 CFR 
164.500(b).
    \26\ See 45 CFR 164.501, definition of designated record set.
    \27\ For more information, see https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/.
---------------------------------------------------------------------------

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

[[Page 25524]]

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

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

1. Introduction
    We proposed to add new provisions at 42 CFR 422.119, 431.60, 
438.242(b)(6) (finalized as Sec.  438.242(b)(5) in this rule; see 
section VI.), 457.730, 457.1233(d), and 45 CFR 156.221, that would, 
respectively, require each MA organization, Medicaid FFS program, 
Medicaid managed care plan, CHIP FFS program, CHIP managed care entity, 
and QHP issuer on an FFE to implement, test, and monitor a standards-
based API that is accessible to third-party applications and 
developers. We noted that states with CHIPs were not required to 
operate FFS systems and that some states' CHIPs were exclusively 
operated by managed care entities. We did not intend to require CHIPs 
that do not operate a FFS program to establish an API; rather, we noted 
that these states may rely on each of their contracted plans, referred 
to throughout the CMS Interoperability and Patient Access proposed rule 
and this final rule as CHIP managed care entities, to set up such a 
system.
    As discussed, the API would allow enrollees and beneficiaries of MA 
organizations, Medicaid and CHIP FFS programs, Medicaid managed care 
plans, CHIP managed care entities, and QHP issuers on the FFEs to 
exercise their HIPAA right of access to certain health information 
specific to their plan electronically, through the use of common 
technologies and without special effort. We explained how ``common 
technologies,'' for purposes of the proposal, means those that are 
widely used and readily available, such as computers, smartphones, or 
tablets.
    The proposals are detailed in section III.C. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7626 through 
7639), and comments received on these proposals and our responses are 
noted below in this final rule.
2. The Standards-Based API Proposal
    In the proposed rule, we addressed the following components of the 
standards-based API. Specifically, we discussed:
     Authority to require implementation of a standards-based 
API by MA organizations, Medicaid and CHIP state agencies, Medicaid 
managed care plans, CHIP managed care entities, and QHP issuers on the 
FFEs;
     The API technical standard and content and vocabulary 
standards;
     Data required to be available through the standards-based 
API and timeframes for data availability;
     Documentation requirements for APIs;
     Routine testing and monitoring of standards-based APIs;
     Compliance with existing privacy and security 
requirements;
     Denial or discontinuation of access to the API;
     Enrollee and beneficiary resources regarding privacy and 
security;
     Exceptions or provisions specific to certain programs or 
sub-programs; and
     Applicability and timing.

We also included an RFI on information sharing between payers and 
providers through APIs.

    Specifically, we proposed nearly identical language for the 
regulations requiring standards-based APIs at 42 CFR 422.119; 431.60, 
and 457.730, and 45 CFR 156.221 for MA organizations, Medicaid state 
agencies, state CHIP agencies, and QHP issuers on the FFEs; Medicaid 
managed care plans would be required, at 42 CFR 438.242(b)(6) 
(finalized as 438.242(b)(5) in this rule; see section VI.), to comply 
with the requirement at 42 CFR 431.60, and CHIP managed care entities 
would be required by 42 CFR 457.1233(d)(2) to comply with the 
requirement at 42 CFR 457.730. As discussed in detail in the CMS 
Interoperability and Patient Access proposed rule, we proposed similar 
if not identical requirements for these various entities to establish 
and maintain a standards-based API, make specified data available 
through that API, disclose API documentation, provide access to the 
API, and make resources available to enrollees. We noted that we 
believed that such nearly identical text is appropriate as the reasons 
and need for the proposal and the associated requirements are the same 
across these programs. We intended to interpret and apply the 
regulations proposed in section III.C. of the CMS Interoperability and 
Patient Access proposed rule similarly and starting with similar text 
is an important step to communicate that to the applicable entities 
that would be required to comply (except as noted below with regard to 
specific proposals).
    In paragraph (a) of each applicable proposed regulation, we 
proposed that the regulated entity (that is, the MA organization, the 
state Medicaid or CHIP agency, the Medicaid managed care plan, the CHIP 
managed care entity, or the QHP issuer on an FFE, as applicable) would 
be required to implement and maintain a standards-based API that 
permits third-party applications to retrieve, with the approval and at 
the direction of the individual patient, data specified in paragraph 
(b) of each regulation through the use of common technologies and 
without special effort from the beneficiary. By ``common technologies 
and without special effort'' by the enrollee, we explained that the 
regulation means use of common consumer technologies, like smart 
phones, home computers, laptops, or tablets, to request, receive, use, 
and approve transfer of the data that would be available through the 
standards-based API technology. By ``without special effort,'' we 
proposed to codify our expectation that third-party software, as well 
as proprietary applications and web portals operated by the payer could 
be used to connect to the API and provide access to the data to the 
enrollee. In the CMS Interoperability and Patient Access proposed rule 
(84 FR 7628 through 7638), we addressed the data that must be made 
available through the API in paragraph (b); the regulation regarding 
the technical standards for the API and the data it contains in 
paragraph (c); the documentation requirements for the API in paragraph 
(d); explicit authority for the payer regulated under each regulation 
to deny or discontinue access to the API in paragraph (e); and, 
requirements for posting information about resources on security and 
privacy for beneficiaries in paragraphs (f) or (g). Additional 
requirements specific to certain programs, discussed in sections IV. 
and V. of the CMS Interoperability and Patient Access proposed rule, 
were also included in some of the regulations that address the API. We 
address those additional requirements in sections IV. and V. of this 
final rule.
a. Authority To Require Implementation of a Standards-Based API
    As noted in the CMS Interoperability and Patient Access proposed 
rule (84 FR 7629 through 7630), the proposal would apply to MA 
organizations, Medicaid

[[Page 25525]]

state agencies and managed care plans, state CHIP agencies and managed 
care entities, and QHP issuers on the FFEs. We noted that the proposal 
for Medicaid managed care plans, at 42 CFR 438.242(b)(6) (finalized as 
438.242(b)(5) in this rule; see section VI.), would require MCOs, 
PIHPs, and PAHPs to comply with the regulation that we proposed for 
Medicaid state agencies at 42 CFR 431.60 as if that regulation applied 
to the Medicaid managed care plan. Similarly, we intended for CHIP 
managed care entities to comply with the requirements we proposed at 42 
CFR 457.730 via the regulations proposed at 42 CFR 457.1233(d)(2). We 
proposed to structure the regulations this way to avoid ambiguity and 
to ensure that the API proposal would result in consistent access to 
information for Medicaid beneficiaries and CHIP enrollees, regardless 
of whether they are in a FFS delivery system administered by the state 
or in a managed care delivery system. We noted that CHIP currently 
adopts the Medicaid requirements at 42 CFR 438.242 in whole. We 
proposed revisions to 42 CFR 457.1233(d)(1) to indicate CHIP's 
continued adoption of 42 CFR 438.242(a), (b)(1) through (5), (c), (d), 
and (e), while we proposed specific text for CHIP managed care entities 
to comply with the regulations proposed at 42 CFR 457.1233(d)(2) in 
lieu of the proposed Medicaid revision, which we noted would add 42 CFR 
438.242(b)(6) (finalized as Sec.  438.242(b)(5) in this rule; see 
section VI.). In our discussion of the specifics of the proposal and 
how we proposed to codify it at 42 CFR 422.119, 431.60, 457.730, and 45 
CFR 156.221, we referred in the CMS Interoperability and Patient Access 
proposed rule and refer in this final rule only generally to 42 CFR 
438.242(b)(5) (proposed as 438.242(b)(6); see section VI.) and 
457.1233(d)(2) for this reason.
(1) Medicare Advantage
    Sections 1856(b) and 1857(e) of the Social Security Act (the Act) 
provide CMS with the authority to add standards and requirements for MA 
organizations that the Secretary finds necessary and appropriate and 
not inconsistent with Part C of the Medicare statute. In addition, 
section 1852(c) of the Act requires disclosure by MA organizations of 
specific information about the plan, covered benefits, and the network 
of providers; section 1852(h) of the Act requires MA organizations to 
provide their enrollees with timely access to medical records and 
health information insofar as MA organizations maintain such 
information. The information required to be made available under these 
authorities through the APIs in this final rule is within the scope of 
information that MA organizations must make available under section 
1852(c) and (h) of the Act and the implementing regulations at 42 CFR 
422.111 and 422.118. As technology evolves to allow for faster, more 
efficient methods of information transfer, so do expectations as to 
what is generally considered ``timely.'' Thus, we noted in the CMS 
Interoperability and Patient Access proposed rule our belief that to 
align the standards with 21st century demands, we must take steps for 
MA enrollees to have immediate, electronic access to their health 
information and plan information. We further noted that the proposed 
requirements were intended to achieve this goal by providing patients 
access to their health information through third-party apps retrieve 
data via the required APIs.
    The CMS Interoperability and Patient Access proposed rule 
provisions for MA organizations relied on our authority in sections 
1856(b) and 1857(e) of the Act (which provide CMS with the authority to 
add standards and requirements for MA organizations), and explained how 
the information to be provided is consistent with the scope of 
disclosure under section 1852(c) and (h) of the Act, to propose that MA 
organizations make specific types of information, at minimum, 
accessible through a standards-based API and require timeframes for 
update cycles. Requirements for the Patient Access API further 
implement and adopt standards for how MA organizations must ensure 
enrollee access to medical records or other health information as 
required by section 1852(h) of the Act. Similarly, the Provider 
Directory API is a means to implement the disclosure requirements in 
section 1852(c) regarding plan providers. Throughout section III.C. of 
the CMS Interoperability and Patient Access proposed rule, we explained 
how and why the standards-based API proposal was necessary and 
appropriate for MA organizations and the MA program. We discussed how 
these requirements would give patients simple and easy access to their 
health information through common technologies, such as smartphones, 
tablets, or laptop computers, without special effort on the part of the 
user by facilitating the ability of patients to get their health 
information from their MA organization through a user-friendly third-
party app. The goals and purposes of achieving interoperability for the 
health care system as a whole are equally applicable to MA 
organizations and their enrollees. Thus, the discussion in section II. 
of the CMS Interoperability and Patient Access proposed rule served to 
provide further explanation as to how a standards-based API proposal is 
necessary and appropriate in the MA program. In addition, we noted that 
having easy access to their claims, encounter, and other health 
information would also facilitate beneficiaries' ability to detect and 
report fraud, waste, and abuse--a critical component of an effective 
programs.
    To the extent necessary, we also relied on section 1860D-12(b)(3) 
of the Act to add provisions specific to the Part D benefit offered by 
certain MA organizations; that provision incorporates the authority to 
add program requirements to the contracts from section 1857(e)(1) of 
the Act. For MA organizations that offer MA Prescription Drug plans, we 
proposed requirements in 42 CFR 422.119(b)(2) regarding electronic 
health information for Part D coverage. We explained that this proposal 
was supported by the disclosure requirements imposed under section 
1860D-4(a) of the Act, requiring Part D claims information, pharmacy 
directory information, and formulary information to be disclosed to 
enrollees. Also, we note here that 42 CFR 423.136(d) requires Part D 
plans to ensure timely access by enrollees to the records and 
information that pertain to them. The APIs in this rule further 
implement and build on these authorities for ensuring that Part D 
enrollees have access to information.
(2) Medicaid and CHIP
    We proposed new provisions at 42 CFR 431.60(a), 457.730, 
438.242(b)(6) (finalized as 42 CFR 438.242(b)(5) in this rule; see 
section VI.), and 457.1233(d)(2) that would require states 
administering Medicaid FFS or CHIP FFS, Medicaid managed care plans, 
and CHIP managed care entities to implement a standards-based API that 
permits third-party applications with the approval and at the direction 
of the beneficiary or enrollee to retrieve certain standardized data. 
The proposed requirement would provide Medicaid beneficiaries' and CHIP 
enrollees simple and easy access to their information through common 
technologies, such as smartphones, tablets, or laptop computers, and 
without special effort on the part of the user.
    For Medicaid, we proposed these new requirements under our 
authority under section 1902(a)(4) of the Act, which requires that a 
state Medicaid plan provide such methods of administration as are found 
by the Secretary to be necessary for the proper and efficient

[[Page 25526]]

operation of the plan, and section 1902(a)(19) of the Act, which 
requires that care and services be provided in a manner consistent with 
simplicity of administration and the best interests of the recipients. 
For CHIP, we proposed these requirements under the authority in section 
2101(a) of the Act, which sets forth that the purpose of title XXI is 
to provide funds to states to provide child health assistance to 
uninsured, low-income children in an effective and efficient manner 
that is coordinated with other sources of health benefits coverage. 
Together we noted that these proposals would provide us with authority 
(in conjunction with our delegation of authority from the Secretary) to 
adopt requirements for Medicaid and CHIP that are necessary to ensure 
the provision of quality care in an efficient and cost-effective way, 
consistent with simplicity of administration and the best interest of 
the beneficiary.
    We noted that we believed that requiring state Medicaid and CHIP 
agencies and managed care plans/entities to take steps to make Medicaid 
beneficiaries' and CHIP enrollees' claims, encounters, and other health 
information available through interoperable technology would ultimately 
lead to these enrollees accessing that information in a convenient, 
timely, and portable way, which is essential for these programs to be 
effectively and efficiently administered in the best interests of 
beneficiaries. Further, we noted that there are independent statutory 
provisions that require the disclosure and delivery of information to 
Medicaid beneficiaries and CHIP enrollees; the proposal would result in 
additional implementation of those requirements in a way that is 
appropriate and necessary in the 21st century. We also noted that we 
believed making this information available in APIs and ultimately apps 
may result in better health outcomes and patient satisfaction and 
improve the cost effectiveness of the entire health care system, 
including Medicaid and CHIP. Having easy access to their claims, 
encounter, and other health information may also facilitate 
beneficiaries' ability to detect and report fraud, waste, and abuse--a 
critical component of an effective programs.
    We discussed that as technology has advanced, we have encouraged 
states, health plans, and providers to adopt various forms of 
technology to improve the accurate and timely exchange of standardized 
health care information. We noted that the proposal would move Medicaid 
and CHIP programs in the direction of enabling better information 
access by Medicaid beneficiaries and CHIP enrollees, which would make 
them active partners in their health care by providing a way for them 
to easily monitor and share their data. By requiring that certain 
information be available in and through standardized formats and 
technologies, we noted that the proposal moved these programs toward 
interoperability, which is key for data sharing and access, and 
ultimately, improved health outcomes. We also noted that states would 
be expected to implement the CHIP provisions using CHIP administrative 
funding, which is limited under sections 2105(a)(1)(D)(v) and 
2105(c)(2)(A) of the Act to 10 percent of a state's total annual CHIP 
expenditures.
(3) Qualified Health Plan Issuers on the Federally-Facilitated 
Exchanges
    We proposed a new QHP minimum certification standard at 45 CFR 
156.221(a) that would require QHP issuers on the FFEs to implement a 
standards-based API that would permit third-party applications, with 
the approval and at the direction of the individual enrollee, to 
retrieve standardized data as specified in the proposal. We also 
proposed to require that the data be made available to QHP enrollees 
through common technologies, such as smartphones or tablets, and 
without special effort from enrollees.
    We proposed the new requirements under our authority in section 
1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as 
amended by the Health Care and Education Reconciliation Act of 2010 
(Pub. L. 111-148, enacted March 23, 2010, and Pub. L. 111-152, enacted 
March 30, 2010, respectively) (collectively referred to as the 
Affordable Care Act), which afforded the Exchanges the discretion to 
certify QHPs that are in the best interests of qualified individuals 
and qualified employers. Specifically, section 1311(e) of the 
Affordable Care Act authorized Exchanges to certify QHPs that meet the 
QHP certification standards established by the Secretary, and if the 
Exchange determined that making available such health plan through such 
Exchange is in the interests of qualified individuals and qualified 
employers in the state in which such Exchange operates.
    In the CMS Interoperability and Patient Access proposed rule, we 
noted specifically in our discussion on QHP issuers on the FFEs, but 
applicable to all payers impacted by this rule, that we believe there 
are numerous benefits associated with individuals having access to 
their health plan data that is built upon widely used standards. The 
ability to easily obtain, use, and share claims, encounter, and other 
health data enables patients to more effectively and easily use the 
health care system. For example, by being able to easily access a 
comprehensive list of their adjudicated claims, patients can ensure 
their providers know what services they have already received, can 
avoid receiving duplicate services, and can help their providers verify 
when prescriptions were filled. We noted that we believe these types of 
activities would result in better health outcomes and patient 
satisfaction and improve the cost effectiveness of the entire health 
care system. Having simple and easy access, without special effort, to 
their health information, including cost and payment information, also 
facilitates patients' ability to detect and report fraud, waste, and 
abuse--a critical component of an effective program. We noted that 
existing and emerging technologies provide a path to make information 
and resources for health and health care management universal, 
integrated, equitable, accessible to all, and personally relevant. 
Specifically, for QHP issuers on the FFEs, we stated that we believe 
generally certifying only health plans that make enrollees' health 
information available to them in a convenient, timely, and portable way 
is in the interests of qualified individuals and qualified employers in 
the state or states in which an FFE operates. We also noted we 
encouraged SBEs to consider whether a similar requirement should be 
applicable to QHP issuers participating in their Exchange.
    We did not receive comments on the authorities discussed in this 
section to implement the Patient Access API. We are finalizing these 
provisions, with the modifications discussed in section III.C. of this 
rule, under this authority. Additionally, we are making two 
modifications to the regulation text to more clearly identify issuers 
subject to the regulation. First, we are modifying the scope of the 
applicability of the regulation to issuers on the individual market 
FFEs, effectively excluding issuers offered through the FF-SHOP, and we 
are explicitly excluding QHP issuers on the FFEs that only offer SADPs.
b. API Technical Standard and Content and Vocabulary Standards
    We proposed to require compliance with 45 CFR 170.215 as finalized 
at 42 CFR 422.119(a) and (c), Sec.  431.60(a) and (c), 457.730(a) and 
(c), 438.242(b)(6) (finalized as 438.242(b)(5) in this rule; see 
section VI.) and 457.1233(d)(2), and 45 CFR 156.221(a) and (c), so that 
MA organizations, Medicaid and CHIP FFS

[[Page 25527]]

programs, Medicaid managed care plans, CHIP managed care entities, and 
QHP issuers on the FFEs implement standards-based API technology 
conformant with the API technical standards finalized by HHS in the ONC 
21st Century Cures Act final rule (published elsewhere in this issue of 
the Federal Register), as discussed in section II.A.3. of the CMS 
Interoperability and Patient Access proposed rule and section II. of 
this final rule. We further proposed to require that the data available 
through the API be in compliance with the regulations regarding the 
following content and vocabulary standards, where applicable to the 
data type or data element, unless an alternate standard is required by 
other applicable law: Standards adopted at 45 CFR part 162 and 42 CFR 
423.160; and standards finalized by HHS in the ONC 21st Century Cures 
Act final rule at 45 CFR 170.213 (USCDI version 1). See section II.A.3. 
of the CMS Interoperability and Patient Access proposed rule for 
further information about how entities subject to this rule would be 
required to utilize these standards. We proposed that both the API 
technical standard and the content and vocabulary standards would be 
required across the MA program, Medicaid program, and CHIP, and by QHP 
issuers on the FFEs.
    With the proposed requirements to implement and maintain an API at 
42 CFR 422.119(a), 431.60(a), and 457.730(a), we proposed corresponding 
requirements at 42 CFR 422.119(c) for MA plans, 431.60(c) for Medicaid 
FFS programs, and 457.730(c) for CHIP FFS programs implementing the 
proposed API technology. At proposed 42 CFR 422.119(c), 431.60(c), and 
457.730(c), MA plans and the state Medicaid or CHIP agency (for states 
that operate CHIP FFS systems) would be required to implement, 
maintain, and use API technology conformant with the standards 
finalized by HHS in the ONC 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register) at 45 CFR 
170.215; for data available through the API, to use content and 
vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and 
finalized at 45 CFR 170.213, unless alternate standards are required by 
other applicable law; and to ensure that technology functions in 
compliance with applicable law protecting the privacy and security of 
the data, including but not limited to 45 CFR parts 162, 42 CFR part 2, 
and the HIPAA Privacy and Security Rules.
    We similarly proposed at 45 CFR 156.221(c) that QHP issuers on the 
FFEs must implement, maintain, and use API technology conformant with 
the API technical standards finalized by HHS in the ONC 21st Century 
Cures Act final rule (published elsewhere in this issue of the Federal 
Register) at 45 CFR 170.215; for data available through the API, use 
content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR 
423.160, and finalized at 45 CFR 170.213, unless alternate standards 
are required by other applicable law; and ensure that technology 
functions in compliance with applicable law protecting the privacy and 
security of the data, including but not limited to 45 CFR part 162, 42 
CFR part 2, and the HIPAA Privacy and Security Rules.
    We noted that we believed these proposals would serve to create a 
health care information ecosystem that allows and encourages the health 
care market to tailor products and services to better serve and compete 
for patients, thereby increasing quality, decreasing costs, and 
empowering patients with information that helps them live better, 
healthier lives. Additionally, under our proposal, clinicians would be 
able to review, with the approval and at the direction of the patient, 
information on the patient's current prescriptions and services 
received by the patient; the patient could also allow clinicians to 
access such information by sharing data received through the API with 
the clinician's EHR system--by forwarding the information once the 
patient receives it or by letting the clinician see the information on 
the patient's smartphone using an app that received the data through 
the API. Developers and providers could also explore approaches where 
patients can authorize release of the data through the API directly to 
the clinician's EHR system.
    We also encouraged payers to consider using the proposed API 
infrastructure as a means to exchange health information for other 
health care purposes, such as to health care providers for treatment 
purposes. Sharing interoperable information directly with the patient's 
health care provider in advance of a patient visit would save time 
during appointments and ultimately improve the quality of care 
delivered to patients. Most clinicians and patients have access to the 
internet, providing many access points for viewing health information 
over secure connections. We noted that we believed these proposed 
requirements would significantly improve patients' experiences by 
providing a mechanism through which they can access their data in a 
standardized, computable, and digital format in alignment with other 
public and private health care entities. We stated that we designed the 
proposals to empower patients to have simple and easy access to their 
data in a usable digital format, and therefore, empower them to decide 
how their health information is going to be used. However, we reminded 
payers, and proposed to codify that the regulation regarding the API 
would not lower or change their obligations as HIPAA covered entities 
to comply with regulations regarding standard transactions at 45 CFR 
part 162.
    Finally, we also proposed to add a new MA contract requirement at 
42 CFR 422.504(a)(18) specifying that MA organizations must comply with 
the requirement for access to health data and plan information under 42 
CFR 422.119.
    We summarize the public comments we received on the Patient Access 
API proposal, generally, and the technical standards we proposed for 
the API and its content, and provide our responses.
    Comment: Many commenters indicated support for the overall proposal 
to require the specified payers to provide patients access to their 
health care information through a standards-based API. These commenters 
supported the goals to provide patients near real-time, electronic 
access to their claims, treatment, and quality information. Many 
commenters were also supportive of provider access to patient data 
through APIs, if the patient consented to (or authorized) access, in 
order to support coordinated care. One commenter was specifically in 
favor of the patient access proposal noting it supports patient access 
to their historical claims information. Finally, one commenter 
requested that CMS explain whether ``API technology'' has the same 
definition as in the ONC proposed rule.
    Response: We appreciate the commenters' support for the Patient 
Access API proposal and are finalizing this policy with modifications, 
as discussed in detail below. We also note that both the CMS and ONC 
rules use the term ``API'' consistently as we work together to align 
technology and standards and forward interoperability across the entire 
health care system. We do note, however, that the Patient Access API 
did not propose to include quality information.
    Comment: One commenter requested CMS specify the historical look-
back period for API exchange. In addition, one commenter requested that 
CMS not require data older than from 2019 be made available through 
APIs due to the implementation costs of standardizing older 
information.

[[Page 25528]]

    Response: We appreciate the commenters' suggestions. The proposed 
rule did not specify a historical look-back period for the Patient 
Access API or limit the timeframe of the data that must be available 
through the API. To ensure consistent implementation and minimize the 
burden on payers, we are finalizing additional text in the applicable 
regulations to specify that MA organizations at 42 CFR 422.119(h), 
state Medicaid FFS programs at 42 CFR 431.60(g), Medicaid managed care 
plans at 42 CFR 438.62(b)(1)(vii), CHIP FFS programs at 42 CFR 
457.730(g), CHIP managed care entities at 42 CFR 457.1233(d), and QHP 
issuers on the FFEs at 45 CFR 156.221(i), beginning January 1, 2021 (or 
plan years beginning on or after January 1, 2021 for QHPs on the FFEs), 
must make available through the Patient Access API data that they 
maintain with a date of service on or after January 1, 2016. This means 
that no information with a date of service earlier than January 1, 2016 
will need to be made available through the Patient Access API. By 
``date of service,'' we mean the date the patient received the item or 
service, regardless of when it was paid for or ordered. This is 
consistent with how we are finalizing the payer-to-payer data exchange 
requirement for MA organizations at 42 CFR 422.119(f), Medicaid managed 
care plans at Sec.  438.62(b)(1)(vi) (made applicable to CHIP managed 
care entities through incorporation in Sec.  457.1216), and QHP issuers 
on the FFEs at 45 CFR 156.221(f). Aligning the years of data available 
through the Patient Access API with the payer-to-payer data exchange 
will minimize cost and burden specific to this regulatory requirement 
and will provide patients with the same timeframe of information as 
payers, furthering transparency. Together these policies facilitate the 
creation and maintenance of a patient's cumulative health record with 
their current payer.
    We do not believe limiting the Patient Access API to data only from 
January 1, 2019 forward is sufficient to help patients most benefit 
from this data availability. However, we do appreciate that making 
older data available for electronic data exchange via the Patient 
Access API is part of the cost of the API. As a result, limiting this 
to data with a date of service of January 1, 2016 forward minimizes 
cost and burden while maximizing patient benefit.
    Comment: A few commenters expressed concerns and indicated that 
they did not believe the Patient Access API proposal would move the 
health care industry toward the stated goal of helping patients make 
more informed care decisions. Several commenters were concerned that 
certain patient groups, such as those with low technology access and/or 
health literacy, would not make use of electronic applications for 
making health care decisions. A few commenters recommended CMS not 
limit patient access to health information through apps alone, 
especially for populations with low technology access and/or literacy.
    Response: We appreciate the commenters' concerns. However, more and 
more Americans are using portable technology like smart phones and 
tablets to conduct a myriad of daily activities. Approximately 81 
percent of U.S. adults reported owning a smartphone and 52 percent 
reported owning a tablet computer in 2019.\28\ An American Community 
Survey Report from the U.S. Census Bureau reported that in 2016, 82 
percent of households reported an internet subscription and 83 percent 
reported a cellular data plan.\29\
---------------------------------------------------------------------------

    \28\ Pew Research Center. (2019, June 12). Retrieved from 
https://www.pewinternet.org/fact-sheet/mobile.
    \29\ Ryan, C. (2018). Computer and internet Use in the United 
States: 2016 (American Community Survey Reports, ACS-39). Retrieved 
from https://www.census.gov/content/dam/Census/library/publications/2018/acs/ACS-39.pdf.
---------------------------------------------------------------------------

    People have a right to be able to manage their health information 
in this way should they choose. We appreciate that not everyone is 
comfortable with, has access to, or uses electronic applications in 
making health care decisions. Such patients will maintain the same 
access that they have to their personal health information today. This 
regulation does not change any existing patient information rights. 
This regulation simply adds new options to ensure patients have the 
information they need, when, and how they need it.
    Comment: Several commenters indicated concerns over what they 
believe would be a costly implementation. A few commenters questioned 
who would be required to bear the costs of implementation and 
maintenance of the APIs, with one commenter requesting CMS explicitly 
permit payers to charge patients and other third-party partners for the 
costs of API implementation and maintenance. In contrast, a few 
commenters recommended that payers should not be allowed to charge 
patients to access their information through APIs. A few commenters 
requested CMS provide federal grant funding to support payers in 
implementing the proposed APIs.
    Response: We appreciate the commenters' concerns and 
recommendations. As discussed in section XIII. of this final rule, we 
are providing updated cost estimates for implementing and maintaining 
the Patient Access API, moving from a single point estimate to a 
range--including a low, primary, and high estimate--to better take into 
account the many factors that impact the cost of implementation. We 
have revised our original estimate of $788,414 per payer, to a primary 
estimate of $1,576,829 per payer, increasing our original estimate by a 
factor of 2 to account for additional information that was provided by 
commenters, which we still believe is relatively minimal in relation to 
the overall budget of these impacted payers. We have included a low 
estimate of $718,414.40 per organization, and a high estimate of 
$2,365,243 per organization. We refer readers to sections XII. and 
XIII. of this final rule for a detailed discussion of our revised cost 
estimates.
    We acknowledge that payers may pass these costs to patients via 
increased premiums. In this way, patients could absorb the cost of the 
API. However, we note the costs of ``premiums'' for MA, Medicaid, and 
CHIP enrollees are primarily borne by the government, as are some 
premium costs for enrollees of QHP issuers on the FFEs who receive 
premium tax credits. We believe that the benefits created by the 
Patient Access API outweigh the costs to patients if payers choose to 
increase premiums as a result.
    At this time, we are not able to offer support for the 
implementation of this policy through federal grant funding. Regarding 
costs for Medicaid managed care plans--since the Patient Access API 
requirements must be contractual obligations under the Medicaid managed 
care contract--the state must include these costs in the development of 
a plan's capitation rates. These capitation rates would be matched at 
the state's medical assistance match rate. State Medicaid agency 
implementation costs would be shared by the state and federal 
government, based on the relevant level of Federal Financial 
Participation, which is 50 percent for general administrative costs and 
90 percent for system development costs.
    Comment: A few commenters described concerns with the maturity of 
APIs for data exchange, as well as the fact that implementation of 
FHIR-based APIs is so new in health care, and expressed that they 
believed there were challenges with meeting the proposed requirement 
given the newness of the needed standards, particularly regarding 
standardizing the required data elements and vocabularies. Several

[[Page 25529]]

commenters were concerned that APIs would not be implemented in a 
standardized fashion, which could lead to interoperability challenges, 
and noted the need for testing for certain use cases, such as 
exchanging data from plan to patients and from plan-to-plan, as well as 
the exchange of provider directory and/or pharmacy/formulary 
information. Several commenters suggested CMS and/or HHS publish 
implementation guides to support consistent and standardized 
implementation of FHIR-based APIs and their associated data standards.
    Response: We appreciate the commenters' concerns. As stated in 
section II. of this final rule, the content and vocabulary standards 
and technical standards HHS is finalizing in the ONC 21st Century Cures 
Act final rule (published elsewhere in this issue of the Federal 
Register) provide the foundation needed to support implementation of 
the policies as proposed and now finalized in this rule. That said, we 
have been working with HL7 and other industry partners to ensure the 
implementation guides requested are freely available to payers to use 
if they choose to use them. Use of these implementation guides is not 
mandatory; however, if a payer does choose to use the publicly 
available guidance, it will limit payer burden and support consistent, 
interoperable API development and implementation. Therefore, use of 
this publicly available guidance can help address the consistency 
concerns raised. Part of the development process of any implementation 
guide is consensus review, balloting, and testing. We are providing a 
link to specific implementations guides and reference implementations 
for all interested payers for both the Patient Access API and the 
Provider Directory API (discussed in section IV. of this final rule) 
that provide valuable guidance to further support sharing the needed 
data using the required standards: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. The implementation guides 
provide information payers can use to meet the requirements of the 
policies being finalized in this rule without having to develop an 
approach independently, saving time and resources. In addition, the 
reference implementations allow payers to see the APIs in action and 
support testing and development.
    Comment: A few commenters indicated concerns with an impending 
proliferation of multiple health plan APIs. Instead, commenters 
recommended a centralized, standardized approach where CMS would 
require the use of Blue Button 2.0 as the platform for providing 
patient access to their health data from all impacted programs 
(Medicare Advantage, Medicaid, CHIP, and QHPs on the FFEs). Commenters 
suggested this would also reduce the burden on app developers to 
develop to one API rather than multiple APIs for various regulated 
entities.
    One commenter requested CMS implement a pilot program for the API 
proposals, citing CMS' Blue Button pilot. One commenter suggested CMS 
convene a group of 10-12 subject matter experts from payers along with 
other relevant stakeholders, such as developers, to meet with CMS, ONC, 
and the FTC to facilitate a smooth path to the API compliance deadline 
and ensure a successful implementation.
    Response: We appreciate the commenters' concerns and 
recommendations. However, we do not wish to require use of the Blue 
Button 2.0 platform as a centralized solution. We believe that industry 
will best have the ability to take interoperability to the next level 
by leading the development of APIs that meet the requirements in the 
regulations at 42 CFR 422.119, 431.60, 438.242, 457.730, and 457.1233, 
as well as 45 CFR 156.221, and which they maintain and control. Blue 
Button is essentially the hub for the Medicare data that CMS, as a 
payer, is making available to our beneficiaries. We do not wish to 
require the centralization of other payer data under this rule. We are 
requiring other payers to also unleash their data and provide the same 
benefits to their enrollees in a standardized way. As noted above, we 
are providing a link to specific implementation guides and reference 
implementations to further support implementation of the Patient Access 
API, as well as the Provider Directory API (discussed in section IV. of 
this final rule), for all payers to use: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Use of these 
freely available materials is not required, but if used will reduce 
development burden for both payers and app developers and facilitate 
industry-wide interoperability.
    Although we appreciate the recommendation to consider a pilot, we 
believe it is important to move ahead with APIs at this time to help 
the health care sector as a whole--including patients, providers and 
payers--start to benefit from this technology as so many other sectors 
have. Also, as previously noted in this final rule, we will share 
lessons learned and best practices from our experience with Blue Button 
as relevant and appropriate to aid the successful implementation of the 
API requirements included in this final rule.
    Regarding the request to convene subject matter experts, we 
reiterate our commitment to continuing our collaboration with our 
federal partners and a diversity of industry stakeholders to ensure a 
successful and smooth implementation of the requirements included in 
this final rule. As this collaboration is ongoing, we do not believe it 
is necessary to convene a new, dedicated group.
    Comment: One commenter recommended that CMS consider standards to 
allow payers and providers to upload patient data directly to a patient 
portal that is owned and managed by the patient. One commenter 
suggested that Health Information Exchanges (HIEs) and Health 
Information Networks (HINs) can be a central source for patients to 
obtain aggregated data in a single location.
    Response: We thank commenters for these recommendations. We 
appreciate that HIEs and HINs can provide patients with valuable 
information, and we look forward to innovative solutions from this 
community. One option would be to leverage APIs and support patient 
access via this technology. We did not propose to use a portal 
approach. One of the advantages of an API approach is that any system 
can make data available and that data can be used by any other system 
that is following the same approach to mapping and transporting data 
without a need to otherwise link the systems or ensure any system-level 
compatibility. Having APIs that can be accessed by third-party apps 
permits the patient to choose how they want to access their data, and 
it promotes innovation in industry to find ways to best help patients 
interact with their data in a way that is most meaningful and helpful 
to them. This same flexibility and interoperability is not easily 
realized through a portal solution, and thus we will not consider this 
recommendation at this time.
    Comment: A few commenters requested CMS confirm the proposed 
preclusion policy for versions of standards and standards themselves at 
42 CFR 422.119(c)(4) for MA organizations, 42 CFR 431.60(c)(4) for 
Medicaid FFS programs, 42 CFR 438.242(b)(5) for Medicaid managed care 
plans, 42 CFR 457.730(c)(4) for CHIP FFS programs, 42 CFR 
457.1233(d)(1) for CHIP managed care entities, and 45 CFR 156.221(c)(4) 
for QHP issuers on the FFEs. These commenters recommended CMS indicate 
that the preclusion policy would prohibit plans from using standards 
not named by CMS for the

[[Page 25530]]

specified API functions, but would not prohibit them from using those 
standards for other use cases not regulated by CMS.
    Response: We confirm that the requirements in this regulation will 
not preclude a payer from using a standard not finalized in this rule 
for use cases that are not specifically discussed in this final rule as 
required for use with the Patient Access API requirement or the 
Provider Directory API requirement (discussed in section IV. of this 
final rule). The content and vocabulary standards being adopted are 
specifically applicable to the data identified and required to be made 
available through the Patient Access API and Provider Directory API; 
this means that if there is a content standard identified in the 
regulation text for the information specified in the regulation text as 
required to be made available through the API, the payer subject to the 
regulation must make available through the API at least these data 
elements using the named content standard. This final rule indicates 
the minimum data that must be made available via these APIs. This does 
not prevent a payer from including more information via either API 
using other available standards. We do strongly support the continued 
use and adoption of FHIR standards for additional use cases to promote 
interoperability and efficient and effective transfer of electronic 
health information, generally.
    Comment: A few commenters expressed concerns that contracts between 
health care providers and payers need to be standardized in order to 
support the requirements of the CMS Interoperability and Patient Access 
proposed rule. A few additional commenters specifically noted that 
timing requirements for making information available through APIs 
should be specified in these contracts. One commenter requested CMS 
prohibit payers from using the Patient Access API requirements to place 
additional contractual demands on health care providers.
    Response: We appreciate the commenters' concerns that there will be 
downstream impacts from the Patient Access API requirements on the 
relationship between payers and their contracted health care providers. 
It will be up to each payer's discretion to address whether this 
information needs to be included in contracts with providers. We do not 
believe it is necessary or appropriate for CMS to adopt regulations to 
standardize all contracts between payers and health care providers to 
accomplish this and are not convinced it would be wise to try to do so 
as each payer is unique, as are their relationships with their 
contracted providers. We are finalizing the implementation timeline 
with modifications from the proposal, as further discussed below, to 
provide payers and providers more time to address all implementation 
issues. We do not anticipate this will create significant additional 
provider burden.
    Comment: Several commenters supported the CMS proposal to adopt 
FHIR as the technical standard for payer APIs. Several commenters 
recommended adopting FHIR Release 4 (R4), also referred to as ``version 
4,'' noting it is more robust than Release 2 (R2), particularly 
regarding laboratory information. A few other commenters supported the 
use of FHIR R2 with the eventual transition to R4. One commenter 
indicated their recommendation on the version of FHIR to adopt (R2 vs 
R4) would depend on the timeline CMS provides payers for compliance. A 
few commenters also suggested CMS align with the version of FHIR that 
ONC adopts in its final rule.
    Response: We thank commenters for their recommendations, which we 
have shared with ONC. We are adopting the standards as finalized by HHS 
in ONC's 21st Century Cures Act final rule (published elsewhere in this 
issue of the Federal Register). As a result, the regulations we are 
finalizing will require the use of the standards identified at 45 CFR 
170.215, which specifically include the use of HL7 FHIR Release 4.0.1. 
As previously stated, we believe that requiring regulated entities to 
comply with the specified standards regulations finalized by HHS in 
ONC's 21st Century Cures Act final rule (published elsewhere in this 
issue of the Federal Register) will support greater alignment and 
interoperability across the health care system, as health IT products 
and applications that will be developed for different settings and use 
cases will be developed according to a consistent base of standards 
that support a more seamless exchange of information. Extending the 
implementation date, as further discussed below, should provide the 
necessary time to build to and use FHIR Release 4.0.1.
    Comment: Although many commenters were generally in support of the 
proposal to use FHIR, several commenters did raise specific 
implementation concerns. Several commenters expressed concerns about 
the costs and burden for payers and providers to update to the 
necessary FHIR standard for content exchange, especially for historical 
data that may not currently be coded to support FHIR. Many of these 
commenters cautioned CMS from proceeding too quickly with FHIR adoption 
and implementation. One commenter noted that semantic interoperability 
is needed for true interoperability but that significant mapping and 
implementation efforts would be needed to achieve this goal. One 
commenter requested CMS provide federal funding to support adoption and 
implementation of FHIR-based APIs.
    Response: We appreciate the commenters' concerns. Regarding the 
readiness of the FHIR standards and the need for semantic 
interoperability, we agree that semantic interoperability is important. 
As noted in this section, though not required for use, we are providing 
a link to specific implementation guides and reference implementations 
that include information about the FHIR resources to use to code and 
map the required data elements as to facilitate interoperable data 
exchange via the Patient Access API, as well as the Provider Directory 
API (discussed in section IV. of this final rule). This addresses the 
concern raised regarding semantic interoperability.
    Regarding burden, as indicated in section XIII. of this final rule, 
we do not anticipate that upgrading to HL7 FHIR Release 4.0.1 and 
preparing historical data for electronic transfer via an API using 
these standards will be more than a relatively minimal expense. We are 
also limiting the amount of historic information that will need to be 
included in the Patient Access API to information with a date of 
service on or after January 1, 2016. This should also help address 
concerns around expense and burden. In addition, we note the discussion 
below regarding the implementation date for this policy appreciating 
the commenters' concerns about moving too quickly. Regarding federal 
funding and costs, we note that for several of the types of payers that 
must comply with the Patient Access API requirements, there is 
significant federal participation in the costs.
    For Medicaid FFS, the provision of enhanced federal match rate is 
addressed in section 1903(a)(3)(A) of the Act and provides a 90 percent 
match rate for the sums expended during such quarter as are 
attributable to the design, development, or installation of such 
mechanized claims processing and information retrieval systems as the 
Secretary determines are likely to provide more efficient, economical, 
and effective administration of the plan.
    For Medicaid managed care plans, since the Patient Access API 
requirements must be contractual obligations under the Medicaid

[[Page 25531]]

managed care contract, the costs must be included in the development of 
a plan's capitation rates. Approved capitation rates would be matched 
at the state's medical assistance match rate.
    As is discussed in section XIII. of this final rule, MA 
organizations may include in their bids the costs of implementing 
provisions of this rule that pertain to MA. The bid, as compared to the 
benchmark, is a significant component of what the government pays MA 
organizations for the provision of Part A and Part B benefits: (1) For 
bids at or below the benchmark, the government pays the bid as the 
capitation amount, and (2) for bids that are above the benchmark, the 
government pays the benchmark and the remainder of the bid amount is 
the premium charged to enrollees of the plan.
    For CHIP, the federal government pays an enhanced federal medical 
assistance percentage (EFMAP) to states for all costs associated with 
CHIP, including systems costs. For federal FY 2020, the EFMAPS will 
range from approximately 65 to 81.5 percent. We note that states will 
be expected to implement the CHIP provisions using CHIP administrative 
funding, which is limited under section 2105(a)(1)(D)(v) and 
2105(c)(2)(A) of the Act to 10 percent of a state's total annual CHIP 
expenditures.
    For QHP issuers on the FFEs, we would expect that issuers would 
raise premiums in the short term in order to cover the costs associated 
with developing and implementing these new standards. To the extent 
that premiums are raised for all QHP issuers on the FFEs, federal 
contributions for the subsidized population in the form of advanced 
premium tax credits will increase proportionally in those initial 
years. Non-subsidized consumers will be expected to pay for the 
increase in premiums themselves and any increases may impact the 
ability of some consumers to afford coverage. Some consumers may 
instead select other options or opt out of coverage if they find QHPs 
unaffordable.
    Comment: A few commenters indicated they did not support CMS' 
proposal to use one standard adopted by HHS (FHIR, which ONC had 
proposed for adoption at 45 CFR 170.215) as the foundational standard 
for standards-based APIs. A few commenters suggested CMS permit the use 
of other standards for exchanging the proposed patient data during a 
transition period or until the FHIR standards are more mature. One 
commenter recommended the use of HIPAA Administrative Simplification 
transaction standards such as those maintained by X12. One commenter 
noted that these HIPAA transaction standards were more accessible to 
payers to represent clinical and case management data. This commenter 
suggested CMS should precisely identify the specific claims data layout 
of the HIPAA Administrative Simplification transaction standards that 
payers would be required to generate and receive because the HIPAA 
Administrative Simplification transaction standards layout varies by 
payer type. However, one commenter noted that patients may not find 
information available through HIPAA standards useful.
    A few commenters suggested CMS should assist affected payers with 
meeting the technical implementation requirements by explaining the 
intent of the required use of the HIPAA Administrative Simplification 
transaction content and vocabulary standards with the HL7 FHIR 
standards. Commenters recommended that CMS review and reconcile 
differences between existing standards that are required for Medicaid 
programs, in particular. For example, commenters suggested identifying 
situations in which CMS has required the use of X12 Electronic Data 
Interchange standards and reconciling these requirements with the 
adoption of the HL7 FHIR standards.
    Response: We appreciate the commenters' concerns and 
recommendations. The policies included in this final rule are not 
intended to alter HIPAA requirements in any way, and these electronic 
data exchanges are not defined transactions under HIPAA regulations, 
therefore there is no need to reconcile use of X12 and the HL7 FHIR 
standards required in this rule. We appreciate that the HIPAA standards 
are more known to many payers at this time; however, we believe the use 
of FHIR standards is important for advancing the policies finalized in 
this rule, which require the transmission of information beyond what is 
available using X12 standards alone. At the same time, as discussed in 
the proposed rule, we are requiring entities subject to this rule to 
use HIPAA content and vocabulary standards at 45 CFR part 162 where 
required by other applicable law, or where such standards are the only 
available standards for the data type or element (84 FR 7623). The use 
of the FHIR standard supports making this information available through 
an API. This is not in conflict with the use of other standards to 
represent the data being transmitted through the API. Instead, the FHIR 
standard can be thought of as defining an envelope, while the contents 
of the envelope can be represented by different content and vocabulary 
standards used in conjunction with FHIR to make data interoperable and 
accessible. For additional information on FHIR standards, we direct 
commenters to the ONC's 21st Century Cures Act final rule (published 
elsewhere in this issue of the Federal Register). To support 
implementation of the policies included in this final rule, we are 
providing a link to specific implementation guides and reference 
implementations that provide valuable guidance to further support 
sharing the needed data using the required standards: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
    As discussed in section II.A.3. of the CMS Interoperability and 
Patient Access proposed rule (84 FR 7622 through 7623), we recognized 
that while we must codify in regulation a specific version of each 
standard, the need for continually evolving standards development has 
historically outpaced our ability to amend regulations. To address how 
standards development can outpace our rulemaking schedule, we offered 
several proposals. We proposed that regulated entities may use an 
updated version of a standard where required by other applicable law. 
We also proposed that regulated entities may use an updated version of 
the standard where not prohibited by other applicable law, under 
certain circumstances.
    We summarize the public comments we received on our approach to 
allowing voluntary adoption of updated standards and provide our 
responses.
    Comment: A few commenters expressed support for the proposal to 
allow plans to upgrade to newer versions of standards supporting data 
classes in the USCDI as standards evolve. A few commenters specifically 
supported the proposal to align with ONC's proposed Standards Version 
Advancement Process and allow payers to adopt newer versions of FHIR 
once approved for use by HHS. A few commenters were concerned with 
backwards compatibility if implementers--payers and developers--are 
permitted to move to new versions of standards, while a few commenters 
supported the proposed requirement to maintain compatibility with 
adopted standards while upgrading to newer standards. One commenter 
expressed concerns with difficulty tracking compliance with standards 
as they move through different versions, generally, and requested CMS 
establish

[[Page 25532]]

a versioning system or identifier for consistency and transparency.
    A few commenters specifically discussed the NCPDP SCRIPT standard; 
however, these comments are out of scope for this rulemaking because 
this rulemaking does not apply to ePrescribing transactions.
    Response: We appreciate the commenters' input. We are adopting the 
ability to use updated standards. As proposed, implementers will need 
to ensure that use of the updated (or newer) standard (instead of the 
standard specified in the applicable regulation) does not disrupt an 
end user's ability to access the data available through the API, which 
should address concerns raised around backward compatibility. 
Specifically, we are finalizing at 42 CFR 422.119(c)(4) for MA 
organizations, 42 CFR 431.60(c)(4) for Medicaid FFS programs, 42 CFR 
438.242(b)(5) for Medicaid managed care plans, 42 CFR 457.730(c)(4) for 
CHIP FFS programs, 42 CFR 457.1233(d)(1) for CHIP managed care 
entities, and 45 CFR 156.221(c)(4) for QHP issuers on the FFEs 
permission to use an updated version of standards adopted at 45 CFR 
170.215, 45 CFR 170.213, 45 CFR part 162, or 42 CFR 423.160, subject to 
the conditions proposed. As long as use of the updated version of a 
standard is not otherwise prohibited, permitted in accordance with the 
conditions described, and, does not disrupt an end user's ability to 
access the data per the requirements of the API, it may be used.
    Regarding the recommendation for CMS to establish a versioning 
system or identifier, we appreciate this recommendation and will review 
the suggestion for future consideration.
c. Data Required To Be Available Through the Standards-Based API & 
Timeframes for Data Availability
    We proposed the content that must be accessible for each enrollee 
of an entity subject to the standards-based API proposal as set out at 
proposed paragraph (b) of 42 CFR 422.119, 431.60, and 457.730, and 45 
CFR 156.221; as noted previously, the regulations for Medicaid managed 
care plans and CHIP managed care entities cross-reference and 
incorporate the regulations we proposed for Medicaid and CHIP FFS 
programs. We noted that the types of content proposed would represent 
the minimum threshold for compliance; at their discretion, MA 
organizations, state Medicaid and CHIP FFS programs, Medicaid managed 
care plans, CHIP managed care entities, and QHP issuers on the FFEs 
would have the option to use the API required by the proposed rule to 
make additional types of health information or plan information 
available, exceeding these minimum requirements.
    We requested comment on the data proposed to be made available as 
detailed in the subsections below. We proposed that MA organizations, 
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP 
managed care entities, and QHP issuers on the FFEs permit third-party 
applications to retrieve, with the approval and at the direction of an 
enrollee, certain specific data: Adjudicated claims data, including 
provider remittances and beneficiary or enrollee cost-sharing data; 
encounter data from capitated providers; and clinical data, including 
laboratory results (but only if maintained by the payer).
(1) Patient Claims and Encounter Data
    We proposed that the adjudicated claims data required to be 
provided include approved and denied claims. Under the proposal, 
adjudicated claims data includes that for which the plan has made an 
initial payment decision even when the period during which an enrollee 
can file an appeal is still in effect, or when the enrollee has filed 
an appeal and is awaiting a decision on that appeal. Such appeal 
decisions might be called reconsiderations, reconsidered decisions, 
organization determinations, or use other terms, but the term is not 
relevant. We specifically requested comments from plans regarding the 
feasibility of including such claims data, including any possible 
timing issues.
    The proposal included timeframe requirements for making these 
various categories of data available through the standards-based API. 
For MA organizations, proposed 42 CFR 422.119(b)(1)(i), (ii), and 
(b)(2)(i) would require standards-based API access to all claims 
activity pertaining to standardized adjudicated claims (including cost, 
specifically provider remittances and enrollee cost-sharing) and 
standardized encounter data for benefits covered by the plan (that is, 
Medicare Part A and Part B items and services, Part D prescription 
drugs if covered by the MA plan, and any supplemental benefits) no 
later than one (1) business day after a claim is processed or the 
encounter data are received by the MA organization. We used the terms 
``adjudicated'' and ``processed'' interchangeably in this context.
    For Medicaid state agencies and managed care plans, we proposed 
that standardized claims data and encounter data would be required 
(specifically at 42 CFR 431.60(b)(1) and (2)) through the API no later 
than one (1) business day after the claim is processed or the data are 
received. For State Medicaid agencies in connection with the FFS 
program, we explained that the API would have to include all claims 
data concerning adjudicated claims and encounter data from providers 
(other than MCOs, PIHPs or PAHPs) that are paid using capitated 
payments. The requirement for Medicaid managed care plans to provide 
encounter data is specified, in conjunction with the incorporation of 
the Medicaid FFS requirement into the Medicaid managed care 
regulations, at 42 CFR 438.242(b)(6)(i) (finalized as Sec.  
438.242(b)(5)(i) in this rule; see section VI.). Similarly, we proposed 
that encounter data that Medicaid managed care plans must make 
available through the API would include any data from subcontractors 
and providers compensated by the managed care plan on the basis of 
capitation payments, such as behavioral health organizations, dental 
management organizations, and pharmacy benefit managers. The API for 
Medicaid managed care plans would have to include all claims and, 
therefore, encounter data that would be included regardless if it is 
adjudicated or generated by the managed care plan itself, a 
subcontractor, or a provider compensated on the basis of capitation 
payments. All data would need to be obtained in a timely manner to 
comply with these proposed requirements that these types of data be 
available through the API no later than one (1) business data after a 
claim is processed or the encounter data are received.
    For CHIP agencies and managed care entities, access to standardized 
claims data and encounter data would be required (specifically at 42 
CFR 457.730(b)(1) and (2)) through the API no later than one (1) 
business day after the claim is processed or the encounter data are 
received. The proposal for CHIP state agencies (regarding FFS programs) 
and CHIP managed care entities is identical to the proposal for 
Medicaid state agencies (regarding FFS programs) and Medicaid managed 
care plans. For QHP issuers on the FFEs, the proposed regulation at 45 
CFR 156.221(b) would require claims and encounter data to be available 
through the Patient Access API no later than one (1) business day after 
adjudication or receipt, respectively.
    Specifically regarding QHP issuers on the FFEs, at 45 CFR 
156.221(b)(1)(i) and (ii), we proposed to require that QHP issuers 
participating on the FFEs make available through the API standardized 
data concerning adjudicated claims (including cost) and standardized

[[Page 25533]]

encounter data. Under proposed paragraph (b)(1)(i), we proposed that 
QHP issuers on the FFEs would be required to make available 
standardized data concerning adjudicated claim, provider remittance, 
and enrollee cost-sharing data through the API within one (1) business 
day after the claim is processed. Under proposed paragraph (b)(1)(ii), 
we proposed that QHP issuers on the FFEs would be required to provide 
standardized encounter data through the API no later than one (1) 
business day after the data are received by the issuer.
    As discussed in the CMS Interoperability and Patient Access 
proposed rule (84 FR 7632 through 7633), the proposed timeframe--making 
the data available to the third-party app with the approval and at the 
direction of the patient through the API no later than one (1) business 
day after processing a claim or receiving encounter data--would ensure 
that data provided to the third-party app, and ultimately the patient, 
through the API would be the most current data available. Providing the 
most current data may be critical if the data are provided by an 
enrollee to his or her health care provider to use in making clinical 
decisions. As proposed, the claims and encounter data to be disclosed 
would include information such as enrollee identifiers, dates of 
service, payment information (provider remittance if applicable and 
available), and enrollee cost-sharing. Our proposal did not exclude any 
elements from the claims and encounter--or the clinical data--required 
to be made available through the Patient Access API. The ability for 
enrollees--created and facilitated by the API required under the 
proposal--to access this information electronically would make it 
easier for them to take it with them as they move from payer to payer 
or among providers across the care continuum.
    Regarding the provision of encounter data through the API no later 
than one (1) business day after receiving the data, we noted that the 
proposal would mean that a payer must rely on capitated providers 
submitting their encounter data in a timely manner to ensure that 
patients receive a timely and complete set of data. To the extent 
providers do not submit in a timely manner, there would be a delay in 
patients having access to their data. We recommended that MA 
organizations, Medicaid managed care plans, CHIP managed care entities, 
and QHP issuers on the FFEs that would need this information in order 
to meet the proposed API requirements in a timely manner should 
consider whether their contracts with network providers should include 
timing requirements for the submission of encounter data and claims so 
that the payer can comply with the API requirements more timely. For 
Medicaid and CHIP FFS programs, we encouraged states to consider other 
means to ensure that necessary encounter data from providers is also 
provided on a timely basis.
    We summarize the public comments we received on making claims and 
encounter data available via the Patient Access API and provide our 
responses.
    Comment: A few commenters expressed concern that there are no named 
or mature industry FHIR-based standards available for representing and 
exchanging claims information. One commenter requested CMS only require 
a specific subset of claims information that would be most useful to 
patients, suggesting patient name, diagnoses codes, procedure codes, 
drug codes, service date(s), provider of service, and out-of-pocket 
costs.
    Response: We appreciate the commenters' concerns and 
recommendations. We have been working with industry partners to ensure 
the necessary FHIR standard and implementation guides as specified at 
45 CFR 170.215 are now available to ensure that payers can fully 
implement sharing claims data via a FHIR-based API, as we are 
finalizing our proposal to have payers impacted by this rule make 
claims and encounter data available via the standards-based Patient 
Access API no later than one (1) business day after claims processing 
or encounter data receipt. To further support payers as they work to 
build the Patient Access API and map claims and encounter data for 
exchange via a FHIR-based API, in partnership with industry, we have 
worked to ensure relevant implementation guides and reference 
implementations are available. A link to specific implementation guides 
and reference implementations for claims and encounter data have been 
produced and tested and can be found at https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Though not 
mandatory, using these publicly available resources will reduce payer 
burden as they work to prepare their data for exchange via a FHIR-based 
API.
    We also appreciate the recommendation to only include a subset of 
claims information. However, we believe it is important for patients to 
have all of their claims information in order to facilitate informed 
decision making. Patients have a right to their claims data. While that 
information currently can be obtained through various means, we decline 
to require that only a subset of the available claims information be 
available through the Patient Access API.
    Comment: One commenter noted that health plans cannot verify the 
accuracy of all information contained in a claim. This commenter 
requested CMS should state that these policies do not mandate that 
payers audit and correct all information furnished by health care 
providers beyond what is currently necessary for existing rules, 
regulations, and internal business purposes.
    Response: We appreciate the commenter's concern. We agree that our 
regulations, as proposed and as finalized, for this Patient Access API 
do not require that payers do any additional audit or review of the 
claims they receive beyond current practices. To the extent that payers 
wish to, they may include a disclaimer or other notice to enrollees as 
part of the API to indicate this. Such a disclaimer would be 
permissible under these regulations.
    Comment: A few commenters recommended that further standardization 
work be done to improve the accuracy of the claims data field that 
identifies the attributed health care provider administering services. 
If this data element is accurate, commenters note it will help ensure 
patients are reaching out to the right clinician. Commenters believe 
this could reduce confusion when patients seek clarification or request 
amendments to their health information.
    Response: We appreciate the commenters' recommendation and will 
evaluate potential future options to address this concern through our 
work with HL7 and other industry partners. We do note, however, this 
seems to be a data accuracy issue and not a standardization issue. That 
said, we do strongly encourage all payers and providers to work 
together to ensure the accuracy of these and all data.
    Comment: A few commenters were concerned that claims data were not 
accurate representations of clinical findings and therefore not 
valuable in assisting patients in making health care decisions. These 
commenters expressed fears that patients may misinterpret claims 
information for health care decision-making when claims data serve a 
payment use case.
    Response: We appreciate the commenters' concerns. We do note, 
however, that there is valuable information on the claim relevant to a 
patient's care and care history that can inform health care decision-
making. For instance, this information provides patients with the names 
of the providers they have visited, when they visited

[[Page 25534]]

certain providers for certain medical needs, when tests or procedures 
were conducted, and more information about these tests and procedures. 
This information alone is very useful to patients as they plan and 
discuss future care with their providers. Also, in the absence of 
clinical data (which is required to be provided through the Patient 
Access API under this rule only if the payer maintains such data), 
claims and encounter data provide a basis of information for patients 
to work with and get value from.
    Comment: One commenter sought clarification on the scope of 
Medicaid-covered services to which the requirement to make claims and 
encounter data available through an API applies. This commenter 
recommended that CMS specify that this requirement to make claims and 
encounter data available does not apply to long-term care waiver 
services, such as in-home care, meal preparation or delivery, and 
transportation. The commenter stated that providing claims and 
encounter data for these services through the API would be cumbersome 
for a variety of reasons including the fact that long-term care waiver 
services tend to have frequent (daily or weekly) utilization by each 
participant, which would result in an unwieldly number of claims or 
encounters being provided through the API for each individual.
    Response: We confirm that under 42 CFR 431.60(b)(1) and (2), 42 CFR 
457.730(b)(1) and (2), 42 CFR 438.242(b)(5) (proposed as Sec.  
438.242(b)(6); see section VI.), and 42 CFR 457.1233(d), states and 
managed care plans must make adjudicated claims and encounter data 
available through the API for all Medicaid- or CHIP-covered services, 
including long-term services and supports (LTSS). This requirement 
extends to in-home care, transportation services, and all other 
Medicaid- or CHIP-covered services for which a claim or encounter is 
generated and adjudicated. We do not believe the number of claims 
generated by LTSS will make the data unwieldy or unusable by the 
beneficiary. We believe that the benefits of providing claims and 
encounter data to beneficiaries so they can make better health care 
decisions and know which providers have been paid for providing 
services to them is no less important simply because it is a frequently 
provided service. Some beneficiaries may find having such data on 
frequently rendered services more important since billing with such 
frequency may make it more prone to errors, fraud, waste, and abuse.
    Comment: Several commenters were concerned with the appropriateness 
of sharing certain claims information, particularly specific costs such 
as negotiated rates that commenters believed could reveal trade secrets 
or be considered proprietary information. These commenters requested 
CMS ensure that confidential, proprietary cost information is excluded 
from the proposed requirements. One commenter believed that disclosure 
of information such as negotiated rates would lead to higher health 
prices in the industry and other anticompetitive behavior. 
Specifically, this commenter gave the example where dominant payers in 
a geographic or other market use this price information to deter 
competitors from entering into value-based payment arrangements. One 
commenter also requested that third-party apps be prohibited from 
aggregating or using any cost information for purposes other than 
transfer of the data to the patient.
    Response: We note that we take our obligations seriously to protect 
from disclosure information that is protected under current law. We 
also affirm our commitment to safeguarding data protected by law from 
inappropriate use and disclosure. We understand the concerns raised 
around sharing cost data. We appreciate the commenters' concerns, 
however we reiterate that we are committed to giving patients access to 
their health information, and we believe the benefits of making this 
information available to patients through third-party apps outweigh 
these concerns. It is critical for patients to better understand health 
care costs and be able to plan and budget as well as possible. Having 
cost information, which is already accessible to patients, available to 
them in a more easy-to-understand presentation would allow patients to 
get the maximum benefit from this information. If a patient uses an app 
to view their health information that does not clearly indicate it will 
not use this cost data for any other purpose, there is a chance the app 
could aggregate or otherwise analyze the data, assuming the single app 
has access to enough patient data in a given market or patients who use 
a particular payer or plan, to make such an analysis possible. 
Appreciating patients already have access to this information and 
understanding the possibility for secondary uses of such data, we are 
finalizing the policy as proposed to require plans to share adjudicated 
claims, including provider remittances and enrollee cost-sharing 
information, via the FHIR-based Patient Access API so patients can 
continue to access this information in ways that will be most useful to 
them. We reiterate, however, that we do not have the authority to 
directly regulate third-party apps.
    Comment: A few commenters also indicated that even if patients had 
access to price information, they would not have the ability to 
negotiate or impact health care costs. One commenter noted that 
patients would find prospective cost information more valuable than 
retrospective payment information.
    Response: We appreciate the commenters' input. With access to price 
information, patients who would have cost sharing that is tied to such 
prices can be more informed consumers of their health care. Even 
patients who have no direct financial responsibility tied to these 
prices can benefit from knowing the information in the event their 
insurance coverage changes in the future or so they can appreciate the 
relationship between the services they receive and their cost to the 
health care system. It is important for patients to understand as much 
as they can about their care. For instance, understanding the costs of 
past services can help them plan for future services. As a result, this 
information has great value to patients even if it does not directly 
impact their ability to specifically influence what they pay for their 
care, or tell them exactly how much their next service will cost out of 
pocket.
    Comment: Many comments were received regarding price transparency, 
generally, and were beyond the scope of the discussion in this rule. 
Overall, these were out of scope for this final rule as they referenced 
other rulemaking activities within HHS.
    Response: We appreciate the commenters' strong interest in greater 
price transparency in health care. We strongly support the 
Administration's and Department's efforts to continue to move toward 
greater transparency to help health care consumers make the most 
informed decisions. We point to the recent release of the CY 2020 
Hospital Outpatient Prospective Payment System Policy Changes and 
Payment Rates and Ambulatory Surgical Center Payment System Policy 
Changes and Payment Rates. Price Transparency Requirements for 
Hospitals To Make Standard Charges Public final rule (84 FR 65524). 
This final rule establishes requirements for all hospitals operating in 
the United States to make their standard charges available to the 
public under section 2718(e) of the PHSA, as well as an enforcement 
scheme under section 2718(b)(3) to enforce those requirements. 
Specifically, sections 2718(b)(3) and 2718(e) of the PHSA require that 
for each year each hospital operating within the United States

[[Page 25535]]

establish (and update) and make public a list of the hospital's 
standard charges for items and services provided by the hospital, 
including for diagnosis-related groups established under section 
1886(d)(4) of the Act. This final rule requires hospitals (as defined 
at 45 CFR 180.20) to establish, update, and make public a list of their 
gross charges, payer-specific negotiated charges (including the de-
identified minimum and maximum negotiated charges), and discounted cash 
prices for all items and services online in a single digital file that 
is in a machine-readable format, as well as their payer-specific 
negotiated charges (including the de-identified minimum and maximum 
negotiated charges) and discounted cash prices (or gross charges, if a 
discounted cash price is not offered by the hospital) for a more 
limited set of shoppable services online in a consumer-friendly format.
    We also direct commenters to the tri-agency Transparency in 
Coverage proposed rule (84 FR 65464) for additional proposals to 
further price transparency.
    Comment: Some commenters generally opposed the proposal to make 
claims and encounter data available through a standards-based API no 
later than one (1) business day after receiving it. Some commenters 
suggested the proposed data availability timeframe is challenging due 
to the timeline for sharing adjudicated claims, in particular, noting 
the different timeframes for payment discharge, benefit determination, 
and settlement of the patient account. One commenter noted the reliance 
on third-party contractors to adjudicate claims and the time required 
to migrate data from one system to another and that validation could 
take longer than one (1) business day. Several commenters expressed 
concern about the timeframe based on revised determinations or revised 
decisions triggered by data that arrives after the initial 
determination. One commenter specifically questioned the value of 
third-party application use of claims data when an enrollee has filed 
an appeal and is awaiting a reconsideration decision. One commenter 
recommended CMS only permit finalized claims where a determination has 
been made be available to be shared via the Patient Access API.
    Some commenters specifically referenced the reliance of MA plans on 
pharmacy benefit management organizations for the administration of 
Part D benefits as a factor in the ability to make these claims data 
available within one (1) business day after receiving them. Other 
commenters referenced the Explanation of Benefit requirements that 
provide a timeframe for information adjustment, which means that the 
final information may not be available in one (1) business day.
    Several commenters suggested an alternative timeframe of 3 or 5 
days for vendor-adjudicated claims, citing time and costs. Some 
commenters recommended a grace period for plans when there is a delay 
due to delayed provider encounter data submission. In addition, some 
requested an exception for specific conditions attributable to certain 
claims and encounter data. Other commenters recommended that CMS work 
with stakeholders to determine an appropriate timeframe for making 
claims and encounter data available via the Patient Access API.
    Response: We appreciate the commenters' concerns and 
recommendations, including comments regarding claims that may be under 
appeal. We are finalizing this policy as proposed that payers make 
available through the Patient Access API, no later than one (1) 
business day after the information is received: (1) Adjudicated claims, 
including claims data for payment decisions that may be appealed, were 
appealed, or are in the process of appeal, and (2) encounter data. We 
reiterate that this is one (1) business day after the claim is 
adjudicated or encounter data are received. This allows for potential 
delays in adjudication or delays in providers submitting their 
encounter data. It does not require payers and providers to change 
their contractual relationships or current processes for receipt, 
though we strongly encourage payers and providers to work together to 
make patient data available in as timely a manner as possible.
    We believe it is valuable to patients to be able to have their data 
in as timely a manner as possible. Having access to this information 
within one (1) business day could empower patients to have the 
information they need when they need it to inform care coordination and 
improve patient outcomes. If a patient needs to get follow-up care, 
having the information relevant to their previous visit is important 
and valuable. API technology allows this exchange to happen more 
quickly and efficiently, and we believe it is important to leverage 
this technological opportunity to ensure patients have the most current 
information about their care.
    It is also important for patients to get this information timely 
even if there is the possibility of a change in determination due to 
appeal or other factors. We conducted research to evaluate the maturity 
of claims to inform researchers using the Chronic Conditions Data 
Warehouse (CCW) data.\30\ This research indicates that nearly half of 
all Medicare FFS or carrier claims are submitted once and unchanged, 
and nearly 85 percent of inpatient claims are never adjusted. For 
carrier claims, 99 percent are fully mature at 10 months; and of non-
inpatient claims that were adjusted, 0.13 percent or less had the 
diagnosis code changed. What this research shows is that many claims 
remain unchanged, and those that do take more that 3 or 5 days after 
adjudication to begin to mature. This wait would not provide patients 
more accurate or complete data; it would only delay their ability to 
benefit from access to their information. Patients have a right to see 
the full lifecycle of their claims and encounter information, and we 
believe they should be able to have access to their information as soon 
as it is available. Even if the payment amounts may change due to 
appeal, for instance, the services received and the providers who 
rendered them are less likely to change. This is very useful 
information and could impact care decisions and facilitate better care 
coordination if available as soon as possible. We do appreciate that 
there are many factors that could influence when some data are 
available. Again, we encourage payers to work with health care 
providers and third-party contractors to ensure timely data processing.
---------------------------------------------------------------------------

    \30\ Chronic Conditions Data Warehouse. (2017, October). CCW 
White Paper: Medicare Claims Maturity (Version 2.0). Retrieved from 
https://protect2.fireeye.com/url?k=7bd1837b-2785aa50-7bd1b244-0cc47a6d17cc-590a0fb580f6d595&u=https://www2.ccwdata.org/documents/10280/19002256/medicare-claims-maturity.pdf.
---------------------------------------------------------------------------

    Comment: Several commenters expressed concern that the proposed 
timeframe for payers to share claims and encounter data with patients 
could require providers to accelerate their submissions to payers 
triggering additional requirements in existing contracts for the 
submission of claims and encounter data. Some commenters cautioned 
there could be potential downstream consequences such as narrowing a 
payer's provider network. One commenter recommended removal of proposed 
rule preamble language suggesting that MA plans, Medicaid managed care 
plans, CHIP managed care entities, and QHP issuers on the FFEs could 
consider adding time requirements for submission of claims and 
encounter data in their contracts with providers. One commenter 
recommended CMS provide sample contract language or dedicate resources

[[Page 25536]]

to educating providers about the intent of these possible contract 
revisions.
    Response: We appreciate the commenters' concerns and 
recommendations. As discussed in the CMS Interoperability and Patient 
Access proposed rule, we do appreciate that some payers may consider 
adding timeframes to contracts with providers to help ensure patients 
get timely access to their claims and encounter data. Again, we 
strongly encourage providers to make this information available in as 
timely a fashion as possible to best assist patients in having access 
to their health information. Adding language to contracts is one way 
for payers and providers to work together to ensure patients get this 
valuable information in as timely a manner as possible. We believe 
providers can benefit as well if this information is available sooner; 
it could be shared with them for the purposes of care coordination in a 
more timely manner, too. It may take some time for providers to improve 
internal efficiencies to meet potential new timeline requirements, but 
we believe the long-term benefit outweighs potential short term 
implementation burden. We do note, however, that the policy being 
finalized in this rule is specific to payers making adjudicated claims 
and encounter information available to patients via the Patient Access 
API within one (1) business day after the payer receives the 
information. Any additional timeframes are between the payers and their 
providers.
(2) Provider Directory Data
    We proposed at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), 
438.242(b)(6)(ii), 457.730(b)(3), and 457.1233(d)(2)(ii) that the 
required Patient Access API make available provider directory data, 
including updates to such data. The proposal at 45 CFR 156.221 would 
not require QHP issuers to permit third-party retrieval of provider 
directory (and preferred drug list information) because such 
information is already required to be provided by QHP issuers on the 
FFEs.
    For MA organizations, at proposed 42 CFR 422.119(b)(1)(iii), we 
proposed to specify that MA organizations make specific provider 
directory information for their network of contracted providers 
accessible through their Patient Access APIs: The names of providers; 
addresses; phone numbers; and specialty. This information is the same 
information MA organizations are already required to disclose to their 
enrollees under 42 CFR 422.111(b)(3) and make available online under 42 
CFR 422.111(h)(2)(ii). As proposed, MA organizations would be required 
to ensure the availability of this information through the Patient 
Access API for all MA plans. We noted that including this information 
in a standards-based API allows non-MA third-party applications to 
consume, aggregate, and display this data in different contexts, 
allowing patients to understand and compare plan information in a way 
that can best serve their individual needs. As proposed, MA plans would 
be required to update provider directory information available through 
the API no later than 30 business days after changes to the provider 
directory are made.
    Under proposed 42 CFR 431.60(b)(3) and 457.730(b)(3), state 
Medicaid and CHIP agencies respectively would be required to make 
provider directory information available through the Patient Access 
API, including updated provider information no later than 30 calendar 
days after the state receives this provider directory information or 
updates to provider directory information. The proposed regulation for 
Medicaid managed care plans at 42 CFR 438.242(b)(6) (finalized as Sec.  
438.242(b)(6) in this final rule; see section IV. of this final rule) 
and for CHIP managed care entities at 42 CFR 457.1233(d)(2) would 
require MCOs, PIHPs, and PAHPs to comply with the same timeframe, with 
the addition of specific provider directory information as noted in 42 
CFR 438.242(b)(6)(ii) and 457.1233(d)(2)(ii). For Medicaid managed care 
plans and CHIP managed care entities, we proposed the provider 
directory information available through the API must include all 
information that is specified in 42 CFR 438.10(h)(1) about provider 
directories for disclosure to managed care enrollees. We proposed that 
the Patient Access API be updated with new provider directory 
information within 30 calendar days from when the updated information 
is received by the state (or the managed care plan under 42 CFR 
438.242(b)(6) (finalized as Sec.  438.242(b)(6) in this final rule; see 
section IV. of this final rule) and Sec.  457.1233(d)(2)) to be 
consistent with existing Medicaid managed care rules at 42 CFR 
438.10(h)(3). We proposed that the API implemented by the state 
Medicaid agency would include the data elements specified for 
disclosure by Medicaid state agencies in section 1902(a)(83) of the 
Act; we proposed at 42 CFR 438.242(b)(6)(ii) that the Patient Access 
API implemented by Medicaid managed care plans would have the data 
elements specified for disclosure at 42 CFR 438.10(h)(1). For CHIP 
agencies that operate FFS systems and CHIP managed care entities at 42 
CFR 457.730(b)(3) and 457.1233(d)(2)(ii), respectively, we also 
proposed that provider directory data be available through the API no 
later than 30 calendar days after receipt of updated information.
    We did not propose a similar requirement for QHP issuers on the 
FFEs. As discussed in the CMS Interoperability and Patient Access 
proposed rule (84 FR 7633), these issuers are already required, under 
45 CFR 156.230(c) and implementing guidance, to make provider directory 
information accessible in a machine-readable format. Because this 
information is already highly accessible in this format, we noted that 
we did not believe the benefits of making it also available through a 
standards-based API outweigh the burden for QHP issuers on the FFEs. 
However, we sought comment as to whether this same requirement should 
apply to QHP issuers, or if such a requirement would be overly 
burdensome for them.
    To avoid unnecessary duplication of effort and potential confusion, 
we are not finalizing the proposal to include provider directory 
information in the Patient Access API. Instead, we are finalizing the 
inclusion of this information (consistent in scope as proposed for the 
Patient Access API) in the public facing Provider Directory API 
discussed in section IV. of this final rule, which requires MA 
organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP 
FFS programs, and CHIP managed care entities to provide public access 
to complete and accurate provider directory information at 42 CFR 
422.120, 431.70, 438.242(b)(6), 457.760, and 457.1233(d)(3). 
Appreciating that the comments we received on provider directory 
information and APIs addressed issues relevant to both including these 
data in the Patient Access API discussed in this section of the final 
rule, but more so making this information more widely available through 
the Provider Directory API as discussed in section IV. of this final 
rule, all comments and our responses related to provider directory 
information via APIs can be found in section IV. of this final rule.
(3) Clinical Data Including Laboratory Results
    Regarding the provision of clinical data, including laboratory 
results, we proposed at 42 CFR 422.119(b)(1)(iv) that MA organizations 
make clinical data, such as laboratory test results, available through 
the API if the MA organization maintains such data. We also proposed in 
paragraph (c)(3)(i) that

[[Page 25537]]

the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, 
be used as the content and vocabulary standard for the clinical data 
made available through the API. We intended the proposal to mean that 
the data required under paragraph (b)(1)(iv) be the same as the data 
that is specified in that content and vocabulary standard defined at 45 
CFR 170.213. In effect, we proposed that at a minimum any clinical data 
included in the USCDI standard, proposed by ONC for HHS adoption at 45 
CFR 170.213, be available through the Patient Access API if such data 
are maintained by the MA organization. We recognized that some MA 
organizations receive this information regularly, or as a part of their 
contracted arrangements for health services, but that not all MA 
organizations do. Therefore, we proposed that this requirement would 
apply to MA organizations, regardless of the type of MA plan offered by 
the MA organization, but only under circumstances when the MA 
organization receives and maintains this clinical data as a part of its 
normal operations. The proposed requirement aligned with existing 
regulations at 42 CFR 422.118, which required MA organizations to 
disclose to individual enrollees any medical records or other health or 
enrollment information the MA organizations maintain with respect to 
their enrollees. We proposed that this data be available through the 
API no later than one (1) business day from its receipt by the MA 
organization.
    Similarly, the proposed regulations for Medicaid and CHIP FFS 
programs and managed care plans (proposed 42 CFR 431.60(b)(4) and Sec.  
457.730(b)(4)), required provision through the Patient Access API of 
standardized clinical data, including laboratory results, if available, 
no later than one (1) business day after the data are received (by the 
state or the managed care plan or entity). We noted that this would 
ensure that data provided through the API would be the most current 
data available, which may be critical if the data are being shared by 
an enrollee with a health care provider who is basing clinical 
decisions on these data. As noted, like proposed 42 CFR 422.119(c), the 
Medicaid and CHIP regulations proposed compliance with the regulations 
regarding the USCDI standard, proposed by ONC for HHS adoption at 45 
CFR 170.213, as the content and vocabulary standard for the clinical 
data available through the Patient Access API; therefore, we proposed 
that at a minimum any clinical data included in that USCDI standard be 
made available through the Patient Access API within one (1) business 
day of receipt. For state agencies managing Medicaid or CHIP FFS 
programs, we proposed that such data be made available through the API 
under the proposal if the state maintains clinical data. The proposed 
regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) 
(finalized as Sec.  438.242(b)(5) in this rule; see section VI.) and 
CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, 
PIHPs, and PAHPs to comply with the same standard in terms of the scope 
of information and the timing of its availability through the Patient 
Access API; the limitation that the clinical data be maintained by the 
entity for it to be required to be sent via the Patient Access API 
would carry through to managed care plans and entities under the 
proposal.
    Proposed 45 CFR 156.221(b)(1)(iii) would require QHP issuers on the 
FFEs to also make these clinical data, including laboratory results, 
available via the Patient Access API, with the approval and at the 
direction of the enrollee, if the QHP maintains such data.
    We recognized not all of the entities subject to this requirement 
have uniform access to this type of data and sought comment on what 
barriers exist that would discourage them from obtaining, maintaining, 
and making these data available through the Patient Access API.
    We summarize the public comments we received on the inclusions of 
clinical data, specifically the data included in the USCDI standard, 
via the Patient Access API and provide our responses below.
    Comment: Several commenters expressed concerns that payers are 
typically not the original source of clinical information, including 
data elements that are part of the USCDI, and would not be the best 
source of the most accurate clinical data for patients. These 
commenters noted concerns with data accuracy provided by payers who are 
typically secondary sources of this clinical information and explained 
that payers do not verify this information. One commenter believed the 
originator should be providing the data, or that payers should be 
allowed to indicate the provenance of the data and where to direct 
questions regarding data accuracy. There was concern that the 
administrative burden on providers could increase due to patient 
inquiries and requests to correct or clarify their data.
    Response: We appreciate the commenters' concerns and 
recommendations. We understand that payers are not the source of this 
clinical information; however, payers do maintain clinical data that 
can be of great value to patients. We note that provenance is one data 
class within the USCDI. As such, this information would be available to 
patients. We also note, that as discussed above, we intend to provide 
suggested content for educational information that payers will be able 
to tailor and use to communicate with their patients about the Patient 
Access API. Payers can choose to indicate the part of a data exchange 
that was received from an outside source so the receiving party 
understands where to direct questions. This will also help patients 
understand how to address incorrect information as it can be made clear 
where questions should be directed. Payers are under no obligation 
under this Patient Access API requirement to validate or correct 
clinical data received from another source; and, providers are under no 
obligation to submit updated data to payers should patients suggest 
there is an error in their data. We do encourage payers and providers 
to continually work to ensure the accuracy of the patient data they 
maintain and share to the extent possible. The Patient Access API must 
include all of the specified clinical information for the enrollee 
maintained by the payer with a date of service on or after January 1, 
2016.
    Comment: A few commenters were concerned that payers could use 
clinical data to discriminate against providers, such as through 
discriminatory reimbursement models, for instance offering lower 
reimbursement rates for certain types of care that a physician deems 
necessary or in the best interest of the patient based on the data 
viewed about the doctor and the care they provide.
    Response: We appreciate the commenters' concerns; however, we note 
the fact that some payers are already automatically accessing a 
physician's EHR for other purposes, either as an elective offering or 
through contractual requirements. As a result, additional data than is 
required to meet the requirements of this final rule are already being 
shared between providers and payers. We reiterate that payers are not 
entitled to receive information from a health care provider if such 
information is protected by applicable federal, state, or local law 
from disclosure to the payer. This final rule does not change any such 
existing legal obligations.
    Comment: A few commenters expressed concerns over provider 
liability for the quality or accuracy of

[[Page 25538]]

clinical data and for being given certain sensitive patient diagnosis 
and problems information, particularly if the provider is a downstream 
recipient of such data.
    Response: We appreciate the commenters' concerns, but reiterate 
that the policies finalized in this regulation do not change any payer 
or provider's obligations to abide by existing federal and state 
regulations and law, including 42 CFR part 2, which governs certain 
substance use disorder records, which are some of the most sensitive 
health information. We note, however, that the patient can direct the 
entity to transfer this sensitive data upon their designation of a 
recipient, or may provide consent or authorization for the transfer, as 
applicable. As a provider, and likely as a covered entity under HIPAA, 
providers are experienced in handling sensitive data. Access through an 
API will provide a new route to receiving sensitive data, not add to 
the burden of protecting such information, given the continued need to 
maintain compliance with all applicable rules and regulations. These 
policies just allow this information to be transmitted via an API with 
the approval and at the direction of the patient.
    Comment: Some commenters expressed concern that patients may not 
understand, or may be confused by, the health information that will be 
available, and questioned if this information will all be relevant to 
patients. A few commenters recommended that educational materials and 
resources be developed to ensure that the data are useful and do not 
cause alarm.
    Response: We appreciate the commenters' concerns and 
recommendations. We appreciate that every patient may not understand 
every piece of information in their medical record. We intend to 
provide suggested content for educational materials or other patient 
resources that payers can tailor and use to ensure that patients have 
information about how to accurately and productively navigate their 
health care information, as further discussed below in this section. It 
is important for patients to have access to their records, review them, 
and have an opportunity to raise questions and seek clarification about 
the information maintained in them.
    Comment: One commenter requested CMS explain the requirement that 
MA organizations make clinical data available through the Patient 
Access API if the entity ``manages such data,'' particularly what is 
meant by ``manages such data.'' This commenter noted that providers 
manage clinical data and requested clarification of whether the 
requirement applies to MA organizations. Another commenter expressed 
similar concerns and inquired whether ``managed by the payer'' would 
include only lab results or all clinical data. Commenters questioned if 
``manage'' meant ``electronically stored in a database under the 
payer's control''?
    Response: We appreciate the commenters' request for additional 
information. As noted in the CMS Interoperability and Patient Access 
proposed rule, payers, including MA organizations, need to make these 
data available through the API when the payer receives and maintains 
these data as a part of its normal operations (84 FR 7633). We used the 
verb ``manages'' to communicate that this proposed requirement would 
apply when the payer has access to the data, control over the data, and 
the authority to make the data available through the API. In order to 
more closely align with how the relevant HIPAA Privacy Rule requirement 
refers to such activity, we are finalizing the regulation text at 42 
CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), as well as 45 
CFR 156.221(b)(1)(iii) with the verb ``maintains'' in place of the verb 
``manages''. As such, we define ``maintain'' to mean the payer has 
access to the data, control over the data, and authority to make the 
data available through the API.
    Comment: One commenter questioned if Medicaid agencies will be 
required to provide clinical data regardless of the type of transaction 
by which the agency received the data.
    Response: We confirm that Medicaid and CHIP agencies, and their 
respective managed care plans, will be required under 42 CFR 
431.60(b)(3), 457.730(b)(3), 438.242(b)(5), and 457.1233(d) to provide 
clinical data through the API if the state or managed care plan 
maintains such clinical data. Clinical data subject to this requirement 
includes laboratory results and other clinical data, and must be made 
available through the Patient Access API regardless of the type of 
transaction by which the state or managed care plan received the data 
originally. However, if the data were received under the payer-to-payer 
data exchange requirement finalized in section V. of this final rule at 
42 CFR 422.119(f), 438.62(b)(1)(vi), and 457.1216, and 45 CFR 
156.221(f), then the payer would only need to share the clinical data 
received via the payer-to-payer data exchange via the Patient Access 
API if the data were received from another payer via a standards-based 
API. As required at 42 CFR 422.119(f)(1)(iii), 438.62(b)(1)(vi)(C), and 
457.1216 and 45 CFR 156.221(f)(1)(iii), data received via the payer-to-
payer data exchange only need to be made available to share in the 
electronic form and format they were received from another payer. If a 
payer receives data specifically for the payer-to-payer data exchange 
via an API, they can then make these data available via the Patient 
Access API without additional burden--the payer will not be required 
per this final rule to take data from another payer received as a 
direct result of the payer-to-payer data exchange policy and prepare it 
to be shared via the Patient Access FHIR-based API; the payer will only 
be required to incorporate that data into the enrollee's record so that 
it can be shared with a new payer, if requested by the patient, in the 
electronic form and format received. Appreciating concerns raised 
around the burden of preparing data for exchange via an API, we have 
provided this guidance to minimize this burden. We note that Medicaid 
and CHIP state agencies are not subject to the payer-to-payer data 
exchange requirement in this rulemaking, as we did not propose this 
policy for these entities.
    Comment: A few commenters recommended that patients have access to 
detailed and accurate lab test and results information through the 
Patient Access API. A few commenters were not supportive of CMS' 
proposal that laboratory information be made available only where 
available. One commenter recommended that these same API requirements 
apply to laboratories providing service to Medicare and Medicaid 
patients as any provider receiving reimbursement for medical services. 
One commenter expressed concern that lab information is not 
standardized and may be difficult to exchange.
    Response: We appreciate the commenters' concerns and 
recommendations. These regulations requiring the Patient Access API and 
detailing the data available through the Patient Access API, as 
proposed and as finalized, do not apply to laboratories or to any 
providers--these requirements are specific to payers as detailed above, 
but we will review the recommendations made for potential future 
consideration.
    Regarding concerns about standardized data exchange of laboratory 
information, the regulations finalized in this rule provide the content 
and vocabulary standards at 45 CFR 170.213 needed to address sharing 
laboratory data through the API. Implementation guidance, now

[[Page 25539]]

available at https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index, though not mandatory, can be used to further 
support sharing these data utilizing the content and vocabulary 
standards adopted in this rule. These implementation guides and 
reference implementations provide additional support to help payers 
implement this policy in a standardized way that facilitates 
interoperability.
    Comment: Some commenters were concerned about the proposed timeline 
and challenges specifically because of the nature of laboratory data, 
specifically laboratory results. Final results can replace preliminary 
results, and laboratory data coming from third parties can take time to 
receive. Additionally, there may be conflicting disclosure requirements 
that permit up to 30 days to pass before laboratory data are available 
to a payer.
    Response: We appreciate the commenters' concerns. We do understand 
that there are many factors that could influence when some data are 
available. However, we reiterate that this Patient Access API policy 
requires the information to be shared no later than one (1) business 
day after it is received by the regulated payer. If it takes additional 
time for laboratory information to be provided to a payer, that does 
not impact the payer's obligation to make the data available via the 
Patient Access API no later than one (1) business day after the receipt 
of the information by the payer. Therefore, we strongly encourage all 
payers and providers to work to make data available in as timely a 
fashion as possible to ensure an optimally informed health care 
ecosystem.
    Comment: Many commenters supported the proposal to require 
providing the information in the USCDI via the Patient Access API. 
Commenters supported alignment with ONC on this and encouraged 
additional alignment across government data sets. Commenters also 
supported the data classes and associated standards in the proposed ONC 
USCDI. One commenter specifically noted support for the pediatric vital 
signs proposed as part of the USCDI. A few commenters recommended the 
addition of data classes that are already proposed as part of the 
USCDI, such as clinical notes, provenance, and unique device 
identifiers. A few commenters strongly supported the inclusion of notes 
in the USCDI, citing several studies of the benefits of patients having 
this information including, but not limited to, patient literacy, 
empowerment, health care coordination, medication adherence, and 
safety. One commenter recommended only final notes be considered 
applicable to the USCDI and that the imaging note be removed from the 
types of required notes. This commenter also indicated that notes that 
contain sensitive information were likely subject to a variety of state 
privacy laws. A few commenters noted further standardization work was 
needed for provenance data fields.
    Response: We appreciate the commenters' support and 
recommendations; we have shared these comments about the USCDI with ONC 
for future consideration. We agree that aligning with ONC and 
finalizing exchange of the USCDI as defined at 45 CFR 170.213 in ONC's 
21st Century Cures Act final rule (published elsewhere in this issue of 
the Federal Register) has many benefits and will help us reach our 
interoperability goals. We refer readers to ONC's final rule for the 
specifics of exactly how the USCDI standard is being finalized by HHS. 
As finalized here, the clinical data required to be made available 
through the Patient Access API at 42 CFR 422.119(b)(1)(iii), 
431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii) at a 
minimum are the USCDI version 1 as defined at 45 CFR 170.213 and 
specified in this rule at 42 CFR 422.119(c)(3)(i), 431.60(c)(3)(i), and 
457.730(c)(3)(i), and 45 CFR 156.221(c)(3)(i). We do note the policies 
finalized in this regulation do not alter obligations under existing 
federal and state laws. We reiterate that we are working closely with 
HL7 and other partners leading the effort to develop standards to 
ensure helpful guidance is available for payers to consult as they work 
to implement the policies being finalized in this rule. Again, we note 
that, though not mandatory, we are providing a link to specific 
implementation guides and reference implementations that provide 
valuable guidance to support payers as they work to implement the 
Patient Access API: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
    Comment: One commenter requested that all the data elements in the 
USCDI be specifically enumerated in the regulation text of this final 
rule for clarity. A few commenters recommended CMS and ONC limit the 
definition of electronic health information to solely the data classes 
included in the USCDI. Another commenter did not believe this 
definition should be limited to identifiable information. One commenter 
suggested that the definition of electronic health information should 
include real price information.
    Response: We appreciate the commenters' recommendations. We are 
finalizing our regulation text that requires use of the standard 
specified at 45 CFR 170.213 in ONC's separate rulemaking to ensure 
alignment and consistency across the two regulations. That specific 
standard is currently the USCDI version 1 and therefore the USCDI will 
be the initial standard applicable under this final rule. Additional 
information about the data classes and data elements included in USCDI 
can be found at https://www.healthit.gov/USCDI. We continue to use 
``electronic health information'' as defined by ONC at 45 CFR 171.102. 
With regard to specifically listing the data elements in the USCDI, we 
believe cross referencing ONC's regulation better supports our goal of 
aligning with ONC's policy regarding this information.
    Comment: One commenter did not support the proposed requirement to 
provide patients with the USCDI data because the commenter believed it 
was not feasible for payers. The commenter indicated that payers do not 
typically collect clinical data. One commenter recommended that CMS use 
FHIR bundles, or a collection of relevant FHIR resources, rather than 
the USCDI. One commenter was concerned with how free text fields would 
be addressed in the USCDI. One commenter expressed concern that CMS 
would require the use of non-HIPAA standards in the USCDI for providing 
data to patients.
    Response: We appreciate the commenters' concerns and 
recommendations. We acknowledge that payers do not maintain all 
clinical data for all patients and our regulation text at 42 CFR 
422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), and 45 CFR 
156.221(b)(1)(iii), as finalized, specifically limits the obligation to 
make clinical data available through the Patient Access API to those 
payers that maintain any such data. If a payer subject to these 
regulations (including the Medicaid and CHIP managed care plans that 
are subject to regulations that incorporate these requirements) 
maintain the data elements specified in this final rule, these data 
elements must be shared as noted in this final rule using the standards 
indicated. If payers do maintain valuable clinical data about patients, 
patients have a right to these data. This is a first step in providing 
patients with information from their medical record in an efficient 
electronic format.
    We appreciate the recommendation to look at alternatives to the 
USCDI, but we believe it is critical for interoperability to align with 
ONC and see great value

[[Page 25540]]

in the continued coordination between CMS, ONC, and partners such as 
HL7 to ensure helpful guidance is available for payers to consult as 
they work to successfully implement these final rule policies. To this 
end, we again note that we have provided a link to specific 
implementation guides and reference implementations that, though not 
mandatory, can be used to support consistent implementation. We refer 
readers to additional information on the USCDI at https://www.healthit.gov/USCDI and available guidance at https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index to best 
understand how to implement all data classes and elements included in 
the USCDI including text fields. Regarding the use of non-HIPAA versus 
HIPAA standards, we do not believe there is a conflict, and we refer 
readers to the discussion of Administrative Simplification transaction 
standards in section III.C.2.b. of this final rule for more 
information.
    Comment: One commenter suggested that standards development 
organizations such as HL7 would be better positioned to support data 
standardization rather than the proposed USCDI approach. A few 
commenters noted there are different use cases for various data types 
and that coordination is required to expand the data in the USCDI. One 
commenter recommended CMS allow voluntary extensions to data sets 
outside of the USCDI to support the growth of new standards and data 
types from a payer perspective.
    Response: We appreciate the commenters' recommendations. In 
addition, we appreciate the valuable role of standards development 
organizations, like HL7, and reiterate our commitment to working with 
such partners as industry develops the necessary standards and 
associated guidance to implement the policies being finalized in this 
rule. We will continue to refer to the USCDI as finalized by HHS in 
ONC's 21st Century Cures Act final rule (published elsewhere in this 
issue of the Federal Register) at 45 CFR 170.213 to ensure alignment 
and consistency across the two regulations. We further refer readers to 
additional information about the USCDI and the expansion process as 
defined by ONC at https://www.healthit.gov/USCDI. We note that this 
expansion process is a consensus process that allows for public input 
and comment and strongly recommend stakeholders continue to engage in 
this valuable process. This coordination and consensus is a cornerstone 
of our interoperability efforts. We also note that the data elements 
required in this final rule represent the minimum data that must be 
shared under our finalized policy through a payer's Patient Access API. 
We strongly encourage payers to share more data as the more data that 
patients have access to, the more they will benefit from this access. 
We agree that continuing to push these limits will spur innovation and 
growth.
    Comment: A few commenters requested additional information 
regarding the definitions of terminology used when discussing the USCDI 
in the CMS Interoperability and Patient Access proposed rule. One 
commenter requested more information on the meaning of ``state 
agencies,'' in reference to ``any clinical data included in the USCDI 
standard . . . be available through the API,'' and if this meant that 
if the state agency managed an immunization registry it would be 
required to make the data available through an API. Another commenter 
requested CMS to provide more information about the use of ``forward'' 
(in the preamble) versus ``send'' (in the regulatory text) regarding 
the USCDI, including whether the information needs to be available to 
the receiving payer and whether use of a trusted exchange network is 
required.
    Response: We appreciate the commenters' requests for additional 
information. We note that the term ``state agencies'' in this instance 
in the proposed rule (84 FR 7634) refers to those state agencies that 
manage Medicaid and CHIP programs. If a Medicaid or CHIP state agency 
has immunization data in connection with its Medicaid program or CHIP 
as defined in the USCDI, these data would be required to be available 
via the Patient Access API per our proposal as finalized. We note that 
in section V. of this final rule, we require the exchange of the USCDI 
between payers subject to this regulation; this payer-to-payer data 
exchange does not require the use of an API. As finalized, our policies 
do not require the use of a trusted exchange network. Regarding the use 
of terms ``forward'' and ``send,'' we note this means that the data 
must be exchanged with the patient as specified here in section III. of 
this final rule or between payers as discussed in section V. of this 
final rule.
(4) Drug Benefit Data, Including Pharmacy Directory, and Formulary Data
    We proposed that drug benefit data, including pharmacy directory 
information and formulary or preferred drug list data, also be 
available through the Patient Access API at proposed 42 CFR 
422.119(b)(2)(ii) and (iii), 431.60(b)(5), and 457.730(b)(5). (Our 
proposal for providing prescription drug claims through this API is 
discussed in section III.C.2.c.(1) of the CMS Interoperability and 
Patient Access proposed rule (84 FR 7632).) As previously discussed, 
Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) 
(finalized as Sec.  438.242(b)(5) in this rule; see section VI.) to 
comply with the requirement at 42 CFR 431.60(b)(5), and CHIP managed 
care entities would be required by 42 CFR 457.1233(d)(2) to comply with 
the requirement at 42 CFR 457.730(b)(5).
    We proposed at 42 CFR 422.119(b)(2)(ii) and (iii) that MA 
organizations offering MA-PD plans must make available through the API 
the following pharmacy benefit data: (1) Pharmacy directory data, 
including the number, mix (specifically the type of pharmacy, such as 
``retail pharmacy''), and addresses of pharmacies in the plan network; 
and (2) formulary data including covered Part D drugs and any tiered 
formulary structure or utilization management procedure which pertains 
to those drugs. The pharmacy directory information is the same 
information that MA-PD plans--like all Part D plans--must provide on 
their websites under 42 CFR 423.128(b)(5) and (d)(2). While 
prescription drug claims would have to be made available through the 
Patient Access API no later than one (1) business day after the MA-PD 
plan's receipt of that information, we did not propose a specific 
timeframe for pharmacy directory or formulary information to be 
available (or updated) through the API. We noted that we intended that 
the requirements in 42 CFR part 423 requiring when and how information 
related to pharmacy directories be updated would apply to the provision 
of this information through the API; we solicited comment whether we 
should address this in the regulation text or otherwise impose a 
timeframe for this information to be made available through the API.
    At 42 CFR 431.60(b)(5), for Medicaid FFS programs, and at 42 CFR 
457.730(b)(5) for CHIP FFS programs, we proposed that states would be 
required to include and update information about covered outpatient 
drugs and updates to such information, including, where applicable, 
preferred drug list information, no later than one (1) business day 
after the effective date of any such information or updates to such 
information.
    We did not propose a similar requirement for QHP issuers on the 
FFEs because, like the provider

[[Page 25541]]

directory information, QHP issuers are required to make drug formulary 
data accessible in a machine-readable format.
    As discussed above for the provider directory information, to avoid 
unnecessary duplication of effort and potential confusion, we are also 
not finalizing the proposal to include pharmacy directory information 
in the Patient Access API. Instead, we are only finalizing the 
inclusion of this information as proposed and explained above be 
included in the public facing Provider Directory API discussed in 
section IV. of this final rule, which requires MA organizations that 
offer MA-PD plans to provide public access to pharmacy directory 
information at 42 CFR 422.120(b). Relevant comments are also discussed 
in section IV. of this final rule.
    We summarize the public comments received on our proposal that 
information about drug coverage and pharmacy benefit coverage be 
available through the Patient Access API and provide our responses.
    Comment: One commenter recommended CMS require that MA plans make 
information about patients' step therapy available for sharing 
electronically. This commenter opposes step therapy and recommended 
that it not be used in MA or Part D.
    Response: The use of step therapy is beyond the scope of this rule. 
However, because step therapy is a utilization management procedure, it 
is included among the types of information MA-PDs must make available 
about Part D drugs through the API. In regard to information about 
utilization management that pertains to basic benefits, which was not 
addressed in this rule, we appreciate the commenter's recommendations 
and will evaluate them for potential future consideration.
    Comment: One commenter strongly recommended the inclusion and 
standardization of prescription drug monitoring program data (PDMP) for 
exchange through APIs, although this commenter referred more to 
exchange between providers for downstream clinical decision support and 
analytics rather than for patient access. A few commenters were not in 
favor of sharing PDMP data through APIs. A few commenters were not 
supportive of PDMP data being available to other providers and payers.
    Response: We appreciate the commenters' recommendations and 
concerns. However, we note that this information is not required to be 
available through the Patient Access API as it is not within the scope 
of 422.119(b)(2).
    Comment: Several commenters expressed concern that the proposals in 
42 CFR 431.60(b)(5), 457.730(b)(5), 438.242(b)(6) (finalized as 42 CFR 
431.60(b)(4), 457.730(b)(4), and 438.242(b)(5) in this rule), and 45 
CFR 457.1233(d) to provide information on covered outpatient drugs and 
preferred drug lists through an API within one (1) business day after 
the effective date of the information or updates to the information may 
be a challenge for state Medicaid and CHIP agencies and Medicaid and 
CHIP managed care entities. One commenter recommended to first require 
state Medicaid pharmacy programs to focus on developing interoperable 
standards for API development and only require managed care entities to 
adopt the standards once the API has been tested and scaled at the 
state level.
    Response: We appreciate the commenters' concerns. We understand 
that our proposed timeframe of one (1) business day may be 
operationally challenging for states and managed care plans but 
continue to believe that this timeframe is critical in order for 
beneficiaries and prescribers to have this information as soon as the 
information is applicable to coverage or in near real time since this 
information could improve care and health outcomes. We believe that 
timely data are particularly important during urgent or emergency 
situations. We note that having access to this information as soon as, 
or even before, it is effective is necessary for patients and their 
providers to make important decisions about which medications should be 
included in a patient's care plan. This is particularly important for 
patients who may not be able to cover a medication out of pocket if it 
is not covered by their plan. Therefore, we are finalizing the 
timeframe. We decline to only apply these requirements to state 
Medicaid programs (and decline to postpone application of the timeframe 
to managed care plans until a future time as recommended by the 
commenter) because this approach would not be consistent with our goal 
of ensuring that the patients covered by the payers impacted by this 
requirement have access to the specified data. We also note that we are 
providing a link to specific implementation guidance and reference 
implementations for all payers to further support sharing the needed 
data using the required standards: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. We are finalizing these 
requirements for the API to include formulary information for MA 
organizations offering MA-PD plans, state Medicaid and CHIP FFS 
programs, Medicaid managed care plans, and CHIP managed care entities.
    In addition to comments about the specific types of information we 
proposed be made available through the Patient Access API, we also 
received comments on additional types of information stakeholders would 
like to see included. We summarize the public comments we received on 
this topic and provide our responses.
    Comment: Commenters made a number of suggestions for additional 
data to be made available to patients via the Patient Access API. Some 
of the data requested is already included in the proposal and being 
finalized for inclusion as proposed. In addition to these requests, a 
few commenters recommended CMS also require the inclusion of 
information regarding prior authorization decisions, drug pricing, and 
a direct phone number for patients to call providers and their staff 
about prior authorization issues. A few commenters specifically 
requested prior authorization decision information, including active 
prior authorizations, be made accessible to patients; a few other 
commenters suggested this prior authorization information be available 
to providers.
    Commenters recommended future versions of the USCDI include 
additional data so that these data would be available via the Patient 
Access API. A few commenters recommended the USCDI include social 
determinants of health data. One commenter recommended CMS and ONC 
include additional immunization data elements from the CDC endorsed 
data elements for immunization and the American Immunization Registry 
Association's Functional Guide. One commenter recommended Care Team 
Data Class as well as Data Class Provenance ``Author Health 
Profession'' be added. One commenter recommended including coverage and 
explanation of benefit data to the USCDI per the CARIN Alliance's 
Implementation Guide. Another commenter recommended CMS include data 
elements related to administrative transactions. One commenter 
recommended the USCDI include Digital Imaging and Communications in 
Medicine (DICOM) images in addition to the already included imaging 
notes. A few commenters requested CMS specifically require the use of 
Systematized Nomenclature of Dentistry (SNODENT) for dentistry 
findings, disorders, and diagnoses, versus making SNODENT optional as 
part of the proposed USCDI.

[[Page 25542]]

    A few commenters recommended that additional care settings or 
provider types are considered for additional USCDI data classes in the 
future. These included anesthesiology, registered dietitian 
nutritionists, and post-acute care settings (including hospice). One 
commenter recommended that the USCDI include additional FHIR-based 
pharmacy benefit standard-based formulary and drug benefit data. 
Another commenter requested that Admission, Discharge, and Transfer 
(ADT) data classes and data elements be included in the USCDI. One 
commenter recommended CMS work with the industry to standardize 
unstructured encounter data. One commenter was concerned that the USCDI 
includes data traditionally collected in EHRs and that data/standards 
for non-health care transactions are not included (for example, home 
modifications). One commenter expressed concerns that the USCDI does 
not include the entire designated record set, such as images and 
genomic test reports and recommends this be included.
    Response: We appreciate the commenters' recommendations and will 
work with ONC to evaluate these recommendations for possible future 
consideration, as appropriate and feasible.
    We also received comments detailing concerns with the volume of 
data being proposed to be made available through the Patient Access 
API. We summarize the public comments we received on this topic and 
provide our responses.
    Comment: A few commenters were concerned with the potential volume 
of data that will be made available to patients through the Patient 
Access API. A few commenters requested CMS provide more information 
regarding the minimum information required to be shared under our 
policies. One commenter suggested that an advisory panel determine the 
volume and types of information that patients should receive.
    Response: We appreciate the commenters' concerns and 
recommendations. Regarding the data to be made available to patients, 
as noted in section III.C.2.b. of this final rule, to ensure consistent 
implementation and minimize the burden on payers, we are finalizing in 
the applicable regulations additional text to specify that MA 
organizations at 42 CFR 422.119(h), state Medicaid FFS programs at 42 
CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii), 
CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at 
42 CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221(i), 
beginning January 1, 2021 (or beginning with plan years beginning on or 
after January 1, 2021 for QHPs on the FFEs), must make available 
through the Patient Access API data they maintain with a date of 
service on or after January 1, 2016. We are also finalizing the same 
years of data be available through the Patient Access API and for the 
payer-to-payer data exchange requirement discussed in section V. of 
this final rule. These policies support the ultimate goal to provide 
patients access to their cumulative health information.
    We are finalizing as proposed the minimum content required to be 
accessible through the Patient Access API in the regulation text at 42 
CFR 422.119(b), 431.60(b), 438.242(b)(5), and 457.730(b), and 45 CFR 
156.221(b). This specifically includes adjudicated claims (including 
cost); encounters with capitated providers; provider remittances; 
enrollee cost-sharing; and clinical data (including laboratory results) 
(where maintained by the applicable payer), as well as formularies or 
preferred drug lists for all impacted payers except QHP issuers on the 
FFEs. As discussed above, these data must be shared using the content 
and vocabulary standards at 45 CFR 170.213, finalized by HHS in ONC's 
21st Century Cures Act final rule (published elsewhere in this issue of 
the Federal Register), and in 45 CFR part 162 and 42 CFR 423.160. We 
believe that patients have a right to their health care information so 
they can use and share this information to best inform their health 
care decisions. We appreciate the recommendation to create an advisory 
panel, and will evaluate it for potential future consideration.
d. Documentation Requirements for APIs
    We proposed that the specific business and technical documentation 
necessary to interact with the proposed APIs be made freely and 
publicly accessible. As discussed in section II.A.1 of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7620), we 
believed transparency about API technology is needed to ensure that any 
interested third-party application developer can easily obtain the 
information needed to develop applications technically compatible with 
the organization's API. Transparency is also needed so that third-
parties can understand how to successfully interact with an 
organization's API. This includes how to satisfy any requirements the 
organization may establish for verifying a developer's identity and 
their applications' authenticity, consistent with the payer's security 
risk analysis and related organizational policies and procedures. In 
this way payers can ensure they maintain an appropriate level of 
privacy and security protection for data on their systems.
    Specifically, at 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 
CFR 156.221(d), we proposed virtually identical text to require the 
regulated entities to make complete accompanying documentation 
regarding the API publicly accessible by posting this documentation 
directly on the applicable entity's website or via a publicly 
accessible hyperlink. As previously discussed, Medicaid managed care 
plans would be required by 42 CFR 438.242(b)(6) (finalized as Sec.  
438.242(b)(5) in this rule; see section VI.) to comply with the 
requirement at 42 CFR 431.60(d), and CHIP managed care entities would 
be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 
42 CFR 457.730(d). In requiring that this documentation be made 
``publicly accessible,'' we noted that we expected that any person 
using commonly available technology to browse the internet could access 
the information without any preconditions or additional steps beyond 
downloading and using a third-party application to access data through 
the API. We also noted that this was not intended to preclude use of 
links the user would click to review the full text of lengthy documents 
or access sources of additional information, such as if the 
technology's supplier prefers to host technical documentation at a 
centralized location. Rather, we meant ``additional steps'' to include 
actions such as: Collecting a fee for access to the documentation; 
requiring the reader to receive a copy of the material via email; or 
requiring the user to read promotional material or agree to receive 
future communications from the organization making the documentation 
available.
    We summarize the public comments received on our proposal regarding 
API documentation and provide our responses.
    Comment: Some commenters opposed the API documentation proposal 
indicating payers and providers will be required to provide data 
without a charge, but the freely and publicly accessible documentation 
would enable applications to collect data and possibly sell the data 
back to payers and providers if needed for secondary uses such as 
provider directories.
    Some commenters supported fees for documentation noting the funds 
required to create and maintain data for sharing between payers and 
enrollees.

[[Page 25543]]

Commenters believed third parties should be charged a fee to maintain 
the API. One commenter expressed concern that the business model of the 
third-party applications hinges on their ability to sell the data they 
collect for secondary uses while payers and providers would be required 
to provide information to vendors absent a fee. This commenter argued 
that charging third-party vendors a fee for documentation could be one 
way for vendors to absorb some of the cost of maintaining the API in 
exchange for the data they could potentially use to make a profit.
    Response: We also appreciate the concerns raised around the 
secondary uses of data shared with third-parties. We note that under 
section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it is considered a 
deceptive act to use a person's sensitive information without 
disclosing in product documentation how this information will be 
shared.\31\ In addition, we do not believe that charging a fee to 
access API documentation is appropriate to offset secondary data use 
concerns. We refer readers to the additional discussion below regarding 
informing patients about potential secondary uses of data.
---------------------------------------------------------------------------

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

    The data that must be shared via the API under this policy are data 
that the payers have and must currently share with patients under 
existing law. The public directory data is already public information. 
We do not believe it is appropriate to charge a fee for documentation 
required to access such available data. Taking the example of provider 
directory data raised by commenters, currently there are vendors that 
collect the publicly available directory data, clean these data, 
supplement these data, and offer this enhanced data product back to 
payers and providers. It is not the data the vendors are charging for 
as much as it is the service of cleaning and enhancing these data. 
Vendors may generate revenue from their third-party apps, but a major 
component of this is the service they are providing--building the app, 
making the data the patient directs to them most usable and valuable--
that generates the revenue. Payers must already make these data 
available to patients. These data alone may also drive revenue, but it 
is the patient's prerogative to provide their data to a third-party in 
order to get a service in exchange. Being sure patients are as informed 
as possible about secondary uses of data and how this may impact them 
is important. As a result, we discuss this issue more below.
    Comment: Some commenters indicated support for permitting access to 
documentation without access fees, citing concern that the fees would 
be extended to consumers as well as logistical concerns for how they 
would be paid. A few commenters specifically recommended alignment with 
the ONC 21st Century Cures Act proposed rule API documentation 
requirement by using the language included in the discussion of the 
proposed requirement at 45 CFR 170.315(g)(10) stating that the 
documentation should be ``accessible to the public via a hyperlink 
without additional access requirements, including, without limitation, 
any form of registration, account creation, `click-through' agreements, 
or requirement to provide contact details or other information prior to 
accessing the documentation'' (84 FR 7484).
    Response: We do appreciate the requests to explicitly state what we 
mean by ``public access'' and ensure it is clear this does not permit 
any additional restrictions or fees. As a result, to further align with 
the discussion in the ONC 21st Century Cures Act proposed rule (84 FR 
7477), and the CMS Interoperability and Patient Access proposed rule 
(84 FR 7620), we are finalizing regulation text stating that ``publicly 
accessible'' means we expect that any person using commonly available 
technology to browse the internet could access the information without 
any preconditions or additional steps, such as a fee for access to the 
documentation; a requirement to receive a copy of the material via 
email; a requirement to register or create an account to receive the 
documentation; or a requirement to read promotional material or agree 
to receive future communications from the organization making the 
documentation available. We are finalizing this requirement at 42 CFR 
422.119(d), 431.60(d), 438.242(b)(5) (through cross-reference to 
Medicaid FFS), 457.730(d), 457.1233(d)(2) (through cross-reference to 
CHIP FFS), and 45 CFR 156.221(d).
    Comment: One commenter did not support this documentation proposal 
for security reasons as the commenter believed that if the 
documentation was public, any third-party or organization could 
potentially call, or connect to, a payer's API. This commenter 
preferred an alternate approach where CMS stipulates in order to call 
an API, there would need to be appropriate security tokens in place 
between the two parties engaged in the data exchange.
    Response: We appreciate the commenters' concerns. We note, however, 
that making the documentation available publicly does not impact the 
security of the standards-based API itself. This level of transparency 
is common in other industries and across standards, and has been shown 
to lead to innovation and competition. HL7 is built on free and open 
documentation to ensure that all developers can equally access 
information. Reviewing the documentation available for FHIR is one way 
of appreciating the value of this information and how having it freely 
accessible can allow innovators to engage with health care data in the 
most meaningful ways.\32\ Having access to the documentation is not the 
same as access to the actual API for the purposes of data exchange.
---------------------------------------------------------------------------

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

    Appreciating the comments received and the need to have 
documentation available to ensure successful implementation and use of 
the Patient Access API, we are finalizing our proposal to make publicly 
accessible documentation that includes, at a minimum: (1) API syntax, 
function names, required and optional parameters supported and their 
data types, return variables and their types/structures, exceptions and 
exception handling methods and their returns; (2) The software 
components and configurations an application must use in order to 
successfully interact with the API and process its response(s); and (3) 
All applicable technical requirements and attributes necessary for an 
application to be registered with any authorization server(s) deployed 
in conjunction with the API. As noted, we have made one modification by 
adding the definition of ``publicly accessible'' to the relevant 
regulation text.
e. Routine Testing and Monitoring of Standards-Based APIs
    At 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR 
156.221(c)(2) for MA organizations, state Medicaid and CHIP FFS 
programs, and QHP issuers on the FFEs, respectively, we proposed that 
the API must be routinely tested and monitored to ensure it is 
functioning properly, including assessments to verify that the API is 
fully and successfully implementing privacy and security features such 
as but not limited to those required to

[[Page 25544]]

comply with the HIPAA Privacy and Security Rules, 42 CFR parts 2 and 3, 
and other applicable law protecting privacy and security of 
individually identifiable health information. As proposed, Medicaid 
managed care plans would be required by 42 CFR 438.242(b)(6) 
(redesignated as 438.242(b)(5) in this final rule; see section VI. of 
this final rule) to comply with the requirement at 42 CFR 431.60(c), 
and CHIP managed care entities would be required by 42 CFR 
457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(c).
    Additionally, we noted that while federal laws that regulate MA 
organizations and MA plans supersede any state law except where noted 
under section 1856(b)(3) of the Act, some state, local, or tribal laws 
that pertain to privacy and security of individually identifiable 
information generally, and that are not specific to health insurance, 
may also apply to MA organizations and MA plans in the context of the 
proposal. For the other entities regulated under the proposals in these 
various programs, we noted that we also intended the phrase ``other 
applicable law'' to include federal, state, tribal or local laws that 
apply to the entity.
    We proposed this requirement to establish and maintain processes to 
routinely test and monitor the standards-based APIs to ensure they are 
functioning properly, especially with respect to their privacy and 
security features. We explained in the preamble of the proposed rule 
that under the proposal, MA organizations, Medicaid and CHIP FFS 
programs, Medicaid managed care plans, CHIP managed care entities, and 
QHP issuers on the FFEs would have to implement, properly maintain, 
update (as appropriate), and routinely test authentication features 
that will be used to verify the identity of individual enrollees who 
seek to access their claims and encounter data and other PHI through 
the API. Similarly, as discussed, compliance with the proposed 
requirements would mean that these entities must implement, maintain, 
update (as appropriate), and routinely test authorization features to 
ensure an individual enrollee or their personal representative can only 
access claims and encounter data or other PHI that belongs to that 
enrollee. As is the case under existing HIPAA Privacy Rule 
requirements, where an individual is also a properly designated 
personal representative of another enrollee, the HIPAA covered entity 
must provide the personal representative appropriate access to the 
information about the enrollee that has designated them as their 
personal representative, just as they would if the personal 
representative were the enrollee.
    We summarize the public comments we received on routine testing and 
monitoring and provide our responses.
    Comment: Several commenters supported the proposal to require that 
payers routinely test and monitor the standards-based API needed to 
meet the requirements of this proposal. One commenter recommended that 
this be self-regulated rather than mandated, however. A few commenters 
expressed concern with the requirement to test and monitor the API. A 
few additional commenters expressed concern that there is no consensus 
on a common testing environment. One commenter believed that testing 
and monitoring will be costly.
    Several commenters urged CMS to provide additional information and 
guidance on any requirements for testing and monitoring APIs, including 
the expected frequency of testing. A few commenters requested 
additional information on whether payers will be required to 
demonstrate compliance by submitting or reporting on testing plans. One 
commenter requested clarification on the process if an issue is found 
during testing or monitoring. One commenter requested that CMS specify 
what ``routine'' means.
    Response: We appreciate the commenters' concerns and 
recommendations. We did not specify exactly at what intervals or 
frequency testing should be done, and thus did not quantify 
``routine,'' as we believe it is important that payers put a process in 
place that works best for them to conduct testing and monitoring at 
regular intervals to ensure the required API remains in compliance and 
is working as expected. We will provide best practice information, 
including information on available API testing tools to support payers 
with this required activity. In our review of the proposed regulation 
text, we realized that the regulation text at 42 CFR 422.119(c)(2), 
431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2) did not specify 
the requirement to also update (as appropriate) the API to ensure it 
functions properly and includes assessments to verify an individual 
enrollee or their personal representative can only access claims and 
encounter data or other PHI that belongs to that enrollee. We are 
finalizing additional text to this effect. We are also removing the 
word ``minimally'' from this regulation text in order to ensure it is 
clear that privacy and security features must be reasonable and 
appropriate, consistent with the requirements of the HIPAA Security 
Rule. We note that this testing requirement is accounted for in 
sections XII. and XIII. of this final rule as one of the expected steps 
of implementing and maintaining an API. This is part of the cost 
factored into implementation of the API and is a necessary part of 
using an API. It is also part of current software development best 
practices. Payers implementing APIs can incorporate testing tools into 
a comprehensive testing plan and continuous integration (CI) system, 
which can automatically validate adherence to the implementation guide 
when changes are made to further mitigate this cost.
f. Compliance With Existing Privacy and Security Requirements
    In the hands of a HIPAA covered entity or its business associate, 
individually identifiable health information, including information in 
patient claims and encounter data, is PHI and protected by the HIPAA 
Rules. Ensuring the privacy and security of the claims, encounter, and 
other health information when it is transmitted through the API is 
important. Therefore, in the CMS Interoperability and Patient Access 
proposed rule (84 FR 7635), we reminded MA organizations, state 
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP 
managed care entities, and QHP issuers on the FFEs that mechanisms and 
practices to release PHI, including but not limited to authorization 
and authentication protocols and practices, must provide protection 
sufficient to comply with the HIPAA Rules and other privacy and 
security law (whether federal, state, tribal, or local) that may apply 
based on the specific circumstances. As proposed, the entities subject 
to these requirements would need to continuously ensure that all 
authorization and authentication mechanisms provide sufficient 
protections to enrollee PHI and that they function as intended. We 
specifically requested public comment on whether existing privacy and 
security standards, including but not limited to those in 45 CFR part 
164, are sufficient with respect to these proposals, or whether 
additional privacy and security standards should be required by CMS as 
part of the proposal.
    We note that comments and our responses related to privacy and 
security issues, generally, can be found in section II.A.2. of this 
final rule. Here, we summarize the public comments we received on 
privacy and security as it relates to consent, authentication, and 
identity verification and provide our responses.

[[Page 25545]]

    Comment: A few commenters expressed concerns with using the 
proposed FHIR standards for obtaining patient consent, with some noting 
the lack of mature consent mechanisms supported through FHIR. A few 
commenters expressed concerns that there are no mature or widely 
accepted standards for documenting patient consent electronically, 
generally. One commenter suggested that the patient be able to see 
their consent preferences and the types of data that have been 
authorized for sharing from a central location.
    One commenter recommended that CMS or OCR develop a standardized 
data sharing patient consent form that payers, providers, and health IT 
vendors can use to ensure appropriate consent. A few commenters 
recommended that CMS require payers and/or apps to use ONC's Model 
Privacy Notice. One commenter recommended that CMS and FTC should 
develop plain language consumer notifications that could be used by app 
developers. One commenter recommended that CMS require payers to 
include in their enrollment process an efficient ``check off'' 
authorization for an enrollee to release their information to their 
providers. A few commenters noted that it should be the responsibility 
of the app to verify the patient's ability to provide consent.
    Response: We appreciate the commenters concerns and 
recommendations, and we have shared these with ONC for consideration. 
Regarding FHIR standards for consent, we refer readers to discussion in 
the ONC 21st Century Cures Act final rule (published elsewhere in this 
issue of the Federal Register), which considers the status of current 
development efforts around consent resources. We will continue to work 
with ONC and industry partners to monitor the development of FHIR 
resources to support consent management. We believe that the security 
protocols at 45 CFR 170.215 are sufficient to authenticate users and 
authorize individuals to access their data maintained by payers in 
accordance with the requirements described in this rule and, therefore, 
provide the necessary consent mechanisms for payers to implement the 
policies in this rule.
    We appreciate the additional recommendations made regarding 
developing consent materials for all payers to use, as well as 
recommendations around the use of the ONC Model Privacy Notice. More 
information on available consent options can be found at https://gforge.hl7.org/gf/project/cbcc/frs/, and ONC's Model Privacy Notice is 
available at https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn, which interested payers or app vendors can 
use. We will evaluate recommendations made that would add requirements 
on payers that we had not proposed, including any centralized solution, 
for possible future rulemaking.
    Comment: Several commenters supported efforts to verify if an 
entity is authorized to access the data they are seeking. One commenter 
supported the proposed use of the OAuth standard. One commenter 
believes that the use of OAuth 2.0 for client application authorization 
and OpenID Connect for client application authentication should include 
authenticity, integrity, and non-repudiation standards. Another 
commenter suggested CMS permit flexibility in the implementation of 
security standards. A few commenters expressed concerns with using the 
proposed FHIR standards for identity proofing alone and supported 
additional measures, such as biometrics, be employed as well. A few 
commenters expressed concern about open-ended token access once 
initially authenticated and instead recommended CMS implement a 90-day 
timeframe for the authentication token to remain open. One commenter 
suggested that encryption of authentication credentials is not 
sufficient.
    One commenter believed that the only true means by which an 
individual can assert their identity is through a government-issued ID, 
and if this cannot be produced, the commenter noted several limitations 
that should be put in place to prohibit data sharing until further 
authentication can be done. Another commenter suggested CMS look into 
biometrics as a means for improving identity proofing. A few commenters 
recommended the use of multi-factor authentication to verify the 
identification of an individual.
    A few commenters recommended requiring payers give their members an 
online way to self-enroll for the necessary credentials to access their 
health information via an API. One commenter stated that this will 
reduce the time it takes for an organization to verify a request. One 
commenter recommended that this should apply to any of a payer's 
patients who have been a member in the past 5 years. One commenter 
expressed concern that without clear guidelines for how patients can 
access their data, patients may face barriers such as trying to get 
authentication credentials, and trying to get an app authorized.
    A few commenters recommended CMS develop a common method to 
validate the identity and authority of the requesting party. One 
commenter recommended CMS issue guidance on authenticating the 
requestor that offers a simple, secure method to obtain authentication 
across all entities. A few commenters supported efforts to develop 
methods to verify a caregiver for a patient and allow that caregiver to 
access all health information systems.
    Response: We appreciate the commenters' concerns and 
recommendations. We are finalizing as proposed to require compliance 
with 45 CFR 170.215 as finalized by HHS in the ONC 21st Century Cures 
Act final rule (published elsewhere in this issue of the Federal 
Register). This requires use of HL7 FHIR Release 4.0.1, and 
complementary security and app registration protocols, specifically the 
SMART Application Launch Implementation Guide (SMART IG) 1.0.0 
(including mandatory support for the ``SMART on FHIR Core 
Capabilities''), which is a profile of the OAuth 2.0 specification, and 
the OpenID Connect Core 1.0 standard, incorporating errata set 1). 
Additional information and implementation guidance can be found at 
https://hl7.org/fhir/smart-app-launch/. The goal of using these 
resources is to make authorization electronic, efficient, and secure so 
that patients can access their health information as effortlessly as 
possible.
    We agree that multifactor authentication represents a best practice 
for privacy and security in health care settings, and we note that an 
important benefit of the OAuth 2.0 standard HHS is finalizing is that 
it provides robust support for multifactor authentication. By requiring 
that payers subject to our Patient Access API requirement use an API 
that is conformant with 45 CFR 170.215, where HHS has finalized the 
SMART IG, we are supporting the use of multifactor authentication. We 
also note that as part of ONC's 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register), HHS is 
finalizing a new provision in the ONC certification program that would 
require health IT developers to attest as to whether they support 
multifactor authentication, further encouraging adoption of such 
security practices. We also strongly encourage payers subject to the 
requirements in this final rule to employ robust privacy and security 
protocols, and use multifactor authentication, where appropriate. 
Multifactor authentication is industry accepted, routinely used across 
many sectors,

[[Page 25546]]

known to patients, and a low burden option that could significantly 
increase security.
    Though we appreciate commenters' requests to leave flexibility 
here, we do believe adopting the standards as finalized by HHS in ONC's 
21st Century Cures Act final rule regarding the use of the SMART IG 
(using the OAuth 2.0 standard) and OpenID Connect Core 1.0 is an 
important starting point. In addition, we note that the technical 
standards at 45 CFR 170.215 address the comments regarding tokens, as 
HHS is finalizing use of tokens at 45 CFR 170.215 as part of the SMART 
IG. We note that ONC is requiring that a token be valid for at least 3 
months for certified health IT; we encourage payers subject to this 
final rule to align with this best practice. We appreciate 
recommendations for a centralized solution to patient authentication 
and identity proofing, and caregiver access, and will take these under 
consideration as appropriate.
    Comment: Many commenters expressed that patients should have 
ultimate authority and the ability to consent to what type of 
information can be shared as well as who can access their health 
information. One commenter recommended CMS require that patients have 
the ability to filter or request only the specific data that they want 
to be shared. One commenter requested that payers be able to access the 
specific types of data a patient authorized the app to access. One 
commenter added patients should also have an accounting of disclosures 
or access to their data.
    A few commenters expressed concerns over the sharing of patient 
electronic health information with health care providers that the 
patient has not consented to share with. A few commenters expressed 
specific concerns with sharing electronic health information beyond the 
immediate health care provider, such as with providers with which a 
patient may be seeking a second opinion or additional care. One 
commenter was concerned with the sharing of family health history data 
particularly for family members who have not consented.
    A few commenters recommended that providers be able to pre-filter 
or select which data can be made available to the patient, citing 
concerns with the sensitivity of some provider notes or patient 
confusion in interpreting certain information. A few commenters also 
suggested that providers be able to select which information can be 
made available to the payer.
    Response: We appreciate the commenters' concerns and suggestions. 
Collectively, HHS has been working to evaluate various technical 
specifications for data segmentation to enhance privacy protections and 
comply with applicable law (such as laws regarding privacy for minors 
or 42 CFR part 2). Both HHS and the industry as a whole are currently 
evaluating future use cases related to segmenting data at the patient 
request. At this time, however, the policies as they are being 
finalized under this rule require that the payers, with the approval 
and at the direction of the patient, provide all of the data as 
specified in the applicable regulation text. Beyond this, payers, 
providers, and patients cannot direct specific segments of data be made 
available via this Patient Access API. The necessary technical 
specifications to allow a patient to request some data elements be 
shared but not others are not widely adopted.\33\ If the patient 
requests their data via the Patient Access API from a payer, the payer 
must make available all of the data allowed per current law, such as 42 
CFR part 2 and relevant state laws, including the data as specified in 
this final rule. We reiterate, however, that the data that are 
available to be shared are only to be shared at the patient's request. 
If there are data elements the patient does not want to be shared, they 
can choose not to make the request. In addition, we note that this 
policy allows data to be exchanged from the payer to a third-party app 
of the patient's choice for their personal use. This rule does not 
require any data exchange directly between or with providers.
---------------------------------------------------------------------------

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

    Specifically regarding the comment on sharing family history, we 
note that the health information required to be shared under this 
policy includes claims and encounter data as well as the data included 
in the USCDI version 1. At this time, ``family history'' is not a 
specific data class within the USCDI. As a result, we do not believe 
this should be an issue under this current policy. We will, however, 
take this into consideration as we consider future policy options.
    We appreciate the recommendation for patients to have a full record 
of disclosures or access to their health information via the API. At 
present, the HIPAA Privacy Rule requires accountings of certain 
disclosures. Consistent with the spirit of this accounting of 
disclosures, we encourage payers to consider setting up functionality 
to allow patients to view a record of when and with whom their data 
have been shared via the API.
    Comment: Many commenters expressed concerns over the complexity 
with parsing or segmenting electronic health information that is 
considered sensitive and/or is subject to 42 CFR part 2 rules. 
Commenters requested CMS take into account these situations with these 
API proposals and cited use cases such as women's health, sexual 
health, young adult health, mental health, and substance abuse 
treatment. A few commenters noted concerns that some health care 
providers may discriminate or treat a patient differently if they were 
able to access certain patient's health information. A few commenters 
recommended that HHS align part 2 and HIPAA regulations. One commenter 
recommended the use of the Consent2Share (C2S) FHIR Consent Profile 
developed by SAMHSA. Another commenter suggested CMS defer adoption of 
the Data Segmentation for Privacy standards until an API FHIR standard 
version is finalized and the Consent2Share guide is revised to conform 
to that version.
    Response: We appreciate the commenters concerns and 
recommendations. We are currently evaluating future options around 
parsing or segmenting data, generally, using the API. As noted above, 
HHS is collectively working to explore standards and technical supports 
for data segmentation for privacy and consent management and point 
commenters to the ONC 21st Century Cures Act final rule for additional 
discussion on this. We also note that using the appropriate FHIR 
profiles, such as those being finalized by HHS in the ONC 21st Century 
Cures Act final rule (published elsewhere in this issue of the Federal 
Register) for API technical standards, including the SMART IG (using 
the OAuth 2.0 standard) and OpenID Connect as finalized at 45 CFR 
170.215, can be leveraged to support this. Again, we note that 
additional information and implementation guidance can be found at 
https://hl7.org/fhir/smart-app-launch/. However, we reiterate that 
payers' privacy and security obligations under the HIPAA Rules and 42 
CFR part 2 are not impacted by this final rule.
    Comment: A few commenters expressed particular concern for 
appropriate authorization of parent/guardian proxies for minor 
patients. One commenter recommended CMS align the CMS Interoperability 
and Patient Access proposed rule with the Children's Online Privacy 
Protection Act (COPPA), which was created to

[[Page 25547]]

protect the privacy of children under 13 and has been in effect since 
2000.
    Response: We appreciate the commenters concerns and 
recommendations, which we are reviewing for future possible 
consideration in regulation. We note that this current regulation does 
not change any existing privacy relationships between minors and 
parents. If, for instance, a teenage minor has asserted their 
protections to not have their guardians see their Explanation of 
Benefits, the payer would be obligated to maintain these protections 
when sharing data via the API. For non-minor dependents, again the 
existing policies hold true.
    Regarding privacy in an enrollment group, at this time, a 
policyholder can see the claims for all members of their enrollment 
group unless there is an agreed upon privacy provision available and in 
place. The HIPAA Privacy Rule states at 45 CFR 164.522 that individuals 
have a right to request restrictions on how a covered entity will use 
and disclose protected health information about them for treatment, 
payment, and health care operations. However, a covered entity is not 
generally required to agree to an individual's request for a 
restriction unless certain limited exceptions are met \34\, but is 
bound by any restrictions to which it does agree. After the Affordable 
Care Act extended the age that group health plans and issuers of health 
insurance coverage in the group or individual market that offer 
dependent coverage of children must continue to make such coverage 
available to adult children until age 26, some states, including 
California, Colorado, Washington, Oregon, and Maryland, have enacted 
stricter protections regarding privacy rights, and although all of 
these states operate their own SBEs and issuers on these Exchanges are 
not implicated in this rule, to the extent issuers are operating in 
both these and FFE states and have applied their privacy policies 
across markets, consumers in FFE states may also benefit from these 
stricter protections. This final rule does not alter obligations under 
any existing federal, state, local, or tribal law. Again, we note that 
this data sharing is currently ongoing; the API just provides an 
additional way to facilitate this exchange.
---------------------------------------------------------------------------

    \34\ See 45 CFR 154.522(a)(1)(vi) for a discussion of the 
limited exceptions.
---------------------------------------------------------------------------

g. Issues Related to Denial or Discontinuation of Access to the API
    We believe patients have a right to their health information. 
However, a covered entity is not expected to tolerate unacceptable 
levels of risk to the PHI held by the covered entity in its systems, as 
determined by its own risk analysis. Accordingly, it may be appropriate 
for an organization to deny or terminate specific applications' 
connection to its API under certain circumstances in which the 
application poses an unacceptable risk to the PHI on its systems.
    At 42 CFR 422.119(e), Sec.  431.60(e), 438.242(b)(6) (redesignated 
as Sec.  438.242(b)(5) in this rule; see section VI.), 457.730(e), 
457.1233(d)(2) and 45 CFR 156.221(e) for MA organizations, state 
Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP 
managed care entities, and QHP issuers on the FFEs, respectively, we 
proposed to specify the circumstances under which these regulated 
entities, which are all HIPAA covered entities subject to HIPAA privacy 
and security requirements, may decline to establish or may terminate a 
third-party application's connection to the covered entity's API while 
remaining in compliance with the proposed requirement to offer patients 
access through standards-based APIs. We noted in the CMS 
Interoperability and Patient Access proposed rule that we intended for 
the proposal to be consistent with the HIPAA Rules, and we noted that 
these circumstances apply to specific applications, rather than the 
third party itself (84 FR 7635 through 7636).
    Specifically, we proposed that a payer subject to our API proposal 
could deny access to the API if the payer reasonably determined that 
allowing that application to connect or remain connected to the API 
would present an unacceptable level of risk to the security of PHI on 
the payer's systems. We further proposed that this determination would 
be made consistent with the payer's HIPAA Security Rule obligations and 
based on objective, verifiable criteria that would be applied fairly 
and consistently across all applications through which enrollees seek 
to access their electronic health information as defined at 45 CFR 
171.102, including but not limited to criteria that may rely on 
automated monitoring and risk mitigation tools.
    Where we proposed to require access through standards-based APIs to 
otherwise publicly available information, such as provider directories, 
the entities subject to the proposal may also deny or terminate an 
application's connection to the API when it makes a similar 
determination about risk to its systems. However, depending on how the 
organization's systems are designed and configured, we recognize that 
the criteria and tolerable risk levels appropriate to assessing an 
application for connection to an API for access to publicly available 
information may differ from those required for API access to non-
published personally identifiable information (PII).
    We also anticipated that, where an application's connection has 
been terminated under these circumstances, it might be feasible in some 
instances for the organization to allow the application to reconnect to 
the API if and when the flaw or compromise of the application has been 
addressed sufficiently that the organization can no longer fairly say 
the application's API connection continues to pose an unacceptable 
risk.
    We summarize the public comments we received on denial or 
discontinuation of service and provide our responses.
    Comment: Several commenters supported the proposal to allow payers 
to deny or discontinue access to apps that pose security risks. One 
commenter specifically supported that the proposal does not allow 
payers to deny requests based on concerns about the worthiness of the 
third-party as a recipient of PHI, because patients have the right to 
share their health information with the app they choose.
    Several commenters encouraged CMS to develop and/or further define 
guidelines for identifying ``unacceptable risk'' and establish a 
clearer standard for acceptable circumstances when API access can be 
restricted or denied. A few commenters expressed concerns that the 
proposed requirements may be interpreted differently among payers, 
apps, users, and providers. One commenter expressed concern because 
payers are liable for breaches that occur during data exchange and the 
commenter does not believe the proposal provides clear authority to 
deny access based on such security concerns. A few commenters requested 
that CMS provide more information regarding whether payers may delay 
and/or deny certain apps that are suspected, or proven to be bad 
actors. One commenter requested that CMS make the distinction between 
the risk posed by providing PHI and providing other widely available 
payer data. A few commenters requested CMS define a time period for how 
long the ban on access may remain in place. One commenter sought 
additional

[[Page 25548]]

information on whether payers will be able to deny third-party access 
across the board for all patient queries and plans. A few commenters 
suggested that CMS should develop a clear process for app developers to 
follow in the event that a covered entity denies access to an API. A 
few commenters recommended that CMS include in the final rule a 
reference to ONC's information blocking definition and clarify that 
unacceptable levels of risk could be an exception to information 
blocking.
    Response: We appreciate the commenters' concerns. As discussed in 
the CMS Interoperability and Patient Access proposed rule, the criteria 
and process for assessing unacceptable risk to a payer's system are 
part of the payer's responsibilities under the HIPAA Security Rule (84 
FR 7635). The HIPAA Security Rule requires a covered entity to perform 
risk analysis as part of its security management processes.\35\ HHS 
makes a number of tools available to assess risk.\36\ Additional tools 
are available through the National Institute of Standards and 
Technology (NIST).\37\
---------------------------------------------------------------------------

    \35\ 45 CFR 164.308(a)1)(ii)(A).
    \36\ For more information, see https://www.hhs.gov/hipaa/for-professionals/security/.
    \37\ Brooks, S., Garcia, M., Lefkovitz, Ligthman, S., & Nadeau, 
E. (2017, January). NISTIR 8062
    An Introduction to Privacy Engineering and Risk Management in 
Federal Systems. Retrieved from https://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf.
---------------------------------------------------------------------------

    We note that this policy regarding denial or discontinuation of 
service refers to a payer's determination that allowing access to their 
API by a third party would result in risk to their system. As also 
noted previously, covered entities, in accordance with HIPAA privacy 
and security obligations, should take reasonable measures to protect 
data in transit, unless an individual expressly asks that the 
information be conveyed in an unsecure form or format (assuming the 
individual was warned of and accepted the risks associated with the 
unsecure transmission). As explained in this section above, it is the 
responsibility of payers to assess the risk to their system and act 
accordingly regardless of whether the data being accessed via the API 
is PHI or not. If the concern is the security of the payer's system, 
the type of data being transferred is not at issue. Absent an 
individual's instruction to disregard in-transit security, if while 
assessing the security of the app's connection to the API, the covered 
entity determines the data could be compromised in transit, the payer 
could discontinue or deny access in order to project the ePHI on its 
system. Again, this assessment must be based on objective, verifiable 
criteria in accordance with obligations under the HIPAA Security Rule. 
Having considered comments, we are finalizing that payers may deny or 
discontinue any third-party application's connection to their API if 
the payer reasonably determines, consistent with its security analysis 
under 45 CFR part 164 subpart C, that allowing an application to 
connect or remain connected to the API would present an unacceptable 
level of risk to the security of protected health information on the 
payer's systems or in transit in instances in which the individual did 
not tell the payer to disregard in-transit risk. For example, where an 
individual requests that their unencrypted ePHI be transmitted to an 
app, the payer would not be responsible for unauthorized access to the 
individual's ePHI while in transmission to the app. When access has 
been denied or discontinued due to security concerns, we encourage 
payers and third parties to work together to address the concerns if 
and as possible to best serve patients. We are not able to set a 
specific time period or process for this as it is beyond our authority, 
however, we do note that the HIPAA Privacy Rule requires access to be 
provided to the individual in a timely manner. Regarding information 
blocking, we refer readers to the ONC 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register).
    Comment: One commenter requested that CMS indicate whether third-
party applications will be subject to HIPAA or FTC regulations. One 
commenter requested information about whether patients will be able to 
terminate third-party access to their health data.
    Response: We appreciate the commenters' request for more 
information. We refer commenters to OCR and FTC for additional 
information about jurisdiction over third-party apps. We do note, as 
discussed earlier, that under section 5 of the FTC Act (15 U.S.C. Sec. 
45(a)), the FTC does regulate such third-party apps. Regarding a 
patient's ability to terminate third-party access, this would be 
something determined in the terms and conditions of each app.
    Comment: A few commenters recommended that covered payers should 
have the flexibility to establish additional terms and conditions when 
denying third-party applications access to their systems. One commenter 
stated that payers should be able to develop their own validation 
process for enrollees and have the right to not release the data where 
the full scope cannot be validated. One commenter stated the payers 
should be able to refuse to connect to non-vetted apps. Another 
commenter stated that payers should be able to restrict access if the 
information exchanged is not permitted under the HIPAA Privacy Rule or 
if the exchange or use would compromise the confidentiality, integrity, 
and availability of the information. One commenter recommended that CMS 
allow covered entities to remove an app from their system if the app 
does not follow the approved privacy policy. One commenter recommended 
that providers should be allowed to require a business associate 
agreement (BAA) with third-party app developers that connect to the API 
required under this final rule. One commenter suggested allowing 
restrictions on data mining. However, one commenter expressed concern 
that payers may place unnecessary barriers and burdens on third-party 
app developers. The commenter encouraged CMS to ensure that payers 
cannot place additional constraints on apps, such as requiring a BAA, 
additional security audits, or requiring that apps make commitments 
about how it will or will not use the information patients store on it.
    Response: We appreciate the commenters' recommendations. 
Specifically, regarding the ability to deny access to a third-party 
app, we are finalizing this policy as proposed with one modification to 
add additional clarity around what it means to reasonably determine 
risk. As such, and as noted above, we are finalizing that payers may 
deny or discontinue any third-party application's connection to their 
API if the payer reasonably determines, consistent with its security 
analysis under 45 CFR part 164 subpart C, that allowing an application 
to connect or remain connected to the API would present an unacceptable 
level of risk to the security of protected health information on the 
payer's systems and the payer makes this determination using objective, 
verifiable criteria that are applied fairly and consistently across all 
applications and developers. As patients have a right to their data and 
this proposal provides the payers the ability to appropriately protect 
their systems and the data they hold on it, we do not believe any 
additional restrictions are needed at this time. We also note it would 
not be appropriate to require a patient-designated third party to enter 
into a BAA with a payer as the API-facilitated exchange is taking place 
per the request of the patient and not by,

[[Page 25549]]

on behalf of, or in service to the payer.\38\ In addition, we reiterate 
that it is beyond our authority to regulate third parties directly. We 
do note that under section 5 of the FTC Act (15 U.S.C. Sec. 45(a)), it 
is considered a deceptive act to use a person's sensitive information 
without disclosing in product documentation how this information will 
be shared. We do, however, believe patient privacy and security are 
vitally important. As a result, we lay out an option for payers to ask 
a third-party app to attest to certain privacy provisions, to help make 
patients aware of the privacy risks associated with their choices, as 
detailed in the next section.
---------------------------------------------------------------------------

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

    Comment: Several commenters had suggestions on how to further this 
proposal. A few commenters recommended that CMS could require apps to 
attest to certain privacy and security provisions, and if they did not, 
payers could deny access to the API. One commenter recommended that 
payers be required to vet third-party applications centrally, rather 
than requiring vetting for every payer and plan. A few commenters 
expressed concern that it will be significantly burdensome for payers 
and providers to vet every app that patients may choose to use in 
support of more central vetting. One commenter suggested that app 
developers should be able to proactively request to be vetted by a 
payer, even if the app developer has not received a request from a 
member.
    Many commenters recommended CMS and/or HHS establish a 
certification, independent verification, or vetting process for third-
party applications and vendors that would vet or test apps for certain 
functions, including privacy and security assurances. As an 
alternative, one commenter recommended CMS require apps generate an 
accounting of disclosures or join a trusted exchange network.
    A few commenters requested CMS share its best practices with app 
authorization and access under the Blue Button 2.0 initiative. A few 
commenters recommended CMS, or the payers pre-approve and/or maintain a 
list of approved apps in order for them to access data. Several 
commenters supported CMS' proposal to allow patients to select any app 
of their choice. One commenter recommended that providers and payers be 
required to authenticate the apps their patients choose to use to gain 
access.
    One commenter recommended that third-party application should be 
clear in their terms and conditions when a consumer downloads an app, 
and if they are not, a payer should not be required to interface with 
the app. One commenter recommended that the proposal for payers to deny 
or terminate specific applications from connecting to its API if the 
risk posed to its systems is unacceptable should be extended to 
hospitals, health systems, and other health care providers. One 
commenter suggested that payers should be required to consider the 
security risks related to provider EHR systems when determining whether 
to deny or terminate a third-party application. One commenter 
recommended that CMS develop three options for denial of an 
application: denial at each API endpoint, centralized application 
denial, or no denial. One commenter suggested that CMS could consider 
allowing providers to voluntarily seek assurances or certifications 
that third-parties are abiding by the API's terms.
    Response: We appreciate the commenters' recommendations, and we 
appreciate the concerns raised around privacy and security and the 
discussion regarding additional steps we can take to protect patient 
health information. We note that hospitals, health systems, and other 
health care providers are considered covered entities under HIPAA, and 
the HIPAA Privacy and Security Rules apply.
    We do appreciate that app vetting, in particular, is an issue of 
great interest to payers and providers. We note that we strongly value 
the role that industry can play in this capacity, and we support 
efforts within industry to facilitate efficient and effective, publicly 
accessible information on vetted apps and vendors. We believe industry 
is in the best position to collectively find the best ways to identify 
those apps with strong privacy and security practices. We also 
appreciate the commenters' request for best practices learned through 
our experience with Blue Button 2.0. You can find this information at 
https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
    We are not going to pursue the recommendation to develop a CMS or 
HHS app certification program. Under our current authorities, we do not 
believe we have the ability to require a third-party app to take part 
in such a certification program.
    We do appreciate that, above all else, stakeholders commented on 
privacy and security and the need to do more to protect patient health 
information. Throughout this rule we have noted the limitations to our 
authority to directly regulate third-party applications. We have also 
explained that we are finalizing that payers can deny API access to a 
third-party app that a patient wishes to use only if the payer assesses 
that such access would pose a risk to the PHI on their system. We 
appreciate, however, that more needs to be done.
    In the ONC 21st Century Cures Act final rule (published elsewhere 
in this Federal Register), ONC notes that it is not information 
blocking to inform a patient about the advantages and disadvantages and 
any associated risks with sharing their health information with a third 
party. In this rule, we are finalizing that impacted payers must share 
educational resources with patients to help them be informed stewards 
of their health information and understand the possible risk of sharing 
their data with third-party apps. As discussed above, commenters 
believe it is a risk when patients do not understand what happens after 
their data leaves the protection of HIPAA and are transmitted to a 
third-party app. Commenters were specifically concerned about secondary 
uses of data. A clear, plain language privacy policy is the primary way 
a patient can be informed about how their information will be protected 
and how it will be used once shared with a third-party app.
    Taking into consideration comments indicating strong public support 
for additional privacy and security measures, we are further building 
off of the privacy and security policies we are finalizing in this rule 
by asserting that MA organizations, Medicaid FFS programs, Medicaid 
managed care plans, CHIP FFS programs, CHIP managed care entities, and 
QHP issuers on the FFEs are encouraged, but are not required, to 
request third-party apps attest to having certain privacy and security 
provisions included in their privacy policy prior to providing the app 
access to the payer's API. If a payer chooses, they can ask that the 
apps requesting access to their API with the approval and at the 
direction of the patient to attest that important provisions that can 
help keep a patient's data private and secure are in place. Explaining 
certain practices around privacy and security in a patient-friendly, 
easy-to-read privacy policy helps inform patients about an app's 
practices for handling their data. It helps patients understand if and 
how the app will protect their health information and how they can be 
an active participant in the protection of their information. Also, as 
explained earlier in this final rule, if an app has a written privacy 
policy and does not follow the policies as written, the FTC has 
authority to intervene. As a result,

[[Page 25550]]

we assert that impacted payers can, but are not required to, ask a 
third-party app to attest that:
     The app has a publicly available privacy policy, written 
in plain language,\39\ that has been affirmatively shared with the 
patient prior to the patient authorizing app access to their health 
information. To ``affirmatively share'' means that the patient had to 
take an action to indicate they saw the privacy policy, such as click 
or check a box or boxes.
---------------------------------------------------------------------------

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

     The app's privacy policy includes, at a minimum, the 
following important information:
    ++ How a patient's health information may be accessed, exchanged, 
or used by any person or other entity, including whether the patient's 
health information may be shared or sold at any time (including in the 
future);
    ++ A requirement for express consent from a patient before the 
patient's health information is accessed, exchanged, or used, including 
receiving express consent before a patient's health information is 
shared or sold (other than disclosures required by law or disclosures 
necessary in connection with the sale of the application or a similar 
transaction);
    ++ If an app will access any other information from a patient's 
device; or
    ++ How a patient can discontinue app access to their data and what 
the app's policy and process is for disposing of a patient's data once 
the patient has withdrawn consent.
    Payers can look to industry best practices, including the CARIN 
Alliance's Code of Conduct \40\ and the ONC Model Privacy Notice\41\ 
for other provisions to include in their attestation request that best 
meet the needs of their patient population. If a payer chooses to 
request third-party apps provide this attestation, the payer must not 
discriminate in its implementation, including for the purposes of 
competitive advantage. Specifically, if a payer requests this 
attestation of one app, it must request it of all apps that seek to 
obtain data. If the third-party app does not attest that their privacy 
policy meets the provisions indicated by the payer, the payer may 
inform patients that the app did not attest and advise them to 
reconsider using this third-party app. The notification to the patient 
should make it clear that the app has not attested to having the basic 
privacy and security protections and indicate what those are, and that 
the patient should exercise caution before opting to disclose their 
information to the app. If the patient still requests the payer make 
their data available to the third-party app, the payer must provide API 
access to the app unless doing so would endanger the security of PHI on 
the payer's systems. This process should not overly delay the patient's 
access. If the app does not attest positively or at all, the payer must 
work to quickly inform the patient and provide a short window for the 
patient to cancel their request the data be shared. If the patient does 
not actively respond, the payer must move forward as the patient has 
already directed their data be shared and this initial request must be 
honored.
---------------------------------------------------------------------------

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

    We believe it is important for patients to have a clear 
understanding of how their health information may be used by a third-
party, as well as how to stop sharing their health information with a 
third-party, if they so choose. We believe the use of this attestation, 
in combination with patient education, will help patients be as 
informed as possible while providing payers with a lower burden vetting 
option. We believe this will better help protect patient privacy and 
security and mitigate many of the concerns raised. Together, this 
framework and the requirement for payers to provide patients with 
educational resources will help continue to move us toward a safer data 
exchange environment. This is a critical focus for CMS, and we look 
forward to continuing to work with stakeholders to keep patient privacy 
and data security a top priority.
h. Enrollee and Beneficiary Resources Regarding Privacy and Security
    As discussed in section II.A. of the CMS Interoperability and 
Patient Access proposed rule (84 FR 7618 through 7623), we are 
committed to maximizing enrollees' access to and control over their 
health information. We noted that we believed this calls for providing 
enrollees that would access data under the proposal with essential 
information about the privacy and security of their information, and 
what to do if they believe they have been misled or deceived about an 
application's terms of use or privacy policy.
    At 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 
156.221(g), we proposed to require MA organizations, state Medicaid and 
CHIP FFS programs, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs, to make available to their 
current and former enrollees certain information about: factors to 
consider in selecting a health information management application, 
practical strategies to help them safeguard the privacy and security of 
their data, and how to submit complaints to OCR or FTC. The proposed 
obligations would apply to Medicaid managed care plans and CHIP managed 
care entities through cross-references proposed in 42 CFR 438.242(b)(6) 
(finalized as Sec.  438.242(b)(5) in this final rule; see section VI. 
of this final rule) and Sec.  457.1233(d)(2).
    The general information about the steps individuals can take to 
help protect the privacy and security of their health information 
should not be limited to, but should specifically include and emphasize 
the importance of understanding the privacy and security practices of 
any application to which they entrust their data. Information about 
submitting complaints should include both specific contact information 
for the OCR and FTC complaints processes and a brief overview, in 
simple and easy-to-understand language, of: What organizations are 
HIPAA covered entities, OCR's responsibility to oversee compliance with 
HIPAA, and FTC's complementary responsibility to take action against 
unfair or deceptive practices, including by non-covered entities that 
may offer direct-to-consumer health information management 
applications.
    We proposed that this information must be made available on the 
website of the payers subject to the proposed requirement, and through 
other appropriate mechanisms through which the payer ordinarily 
communicates with enrollees that are seeking to access their health 
information held by the payer. This could include customer portals, 
online customer service help desks, and other locations, such as any 
portals through which enrollees and former enrollees might request 
disclosure of their data to a third-party application through the 
payer's API. We also proposed that the payer must make this information 
available in non-technical, simple, and easy to understand language.
    We explained in the proposed rule how we anticipate that payers 
could meet the requirement to provide information to current and former 
enrollees in whole or in part using materials designed for consumer 
audiences that are available on the HHS website. However, we noted that 
whether the organization chooses to draft its own resource materials to 
provide the required information or to

[[Page 25551]]

rely on governmental or other sources for such materials, the 
organization will be responsible for ensuring that the content of the 
materials is adequate to inform the patient regarding the privacy and 
security risks, and that it remains current as relevant law and policy 
may evolve over time. We sought comment on the proposal, and we invited 
additional comments on what specific information resources in addition 
to those already available on the websites noted above would be most 
useful to entities in meeting this requirement. We anticipated using 
this feedback to help inform HHS planning and prioritization of 
informational resource development work in addition to making a 
decision on the final rule regarding the proposal.
    We summarize the public comments we received on enrollee resources 
and provide our responses.
    Comment: Several commenters supported the enrollee resources 
proposal that would require payers to make information available to 
consumers about selecting an app, safeguarding data, and submitting 
complaints. Several commenters supported the recommendation that the 
resources be available in consumer-friendly language and be presented 
in a way that is easy for consumers to understand. One commenter 
requested more information about whether payers may make the 
educational information available through electronic disclosures, such 
as emailing the information to enrollees, in addition to making the 
information available online.
    Response: We appreciate the commenters' support. We do note that 
payers may share the information through other appropriate mechanisms 
usually used to communicate with patients, such as secure email, as 
well as include the information on a payer website.
    Comment: A few commenters recommended that CMS provide patient 
education resources to help patients understand the information 
available to them through the payers' APIs. These commenters expressed 
concerns that patients may not fully understand the context of the 
data, such as detailed claims information that may not be intuitive to 
understand. Several commenters expressed concern with consumers' lack 
of knowledge about the privacy and security of their health information 
as it relates to third-party applications. Several commenters expressed 
concern that consumers may not understand that their health information 
is not protected by HIPAA once the information is sent to a non-covered 
third-party app or how an app may use their health information.
    Many commenters recommended that CMS develop and/or support 
education for consumers. Several commenters stated that CMS should have 
the responsibility to develop educational materials, rather than the 
payers or providers. Many commenters recommended that CMS collaborate 
with other regulatory agencies, including OCR and the FTC, to provide 
consumer education and notification materials. Several commenters 
recommended that CMS and other HHS agencies develop a campaign to 
educate patients about the privacy and security of health information, 
including the risks and challenges when connecting to third-party apps 
as well as differences between HIPAA and non-HIPAA covered entities and 
how the differences may affect how their data are used, stored, and 
shared.
    Specifically, a few commenters recommended that CMS and FTC should 
require that third-party app developers inform consumers that HIPAA 
privacy rules will not apply when they agree to share their data with 
apps and describe how they will use the consumer's data. One commenter 
recommended that educational materials include information on the 
differences between HIPAA and FTC protections. One commenter 
recommended that CMS, OCR, or FTC publish the resources on their 
website and maintain a complaint portal. A few commenters stated that 
it is the responsibility of all stakeholders to inform consumers of 
their rights and use of PHI. One commenter recommended that the 
responsibility of providing educational materials to the consumer 
should fall on an organization where the patient may have a longer-
term, non-transactional relationship, such as an HIE.
    Several commenters expressed concern that educational resources 
will not be enough to promote privacy and security. Several commenters 
recommended that CMS and ONC should require third-party apps to provide 
notifications on how they may use, share, or sell their health 
information. One commenter expressed concern that there will not be 
enough oversight over third-party apps. The commenter recommended that 
CMS use HIPAA as a framework for developing a privacy structure for 
third-party apps.
    Response: We appreciate the commenters' concerns and 
recommendations. We agree it is important to help ensure patients fully 
understand their health information, their rights, and the implications 
of sharing their information. It is also important patients know what 
to do if there is a breach of their health information. We appreciate 
that it would eliminate some burden from payers and providers if we 
assist with the production of the educational materials needed for the 
purposes of the requirements in this final rule. As a result, CMS is 
providing suggested content for educational materials that payers can 
use to tailor to their patient population and share with patients. We 
are finalizing the requirement with modification that payers must 
publish on their websites the necessary educational information, but we 
will help supply the content needed to meet this requirement. The 
suggested content we are providing for the educational materials will 
be shared through our normal communication channels including via 
listservs and is available via our website: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. The 
modification we are making is to refine the language in the regulation 
text to expressly state that payers must include a discussion about a 
third-party app's secondary uses of data when providing factors to 
consider in selecting an application at 42 CFR 422.119(g)(1), 
431.60(f)(1), and 457.730(f)(1), and 45 CFR 156.221(g)(1). In addition, 
at 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g), 
we are modifying the regulation text to state the payer must make these 
materials available in an easily accessible location on its public 
website.
    We note, however, that our authority is limited to helping payers 
educate patients about their privacy and security rights and where they 
can go for additional information. We have shared commenter feedback 
with our federal partners and will continue to work with all 
stakeholders to ensure patients, providers, and payers have the 
information they need to address privacy and security issues relevant 
to the regulations finalized in this rule. We will also continue 
coordinating with ONC and all of our federal partners through the 
Federal Health IT Coordinating Council and other federal partnering 
opportunities to ensure we are tracking the impact of this final rule 
together, as appropriate. Privacy and security, however, is a much 
larger issue, and we remind commenters that CMS does not have authority 
to regulate third-party apps or their developers or develop privacy 
frameworks that exceed the scope of our authority or this final rule.
    Comment: Several commenters provided additional recommendations 
related to patient resources. One commenter recommended requiring

[[Page 25552]]

payers to include information on how the consumer can contact the payer 
directly to report a privacy or security breach. One commenter 
recommended that CMS develop an easy-to-understand questionnaire for 
third-party applications to fill out that included information about 
how the app plans to use the data. This questionnaire could be 
available to patients. One commenter recommended that educational 
information about tools be available to family members and clinicians 
and not just the patient. One commenter suggested including educational 
content for specific conditions or patient populations, such as for 
pediatric care.
    Several commenters recommended that CMS include a requirement that 
the educational materials developed for consumers should also include 
materials for consumers who may be limited English proficient or have 
low health literacy. A few commenters recommended that educational 
materials should be developed with special considerations for 
vulnerable populations. One commenter recommended that consistent 
information be available across multiple settings to accommodate 
varying levels of technology literacy.
    Response: We appreciate the commenters' recommendations. As 
indicated above, we will be providing suggested content for educational 
materials to assist payers in meeting their educational obligations 
under this final rule as detailed at 42 CFR 422.119(g), 431.60(f), and 
457.730(f), and 45 CFR 156.221(g). We note that this would also be 
available to caregivers and family members as we are requiring this 
material to be posted on the payer's website. Payers can tailor these 
materials to best meet the needs of their patient populations, 
including literacy levels, languages spoken, conditions, etc. Regarding 
recommendations to have patients contact the payer directly in the 
event of a breach, that is the patient's prerogative; a payer is 
required by the HIPAA Privacy Rule to have procedures for individuals 
to submit complaints, and to provide directions for doing so in its 
Notice of Privacy Practices. Individuals may also submit complaints to 
the OCR and FTC, in the appropriate situations, to address these 
concerns. Finally, we reiterate that we do not have the authority to 
regulate apps, so we cannot ask apps to fill out a questionnaire or 
facilitate sharing that information with patients. We do note that we 
are making available a document containing best practices for app 
developers to follow, with a special emphasis on ways to protect the 
privacy and security of patient data: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
i. Exceptions or Provisions Specific to Certain Programs or Sub-
Programs
    We proposed certain exceptions or specific additional provisions as 
part of the CMS Interoperability and Patient Access proposed rule (84 
FR 7637) for certain QHP issuers on the FFEs. We also proposed 
specifics about how MA organizations subject to the regulations 
finalized here would have to include certain information about the Part 
D benefit if the MA organization also offered Part D benefits; those 
aspects of the proposals are addressed in section III.C.2.c(1) of this 
final rule.
    Related to QHP issuers, we specifically proposed two exceptions. 
First, we proposed that the requirements proposed in 45 CFR 156.221(a) 
not apply to issuers offering only SADPs on the FFEs. In contrast to 
QHP issuers of medical plans, issuers offering only SADPs offer 
enrollees access to a unique and specialized form of medical care. We 
believed the proposed standards and health IT investment would be 
overly burdensome for SADP issuers as related to their current 
enrollment and premium intake and could result in SADP issuers no 
longer participating in FFEs, which would not be in the best interest 
of enrollees. Additionally, we believed much of the benefit to 
enrollees from requiring issuers of QHPs to make patient data more 
easily available through a standard format depends upon deployment of 
standards-based API technology that conforms to standards proposed by 
ONC for HHS adoption at 45 CFR 170.215 (84 FR 7589) and a corresponding 
energetic response by the developer community in developing innovative, 
useful, usable, and affordable consumer-facing applications through 
which plan enrollees can conveniently access, use, and share their 
information as they choose. Based on the proposals to require 
implementation of standards-based API technology in the Medicare, 
Medicaid and CHIP programs, as well as by QHP issuers on the FFEs, we 
would anticipate significantly expanding the implementation of 
standards-based APIs by medical plans. However, we noted that we did 
not anticipate similar widespread usage with respect to SADPs. 
Therefore, we believed that the utility of access to issuers' data is 
less applicable to dental coverage, and did not believe it would be in 
the interest of qualified individuals and qualified employers in the 
states in which an FFE operates to not certify SADPs because they do 
not provide patient access to their data through a standards-based API. 
We sought comment on whether we should apply this policy to SADP 
issuers in the future.
    We also proposed to provide an exceptions process through which the 
FFEs may certify health plans that do not provide patient access 
through a standards-based API, but otherwise meet the requirements for 
QHP certification. We proposed in 45 CFR 156.221(h)(1) that if a plan 
applying for QHP certification that is to be offered through an FFE 
does not provide patient access to their data through a standards-based 
API, the issuer must include as part of its QHP application a narrative 
justification outlining the reasons why the plan cannot reasonably 
satisfy the requirements in proposed 45 CFR 156.221(a), (b), or (c), 
the impact of non-compliance upon enrollees, the current or proposed 
means of providing health information to enrollees, and proposed 
solutions and timeline to achieve API compliance. In 45 CFR 
156.221(h)(2), we proposed that the FFE may grant an exception to the 
requirement to provide enrollees access to data through standards-based 
API technology, if the FFE determines that making available such health 
plan is in the interest of qualified individuals and qualified 
employers in a particular FFE state. We anticipated that this exception 
would be provided in limited situations. For example, we would consider 
providing an exception for small issuers, issuers who are only in the 
individual or small group market, financially vulnerable issuers, or 
new entrants to the FFEs who demonstrate that deploying standards-based 
API technology consistent with the required interoperability standards 
would pose a significant barrier to the issuer's ability to provide 
coverage to consumers, and not certifying the issuer's QHP or QHPs 
would result in consumers having few or no plan options in certain 
areas. We sought comment on other circumstances in which the FFE should 
consider providing an exception.
    We summarize the public comments we received on QHP exemptions and 
provide our responses.
    Comment: Several commenters supported CMS' proposal to exempt SADPs 
from the requirements to provide a patient API. These commenters agreed 
with the justification offered that dental information may not be as 
useful to patients, as well as the resource burden concern for SADPs. A 
few commenters did not support the proposal to exempt SADPs from the 
patient API proposed requirements, suggesting it may help dentists and 
their patients make more

[[Page 25553]]

informed decisions and that dental information may help other health 
care providers for patient treatment.
    Response: We appreciate the commenters support, as well as the 
concerns raised. We believe the financial impact on SADP issuers may 
result in fewer SADPs available in the FFEs. We may consider the 
application of this policy to SADP issuers in future rulemaking. We are 
finalizing this policy as proposed and exempting SADPs from the Patient 
Access API at this time.
    Comment: A few commenters expressed support for the proposal to 
allow CMS to review a QHP issuer's justification for an exception to 
the Patient Access API proposal. One commenter recommended CMS require 
QHPs that are granted an exception to notify potential enrollees that 
they will not be compliant with the requirement to provide enrollees 
access to data through standards-based API technology. A few commenters 
did not support or expressed concern with CMS' proposal to grant QHPs 
an exception process, fearing an impact to patient care and uneven 
patient access to health data. One commenter did not want plans and 
entities to function solely as data consumers or aggregators. One 
commenter suggested that exceptions should be rare, limited, and for a 
defined duration.
    A few commenters recommended CMS establish or work with plans to 
make clear the evaluation criteria for reviewing exception requests to 
ensure parity. One commenter recommended CMS define a standard for 
expected alternative API implementation timeline. This commenter also 
recommended CMS establish a timeline for evaluating exception requests. 
One commenter requested CMS specify how justifications will be 
submitted as well as guidance in its annual Letter to Issuers in the 
FFEs to assist providers in understanding the requirements of the 
exception application process.
    Response: We appreciate the commenters' concerns and 
recommendations. Regarding concerns that this exception would impact 
care and access to health data, we believe it is more important to 
ensure patients have access to QHPs, and if an exception can provide 
consumers continued coverage, the exception is the preferable approach. 
We are evaluating the additional recommendations provided for future 
consideration. Further, in order to better clarify the applicability of 
the API-related requirements, we are revising 45 CFR 156.221(h) to 
expand the exceptions process to encompass all requirements in 
paragraphs (a) through (g), rather than (a) through (c) in the proposed 
rule. This will ensure that QHP issuers on the FFEs that are not able 
to meet any of the standards will be subject to the exceptions process. 
Again, we believe that ensuring patients have access to QHPs is 
paramount. We also note that additional guidance will be provided to 
QHP issuers in the future in order to specify how issuers will 
demonstrate compliance with these standards.
    Comment: Several commenters recommended that CMS expand the 
proposal to provide exemptions to the Patient Access API proposal to 
other types of plans for similar reasons including implementation 
burden and potential unintended consequences, such as driving plans out 
of the market. The types of payers that the commenters recommended be 
provided exemptions include MA, Medicaid (including MCOs, Medicare-
Medicaid Plans, Fully Integrated Dual-Eligible Special Needs Plan, 
Long-Term Services and Supports), CHIP, public health agencies, smaller 
QHPs and small plans, and new and current QHP issuers. A few commenters 
recommended CMS include ``local plans'' in the definition of ``small 
issuer.'' One commenter recommended that tribes also be exempt from 
this policy.
    Response: We appreciate the commenters' recommendations, and we 
appreciate the concerns that certain payers may have unique 
circumstances making new requirements potentially more challenging. We 
note that these policies only apply to Medicare Advantage 
organizations, Medicaid and CHIP FFS programs, Medicaid managed care 
plans, CHIP managed care entities, and QHP issuers on the FFEs. We are 
only finalizing one exemption, the exception noted below, not 
identified in the proposed rule, however. We do not believe the burden 
or potential unintended consequences outweigh the immense benefit to 
patients and the potential for improved health outcomes these policies 
can facilitate.
    As noted earlier in this final rule, we are modifying the scope of 
the applicability of the regulations to QHP issuers on an individual 
market FFE. In considering the application to issuers offering plans 
through the FF-SHOPs, we believe that, like the exception for issuers 
of SADPs discussed above, the financial burden to implement these 
policies may result in fewer issuers offering plans through the FF-
SHOPs and could result in small employers and consumers having fewer or 
no FF-SHOP plan options. Further, we believe that most FF-SHOP issuers 
likely would qualify for exclusion via the exceptions process we are 
finalizing. We have modified 45 CFR 156.221(h)(2) to remove the 
reference to ``qualified employers'' and paragraph (i) to include 
applicability to individual market FFEs.
j. Applicability and Timing
    At 42 CFR 422.119(h) and 45 CFR 156.221(i), we proposed specific 
provisions regarding applicability and timing for MA organizations and 
QHP issuers on the FFEs that would be subject to the proposal. We did 
not propose specific regulation text for 42 CFR 431.60 or 438.242 
because we intended to make the regulation text effective on the 
applicable date, as discussed below. We noted that we expected that 
state Medicaid and CHIP agencies would be aware of upcoming new 
regulations and planning for compliance with them when they are 
applicable, even if the new regulation is not yet codified in the CFR; 
we similarly expected that such agencies will ensure that their managed 
care plans/entities will be prepared for compliance. Unlike Medicaid 
state agencies and managed care plans and state CHIP agencies and 
managed care entities, MA organizations and QHP issuers on the FFEs 
generally are subject to rules regarding bid and application 
submissions to CMS in advance of the coverage period; for example, MA 
organizations must submit bids to CMS by the first Monday in June of 
the year before coverage starts in order to be awarded an MA contract. 
In an abundance of caution and to ensure that these requirements for MA 
organizations and QHP issuers on the FFEs are enforceable and reflected 
in the bids and applications these entities submit to us in advance of 
when the actual requirements must be met, we proposed to codify the 
actual compliance and applicability dates of these requirements. We 
solicited comment on this approach.
    For MA organizations, under 42 CFR 422.119(h), we proposed that the 
requirements would be applicable beginning January 1, 2020. Under the 
proposal, the requirements at 42 CFR 422.119 would be applicable for 
all MA organizations with contracts to offer any MA plan on that date 
and thereafter. We requested feedback about the proposed timing from 
the industry. In particular, we solicited information and requested 
comment from MA organizations about their current capability to 
implement an API consistent with the proposal and the costs associated 
with compliance by January 1, 2020, versus compliance by a future date.
    For Medicaid FFS at 42 CFR 431.60, CHIP agencies that operate FFS 
systems at 42 CFR 457.730, Medicaid managed

[[Page 25554]]

care plans at 42 CFR 438.242(b)(6) (finalized as Sec.  438.242(b)(5) in 
this rule; see section VI.), and CHIP managed care entities at 42 CFR 
457.1233(d)(2), we proposed that the API requirements would be 
applicable beginning July 1, 2020, regardless of when the managed care 
contract started. We noted that given the expected date of publication 
of the final rule, we believed July 1, 2020, would provide state 
Medicaid agencies and CHIP agencies that operate FFS systems, Medicaid 
managed care plans, and CHIP managed care entities sufficient time to 
implement. We solicited comment on the proposal and whether additional 
flexibility would be necessary to take into account the contract terms 
that states use for their Medicaid managed care plans.
    For CHIP, we noted that we are aware that some states do not 
provide any benefits on a FFS basis, and we did not intend for those 
states to implement an API outside their managed care plans. Therefore, 
we proposed in 42 CFR 457.700(c) that separate CHIP agencies that 
provide benefits exclusively through managed care entities may meet the 
requirements of 42 CFR 457.730 by requiring the managed care entities 
to meet the requirements of 42 CFR 457.1233(d)(2) beginning July 1, 
2020.
    For QHP issuers on the FFEs, we proposed in 45 CFR 156.221(i) that 
these requirements would be applicable for plan years beginning on or 
after January 1, 2020. We sought comment on the timing of these 
requirements, and on how long issuers, particularly smaller issuers, 
anticipate it would take to come into compliance with these 
requirements.
    We explained in the CMS Interoperability and Patient Access 
proposed rule our belief that these proposals would help to create a 
health care information ecosystem that allows and encourages the health 
care market to tailor products and services to compete for patients, 
thereby increasing quality, decreasing costs, and helping them live 
better, healthier lives. Additionally, under these proposals, 
physicians would be able to access information on their patient's 
current prescriptions and services by reviewing the information with 
the patient on the patient's personal device or by the patient sharing 
data with the provider's EHR system, which would save time during 
appointments and ultimately improve the quality of care delivered to 
beneficiaries. Most health care professionals and consumers have 
widespread access to the internet, providing many access points for 
viewing health care data over secure connections. These proposed 
requirements would significantly improve beneficiaries' experiences by 
providing a secure mechanism through which they can access their data 
in a standardized, computable format.
    We noted that these proposals were designed to empower patients by 
making sure that they have access to health information about 
themselves in a usable digital format and can make decisions about how, 
with whom, and for what uses they will share it. By making claims data 
readily available and portable to the enrollee, these initiatives 
supported efforts to move our health care system away from a FFS 
payment system that pays for volume and toward a payment system that 
pays for value and quality by reducing duplication of services, adding 
efficiency to patient visits to providers; and, facilitating 
identification of fraud, waste, and abuse. Data interoperability is 
critical to the success of new payment models and approaches that 
incentivize high quality, efficient care. All of the health care 
providers for a patient need to coordinate their care for a value-based 
system to work, and that requires information to be securely shareable 
in standardized, computable formats. Moreover, we noted that patients 
needed to understand and be actively involved in their care under a 
value-based framework. We committed to supporting requirements that 
focus on these goals, and we noted we believe that the specific 
proposals supported these efforts.
    We summarize the public comments we received on applicability and 
timing of the Patient Access API and provide our responses.
    Comment: A few commenters supported the proposed timeline for 
implementing APIs. One commenter believes that payers have sufficient 
time to prepare APIs and recommended that CMS maintain the proposed 
timeline. One commenter suggested that to address payer concerns CMS 
could reward plans, such as through higher HEDIS scores, who are able 
to meet the January 1, 2020 date.
    Many commenters expressed concern with the proposed implementation 
timelines. Many commenters believed that payers and developers will 
need more time to implement the requirements and encouraged CMS to 
delay the implementation date. A few commenters were concerned that 
without sufficient time and resources to implement security protocols, 
payers will be unable to meet the proposed requirements. Many 
commenters believed that additional time will allow health IT vendors 
and payers to develop, test, and implement the necessary systems. 
Several commenters expressed concern with the costs needed to implement 
the proposals under the proposed timelines.
    Several commenters recommended an implementation deadline no 
earlier than 2021, while several other commenters recommended a 
proposed implementation date of January 1, 2022. One commenter each 
suggested January 1, 2023 and January 1, 2024, while another 
recommended 12 months after the publication of the rule. Many 
commenters recommended a timeline of at least 18 to 24 months after 
publication of the final rule. Several commenters recommended aligning 
the CMS timelines with the ONC timelines, therefore recommending CMS 
implement policies in this final rule 2 years after the publication of 
this final rule. A few commenters recommended a 36-month timeline for 
all proposed policy implementation dates included in this rulemaking.
    A few commenters did not support proposing a timeline yet. The 
commenters noted that the standards and the infrastructure should be 
more mature before implementation dates are set. One commenter 
suggested that CMS and ONC convene a planning group to establish a more 
appropriate timeline.
    Several commenters encouraged CMS take a phased approach, which 
some explained as creating a ``glide path'' from ``proof of concept'' 
to more advanced use cases and a more expansive set of data. Commenters 
had a few different recommendations for which data elements could be 
included in which phase of the implementation in such a scenario. A few 
commenters suggested an approach where smaller plans meet fewer 
requirements initially and phase-in to full adoption. One commenter 
requested that CMS exempt small issuers from the requirements of the 
rule.
    A few commenters recommended delaying any disincentives and/or 
penalties until 2 years after implementation. One commenter expressed 
concern that the different implementation dates for different payers 
may create confusion, particularly for dual eligible beneficiaries.
    Response: We appreciate the commenters' concerns and 
recommendations. We understand that payers need time to be able to 
develop, test, and implement the APIs being finalized in this rule. We 
appreciate that it will take time to map and prepare historic data for 
sharing via the standards-based FHIR API. We want to be sure that 
payers have the time and guidance needed to fully and accurately

[[Page 25555]]

implement the policies being finalized in this rulemaking. We do not 
agree, however, that it is necessary to convene a planning group to 
develop a timeline for implementation. The public has had the 
opportunity to provide feedback on this issue as part of this 
rulemaking. As a result, we are finalizing the implementation date of 
the Patient Access API as January 1, 2021 for all payers impacted by 
this rulemaking, except for QHP issuers on the FFEs, for which the rule 
will be applicable beginning with plan years beginning on or after 
January 1, 2021. We strongly encourage payers to implement these 
policies as soon as they are capable, but the Patient Access API will 
not be required until January 1, 2021. For Medicaid managed care, we 
remind states that should they determine that obligations in this rule 
warrant a retroactive adjustment to capitation rates, those adjustments 
must be certified by an actuary in a revised rate certification and 
submitted to CMS as a contract amendment, pursuant to 42 CFR 438.7(c).
    We do appreciate the commenters' suggestion to evaluate a phased 
implementation approach. As a result, you will see in section IV. of 
this final rule how we are using the Provider Directory API proposal as 
a way for payers to show they are making progress toward API 
development and access.
k. Request for Information on Information Sharing Between Payers and 
Providers Through APIs
    We proposed the implementation of standards-based APIs for making 
accessible data that a third party could use to create applications for 
patients to access data in order to coordinate and better participate 
in their medical treatment. While in some instances, direct provider to 
health plan transmission of health information may be more appropriate 
than sharing data through a standards-based API, in other instances a 
patient may wish to send a provider a copy of their health information 
via another health care provider's API. In such cases, patients could 
direct the payer to transmit the health information to an application 
(for example, an application offered by a health care provider to 
obtain patient claims and encounter data, as well as lab test results 
(if applicable)) on a one-off and as-needed basis. To the extent a 
HIPAA covered entity offers patients access to their records via a 
standards-based application, another HIPAA covered entity may be able 
to obtain an individual's health information from the app for 
treatment, payment, or certain health care operations purposes, without 
need of an individual's authorization, consistent with the HIPAA Rules 
(see 45 CFR 164.506). Under other laws, providers may need to obtain 
specific individual consent to obtain health information related to 
care provided by a behavioral health provider, treatment received at a 
substance use disorder treatment facility, certain 42 CFR part 2-
covered diagnoses or other claims-related information, or labs that 
suggest a part 2 diagnosis. We explained in the CMS Interoperability 
and Patient Access proposed rule how we did not intend to expand any 
scope of authority to access patient data nor to contravene existing 
requirements related to disclosure of PHI under the HIPAA Rules and 
other legal standards, but instead specified a new and additional 
mechanism by which to share health information as directed by the 
individual, through the use of API technology in compliance with all 
existing federal, state, local, and tribal privacy and security laws.
    We explained how, in the future, we anticipate payers and providers 
may seek to coordinate care and share information in such a way as to 
request data on providers' or a payer's patient/insured overlapping 
population(s) in one transaction. We sought comment for possible 
consideration in future rulemaking on the feasibility of providers 
being able to request a download on a shared patient population using a 
standards-based API. We thank commenters for their insights and are 
reviewing the comments received for inclusion in potential future 
rulemaking.
    In addition to the comments we received about the specific sections 
of this Patient Access API proposal, we also received a number of 
comments that were specific to the types of payers impacted by the 
proposal, generally. We summarize these public comments by payer type 
and provide our responses.
    We received these public comments related to Medicare Advantage.
    Comment: One commenter suggested CMS require that MA organizations 
make patient data maintained in connection with the organizations' 
various individual and small group market plans available for access 
and exchange through the Patient Access API.
    Response: We appreciate the commenter's suggestion. However, in 
light of the limits on CMS's authority over MA organizations, 
commercial insurance, and group health plans, we are not adopting 
requirements to apply as broadly as the commenter suggested. We note 
that QHP issuers on the individual market FFEs are required under this 
final rule to implement the Patient Access API, and we encourage other 
individual markets, as well as small group market plans and group 
health plans to do so, as well.
    Comment: One commenter recommended CMS specify the expectations of 
MA organizations regarding supplemental benefits in relation to the 
Patient Access API. One commenter recommended CMS evaluate whether the 
standards proposed for this API are appropriate for the dental care 
space.
    Response: We appreciate the commenter's request for additional 
information. We note that MA claims data, encounter data, and clinical 
data related to supplemental benefits, including dental services, are 
subject to the API requirement, even if issuers only offering SADPs on 
FFEs are not subject to the requirement.
    Comment: One commenter requested additional information on whether 
Medicare Advantage D-SNPs would be required to provide patients an API.
    Response: We appreciate the commenter's request for additional 
information. We note D-SNPs are MA plans offered by MA organizations 
and therefore subject to the API requirement adopted at 42 CFR 422.119.
    Comment: One commenter requested additional information of whether 
data shared via an API would be subject to member communication rules, 
such as Medicare Communications and Marketing Guidelines.
    Response: We appreciate the commenter's request for additional 
information. Whether or not data shared via the Patient Access API 
being finalized at 42 CFR 422.119(b) falls under the purview of CMS's 
communication and marketing rules would be dependent on factors such as 
the relationship of the developer and the MA plan(s), the content 
accompanying the API data, and the intended outcome of the application 
using the API data. MA plans must continue to follow the provisions of 
42 CFR part 422 (such as but not limited to 42 CFR 422.118(d), 422.2260 
through 422.2268), including in circumstances when their communications 
and marketing materials include data that is retrieved through an API. 
For example, if a field marketing organization (FMO) uses API data to 
create a software application that compares the provider networks for 
the plans the FMO is contracted to sell, the application would fall 
under the MA marketing and communications regulations and CMS's 
oversight. Conversely, if a developer uses API data to create an 
independent application that provides an alternative

[[Page 25556]]

means of scheduling provider appointments, the application would fall 
outside of CMS's purview.
    We received these public comments related to Medicaid and CHIP.
    Comment: Several commenters requested additional information on 
which Medicaid programs would be required to implement and maintain a 
standards-based API. One commenter wanted additional information as to 
whether all state's Medicaid Management Information Systems (MMIS) 
would be required to develop APIs. This commenter stated that while it 
seemed clear that the rule does not require health plans to use Health 
IT modules to make administrative data available, the role of a payer's 
claims adjudication system (including MMIS) is unclear.
    Response: We appreciate the commenters' request for information. In 
proposed 42 CFR 431.60 and 457.730, we specified that states would have 
to implement and maintain an API for FFS Medicaid programs and CHIP; we 
also proposed in 42 CFR 438.242(b)(6) (finalized as 42 CFR 
438.242(b)(5) in this rule; see section VI.) and 457.1233(d) that 
states would have to require each MCO, PIHP, and PAHP to comply with 42 
CFR 431.60 (under Medicaid managed care contracts) and 457.730 (under 
CHIP managed care contracts) as if such requirements applied directly 
to them. We are finalizing these policies as proposed. Sections 431.60 
and 457.730 do not require a specific system to be used for the 
implementation and maintenance of the API, thus we defer to each state 
and Medicaid managed care plan to determine which of their systems 
would be the most appropriate.
    Comment: One commenter requested that CMS clarify if an arrangement 
in which a state provided beneficiaries access to their FFS data by 
delegating the API function to a managed care plan would be sufficient 
to satisfy the rule, or if each entity in the chain is required to 
implement their own systems, portals, and/or API interfaces. This 
commenter questioned if CMS envisioned the creation of a national 
network to exchange Medicare/Medicaid records that would satisfy these 
requirements in a centralized fashion.
    Response: We appreciate the commenter's request for information. We 
are, however, somewhat unclear what the commenter meant by ``delegating 
the API function to a managed care plan.'' We believe the commenter may 
be questioning if a state could utilize a managed care plan to 
implement the API required for the state's FFS beneficiaries in lieu of 
the state implementing the API required in 42 CFR 431.60. If so, the 
proposed rule did not anticipate nor prohibit that type of an 
arrangement. As such, this final rule could permit such an arrangement, 
but we remind a state contemplating using such an arrangement that it 
must meet the all of the requirements in this final rule, including the 
timelines and scope specified for data accessibility in Sec.  
431.60(b). There is no plan for a national network to exchange 
Medicare/Medicaid records in lieu of the APIs being finalized in this 
rule at this time.
    Comment: One commenter suggested that CMS establish a stakeholder 
workgroup to identify best practices in data-sharing with Medicaid 
beneficiaries.
    Response: We appreciate this suggestion and encourage states and 
Medicaid managed care plans to work with their stakeholders to identify 
best practices for data-sharing with Medicaid beneficiaries in their 
states.
    Comment: A commenter expressed concern that reimbursing states for 
modification of their IT systems at an enhanced match rate while 
reimbursing managed care plans for their system modifications at the 
state's standard match rate creates an uneven playing field for 
Medicaid managed care plans and a disparity of funding. This commenter 
noted that in states that make extensive use of managed care, the bulk 
of system modifications needed to carry out and maintain the proposed 
interoperability capabilities for Medicaid enrollees will be borne by 
Medicaid managed care plans and requested that CMS revise its proposal 
to reflect that all costs attributable to design, development, 
installation, enhancement, or ongoing operation of both state and 
Medicaid managed care plan systems will receive the appropriate 
enhanced federal match. Finally, this commenter requested that CMS take 
a more rigorous approach and update its methodology for review of state 
MCO capitation rates to ensure that proposed rates include reasonable 
allowances for costs of IT systems work performed by the state's 
Medicaid managed care plans in furtherance of the proposals in this 
regulation.
    Response: We appreciate the commenter's concern. However, we do not 
agree that the difference in the federal match rate creates an uneven 
playing field. Capitation rates must be actuarially sound independent 
of the federal matching rate that applies to the payment of those 
rates. The provision of enhanced federal match rate is addressed in 
section 1903(a)(3)(A) of the Act and provides a 90 percent match rate 
for ``. . . the sums expended during such quarter as are attributable 
to the design, development, or installation of such mechanized claims 
processing and information retrieval systems as the Secretary 
determines are likely to provide more efficient, economical, and 
effective administration of the plan . . .'' It does not specifically 
provide an enhanced match rate for the portion of a capitation rate 
that may be included for information technology expenditures, and we do 
not have the authority to extend the enhanced match rate beyond the 
conditions specified in statute. We already have a very rigorous 
capitation rate review process and will review any changes noted by the 
states in those rates, including any specifically noted for IT system 
enhancements specific to the requirements finalized in this rule.
    Comment: One commenter requested that the new requirement to 
implement and maintain an API must be uniform across the system and 
non-negotiable to Medicaid managed care plans, state government, and 
providers. One commenter noted that CMS should address situations where 
states may choose to adopt additional or conflicting data sharing 
requirements in Medicaid or CHIP managed care contracts. This commenter 
further stated that it is critical that covered health plans be subject 
to uniform standards for data accessed through an API and that CMS 
should work with state Medicaid and CHIP programs to ensure that any 
state mandated requirements for data accessed through an API are 
harmonized with the new federal standards. This commenter suggested 
that submission of the encounters in a timely manner by all involved 
with the new rule must be a non-negotiable condition for the receipt of 
Medicare or Medicaid reimbursement. In addition, the commenter noted 
that enforcement cannot be left to plans based on variable contract 
terms but must be provided by federal agencies.
    Response: We agree with the commenter that implementation of 
standards-based APIs should be consistent across states and Medicaid 
and CHIP managed care plans and have codified the requirements for APIs 
in 42 CFR 431.60(b), 457.730(b), 438.242(b)(6) (finalized as 
438.242(b)(5) in this rule; see section VI.), and 457.1233(d) to ensure 
an appropriate level of uniformity and consistency while still 
providing states with an adequate level of flexibility to go beyond the 
minimum standards included in this final rule when they believe doing 
so benefits their beneficiaries. While we do not have a specific 
provisions that

[[Page 25557]]

conditions payment on the timely receipt of encounters, states and 
managed care plans may find that a useful provision to include in their 
contracts. States must have a monitoring system in effect for their 
Medicaid managed care programs under Sec.  438.66(b)(6), which also 
specifies ``information systems, including encounter data reporting'' 
as a required element. Similarly, we have certain program oversight 
responsibilities, such as the review of certain Medicaid and CHIP 
managed care contracts and all capitation rates, and will incorporate 
oversight of requirements in this final rule to the extent appropriate.
    Comment: One commenter noted that CMS encourages the Medicaid and 
CHIP FFS programs to use the API as a means to exchange PHI with 
providers for treatment purposes, suggesting the data would be shared 
in advance of a patient's visit. But CMS also states that this proposal 
can empower the patient to decide how their health information is going 
to be used. This commenter requested additional information of the role 
CMS intends for the patient and the provider to have in the use of 
APIs.
    Response: While we believe that a beneficiary's use of an API to 
obtain their health care data will play an important role in their 
health care, as proposed and finalized, this rule does not set 
standards for health care provider use of apps to obtain information 
from payers. As proposed and finalized in 42 CFR 431.60(a) and 
457.730(a), the API permits third-party applications to retrieve a 
patient's data at the patient's request. A beneficiary may make the 
decision to obtain their health care data through such an app and share 
it with a provider in advance of a visit or otherwise.
    Comment: One commenter requested clarity on whether the proposed 
rule requires all states' MMIS [Medicaid Management Information System] 
to make information available to patients within one (1) business day 
of receipt or adjudication of administrative data (adjudicated claims, 
encounters, provider remittance, etc.). This commenter expressed 
concern that these data could appear to conflict with data obtained by 
a patient directly from a managed care plan, causing confusion and 
increasing administrative overhead.
    Response: We appreciate the commenter's request for additional 
information. Medicaid beneficiaries should not be receiving the 
information from both the state and managed care plan for the same 
service. If the beneficiary is receiving a service under the state's 
Medicaid FFS program, the requirements in Sec.  431.60 apply; that is, 
the state is responsible for providing the specified data elements in 
Sec.  431.60(b) through the API. If the beneficiary is enrolled in a 
managed care plan (receiving the service under the managed care plan's 
contract), the requirements in Sec.  438.242(b)(5) (proposed as Sec.  
438.242(b)(6); see section VI.) apply; that is, the managed care plan 
is responsible for providing the specified data elements in Sec.  
431.60(b) through the API. The beneficiary should not receive data that 
is in conflict with other data that is made available through the API. 
The same is true for CHIP. If the beneficiary is in CHIP FFS, the 
requirements in Sec.  457.730 apply; that is, the state is responsible 
for providing the specified data elements in Sec.  457.730(b) through 
an API. If the beneficiary is enrolled in a managed care plan, the 
requirements in Sec.  457.1233(d) apply; that is, the managed care plan 
is responsible for providing the specified data elements in Sec.  
457.730(b) through the API.
    Comment: One commenter expressed concerns regarding the ongoing 
burden for state Medicaid and CHIP agencies to monitor the API, privacy 
and security features, and potential security risks posed by the 
numerous applications that may connect to the API. This commenter 
recommended that states be required to monitor the compliance of each 
of their managed care plans regarding the API requirements.
    Response: We understand the commenter's concerns about burden 
related to the API, as well as the need for states to monitor the API 
for privacy and security. These requirements are specified at 42 CFR 
431.60(c)(1) and (2) and 457.730(c)(1) and (2). While we understand 
that there is some burden for states and managed care plans related to 
the development and implementation of the API, we continue to believe 
that the benefits and potential for improved health outcomes outweigh 
the burden associated with these requirements. We also confirm for 
commenters that states are required to monitor compliance for their 
contracted managed care plans in regard to the API requirements under 
42 CFR 438.242(b)(5) (proposed as 42 CFR 438.242(b)(6); see section 
VI.) and 457.1233(d). Since these requirements apply to managed care 
plans, states are required to include the requirements under their 
managed care contracts and must ensure that plans comply with the 
standards specified in 42 CFR 431.60 and 457.730 as if those 
requirements applied directly to the managed care plan.
    Comment: Several commenters stated that the Patient Access API 
proposal places a significant burden on Medicaid and CHIP beneficiaries 
to monitor the privacy and security of their own health information 
while it is being accessed by non-HIPAA covered entities. One commenter 
recommended that CMS consider how educational efforts could be uniquely 
tailored to specific populations, such as Medicaid beneficiaries, 
particularly given the need for special considerations when attempting 
to engage with vulnerable populations. This commenter recommended that 
CMS amend or revise the current language in its proposed rule to 
explicitly require that API vendors be responsible for the education of 
consumers. Another commenter noted that many Medicaid and CHIP 
beneficiaries are children and that app developers, states, and managed 
care plans will also need to develop resources for minor access and 
control over health information and educate members accordingly.
    Response: We appreciate the commenters' concerns, and we 
acknowledge that some Medicaid beneficiaries may find negotiating the 
privacy and security app landscape burdensome. Any patient, including 
one who is not comfortable with technology, may choose not to use this 
method of data exchange. However, we would like all beneficiaries to be 
able to benefit from these apps. One way we are looking to mitigate 
this burden is through education. We believe that it is important for 
beneficiaries to have the educational resources to be able to best 
evaluate their third-party options. States and managed care plans must 
comply with the requirements 42 CFR 431.60(f) and 457.730(f) that 
require states and managed care plans to develop and provide on a 
public website beneficiary resources regarding privacy and security, 
including information on how beneficiaries can protect the privacy and 
security of their health information in non-technical, simple and easy-
to-understand language. We note in section III.C.2.h. of this final 
rule, that CMS will provide suggested content for educational material 
payers can use to meet this requirement. States, Medicaid managed care 
plans, and CHIP managed care entities have vast experience with 
techniques for creating effective communications for their 
beneficiaries and we encourage states and managed care plans to tailor 
these resources for their Medicaid and CHIP populations. We also agree 
that states and managed care plans will need to develop or refine 
resources to address patient access for minor populations and for 
populations based on health literacy levels. We do

[[Page 25558]]

note that we do not have the authority to regulate vendors. While we 
agree that API vendors should have a role in educating consumers, 
states and managed care plans are the entities responsible for 
developing and implementing the API; therefore, we believe it is more 
appropriate for states and managed care plans to develop and provide 
the educational resources for beneficiaries.
    Comment: A few commenters requested that CMS modify the rule to 
exempt Medicaid managed care plans. Commenters noted that Medicaid 
managed care plans are already operating with razor thin margins and 
the proposed rule will substantially increase the costs for Medicaid 
managed care plans. Further, commenters noted that due to the 
substantial increase in costs, plans may not be able to meet the MLR 
requirements in 42 CFR 438.8. Another commenter suggested that CMS 
explicitly exclude from the requirements of the rule long[hyphen]term 
services and supports (LTSS) plans. Some commenters also recommended 
that CMS exclude dental plans from the requirements in the proposed 
rule.
    Response: We appreciate the commenters' concerns, however we are 
not exempting Medicaid or CHIP managed care plans, including LTSS or 
dental plans, from the requirements in this rule, as such an approach 
would not be consistent with our goal of ensuring that all 
beneficiaries across the health care market, including Medicaid FFS and 
managed care, have access to and can exchange specified health care 
data. We are finalizing the Patient Access API requirements for state 
Medicaid and CHIP agencies and managed care plans, including LTSS and 
dental plans. States and managed care plans must make adjudicated 
claims and encounter data available through the API for all Medicaid-
covered services, including LTSS and dental. This requirement extends 
to all Medicaid-covered services for which a claim, or encounter claim, 
is generated and adjudicated. Regarding costs for managed care plans--
since the Patient Access API requirements must be contractual 
obligations under the managed care contract--the state must include 
these costs in the development of a plan's capitation rates.
    Final Action: After consideration of the comments received, and for 
the reasons outlined in our response to these comments and in the CMS 
Interoperability and Patient Access proposed rule, we are finalizing 
with modifications our proposal to require MA organizations, Medicaid 
and CHIP FFS programs, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs to implement and maintain a 
standards-based Patient Access API that meets the technical standards 
as finalized by HHS in the ONC 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register) at 45 CFR 
170.215, content and vocabulary standards adopted at 45 CFR part 162 
and 42 CFR 423.160, and finalized by HHS at 45 CFR 170.213 (USCDI 
version 1), unless alternate standards are required by other applicable 
law; includes the data elements specified in this final rule, and 
permits third-party applications to retrieve, with the approval and at 
the direction of the enrollee, data specified at 42 CFR 422.119, 
431.60, 457.730, and 45 CFR 156.221. Specifically, we are finalizing 
that the Patient Access API must, at a minimum, make available 
adjudicated claims; encounters with capitated providers; provider 
remittances; enrollee cost-sharing; and clinical data, including 
laboratory results (where maintained by the impacted payer). Data must 
be made available no later than one (1) business day after a claim is 
adjudicated or encounter data are received by the impacted payer. We 
are not finalizing a requirement for the Patient Access API to make 
provider directory and pharmacy directory information available. 
Instead, to limit burden, we are only requiring provider and, in the 
case of MA-PD plans, pharmacy directory information be included in the 
Provider Directory API discussed in section IV. of this final rule.
    We are finalizing the proposed documentation requirements noting 
business and technical documentation necessary to interact with the API 
must be made freely and publicly accessible. We note that the APIs need 
to comply with all existing federal and state privacy and security 
laws. We are finalizing, consistent with the HIPAA Rules that a payer 
may deny access to the Patient Access API if the payer reasonably 
determines that allowing a specific third-party application to connect 
or remain connected to the API would present an unacceptable level of 
risk to the security of PHI on the payer's systems based on objective 
and verifiable criteria. We are also finalizing that payers need to 
make available to enrollees resources explaining factors to consider in 
selecting an app for their health information, practical strategies to 
safeguard their privacy and security, and how to submit complaints to 
OCR or FTC. We do note that we are providing payers with suggested 
content they can use and tailor to meet this requirement, available 
here: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. We also note that impacted payers are allowed 
to request that third-party apps attest to having certain information 
included in their privacy policy, and inform patients about this 
attestation, to help ensure patients are aware of the privacy risks 
associated with their choices.
    We are finalizing this policy with the following technical 
corrections and additional information. At 42 CFR 422.119(a) and 
(b)(1); 42 CFR 431.60(a) and (b); 42 CFR 457.730(a) and (b); and, 45 
CFR 156.221(a) and (b) we specify these policies apply to current 
patients and their personal representatives. At 42 CFR 
422.119(b)(1)(i), (1)(ii), and (2)(i); 42 CFR 431.60(b)(1) and (2); 42 
CFR 457.730(b)(1) and (2); and, 45 CFR 156.221(b)(1)(i) and (ii) we are 
removing the word ``standardized'' to avoid confusion as the standards 
are specified elsewhere. We are finalizing the regulation text at 42 
CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), with the verb 
``maintains'' in place of the verb ``manages'' in order to more closely 
align with the relevant HIPAA Privacy Rule requirement. We are 
finalizing a technical correction at 42 CFR 431.60(b)(2) and 42 CFR 
457.730(b)(2) to replace ``within one (1) business day'' with ``no 
later than 1 business day after'' to be consistent across payers. We 
have added text to specifically indicate that the technical 
requirements at 42 CFR 422.119(c), 431.60(c), and 457.730(c), and 45 
CFR 156.221(c) apply to the API under paragraph (a) of the respective 
sections. We are finalizing at 42 CFR 422.119(c)(2), 431.60(c)(2), 
457.730(c)(2), and 45 CFR 156.221(c)(2), to include additional text to 
explicitly require, as described in the CMS Interoperability and 
Patient Access proposed rule (84 FR 7635) the requirement to also 
update (as appropriate) the API to ensure it functions properly and 
includes assessments to verify an individual enrollee or their personal 
representative can only access claims and encounter data or other PHI 
that belongs to that enrollee. In addition, we are removing the word 
``minimally'' from this regulation text in order to ensure it is clear 
that privacy and security features must be reasonable and appropriate, 
consistent with the requirements of HIPAA Privacy and Security Rules, 
42 CFR parts 2 and 3, and other applicable law protecting privacy and 
security of individually identifiable health information. We are making 
a technical

[[Page 25559]]

change for readability only at 42 CFR 422.119(c)(3) and (4)(ii)(C), 
431.60(c)(3) and (4)(ii)(C), 438.242(b)(5), 457.730(c)(3) and 
(4)(ii)(C), 457.1233(d)(1), and 45 CFR 156.221(c)(3) and (4)(ii)(C). In 
addition, we have refined the language at 42 CFR 422.119(g), 431.60(f), 
and 457.730(f), and 45 CFR 156.221(g) to state the payer must make 
education materials available ``in an easily accessible location on its 
public website,'' and at 42 CFR 422.119(g)(1), 431.60(f)(1), and 
457.730(f)(1), and 45 CFR 156.221(g)(1) to include a reference to 
``secondary uses of data.''
    At 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 CFR 156.221(d), 
we are finalizing additional text to specify that ``publicly 
accessible'' means that any person using commonly available technology 
to browse the internet could access the information without any 
preconditions or additional steps, such as a fee for access to the 
documentation; a requirement to receive a copy of the material via 
email; a requirement to register or create an account to receive the 
documentation; or a requirement to read promotional material or agree 
to receive future communications from the organization making the 
documentation available.
    In the CMS Interoperability and Patient Access proposed rule, the 
criteria and process for assessing unacceptable risk to a payers system 
was explained as part of the payer's responsibilities under the HIPAA 
Security Rule (84 FR 7635). At 42 CFR 422.119(e)(1), 431.60(e)(1), 
438.242(b)(5), 457.730(e)(1), and 457.1233(d), as well as 45 CFR 
156.221(e)(1) we are finalizing additional text to note that payers 
should determine risk consistent with its security risk analysis under 
45 CFR part 164 subpart C to indicate the specific section of the HIPAA 
Security Rule implicated here. We are modifying 45 CFR 156.221(h)(2) to 
remove the reference to ``qualified employers'' and 45 CFR 156.221(i) 
to include applicability to ``individual market'' FFEs to exclude 
issuers offering plans through the FF-SHOPs. Finally, we are finalizing 
for MA organizations at 42 CFR 422.119(h), Medicaid FFS programs at 42 
CFR 431.60(g), Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii), 
CHIP FFS programs at 42 CFR 457.730(g), CHIP managed care entities at 
42 CFR 457.1233(d), that beginning January 1, 2021, and for QHP issuers 
on the FFEs at 45 CFR 156.221(i) beginning with plan years beginning on 
or after January 1, 2021, these payers must make available through the 
Patient Access API data they maintain with a date of service on or 
after January 1, 2016, consistent with the payer-to-payer data exchange 
requirement discussed in section V. of this final rule.

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

A. Interoperability Background and Use Cases

    In section III. of the CMS Interoperability and Patient Access 
proposed rule (84 FR 7626 through 7639), we focused on patient access 
to their own data through a standardized, transparent API--the Patient 
Access API. As part of this proposal, we discussed and sought comment 
on requiring payers at 42 CFR 422.119(b)(1)(iii) and (b)(2)(ii) for MA 
organizations, 42 CFR 431.60(b)(3) for Medicaid FFS programs, 42 CFR 
438.242(b)(6)(ii) for Medicaid managed care plans, 42 CFR 457.730(b)(3) 
for CHIP FFS programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed 
care entities to provide their provider directory information through 
that same Patient Access API. In addition, the proposed rule sought 
comment on making the provider directory information available through 
a public-facing standards-based API. As we discussed in the CMS 
Interoperability and Patient Access proposed rule (84 FR 7639), making 
provider directory information available through a public-facing API 
raised different issues than API access proposals related to patient 
data. Based on our consideration of public comments summarized and 
responded to below, and in an effort to avoid duplicative effort and 
additional burden resulting from having the provider directory 
information included in both the Patient Access API and the Provider 
Directory API, we are finalizing the requirement for a public-facing 
Provider Directory API at 42 CFR 422.120 for MA organizations, 42 CFR 
431.70 for Medicaid FFS programs, 42 CFR 438.242(b)(6) for Medicaid 
managed care plans, 42 CFR 457.760 for CHIP FFS programs, and 42 CFR 
457.1233(d)(3) for CHIP managed care entities, but we will not finalize 
our proposal to also provide access to this provider directory 
information through the Patient Access API at 422.119, 42 CFR 431.60, 
42 CFR 438.242(b)(6), 42 CFR 457.730, and 42 CFR 457.1233(d)(2), 
respectively.
    Provider directories make key information about health care 
professionals and organizations available to help consumers identify a 
provider when they enroll in an insurance plan or as new health needs 
arise. For example, such information might include hours of operation, 
languages spoken, specialty/services, and availability for new 
patients. Provider directories also function as a resource used by the 
provider community to discover contact information of other providers 
to facilitate referrals, transitions of care, and care coordination for 
enrollees.
    As discussed in the CMS Interoperability and Patient Access 
proposed rule, the current applicable regulations for MA plans (42 CFR 
422.111) and Medicaid and CHIP managed care plans (42 CFR 
438.10(e)(2)(vi) and (h) and 457.1207, respectively) already require 
that provider directories be made available to enrollees and potential 
enrollees in hard copy and on the plan's website. Section 1902(a)(83) 
of the Act requires state Medicaid agencies to publish a directory of 
certain physicians on the public website of the State agency. A 
regulation for QHP issuers (45 CFR 156.230(b)) requires public access 
to the QHP's provider directory in addition to distribution and access 
for enrollees. In addition to mandating that this information be 
accessible, the current regulations also address the content of such 
directories and the format and manner in which MA plans, Medicaid 
managed care plans, CHIP managed care entities, and QHP issuers on the 
FFEs must make the information available.
    Making this required provider directory information available to 
enrollees and prospective enrollees through an API could support 
development of third-party software applications, or apps, (whether 
standalone or integrated with providers' EHR technology) that would 
pull in current information about available providers to meet 
enrollees' current needs. Broad availability of provider directory data 
through interoperable API technology would also allow for innovation in 
applications or other services that help enrollees and prospective 
enrollees to more easily compare provider networks while they are 
considering their options for changing health plans. Finally, we noted 
in our proposal that a consistent, FHIR-based API-driven approach to 
making provider directory data accessible could reduce provider burden 
by enabling payers to more widely share basic information about the 
providers in their networks, such as provider type, specialty, contact 
information, and whether or not they are accepting new patients.

[[Page 25560]]

B. Broad API Access to Provider Directory Data

    In sections III.C. and IV. of the CMS Interoperability and Patient 
Access proposed rule (84 FR 7633, 7639 through 7642), we proposed to 
require at 42 CFR 422.119(b)(1)(iii) for MA organizations, 42 CFR 
431.60(b)(3) for Medicaid FFS programs, 42 CFR 438.242(b)(6)(ii) for 
Medicaid managed care plans, 42 CFR 457.730(b)(3) for CHIP FFS 
programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed care entities 
that payers subject to the proposed rule make standardized information 
about their provider networks available through API technology, so that 
the public, including third-party app developers and patients, could 
access and use that information, including republishing the information 
or information derived from that information in a user-friendly way. As 
discussed in the preamble of the CMS Interoperability and Patient 
Access proposed rule, we sought comment on making provider directory 
information more generally available (84 FR 7639 through 7642). We 
discussed requiring that the API technology conform to the API 
standards proposed by ONC for HHS adoption at 45 CFR 170.215 (84 FR 
7589). Currently, because QHP issuers on the FFEs are already required 
to make provider directory information available in a specified, 
machine-readable format,\42\ we did not propose that QHP issuers would 
have to make provider directory information available through an API. 
However, we requested information regarding whether this same 
requirement should apply to QHP issuers, or if such a requirement would 
be overly burdensome for them. We thank commenters for their insights 
on this request for information and are reviewing the comments received 
for inclusion in potential future rulemaking.
---------------------------------------------------------------------------

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

    We noted in the preamble of the proposed rule that, since this 
provider directory information is already available and accessible to 
enrollees without cost to them under existing law, this information 
should be as accessible through the API as it is required to be when 
posted on the organization's websites. Therefore, we proposed that the 
technical standards proposed (now finalized) by HHS in the ONC 21st 
Century Cures Act final rule (published elsewhere in this issue of the 
Federal Register) at 45 CFR 170.215 (specifically at paragraphs (a)(3) 
and (b)) that are specific to authenticating users and confirming 
individuals' authorization or request to disclose their personal 
information to a specific application through an API, namely the SMART 
IG (using the OAuth 2.0 standard) and OpenID Connect Core 1.0, should 
not apply to our proposed public access to provider directory 
information through APIs (84 FR 7639). We noted that while we were 
aware the organization will nevertheless need to take appropriate steps 
to mitigate the potential security risks of allowing any application to 
connect to the API through which it offers provider directory access, 
we emphasized that these steps should be appropriate to the level of 
risk associated with the specific use case of accessing otherwise 
public information through API technology. We also noted that those 
wishing to access these data should not be unduly burdened by security 
protocols that are not necessary to provide the appropriate degree of 
protection for the organization's systems and data.
    As referenced in sections II. and III. of the CMS Interoperability 
and Patient Access proposed rule (84 FR 7618 through 7639), we intended 
to develop additional guidance, incorporating feedback from industry 
that provides implementation best practices relevant to FHIR-conformant 
standards-based APIs to help organizations subject to the requirements 
proposed in this rulemaking. To that end, we solicited comment on what 
specific resources would be most helpful to organizations implementing 
APIs under requirements proposed in the proposed rule.
    We summarize all public comments we received on making provider 
directory information available through an API--in terms of requiring a 
dedicated, publicly accessible Provider Directory API and more 
generally sharing provider directory information via an API, including 
as proposed under the Patient Access API discussed in section III. of 
this final rule and provide our responses.
    Comment: Many commenters supported a requirement for MA 
organizations, state Medicaid and CHIP FFS programs, Medicaid managed 
care plans, and CHIP managed care entities to make standardized 
information about their provider networks available through API 
technology to current enrollees, prospective enrollees, and possibly 
the general public. Commenters stated that they believe accurate 
provider directory data will improve transparency and accessibility of 
information regarding a provider's network status, which will help with 
efforts to address surprise billing and other coverage issues related 
to whether providers are in or out-of-network.
    Response: We thank commenters for their support. Appreciating that 
provider information is already publicly available, and unlike the 
other information included in the Patient Access API discussed in 
section III. of this final rule, is of a less sensitive nature, to 
avoid potential confusion and reduce burden resulting from having the 
provider directory information included in both the Patient Access API 
and the Provider Directory API, we are only requiring that one API--the 
Provider Directory API--provide access to provider directory 
information. As a result, we are finalizing additional regulation text 
to require the Provider Directory API at 42 CFR 422.120 for MA 
organizations; at 42 CFR 431.70 for Medicaid state agencies; at 42 CFR 
438.242(b)(6) for managed care plans; at 42 CFR 457.760 for CHIP state 
agencies; and at 42 CFR 457.1233(d)(3) for CHIP managed care entities. 
This Provider Directory API must include the same information about the 
provider directory as originally proposed for the Patient Access API. 
Specifically, the Provider Directory API must include provider 
directory data on a payer's network of contracted providers, including 
names, addresses, phone numbers, and specialties, updated no later than 
30 calendar days after a payer receives provider directory information 
or updates to provider directory information. We are finalizing the 
applicable regulation text with the phrase ``complete and accurate'' to 
emphasize our intent that the directory data meet this standard. For MA 
organizations that offer MA-PD plans, the Provider Directory API must 
also make available pharmacy directory data, we are specifying that the 
plans must make available, at a minimum, pharmacy name, address, phone 
number, number of pharmacies in the network, and mix (specifically the 
type of pharmacy, such as ``retail pharmacy''). As with the provider 
directory information, we are finalizing that pharmacy directory 
information must be updated no later than 30 calendar days after the MA 
organization that offers the MA-PD plan receives pharmacy directory 
information or updates to pharmacy directory information.
    Comment: Some commenters disagreed with the proposal. They stated 
that payers are already required to make this information available and 
this proposal could result in unnecessary duplication of effort and 
additional costs. One commenter suggested CMS provide an exemption for 
payers that are

[[Page 25561]]

already providing this information in a manner that aligns with the 
requirements in the proposed rule.
    Response: We appreciate the commenters' concern about potentially 
duplicative effort. While we understand that different payers are 
already required to make this information available in a machine 
readable format or on a public website according to the different rules 
associated with each program, we believe that making this information 
available through a standardized API will bring additional benefits to 
enrollees and prospective enrollees by making it easier for developers 
to incorporate this information into consumer-facing applications. We 
note that we did not propose to extend the requirement regarding 
provider directory information to QHP issuers on the FFEs, as these 
issuers are already required to make provider directory information 
available according to a specific standard for the electronic transfer 
of this information, as discussed in the CMS Interoperability and 
Patient Access proposed rule (84 FR 7633).
    Comment: Many commenters raised concerns about the accuracy of 
provider directory information that would be available through the API, 
and how these inaccuracies can have a negative impact on consumers. One 
commenter stated that there is a high prevalence of inaccurate provider 
directories issued by MA organizations, in particular, and for other 
public and private payers, generally, and that this can bring into 
question the adequacy and validity of a network. Another noted that 
inaccurate provider directories have also resulted in patients 
receiving surprise bills as a result of seeing an out-of-network 
physician. Commenters expressed concern that making provider directory 
information more accessible through an API could exacerbate the impact 
of inaccuracies resulting in conflicting and confusing information for 
consumers, for instance, where an enrollee participates in two plans 
and receives different information about the same provider from each.
    Commenters discussed a variety of steps that CMS should take in 
concert with the proposal to ensure that provider directory information 
made available through the API is tested to ensure it is current, 
correct, and accurate. One commenter suggested CMS require payers to 
provide API vendors with accurate provider directory information.
    Response: We appreciate commenters' concerns and thank the 
commenters for their suggestions. We have taken a number of steps to 
improve the accuracy of provider directory information for plans 
subject to direct regulation by CMS, such as implementing a process to 
audit directory information with MA organizations to identify 
deficiencies in an effort to increase data accuracy (for more 
information see https://www.cms.gov/Medicare/Health-Plans/ManagedCareMarketing/Downloads/Provider_Directory_Review_Industry_Report_Round_3_11-28-2018.pdf). We 
will take the suggestions provided into consideration as we continue 
this effort. We encourage all enrollees to check with a new provider 
about network participation to avoid surprises and continue to explore 
ways to work with the payers that we directly regulate (like MA 
organizations) to improve the accuracy of directories.
    We are finalizing regulation text on the Provider Directory API at 
42 CFR 422.120(b), 431.70(b), 438.242(b)(6), 457.760(b), and 
457.1233(d)(3) to require that accurate and complete provider directory 
information be made available through the API. We believe that this 
language will clarify our expectation that payers take steps to ensure 
provider directory information made available through the API 
accurately reflects the current providers within the payer's network.
    Commenter: Several commenters responded to our proposal that 
impacted payers update provider directory information made available 
through the API to current and prospective enrollees within 30 days of 
receiving an update to their directory information. The commenters 
suggested that CMS should decrease the amount of time allowed for 
updates; for instance, one commenter suggested that CMS should require 
that provider directory information is updated within 48 hours of a 
change, while another recommended directory updates occur in real time, 
or on a regular basis as frequently as possible.
    Some commenters who supported the requirement that provider 
directories be publicly available through API technology specifically 
expressed concerns with how frequently directories must be updated in 
the case of Medicaid and CHIP programs. One commenter recommended that 
the clock for the 30-day requirement begins from the date the state 
provides the information to the Medicaid or CHIP managed care plan. 
Another commenter recommended that entities should be required to 
update provider directories in real-time.
    Response: We appreciate commenters' suggestions, and agree that 
more frequent updates of the provider directory information made 
available through the API could help to increase the accuracy of this 
information. Our proposed 30-day time frame was not intended to 
preclude payers from updating the information available via the API on 
a shorter timeframe, or from making updates in real time. However, we 
understand that payers may have different operational processes for 
making updates to their provider directories and are seeking to set a 
minimum floor for how frequently information available through the API 
must be updated. This is consistent with timeframes for other updates 
some of these payers are required to make. For instance, Medicaid 
managed care plans must update paper provider directories monthly and 
electronic provider directories no later than 30 days after the plan 
receives the updated information under Sec.  438.10(h)(3).
    The Provider Directory API regulations finalized here require that 
state Medicaid and CHIP agencies, and managed care plans, make 
available through the API provider directory information no later than 
30 calendar days after the state or managed care plan receives the 
provider directory information or updates to the provider directory 
information. We confirm that the state or managed care plan must make 
the provider directory information available through the API within 30 
calendar days of receiving the information. This timeframe for managed 
care plans is consistent with the requirement in Sec.  438.10(h)(3) for 
Medicaid managed care plans, which applies to CHIP managed care 
entities under Sec.  457.1207.
    We decline to require updates to provider directories in real-time 
as we do not believe that such a timeframe is operationally feasible 
for MA organizations, states or Medicaid and CHIP managed care plans at 
this time. We are finalizing our proposal that MA organizations, state 
Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP 
managed care entities update provider directory information made 
available through this API within 30 days of receiving a change as 
proposed.
    Comment: Several commenters believe that, in order to increase the 
accuracy of provider directory data, CMS should take steps to hold 
providers responsible for the accuracy of their provider directory 
information. One commenter suggested CMS require health care providers 
to update their information with a centralized entity, for instance a 
trusted health information exchange, rather than looking to impacted 
payers to include these mandates in their contracts with

[[Page 25562]]

providers. Another suggested that CMS should require providers to 
submit rosters to CMS each month indicating which health plans they 
contract with, enabling CMS to validate information provided through 
the proposed API. Another commenter suggested CMS ensure that CMS-
regulated payers are provided with updated provider information in a 
timely manner by making such reporting requirements a condition of 
participation in Medicare.
    Response: We appreciate commenters' suggestions, and agree that 
providers have an important role to play in ensuring that provider 
directory information about them, provided to, and used by the payers 
with which they contract or participate, is up-to-date. While we did 
not include any proposals in this rulemaking specifically focused on 
provider responsibility for updating the information to be made 
available through the proposed API, we will continue to work with 
federal and industry partners to identify opportunities to improve the 
accuracy of provider directory information across the health care 
system.
    Comment: Several commenters noted that a centralized repository 
that can serve as a ``source of truth'' for provider directory 
information is needed to ensure accuracy, and urged CMS to support work 
across stakeholders for such an approach. One commenter noted that 
health information exchanges (HIEs) could help payers to update their 
information through access to the directories that HIEs use for 
clinical data exchange.
    Response: We thank commenters for their input. Our policy is 
focused around payers making provider directory information available 
through APIs to provide greater access to specific information on the 
providers in their networks. However, we believe entities focused on 
aggregating provider directory information can serve an important role, 
and we encourage payers to work with partners that maintain this 
information to improve accuracy.
    Comment: Several commenters suggested additional information for 
inclusion as part of the provider directory information made available 
through the API for current and prospective enrollees (in addition to 
provider names, addresses, phone numbers, and specialties), such as 
NPIs for individual and group providers, practice group name, health 
system name, as well as the specific plan(s) and tiers a provider 
participates in. One commenter also suggested including minimum 
provider demographics to be included in the clinical and administrative 
transactions to ensure accurate provider matching; whether the provider 
is accepting new patients; information about which providers are in-
network for a plan by geography and/or specialty regardless of whether 
the individual is a member of a particular plan or is researching plan 
options; and which clinicians are in-network for care coordination and 
plan switching purposes.
    Response: We appreciate commenters' suggestions and agree that this 
additional information may be helpful to consumers. However, at this 
time we are seeking to minimize the burden for the regulated payers 
that must comply with this proposal, and have sought to identify a 
minimum set of provider directory information that aligns with existing 
requirements applicable to MA organizations (including MA organizations 
that offer MA-PD plans), state Medicaid and CHIP FFS programs, Medicaid 
managed care plans, and CHIP managed care entities regarding such 
directories. We do encourage payers to explore how they can make 
additional provider directory data available through the API to most 
benefit current and prospective enrollees. Also, we note that the 
requirements in this final rule set out the minimum requirements; 
payers are strongly encouraged to go beyond that minimum, if and as 
possible, to make useful information available for their enrollees and 
beneficiaries.
    Comment: One commenter who supported our proposal also urged CMS to 
take additional steps to make provider directories more accessible to 
enrollees, for instance by integrating a provider directory in future 
iterations of Plan Finder for MA plans, and ensuring the directory data 
is accurate and up to date.
    Response: We thank the commenter for the suggestions. We will take 
these suggestions into consideration.
    Comment: Several commenters addressed issues with technical 
standards for provider directory information, with several stating that 
appropriate standards for making this information available through an 
API are still emerging. For instance, one commenter noted that current 
provider directory standards were written for FHIR Release 3 and that 
the standard has not been adopted by the field. The commenter stated 
that before CMS requires payers to make provider directory information 
available via a standards-based API, more work is needed to build the 
provider directory specification in FHIR Release 4.
    Several commenters suggested that CMS should delay implementing 
this proposal, proposed to be applicable starting January 1, 2020, 
until stakeholders have been able to establish consensus-based 
standards for the creation and display of directory information. One 
commenter encouraged CMS to develop a voluntary, multi-stakeholder 
partnership to establish data content FHIR-based standards related to 
provider directories and then wait to establish the timeframe for 
provider directory data updates until the development of these FHIR-
based standards are completed.
    Response: We appreciate commenters' concerns, and agree that 
updated FHIR-based provider directory implementation guidance is 
important for implementation of this policy. We confirm here that HL7 
FHIR Release 4.0.1--the API standard adopted at 45 CFR 170.215 and 
which must be used under our Provider Directory API requirement--
provides a base standard for moving information through an API. The 
basic information (name, phone number, address, and specialty) required 
for this Provider Directory API can all be represented through FHIR 
Release 4.0.1. Additional implementation guidance will provide 
additional information for how to use the FHIR Release 4.0.1 base 
standard to make provider directory information available and ensure 
greater uniformity in implementation and reduce implementation burden 
for payers. As noted in section III. of this final rule, we have been 
working with HL7 and partners to ensure the necessary consensus-based 
standards and associated guidance are available so that impacted payers 
can consistently implement all of the requirements included in this 
final rule. We are providing a link to a specific FHIR Release 4.0.1 
implementation guide and reference implementation for all interested 
payers for the Provider Directory API that provide valuable guidance to 
further support sharing the needed data using the required standards: 
https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. Though not mandatory, using this guidance will lower payer 
burden and support consistent implementation of the FHIR Release 4.0.1 
APIs.
    Appreciating the time needed for payers to build, implement, and 
test these APIs, we are providing additional time for implementation, 
and are finalizing January 1, 2021 as the implementation date for the 
Provider Directory API for all payers subject to this requirement. 
Appreciating the value of making this information publicly accessible, 
we do encourage payers to

[[Page 25563]]

implement this Provider Directory API as soon as they are able. We are 
requiring at 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for 
Medicaid state agencies, at 42 CFR 438.242(b)(6) for Medicaid managed 
care plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 
457.1233(d)(3) for CHIP managed care entities that these payers make 
the Provider Directory API accessible via a public-facing digital 
endpoint on their website. We will check a random sample of payer 
websites for links to these publicly accessible APIs, starting in 
January 2021 to evaluate compliance.
    Comment: One commenter suggested that, as CMS already requires 
provider directory information to be made available online by payers 
subject to this rule, for interoperability transactions CMS should 
require use of a standard described as ``the HIPAA 274 transaction.'' 
The commenter stated that the metadata defined within this transaction 
can drive a consistent payload for an API to support provider directory 
information sharing.
    Response: We appreciate the commenter's suggestion, but at this 
time we are finalizing requirements for provider directory information 
to be available through an API using the standards at 45 CFR 170.215, 
including, FHIR Release 4.0.1 standards finalized by HHS in the ONC 
21st Century Cures Act final rule (published elsewhere in this issue of 
the Federal Register) to consistently align all various API formats 
throughout the rule with a single modern standard capable of meeting 
all requirements. CMS understands that some information within the X12 
274 Transaction (Healthcare Provider Information Transaction Set for 
use within the context of an Electronic Data Interchange (EDI) 
environment) may provide the basic provider information to support an 
API. HHS, however, has not adopted the X12 274 transaction standard 
under HIPAA or for any other use. Moreover, the required availability 
of a plan's entire provider directory via an API is not a HIPAA 
transaction that has been defined or associated with a specific 
transaction under HIPAA. We believe that using FHIR Release 4.0.1 for 
the purpose of this Provider Directory API will provide greater long 
term flexibility for payers subject to this rule, allowing them the 
ability to meet minimum requirements, and extend beyond these 
requirements based on the industry's diverse and evolving needs 
surrounding provider directories, while reducing impact on those who 
may not be ready to receive additional information beyond the minimum 
set of data required by this final rule.
    Comment: One commenter requested that CMS ensure public health 
agencies are also able to access provider directory information made 
available through the API, while another commenter requested that 
approved agents and brokers be granted access to this information.
    Response: Under this final rule, the Provider Directory API must be 
publicly accessible, so that any third party can access an impacted 
payer's provider directory information. Our regulation text reflects 
this by requiring that the Provider Directory API be accessible via a 
public-facing digital endpoint on the applicable payer's website. The 
value of making this information available via an API is that third-
party developers will be able to access it to make it available in 
valuable and useful ways for all interested stakeholders. We therefore 
anticipate that public health agencies, agents, and brokers, and any 
other member of the public would be able to access these data via 
third-party apps.
    Comment: Several commenters suggested CMS require payers to include 
other types of non-physician professionals within their provider 
directories, such as nurse practitioners, certified registered nurse 
anesthetists, physical therapists, and post-acute care providers. 
Commenters stated that including additional qualified licensed non-
physician providers could help increase patient access to care.
    Response: We appreciate commenters' suggestions. We did not propose 
to change the parameters of the information required to be included in 
provider directories for the payers subject to the Provider Directory 
API requirement here. Existing requirements for paper and on-line 
provider directories, such as those in 42 CFR 422.111 and 438.10(h), 
are not changed or limited by this final rule. Instead, our API 
proposals and this final rule focus on making certain payers (that is, 
MA organizations, state Medicaid and CHIP FFS programs, Medicaid 
managed care plans, and CHIP managed care entities) share provider 
directory information through an API. How ``provider'' is defined in 
this context is outside the scope of this regulation.
    Comment: One commenter recommended that CMS amend the API 
requirement to also include FHIR endpoint information for providers as 
part of provider directory information, to ensure access to regional/
national directories in addition to the current partial ones.
    Response: We agree with commenters that FHIR endpoint information 
is important to improve interoperability across providers. We discuss 
FHIR endpoints in section IX. of this final rule. For this Provider 
Directory API, we have focused on a minimum set of information of 
primary interest to patients and typically found in provider 
directories. However, we encourage payers to consider including other 
data elements that may add value to the Provider Directory API. We may 
consider expanding this minimum set of information in potential future 
rulemaking.
    Comment: One commenter suggested that CMS impose penalties on plans 
that do not comply with the provider directory requirement.
    Response: We thank the commenter for this suggestion. We did not 
propose to establish additional penalties for noncompliance with the 
requirement to make provider directory information available through an 
API; however, we note that the requirement to make provider directory 
information available through an API will be a requirement for MA 
organizations, Medicaid managed care plans and CHIP managed care 
entities to fulfill under their contracts in their respective programs. 
Therefore, existing enforcement authority for ensuring compliance with 
those contracts will apply. Further, the API requirements, including 
the provider directory components of the required API(s) will be 
required for state Medicaid and CHIP agencies operating FFS Medicaid 
programs and CHIPs.
    Final Action: After consideration of the comments received, and for 
the reasons outlined in our response to these comments and in the CMS 
Interoperability and Patient Access proposed rule, we are finalizing 
regulations to require that MA organizations, Medicaid and CHIP FFS 
programs, Medicaid managed care plans, and CHIP managed care entities 
make standardized information about their provider networks available 
via a FHIR-based API conformant with the standards finalized by HHS in 
the ONC 21st Century Cures Act final rule (published elsewhere in this 
issue of the Federal Register) at 45 CFR 170.215 (including FHIR 
Release 4.0.1), excluding the security protocols related to user 
authentication and authorization and any other protocols that restrict 
the availability of this information to anyone wishing to access it. At 
a minimum, these payers must make available via the Provider Directory 
API provider names, addresses, phone numbers, and specialties. For MA 
organizations that offer MA-PD plans, we are specifying that they must 
make available, at a minimum, pharmacy

[[Page 25564]]

directory data, including the pharmacy name, address, phone number, 
number of pharmacies in the network, and mix (specifically the type of 
pharmacy, such as ``retail pharmacy''), updating the regulation text 
from the proposed rule, which simply stated ``number, mix, and 
addresses of network pharmacies''. All directory information must be 
available through the API within 30 calendar days of a payer receiving 
the directory information or an update to the directory information. We 
note we have also revised the proposed regulation text for making 
directory information available through an API to specify consistently 
that the directory information must be complete and accurate and that 
updates must be made in ``calendar'' days.
    The Provider Directory API is being finalized at 42 CFR 422.120 for 
MA organizations, at 42 CFR 431.70 for Medicaid state agencies, at 42 
CFR 438.242(b)(6) for Medicaid managed care plans, at 42 CFR 457.760 
for CHIP state agencies, and at 42 CFR 457.1233(d)(3) for CHIP managed 
care entities. We are finalizing that access to the published Provider 
Directory API must be fully implemented by January 1, 2021 for all 
payers subject to this new requirement. We encourage payers to 
implement this Provider Directory API as soon as they are able to make 
and show progress toward the API requirements in this final rule and to 
signal their commitment to making the information that will empower 
their patients easily accessible and usable. Under this final rule, MA 
organizations, Medicaid and CHIP FFS programs, Medicaid managed care 
plans, and CHIP managed care entities must make the Provider Directory 
API accessible via a public-facing digital endpoint on their website to 
ensure public discovery and access.

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

    We proposed a new requirement for MA organizations, Medicaid 
managed care plans, CHIP managed care entities, and QHP issuers on the 
FFEs to require these payers to maintain a process to coordinate care 
between payers by exchanging, at a minimum, the USCDI at the enrollee's 
request as specified in the proposed regulation text. Instead of 
specifically proposing use of the USCDI, we proposed use of a content 
standard adopted by ONC at 45 CFR 170.213, which was proposed in a 
companion proposed rule, the ONC 21st Century Cures Act proposed rule 
as the USCDI (version 1) (84 FR 7441 through 7444). Understanding that 
enrollees' information is already exchanged between plans for use in 
carrying out various plan functions,\43\ payers have experience 
exchanging, receiving, and incorporating data from other plans into an 
enrollee's record. We proposed requiring the USCDI data set be 
exchanged at the enrollee's direction, and when received by a payer, 
incorporated into the recipient payer's data system. As proposed, upon 
request from an enrollee, the USCDI data set would have to be sent to 
another payer that covers the enrollee or a payer identified by the 
enrollee at any time during coverage or up to 5 years after coverage 
ends, and the payer would have to receive the USCDI data set from any 
payer that covered the enrollee within the preceding 5 years. These 
proposals were intended to support patient directed coordination of 
care; that is, each of the payers subject to the requirement would be 
required to, upon an enrollee's request: (1) Receive the data set from 
another payer that had covered the enrollee within the previous 5 
years; (2) send the data set at any time during an enrollee's 
enrollment and up to 5 years later, to another payer that currently 
covers the enrollee; and (3) send the data set at any time during 
enrollment or up to 5 years after enrollment has ended to a recipient 
identified by the enrollee.
---------------------------------------------------------------------------

    \43\ See Office for Civil Rights. (2016, August 16). 3014-HIPAA 
and Health Plans--Uses and Disclosures for Care Coordination and 
Continuity of Care. Retrieved from https://www.hhs.gov/hipaa/for-professionals/faq/3014/uses-and-disclosures-for-care-coordination-and-continuity-of-care/.
---------------------------------------------------------------------------

    We identified in the proposed rule that this proposal is based on 
our authority under sections 1856(b) and 1857(e) of the Act to adopt 
standards and contract terms for MA plans; section 1902(a)(4) of the 
Act to adopt methods of administration for state Medicaid plans, 
including requirements for Medicaid managed care plans (MCOs, PIHPs, 
and PAHPs); section 2101(a) of the Act for CHIP managed care entities 
(MCOs, PIHPs, and PAHPs); and section 1311(e)(1)(B) of the Affordable 
Care Act for QHP issuers on the FFEs. We explained in the CMS 
Interoperability and Patient Access proposed rule our belief that the 
proposal will help to reduce provider burden and improve patient access 
to their health information through coordination of care between payers 
(84 FR 7640 through 7642). We also noted that the CHIP regulations 
incorporate and apply, through an existing cross-reference at 42 CFR 
457.1216, the Medicaid managed care plan requirements codified at 42 
CFR 438.62(b)(1)(vi). Therefore, the proposal for Medicaid managed care 
plans described also applied to CHIP managed care entities even though 
we did not propose new regulation text in part 457. We proposed that 
this new requirement would be applicable starting January 1, 2020 for 
MA organizations, Medicaid managed care plans, CHIP managed care 
entities, and beginning with plan years beginning on or after January 
1, 2020 for QHP issuers on the FFEs. Among other topics related to the 
proposal, we solicited comments on the proposed date these policies 
would be applicable.
    We proposed to codify this new requirement at 42 CFR 422.119(f) for 
MA organizations; at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care 
plans (and by extension under existing rules at 42 CFR 457.1216, to 
CHIP managed care entities); and at 45 CFR 156.221(f) for QHP issuers 
on the FFEs. The proposed new requirement was virtually identical for 
MA organizations, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs, with modifications in the 
proposal necessary for specific payer types to account for the program 
needs of each. The proposed regulation text references the content 
standard adopted at 45 CFR 170.213, which ONC proposed as the USCDI 
(version 1) data set (84 FR 7441 through 7444). We noted we believed 
that exchanging this data set would help both enrollees and health care 
providers coordinate care and reduce administrative burden to ensure 
that payers provide coordinated high-quality care in an efficient and 
cost-effective way that protects program integrity. For a full 
discussion of the benefits we anticipate from this data exchange 
requirement, see the discussion in the CMS Interoperability and Patient 
Access proposed rule (84 FR 7640).
    In addition to the benefits for care coordination at the payer 
level and reduced provider burden, we noted that once the requested 
information, as specified by the USCDI standard, was made available to 
the patient's current plan, the enrollee would have access to multiple 
years of their health information through the proposed Patient Access 
API, discussed in section III.C. of the CMS Interoperability and 
Patient Access proposed rule and in this final rule. This is the case 
because the proposal required the receiving payer to incorporate the 
received data into its records about the patient, therefore making 
these data the payer maintains, and data available to share with the

[[Page 25565]]

patient via the Patient Access API. The USCDI data set includes 
clinical data points essential for care coordination. Access to these 
data would provide the patient with a more comprehensive history of 
their medical care, helping them to make better informed health care 
decisions. We sought comment on how plans might combine records and 
address error reconciliation or other factors in establishing a more 
longitudinal record for each patient.
    We proposed to allow multiple methods for electronic exchange of 
the information, including use of the APIs proposed in section III. of 
the CMS Interoperability and Patient Access proposed rule (84 FR 7627 
through 7639), to allow for patient-mediated exchange of payer 
information or direct payer-to-payer communication, subject to HIPAA 
requirements, 42 CFR part 2, and other applicable federal and state 
laws. We noted that we considered requiring the use of the FHIR-based 
API discussed in section III. of the proposed rule for this information 
exchange; however, we understood that some geographic areas might have 
a regional health information exchange (HIE) that could coordinate such 
data transfers for any HIE-participating MA plans, Medicaid managed 
care plans, CHIP managed care entities, and QHP issuers on the FFEs 
that are subject to the proposal. We sought comment on whether it would 
be beneficial to interoperability and patient care coordination for us 
to require the use of the FHIR-based API otherwise proposed, and 
whether this should be the only mechanism allowed for this exchange, or 
whether multiple methods for electronic exchange of the information 
should be allowed under the proposed policy and whether CMS might be 
able to leverage its program authority to facilitate the data exchanges 
contemplated by the proposal. We expected enrollees to have constant 
access to requesting an exchange of data as the proposal would require 
exchange of the USCDI data set whenever an enrollee makes such a 
request, which may occur at times other than enrollment or 
disenrollment. We acknowledged that in some cases payers subject to the 
proposed requirement may be exchanging patient health information with 
other payers that are not similarly required to exchange USCDI data 
sets for enrollees, for example, if a consumer changes their health 
coverage from a QHP on an FFE to employer-sponsored coverage, and we 
requested comment on how to support patients and providers in those 
situations.
    We also proposed that a patient should be able to request his or 
her information from their prior payer up to 5 years after dis-
enrollment, which is considerably less than existing data retention 
policies for some of the payers.\44\ Further, we proposed that the 
health information received as part of the USCDI (version 1) data set 
under our proposal would have to be incorporated into the IT and data 
systems of each payer that receives the USCDI data set under the 
proposed requirement, such that the enrollee's data would be cumulative 
and move with the enrollee as he or she changes enrollment. For 
example, if a patient is enrolled in Plan 1 in 2020 and Plan 2 in 2021, 
then requests the data from Plan 1 to be sent to Plan 2, Plan 2 would 
have at least 2 years (2020 and 2021) of health information for that 
patient. If the patient moves to Plan 3 in 2022, Plan 3 should receive 
both 2020 and 2021 data from Plan 2 at the patient's request. While the 
proposal would require compliance (and thus exchange of these data 
sets) only by MA plans, Medicaid managed care plans, CHIP managed care 
entities, and QHP issuers on the FFEs, we noted that we hoped that 
compliance by these payers could be the first step toward adoption and 
implementation of these standards on a voluntary basis by other payers 
throughout the health care system.
---------------------------------------------------------------------------

    \44\ Under 42 CFR 422.504(d) and 438.3(u), MA organizations and 
Medicaid managed care plans, and CHIP plans must retain records for 
at least 10 years. Under 45 CFR 156.705; 45 CFR 155.1210(b)(2), (3) 
and (5), QHP issuers on the FFEs must also retain records for 10 
years.
---------------------------------------------------------------------------

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

    \45\ Office of the National Coordinator. (2019, June 4). 
Improved Diagnostics & Patient Outcomes. Retrieved from https://www.healthit.gov/topic/health-it-and-health-information-exchange-basics/improved-diagnostics-patient-outcomes.
---------------------------------------------------------------------------

    We proposed that the payers subject to this new requirement would 
be required to exchange, at a minimum, the data classes and elements 
included in the content standard proposed to be adopted at 45 CFR 
170.213 in the ONC 21st Century Cures Act proposed rule, specifically, 
the USCDI (version 1) data set. On behalf of HHS, ONC proposed to adopt 
the USCDI as a standard (84 FR 7441 through 7444), to be codified at 45 
CFR 170.213, and the proposed regulation text cross-references this 
regulation. These data exchanges would provide the enrollee's new payer 
with a core set of data that could be used to support better care 
coordination and improved outcomes for the enrollee. We considered 
requiring plans to exchange all the data that we proposed be available 
through an API (see section III. of the CMS Interoperability and 
Patient Access proposed rule (84 FR 7627 through 7639)) but we 
understood that ingesting data and reconciling errors has challenges 
and proposed this more limited data set to address those concerns. We 
sought comment on whether the USCDI data set would be comprehensive 
enough to facilitate the type of care coordination and patient access 
described in the proposal, or whether additional data fields and data 
elements that would be available under the API proposal in section III. 
of the CMS Interoperability and Patient Access proposed rule (84 FR 
7627 through 7639) should also be required. For a full discussion of 
the benefits of the USCDI for this data exchange, see the CMS 
Interoperability and Patient Access proposed rule (84 FR 7641).
    We stated that we believed that the proposed requirement would also 
support dually eligible individuals who are concurrently enrolled in MA 
plans and Medicaid managed care plans. Under the proposal, both of the 
dually eligible individual's payers would be subject to the requirement 
to exchange that individual's data in the form of the USCDI, which 
should improve the ability of both payers to coordinate care based on 
that data, as discussed in the CMS Interoperability and Patient Access 
proposed rule (84 FR 7642). We sought comment on how payers should 
coordinate care and exchange information for dually eligible 
individuals. We also sought comment on the associated burden on plans 
to exchange the USCDI data set under the proposal. In addition, we 
noted that we were interested in comments about potential legal 
barriers to exchanging the USCDI data set as would be required under 
the proposal; for example, whether there were federal, state, local, 
and tribal laws governing privacy for specific use cases (such as in 
the care of minors or for certain behavioral health treatments) that 
would raise additional considerations that we should address in this 
regulation or in guidance.
    We stated that activities related to the proposed requirement could 
qualify as a quality improvement activity (QIA)

[[Page 25566]]

meeting the criteria described in section 2718(a)(2) of the PHSA for 
purposes of the Medical Loss Ratio (MLR) requirements for QHP issuers 
on an FFE,\46\ and similar standards for treatment of QIA standards 
applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs) 
under 42 CFR 438.8, CHIP managed care entities under 42 CFR 
457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490. An 
entity's MLR is generally calculated as the proportion of revenue spent 
on clinical services and QIA. There are several specific criteria an 
expense must meet, such as being designed to improve health quality and 
health outcomes through activities such as care coordination, in order 
to qualify as QIA.\47\ We requested comments related to this assumption 
and its implications.
---------------------------------------------------------------------------

    \46\ While this rulemaking is specific to QHP issuers 
participating on the FFEs, we note that to the extent other 
commercial market issuers incur similar costs for coverage sold in 
the individual or group markets, those expenses may similarly 
qualify as QIA.
    \47\ See, for example, 45 CFR 158.150 and 45 CFR 158.151.
---------------------------------------------------------------------------

    We summarize the public comments we received on the payer-to-payer 
data exchange, as well as on whether these new activities may qualify 
as QIA for MLR purposes, and provide our responses.
    Comment: Many commenters were very supportive of this proposal and 
indicated their belief that these new data exchange requirements could 
improve care coordination by reducing burden on both beneficiaries and 
providers by limiting the need for duplicative letters of medical 
necessity, preventing inappropriate step therapy, and reducing 
unnecessary utilization reviews and prior authorizations.
    Response: We appreciate the commenters' support for this payer-to-
payer data exchange proposal. We are finalizing this proposal with some 
modifications as detailed below. Under this final rule, payers subject 
to this requirement must maintain a process for the electronic exchange 
of, at a minimum, the data classes and elements included in the content 
standard finalized by HHS in the ONC 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register) at 45 CFR 
170.213, which is currently version 1 of the USCDI. We are also 
finalizing that payers must use this process to exchange the USCDI-
defined data set with the approval and at the direction of a current or 
former enrollee, or the enrollee's personal representative, to align 
with the language used for the API requirements. Furthermore, we are 
finalizing the proposal that upon receipt, the receiving payer must 
incorporate the data set into the payer's own records about the 
enrollee with a clarification that this obligation applies to records 
about current enrollees. We clarify here that incorporating the data 
into the payer's records under this specific regulation would not 
require that the payer treat or rely on these data as its own, but that 
the payer must include these data in the record it maintains for each 
enrollee. While the obligation to incorporate data received from other 
payers into the receiving payer's records applies only for data about 
current enrollees, once incorporated, these data must be maintained 
even after a current enrollee leaves the payer's coverage. We do not 
want to be overly prescriptive about how these data are used by each 
payer at this time. Initially, we are only requiring that these data 
are incorporated into the existing record to facilitate the creation 
and maintenance of a patient's cumulative health record with their 
current payer. In subsequent rulemaking, however, we may be more 
specific, depending on proposed use cases, and propose more 
prescriptive use of specific data.
    Comment: Some commenters expressed concern about each payer's 
increased access to clinical information impacting coverage decision-
making. Commenters noted that while historically physicians have 
controlled the patient's clinical data in determining what to submit to 
obtain reimbursement for care provided, payers would now have access to 
information outside of the scope of the specific service being billed 
by a provider. Commenters noted that a payer may access the exchanged 
health data from a prior payer and determine that a patient has already 
received treatment for a condition and deny, delay, and/or require 
prior authorization for allegedly duplicative treatment. Additionally, 
a few commenters expressed concern that payers may use prior 
information to restrict coverage for medically necessary care that a 
patient may have received previously. A few commenters recommended that 
CMS require that payers must attest that the exchanged data cannot be 
used to deny or delay treatment, increase rates, or implement step 
therapy.
    Response: We appreciate the commenters' concerns. We note that this 
regulation does not make any changes to when payers can deny coverage. 
The data received via this data exchange must be used per all 
applicable law, regulation, and in accordance with payer contracts as 
it relates to coverage decisions and, specifically, coverage denial. 
Nothing in this regulation changes any existing obligations or policies 
related to coverage or services. Further, as proposed and finalized, 
the regulations regarding the exchange of data among payers is 
triggered by an enrollee's request that the information be sent or 
received and incorporated. The individual enrollee retains control in 
this situation and can refrain from requesting information be sent to a 
new or current payer. We do note, however, that there are currently 
scenarios where payers can exchange data without an enrollee's request, 
such as for payment and health care operations.
    Comment: Several commenters were concerned about the responsibility 
of MA plans, Medicaid managed care plans, CHIP managed care entities, 
and QHP issuers on the FFEs to forward information from other payers or 
information from outside their organization where they did not control 
data integrity. Also, commenters were concerned there might be 
information that is contradictory and were unsure of each payer's 
responsibilities in that case.
    Response: We appreciate the commenters' concerns. We do believe 
that patients have a right to their data. In addition, they have a 
right to request that their health data follow them throughout their 
health care journey. It is only when patients are able to facilitate 
the sharing of their data, and even see it themselves, such as via the 
Patient Access API, that they will be able to understand where there 
may be opportunities to work with their previous and current providers 
and payers to ensure they have an accurate health record. Today, to the 
extent permitted by law, payers may exchange patient data without the 
patient's consent for various purposes including payment and health 
care operations. The policy we are finalizing here will allow the 
patient to facilitate that exchange of their health information. In 
using this process, patients can ensure their payers and providers have 
the most accurate and up-to-date information about them.
    Payers can choose to indicate which data being exchanged were 
received from a previous payer so the receiving payer, or even a 
patient, understands where to direct questions and is aware of the 
scope of control over data integrity. This will also help receiving 
payers and patients understand how to reconcile contradictory 
information as it can be made clear where questions should be directed. 
Payers are under no obligation under this regulation to update, 
validate, or correct data received from another payer.

[[Page 25567]]

    Comment: Several commenters agreed with the proposed suggestion 
that activities related to this proposal may qualify as QIA meeting the 
criteria described in section 2718(a)(2) of the PHSA for purposes of 
the MLR requirements for QHP issuers on the FFEs, and similar standards 
for treatment of quality improvement standards applicable to Medicaid 
managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP 
managed care entities under 42 CFR 457.1203(f), and MA plans under 42 
CFR 422.2400 through 422.2490.
    Response: We confirm that we continue to believe that expenses for 
the care coordination data exchanges required by this final rule may 
qualify as QIA for purposes of calculating the MLR for payers that 
engage in such exchanges. As noted above, while this rulemaking is 
specific to QHP issuers participating on the FFEs, to the extent other 
commercial market issuers incur similar costs for coverage sold in the 
individual or group markets, those expenses may similarly qualify as 
QIA. We appreciate the commenters' support and will consider 
recognizing the expenses related to this data exchange as QIA in future 
rulemaking or guidance, as may be necessary.
    Comment: Many commenters were concerned about the time frame to 
implement this provision and were concerned making this policy 
applicable in 2020 would not provide enough time to operationalize this 
policy.
    Response: We appreciate the commenters' concerns and understand 
that it will take time to fully and properly implement this policy. We 
are finalizing this payer-to-payer data exchange requirement with an 
applicability date of January 1, 2022 with respect to the exchange of 
the USCDI data set.
    Although we did not propose to require payers to use an API to 
exchange the USCDI under this payer-to-payer data exchange proposal, we 
appreciate and support that some payers would like to leverage the 
Patient Access API (discussed in section III. of this final rule) to 
meet the requirements of this payer-to-payer data exchange. The Patient 
Access API requirement makes USCDI data available to the patient or a 
third party at the patient's direction. Because the Patient Access API 
is facilitating the exchange of the USCDI, some of the work to develop 
an API to exchange these data and the work to map the relevant USCDI 
data will be completed by January 1, 2021, when the Patient Access API 
must be made available as finalized in section III. of this rule. In 
addition, if a payer receives data via an API, the payer could then 
incorporate it into a patient's record and in turn share it with the 
patient via the Patient Access API with little additional work needed.
    We appreciate the value of using an API for this data exchange, and 
we understand the efficiencies that it can add to both this payer-to-
payer data exchange as well as the Patient Access API policy. We also 
appreciate that incorporating data from other payers received via an 
API will be a new experience for payers, however. For instance, payers 
will need to develop a process to incorporate data from other payers 
into their systems, including potentially processes for tagging these 
data as originating with another payer so they can efficiently share 
that information with patients and future payers. These are additional 
processing steps that take time to implement.
    In evaluating the comments on the proposals in this rule, and 
appreciating the value of sharing and exchanging data via APIs, we see 
the benefit of having all data exchanged via APIs. Therefore, we may 
consider for future rulemaking an API-based payer-to-payer data 
exchange. At this time, we believe that an applicability date of 
January 1, 2022 for compliance with this requirement is appropriate. 
This provides time for payers to get experience with the Patient Access 
API, and provides payers with additional time to fully and successfully 
implement this payer-to-payer data exchange requirement.
    To support a more seamless data exchange and to further clarify 
this payer-to-payer data exchange requirement, we are finalizing some 
modifications of the proposed regulation text at 42 CFR 
422.119(f)(1)(ii) and (iii) for MA organizations; at 42 CFR 
438.62(b)(1)(vi)(B) and (C) for Medicaid managed care plans (and by 
cross-reference from 42 CFR 457.1216, to CHIP managed care entities); 
and at 45 CFR 156.221(f)(1)(ii) and (iii) for QHP issuers on the FFEs 
to clearly indicate payers are obligated under this proposal to, with 
the approval and at the direction of a current or former enrollee, 
exchange data with any other payer identified by the enrollee. The 
proposed regulation text used both the term ``recipient'' and ``any 
other health care plan'' to identify where these data would be sent at 
an enrollee's request; the term ``recipient'' could have been 
interpreted more broadly than we intended. In the final regulation 
text, we are using ``payer'' instead and consolidating the proposed 
provisions that would require the payer that is subject to these rules 
to send data at the enrollee's request at any time during enrollment or 
up to 5 years after enrollment ends. As discussed in section III. of 
this final rule, we are also specifying in the final regulations that a 
payer is only required to send data received under this payer-to-payer 
data exchange requirement in the electronic form and format it was 
received. In this way, a payer would not be asked to receive paper 
records from another payer under this policy and then in turn share 
those paper records with another payer in the future at the patient's 
direction. If the payer received a patient's information via an API, 
the payer must share it via an API if the payer they are sending to has 
the capacity to receive it. If a patient requests that a former payer 
send their information to their new payer and then requests that their 
new payer make their data accessible via that new payer's Patient 
Access API, the new payer would only be required to include the 
information received from the former payer at the patient's direction 
if this newly acquired information was received via a FHIR-based API. 
Otherwise, the new payer is only required to share data via the Patient 
Access API that the payer already maintains and has prepared to be 
shared via a FHIR-based API.
    We are also finalizing new regulation text, at 42 CFR 422.119(h) 
for MA organizations; at 42 CFR 438.62(b)(1)(vii) for Medicaid managed 
care plans (and by cross-reference from 42 CFR 457.1216, to CHIP 
managed care entities); and at 45 CFR 156.221(i) for QHP issuers on the 
FFEs, that these regulated payers will need to comply with the payer-
to-payer data exchange requirements beginning January 1, 2022 (or 
beginning with plan years beginning on or after January 1, 2022 for QHP 
issuers on the FFEs). In addition, this requirement, as finalized, 
provides that payers are required to exchange data they maintain with a 
date of service on or after January 1, 2016. In this way, payers only 
have to prepare a defined initial historical set of data for sharing 
via this payer-to-payer data exchange policy, as also required under 
the Patient Access API policy discussed in section III. of this final 
rule. We believe that delaying implementation to January 1, 2022 and 
specifying that only data with a date of service on or after January 1, 
2016 must be exchanged under the new requirement addresses concerns 
about the timing and level of burden involved in meeting this 
requirement. This also clarifies that if certain information is not 
maintained by the

[[Page 25568]]

payer, the payer is not obligated to seek out and obtain the data.
    We also sought comment on how this policy might impact dually 
eligible individuals. We summarize the public comments we received on 
this payer-to-payer data exchange specifically regarding our request 
for comment for how this policy might impact dually eligible 
individuals who are concurrently enrolled in MA plans and Medicaid 
managed care plans and provide our responses.
    Comment: A few commenters supported the proposal because it could 
improve care coordination for dually eligible beneficiaries. One 
commenter noted that because of this proposal, MA plans and Medicaid 
MCO plans would have the same data and health history for an 
individual. One commenter believed that this could help states that do 
not have an easily accessible source of data for knowing when their 
Medicaid beneficiaries are enrolled for Medicare. This commenter 
recommended including enrollment source and enrollment and 
disenrollment dates in the data exchanged between payers.
    Response: We appreciate the commenters' support and the suggestion 
noted. We will further evaluate this suggestion for future 
consideration.
    Comment: One commenter requested additional information regarding 
how plans should account for gaps in plan coverage over the course of 5 
years. The commenter believed this will be particularly important for 
dual eligible and Medicaid beneficiaries who may move in and out of a 
health plan program as their status may change due to changing 
circumstances.
    Response: We appreciate the commenter's request for information. We 
note that one payer would only be obligated to send another payer 
information that the payer maintains (which could include data received 
from other payers under this final rule that must be incorporated into 
the current payer's records). If in the 5 years prior to January 1, 
2022, a patient was in a Medicaid managed care plan for 1 year in 2019 
and then there was a break in service with the patient returning for 1 
year in 2021, this Medicaid managed care plan would be required to 
share data from 2019 and 2021 if requested by the patient. It would not 
be the managed care plan's responsibility to address the gaps in the 
data that the plan maintains. Assuming that the patient was enrolled in 
an MA plan or another Medicaid managed care plan in 2020, the patient 
could request that the plan they had in 2020 independently send their 
data to the payer they have indicated. In this way, the indicated payer 
is now the holder of the comprehensive information, as under this 
requirement a payer must incorporate the data received from other 
payers under this policy into their data system. If the patient leaves 
to go to a new payer in 2023, the one payer that now maintains their 
data from 2019 to 2022 would be the one payer that could forward the 
data to the new payer, in the electronic form and format it was 
received. We acknowledge that this may be complex for dually eligible 
beneficiaries.
    Comment: A few commenters noted advantages, burdens, and 
complexities associated with plans serving dually eligible 
beneficiaries continuously aggregating real-time member data from 
multiple plans. One commenter noted that each payer should only be 
responsible for their own data set and the coordination of data across 
multiple plans and providers would be more ideally done through a 
Trusted Exchange Framework and Common Agreement (TEFCA). This commenter 
noted that additional technical capabilities will be required due to 
the possibility of overlapping coverage when combining and 
incorporating records.
    Response: We appreciate these thoughtful comments. We note that 
this payer-to-payer data exchange is only required when initiated by an 
enrollee's request, and only applies to the payers who are subject to 
our final regulations at 42 CFR 422.119(f)(1) and (h) for MA 
organizations; 42 CFR 438.62(b)(1)(vi) and (vii) for Medicaid managed 
care plans (and by cross-reference from 42 CFR 457.1216, to CHIP 
managed care entities); and at 45 CFR 156.221(f) and (i) for QHP 
issuers on the FFEs. The enrollee may request this payer-to-payer 
exchange just once, or more frequently. We did not propose, and are not 
finalizing, any requirement for continuous data exchange, however.
    Final Action: After consideration of the comments received, and for 
the reasons outlined in our response to these comments and in the CMS 
Interoperability and Patient Access proposed rule, we are finalizing 
with modifications our proposal at 42 CFR 422.119(f)(1) and 
438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to require MA 
organizations, Medicaid managed care plans, CHIP managed care entities, 
and QHP issuers on the FFEs to maintain a process for the electronic 
exchange of, at a minimum, the data classes and elements included in 
the content standard adopted at 45 CFR 170.213 (currently version 1 of 
the USCDI), as outlined in section III. of this final rule. 
Specifically, we are finalizing as proposed that the payers subject to 
these regulations incorporate the data they receive into the enrollee's 
record. In the final regulation text, we are using the language ``with 
the approval and at the direction'' of the enrollee versus ``at the 
request'' of the enrollee to align with the language used for the API 
requirements.
    We are finalizing modifications to the proposed regulation text to 
streamline the text and best specify the scope of the policy as 
intended, as well as to align the text for all payer types as 
appropriate. Specifically, at 42 CFR 422.119(f)(1)(i), 
438.62(b)(1)(vi)(A) (and by cross-reference from 42 CFR 457.1216), and 
at 45 CFR 156.221(f)(1)(i), the regulation text states that relevant 
payers ``receive'' versus ``accept'' data for current enrollees. At 42 
CFR 422.119(f)(1)(ii), 438.62(b)(1)(vi)(B) (and by cross-reference from 
42 CFR 457.1216), and at 45 CFR 156.221(f)(1)(ii), the final 
regulations provide that a payer must send the defined information set 
to any other payer. In addition, at 42 CFR 422.119(f)(1)(iii), 
438.62(b)(1)(vi)(C) (and by cross-reference from 42 CFR 457.1216), and 
at 45 CFR 156.221(f)(1)(iii), we specify that a payer is only obligated 
to send data received from another payer under this policy in the 
electronic form and format it was received. This is intended to reduce 
burden on payers. We note the final regulations do use the term 
``payer'' in place of ``health care plan'' to clarify that the scope of 
the obligations are for all payers impacted by this regulation. Also at 
45 CFR 156.221(f)(1), we updated the title of the paragraph to align 
with the parallel regulations for other payers types, and we corrected 
an incomplete sentence. Finally, we specify that this policy also 
applies to an enrollee's personal representative.
    We are also finalizing regulation text to address when these 
regulated payers must comply with these new requirements at 42 CFR 
422.119(h) for MA organizations; at 42 CFR 438.62(b)(1)(vii) for 
Medicaid managed care plans (and at 42 CFR 457.1216, to CHIP managed 
care entities); and at 45 CFR 156.221(i) for QHP issuers on the FFEs. 
Starting January 1, 2022, and for QHP issuers on the FFEs starting with 
plan years beginning on or after January 1, 2022, the finalized 
regulation requires these payers to exchange data with a date of 
service on or after January 1, 2016 that meets the requirements of this 
section and which the payer maintains. In this way, payers only have to 
prepare an initial historical set of data for sharing via this payer-
to-payer data exchange policy that is consistent with the data set to 
be available through the

[[Page 25569]]

Patient Access API, as finalized in section III. of this final rule.

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

    We proposed to require MA plans, Medicaid managed care plans, CHIP 
managed care entities, and QHP issuers on the FFEs to participate in 
trust networks in order to improve interoperability in these programs. 
We noted that we would codify this requirement in, respectively, 42 CFR 
422.119(f)(2), Sec.  438.242(b)(5), and Sec.  457.1233(d) (which cross-
references the requirements in 42 CFR 438.242(b)(5)) and 45 CFR 
156.221(f). In general, payers and patients' ability to communicate 
between themselves and with health care providers could considerably 
improve patient access to data, reduce provider burden, and reduce 
redundant and unnecessary procedures. Trusted exchange networks allow 
for broader interoperability beyond one health system or point to point 
connections among payers, providers, and patients. Such networks 
establish rules of the road for interoperability, and with maturing 
technology, such networks are scaling interoperability and gathering 
momentum with participants, including several federal agencies, EHR 
vendors, retail pharmacy chains, large provider associations, and 
others.
    The importance of a trusted exchange framework to such 
interoperability is reflected in section 4003(b) of the Cures Act, 
which was discussed in more detail in section I.D. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7612 through 
7614). In section VI. of the CMS Interoperability and Patient Access 
proposed rule (84 FR 7642), we discussed and explained our proposal to 
require certain payers to participate in trusted exchange networks. A 
trusted exchange framework allows for the secure exchange of electronic 
health information with, and use of electronic health information from, 
other health IT. Widespread payer participation in such a framework 
might allow for more complete access and exchange of all electronically 
accessible health information for authorized use under applicable state 
or federal law, which we believe would lead to better use of such data. 
We noted that while we cannot require widespread payer participation in 
trust networks, we proposed to use our program authority in the MA 
program, Medicaid managed care program, CHIP managed care program, and 
QHP certification program for the FFEs to increase participation in 
trust networks and to bring the potential benefits of participating in 
such programs, including improved interoperable communication and care 
coordination, which result in opportunities for improved patient 
outcomes and burden reduction.
    We proposed to require, beginning January 1, 2020, that MA plans, 
Medicaid managed care plans, CHIP managed care entities, and QHP 
issuers on the FFEs participate in a trusted exchange network. The 
proposal was based on our authority under: Sections 1856(b) and 1857(e) 
of the Act to adopt standards and contract terms for MA plans; section 
1902(a)(4) of the Act to adopt methods of administration for the 
administration state Medicaid plans, including requirements for 
Medicaid managed care plans (MCOs, PIHPs, and PAHPs); section 2101(a) 
for CHIP managed care entities (MCOs, PIHPs, and PAHPS); and section 
3001(c)(9)(F)(iii) of the PHSA and section 1311(e)(1)(B) of the 
Affordable Care Act for QHP issuers on an FFE. Under the proposal, and 
consistent with section 4003(b) of the Cures Act, participation would 
be required in a trusted exchange framework that met the following 
criteria:
    (1) The trusted exchange network must be able to exchange PHI, 
defined at 45 CFR 160.103, in compliance with all applicable state and 
federal laws across jurisdictions.
    (2) The trusted exchange network must be capable of connecting both 
inpatient EHRs and ambulatory EHRs.
    (3) The trusted exchange network must support secure messaging or 
electronic querying by and between patients, providers, and payers.
    We proposed to codify these requirements for these payers at 42 CFR 
422.119(f)(2) for MA organizations, Sec.  438.242(b)(5) for Medicaid 
managed care plans, Sec.  457.1233(d)(2) for CHIP managed care 
entities, and 45 CFR 156.221(f) for QHPs on the FFEs.
    On April 19, 2019, ONC released the draft Trusted Exchange 
Framework and Common Agreement (TEFCA Draft 2) for public comment.\48\ 
Previous commenters on draft 1 of the TEFCA, particularly payers 
providing comments, requested that existing trust networks that are 
operating successfully be leveraged in further advancing 
interoperability; thus, we considered a possible future approach to 
payer-to-payer and payer-to-provider interoperability that leverages 
existing trust networks to support care coordination and improve 
patient access to their data. We requested comments on this approach 
and how it might be aligned in the future with section 4003(b) of the 
Cures Act. We also requested comments on the applicability date we 
proposed for the trusted exchange network participation requirement and 
what benefits and challenges the payers subject to our proposal might 
face meeting this requirement for additional consideration in future 
rulemaking.
---------------------------------------------------------------------------

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

    We summarize the public comments we received on this topic and 
provide our responses.
    Comment: Although many stakeholders supported the concept of this 
proposal, there were strong exceptions. Many commenters, particularly 
payers, indicated that it was premature for CMS to finalize a proposal 
related to trusted exchange network participation before the first 
version of the Common Agreement under ONC's TEFCA was finalized. 
Commenters noted that, even though they supported using a trusted 
exchange network, it would not be advisable until after TEFCA as 
outlined in section 4003 of the 21st Century Cures Act was available to 
facilitate this proposal.
    Response: We appreciate that although commenters supported the 
general concept of trusted exchange network participation and how it 
could advance interoperability and data exchange, the true value of 
this concept might be best realized via TEFCA in the future. We agree 
that trusted exchange networks can play a positive role, but given the 
concerns commenters raised regarding the need for a mature TEFCA, and 
appreciating the ongoing work on TEFCA being done at this time, we are 
not finalizing this policy at this time.
    Comment: Some commenters noted that more detail would be needed to 
understand how this proposal would be operationalized. These commenters 
also indicated more information would be needed to understand how this 
policy would relate to existing Health Information Exchanges (HIEs) and 
Health Information Networks (HINs) and whether these entities would 
qualify as trusted exchange networks. A few commenters indicated this 
policy may be redundant appreciating the existing role of HIEs and 
HINs.
    Response: We appreciate the commenters' concerns and requests for

[[Page 25570]]

additional information. We will keep these in mind as we consider 
possible future proposals around participation in trusted exchange 
networks.
    Comment: Many commenters expressed concerns with the proposed 
implementation timeline. They did not believe this policy could be 
implemented by January 1, 2020. Commenters indicated it would take more 
time to meet the necessary requirements and fully understand the 
implications of the policy, particularly for HIEs and HINs. Many 
commenters suggested a delay ranging from 12 to 24 months. Other 
commenters suggested CMS align the timeline of this proposal with TEFCA 
implementation milestones. In addition to a delay, some commenters 
suggested an exemption process.
    Response: We appreciate the commenters concerns, and based on these 
concerns and those summarized from other commenters, we are not 
finalizing this proposal at this time. To reflect this in this final 
rule, the regulation text proposed for all impacted payers is not being 
finalized. In addition, as 42 CFR 438.242(b)(5) is not being finalized, 
the regulation text proposed at 42 CFR 438.242(b)(6) is being 
redesignated as 42 CFR 438.242(b)(5).
    Final Action: After consideration of the comments received, and for 
the reasons outlined in our response to these comments, we are not 
finalizing this proposal to require MA organizations, Medicaid managed 
care plans, CHIP managed care entities, and QHP issuers on the FFEs to 
participate in a trusted exchange network.

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

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

1. Background
    The Medicare and Medicaid programs were originally created as 
distinct programs with different purposes. The programs have different 
rules for eligibility, covered benefits, and payment. The programs have 
operated as separate and distinct systems despite a growing number of 
people who depend on both programs (known as dually eligible 
individuals) for their health care. There is an increasing need to 
align these programs--and the data and systems that support them--to 
improve care delivery and the beneficiary experience for dually 
eligible individuals, while reducing administrative burden for 
providers, health plans, and states. The interoperability of state and 
CMS eligibility and Medicaid Management Information System (MMIS) 
systems is a critical part of modernizing the programs and improving 
beneficiary and provider experiences. Improving the accuracy of data on 
dual eligibility by increasing the frequency of federal-state data 
exchanges is a strong first step in improving how these systems work 
together.
2. Data Exchanges To Support State Buy-In for Medicare Parts A and B
    States and CMS routinely exchange data on who is enrolled in 
Medicare and Medicaid, and which parties are liable for paying that 
beneficiary's Parts A and B premiums. These data exchanges support 
state, CMS, and Social Security Administration (SSA) premium 
accounting, collections, and enrollment functions. Section 1843 of the 
Act permits states to enter into an agreement with the Secretary to 
facilitate state ``buy-in,'' that is, payment of Medicare premiums, in 
this case Part B premiums, on behalf of certain individuals. For those 
beneficiaries covered under the agreement, the state pays the 
beneficiary's monthly Part B premium. Section 1818(g) of the Act 
establishes the option for states to amend their buy-in agreement to 
include enrollment and payment of the Part A premium for certain 
specified individuals. All states and the District of Columbia have a 
Part B buy-in agreement; 36 states and the District of Columbia have a 
Part A buy-in agreement.
    To effectuate the state payment of Medicare Part A or Part B 
premiums, a state submits data on a buy-in file to CMS via an 
electronic file transfer (EFT) exchange setup. The state's input file 
includes a record for each Medicare beneficiary for whom the state is 
adding or deleting coverage, or changing buy-in status. In response, 
CMS returns an updated transaction record that provides data 
identifying, for each transaction on the state file, whether CMS 
accepted, modified, or rejected it, as well a Part A or Part B billing 
record showing the state's premium responsibility. In addition, the CMS 
file may ``push'' new updates obtained from SSA to the state, for 
example, changes to the Medicare Beneficiary Identifier number or a 
change of address.
    We have issued regulations for certain details of the state buy-in 
processes. For Medicare Part A, 42 CFR 407.40 describes the option for 
states to amend the buy-in agreement to cover Part A premiums for 
Qualified Medicare Beneficiaries (QMBs). For Medicare Part B, 42 CFR 
406.26 codifies the process for modifying the buy-in agreement to 
identify the eligibility groups covered. CMS subregulatory guidance, 
specifically Chapter 3 of the State Buy-in Manual,\49\ specifies that 
states should exchange buy-in data with CMS at least monthly, but 
describes the option for states to exchange buy-in data with CMS daily 
or weekly. Likewise, states can choose to receive the CMS response data 
file daily or monthly. We note that 35 states and the District of 
Columbia are now submitting buy-in data to CMS daily; 31 states and the 
District of Columbia are now receiving buy-in response files from CMS 
daily.
---------------------------------------------------------------------------

    \49\ Centers for Medicare and Medicaid Services. (2003). State 
Buy-In Manual: Chapter 3--Data Exchange. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Guidance/Manuals/downloads/buyin_c03.pdf. (Last accessed June 24, 2019).
---------------------------------------------------------------------------

    While many states submit and receive buy-in files daily, some 
continue to only do so on a monthly basis. We have become increasingly 
concerned about the limitations of monthly buy-in data exchanges with 
states. The relatively long lag in updating buy-in data means that the 
state is not able to terminate or activate buy-in coverage sooner, so 
the state or beneficiary may be paying premiums for longer than 
appropriate. In most cases, funds must be recouped and redistributed--a 
burdensome administrative process involving debits and payments between 
the beneficiary, state, CMS, and SSA. Additionally, transaction errors 
do occur in the current data exchange processes. In a monthly exchange, 
it can take multiple months to correct and resubmit an improperly 
processed transaction, exacerbating the delays in appropriately 
assigning premium liability, leading to larger mispayment, recoupment, 
and redistribution of premiums. Exchanging the buy-in data with greater 
frequency supports more timely access to coverage.
    All states' systems already have the capacity to exchange buy-in 
data. We acknowledge that states that do not already exchange data 
daily will need an initial, one-time systems change to do so. However, 
moving to a daily data exchange would result in a net reduction of 
burden for states, and further, reduce administrative complexity for 
beneficiaries and providers. More frequent submission of updates to 
individuals' buy-in status positively impacts all involved. For a full 
discussion of the benefits, see the CMS Interoperability and Patient 
Access

[[Page 25571]]

proposed rule (84 FR 7643 through 7644).
    While there exist opportunities to modernize the platform for buy-
in data exchange, we believe that an important first step is to promote 
the exchange of the most current available data. Section 1843(f) of the 
Act specifies that Part B buy-in agreements shall contain such 
provisions as will facilitate the financial transactions of the State 
and the carrier with respect to deductions, coinsurance, and otherwise, 
and as will lead to economy and efficiency of operation. Further, 
section 1818(g)(2)(A) of the Act on Part A buy-in identifies this 
section 1843(f) requirement as applicable to Part A buy-in. While the 
regulations governing buy-in agreements (see 42 CFR 406.26 and 407.40) 
are silent on the frequency of buy-in data exchanges, current guidance 
articulates that the required buy-in data may be submitted daily, 
weekly, or monthly. Therefore, we proposed to establish frequency 
requirements in the regulations at 42 CFR 406.26(a)(1) and 407.40(c) to 
require all states to participate in daily exchange of buy-in data with 
CMS, with ``daily'' meaning every business day, but that if no new 
transactions are available to transmit, data would not need to be 
submitted on a given business day. We noted that we believe these 
requirements will improve the economy and efficiency of operation of 
the buy-in process. We proposed that states would be required to begin 
participating in daily exchange of buy-in data with CMS by April 1, 
2022. We noted that we believe this applicability date would allow 
states to phase in any necessary operational changes or bundle them 
with any new systems implementation. In the CMS Interoperability and 
Patient Access proposed rule, we estimated that 19 states would need to 
make a system change to send buy-in data to CMS daily and 22 states 
would need to make a system change to receive buy-in data from CMS 
daily (84 FR 7668). Based on more recent data, we estimate that 26 and 
19 states would require such system changes, respectively. We updated 
our estimates to determine the one-time cost to be $85,000 per state, 
per change, so a state that needs to make systems updates to both send 
buy-in data daily, and receive buy-in data daily would have a one-time 
cost of just over $170,000. We sought comment on the proposals.
    We summarize the public comments we received on data exchanges to 
support state buy-in for Medicare Parts A and B and provide our 
responses.
    Comment: Almost all those who commented on these provisions 
supported the proposal to require that all states participate in daily 
exchange of buy-in data with CMS by April 1, 2022. Commenters stated 
that the changes would improve the timeliness and accuracy of 
eligibility and enrollment data, and enhance capability for 
coordination of benefits.
    Response: We appreciate the strong support for the proposed change 
to the regulation.
    Comment: One commenter supported the change, but also encouraged 
CMS to modify its own processes and systems to effectively leverage 
daily data exchanges to support enhanced care for dually eligible 
individuals. Another commenter requested clarification if the daily 
state submission of the buy-in file encompasses a reciprocal daily 
response from CMS to the states.
    Response: We agree that CMS and states both play important roles in 
implementing systems changes to support the state buy-in process. 
Currently, states can choose to exchange buy-in data with CMS daily, 
weekly, or monthly; and separately, they can choose to receive the CMS 
response data file daily, weekly, or monthly. We proposed that all 
states both send data to CMS and receive responses from CMS on a daily 
basis. We will continue to look for opportunities to optimize CMS 
systems and processes to support better care for dually eligible 
individuals.
    Comment: One commenter supported requiring frequent exchanges of 
this data as a way to eliminate current inefficiencies and improve 
benefit coordination for the dually eligible population so long as this 
requirement does not impose additional reporting requirements on 
clinicians.
    Response: We appreciate the support for our proposal. We confirm 
that the regulation as proposed does not create additional reporting 
requirements on clinicians. As noted in the preamble to the CMS 
Interoperability and Patient Access proposed rule, we estimate that the 
change to a daily submission would result in a net reduction of burden 
for states, and further, reduce administrative complexity for 
beneficiaries and providers.
    Comment: One commenter noted that the proposed applicability date 
of April 1, 2022 will be sufficient for this change, but for overall 
unity in the rule's proposed changes, encouraged CMS to consider 
aligning the applicability date of this proposal with an overall 
extended implementation time frame of at least 2 years--and ideally 5 
years--for the remainder of the rule's provisions.
    Response: We appreciate the value in aligned implementation 
timelines. However, given that other provisions in this rule for health 
plans and states are distinct from this requirement, and will be 
required beginning in 2020, we continue to believe that the April 1, 
2022 implementation timeline proposed for daily exchange of buy-in data 
is appropriate.
    Comment: Commenters recommended that CMS establish a process for 
states to provide Medicare dual eligible special needs plans (D-SNPs) 
with, at a minimum, data on beneficiaries' Medicaid coverage. 
Commenters requested CMS align the eligibility and enrollment 
information that health plans receive with the information being shared 
between states and the federal government so there is a single ``source 
of truth'' on these data. Commenters noted this consistency is critical 
to improving care coordination for dually eligible individuals.
    Response: D-SNPs have an important role in supporting their 
enrollees' access to Medicaid benefits. We understand that in many 
states D-SNPs have limited access to timely data on Medicaid 
enrollment. We note that we do provide data to D-SNPs and other MA 
plans on the Medicaid status of their members. While we appreciate the 
value of D-SNPs getting additional Medicaid coverage data such as 
Medicaid plan enrollment, we decline to modify the regulations to 
require states to do so as it is beyond the scope of this proposal. 
However, we continue to explore opportunities to provide plans with 
data that would assist them in better coordinating benefits and 
coverage for their dually eligible enrollees.
    Comment: One commenter noted that the CMS Interoperability and 
Patient Access proposed rule does not require states to input the 
latest eligibility data in a specific timeframe on their claims 
platforms. The commenter noted that not having this clarity means that 
there could be a potential for inconsistent data. The commenter 
recommended that CMS require state Medicaid programs to update their 
claims platforms daily to assist with accurate data exchanges.
    Response: We appreciate the point the commenter is making. Our 
proposal did not explicitly address how states incorporate eligibility 
data with claims and other systems. We will consider this 
recommendation for the future as we gain additional experience with 
daily data exchange.
    Comment: Two commenters stated that daily exchange of buy-in data 
would require significant systems changes and costs. One of these 
commenters recommended that CMS revise the proposal to update the 
frequency of exchange from monthly to

[[Page 25572]]

weekly, rather than daily. The commenter noted that it would seldom 
have new information to send on a daily basis, but that determining on 
a daily basis whether there was any new information to send would be a 
large effort. Finally, the commenter requested if CMS finalized the 
regulation to require daily updates, that provisions be made for states 
whose systems cycles are other than within a calendar day, for example, 
6 p.m. to 6 a.m.
    Response: We appreciate the costs that the state may bear to make 
the systems changes necessary to implement these provisions. We will 
provide technical assistance and opportunities for shared learning 
through webinars and training to support states' transition.
    We also note that federal matching funds at the standard rate of 50 
percent for administration will reduce the states' costs. States may 
also be eligible for enhanced 90 percent federal matching funds for the 
costs of developing and implementing any necessary system changes 
required by regulation, and enhanced 75 percent federal matching funds 
for their system's maintenance and operation costs. These enhanced 
federal matching funds would be available for their Eligibility and 
Enrollment (E&E) systems (and, if necessary, their Medicaid Management 
Information System (MMIS)). States would request enhanced funding 
through the Advance Planning Document (APD) process.
    Even though there are costs to the states in implementing daily 
exchange of buy-in data, other commenters uniformly supported the value 
of daily exchanges in improving the experience of dually eligible 
individuals, and in reducing burden on states, providers, and plans to 
reconcile payment. As a result, we decline to make the suggested 
change.
    With respect to the point that there would often not be updates on 
a daily basis, we reiterate that no file would be required on business 
days where there were no updates. We expect that states would be able 
to automate their systems so that they check daily for changes to buy-
in status that would need to be submitted to CMS on the buy-in file, 
but also automate a process by which the system only generates a buy-in 
file upon identifying such a change. We appreciate the additional 
coding required to implement this logic but expect that once 
implemented, no additional interventions would be needed. We will work 
with states that have implemented these changes to identify and share 
best practices in identifying data changes to trigger daily 
submissions.
    Finally, in response to the concern about whether states that have 
an overnight processing cycle would be permitted to continue doing so, 
we affirm that the proposed regulation would permit this.
    After consideration of the public comments and for the reasons 
articulated in the CMS Interoperability and Patient Access proposed 
rule and our responses to comments, we are finalizing changes to 42 CFR 
406.26 and 407.40 as proposed.
3. Exchange of State MMA Data Files
    States submit data on files at least monthly to CMS to identify all 
dually eligible individuals, including full-benefit and partial-benefit 
dually eligible individuals (that is, those who get Medicaid help with 
Medicare premiums, and often for cost-sharing). The file is called the 
``MMA file,'' but is occasionally referred to as the ``State Phasedown 
file.'' The MMA file was originally developed to meet the need to 
timely identify dually eligible individuals for the then-new Medicare 
Part D prescription drug benefit. The Medicare Modernization Act (MMA) 
established that, beginning January 1, 2006, Medicare would be 
primarily responsible for prescription drug coverage for full-benefit 
dually eligible individuals; established auto-enrollment of full-
benefit dually eligible individuals into Medicare prescription drug 
plans (with regulations further establishing facilitated enrollment 
into prescription drug plans for partial-benefit dually eligible 
individuals), provided that dually eligible individuals are treated as 
eligible for the Medicare Part D Low Income Subsidy (LIS), sometimes 
called Extra Help; defined phased down state contributions to partly 
finance Part D costs for dually eligible individuals; and required 
risk-adjusting capitation payments for LIS (which include dually 
eligible) enrollees of Part D plans. To support these new requirements, 
we issued 42 CFR 423.910, establishing monthly reporting by states, in 
which states would submit, at least monthly, a data file identifying 
dually eligible individuals in their state. Over time, we used these 
files' data on dual eligibility status to support Part C capitation 
risk-adjustment, and most recently, to feed dual eligibility status to 
Part A and B eligibility and claims processing systems so providers, 
suppliers, and individuals have accurate information on beneficiary 
cost-sharing obligations.
    Currently, regulations require states to submit at least one MMA 
file each month. However, states have the option to submit multiple MMA 
files throughout the month (up to one per day). Most states submit MMA 
data files at least weekly. In the CMS Interoperability and Patient 
Access proposed rule, we estimated that 37 states and DC would need to 
make a system change to send MMA data to CMS daily (84 FR 7668). Based 
on more recent data, we estimate that 36 states and DC would require 
such system changes. As CMS now leverages MMA data on dual eligibility 
status into systems supporting all four parts of the Medicare program, 
it is becoming even more essential that dual eligibility status is 
accurate and up-to-date. Dual eligibility status can change at any time 
in a month. Waiting up to a month for status updates can negatively 
impact access to the correct level of benefit at the correct level of 
payment. Based on our experience with states that exchange data daily, 
more frequent MMA file submissions benefit states, individuals, and 
providers, in a number of ways. For a full discussion of the benefits, 
see the CMS Interoperability and Patient Access proposed rule (84 FR 
7644).
    As noted, current regulation requires that each state submit an MMA 
file at least monthly. We have implemented ``work-arounds'' for lags in 
dual eligibility status for Part D, including the ``Best Available 
Evidence'' policy (see 42 CFR 423.800(d)), as well as the Limited 
Income Newly Eligible Transition demonstration, which provides short 
term drug coverage for dually eligible individuals with no Part D plan 
enrollment in a given month (see Medicare Prescription Drug Benefit 
Manual, Chapter 3, Section 40.1.4).\50\ While these work-arounds 
provide needed protections, more frequent data exchanges would mitigate 
the need for them.
---------------------------------------------------------------------------

    \50\ Centers for Medicare and Medicaid Services. (2017). 
Medicare Prescription Drug Benefit Manual: Chapter 3--Eligibility, 
Enrollment and Disenrollment. Retrieved from https://www.cms.gov/Medicare/Eligibility-and-Enrollment/MedicarePresDrugEligEnrol/Downloads/CY_2018_PDP_Enrollment_and_Disenrollment_Guidance_6-15-17.pdf. (Last accessed June 24, 2019).
---------------------------------------------------------------------------

    Ensuring information on dual eligibility status is accurate and up-
to-date by increasing the frequency of federal-state data exchange is 
an important step in the path to interoperability. As a result, we 
proposed to update the frequency requirements in 42 CFR 423.910(d) to 
require that, starting April 1, 2022, all states submit the required 
MMA file data to CMS daily, and to make conforming edits to 42 CFR 
423.910(b)(1). Daily would mean every

[[Page 25573]]

business day, but that if no new transactions are available to 
transmit, states would not need to submit data on a given business day. 
We proposed requiring that states begin submitting these data daily to 
CMS by April 1, 2022 because we believed this applicability date would 
allow states to phase in any necessary operational changes or bundle 
them with any new systems implementation. We estimated an updated one-
time cost for a state to be $85,000 for this MMA data systems change. 
For a detailed discussion of the costs associated with these 
requirements, we refer readers to section XVI. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7660 through 
7673), as well as section XVI of this final rule. We sought comment on 
these proposals.
    We summarize the public comments we received on exchange of state 
MMA data files and provide our responses.
    Comment: Almost all those who commented on this provision supported 
the proposal to require all states to participate in daily submission 
of MMA file data with CMS by April 1, 2022. Commenters noted that the 
changes would improve the timeliness and accuracy of eligibility and 
enrollment data, enhance coordination of benefits, and support greater 
integration of care.
    Response: We appreciate the strong support for the proposed change 
to the regulation.
    Comment: One commenter supported the proposed change, but requested 
CMS consider standardizing which file types and data sets will be 
acceptable to support standardized daily submissions, for the overall 
purpose of improving the state and CMS data exchanges.
    Response: We understand the suggestion that we standardize which 
upstream data sets (for example, CMS finder files, state eligibility 
data) states should use to support daily MMA file submissions. To that 
end, we will provide technical assistance to states that need to make 
changes to submit the file daily. As part of that effort, we will work 
with states that already submit MMA files daily to understand and share 
information on best practices on the upstream data sets necessary to 
implement daily MMA file submissions.
    Comment: One commenter noted that the proposed applicability date 
of April 1, 2022 will be sufficient for this change, but for overall 
unity in the rule's proposed changes, encouraged CMS to consider 
aligning the effective date of this proposal with an overall extended 
implementation time frame of at least 2 years--and ideally 5 years--for 
the remainder of the rule's provisions.
    Response: We appreciate the value in aligned implementation 
timelines. However, given that other provisions in this rule for health 
plans and states are distinct from this requirement, and will be 
required beginning in 2020, we continue to believe that the April 1, 
2022 implementation timeline proposed for daily MMA file submissions is 
appropriate.
    Comment: A few commenters noted the value of the data in the MMA 
file to Medicaid managed care organizations (MCO), Medicare dual 
eligible special needs plans (D-SNPs), Health Information Exchanges, 
and providers for the purposes of coordinating enrollment, benefits, 
and/or care for dually eligible individuals. These commenters requested 
access to the daily MMA file. One commenter noted that some states are 
sharing Medicare plan enrolment data from these files with their 
Medicaid MCOs while also providing batch inquiry data sharing 
mechanisms to D-SNPs on Medicaid plan enrollment. This commenter 
recommended that CMS encourage or require all states to follow this 
process at a minimum.
    Commenters also encouraged CMS to leverage the MMA file to support 
parties complying with the D-SNP integration standards recently issued 
in 42 CFR 422.2.
    Response: We appreciate these suggestions to promote access to data 
for plans and providers serving dually eligible individuals, and we 
will explore these ideas further for potential future consideration. 
However, we decline to modify the regulation as suggested, as the 
recommended changes are beyond the scope of the proposal, which is 
limited to the frequency of the file exchange.
    Comment: A few commenters made additional suggestions for 
streamlining data exchanges. In addition to making the MMA files 
accessible to plans and providers, some commenters recommended adding 
Medicaid plan enrollment information to MMA files to create a single 
source of Medicare-Medicaid enrollment data for dually eligible 
individuals. Another commenter suggested a potential pathway to 
streamlining data exchanges would be for CMS to allow state Transformed 
Medicaid Statistical Information System (T-MSIS) files to serve as the 
beneficiary data source for third-party applications.
    Response: We appreciate the value of streamlining data exchanges, 
including access to a consistent data source on eligibility and 
enrollment. We also acknowledge the overlap of certain data exchanged 
in the MMA and T-MSIS file, though we note we would need to carefully 
explore the implications and impacts of merging operational data 
exchanges such as the MMA file--which result in changes to an 
individual's Medicare benefit--with informational exchanges such as T-
MSIS. We will consider exploring these opportunities further for 
potential future consideration. However, we decline to modify the 
regulation as suggested, as the recommended changes are beyond the 
scope of the proposal, which is limited to the frequency of the file 
exchange.
    Comment: Several commenters noted significant system changes and 
cost to update the frequency of exchanging MMA files to daily. One 
commenter stated that they believe HHS has underestimated the cost to 
upgrade the MMA system to support daily exchange. The commenter 
encouraged CMS to provide an updated estimate for the costs to upgrade 
the system that include additional operational costs. This commenter 
and others encouraged CMS to consider providing additional funding to 
state Medicaid programs that will need to upgrade their data systems. 
One commenter questioned if CMS would consider increasing the FMAP 
states receive for interoperability activities that support dual 
eligible plans integrations and in particular, for programmatic or 
systems changes to come into compliance with D-SNP integration. The 
commenter noted that this increase could exceed existing enhanced 
matches, for example allowing the 90 percent match to apply for ongoing 
systems operations that facilitate care coordination.
    Response: We appreciate the input on the level of effort needed to 
submit the MMA file daily. As noted elsewhere, we will provide 
technical assistance and opportunities for shared learning through 
webinars and training to support states' transition. We also note that 
federal matching funds of 50 percent for administration will reduce the 
states' costs. States may also be eligible for enhanced 90 percent 
federal matching funds for the costs of developing and implementing any 
necessary system changes required by regulation, and enhanced 75 
percent federal matching funds for their system's maintenance and 
operation costs. These enhanced federal matching funds would be 
available for their Eligibility and Enrollment systems (and, if 
necessary, their Medicaid Management Information System (MMIS)). States 
would request enhanced funding through the Advance Planning Document 
(APD) process.

[[Page 25574]]

    As commenters did not provide specific information on the costs in 
excess of our assessment, we find that we have no basis to make a 
reasonable adjustment. As such, we are maintaining our estimate of the 
number of hours required, as detailed in sections XII. and XIII. of 
this final rule.
    Comment: One commenter opposed increasing states submission of the 
MMA file from monthly to daily, recommending instead that the frequency 
be increased to weekly. The commenter stated that determining on a 
daily basis whether there was any new information to send would be a 
significant effort, as multiple upstream systems may have to be 
changed, and further, that there would seldom be new data to send on a 
daily basis. The commenter requested that if CMS finalized the 
regulation to require daily exchanges that states be permitted to 
continue to existing processing cycles that cross business, for 
example, run overnight between 6:00 p.m. to 6:00 a.m.
    Response: We acknowledge the commenter's concerns about resources, 
but note that other commenters--even those who echoed concerns about 
resources--uniformly supported the value of daily exchanges in 
improving the experience of dually eligible individuals and the ability 
of providers and plans to coordinate eligibility, enrollment, benefits, 
and/or care for this population. As we note above, we are committed to 
providing technical assistance and federal matching funds to support 
needed systems changes at the state. As a result, we decline to make 
the recommended change.
    With respect to the point that there would not be updates on a 
daily basis, we reiterate that no file would be required on business 
days when there were no updates. We expect that states would be able to 
automate their systems so that they check daily for changes to data 
that would need to be submitted to CMS on the MMA file, but also 
automate a process by which the system only generates an MMA file upon 
identifying such a change. We appreciate the additional coding required 
to implement this logic but that that once implemented, no additional 
interventions would be needed. We will work with states that have 
implemented these changes to identify and share best practices in 
identifying data changes to trigger daily submissions.
    Finally, in response to the concern about states that have an 
overnight processing cycle to continue so to meet the definition of 
``daily,'' the proposed regulation would permit this.
    After consideration of the public comments and for the reasons 
articulated in the CMS Interoperability and Patient Access proposed 
rule and our responses to comments, we are finalizing 42 CFR 423.910 as 
proposed.

B. Request for Stakeholder Input

    In addition to the proposals discussed above, we sought public 
comment for consideration in potential future rulemaking on how we can 
achieve greater interoperability of federal-state data for dually 
eligible individuals, including in the areas of program integrity and 
care coordination, coordination of benefits and crossover claims, 
beneficiary eligibility and enrollment, and their underlying data 
infrastructure. For more information on our request for comment, see 
the CMS Interoperability and Patient Access proposed rule (84 FR 7645). 
We thank commenters for their input. We will consider the information 
received for potential future rulemaking.
    Final Action: We will require all states to participate in daily 
exchange of buy-in data, which includes both sending data to CMS and 
receiving responses from CMS daily, and require all states submit the 
required MMA file data to CMS daily by April 1, 2022. These policies 
are being finalized in 42 CFR 406.26, 407.40, and 423.910, 
respectively, as proposed. These requirements will improve the 
experience of dually eligible individuals and the ability of providers 
and payers to coordinate eligibility, enrollment, benefits, and/or care 
for this population. Federal matching funds of 50 percent for 
administration are available to support states' costs. States may also 
be eligible for enhanced 90 percent federal matching funds for the 
costs of developing and implementing any necessary system changes 
required by this regulation, and enhanced 75 percent federal matching 
funds for their system's maintenance and operation costs. CMS will 
provide technical assistance to the states that need to make changes to 
submit their files daily, including best practices on the upstream data 
sets necessary to implement daily MMA file submissions.

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

A. Information Blocking Background

1. Legislative Background and Policy Considerations
    The nature and extent of information blocking has come into focus 
in recent years. In 2015, at the request of the Congress, ONC submitted 
a Report on Health Information Blocking \51\ (hereinafter referred to 
as the ``Information Blocking Congressional Report''), in which ONC 
commented on the then current state of technology, health IT, and 
health care markets. Notably, ONC observed that prevailing market 
conditions create incentives for some individuals and entities to 
exercise their control over electronic health information in ways that 
limit its availability and use. Since that time, ONC and other 
divisions of HHS have continued to receive feedback from patients, 
clinicians, health care executives, payers, app developers and other 
technology companies, registries and health information exchanges, 
professional and trade associations, and many other stakeholders 
regarding practices which may constitute information blocking. Despite 
significant public and private sector efforts to improve 
interoperability and data liquidity, engagement with stakeholders 
confirms that adverse incentives remain and continue to undermine 
progress toward a more connected health system.
---------------------------------------------------------------------------

    \51\ Office of the National Coordinator. (2015, April 9). Report 
to Congress on Health Information Blocking. Retrieved from https://www.healthit.gov/sites/default/files/reports/info_blocking_040915.pdf.
---------------------------------------------------------------------------

    Based on these economic realities and first-hand experience working 
with the health IT industry and stakeholders, ONC concluded in the 
Information Blocking Congressional Report that information blocking is 
a serious problem and recommended that the Congress prohibit 
information blocking and provide penalties and enforcement mechanisms 
to deter these harmful practices.
    MACRA became law in the same month that the Information Blocking 
Congressional Report was published. Section 106(b)(2)(A) of MACRA 
amended section 1848(o)(2)(A)(ii) of the Act to require that an 
eligible professional must demonstrate that he or she has not knowingly 
and willfully taken action (such as to disable functionality) to limit 
or restrict the compatibility or interoperability of certified EHR 
technology, as part of being a meaningful EHR user. Section 
106(b)(2)(B) of MACRA made corresponding amendments to section 
1886(n)(3)(A)(ii) of the Act for eligible hospitals and, by extension, 
under section 1814(l)(3) of the Act for CAHs. Sections 106(b)(2)(A) and 
(B) of MACRA provide that the manner of this demonstration is to be 
through a process specified by the Secretary, such as the use of an 
attestation. To implement these provisions, as discussed further

[[Page 25575]]

below, we established and codified attestation requirements to support 
the prevention of information blocking, which consist of three 
statements containing specific representations about a health care 
provider's implementation and use of CEHRT. To review our discussion of 
these requirements, we refer readers to the CY 2017 Quality Payment 
Program final rule (81 FR 77028 through 77035).
    Recent empirical and economic research further underscores the 
complexity of the information blocking problem and its harmful effects. 
For a full discussion of the research, see the CMS Interoperability and 
Patient Access proposed rule (84 FR 7645 through 7646).
    In December 2016, section 4004 of the Cures Act added section 3022 
of the PHSA (the ``PHSA information blocking provision''), which 
defines conduct by health care providers, health IT developers, and 
health information exchanges and networks that constitutes information 
blocking. The PHSA information blocking provision was enacted in 
response to ongoing concerns that some individuals and entities are 
engaging in practices that unreasonably limit the availability and use 
of electronic health information for authorized and permitted purposes 
(see the definition of electronic health information proposed by ONC 
for HHS adoption at 45 CFR 171.102 (84 FR 7588)). These practices 
undermine public and private sector investments in the nation's health 
IT infrastructure and frustrate efforts to use modern technologies to 
improve health care quality and efficiency, accelerate research and 
innovation, and provide greater value and choice to health care 
consumers.
    The information blocking provision defines and creates possible 
penalties and disincentives for information blocking in broad terms, 
working to deter the entire spectrum of practices likely to interfere 
with, prevent, or materially discourage access, exchange, or use of 
electronic health information. The PHSA information blocking provision 
applies to health care providers, health IT developers, exchanges, and 
networks. The information blocking provision also provides that the 
``Secretary, through rulemaking, shall identify reasonable and 
necessary activities that do not constitute information blocking for 
purposes of the definition at section 3022(a)(1) of the PHSA.'' ONC's 
21st Century Cures Act proposed rule proposed ``exceptions'' to the 
information blocking provision. These exceptions are reasonable and 
necessary activities that would not constitute information blocking. In 
addition to the attestation discussed in this section, all health care 
providers would also be subject to the separate information blocking 
regulations proposed by ONC for HHS adoption at 45 CFR part 171 (84 FR 
7601 through 7605).

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

    Physician Compare (https://www.medicare.gov/physiciancompare) draws 
its operating authority from section 10331(a)(1) of the Affordable Care 
Act. Consistent with section 10331(a)(2) of the Affordable Care Act, 
Physician Compare initiated a phased approach to publicly reporting 
performance scores that provide comparable information on quality and 
patient experience measures. A complete history of public reporting on 
Physician Compare is detailed in the CY 2016 Physician Fee Schedule 
(PFS) final rule with comment period (80 FR 71117 through 71122). More 
information about Physician Compare, including the history of public 
reporting and regular updates about what information is currently 
available, can also be accessed on the Physician Compare Initiative 
website at https://www.cms.gov/medicare/quality-initiatives-patient-assessment-instruments/physician-compare-initiative/.
    As discussed in the CY 2018 Quality Payment Program final rule (82 
FR 53820), Physician Compare has continued to pursue a phased approach 
to public reporting under MACRA in accordance with section 1848(q)(9) 
of the Act. For a discussion of public reporting on Physician Compare, 
see the CMS Interoperability and Patient Access proposed rule (84 FR 
7646 through 7647).
    Building upon the continuation of our phased approach to public 
reporting and understanding the importance of preventing information 
blocking, promoting interoperability, and the sharing of information, 
we proposed to make certain data about the attestation statements on 
the prevention of information blocking referenced in the CMS 
Interoperability and Patient Access proposed rule (84 FR 7645) 
available for public reporting on Physician Compare, drawing upon our 
authority under section 10331(a)(2) of Affordable Care Act, which 
required us to make publicly available on Physician Compare information 
on physician performance that provides comparable information for the 
public on quality and patient experience measures. Section 10331(a)(2) 
of the Affordable Care Act provided that to the extent scientifically 
sound measures that are developed consistent with the requirements of 
section 10331 of the Affordable Care Act are available, such 
information shall include, to the extent practicable, an assessment of 
the coordination of care and other information as determined 
appropriate by the Secretary. We noted our belief that section 
10331(a)(2) of the Affordable Care Act provided the statutory authority 
to publicly report certain data about the prevention of information 
blocking attestation statements as an assessment of care coordination 
and as other information determined appropriate by the Secretary. 
Furthermore, the prevention of information blocking attestation 
statements are required for a clinician to earn a Promoting 
Interoperability performance category score, which is then incorporated 
into the final score for MIPS, and we are required to publicly report 
both of these scores under section 1848(q)(9)(A) of the Act. Publicly 
posting this information as an indicator is consistent with our 
finalized policy to publicly report, either on the profile pages or in 
the downloadable database, other aspects of the Promoting 
Interoperability performance category, such as objectives, activities, 
or measures specified in the CY 2018 Quality Payment Program final rule 
(82 FR 53826 through 53827). We note that we finalized at 42 CFR 
414.1395(b), that, with the exception of data that must be mandatorily 
reported on Physician Compare, for each program year, we rely on the 
established public reporting standards to guide the information 
available for inclusion on Physician Compare. The public reporting 
standards require data included on Physician Compare to be 
statistically valid, reliable, and accurate; be comparable across 
submission mechanisms; and, meet the reliability threshold. To be 
included on the public facing profile pages, the data must also 
resonate with website users, as determined by CMS.
    There are three prevention of information blocking attestation 
statements under 42 CFR 414.1375(b)(3)(ii)(A) through (C) to which 
eligible clinicians reporting on the Promoting Interoperability 
performance category of MIPS must attest. To report successfully on the 
Promoting Interoperability performance category, in addition to 
satisfying other requirements, an eligible clinician must submit an 
attestation response of ``yes'' for each of these statements. For more 
information about these statements, we refer readers to the preamble 
discussion

[[Page 25576]]

in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 
81 FR 77035).
    The Promoting Interoperability performance category weight 
comprises 25 percent of a MIPS eligible clinician's final score for 
each MIPS payment year, as specified at 42 CFR 414.1375(a). As 
specified at 42 CFR 414.1405(b)(2), MIPS eligible clinicians with a 
final score below the performance threshold receive a negative MIPS 
payment adjustment factor on a linear sliding scale. Certain MIPS 
eligible clinicians who submit data for the Promoting Interoperability 
performance category may be eligible for reweighting, as specified 
under 42 CFR 414.1380(c)(2). As specified at 42 CFR 414.1405(a), 
(b)(1), and (b)(2), MIPS eligible clinicians may receive a positive, 
neutral, or negative MIPS payment adjustment factor. As specified at 42 
CFR 414.1405(c), the applicable percent for MIPS payment year 2021 is 7 
percent. For MIPS payment year 2022, and each subsequent MIPS payment 
year, it is 9 percent. For more information about the MIPS, we refer 
readers to the preamble discussion in the CY 2020 Quality Payment 
Program final rule (84 FR 62946 through 63083).
    We noted our belief that it would benefit the public to know if 
eligible clinicians have attested negatively to the statements under 42 
CFR 414.1375(b)(3)(ii) as this may assist the patient in selecting a 
clinician or group who collaborates with other clinicians, groups, or 
other types of health care providers by sharing information 
electronically, and does not withhold information that may result in 
better care. Therefore, we proposed to include an indicator on 
Physician Compare for the eligible clinicians and groups that submit a 
``no'' response to any of the three statements under 42 CFR 
414.1375(b)(3)(ii)(A) through (C). In the event that these statements 
are left blank, that is, a ``yes'' or a ``no'' response is not 
submitted, the attestations would be considered incomplete, and we 
would not include an indicator on Physician Compare. We also proposed 
to post this indicator on Physician Compare, either on the profile 
pages or the downloadable database, as feasible and appropriate, 
starting with the 2019 performance period data available for public 
reporting starting in late 2020. We refer readers to the 2019 Promoting 
Interoperability Information Blocking Factsheet at https://qpp-cm-prod-content.s3.amazonaws.com/uploads/282/2019%20PI%20Information%20Blocking%20Fact%20Sheet.pdf for more 
information about the attestation statements.
    Under 42 CFR 414.1395(b), these data must meet our established 
public reporting standards, including that to be included on the public 
facing profile pages, the data must resonate with website users, as 
determined by CMS. In previous testing with patients and caregivers, we 
learned that effective use of CEHRT is important to them when making 
informed health care decisions. For more information about previous 
testing with patients and caregivers, we refer readers to the Physician 
Compare Technical Expert Panel (TEP) Summary Report at https://www.cms.gov/Medicare/Quality-Initiatives-Patient-Assessment-Instruments/physician-compare-initiative/Downloads/Physician-Compare-TEP-Summary-2018.pdf. To determine how to best display and meaningfully 
communicate the indicator on the Physician Compare website, the exact 
wording and, if applicable, profile page indicator would be determined 
after user testing and shared with stakeholders through the Physician 
Compare Initiative page, listservs, webinars, and other available 
communication channels. We noted that the proposal was contingent upon 
the availability of and technical feasibility to use the data for 
public reporting.
    We summarize the public comments we received on this topic and 
provide our responses.
    Comment: Most commenters supported our proposal to publicly report 
an indicator on the Physician Compare website for the eligible 
clinicians and groups that submit a ``no'' response to any of the three 
prevention of information blocking attestation statements, noting that 
the indicator would discourage clinicians and groups from information 
blocking and help Medicare patients and caregivers make informed health 
care decisions.
    Response: We thank commenters for their support and agree that 
publicly reporting an indicator on Physician Compare will discourage 
clinicians and groups from information blocking and help Medicare 
patients and caregivers make informed decisions.
    Comment: Some commenters expressed concern for various reasons 
about publicly reporting an indicator on the Physician Compare website 
for the eligible clinicians and groups that submit a ``no'' response to 
any of the three prevention of information blocking attestation 
statements. Several of these commenters thought the indicator would be 
redundant, since there is already an incentive for clinicians to attest 
to the prevention of information blocking statements in order to earn a 
MIPS Promoting Interoperability performance category score. Some 
commenters were concerned that an indicator may not accurately reflect 
whether a clinician or group is knowingly or willfully information 
blocking, since they may be confused about the attestation statements' 
meanings. A few commenters suggested delaying Physician Compare's 
indicator implementation in order to give clinicians and groups, 
particularly small and rural practices, time to become more familiar 
with the attestations. Other commenters expressed concern as to whether 
Medicare patients and caregivers would find the indicator useful; one 
of these commenters suggested conducting a pilot study to make such a 
determination. Finally, several commenters suggested an appeal process 
or an opportunity for clinicians and groups to review their information 
prior to public reporting.
    Response: We appreciate the commenters' concerns. We believe 
publicly reporting an indicator on Physician Compare for the eligible 
clinicians and groups that submit a ``no'' response to any of the three 
prevention of information blocking attestation statements is not 
redundant, as Medicare patients and caregivers do not currently have 
access to this type of information, which could aid them in making 
informed health care decisions.
    Regarding concerns about clinicians, including small and rural 
practices, needing time to become familiar with the attestations, we 
believe there has been sufficient time for clinicians to become 
familiar with them, since these attestation statements have been a MIPS 
Promoting Interoperability performance category requirement since the 
2017 performance period. We also believe that webinars and educational 
materials that CMS has made available have provided clinicians and 
groups an opportunity to become familiar with the information blocking 
attestation statements. We will also continue to support small and 
rural practices by offering free and customized resources available 
within local communities, including direct, one-on-one support from the 
Small, Underserved, and Rural Support Initiative along with our other 
no-cost technical assistance (83 FR 59720). Regarding whether an 
information blocking indicator would be meaningful to patients and 
caregivers, we note that under 42 CFR 414.1395(b), these data must meet 
our established public reporting standards, including that to be posted 
on public facing profile pages, the data must resonate with website 
users, as determined by CMS. Such user testing to date has shown that

[[Page 25577]]

effective CEHRT usage is important to patients when making health care 
decisions. In addition, as specified at 42 CFR 414.1375(b)(3)(ii), MIPS 
eligible clinicians must attest to the prevention of information 
blocking statements. For more information about these statements, we 
refer readers to the preamble discussion in the CY 2017 Quality Payment 
Program final rule (81 FR 77028 through 81 FR 77035). In addition, we 
note that section 4004 of the Cures Act added section 3022 of the PHSA, 
which directs HHS to identify reasonable and necessary activities 
conducted by health care providers, health IT developers, and health 
information exchanges and networks that would not constitute 
information blocking as defined in section 3022. For more information, 
see the information blocking discussion in ONC's 21st Century Cures Act 
final rule (published elsewhere in this issue of the Federal Register).
    While we appreciate the commenter's suggestion to conduct a pilot 
study, we believe that further user testing will allow us to gain the 
additional understanding necessary.
    Regarding the comments requesting an opportunity to review or an 
appeal process, we note that, under 42 CFR 414.1395(d), for each 
program year, CMS provides a 30-day preview period for any clinician or 
group with Quality Payment Program data before the data are publicly 
reported on Physician Compare. Although at this time we do not preview 
indicator information, clinicians and groups will be able to preview 
their Promoting Interoperability performance category information, 
including their attestation responses to the three statements during 
the MIPS targeted review process. All performance data publicly 
reported on Physician Compare will reflect the scores eligible 
clinicians and groups receive in their MIPS performance feedback, which 
will be available for review and potential correction during the 
targeted review process (83 FR 59912).
    Comment: Many commenters recommended additional actions to prevent 
information blocking, beyond publicly reporting an indicator on 
Physician Compare. Some commenters recommended implementing additional 
penalties for clinicians and groups that attest ``no'' to the 
prevention of information blocking attestations, such as corrective 
action. Other commenters suggested CMS offer more positive incentives. 
Several commenters suggested having additional indicators, such a 
positive one for those who attest ``yes.'' Another commenter 
recommended treating a blank response to the three attestation 
statements as a ``no'' response. A few commenters recommended that the 
proposed indicator not be used for clinicians and groups that 
participate in trusted exchange networks.
    Response: We appreciate commenters' suggestions and will consider 
them for potential future rulemaking, to the extent permitted by our 
authority. To the extent of our authority, we will consider treatment 
of attestation statements that are left blank, use of a positive 
indicator on the Physician Compare profile pages or downloadable 
database, and the use of the proposed indicator for clinicians and 
groups that participate in trusted exchange networks for potential 
future rulemaking.
    Regarding commenters' suggestions for additional penalties, we note 
that section 4004 of the Cures Act identifies potential penalties and 
disincentives for information blocking. Health care providers 
determined by the Inspector General to have committed information 
blocking shall be referred to the appropriate agency to be subject to 
appropriate disincentives using authorities under applicable federal 
law, as the Secretary sets forth through notice and comment rulemaking. 
In the ONC 21st Century Cures Act proposed rule, a request for 
information regarding disincentives for health care providers was 
included (84 FR 7553).
    Comment: Some commenters requested additional information on the 
proposed information blocking indicator. A few of these commenters 
requested additional information on the attestation requirements for 
clinicians and groups participating in other programs, such as Medicare 
Advantage. Several commenters requested additional guidance on 
exceptions to the attestations. Another commenter requested more 
information on the implications for clinicians and groups who leave the 
attestation statements blank and do not attest ``yes'' or ``no.'' 
Several commenters questioned how clinicians' responses to the three 
attestation statements would be verified for accuracy.
    Response: The three attestation statements are required under the 
MIPS, which is a Medicare FFS program. We note that 42 CFR 414.1310(b) 
and (c) provide that Qualifying APM Participants (QPs) and Partial QPs 
who do not report on applicable measures and activities that are 
required to be reported under MIPS for any given performance period in 
a year are excluded from this definition at 42 CFR 414.1305 of a MIPS 
eligible clinician per the statutory exclusions defined in section 
1848(q)(1)(C)(ii) and (v) of the Act. Therefore, the prevention of 
information blocking indicator would be applicable only to MIPS 
eligible clinicians and groups under Medicare FFS and not to other 
programs, such as MA. Under MIPS, the attestation statements are 
required for all eligible clinicians under the Promoting 
Interoperability performance category of MIPS, as specified at 42 CFR 
414.1375(b)(3)(ii) (81 FR 77035). If the attestation statements are 
left blank, that is, a ``yes'' or ``no'' response is not submitted, the 
attestations would be considered incomplete and the clinician or group 
would not receive a Promoting Interoperability performance category 
score. In this situation, we would not have an affirmative or negative 
response to the three attestation statements from the clinician or 
group, and we would not have enough information to determine whether 
the clinician or group is knowingly and willfully information blocking. 
Regarding exceptions to the attestation requirements, under 42 CFR 
414.1380(c)(2) the Promoting Interoperability performance category may 
be reweighted to zero percent of the final score for a MIPS eligible 
clinician in certain circumstances, and clinicians who receive 
reweighting would not have to submit data for the Promoting 
Interoperability performance category, including their responses to the 
attestation statements. Regarding verification of clinicians' 
attestation statements, we note that we finalized in prior rulemaking 
that we will perform ongoing monitoring of MIPS eligible clinicians and 
groups on an ongoing basis for data validation, auditing, program 
integrity issues, and instances of non-compliance with MIPS 
requirements. If a MIPS eligible clinician or group is found to have 
submitted inaccurate data for MIPS, we finalized that we would reopen 
and revise the determination in accordance with the rules set forth at 
42 CFR 405.980 through 405.986 (81 FR 77362).
    Final Action: After consideration of the comments received, and for 
the reasons outlined in our responses to these comments, we are 
finalizing this policy as proposed. Specifically, we are finalizing to 
include an indicator on Physician Compare for the eligible clinicians 
and groups that submit a ``no'' response to any of the three prevention 
of information blocking attestation statements for MIPS under 42 CFR 
414.1375(b)(3)(ii)(A) through (C), as proposed. In the event that these 
statements are left blank, that is, a ``yes''

[[Page 25578]]

or a ``no'' response is not submitted, the attestations will be 
considered incomplete, and we will not include an indicator on 
Physician Compare. We will post this indicator on Physician Compare, 
either on the profile pages or in the downloadable database, as 
feasible and appropriate, starting with the 2019 performance period 
data available for public reporting starting in late 2020.

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

    Section 1886(n)(4)(B) of the Act requires the Secretary to post in 
an easily understandable format a list of the names and other relevant 
data, as determined appropriate by the Secretary, of eligible hospitals 
and CAHs who are meaningful EHR users under the Medicare FFS program, 
on a CMS website. In addition, that section requires the Secretary to 
ensure that an eligible hospital or CAH has the opportunity to review 
the other relevant data that are to be made public with respect to the 
eligible hospital or CAH prior to such data being made public. We noted 
in the CMS Interoperability and Patient Access proposed rule (84 FR 
7647) that we believed certain information related to the prevention of 
information blocking attestation statements under 42 CFR 
495.40(b)(2)(i)(I)(1) through (3) would constitute other relevant data 
under section 1886(n)(4)(B) of the Act. Specifically, we referred to 
the three prevention of information blocking attestation statements 
under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) to which eligible 
hospitals and CAHs must attest for purposes of the Promoting 
Interoperability Program. As part of successfully demonstrating that an 
eligible hospital or CAH is a meaningful EHR user for purposes of the 
Promoting Interoperability Program, the eligible hospital or CAH must 
submit an attestation response of ``yes'' for each of these statements. 
For more information about these statements, we referred readers to the 
preamble discussion in the CY 2017 Quality Payment Program final rule 
(81 FR 77028 through 77035).
    We noted in the CMS Interoperability and Patient Access proposed 
rule (84 FR 7647) that we believed it would be relevant to the public 
to know if eligible hospitals and CAHs have attested negatively to the 
statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) as it could 
indicate that they are knowingly and unreasonably interfering with the 
exchange or use of electronic health information in ways that limit its 
availability and use to improve health care. As we stated in the CY 
2017 Quality Payment Program final rule, we believed that addressing 
issues related to information blocking would require additional and 
more comprehensive measures (81 FR 77029). In addition, publicly 
posting this information would reinforce our commitment to focus on 
increased interoperability and the appropriate exchange of health 
information. We proposed to post information on a CMS website available 
to the public indicating that an eligible hospital or CAH attesting 
under the Medicare FFS Promoting Interoperability Program submitted a 
``no'' response to any of the three statements under 42 CFR 
495.40(b)(2)(i)(I)(1) through (3). In the event that these statements 
are left blank, that is, a ``yes'' or a ``no'' response is not 
submitted, we proposed the attestations would be considered incomplete, 
and we would not post any information related to these attestation 
statements for that hospital or CAH. We proposed to post this 
information starting with the attestations for the EHR reporting period 
in 2019, and we expected the information would be posted in late 2020. 
In accordance with section 1886(n)(4)(B) of the Act, we proposed to 
establish a process for each eligible hospital and CAH to review the 
information related to their specific prevention of information 
blocking attestation statements before it is publicly posted on a CMS 
website. Specifically, for each program year, we proposed a 30-day 
preview period for an eligible hospital or CAH to review this 
information before it is publicly posted. During the 30-day preview 
period, we proposed that all of the information that we would publicly 
post would be available for the eligible hospital or CAH to review, and 
we would consider making changes to the information on a case-by-case 
basis (for example, in the event the eligible hospital or CAH 
identifies an error, and we subsequently determine that the information 
is not accurate). Additional information on the review process would be 
provided outside of the rulemaking process through the usual 
communication channels for the program.
    We summarize the public comments we received on this topic and 
provide our responses.
    Comment: Many commenters indicated their strong support for this 
proposal and suggested that we finalize the proposal, as commenters 
believe it is necessary in building an interoperable health system. One 
commenter believes that maintaining accountability and enforcing 
penalties is critical to maintaining individual health and safety. 
Another commenter agreed, stating that information blocking is 
detrimental to the health, safety, and welfare of patients. Many 
commenters indicated that information blocking should not be tolerated 
for competitive or financial reasons, further indicating that consumers 
and stakeholders should be made aware of those who participate in 
information blocking practices, as this transparency can prevent 
potential medical errors and improve the overall quality of care.
    Response: We thank commenters for their support for the proposal. 
We agree with the commenters and believe that the proposed policy would 
be both appropriate and effective in reinforcing our commitment to 
focus on increasing interoperability and the appropriate exchange of 
health information. Knowingly or willfully preventing, avoiding, or 
withholding information limits interoperability and prevents the 
sharing of important health information.
    Comment: Many commenters indicated support for the promotion of 
health information exchange and the prevention of information blocking, 
generally, but expressed several concerns about the implementation of 
this proposal. A couple of commenters were concerned that there is not 
enough time to develop the policies and procedures needed to streamline 
the proposed process, and in response, suggested building in a period 
of non-enforcement (a practice period without posting any information 
publicly). Several commenters expressed concern that there will not be 
an opportunity to dispute information prior to publication, and 
requested including a guarantee of the proposed 30-day preview period 
prior to the publication of certain information on a CMS website. 
Finally, commenters had concerns about how policies related to 
information blocking and changes to the 2015 Edition of certified 
health IT proposed in ONC's 21st Century Cures Act proposed rule may 
impact the prevention of information blocking attestations under the 
Promoting Interoperability Program.
    Response: We appreciate the commenters' concerns and suggestions. 
We are finalizing the proposal to post this information starting with 
the attestations for the EHR reporting period in 2019, and we are 
targeting for this information to be posted in late 2020. Although we 
will not have a period of non-enforcement (postponing posting of 
information publicly), we are building in a 30-day preview period 
during which any discrepancies or concerns may be addressed on a case-
by-case

[[Page 25579]]

basis prior to posting. Additional information on the preview period 
will be provided outside of the rulemaking process through the usual 
communication channels for the program. With regard to ONC's 21st 
Century Cures Act rule, the prevention of information blocking 
attestation statements under the Promoting Interoperability Program are 
not affected by ONC's final rule policies and remain unchanged.
    Comment: A number of commenters supported the prevention of 
information blocking, but had concerns about the additional burden this 
proposal may add. One commenter requested reassurance that this process 
will not increase burden, while a few other commenters shared concerns 
that this process will increase burden.
    Response: We appreciate the commenters' concerns. As eligible 
hospitals and CAHs are already required to respond to these three 
attestation statements under the Promoting Interoperability Program, we 
do not believe this proposal would require additional reporting effort, 
or thereby increase burden. We do not believe the 30-day preview period 
would increase burden as it will be an opportunity for eligible 
hospitals and CAHs to ensure the accuracy of the information that will 
be posted publicly, should they choose to take advantage of this 
opportunity.
    Comment: Many commenters stated that there should be an audit or 
spot check process to validate the responses provided to the three 
attestation statements. Commenters indicated concern that those who 
knowingly participate in information blocking practices will answer 
`yes' to the three attestation statements simply to complete the 
question/answer sequencing in the reporting system. Further, commenters 
expressed concern regarding how easy it could be for their peers to 
respond dishonestly, and requested more stringent auditing practices 
from CMS. A number of commenters requested additional information on 
how a ``blank'' response would be treated for purposes of this 
proposal; one commenter believed that a ``blank'' should be considered 
a ``no'', and another commenter believed that a ``blank'' should simply 
be considered as a ``blank.''
    Response: We appreciate the commenters' concerns. We do not have a 
specific auditing practice in place for these specific attestation 
statements. Instead, all eligible hospitals and CAHs are required to 
submit responses to the attestation statements under the Promoting 
Interoperability Program and must respond accurately, as any eligible 
hospital or CAH participating in the Promoting Interoperability Program 
may be subject to an audit. In the event that an eligible hospital or 
CAH leaves a ``blank'' response to an attestation statement, where a 
``yes'' or a ``no'' response is not submitted, the response would be 
considered incomplete, and no information would be posted related to 
these attestation statements at this time.
    Comment: Many commenters supported the effort to prevent 
information blocking, though several believed that posting certain 
information on a CMS website of those who attest `no' to the prevention 
of information blocking statements may not strongly impact the issue. 
Of the reasons given, one commenter remained agnostic on whether such a 
policy would have tangible success in deterring information blocking, 
several commenters stated that the information posted on a CMS website 
will have little meaning to consumers, and others believed that this 
process would not promote interoperability nor would it improve patient 
access to information.
    Response: We appreciate all of the commenters' concerns. As 
discussed in the CY 2017 Quality Payment Program Final Rule (81 FR 
77029), the act of information blocking is a systemic problem that 
Congress has expressed concerns about. Growing evidence has established 
that there is a strong incentive for health care providers to 
unreasonably interfere with the exchange of health information. We 
believe that publicly posting certain information on a CMS website is 
one valuable tool in our continued effort to deter these information 
blocking practices.
    As patients gain access to more data, they become more empowered 
and more informed decision makers. Knowing if a physician may be 
information blocking could influence their decision to see that 
physician. In addition, knowing patients can see this information may 
deter physicians from engaging in this behavior. For these reasons, we 
do believe that this effort will have an impact and be meaningful to 
consumers. We do also believe that this policy will promote 
interoperability and improve patient access to information. With 
patients becoming more empowered, this drives health care providers to 
move toward information sharing rather than information blocking, which 
directly leads to improved patient access to information.
    Comment: A couple commenters suggested moving away from posting 
public information, and instead focusing on creating positive incentive 
programs, enhancing guidance, providing more education, and fostering 
change through encouraging the prevention of information blocking. Some 
commenters agreed with the approach, but believed CMS could develop 
more concrete measures that would have a stronger justification for 
posting information on a CMS website versus using the three attestation 
statements.
    Response: Thank you for these comments and suggestions. To the 
extent that the commenters are requesting that we create positive 
incentive programs that include incentive payments to eligible 
hospitals and CAHs, we note that we can only do so to the extent 
authorized by law. We will take into consideration the suggestions for 
enhancing prevention of information blocking guidance, providing more 
education, and fostering change through encouragement in potential 
future rulemaking.
    Comment: A few commenters were in favor of posting certain 
information on eligible hospitals and/or CAHs that provide a ``no'' 
response to the prevention of information blocking attestation 
statements, but have requested additional ways to discourage this 
practice. Commenters requested that those who are knowingly and 
willfully blocking the transfer of information also be fined, per 
instance or per patient, as a way of disincentivizing this practice. A 
couple commenters suggested strengthening this provision by 
establishing an easy way for stakeholders to report potential 
information blocking activities.
    Response: We appreciate the commenters' suggestions regarding 
additional ways to discourage information blocking. We refer commenters 
to section 3022(b)(2)(B) of the PHSA, which provides that any health 
care provider determined by the Office of the Inspector General (OIG) 
to have committed information blocking shall be referred to the 
appropriate agency to be subject to appropriate disincentives using 
authorities under applicable federal law, as the Secretary sets forth 
through notice and comment rulemaking. Health care providers would also 
be subject to the separate information blocking regulations proposed by 
ONC for HHS adoption at 45 CFR part 171 (84 FR 7601 through 7605). 
Further, we note that ONC's 21st Century Cures Act proposed rule 
included a request for information regarding disincentives for health 
care providers (84 FR 7553).
    Comment: Many commenters, while in agreement with publicly posting 
certain information related to

[[Page 25580]]

information blocking, had concerns that eligible hospitals and CAHs are 
being held accountable for the practices of health IT vendors. Many 
commenters were concerned that vendors are restricting the transfer of 
data by data embargoing, actively blocking, and refusing or prohibiting 
the transfer of data. Further, there were concerns that vendors are 
requiring complex programs, the purchase of many costly programs, and 
requiring excessive fees to conduct data transfer. Last, several 
commenters requested that vendors be penalized equally, and in the same 
manner, as eligible hospitals and CAHs.
    Response: We appreciate the commenters' support for the proposal, 
and we also appreciate their concerns. We emphasize that the 
information blocking provision (section 4004 of the Cures Act) applies 
to health IT developers of certified health IT. Section 3022(a)(1) of 
the PHSA, in defining information blocking, refers to four classes of 
individuals and entities that may engage in information blocking and 
which include: Health care providers, health IT developers of certified 
health IT, networks, and exchanges. In the ONC 21st Century Cures Act 
proposed rule, ONC proposed to adopt definitions of these terms to 
provide clarity regarding the types of individuals and entities to whom 
the information blocking provision applies (84 FR 7601 through 7602).
    Regarding penalties, section 4004 of the Cures Act identifies 
potential penalties and disincentives for information blocking. Health 
IT developers, health information networks, and health information 
exchanges that the Inspector General, following an investigation, 
determines to have committed information blocking shall be subject to a 
civil monetary penalty determined by the Secretary for all such 
violations identified through such investigation, which may not exceed 
$1,000,000 per violation. Such determination shall take into account 
factors such as the nature and extent of the information blocking and 
harm resulting from such information blocking, including, where 
applicable, the number of patients affected, the number of providers 
affected, and the number of days the information blocking persisted. 
Health care providers determined by the Inspector General to have 
committed information blocking shall be referred to the appropriate 
agency to be subject to appropriate disincentives using authorities 
under applicable Federal law, as the Secretary sets forth through 
notice and comment rulemaking.
    Comment: One commenter suggested a collaboration between CMS, ONC, 
and OIG in order to address information blocking together, to combat 
information blocking consistently and from all angles.
    Response: We appreciate the commenter's suggestion, and note that 
CMS, ONC, and OIG are consistently working together on issues such as 
information blocking so that our policies are complementary and work 
together to address the issue.
    Final Action: After consideration of the comments received, and for 
the reasons outlined in our response to these comments and in the CMS 
Interoperability and Patient Access proposed rule, we are finalizing 
this policy as proposed. We will include information on a CMS website 
available to the public indicating that an eligible hospital or CAH 
attesting under the Medicare FFS Promoting Interoperability Program 
submitted a ``no'' response to any of the three prevention of 
information blocking attestation statements under 42 CFR 
495.40(b)(2)(i)(I)(1) through (3). We will post this information 
starting with the attestations for the EHR reporting period in 2019, 
and expect the information will be posted in late 2020. In the event 
that an eligible hospital or CAH leaves a ``blank'' response to an 
attestation statement, where a ``yes'' or a ``no'' response is not 
submitted, the attestations will be considered incomplete, and no 
information will be posted related to these attestation statements. We 
will establish a process for each eligible hospital and CAH to review 
the information related to their specific prevention of information 
blocking attestation statements before it is publicly posted on the CMS 
website. For each program year, we will have a 30-day preview period 
for an eligible hospital or CAH to review this information before it is 
publicly posted. During the 30-day preview period, all of the 
information that we will publicly post will be available for the 
eligible hospital or CAH to review, and we will consider making changes 
to the information on a case-by-case basis.

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

A. Background

    Congress required the Secretary to create a provider digital 
contact information index in section 4003 of the Cures Act. This index 
must include all individual health care providers and health care 
facilities, or practices, in order to facilitate a comprehensive and 
open exchange of patient health information. Congress gave the 
Secretary the authority to use an existing index or to facilitate the 
creation of a new index. In comments received on the FY 2019 IPPS 
proposed rule RFI, there was strong support for a single, public 
directory of provider digital contact information. Commenters noted 
that digital communication could improve interoperability by 
facilitating efficient exchange of patient records, eliminating the 
burden of working with scanned paper documents, and ultimately 
enhancing care coordination.
    To ensure the index is accessible to all clinicians and facilities, 
we updated the National Plan and Provider Enumeration System (NPPES) 
\52\ to be able to capture digital contact information for both 
individuals and facilities. It is important to note that the 
aforementioned updates to the NPPES entailed the addition of two 
additional data fields. However, due to an administrative oversight, 
the data elements which allow for the digital capture of contact 
information are not OMB approved. CMS acknowledges this violation of 
the Paperwork Reduction Act of 1995 (PRA) and is currently working to 
remediate the issue by creating a new PRA package and thereby come into 
compliance with the PRA. Prior to its submission for OMB approval, the 
new information collection request will be made available for public 
review and comment as required by the PRA.
---------------------------------------------------------------------------

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

    NPPES currently supplies National Provider Identifier (NPI) numbers 
to health care providers (both individuals and facilities), maintains 
their NPI record, and publishes the records online. The Secretary 
adopted the NPI as the HIPAA administrative simplification standard 
identifier for health care providers (69 FR 3434). HIPAA covered 
entities, including health care providers, health plans, and health 
care clearinghouses, must use the NPI in HIPAA transactions. All health 
care providers that transmit health information in electronic form in 
connection with a HIPAA transaction must obtain an NPI.
    Health care providers are required to communicate to the NPPES any 
information that has changed within 30 days of the change (45 CFR 
162.410(a)(4)). We review NPPES to ensure a provider has a valid NPI as 
part of the Medicare enrollment process, as well as the revalidation 
process, which occurs every 3 to 5 years depending on the provider or 
supplier type.

[[Page 25581]]

    Information in NPPES is publicly accessible via both an online 
search option and a downloadable database option. As a result, adding 
digital contact information to this existing index is an efficient and 
effective way to meet the Congressional requirement to establish a 
digital contact information index and to promote the sharing of 
information.
    As of June 2018, NPPES has been updated to include the capability 
to capture one or more pieces of digital contact information that can 
be used to facilitate secure sharing of health information. For 
instance, providers can submit a Direct address, which functions 
similar to a regular email address, but includes additional security 
measures to ensure that messages are only accessible to the intended 
recipient in order to keep the information confidential and secure. 
``Direct'' is a technical standard for exchanging health information. 
Direct addresses are available from a variety of sources, including EHR 
vendors, State Health Information Exchange entities, regional and local 
Health Information Exchange entities, as well as private service 
providers offering Direct exchange capabilities called Health 
Information Service Providers (HISPs) (https://www.healthit.gov/sites/default/files/directbasicsforprovidersqa_05092014.pdf). NPPES can also 
capture information about a wide range of other types of endpoints that 
providers can use to facilitate secure exchange of health information, 
for instance a FHIR server URL or query endpoint associated with a 
health information exchange. We strongly encourage the inclusion of 
this FHIR endpoint information in NPPES in support of the Patient 
Access API policy discussed in section III. of this final rule and the 
Provider Directory API policy discussed in section IV. of this final 
rule. Using NPPES as one way to make these endpoints publicly known 
will significantly support interoperability throughout the health care 
system.
    In addition, NPPES can now maintain information about the type of 
contact information providers and organizations are associated with, 
along with the preferred uses for each address. Each provider in NPPES 
can maintain their own unique information or associate themselves with 
information shared among a group of providers. Finally, in March 2019, 
NPPES added a public API which can be used to obtain the digital 
contact information stored in the database. Although NPPES is now 
better equipped to maintain provider digital contact information, many 
providers have not submitted this information. In the 2015 final rule, 
``Medicare and Medicaid Programs; Electronic Health Record Incentive 
Program-Stage 3 and Modifications to Meaningful Use in 2015 Through 
2017'' (80 FR 62901), we finalized a policy to collect information in 
NPPES about the electronic addresses of participants in the EHR 
Incentive Program (specifically, a Direct address and/or other 
``electronic service information'' as available). However, this policy 
was not fully implemented at the time, in part due to the limitations 
of the NPPES system which have since been addressed. As a result, many 
providers have not yet added their digital contact information to NPPES 
and digital contact information is frequently out of date.
    In light of these updates to the NPPES system, all individual 
health care providers and facilities can take immediate action to 
update their NPPES record online to add digital contact information. 
This simple step will significantly improve interoperability by making 
valuable contact information easily accessible. For those providers who 
continue to rely on the use of cumbersome, fax-based modes of sharing 
information, we hope that greater availability of digital contact 
information will help to reduce barriers to electronic communication 
with a wider set of providers with whom they share patients. 
Ubiquitous, public availability of digital contact information for all 
providers is a crucial step towards eliminating the use of fax machines 
for the exchange of health information. We urged all providers to take 
advantage of this resource to implement Congress' requirement that the 
Secretary establish a digital contact information index.

B. Public Reporting of Missing Digital Contact Information

    Entities seeking to engage in electronic health information 
exchange need accurate information about the electronic addresses (for 
example, Direct address, FHIR server URL, query endpoint, or other 
digital contact information) of potential exchange partners. A common 
directory of the electronic addresses of health care providers and 
organizations could enhance interoperability and information exchange 
by providing a resource where users can obtain information about how to 
securely transmit electronic health information to a provider.
    We proposed to increase the number of providers with valid and 
current digital contact information available through NPPES by publicly 
reporting the names and NPIs of those providers who do not yet have 
their digital contact information included in the NPPES system. We 
proposed to begin this public reporting in the second half of 2020, to 
allow individuals and facilities time to review their records in NPPES 
and update the system with appropriate digital contact information. We 
also requested comment from stakeholders on the most appropriate way to 
pursue this public reporting initiative, including where these names 
should be posted, with what frequency, and any other information 
stakeholders believed would be helpful.
    We noted that we believed this information would be extremely 
valuable to facilitate interoperability, and we appreciated Congress' 
leadership in requiring the establishment of this directory. We 
requested stakeholder comment on additional possible enforcement 
authorities to ensure that individuals and facilities make their 
digital contact information publicly available through NPPES. For 
example, we questioned if Medicare reporting programs, such as MIPS, 
should require eligible clinicians to update their NPPES data with 
their digital contact information? Should CMS require this information 
to be included as part of the Medicare enrollment and revalidation 
process? How can CMS work with states to promote adding information to 
the directory through state Medicaid programs and CHIP? Should CMS 
require providers to submit digital contact information as part of 
program integrity processes related to prior authorization and 
submission of medical record documentation? We noted that we would 
review comments for possible consideration in future rulemaking on 
these questions.
    We summarize the public comments we received on this topic and 
provide our responses.
    Comment: Many stakeholders shared our goal of improving the 
accuracy and completeness of data in the NPPES.
    Response: We thank commenters for their support and are finalizing 
this policy as proposed.
    Comment: Many commenters, while supporting the ultimate goal of the 
proposal, noted doubts about whether the proposal would be effective at 
increasing the accuracy and completeness of digital contact information 
in NPPES. Commenters believed that a public reporting mechanism would 
not serve as a meaningful deterrent to providers leaving their 
information blank. One commenter stated that they believed, even with 
the implementation of this proposal, high rates of inaccuracies would 
persist in NPPES, and

[[Page 25582]]

stakeholders would continue to rely on internal sources of information. 
Several commenters stated that, given the likelihood that this proposal 
would not result in meaningful improvements, this proposal would 
represent unnecessary administrative burden for providers.
    Response: We thank commenters for their feedback on the potential 
effectiveness of this proposal. While we believe that this proposal is 
an important initial step toward increasing the accuracy of information 
in NPPES, we appreciate that this proposal may not be sufficient to 
fully realize the goal of NPPES serving as a comprehensive index of 
provider digital contact information. To this end, we requested comment 
on other programs that CMS could leverage to improve the completeness 
and accuracy of information in NPPES. The responses to this comment 
solicitation are discussed in more detail below.
    Comment: Many commenters recommended that, instead of pursuing a 
policy based on ``public shaming,'' it would be more effective for CMS 
to consider incentive-based policies for updating their digital contact 
information in NPPES.
    Response: We thank commenters for their recommendations. While we 
believe the proposed policy is an important step toward increasing the 
completeness and accuracy of information in NPPES, we believe that 
other policy initiatives using incentives may be effective as well, 
such as leveraging opportunities under the MIPS program, and we will 
consider these approaches for potential inclusion in future rulemaking.
    Comment: In the proposed rule, CMS requested comment on additional 
possible enforcement authorities to ensure that individuals and 
facilities make their digital contact information publicly available 
through NPPES. Many commenters supported the use of other authorities 
to increase the accuracy and completeness of digital contact 
information in NPPES, stating that they believe these authorities were 
more likely to be effective than the proposed policy for publicly 
reporting the names and NPIs of those providers that have not included 
digital contact information in NPPES.
    For instance, many commenters believed that including this 
requirement in the MIPS program would be a more effective strategy for 
achieving the goals of the policy. Commenters believed this would be 
more effective due to the incentives available through the MIPS 
program. Commenters also believed that use of the MIPS program would be 
more effective since the Promoting Interoperability category of MIPS 
already includes requirements to electronically exchange health 
information, and the goal of increasing availability of digital contact 
information would align with those features of the program. Commenters 
also believed that tying this policy to the MIPS program would help to 
ensure annual updates of digital contact information as part of 
required MIPS data submissions.
    Several commenters also supported the use of the Medicare 
enrollment or revalidation process and the use of program integrity 
processes as ways to promote updating of digital contact information in 
NPPES.
    Response: We thank commenters for their input on additional 
enforcement mechanisms. We will take these comments under consideration 
as we consider potential future rulemaking or operational changes to 
these programs that are consistent with each program's statutory 
authority.
    Comment: Many commenters suggested that CMS provide additional 
education and guidance about the benefits of adding their digital 
contact information to NPPES. These commenters recommended that CMS 
engage in public education as a necessary step before proceeding with 
public reporting in order to build awareness among providers of the 
importance of updating this information. For instance, one commenter 
noted that many hospital-based physicians are not aware of their 
digital contact information, currently relying on their institution's 
informatics division to manage this data. Others suggested that 
providers are not aware of the new functionality in NPPES allowing for 
submission of digital contact information and that education will be 
needed to familiarize providers with this feature. Commenters 
recommended that public education initiatives be targeted at those 
providers least likely to be familiar with the new functionality, and 
that CMS should work with specialty societies and other provider 
representatives to ensure education reaches a wide variety of 
providers. Some commenters also stated that a public education 
initiative alone would be a more appropriate alternative to public 
reporting of providers' names and NPIs.
    Response: We appreciate commenters' recommendations around the need 
for public education. Since updating the functionality in NPPES 
starting in 2018, we have taken steps to familiarize the provider 
community with these updates and plan to continue and expand this 
outreach. We agree that education efforts will be important to ensure 
that providers are aware of their responsibilities and that they may be 
at risk of having their names and NPIs publicly reported if they do not 
update their digital contact information in NPPES in a timely manner. 
While recognizing the importance of public education, we also believe 
that more aggressive steps are needed to accelerate the accuracy of 
completeness of information within NPPES, therefore we are finalizing 
the policy to publicly report the names and NPIs of providers that do 
not include digital contact information in NPPES.
    Comment: CMS proposed to begin public reporting in the second half 
of 2020. A number of commenters suggested that CMS delay this timeframe 
to allow providers more time to be made aware of the policy, review 
their NPPES record, and add missing information. One commenter believed 
that this timeline was not consistent with the time that would be 
required for CMS to reach small providers with information about the 
new policy, and recommended a delay of at least an additional 12 months 
before public reporting begins.
    Response: We appreciate commenters' concerns and suggestions 
regarding the appropriate timeframe for public reporting under this 
proposal. However, we believe that the proposed timeline allows 
sufficient time for outreach and education to make providers aware of 
the requirement. We are therefore finalizing this timeframe as 
proposed.
    Comment: Many commenters expressed concerns about the accuracy of 
information in NPPES, stating that inaccurate information imposes a 
burden on both providers and consumers who may try to collect and use 
this information only to find out that it is incorrect. These 
commenters noted inaccurate contact information also poses a problem 
for providers who are concerned with sending protected health 
information to the wrong recipient. One commenter stated that these 
challenges raise questions about whether a public file is appropriate 
to serve as the basis for increasing interoperability across provider 
systems.
    Commenters suggested steps CMS could take to improve the accuracy 
of information in NPPES. One commenter suggested that CMS establish a 
requirement that providers update their information within a set time 
period. Another commenter suggested that NPPES post the date that 
information associated with a given NPI was last updated so that 
individuals reviewing the database could assess its accuracy. Several 
commenters urged CMS to

[[Page 25583]]

conduct direct outreach to providers to confirm their information, or 
to validate provider information with other sources, such as state 
licensing boards, in order to increase accuracy.
    Response: We appreciate commenters' concerns about the accuracy of 
provider contact information within NPPES. The ``Last Updated'' date is 
posted on the ``NPI View'' page for records in the public NPPES NPI 
Registry. It should also be noted that providers are required to update 
information included in NPPES within 30 days of a change (45 CFR 
162.410(a)(4)). However, we understand from commenters that in practice 
these updates often do not occur, contributing to historical challenges 
with the accuracy of NPPES data.
    We appreciate commenters' suggestions for ways to improve the 
accuracy of data within NPPES, and we will take these suggestions into 
consideration.
    Comment: Several commenters noted that providers who have not 
participated in the Promoting Interoperability Program (formerly the 
EHR Incentive Programs) are more likely to not have digital contact 
information available than those that have participated and received 
incentives for adoption of health information. Commenters stated that 
these providers would be at a disadvantage under the proposed policy, 
and that identifying these providers as noncompliant through a public 
reporting mechanism would be unfair. Commenters stated that this group 
likely includes smaller practices, rural clinicians, hospital-based 
clinicians, and clinicians employed at a variety of settings which were 
not eligible for EHR incentives, such as rehabilitation centers.
    Response: We appreciate commenters' concerns regarding those 
clinicians that are less likely to have existing digital contact 
information. While we understand that it may take more time for these 
clinicians to obtain and submit digital contact information to NPPES, 
we believe that the timeframe for implementing this proposal will 
provide sufficient notice to clinicians. We also believe that obtaining 
digital contact information, such as a Direct address, is now widely 
available to clinicians, including those who do not have certified EHR 
systems. Accordingly, we believe that these providers will be able to 
obtain digital contact information and add it to their NPPES record 
with relatively minimal burden.
    Comment: Many commenters suggested that CMS establish a process for 
offering providers a chance to review their information and correct any 
issues prior to the implementation of public reporting. Commenters 
stated that CMS should issue communication to providers informing them 
of the status of their digital contact information, and that 
communications should include mechanisms which allow the provider to 
make corrections. One commenter recommended that CMS institute a 60-day 
review period prior to public reporting similar to the review period 
established for data included on the Physician Compare website.
    Response: We appreciate commenters' suggestions regarding 
opportunities for clinicians to review their information prior to the 
implementation of this public reporting policy. We have already 
implemented multiple methods for providers to review their information 
allowing them to correct any issues with their NPPES record. Providers 
can review their information using the NPPES NPI Registry (https://npiregistry.cms.hhs.gov/), the NPPES NPI Registry API (https://npiregistry.cms.hhs.gov/registry/help-api), or the NPPES Data 
Dissemination file (https://www.cms.gov/Regulations-and-Guidance/Administrative-Simplification/NationalProvIdentStand/DataDissemination). Each source currently contains all the information 
that will allow providers to determine the correctness of their 
information. As discussed above, we will also engage in continued 
public education efforts to ensure providers are aware of the benefits 
of including digital contact information in NPPES, as well as the 
associated public reporting policy.
    Comment: Several commenters requested additional information about 
what kind of digital contact information would satisfy this 
requirement. One commenter recommended that providers should be able to 
specify other digital endpoints besides a Direct address. Another 
commenter requested clarity on whether the digital fax numbers would 
qualify as digital contact information.
    Response: As discussed in the proposed rule, NPPES is able to 
capture a variety of different digital endpoints. A digital fax number 
is not considered a digital endpoint for the purposes of this proposal. 
For more information on the digital contact information which can be 
added to NPPES, see https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html.
    Comment: Several commenters recommended that CMS partner with other 
centralized authorities that collect provider information. Commenters 
stated that relying on providers alone to update their information will 
not provide the levels of accuracy necessary for other providers to 
utilize NPPES for routine exchange of electronic health information. 
Commenters noted that today, directory services that employ appropriate 
identify proofing processes and other means for ensuring records are 
up-to-date are much more likely to possess accurate information than 
NPPES, and CMS should seek to improve the quality of NPPES by working 
with these partners. Commenters believed that by working with these 
entities, CMS could greatly reduce provider burden associated with 
entering information into and updating information in NPPES.
    Response: We appreciate commenters' input regarding other 
strategies to improve the accuracy of the digital contact information 
within NPPES.
    Comment: Several commenters requested additional guidance on how 
the public reporting mechanism would operate. One commenter sought 
information on where the names would be publicly reported. Another 
commenter questioned how CMS would address public reporting of 
providers that have an NPI but do not have active practice locations 
where they are providing services under Medicare or engaging in 
communication with patients.
    Response: We thank commenters for these questions. Following the 
publication of the final rule, we will release additional information 
around the public reporting mechanism including where we intend to 
publish the names and NPIs of providers that do not have digital 
contact information in NPPES, as well as information about whether 
certain providers would be exempt from public reporting.
    Comment: One commenter questioned how providers would be expected 
to know their digital contact information as this information may not 
be visible to providers in many EHR systems.
    Response: We encourage providers, especially clinicians, to work 
with health IT administrators in their organization or directly with 
their health IT vendor if they are unclear on where their digital 
contact information can be found. We also note that NPPES now provides 
for bulk uploading of information to multiple NPI records, and 
encourage clinicians to work with health IT administrators in their 
organization to develop streamlined processes for updating this 
information in a way that imposes minimal burden on clinicians.
    Comment: Several commenters noted the Provider Enrollment, Chain, 
and Ownership System (PECOS) system

[[Page 25584]]

would be the most appropriate location for storing digital contact 
information.
    Response: While we understand the interest in using PECOS as the 
location for storing digital contact information, we are not 
considering this as an option at this time. PECOS collects information 
specific to provider and supplier enrollment in the Medicare program 
and the system is limited to the fields on the CMS 855 Enrollment 
forms. Any other data outside of this is optional. There are also many 
operational and systematic issues that prevent PECOS from being 
utilized to implement the digital contact information requirement.
    Comment: Several commenters raised questions about what entities 
would have access to the information in NPPES. One commenter stated 
that any entity should be able to gain access to NPPES in order to 
advance interoperability. Another noted that making digital endpoints 
publicly accessible via an API that may be accessible to third parties 
could pose a risk to the security of protected health information 
available through those APIs, and recommended that CMS make this 
information available to other entities only if the third-party entity 
requests access from the API owner.
    Response: NPPES already furnishes a public downloadable data 
dissemination file as well as a public API that provides the public 
information available in the NPI Registry. Both files are publicly 
accessible. Please note that this proposal is not related to the 
Patient Access API discussed in section III. of this final rule that 
can include patient protected health information.
    Comment: A number of commenters requested additional information on 
issues related to NPPES functionality, and sought guidance on how to 
enter digital contact information. For instance, numerous commenters 
believed that the NPPES does not allow for a provider to enter 
information for multiple practice and billing locations. Several 
commenters sought information about whether a provider could enter 
multiple digital endpoints, for instance if they employ different 
endpoints for different types of communication. One commenter requested 
information on whether a provider could enter digital contact 
information for his or her employer, rather than individual 
information.
    Response: For more information on how information is captured in 
NPPES, we encourage commenters to review information available on the 
NPPES website at https://nppes.cms.hhs.gov/webhelp/nppeshelp/HEALTH%20INFORMATION%20EXCHANGE.html.
    Comment: Several commenters suggested that CMS develop a digital 
contact information interoperability standard for facilitating 
efficient exchange of patient records.
    Response: We appreciate commenters' suggestions, and note that we 
continue to collaborate with ONC, other federal partners, and industry 
stakeholders, to develop more robust provider directory standards that 
can support exchange of this information. We also direct commenters to 
the discussion of the Provider Directory API in section IV. of this 
final rule.
    Final Action: After consideration of the comments received, and for 
the reasons outlined in our response to these comments and in the CMS 
Interoperability and Patient Access proposed rule, we are finalizing to 
publicly report the names and NPIs of those providers who do not have 
digital contact information included in the NPPES system beginning in 
the second half of 2020 as proposed. Additionally, we will engage in 
continued public education efforts to ensure providers are aware of the 
benefits of including digital contact information in NPPES, including 
FHIR API endpoints, and when and where this information will be posted.

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

A. Background

    As noted in the CMS Interoperability and Patient Access proposed 
rule (84 FR 7649 through 7653), we appreciate the pathways Congress has 
created for action on interoperability and have been working diligently 
with ONC to implement them. In order to ensure broad stakeholder input 
to inform the proposals, we published a Request for Information (RFI) 
on interoperability in several proposed rules, including the FY 2019 
IPPS proposed rule (83 FR 20550). Specifically, we published the RFI 
entitled, ``Promoting Interoperability and Electronic Healthcare 
Information Exchange Through Possible Revisions to the CMS Patient 
Health and Safety Requirements for Hospitals and Other Medicare- and 
Medicaid-Participating Providers and Suppliers.'' We requested 
stakeholders' input on how we could use the CMS health and safety 
standards that are required for providers and suppliers participating 
in the Medicare and Medicaid programs (that is, the Conditions of 
Participation (CoPs), Conditions for Coverage (CfCs), and Requirements 
for long term care facilities) to further advance electronic exchange 
of information that supports safe, effective transitions of care 
between hospitals and community providers. Specifically, we requested 
comment on revisions to the current CMS CoPs for hospitals such as: 
Requiring that hospitals transferring medically necessary information 
to another facility upon a patient transfer or discharge do so 
electronically; requiring that hospitals electronically send required 
discharge information to a community provider via electronic means if 
possible and if a community provider can be identified; and requiring 
that hospitals make certain information available to patients or a 
specified third-party application (for example, required discharge 
instructions) via electronic means if requested.
    The RFI discussed several steps we have taken in recent years to 
update and modernize the CoPs and other health and safety standards to 
reflect current best practices for clinical care, especially in the 
area of care coordination and discharge planning. For a complete 
discussion of this work, see the proposed rule (84 FR 7649 through 
7650).
    In the September 30, 2019 Federal Register, we published a final 
rule, ``Medicare and Medicaid Programs; Revisions to Requirements for 
Discharge Planning'' (84 FR 51836) (``Discharge Planning final rule''), 
that revises the discharge planning requirements that hospitals 
(including psychiatric hospitals, long-term care hospitals, and 
inpatient rehabilitation facilities), critical access hospitals (CAHs), 
and home health agencies, must meet to participate in Medicare and 
Medicaid programs. The rule supports CMS' interoperability efforts by 
promoting the exchange of patient information between health care 
settings, and by ensuring that a patient's necessary medical 
information is transferred with the patient after discharge from a 
hospital, CAH, or post-acute care services provider. By requiring that 
all of the patient's necessary medical information, including his or 
her post-discharge goals of care and treatment preferences, must be 
documented in the patient's medical record and transferred along with 
the patient at the time of discharge to an appropriate receiving health 
care facility, such as a PAC service provider or agency, and to other 
outpatient service providers and practitioners responsible for the 
patient's follow-up or ancillary care, the rule aims to better prepare 
patients and their caregivers to be active partners and advocates for 
their health care and community support needs upon

[[Page 25585]]

discharge from the hospital or post-acute care setting.
    While we finalized a broad requirement for sending necessary 
medical information in accordance with all applicable laws, rather than 
listing specific data elements (such as those explicitly aligned with 
the data referenced as part of the Common Clinical Data Set (CCDS) that 
was finalized in the 2015 final rule, ``Medicare and Medicaid Programs; 
Electronic Health Record Incentive Program--Stage 3 and Modifications 
to Meaningful Use in 2015 Through 2017'' (80 FR 62762), we also ensured 
that the revisions to the CoPs did not conflict with the CCDS, or 
future standards proposed for adoption for electronic exchange of 
health information, specifically the USCDI. The discharge planning CoPs 
do not bar providers from sending all additional appropriate medical 
information regarding the patient's current course of illness and 
treatment, post-discharge goals of care, and treatment preferences in 
accordance with applicable laws. However, we note here that the 
Discharge Planning final rule does not require hospitals, CAHs, and 
HHAs to transfer the necessary patient medical information exclusively 
by electronic means nor does it require that providers notify the 
appropriate providers, suppliers, and practitioners receiving the 
necessary medical information of the patient's discharge as we are now 
requiring in this final rule.
    Additionally, the Discharge Planning final rule further supports 
interoperability and a patient's access to his or her own medical 
records by updating the hospital Patient Rights CoP to now state that 
the patient has the right to access his or her medical records in the 
form and format requested (including in an electronic form or format 
when such medical records are maintained electronically). Therefore, 
the hospital CoPs now include an explicit requirement that, as a 
condition of participation, hospitals must provide patients with access 
to their medical records in an electronic format upon the patient's 
request if the hospital has the capacity to do so.
    In response to the RFI in the FY 2019 IPPS proposed rule, many 
stakeholders supported our goals of increasing interoperability, and 
acknowledged the important role that hospital settings play in 
supporting care coordination. Stakeholders agreed that use of 
electronic technology was an important factor in ensuring safe 
transitions. Multiple stakeholders emphasized that electronic data 
exchange between hospitals and physician offices, as well as with 
hospices, HHAs, SNFs, and other post-acute care services providers, was 
especially important during care transitions when maintaining access to 
patient health information, including medication information, and is 
extremely relevant to the patient's next phase of care. Additionally, 
stakeholders noted that giving patients and their caregivers access to 
important health information (such as discharge information along with 
accurately reconciled lists of discharge medications) created a more 
patient-centered health care system, and reduced the risk of errors and 
hospital readmissions. But many stakeholders also expressed concerns 
about implementing policy changes within the CoPs that might increase 
the compliance burden on hospitals. However, several stakeholders also 
strongly recommended that CMS add details to the CoPs, and require that 
hospitals share not only medically necessary information with physician 
offices, HHAs, and SNFs (such as pending tests and discharge 
summaries), but also notifications of when patients were admitted to 
the hospital as well as discharged or transferred from the hospital and 
admitted to the care of applicable PAC services providers and 
suppliers.
    Given responses to the RFI, as well as previous rulemaking 
activities, we sought to further expand CMS requirements for 
interoperability within the hospital and CAH CoPs as part of the CMS 
Interoperability and Patient Access proposed rule by focusing on 
electronic patient event notifications. In addition, we noted that we 
were committed to taking further steps to ensure that facilities that 
are electronically capturing information are electronically exchanging 
that information with providers who have the capacity to accept it.
    Infrastructure supporting the exchange of electronic health 
information across settings has matured substantially in recent years. 
Research studies have increasingly found that health information 
exchange interventions can affect positive outcomes in health care 
quality and public health, in addition to more longstanding findings 
around reductions in utilization and costs. A recent review of how 
health information exchange interventions can improve cost and quality 
outcomes identified a growing body of high-quality studies showing that 
these interventions are associated with beneficial results.\53\ The 
authors identified a number of studies demonstrating positive effects 
on outcomes associated with better care coordination, such as 
reductions in 30-day readmissions,54 55 56 and improved 
medication reconciliation.\57\
---------------------------------------------------------------------------

    \53\ Menachemi, N., Rahurkar, S., Harle, C.A., & Vest, J.R. 
(2018). The benefits of health information exchange: An updated 
systematic review. Journal of the American Medical Informatics 
Association, 25(9), 1259-1265. doi: 10.1093/jamia/ocy035.
    \54\ Yeaman, B., Ko, K., del Castillo, R. (2015). Care 
transitions in long-term care and acute care: Health information 
exchange and readmission rates. The Online Journal of Issues in 
Nursing, 20(3). doi: 10.3912/OJIN.Vol20No03Man05.
    \55\ Vest, J.R., Kern, L.M., Silver, M.D., & Kaushal, R. (2015). 
The potential for community-based health information exchange 
systems to reduce hospital readmissions. Journal of the American 
Medical Informatics Association, 22(2), 435-442. doi: 10.1136/
amiajnl-2014-002760.
    \56\ Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest, J.R. (2017). 
Hospitalization event notifications and reductions in readmissions 
of Medicare fee-for-service beneficiaries in the Bronx, New York. 
Journal of the American Medical Informatics Association, 24(e1), 
e150-e156. doi: 10.1093/jamia/ocw139.
    \57\ Boockvar, K.S., Ho, W., Pruskowski, J., Dipalo, K.E., Wong, 
J.J., Patel, J., . . . Hung, W. (2017). Effect of health information 
exchange on recognition of medication discrepancies is interrupted 
when data charges are introduced: Results of a cluster-randomized 
controlled trial. Journal of the American Medical Informatics 
Association, 24(6), 1095-1101. doi: 10.1093/jamia/ocx044.
---------------------------------------------------------------------------

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

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

    Patient event notifications are automated, electronic 
communications from the discharging provider to another facility, or to 
another applicable community provider as identified by the patient 
(such as a patient's primary care practitioner or practice group, post-
acute care services providers and suppliers, and other practitioners 
and providers that need the notification for post-acute care 
coordination, treatment, and/or quality improvement purposes),

[[Page 25586]]

which alerts the receiving provider that the patient has received care 
at a different setting. Depending on the implementation, information 
included with these notifications can range from conveying the 
patient's name, other basic demographic information, and the sending 
institution to a richer set of clinical data on the patient. Even with 
a minimum set of information included, these notifications can help 
ensure that a receiving provider, facility, or practitioner is aware 
that the patient has received care elsewhere. The notification triggers 
a receiving provider, facility, or practitioner to reach out to the 
patient and deliver appropriate follow-up care in a timely manner. By 
notifying the individuals and entities that need notification of the 
patient's status for treatment, care coordination, or quality 
improvement purposes, the notification can help to improve post-
discharge transitions and reduce the likelihood that a patient would 
face complications from inadequate follow-up care.
    In addition to their effectiveness in supporting care coordination, 
virtually all EHR systems generate the basic messages commonly used to 
support electronic patient event notifications. These notifications are 
based on admission, discharge, and transfer (ADT) messages, a standard 
message used within an EHR as the vehicle for communicating information 
about key changes in a patient's status as they are tracked by the 
system (more information about the current standard supporting these 
messages is available at https://www.hl7.org/implement/standards/product_brief.cfm?product_id=144). As noted in the Interoperability 
Standards Advisory (ISA) published by ONC, this messaging standard has 
been widely adopted across the health care system (see https://www.healthit.gov/isa/sending-a-notification-a-patients-admission-discharge-andor-transfer-status-other-providers).
    ADT messages provide each patient's personal or demographic 
information (such as the patient's name, insurance, next of kin, and 
attending physician), when that information has been updated, and also 
indicate when an ADT status has changed. To create an electronic 
patient event notification, a system can use the change in ADT status 
to trigger a message to a receiving provider or to a health information 
exchange system that can then route the message to the appropriate 
provider. In addition to the basic demographic information contained in 
the ADT message, some patient event notification implementations attach 
more detailed information to the message regarding the patient's 
clinical status and care received from the sending provider.

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

    We proposed to revise the CoPs for Medicare- and Medicaid-
participating hospitals at 42 CFR 482.24 by adding a new standard at 
paragraph (d), ``Electronic Notifications,'' that would require 
hospitals to send electronic patient event notifications of a patient's 
admission, discharge, and/or transfer to another health care facility 
or to another community provider or practitioner. We proposed to 
require hospitals to convey, at a minimum, the patient's basic personal 
or demographic information, as well as the name of the sending 
institution (that is, the hospital), and, if not prohibited by other 
applicable law, the patient's diagnosis. In proposing that patient 
event notifications sent by a hospital's medical records system include 
diagnosis, where not prohibited by other applicable law, we requested 
comment on the technical feasibility of this proposal, noting that we 
recognize some existing ADT messages might not include diagnosis, as 
well as the challenges in appropriately segmenting this information in 
instances where the diagnosis may not be permitted for disclosure under 
other applicable laws.
    We also encouraged hospitals, as their systems and those of the 
receiving providers allowed, to work with patients and their 
practitioners to offer more robust patient information and clinical 
data upon request in accordance with applicable law.
    For a hospital that currently possesses an EHR system with the 
capacity to generate the basic patient personal or demographic 
information for electronic patient event notifications, we proposed 
that compliance with the proposed standard within the Medical records 
services CoP (42 CFR 482.24) would be determined by the hospital 
demonstrating to the surveyor or accrediting organization that its 
system: (1) Is fully operational and that it operates in accordance 
with all state and federal statutes and regulations regarding the 
exchange of patient health information; (2) utilizes the content 
exchange standard incorporated by reference at 45 CFR 170.205(a)(4)(i); 
(3) sends notifications that would have to include the minimum patient 
health information (which, as noted above, would be the patient's name, 
treating practitioner name, sending institution name, and, if not 
prohibited by other applicable law, patient diagnosis); and (4) sends 
notifications directly, or through an intermediary that facilitates 
exchange of health information, and at the time of the patient's 
admission to the hospital and either immediately prior to or at the 
time of the patient's discharge and/or transfer from the hospital.
    We proposed to limit this requirement to only those hospitals which 
currently possess EHR systems with the technical capacity to generate 
information for electronic patient event notifications as discussed 
below, recognizing that not all Medicare- and Medicaid-participating 
hospitals have been eligible for past programs promoting adoption of 
EHR systems. We noted our goal in proposing the requirement was to 
ensure that hospital EHR systems have a basic capacity to generate 
messages that can be utilized for notifications by a wide range of 
receiving providers, enabled by common standards. We believed that a 
system that utilizes the ADT messaging standard, which is widely used 
as the basis for implementing these notifications and other similar use 
cases, would meet this goal by supporting the availability of 
information that can be used to generate information for patient event 
notifications. Specifically, we proposed that the system utilize the 
ADT messaging standard incorporated by reference at 45 CFR 
170.205(a)(4)(i).\59\
---------------------------------------------------------------------------

    \59\ Health Level Seven Messaging Standard Version 2.5.1 (HL7 
2.5.1), an Application Protocol for Electronic Data Exchange in 
Healthcare Environments, February 21, 2007.
---------------------------------------------------------------------------

    We noted that, while there are no criteria under the ONC Health IT 
Certification Program which certifies health IT to create and send 
electronic patient event notifications, the ADT standard is referenced 
by other certification criteria under the program. Specifically, this 
standard supports certification criteria related to transferring 
information to immunization registries, as well as transmission of 
laboratory results to public health agencies as described at 45 CFR 
170.315(f) under the 2015 Edition certification criteria, and at 45 CFR 
170.314(f) under the 2014 Edition. Thus, we expect systems that include 
Health IT Modules certified to meet criteria which reference this 
standard will possess the basic capacity to generate information for 
notification messages. We further noted that adopting certified health 
IT that meets these criteria has been required for any hospital seeking 
to qualify for the Promoting Interoperability Programs (formerly the 
EHR Incentive Programs).
    We recognized that there is currently significant variation in how 
hospitals have utilized the ADT messages to

[[Page 25587]]

support implementation of patient event notifications. We also 
recognized that many hospitals, which have already implemented 
notifications, may be delivering additional information beyond the 
basic information included in the ADT message (both automatically when 
a patient's status changes and then upon request from receiving 
providers) to receiving practitioners, patient care team members, and 
post-acute care services providers and suppliers with whom they have 
established patient care relationships and agreements for patient 
health information exchange as allowed by law. We believe consensus 
standards for ADT-based notifications may become more widely adopted in 
the future (we refer readers to ONC's ISA \60\ for more information 
about standards under consideration). However, at this time, we stated 
that we did not wish to restrict hospitals from pursuing more advanced 
content as part of patient notifications, nor to create redundant 
requirements where hospitals already have a suitable notification 
system in place. Accordingly, while we specified that hospitals subject 
to the proposal possess a system utilizing this standard, we proposed 
that hospitals could utilize other standards or features to support 
their notification systems. We requested comment on the proposal, 
including whether this requirement would achieve the goal of setting a 
baseline for hospitals' capacity to generate information for electronic 
notifications, while still allowing for innovative approaches that 
would potentially increase the effectiveness of these notifications 
toward improving patient outcomes and safety during transitions in 
care.
---------------------------------------------------------------------------

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

    We further proposed that the hospital would need to demonstrate 
that the system's notification capacity was fully operational, that it 
operated in accordance with all state and federal statutes and 
regulations regarding the exchange of patient health information. We 
intended for these notifications to be required, at minimum, for 
inpatients admitted to, and discharged and/or transferred from the 
hospital. However, we also noted that patient event notifications are 
an effective tool for coordinating care across a wider set of patients 
that may be cared for by a hospital. For instance, a patient event 
notification could ensure that a primary care physician was aware that 
his or her patient had received care at the emergency room, and 
initiate outreach to the patient to ensure that appropriate follow-up 
for the emergency visit was pursued. While we encouraged hospitals to 
extend the coverage of their notification systems to serve additional 
patients, outside of those admitted and seen as inpatients, we also 
sought comment on whether we should identify a broader set of patients 
to whom this requirement would apply, and if so, how we should 
implement such a requirement in a way that minimizes administrative 
burden on hospitals.
    Additionally, we proposed that the hospital would have to 
demonstrate that its system sends notifications that include the 
minimum patient health information (specifically, patient name, 
treating practitioner name, sending institution name, and, if not 
prohibited by other applicable law, patient diagnosis). We proposed 
that the hospital would also need to demonstrate that the system sends 
notifications directly, or through an intermediary that facilitates 
exchange of health information, at the time of the patient's hospital 
admission, discharge, or transfer, to licensed and qualified 
practitioners, other patient care team members, and PAC services 
providers and suppliers that: (1) Receive the notification for 
treatment, care coordination, or quality improvement purposes; (2) have 
an established care relationship with the patient relevant to his or 
her care; and (3) the hospital has reasonable certainty that such 
notifications are received. We noted that we believed the proposal 
would allow for a diverse set of strategies that hospitals might use 
when implementing patient event notifications.
    Through these provisions, we sought to allow for different ways 
that a hospital might identify those practitioners, other patient care 
team members, and PAC services providers and suppliers that are most 
relevant to both the pre-admission and post-discharge care of a 
patient. We proposed that hospitals send notifications to those 
practitioners or providers that had an established care relationship 
with the patient relevant to his or her care. We recognized that 
hospitals and their partners may identify appropriate recipients 
through various methods. For instance, hospitals might identify 
appropriate practitioners by requesting this information from patients 
or caregivers upon arrival, or by obtaining information about care team 
members from the patient's record. We expected hospitals might develop 
or optimize processes to capture information about established care 
relationships directly, or work with an intermediary that maintains 
information about care relationships. In other cases, we noted that 
hospitals may, directly or through an intermediary, identify 
appropriate notification recipients through the analysis of care 
patterns or other attribution methods that seek to determine the 
provider most likely to be able to effectively coordinate care post-
discharge for a specific patient. The hospital or intermediary might 
also develop processes to allow a provider to specifically request 
notifications for a given patient for whom they are responsible for 
care coordination as confirmed through conversations with the patient.
    Additionally, we expected hospitals, psychiatric hospitals, and 
CAHs to comply with the HIPAA Rules set out at 45 CFR parts 160 and 164 
if these proposed CoP requirements for patient event notifications were 
finalized. As required at 42 CFR 482.11 for hospitals and psychiatric 
hospitals and at 42 CFR 485.608 for CAHs, these providers must comply 
with all pertinent currently existing federal laws, including the HIPAA 
Privacy and Security Rules. The Privacy Rule permits patient event 
notifications as disclosures for treatment purposes (the proposed 
required notifications, when finalized, also may be treated as 
disclosures required by law (see 45 CFR 164.502(a)).
    We also recognized that factors outside of the hospital's control 
might determine whether or not a notification was successfully received 
and utilized by a practitioner. Accordingly, we proposed that a 
hospital would only need to send notifications to those practitioners 
for whom the hospital has reasonable certainty of receipt. While we 
stated that we expected hospitals would, to the best of their ability, 
seek to ensure that notification recipients were able to receive 
notifications (for instance, by obtaining a recipient's Direct address 
\61\), we understood that technical issues beyond the hospital's 
control could prevent successful receipt and use of a notification.
---------------------------------------------------------------------------

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

    Finally, we noted that hospitals have an existing responsibility 
under the CoPs at 42 CFR 482.43(d) to ``transfer or refer patients, 
along with necessary medical information, to appropriate facilities, 
agencies, or outpatient services, as needed, for follow-up or ancillary 
care.'' We emphasized that the proposal regarding patient event 
notifications would be separate from the

[[Page 25588]]

requirement regarding necessary medical information at 42 CFR 
482.43(d). However, we recognized that processes to implement the 
proposal, if finalized, could intersect with the hospital's discharge 
planning process. We noted that nothing in the proposal would affect 
the hospital's responsibilities under 42 CFR 482.43(d). However, we 
noted if the proposal was finalized, hospitals might wish to consider 
ways to fulfill these requirements in ways that reduce redundancy while 
still remaining compliant with existing requirements. For instance, 
where appropriate and allowed by law, hospitals might seek to include 
required necessary medical information within the same message as a 
patient event notification.

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

    Medicare- and Medicaid-participating psychiatric hospitals must 
comply with all of the hospital CoPs at 42 CFR 482.1 through 482.23 and 
at 42 CFR 482.25 through 482.57. They also must adhere to special 
provisions regarding medical records at 42 CFR 482.61 and staffing 
requirements at 42 CFR 482.62. Since the medical records requirements 
are different for psychiatric hospitals, and since these hospitals do 
not have to comply with the regulations at 42 CFR 482.24, we proposed a 
new electronic notification standard at 42 CFR 482.61(f) within the 
special provisions for psychiatric hospitals in this section.
    Similar to the proposal for hospitals at 42 CFR 482.24(d), we 
proposed a new standard at 42 CFR 482.61(f), ``Electronic 
Notifications,'' that would require psychiatric hospitals to send 
electronic patient event notifications of a patient's admission, 
discharge, and/or transfer to another health care facility or to 
another community provider.
    As we proposed for hospitals, we proposed to limit this requirement 
to only those psychiatric hospitals which currently possess EHR systems 
with the technical capacity to generate information for electronic 
patient event notifications, defined as systems that utilize the 
content exchange standard incorporated by reference at 45 CFR 
170.205(a)(4)(i). We proposed that that for a psychiatric hospital that 
currently possessed an EHR system with the capacity to generate the 
basic patient personal or demographic information for electronic 
patient event (ADT) notifications, compliance with the proposed 
standard within the Special medical records requirements for 
psychiatric hospitals CoP (42 CFR 482.61) would be determined by the 
hospital demonstrating that its system: (1) Is fully operational and 
that it operated in accordance with all state and federal statutes and 
regulations regarding the exchange of patient health information; (2) 
utilizes the content exchange standard incorporated by reference at 45 
CFR 170.205(a)(4)(i); (3) sends notifications that would have to 
include the minimum patient health information (specifically, patient 
name, treating practitioner name, sending institution name, and, if not 
prohibited by other applicable law, patient diagnosis); and (4) sends 
notifications directly, or through an intermediary that facilitates 
exchange of health information, and at the time of the patient's 
admission to the hospital and either immediately prior to or at the 
time of the patient's discharge and/or transfer from the hospital. We 
requested comment on the policy as part of this hospital proposal in 
section X.B. of the CMS Interoperability and Patient Access proposed 
rule (84 FR 7650 through 7652).
    We also proposed that the hospital would need to demonstrate that 
the system sends notifications directly, or through an intermediary 
that facilitates exchange of health information, and either immediately 
prior to or at the time of the patient's hospital admission, discharge, 
or transfer, to licensed and qualified practitioners, other patient 
care team members, and PAC services providers and suppliers that: (1) 
Receive the notification for treatment, care coordination, or quality 
improvement purposes; (2) have an established care relationship with 
the patient relevant to his or her care; and (3) the hospital is 
reasonably certain will receive such notifications.
    We referred readers to the extended discussion of the proposals in 
sections X.A. and B. of the CMS Interoperability and Patient Access 
proposed rule (84 FR 7649 through 7652). We sought comment on these 
proposals.

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

    We believe implementation of patient event notifications are also 
important for CAHs to support improved care coordination from these 
facilities to other providers in their communities. Therefore, similar 
to the proposals for the hospital and psychiatric hospital medical 
records requirements as discussed in the preceding sections, we 
proposed to revise 42 CFR 485.638, by adding a new standard to the CAH 
Clinical records CoP at paragraph (d), ``Electronic Notifications.'' As 
discussed, the proposed standard would require CAHs to send electronic 
patient event notifications of a patient's admission, discharge, and/or 
transfer to another health care facility or to another community 
provider.
    We proposed to limit this requirement to only those CAHs which 
currently possess EHR systems with the technical capacity to generate 
information for electronic patient event notifications, defined as 
systems that utilize the content exchange standard incorporated by 
reference at 45 CFR 170.205(a)(4)(i). We proposed that for a CAH that 
currently possessed an EHR system with the capacity to generate the 
basic patient personal or demographic information for electronic 
patient event (ADT) notifications, compliance with the proposed 
standard within the Clinical records services CoP (42 CFR 485.638) 
would be determined by the CAH demonstrating that its system: (1) Is 
fully operational and that it operates in accordance with all state and 
federal statutes and regulations regarding the exchange of patient 
health information; (2) utilizes the content exchange standard 
incorporated by reference at 45 CFR 170.205(a)(4)(i); (3) sends 
notifications that would have to include the minimum patient health 
information (specifically, patient name, treating practitioner name, 
sending institution name, and, if not prohibited by other applicable 
law, patient diagnosis); and (4) sends notifications directly, or 
through an intermediary that facilitates exchange of health 
information, and at the time of the patient's admission to the CAH and 
either immediately prior to or at the time of the patient's discharge 
and/or transfer from the CAH. We requested comment on the policy as 
part of the hospital proposal in section X.B. of the CMS 
Interoperability and Patient Access proposed rule (84 FR 7650 through 
7652).
    Additionally, we proposed that the CAH would need to demonstrate 
that the system sends notifications directly, or through an 
intermediary that facilitated exchange of health information, and at or 
immediately prior to the time of the patient's CAH admission, 
discharge, or transfer, to licensed and qualified practitioners, other 
patient care team members, and PAC services providers and suppliers 
that: (1) Receive the notification for treatment, care coordination, or 
quality improvement purposes; (2) have an established care relationship 
with the patient relevant to his or her care; and (3) the CAH is 
reasonably certain will receive such notifications.

[[Page 25589]]

E. Comments and Responses on the Provisions of the Proposed Rule; Final 
Actions and Provisions of the Final Rule for Hospitals (42 CFR 
482.24(d)), Psychiatric Hospitals (42 CFR 482.61(f)); and CAHs (42 CFR 
485.638(d))

    We requested comments on the proposals including stakeholder 
feedback about how the proposals should be operationalized. 
Additionally, we sought comment on how CMS should implement these 
proposals as part of survey and certification guidance in a manner that 
minimizes compliance burden on hospitals, psychiatric hospitals, and 
CAHs while ensuring adherence with the standards. We also sought 
stakeholder input about a reasonable timeframe for implementation of 
these proposals for hospitals, psychiatric hospitals, and CAHs, 
respectively.
    We received more than 600 public comments on this section that were 
specific to the patient event notification requirements proposed for 
inclusion in the CoPs, but which generally did not distinguish among 
the requirements individually proposed for hospitals, psychiatric 
hospitals, and CAHs at 42 CFR 482.24(d), 482.61(f), and 485.638(d), 
respectively. We summarize the public comments we received on our 
proposals related to the Conditions of Participation and provide our 
responses in this section. This summary of the public comments and our 
responses apply equally to all three provider types included under this 
proposed requirement and the specific provisions proposed for each 
unless otherwise noted. We provide the final actions and the provisions 
of the final rule at the end of this section.
    Comment: Many commenters supported the proposals to require 
hospitals (including psychiatric hospitals) and CAHs to send electronic 
patient event notifications of a patient's admission, discharge, and/or 
transfer to another health care facility or to another community 
provider. Commenters stated that they believed implementing patient 
event notifications would be a highly effective tool to improve care 
transitions for patients moving between a hospital and other settings, 
including returning home. Commenters believed that increasing the 
sharing of patient event notifications at admission and discharge can 
lead to improved outcomes, higher quality, and lower cost care. 
Commenters also pointed to many instances in which these notifications 
are being utilized today, stating that they believe that patient event 
notifications had effectively contributed to improved care 
coordination. For instance, one commenter pointed to the statewide 
requirement for hospitals in Maryland to transmit notifications, noting 
that this has been an important policy supporting care coordination in 
the state. Several commenters noted that the availability of 
notification information is especially important for the success of 
value-based payment models, such as ACO initiatives, where participants 
may be financially at risk for costs associated with poor care 
transitions.
    Response: We appreciate commenters' support for the proposal and 
are finalizing our proposal with modifications as discussed below.
    Comment: While many commenters agreed that patient event 
notifications are an important way to improve care coordination, some 
disagreed that the CoPs were the appropriate vehicle for advancing 
their use. Many commenters stated that by placing the patient event 
notification requirements in the CoPs, CMS is putting hospitals' 
participation in Medicare at risk, which they stated would be an 
excessive penalty for failure to implement patient event notifications 
in accordance with the proposed requirements.
    Commenters also stated that the survey and certification process 
was not well-suited to determining compliance with the proposed CoP 
``Electronic notifications'' standard. These commenters questioned how 
surveyors would assess compliance with the requirements, including one 
commenter who questioned how a hospital would demonstrate that its 
system sent notifications that improve the coordination of care, and 
not just show that its system is merely functioning as required. They 
further stated that a survey team would need clear guidance on how to 
assess providers for compliance to ensure that hospitals are 
transmitting patient information to, and receiving it from, other 
providers.
    Additionally, one commenter stated that hospital accreditation 
programs are not the appropriate entities to assess compliance, due to 
the technical nature of the requirements.
    Commenters also expressed concern that tying these requirements to 
the CoPs could lead to hospitals sending more information than is 
necessary to ensure compliance, further increasing excessive 
information received by providers.
    Response: We appreciate the commenters' concerns regarding use of 
the CoPs to advance the use of patient notifications; however, we 
disagree that the CoPs are an inappropriate vehicle for this purpose. 
We believe that the capability to send patient event notifications 
should be a fundamental feature of hospital medical record systems to 
support effective care transitions and promote patient safety during 
transitions. This belief is consistent with the statutory authority for 
establishing and appropriately updating the CoPs as that authority is 
contained in section 1861(e) of the Act, which defines institutions 
that meet the definition of a hospital for Medicare purposes. 
Specifically, section 1861(e)(2) of the Act requires that a hospital 
``maintains clinical records on all patients,'' and section 1861(e)(9) 
of the Act requires that a hospital ``meets such other requirements as 
the Secretary finds necessary in the interest of the health and safety 
of individuals who are furnished services in the institution.'' As 
discussed in the proposed rule (84 FR 7650), we believe patient event 
notifications can help to improve care coordination for patients 
discharged from the hospital and reduce the incidence of events such as 
hospital readmissions that could have been avoided through more timely 
follow-up care.
    Further, including a CoP requirement for patient event 
notifications at the time of a patient's discharge or transfer as we 
have proposed and are finalizing in this rule is also consistent with 
section 1861(ee)(2) of the Act, which states that the Secretary shall 
develop guidelines and standards for the discharge planning process in 
order to ensure a timely and smooth transition to the most appropriate 
type of and setting for post-hospital or rehabilitative care. We 
believe patient event notifications are an effective tool for ensuring 
that the settings responsible for follow-up care are made aware that 
their patients have been discharged in an expeditious manner. We 
believe that these notifications can be utilized to more effectively 
trigger care coordination activities that promote timely transitions. 
We have chosen to include these requirements in the CoPs for medical 
records services, and not those for discharge planning, because we 
believe that the medical records CoPs provide a more global approach to 
the notifications than do the discharge planning CoPs, especially since 
we are requiring notifications for inpatient admissions as well as ED 
and outpatient observation admissions or registrations in addition to 
patient discharges and transfers. Therefore, given this statutory 
authority, we maintain that the CoPs are an appropriate vehicle for 
advancing the use of patient event notifications.
    We also disagree that the CoPs are an inappropriate vehicle for 
this policy due to what the commenters' characterize as

[[Page 25590]]

the disproportionate penalties associated with noncompliance with this 
CoP. We note that while the CoPs are a significant regulatory 
mechanism, noncompliance with one subordinate standard under one CoP 
must be considered relative to a hospital's compliance or noncompliance 
with the many other CoPs and standards as well as the severity of the 
noncompliance and the risk it poses to patient health and safety. Under 
the heading, ``Determining the Severity of Deficiencies,'' the State 
Operations Manual (SOM), Appendix A--Survey Protocol, Regulations and 
Interpretive Guidelines for Hospitals cites the regulations at 42 CFR 
488.26 (``The decision as to whether there is compliance with a 
particular requirement, condition of participation, or condition for 
coverage, depends upon the manner and degree to which the provider or 
supplier satisfies the various standards within each condition.'') as 
the basis for determining the various levels of noncompliance with the 
CoPs during a survey (https://www.cms.gov/Regulations-andGuidance/Guidance/Manuals/downloads/som107ap_a_hospitals.pdf; p.19).
    From page 19 of the SOM, Appendix A:
    ``When noncompliance with a condition of participation is noted, 
the determination of whether a lack of compliance is at the Standard or 
Condition level depends upon the nature (how severe, how dangerous, how 
critical, etc.) and extent (how prevalent, how many, how pervasive, how 
often, etc.) of the lack of compliance. The cited level of the 
noncompliance is determined by the interrelationship between the nature 
and extent of the noncompliance.
    ``A deficiency at the Condition level may be due to noncompliance 
with requirements in a single standard or several standards within the 
condition, or with requirements of noncompliance with a single part 
(tag) representing a severe or critical health or safety breach. Even a 
seemingly small breach in critical actions or at critical times can 
kill or severely injure a patient, and represents a critical or severe 
health or safety threat.
    ``A deficiency is at the Standard level when there is noncompliance 
with any single requirement or several requirements within a particular 
standard that are not of such character as to substantially limit a 
facility's capacity to furnish adequate care, or which would not 
jeopardize or adversely affect the health or safety of patients if the 
deficient practice recurred.''
    Regarding the comments questioning how surveyors, either state 
surveyors or those from one of the hospital accreditation programs, 
would determine compliance with the notification requirements, we will 
issue, as we do with all new or revised CoP requirements, new 
interpretive guidelines, which include survey procedures, for the State 
Operations Manual, following finalization of this rule and prior to the 
rule's effective date. We will advise and train state surveyors on the 
new requirements as is the normal procedure when new and/or revised 
CoPs and standards are finalized. For example, the current Medical 
Record Services CoP requirements, contained at 42 CFR 482.24, and in 
which we are finalizing these new patient event notification 
requirements, primarily contain provisions for administrative systems 
or processes where the hospital is responsible for demonstrating that 
the various components of its medical records system or process are in 
place and operational in order to comply with the overall requirements 
of the CoP. Surveyors would then approach these new requirements in a 
similar fashion and apply similar survey procedures and methods that do 
not require surveyors to have deep technical knowledge of various 
systems in order to determine compliance. As with the survey of the 
hospital's total medical records system, surveyors would utilize basic 
and effective survey procedures and methods such as:
     Review of the organizational structure and policy 
statements and an interview with the person responsible for the medical 
records service to first ascertain that the hospital has a system that 
meets the initial requirements for patient event notifications in order 
to determine whether or not the hospital is exempt from the specific 
patient event notification requirements that follow.
     Review of a sample of active and closed medical records 
for completeness and accuracy, including any patient event 
notifications, in accordance with federal and state laws and 
regulations and hospital policy.
     Interview of medical records and other hospital staff, 
including physicians and other practitioners, to determine 
understanding of the patient events notification function of the 
system.
     Conducting observations and interviews with medical 
records staff and leadership to determine if requirements for patient 
event notifications are being met.
    CMS-approved accreditation organizations (AOs) with hospital 
programs are required, at a minimum, to enforce standards that meet or 
exceed hospital CoP requirements, so each AO will be responsible for 
training its survey and accreditation staff on the patient event 
notification requirements finalized in this rule ahead of the 
applicable date established by CMS.
    Finally, the patient event notification requirements that we are 
finalizing require a hospital to send only a minimal amount of patient 
information in order to be in compliance with the provisions. These 
requirements are consistent with our belief that existing patient event 
notification systems have demonstrated that a minimal set of 
information can achieve the desired effect of improving care 
coordination while imposing minimal burden on providers. However, 
hospitals are not prohibited from sending more detailed information 
under these requirements and we would expect each hospital is fully 
aware of its own capacity to send additional patient information, other 
applicable laws governing this, and the capacities of the intended 
recipients to receive additional patient information, and would base 
its decisions to send additional information on these factors as well 
as on what is best for the patient. Based on our experience with 
hospitals, we disagree with the commenter that a hospital would 
unnecessarily send ``excessive'' amounts of patient information in an 
attempt to ensure a determination that the hospital was in compliance. 
To prevent such confusion, we have clearly delineated the patient 
information requirements in this final rule.
    Comment: Many commenters stated that the CoPs were not appropriate 
for advancing goals related to interoperability and the use of health 
IT. Commenters stated that CMS currently regulates provider use of 
technology through a variety of other avenues, such as the Promoting 
Interoperability Programs, and that adding the proposed requirements 
under the CoPs would add an unnecessary additional mechanism for 
addressing these issues. Commenters believed this could lead to 
additional provider burden and confusion, as stakeholders would be 
required to navigate duplicative requirements around the electronic 
exchange of information. Several commenters stated that, by shifting 
focus to compliance with the proposed requirements, and requiring 
hospitals to engage in duplicative reporting on information exchange, 
this proposal could divert funding and attention from necessary 
investments in interoperable health information exchange. Commenters 
stated that they believed using the CoPs

[[Page 25591]]

in this fashion was inconsistent with congressional intent for how HHS 
should regulate the use of health IT.
    Commenters also noted that HHS is currently seeking to establish a 
range of new policies designed to advance the interoperable exchange of 
health information. Commenters believed these policies could have a 
significant impact on the sharing of health information, including the 
sharing of patient event notifications, and that CMS should refrain 
from rulemaking through the CoPs until these polices have been 
finalized. One commenter also noted that, at the time the comment 
period on the CMS Interoperability and Patient Access proposed rule 
closed, CMS' Discharge Planning rule (80 FR 68125) had not yet been 
finalized, and that it would be premature to add this requirement in 
advance of finalizing related revisions to the discharge planning 
section of the CoPs.
    Commenters further stated that HHS has a variety of other 
mechanisms for advancing electronic information exchange and improving 
the infrastructure for exchange that would be more effective than 
adding requirements to the CoPs. Several commenters expressed concern 
that using the CoPs would set static requirements that are ill-suited 
to an evolving technology environment and the innovation needed to 
increase adoption of notifications across providers.
    Response: We appreciate commenters' input. As noted above, we 
disagree with commenters who stated that the CoPs are not an 
appropriate mechanism for policy related to interoperability or the use 
of health IT. Existing CoPs address requirements related to medical 
records systems as well as the transfer of health information, and we 
believe there is no reason that these regulations should not address 
technology issues where the use of technology may be relevant to 
patient health and safety, provided that such references to technology 
in the CoPs do not lead to ``static requirements'' as noted by the 
commenter, and which we believe we have avoided doing in both the 
proposed and final rules. Furthermore, while a 2017 review of the 
current available scientific evidence on the impact of different health 
information technologies on improving patient safety outcomes, warned 
that health care organizations ``need to be selective in which 
technology to invest in, as literature shows that some technologies 
have limited evidence in improving patient safety outcomes,'' the 
review also stated that there ``should be no doubt that health 
information technology is an important tool for improving healthcare 
quality and safety.'' \62\ According to the authors of the review, 
evidence from a number of studies shows that health IT offers numerous 
opportunities for improving and transforming health care that includes 
the potential to reduce human errors, improve clinical outcomes, 
facilitate care coordination, improve practice efficiencies, and track 
data over time. Based on this evidence as well as the evidence directly 
related to patient event notifications that we cited previously, we 
believe that the requirements for patient event notifications that we 
have proposed and that we are finalizing in this rule will have a 
positive impact on many of these same areas, especially regarding the 
facilitation of care coordination for patients, leading to improved 
outcomes and enhanced patient health and safety.
---------------------------------------------------------------------------

    \62\ Alotaibi, Y., & Federico, F. (2017). The impact of health 
information technology on patient safety. Saudi Medical Journal, 
38(12), 1173-1180. doi: 10.15537/smj.2017.12.20631.
---------------------------------------------------------------------------

    While we appreciate the importance of aligning policies across 
different programs to minimize provider burden, we believe that the 
proposed requirements are not addressed elsewhere and are appropriate 
for inclusion in the CoPs. Additionally, we disagree with commenters 
who stated that the proposed requirements will require hospitals to 
engage in duplicative reporting on information exchange since the 
proposed requirements do not require hospitals and CAHs to do any type 
of reporting to CMS in order to comply with the requirements. We also 
understand that other proposed or recently finalized policies may be 
relevant to the proposed requirements in this rule; however, we believe 
these policies will complement one another and serve to enable the 
proposed requirements around patient event notifications. As we noted 
above regarding the final rule published on September 30, 2019, 
Discharge Planning final rule (84 FR 51836), the revised discharge 
planning CoPs do not require hospitals, CAHs, and HHAs to transfer 
necessary patient medical information exclusively by electronic means, 
nor do they require that providers notify the appropriate providers, 
suppliers, and practitioners receiving the necessary medical 
information of the patient's discharge (or admission) as we are now are 
requiring in this final rule. We believe that the two rules, as written 
and finalized, do not conflict, but instead complement and support each 
other in CMS' goal of improving patient care transitions. Therefore, we 
disagree with the comments stating that the patient event notification 
requirements are premature or duplicative in relation to the final 
discharge planning requirements for hospitals, CAHs, and HHAs.
    Regarding concerns that it will be challenging to update the CoPs 
to reflect changing technology requirements, our proposal sought to 
focus primarily on functional requirements that will allow hospitals 
the flexibility to pursue innovation and adapt their systems over time, 
similar to other functional requirements under the Medical Records 
Services CoP. Where we do reference a specific standard, in order to 
determine whether or not a hospital's system would be subject to the 
proposed ``Electronic notifications'' standard, we reference a content 
exchange standard at 45 CFR 170.205(d)(2) common to many EHRs that we 
believe is unlikely to undergo changes that would require frequent 
updates.
    Comment: Commenters stated that including these requirements under 
the CoPs would significantly increase the compliance burden for 
providers. Commenters believed that the proposed policy was contrary to 
other recent HHS burden reduction initiatives for providers. Commenters 
also believed that this proposal would add additional layers of 
regulation to what is a common practice for many hospitals today, 
further increasing provider burden.
    Several commenters stated that CMS had underestimated the burden 
associated with this proposal. They disagreed that implementing patient 
event notifications would be largely limited to a one-time cost, and 
stated that there would be substantial work required prior to 
implementing the proposal and continuous work around receiving 
notifications from other providers. Commenters suggested that CMS 
pursue other initiatives to alleviate costs, such as standardizing the 
data set for patient event notifications. Stakeholders also urged CMS 
to ensure that providers have cost-effective choices for required 
technology solutions, and to not create an environment that encourages 
over-pricing of solutions.
    Response: We appreciate commenters' concerns about additional 
provider burden. While we understand that this new requirement may 
impose some additional implementation burden on hospitals, commenters 
also expressed that there are many ways for hospitals to minimize this 
burden through the use of existing technologies and services, such as 
health information exchanges and other service providers which capture 
notification information from a hospital's EHR and route it to

[[Page 25592]]

appropriate recipients. We believe that there is sufficient flexibility 
in the current proposal to ensure hospitals have a broad range of 
options for implementation and will be able to comply in a way that 
aligns with their existing capabilities.
    We believe that care coordination can have a significant positive 
impact on the quality of life, consumer experience, and health outcomes 
for patients. However, we acknowledge that though such activities can 
have positive impact, they will likely generate some costs. We believe 
it is difficult to quantify the impact of these changes because EHR 
implementation across care settings varies in maturity rates, leading 
to potential variance in cost and impact across such settings. 
Nonetheless, we have attempted to estimate the burden for those 
hospitals and CAHs that currently utilize electronic medical records 
systems or other electronic administrative systems that are conformant 
with the content exchange standard at 45 CFR 170.205(d)(2), and which 
generate information to support the basic messages commonly used for 
electronic patient event notifications, but which are not currently 
transmitting notifications. The cost of implementing these changes will 
include a one-time cost related to initial implementation of the 
notification system. Additionally, we have also estimated recurring 
maintenance costs for either those hospitals or CAHs that use hospital 
or CAH IT services staff to perform this recurring maintenance, or for 
those hospitals and CAHs that contract with third party outside 
services providers to perform this maintenance. We also stress that the 
requirements that we are finalizing here do not mandate that a hospital 
or CAH must purchase and implement a new EHR system. Rather, as 
finalized here, the provisions require a hospital or a CAH to 
demonstrate compliance with all of the provisions contained at 42 CFR 
482.24(d), 482.61(f), and 485.638(d) only if it utilizes an electronic 
medical records system or other electronic administrative system that 
is conformant with the content exchange standard at 45 CFR 
170.205(d)(2). We note here then that a hospital or a CAH that does not 
meet the basic requirements denoted in the standard language at 
paragraphs 42 CFR 482.24(d), 482.61(f), and 485.638(d) is exempt from 
demonstrating compliance with the requirements that follow and will not 
be surveyed for those specific provisions once a surveyor determines 
that the system used by the hospital or CAH is not conformant with the 
content exchange standard discussed here.
    Comment: Many commenters supported the proposal to limit the 
application of the proposed requirements to hospitals that possess a 
system capable of generating information for patient event 
notifications, while several disagreed with CMS and thought that CMS 
should not limit these requirements to only certain hospitals. Numerous 
commenters also sought additional information on how CMS will determine 
whether a hospital's system is subject to the proposed CoP standard. 
Commenters stated that the proposed rule did not indicate how surveyors 
would determine which electronic records systems possess required 
attributes, and that surveyors would not have the technical expertise 
required to make this determination.
    Response: In the CMS Interoperability and Patient Access proposed 
rule, we proposed to limit this requirement to only those hospitals 
which currently possess EHR systems with the technical capacity to 
generate information for electronic patient event notifications. We 
defined a system with this capacity as one that utilizes the ADT 
messaging standard, Health Level Seven (HL7[supreg]) Messaging Standard 
Version 2.5.1 (HL7 2.5.1)) incorporated by reference at 45 CFR 
170.205(a)(4)(i). We noted that this standard is referenced by 
certification criteria related to transferring information to 
immunization registries, as well as transmission of laboratory results 
to public health agencies as described at 45 CFR 170.315(f), and that 
adoption of certified health IT that meets these criteria has been 
required for any hospital seeking to qualify for the Promoting 
Interoperability Program. We believe hospitals and surveyors will be 
able to determine whether an EHR system possesses the capacity to 
generate information for electronic patient event notifications, 
defined for the purposes of the CoP as a system conformant with the 
specified ADT messaging standard (HL7 2.5.1), based on existing 
requirements for other programs, such as the Promoting Interoperability 
Program. In general, we believe that information about whether a system 
complies with this provision will be easy to obtain from a hospital's 
health IT developer.
    As discussed below, we are finalizing a citation to the ADT 
messaging standard (HL7 2.5.1) at 45 CFR 170.205(d)(2).
    Comment: A commenter noted that in some instances a hospital's 
patient event notification system is connected to the hospital's 
registration system rather than its EHR system, which is used for 
clinical purposes only.
    Response: We appreciate the comment and the opportunity to note 
here that the ``electronic medical records system'' described in the 
CoPs is not limited to the EHR system used for the management of 
clinical data. Hospitals would also be permitted to send patient event 
notifications using their registration system. Based on this comment, 
we are revising the language at 42 CFR 482.24(d), 482.61(f), and 
485.638(d) in this final rule to now state that if the hospital (or 
psychiatric hospital or CAH), ``. . . utilizes an electronic medical 
records system or other electronic administrative system,'' then the 
hospital (or psychiatric hospital or CAH) would need to demonstrate 
that its system complies with the provisions that follow in this 
section.
    Comment: In the proposed rule we sought comment on whether we 
should identify a broader set of patients to whom this requirement 
would apply, beyond those admitted and treated as inpatients. For 
instance, we noted that a patient event notification could ensure a 
primary care physician is aware that their patient has received care at 
the emergency room, and initiate outreach to the patient to ensure that 
appropriate follow-up for the emergency visit is pursued (84 FR 7651).
    Many stakeholders responded to this request for comment by stating 
that they supported extending this policy to also include patients seen 
in a hospital's emergency department (ED). Commenters stated that 
requiring systems to be able to send these notifications would be an 
important way to support better care coordination and prevent 
unnecessary repeat visits to the emergency department. Commenters also 
suggested that this requirement should include patients seen in the 
hospital for ``observational'' stays, but who are not admitted as 
inpatients.
    Response: We agree with the commenters that ED patients should be 
included in the patient event notification system, and have revised the 
regulatory text at 42 CFR 482.24(3)(i) and (4)(i), 482.61(3)(i) and 
(4)(i), and 485.638(3)(i) and (4)(i) to include these patients. Many 
patients registered in the ED are eventually discharged home after 
being treated, while others are either held for observation in a 
hospital bed as outpatients or admitted as inpatients to the hospital. 
The revisions we are finalizing here would require a hospital's system 
to send patient event notifications for patients who are registered in 
the ED, if applicable, and then also for patients admitted as

[[Page 25593]]

inpatients, regardless if the patient was admitted from the ED, from an 
observation stay, or as a direct admission from home, from their 
practitioner's office, or as a transfer from some other facility. We 
agree with the commenters and believe that if we were not to include ED 
patients in the notification requirements in this final rule, we would 
miss an important opportunity for positively impacting the care 
transitions and the continuing care of a significant number of patients 
seen in the nation's hospital emergency departments. Including ED 
patients in the patient event notification requirements is consistent 
with the purpose of the CoPs as a regulatory means of promoting and 
protecting the overall health and safety of all hospital patients, 
regardless of their physical location in the hospital.
    To illustrate when a patient event notification is, and is not, 
required, we would like to point out the following scenarios. A 
hospital's system would be expected to send one notification when a 
patient is first registered in a hospital's ED or as an observational 
stay (that is, in both of these cases, the patient would be considered 
an outpatient and not an inpatient at this point in time), and a second 
notification if the same patient was then later admitted to a hospital 
inpatient services unit (for example, medical unit, labor and delivery 
unit, telemetry unit, neurology unit, surgical unit, intensive care 
unit (ICU), etc.), or if the same patient was admitted for inpatient 
services, but was being boarded in the ED while waiting for an 
inpatient unit bed. In contrast, a second patient event notification 
would not be required if an already admitted inpatient was transferred 
from one inpatient services unit of the hospital to another (for 
example, if the patient was admitted to the hospital's ICU, but was 
then later transferred to the hospital's ``step-down'' or 
``intermediate care'' unit or to a medical unit, in which case, the 
patient continued to remain an inpatient of the hospital), or if an 
already admitted patient was being boarded in the ED and then was 
transferred to an inpatient unit when a bed became available. However, 
while the requirements do not prohibit a hospital from electing to send 
a patient event notification when a patient is transferred to one 
inpatient services unit of the hospital to another, the requirements 
finalized in this rule are based on a change in the patient's status 
from outpatient to inpatient, and not necessarily on the physical 
location of the patient.
    Finally, in all cases, a patient's discharge or transfer from the 
hospital, either from the ED or an observational stay or an inpatient 
services unit, would still require the hospital to send another and 
separate patient event notification to the applicable entities as 
required under this rule.
    Comment: We proposed that hospitals should send notifications to 
those practitioners or providers that have an established care 
relationship with the patient relevant to his or her care (84 FR 7652). 
Many commenters sought additional information about the term 
``established care relationship'' and how hospitals should discern who 
has an established care relationship with a patient. Commenters noted 
that the list of providers who have an ``established care 
relationship'' with a patient could be very extensive and requested 
more information on the extent of the specialization of care team 
members covered by the requirement. One commenter suggested CMS 
indicate that the term ``established care relationship'' only applies 
to one that is current and directly related to the patient's diagnosis 
for which the notification is sent. Another commenter suggested that 
CMS define ``established care relationship'' as the principle physician 
identified by the patient and any institution that the patient 
identifies. Several commenters suggested that CMS replace the term 
``established care relationship'' with ``active relationship,'' and 
noted that this would also ensure payers received the notifications, as 
their relationship with a patient may not be included under the 
definition of a ``care'' relationship. One commenter suggested that CMS 
note that hospitals have the latitude to choose the recipient of the 
notification. Commenters also sought direction on how hospitals should 
approach a situation in which a patient does not have a primary care 
provider, or in which a provider who has an established care 
relationship with the patient cannot be easily identified. Several 
commenters noted that effective notification systems are often 
organized around a subscription model, in which receiving providers are 
responsible for identifying those patients for whom they would like to 
receive notifications.
    Response: We appreciate commenters' input. We agree that the term 
``established care relationship'' could be subject to an overly broad 
interpretation that is not consistent with our goal to set a minimum 
floor for these requirements under the CoPs. Accordingly, we are 
finalizing a more limited set of recipients to whom a hospital's system 
must send patient event notifications for the purposes of meeting this 
CoP. We are finalizing at 42 CFR 482.24(d)(5), 482.61(f)(5), and 
485.638(d)(5) requirements that the hospital's system send 
notifications to the following recipients as applicable: The patient's 
established primary care practitioner; the patient's established 
primary care practice group or entity; or other practitioners or 
practice groups or entities, identified by the patient as the 
practitioner, or practice group or entity, primarily responsible for 
his or her care. We believe that the use of the modifier 
``established,'' as finalized here in the context of a patient's 
established primary care practitioner or his or her established primary 
care practice group or entity, more clearly signifies a care 
relationship that the patient recognizes as primary or one that is 
evidenced by documentation of the relationship in the patient's medical 
record. As an example, if the patient's established primary care 
practitioner refers the patient to the hospital, this primary care 
practitioner should receive the event notification. We believe this 
language improves upon the proposed term ``established care 
relationship,'' which commenters correctly noted is too vague in 
meaning, too broad in scope, and too open to various interpretations, 
all of which could prove burdensome for hospitals to demonstrate 
compliance with the requirements here. We note that this final policy 
does not prevent a hospital from sending patient event notifications to 
other practitioners, in accordance with all applicable laws, who may be 
relevant to a patient's post-discharge care and would benefit from 
receiving patient event notifications, nor would it prevent a hospital 
from seeking to identify these other practitioners. However, we believe 
this more limited set of recipients is more appropriate to our goal of 
setting baseline requirements and will provide hospitals with 
sufficient specificity to comply with the requirements.
    In cases where a hospital is not able to identify a primary care 
practitioner for a patient, the patient has not identified a provider 
to whom they would like information about their care to be sent, or 
there is no applicable PAC provider or supplier identified, we would 
not expect a hospital to send a patient event notification for that 
patient. We note that under the CoP, a hospital would be required to 
demonstrate that its system sends notifications to appropriate 
recipients. We expect that hospitals would demonstrate this capability 
in variety of ways, for instance, by demonstrating that the hospital 
has processes and policies in place to identify patients' primary care 
practitioners and

[[Page 25594]]

incorporate this information into the patient event notification 
system, or through recording information received from patients about 
their providers.
    Comment: Commenters stated that obtaining information about 
providers who have an ``established care relationship'' with a given 
patient and maintaining lists of these providers and contact 
information for delivery of patient event notifications would impose 
significant burden on hospitals. One commenter noted that patients may 
not reliably provide information about their providers, and recommended 
that in those cases the recipient of the patient event notification 
should identify their relationship with a patient in advance.
    Several commenters noted that, to the extent hospitals already have 
operational processes and infrastructure in place to determine 
destinations for notifications, these processes should be left in 
place. Several commenters noted that, in order to successfully route 
messages to the appropriate provider, hospitals would need to be able 
to overcome challenges associated with patient matching: The ability 
for a hospital to accurately match records about a patient with the 
records held by a receiving provider. Commenters stated that challenges 
with patient matching could inhibit patient event notifications from 
being received by the correct provider and will lead to frequent 
pushback from providers about receiving notifications regarding 
patients they are not affiliated with. Commenters also noted the 
importance of community-wide directories that map the address of a 
provider to their electronic endpoint destination, which would allow a 
hospital to query a directory and find the destination of the patient's 
choice.
    Response: As noted, we are finalizing a more limited minimum set of 
recipients for patient event notifications than originally proposed. 
This set of recipients is focused on a patient's established primary 
care practitioner (or established primary care practice group or 
entity) or any other practitioner (or practice group or entity) 
identified by the patient as primarily responsible for his or her care. 
However, we are retaining inclusion in this final rule of PAC providers 
and suppliers as required recipients of notifications as originally 
proposed. In order to clarify the PAC services providers and suppliers 
that are required recipients, we are modifying this proposal to refer 
to ``all applicable PAC services providers and suppliers.'' For 
purposes of this policy, applicable PAC services providers and 
suppliers would be those PAC services providers and suppliers with whom 
the patient has an established care relationship prior to admission or 
to whom the patient is being transferred or referred. Similar to our 
modification to reference the patient's established primary care 
practitioner, these PAC services providers and suppliers would be those 
with an established care relationship immediately preceding the 
hospital registration or admission (such as a PAC services provider or 
supplier from which the patient was transferred to the hospital) or 
those with which a relationship is being established for purposes of 
treatment and/or care coordination post-discharge from the hospital. 
The potential recipients of patient event notifications will be limited 
to only those that need to receive notification of the patient's status 
for treatment, care coordination, or quality improvement purposes. We 
believe that this final policy will reduce potential operational burden 
associated with a broader ``established care relationship'' definition. 
We believe that increasing numbers of hospitals now commonly seek to 
identify patients' primary care practitioners and their contact 
information, including any digital contact information, or partner with 
intermediaries that identify primary care practitioners, and that many 
hospitals will be able to continue to use their existing processes to 
satisfy the CoP. If a hospital has processes in place for identifying 
patients' primary care practitioners and other applicable providers, 
but is not able to identify an appropriate recipient for a patient 
event notification for a specific patient, the hospital would not be 
expected to send a notification for that patient.
    Research using CMS data on readmission rates in Medicare-
participating hospitals from 2007 to 2015 shows that the readmission 
rates for targeted conditions (that is, a set of specific diagnoses 
measured by Medicare) declined from 21.5 percent to 17.8 percent, and 
rates for non-targeted conditions declined from 15.3 percent to 13.1 
percent.\63\ While this decline in readmissions rates is attributable 
to multiple factors, we believe that one of the significant factors 
driving down avoidable patient readmissions is identification by the 
hospital of the patient's established primary care practitioner (or 
practice group) and his or her contact information prior to discharge 
and/or transfer. Increased and early identification of the patient's 
primary care practitioner is more likely to lead to more accurate and 
timely transfer of patient health information from hospital-based 
practitioners to community-based primary care practitioners. 
Additionally, early identification of a patient's primary care 
practitioner along with the patient event notification to the 
practitioner that his or her patient is about to be discharged from the 
hospital is most likely to have a net positive effect on scheduled 
post-discharge follow-up rates for patients most at risk for avoidable 
readmissions.
---------------------------------------------------------------------------

    \63\ Alper, E., O'Malley, T.A., & Greenwald, J. (n.d.). Hospital 
discharge and readmission. Retrieved from https://www.uptodate.com/contents/hospital-discharge-and-readmission.
---------------------------------------------------------------------------

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

    \64\ National Association of Healthcare Access Management. 
(2016, March 17). NAHAM Public Policy Statement on Patient Identity 
Integrity. Retrieved from https://nahamnews.blogspot.com/2016/03/naham-public-policy-statement-on.html.
---------------------------------------------------------------------------

    Capturing incorrect or incomplete data can result in critical 
patient care issues and risk privacy breaches. Health care 
organizations are more likely to have their EHR system filled with 
duplicate patient records and inaccurate information about their 
patients when they are not managing an effective PIM process. Having an 
ineffective PIM process will most definitely negatively impact a 
hospital's patient event notification system, which is one of the many 
reasons why a rigorous PIM process is essential to patient care as 
health IT moves forward. Additionally, PIM has become crucial in order 
to (1)

[[Page 25595]]

enable health record document consumers to obtain trusted views of 
their patient subjects; (2) facilitate data exchange projects; (3) 
abide by the current regulations concerning patient information-related 
transparency, privacy, disclosure, handling, and documentation; and (4) 
make the most efficient use of limited health care resources by 
reducing redundant data collection.\65\
---------------------------------------------------------------------------

    \65\ Gliklich, R., Dreyer, N., & Leavy, M. (Eds.). (2014). 
Registries for Evaluating Patient Outcomes: A User's Guide (3rd 
ed.). Rockville, MD: AHRQ Publication. Retrieved from https://www.ncbi.nlm.nih.gov/books/NBK208616/.
---------------------------------------------------------------------------

    Nationally recognized practices and standards for ensuring patient 
identity integrity have been identified by organizations such as the 
National Association of Healthcare Access Management, American Health 
Information Management Association, the Agency for Healthcare Research 
and Quality, and ONC. These standards include standardizing demographic 
data fields and internally evaluating the accuracy of patient matching 
within health care organizations.
    We believe this presents an opportunity for the health IT industry 
to lead the way in developing innovative solutions to patient matching, 
or PIM, that can benefit all facets of the health care industry. 
However, appreciating the importance of accurate patient matching, CMS 
will continue to evaluate ways to support improved patient matching 
solutions.
    Comment: Several commenters suggested additional provider types 
that should receive patient event notifications. For instance, 
commenters suggested health plans should be included on the list of 
recipients for patient event notifications, noting that this 
information would be valuable to plans responsible for coordinating 
services for beneficiaries and reducing readmissions. One commenter 
also recommended sending notifications to public health departments. 
Several commenters also requested that specific health care 
professionals be identified as recipients. Commenters also suggested 
that other caregivers such as relatives be included on the list of 
recipients.
    Response: We appreciate commenters' suggestions about adding 
additional recipients for patient event notifications. While there may 
be other entities that could benefit from receiving patient event 
notifications, we believe it is more appropriate for the purposes of 
the CoP requirements to focus on a minimal set of recipients for 
notifications. This approach would not preclude hospitals from sending 
notifications to other entities, including health plans, provided 
hospitals comply with applicable laws and regulations regarding sharing 
of patient data.
    Comment: Many commenters suggested that CMS should consider 
approaches that aim to incentivize providers to implement patient event 
notifications, rather than requiring hospitals to do so through the 
CoPs. Commenters stated that adding this requirement would result in 
unnecessary and burdensome duplication of requirements that hospitals 
are already subject to as part of existing programs focused on 
advancing health information exchange. Specifically, many commenters 
recommended that CMS seek to advance these goals through the Promoting 
Interoperability Program. Commenters suggested CMS consider adding a 
measure to the program based on patient event notifications, noting 
that such a measure could mirror the ``active engagement'' concept 
currently used for public health measures under the program or be 
assessed through an attestation similar to current attestations related 
to information blocking. Several commenters also noted our discussion 
of potentially establishing a set of ``health IT activities'' under the 
Promoting Interoperability Program (84 FR 7618) that would not be 
linked to performance measures, noting that such a concept would be 
well-suited to advancing patient event notifications. One commenter 
noted that the Promoting Interoperability Program, with its annual 
performance assessment, is more appropriate to supporting progress on 
technology goals than the CoPs, and that a measure reported annually 
could better assess the degree to which providers are improving their 
usage of patient event notifications.
    Commenters also recommended other alternative strategies that CMS 
could engage in to incentivize use of patient event notifications, such 
as models established under Innovation Center authority. Commenters 
believed that highlighting the use of patient event notifications in 
connection with alternative payment models could help to strengthen the 
business case for this intervention. Another commenter recommended that 
the use of patient event notifications could be incentivized through an 
offset or bonus in a hospital-focused quality program, or through 
offering regulatory flexibility (for instance around telehealth) to 
hospitals that choose to implement a system for notifications.
    Response: We appreciate commenters' suggestions to encourage the 
use of patient event notifications through the Promoting 
Interoperability Program. In order for an action to serve as the basis 
for a measure under the Promoting Interoperability Program, the action 
must require the use of certified health IT. As discussed in the CMS 
Interoperability and Patient Access proposed rule, at this time there 
is no certification criterion included in ONC's certification program 
for the creation and transmission of patient event notifications (84 FR 
7651). As discussed elsewhere in this final rule, ONC does not believe 
there is a widely adopted consensus standard for patient event 
notifications at this time. ONC will continue to monitor adoption of 
standards for this use case and consider whether it would be 
appropriate to develop a certification criterion for this 
functionality. Accordingly, we believe it would not be feasible to add 
a measure related to patient event notifications to the Promoting 
Interoperability Program at this time.
    We appreciate commenters input about other programs that could 
advance the use of patient event notifications, such as models 
established under Innovation Center authority, and will take these 
under consideration.
    Comment: Several commenters addressed the use of the ADT standard 
for patient event notifications. One commenter noted that the ADT 
messaging standard is very broad and that implementations are subject 
to significant variability and customization. Commenters highlighted 
the fact that there is significant variation in the implementation of 
the ADT standard, limiting interoperability across interfaces using 
this standard, and suggested that CMS clarify specific content and 
triggering events for ADT data exchange. Another commenter noted that 
the lack of an implementation guide for the use of ADT messages for 
notifications is challenging, as this guidance is essential for 
understanding what information must be sent and how. Commenters who 
believed that the reference to the ADT standard would require the 
establishment of new interfaces for exchanging ADT messages stated that 
recipient providers would not be able to receive ADT messages if they 
do not have an inbound ADT interface in place. Many commenters believed 
that specifying the HL7 2.5.1 ADT message standard would be overly 
restrictive and recommended that CMS not specify a specific standard 
for these transactions at this time. Commenters urged CMS to focus on 
creating functional requirements rather than identifying specific 
mechanisms or standards for

[[Page 25596]]

the data. Other commenters stated that any standard should be required 
as a floor, rather than a ceiling. One stakeholder recommended that CMS 
compile stakeholder feedback to better understand which standard would 
be preferred by the industry.
    Several commenters supported adoption of the ADT message standard 
(HL7 2.5.1), stating that it is the most frequently used standard for 
the transmission of patient event notifications. One commenter urged 
CMS to avoid policies that allow a hospital to deviate from a required 
standard, and to align with standards proposed by ONC to ensure 
consistency across different types of data exchange.
    One commenter suggested that CMS explore moving to later versions 
of the HL7 2.5.1 standard, which provide additional message types, 
segments, and codes while others noted that additional work will be 
needed by standards setting bodies such as HL7 to develop a more robust 
standard in the future.
    Other commenters supported the flexibility discussed in the CMS 
Interoperability and Patient Access proposed rule with respect to using 
other standards and features to support sending patient event 
notifications. One commenter supported the flexibility provided in the 
proposed rule, but believed that this flexibility may introduce 
challenges for those providers receiving and incorporating information 
provided by a hospital.
    Several commenters urged CMS to not require the use of certified 
EHR technology (CEHRT) to send ADT messages, noting that hospitals 
currently use a variety of solutions to send patient event 
notifications. One commenter noted that the HL7 protocol cannot be sent 
using Direct messaging or other exchanges used for continuity of care 
documents. One commenter noted that ADT information is not available in 
real time, and that an open API for both the hospital and receiving 
provider would be needed to enable real-time notifications. Commenters 
recommended that CMS instead focus on the use of standards-based feeds 
from the hospital's technology of choice.
    Response: We appreciate commenters' feedback. We recognized in the 
CMS Interoperability and Patient Access proposed rule that there is 
currently significant variation in how hospitals have utilized ADT 
messages to support implementation of patient event notifications (84 
FR 7651). In recognition of this current state, we proposed to require 
that a hospital would be subject to this CoP if its system complied 
with the ADT messaging standard, but we did not propose to require that 
hospitals use a specific standard to format or deliver patient event 
notifications. We believe this flexibility is necessary due to 
significant variation in how HL7 2.5.1 messages have been used to 
support notifications, and allows providers to use other standards for 
structuring and delivering this information that they may be currently 
using to implement patient event notifications, or may prefer to use 
for other reasons.
    As noted, our intent is to allow flexibility; therefore, we have 
refrained from specifying a standard for delivery of patient event 
notifications that could be overly limiting for hospitals. We are 
finalizing revised regulation text at 42 CFR 482.24(d), 482.61(f), and 
485.638(d) that specifies that a hospital system's conformance with the 
ADT standard will be used solely to determine whether a hospital is 
subject to the CoP. Requirements regarding the content and format of 
the patient event notifications, which a hospital's system must send to 
satisfy the CoP, are limited to the minimal information elements 
described elsewhere in this final rule. We are not specifying a 
standard for the content, format, or delivery of these notifications.
    We also note that we did not specify that hospitals must use a 
specific technology to send patient event notifications; for instance, 
we did not specify that a hospital must use the capabilities of 
certified health IT to send notifications, nor that hospitals must send 
notifications via an interface adhering to the HL7 messaging standard. 
We hope that this response addresses commenters' concerns, and 
clarifies that the reference to the HL7 messaging standard in these 
requirements does not preclude use of other standards for transporting 
patient event notifications. In addition, we note that our 
understanding is that many successful patient event notification 
implementations have used the content of HL7 messages in conjunction 
with other forms of transport, such as Direct messages.
    While we agree with commenters that common usage of a single, 
strictly defined standard would increase interoperability for these 
transactions, we do not believe that this is possible at this time. At 
the same time, we strongly encourage hospitals, and any intermediaries 
a hospital may partner with, to adopt standards-based approaches to the 
structure and transmission of patient event notifications, including 
the many standards-based solutions described by commenters. We 
acknowledge that, at this time, the use of different standards may 
result in decreased ability for certain providers to receive 
notifications from sending hospitals, depending on the attributes of 
their respective systems. We will consider whether there are additional 
ways we can encourage hospitals to move towards increased 
interoperability for these transactions in the future.
    We also wish to address and clarify a discrepancy in the way we 
referenced the ADT messaging standard in the proposed rule. 
Specifically, in the preamble of the proposed rule we cited 45 CFR 
170.299(f)(2), where the HL7 2.5.1 messaging standard is listed for 
incorporation by reference. However, in the regulation text of the 
proposed rule, we erroneously cited to 45 CFR 170.205(a)(4)(i), which 
contains the C-CDA standard instead of HL7 2.5.1. The C-CDA standard is 
referenced in certification criteria related to summary of care records 
(84 FR 7678). As discussed above, we are finalizing our policy that a 
hospital will be subject to the requirements in this section if it uses 
a system conformant with the HL7 2.5.1 content exchange standard, which 
indicates a system has the basic capacity to generate information for 
patient event notifications. In this final rule, we are revising the 
regulation text and finalizing a citation to the HL7 2.5.1 content 
exchange standard where it is currently referenced at 45 CFR 
170.205(d)(2). We believe that this citation is the most appropriate 
way to reference the HL7 2.5.1 standard.
    Comment: Several commenters requested that CMS indicate whether it 
would be acceptable to transmit information using other standards than 
the ADT message, specifically delivering messages using the C-CDA 
standard, which providers must use to satisfy the requirements of the 
transitions of care measures under the Promoting Interoperability 
Programs. Several commenters stated that they would prefer to format 
messages using this standard, which they already use for the Promoting 
Interoperability Program, and that a requirement to deliver messages 
according to the HL7 ADT messaging standard would result in duplicative 
work. Others questioned whether transmitting notifications via a 
FHIR[supreg]-based API would be permissible.
    Response: In the proposed rule, we stated that a hospital's medical 
records system is a compliant system if it utilizes the ADT messaging 
standard. However, we did not propose a specific format or standard for 
the patient event notification that a hospital would be required to 
send under the proposed CoP. Thus, hospitals would be allowed to 
transmit patient event notifications

[[Page 25597]]

using other standards, such as the C-CDA or via a FHIR-based API.
    Comment: Many commenters supported the inclusion of diagnosis in 
patient event notifications where permitted by law, stating that this 
information is helpful for supporting care coordination between a 
hospital and other providers. One commenter noted that this information 
can be included by leveraging certain segments of the HL7 ADT feed, and 
that this segment can also be filtered for sensitive diagnoses that are 
prohibited for transmission under certain state or federal laws.
    A number of commenters expressed concerns about requiring the 
inclusion of diagnosis, noting that hospitals may not have this 
information at the time of admission, when only the presenting symptom 
may be available, or immediately at discharge. Other commenters noted 
that while this is important information for improving care 
coordination, diagnosis is not included in the most basic versions of 
the HL7 ADT messaging standard. Other commenters noted that clinical 
data is more appropriate for transfer through other standards for 
sharing clinical data, such as the C-CDA standard, which is specified 
to support the exchange of clinical summaries using certified health 
IT. These commenters noted that rather than requiring the inclusion of 
diagnosis in the patient event notification, it would make more sense 
to allow hospitals to transfer this information by attaching a clinical 
summary to the notification, or by providing this information upon 
request from a receiving provider.
    Response: We agree with commenters that diagnosis is an important 
data element to share during care transitions. However, our intention 
for this proposal has been to set a minimal floor for patient event 
notifications, allowing for significant flexibility, in recognition of 
the wide variety of ways that providers are currently implementing 
patient event notifications. We are concerned that the proposed 
requirement to include diagnosis could introduce unnecessary burden for 
hospitals that will be seeking to satisfy this requirement utilizing 
the most basic information available in an ADT message to support 
patient event notifications. As a result, we are not finalizing a 
requirement that diagnosis must be included in patient event 
notifications at 42 CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2). 
We wish to reiterate that this final policy in no way precludes 
hospitals from including additional information, such as diagnosis, in 
a patient event notification. We also note that hospitals are required 
to send other necessary medical information to receiving providers 
under the hospital CoP on Discharge Planning at 42 CFR 482.43. In 
addition, certain clinical information such as diagnosis is included in 
the summary of care record which hospitals must be capable of 
transferring electronically in order to meet the health information 
exchange measures under the Promoting Interoperability Program.
    Comment: Several commenters suggested CMS require hospitals to 
include additional informational elements in patient event 
notifications, such as: Discharge disposition; chief complaint; 
medication profile; insurance policy coverage information; additional 
information about the hospital, such as address and tax ID; contact 
information for a variety of resources such as social services agencies 
and legal assistance providers; and other information that can be used 
for patient matching. Commenters believe that additional information 
would have a positive impact on care coordination. Other commenters 
supported the proposal to require only a limited data set. One 
commenter recommended that CMS impose additional parameters on the 
information included as part of patient event notifications, including 
a requirement that data must be recent and relevant to patient care.
    Response: We appreciate commenters' suggestions, and agree that 
this additional information can have a positive impact on care 
coordination, patient matching, and other requirements. However, we do 
not believe that this information should be required within the CoPs 
for patient event notifications. We have heard from many stakeholders 
that even patient event notifications with extremely limited 
information can have a positive effect on care coordination when they 
are delivered in a timely manner. In addition, we understand that 
hospitals are currently delivering patient event notifications with 
widely varying sets of information. Finally, we note that hospitals are 
required to send other necessary medical information to receiving 
providers under the hospital CoP on Discharge Planning at 42 CFR 
482.43. While we decline to require additional data at this time, to 
ensure that hospitals are able to satisfy the requirement with minimal 
effort, we encourage hospitals to consider other information that can 
be added to patient event notifications to support care coordination.
    Comment: Many commenters suggested that CMS work with ONC to add a 
certification criterion or a condition of certification related to the 
transmission of patient event notifications under ONC's certification 
program. Many commenters stated that hospitals should not be required 
to comply with the proposed requirements until they have had an 
opportunity to adopt certified technology supporting these 
requirements. Commenters believed this would assure hospitals that 
their systems are compliant with the proposed requirements. Moreover, 
commenters expressed concern that without complementary regulation 
directed toward health IT developers, the burden for ensuring these 
technical capabilities would rest on hospital providers alone. Some 
commenters suggested that ONC should also include data elements related 
to patient event notifications in the USCDI, or seek to standardize 
notification data elements in another way, to ensure that notifications 
can be received by other EHR systems. Commenters also pointed to a 
variety of emerging initiatives which focus on barriers to information 
exchange, such as TEFCA, policies to address information blocking, and 
updates to API technology under the ONC certification program. 
Commenters urged CMS to leverage these initiatives to advance the use 
of patient event notifications, for instance, by incorporating patient 
event notification functionality through the networks established as 
part of TEFCA.
    Response: We appreciate commenters' input. As we noted in the CMS 
Interoperability and Patient Access proposed rule, there is currently 
no certification criterion specific to creating and sending electronic 
patient event notifications included in ONC's certification program (84 
FR 7651). While ONC monitors the development of consensus standards for 
patient event notifications as part of its ISA (https://www.healthit.gov/isa/admission-discharge-and-transfer), ONC has not yet 
proposed to develop a certification criterion based on any of these 
standards. Instead of focusing on the use of a specific certification 
criterion, we have sought to allow hospitals flexibility in how they 
satisfy the proposed CoP. We believe this is consistent with current 
practices around patient event notifications that have been implemented 
in a wide variety of ways across hospitals. We appreciate that many 
other policy initiatives may intersect with how hospitals implement 
patient event notification requirements. While we believe that 
providers will be

[[Page 25598]]

able to implement patient event notifications based on existing systems 
and infrastructure, we believe that many of the initiatives commenters 
mentioned will help to enable and enhance notification capabilities as 
they are introduced.
    Comment: A number of commenters stated that the proposal would 
disproportionately burden rural and critical access hospitals. 
Commenters noted that providers in these settings may not have an EHR 
system, or may be unable to upgrade to the newest edition of certified 
technology. For small and rural providers that do have an EHR system, 
commenters expressed concern about the implementation costs providers 
would need to incur as they work with their EHR vendors to deploy new 
functionality. Commenters noted that, while working with an 
intermediary could substantially reduce the burden associated with this 
proposal, many small and rural hospitals are operating in geographic 
areas that are not yet served by entities such as health information 
exchanges that could serve as intermediaries, requiring these hospitals 
to dedicate significant resources to developing a compliant solution. 
This lack of access to appropriate infrastructure would put small and 
rural hospitals at disproportionate risk of noncompliance with the CoP 
standard, despite the significant effects penalties for noncompliance 
may have on underserved communities. Several commenters raised concerns 
about these providers' ability to shoulder compliance costs with the 
proposed requirements, and suggested CMS provide funding opportunities 
to these hospitals to mitigate the potential burden associated with the 
proposal.
    Response: We appreciate commenters' concerns about the impact of 
this proposal on small, rural, and critical access hospitals (CAHs). We 
note that those hospitals without an EHR system with the technical 
capacity to generate information for electronic patient event 
notifications, defined as a system conformant with the ADT messaging 
standard (HL7 2.5.1), will not be subject to this final rule. 
Furthermore, we believe that changes finalized in this rule will ease 
some of the potential compliance burden associated with the rule, and 
make it easier for these hospitals to comply successfully with the CoP 
standard. For example, our final policy extends the applicable date for 
the requirements as well as defining a more limited set of a recipients 
to whom hospitals must send notifications for the purposes of 
compliance with the CoP.
    Comment: Many commenters noted that patient event notifications are 
most effective when they take into account receiving providers' 
preferences. Commenters noted that recipients need flexibility to 
determine the information that they want to be notified about, the 
frequency of notification delivery, and how they would like 
notifications delivered; otherwise providers may experience ``signal 
fatigue'' due to receiving an excessive number of messages that do not 
contain information the provider finds useful. Commenters expressed 
concern that, under the proposed requirements, hospitals would not have 
flexibility to take into account receiving providers' preferences for 
receiving patient event notifications. They further believed that the 
proposed requirements would result in hospitals sending information to 
all providers regardless of their interest in receiving notifications, 
while implementation experience has shown that notifications are more 
successful when receiving providers can request the information they 
would like to receive.
    Response: We appreciate commenters' concerns about the importance 
of incorporating provider recipients' preferences when implementing 
patient notification systems. We understand from stakeholders that a 
key feature of successful patient event notification implementations is 
flexibility with respect to the manner in which notifications are 
delivered, to allow for better alignment with individual providers' 
workflows. Without such flexibility, providers are more likely not to 
find notification systems useful, reducing their effectiveness to 
improve care coordination.
    We note that under the proposed requirement, hospital systems must 
send patient notifications in accordance with the proposed 
requirements. However, this would not preclude hospitals, working 
either directly with providers or through an intermediary, from 
tailoring the delivery of patient notifications in a manner consistent 
with individual provider preferences. For instance, while a hospital's 
system must be able to send notifications at both admission and 
discharge, as well as at the time of registration in the emergency 
department, if a specific provider prefers only to receive 
notifications upon discharge, nothing would prevent the hospital from 
limiting the notifications sent to that provider accordingly.
    We note that our revised regulation text states that hospitals must 
send notifications to those recipients that ``need to receive 
notification of the patient's status for treatment, care coordination, 
or quality improvement purposes.'' We believe that this standard will 
allow hospitals the discretion to determine which recipients need to 
receive notifications, for instance, by declining to send certain 
notifications where a practitioner has stated that such notifications 
are not necessary or effective for supporting care coordination. In 
cases where the hospital has partnered with an intermediary to deliver 
notifications, the intermediary may exercise this discretion on behalf 
of a hospital.
    Comment: Many commenters supported the proposal to allow use of an 
intermediary to deliver patient event notifications. Commenters stated 
that use of an intermediary could reduce operational burden on 
hospitals by maintaining recipient information, supporting more 
effective patient matching, and delivering notifications in accordance 
with receiving providers' preferences. Commenters pointed to numerous 
examples of how intermediaries, such as health information exchanges, 
are successfully facilitating the delivery of more complete and 
accurate patient event notifications from today.
    Response: We thank commenters for their support and agree that the 
use of intermediaries to deliver patient notifications can reduce 
burden on hospitals and support effective notification systems.
    Comment: Several commenters sought additional information on our 
proposals with respect to the use of an intermediary, and whether 
exclusive use of an intermediary, provided other requirements are met, 
would satisfy the CoP. Commenters stated that they believe hospitals 
should be able to exclusively make use of an intermediary. Other 
commenters suggested that CMS should ``deem'' a hospital compliant with 
the CoP if they demonstrate that they are using an intermediary to 
deliver notifications, as long as the intermediary has not been found 
to violate information blocking rules.
    Response: In the CMS Interoperability and Patient Access proposed 
rule, we stated that, if finalized, hospitals would be required to send 
notifications ``directly or through an intermediary that facilitates 
exchange of health information.'' We believe this would allow exclusive 
use of either method, or a combination of these methods, provided other 
requirements of the CoP are met. For instance, if a hospital makes 
exclusive use of an intermediary to satisfy the CoP, the hospital would 
still be subject to the requirement that

[[Page 25599]]

notifications must be sent to the set of recipients we are finalizing 
in this rule, specifically all applicable post-acute care services 
providers and suppliers as well as a patients' primary care 
practitioners or practice groups and entities primarily responsible for 
a patient's care, as well as practitioners identified by the patient. 
Given this requirement, exclusive use of an intermediary with a limited 
ability to deliver notifications to the specified set of recipients, 
for instance an intermediary which restricts its delivery to only those 
providers within a specific integrated health care system, would not 
satisfy the CoP. Alternatively, if a hospital demonstrates that an 
intermediary connects to a wide range of recipients and does not impose 
restrictions on which recipients are able to receive notifications 
through the intermediary, exclusive use of such an intermediary would 
satisfy the CoP.
    Comment: Commenters sought additional information on whether it 
would be permissible for a hospital to delegate responsibility for 
making a determination about the existence of a patient's care 
relationships to an intermediary that facilitates delivery of a patient 
notification.
    Response: In the CMS Interoperability and Patient Access proposed 
rule we discussed a variety of methods through which hospitals can 
identify recipients for patient notifications, including through 
partnering with intermediaries such as health information exchanges (84 
FR 7652). We reiterate that we believe this is one way that hospitals 
are currently identifying recipients for notifications, and that using 
an intermediary to do so may reduce operational burden for hospitals. 
Thus, hospitals would be permitted to delegate this authority.
    Comment: Several commenters requested additional information on 
whether ACOs would be entitled to receive patient event notifications. 
Commenters stated that ACOs represent groups of providers and suppliers 
and work directly on their behalf. Therefore, it was unclear whether 
they would be considered intermediaries or providers and suppliers for 
the purposes of the proposed CoP. Commenters stated that patient event 
notifications are used by many ACOs today, and that ACOs both receive 
notifications directly from hospitals and through other intermediaries 
such as health information exchanges.
    Response: We note that the proposed CoP does not create an 
entitlement for any specific provider or intermediary to receive 
patient event notifications. Rather, it requires hospitals to 
demonstrate that their medical records system sends patient event 
notifications in a manner compliant with the proposed requirements. We 
believe there is nothing in the proposed requirements that would 
prevent ACOs that have business associate relationships with the 
intended primary care practitioner or practice group or entity from 
receiving patient event notifications on behalf of that practitioner, 
group, or entity so long as their business associate agreement allows 
them to fulfill that role.
    Comment: Several commenters suggested that CMS should develop a 
mechanism for allowing community providers to report that they have not 
received notifications from a given hospital, or that the notifications 
received are incomplete or unreasonably delayed. Commenters believe 
that such a mechanism would ensure patient event notification systems 
are functional and help to establish delivery parameters across a 
community.
    Response: We appreciate commenters' input, but are unclear here as 
to whether the commenters are requesting that we develop a regulatory 
mechanism within the CoP provisions to allow for a community provider 
to report to a hospital any issues it may be experiencing with the 
hospital's notification system or if the request is for CMS to develop 
some other type of mechanism to accomplish this, such as an incentive-
based payment mechanism as a means of encouraging a hospital to include 
this reporting function as part of its notification system. If it is 
the latter type of request, then such a mechanism would be outside the 
scope of the CoPs and this section of the rule. However, if it is the 
former type of request, we will consider these ideas as we evaluate 
future updates and revisions to the CoPs with regard to patient event 
notifications.
    Comment: We proposed that a hospital would only need to send 
notifications to those practitioners for whom the hospital has 
reasonable certainty of receipt (84 FR 7652). We further explained that 
we expected hospitals would, to the best of their ability, seek to 
ensure that notification recipients were able to receive notifications, 
but that we recognized that factors outside of the hospital's control 
may determine whether or not a notification was successfully received 
and utilized by a practitioner.
    Many commenters stated that a standard of ``reasonable certainty'' 
would hold hospitals responsible for factors outside of their control 
that prevent delivery of notifications, and that hospitals should only 
be held accountable for transmission of information, not receipt. 
Commenters stated that it would be very difficult for hospitals to 
obtain reasonable certainty given the limitations of the infrastructure 
that is currently available for sharing health information. Several 
commenters believed that the phrase ``reasonable certainty'' would 
impose a new affirmative duty to validate receipt of notifications, 
which would result in significant additional administrative burden for 
hospitals. Several commenters suggested that CMS replace the term 
``reasonable certainty'' with alternatives such as ``reasonable 
effort'' or ``reasonable confidence.'' They believed these alternative 
standards would better reflect actions within the hospital's control.
    Response: We appreciate commenters' feedback. In proposing that 
hospitals send notifications to those practitioners for whom the 
hospital has reasonable certainty of receipt, we sought to adapt a 
similar standard currently identified in guidance for the Promoting 
Interoperability Program (see https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/MedicareEH_2019_Obj2-.pdf) regarding the expectations of participants 
in that program when they transfer a summary of care record to another 
provider. However, we concur with commenters that a standard of 
``reasonable certainty,'' while appropriate for the Promoting 
Interoperability Program, in which participants are required to use 
certified technology for the transmission and receipt of summary of 
care documents, may not be appropriate in the context of this proposal, 
which permits flexibility in both the technology used to send and 
receive patient event notifications and the format of the notification 
itself. We agree that a standard that better reflects actions within 
the hospital's control would be much more appropriate in this 
circumstance. Accordingly, we are revising our final policy (at 42 CFR 
482.24(d)(5), 482.61(f)(5), and 485.638(d)(5)) to now require that a 
hospital (or a CAH) must demonstrate that it ``has made a reasonable 
effort to ensure that'' the system sends the notifications to any of 
the following that need to receive notification of the patient's status 
for treatment, care coordination, or quality improvement purposes to 
all applicable post-acute care services providers and suppliers and: 
(1) The patient's established primary care practitioner; (2) the 
patient's established primary care practice group or entity; or (3) 
other

[[Page 25600]]

practitioner, or other practice group or entity, identified by the 
patient as the practitioner, or practice group or entity, primarily 
responsible for his or her care.
    We believe that this modified standard will provide hospitals and 
CAHs with appropriate flexibility and can account for the constraints 
of providers' existing systems. We also believe that this modified 
standard takes into account the fact that some recipients may not be 
able to receive patient event notifications, or may not be able to 
receive notifications in a manner consistent with a hospital system's 
capabilities, and the fact that hospitals and CAHs may not be able to 
identify provider recipients for some patients. We expect that 
surveyors will evaluate whether a hospital is making a reasonable 
effort to send patient event notifications while working within the 
constraints of its existing technology infrastructure.
    Comment: Several commenters offered their assessments of readiness 
across hospitals to implement patient event notifications. One 
commenter pointed to hospitals' high levels of engagement in some form 
of health information exchange as an indication that hospitals are 
well-positioned to distribute patient event notifications, and stated 
that establishing ADT-based notification feeds did not impose 
significant burdens on hospitals. Another commenter agreed that the 
technical capabilities to implement notifications exists today, and 
stated that the primary challenge for hospitals would be in updating 
business and operational practices to comply.
    Other commenters stated that functionality to use ADT message 
information for patient event notifications is not part of certified 
electronic health record technology and that not all EHRs are capable 
of generating notifications. They stated that EHRs are not able to 
automatically send and receive notifications and cautioned CMS against 
oversimplifying the development burden associated with implementation. 
One commenter suggested that CMS should provide supplemental funding to 
support hospitals' costs, workflow changes, and technical expertise 
associated with implementation.
    Response: We thank commenters for their insights. We share the 
assessment of commenters who stated that most hospitals will be able to 
implement patient event notifications with minimal burden due to the 
widespread adoption of technology systems that can be utilized to 
support generating and sending these notifications. Patient event 
notifications have been widely recognized as an important way to 
support patient safety, by enabling providers and suppliers responsible 
for the post-discharge care of a patient to quickly initiate care 
coordination protocols that can mitigate the risk of deterioration of a 
patient's condition following a hospital stay. We understand some 
commenters' concerns that the ability to send patient event 
notifications has not been included as a capability certified under the 
ONC certification program, and that there is no widely adopted, uniform 
approach to sending patient event notifications at this time. However, 
as noted by many commenters, we believe there are a wide variety of 
available, low-cost solutions that providers can adopt to fulfill the 
minimal requirements described in this final rule. Accordingly, we have 
provided significant flexibility for providers to meet these 
requirements by not including additional technical specifications about 
how patient event notifications must be formatted and shared. We 
believe that this approach allows flexibility for hospitals to 
establish patient event notifications that meet the requirements in 
ways that minimize implementation burden; however, we recognize that 
the lack of a uniform approach may lead to instances where a provider 
is unable to receive notifications sent by a hospital in a seamless, 
interoperable fashion.
    Comment: Commenters stated that national infrastructure for health 
information exchange was not yet mature enough to support the 
widespread implementation of patient event notifications and that 
successful implementation of notifications requires the ability to 
acquire data feeds and a rules engine to support alerting routing and 
delivery, as well as a patient index function to create and verify 
patient panels. While many commenters believed that this infrastructure 
might be available in the future, for instance, through establishment 
of the TEFCA, they stated that it is not ubiquitous today. Without this 
infrastructure, commenters noted that providers would be required to 
support a large number of point-to-point interfaces with other 
providers that lack scalability, and will be highly costly, 
inefficient, and burdensome to develop and maintain. One commenter 
recommended that CMS establish that, for compliance purposes, a 
hospital would only be required to demonstrate a notification has been 
sent for a single patient. This would allow surveyors to confirm that 
the system is functional while allowing for variation across hospitals 
depending on their capabilities to send notifications under different 
circumstances. One commenter suggested that CMS should focus on 
incentivizing providers to participate in existing scalable networks 
that support health information exchange, including patient event 
notifications.
    Response: We agree with commenters that the national health 
information exchange infrastructure to support patient event 
notifications is not yet ubiquitous. However, we believe that the 
health information infrastructure that exists today will be sufficient 
to provide substantial support for the requirements we are finalizing 
in this rule. As other commenters noted, organizations such as health 
information exchanges are supporting the sharing of patient event 
notifications in many areas today. While we understand there is 
variation in availability of this infrastructure, we believe there are 
options increasingly available for hospitals to implement basic patient 
event notifications that will allow hospitals to demonstrate they have 
made a ``reasonable effort'' to ensure their system sends the required 
notifications, as per the policy finalized in this final rule.
    We appreciate the suggestion that the CoP should specify a hospital 
could achieve compliance through demonstrating that a notification has 
been sent for a single patient, and that this would ease compliance 
concerns expressed by stakeholders. However, we believe that these 
concerns are addressed through the more limited standard in our final 
policy that requires a hospital (or CAH) to make a ``reasonable 
effort'' to ensure that its system sends these notifications. In 
addition, and as previously noted, survey and certification 
interpretive guidelines utilize a variety of approaches to evaluate 
whether a hospital has satisfied the CoP, and in this final rule we 
decline to employ overly prescriptive regulatory language that might 
significantly limit options for surveyors as they assess compliance.
    Comment: Many commenters identified challenges related to the 
proposal that a hospital demonstrate that its system sends 
notifications to licensed and qualified practitioners, other patient 
care team members, and post-acute care services providers and suppliers 
meeting certain conditions (84 FR 7651). Commenters stated that the 
proposal seemed to require a hospital to be able to send a notification 
to any other health care provider and assumed that the receiving 
provider would have the technological capabilities to receive this 
information. Commenters stated that this is not realistic given the 
current

[[Page 25601]]

state of technology adoption among receiving providers, and that 
recipients would need to develop capabilities to receive, incorporate, 
and use these notifications for the proposal to be effective.
    Commenters stated that, today, notifications would only be likely 
to reach recipients only a percentage of the time citing many factors 
related to the limitations of EHR technology that prevent providers and 
clinicians from incorporating electronic information into their EHRs. 
For instance, commenters noted that EHRs must be able to confidentially 
match transferred data to a patient, incorporate the notification into 
the EHR, and ensure that it is reviewed and stored in a clinically 
appropriate way to ensure it is effectively used. Commenters stated 
that CMS should consider complementary requirements and/or supports for 
ambulatory and other facilities to ensure they are able to receive 
patient event notifications provided by hospitals. Commenters requested 
additional information on the expectations for receiving providers to 
successfully receive and incorporate patient event notifications, and 
noted they may face significant burden associated with technical 
development if expected to be able to receive these notifications.
    Moreover, commenters expressed concerns about the capacity of 
specific providers, including small and rural physician practices and 
post-acute care providers and suppliers, to receive patient event 
notifications. Commenters specifically noted that post-acute care 
providers were not provided financial incentives under the HITECH, and 
therefore many post-acute care providers are not using EHRs or are 
using EHRs that are not able to exchange information with hospital 
EHRs. Several commenters recommended that CMS not hold hospitals 
accountable for delivering patient event notifications to post-acute 
care suppliers, given the difficulties these suppliers would have in 
receiving these notifications. Others stated that the inability of 
these providers to receive notifications would limit the effectiveness 
of the proposed requirements.
    Response: We appreciate commenters input on this issue. In the CMS 
Interoperability and Patient Access proposed rule, we stated that a 
hospital subject to the proposed requirements must demonstrate that its 
system sends notifications to certain recipients. We do not expect that 
a hospital would ``demonstrate'' that its system meets these 
requirements through meeting a comprehensive measure of performance. 
Likewise, we would not expect a hospital's system to be capable of 
electronically communicating with every possible provider, facility, or 
practitioner system, or of satisfying every possible preference for 
delivery of patient event notifications that a provider, facility, or 
practitioner might attempt to impose on the hospital. As noted above, 
we are modifying our proposal to require that a hospital makes a 
``reasonable effort'' to ensure that its system sends patient event 
notifications to the specified recipients.
    Under the survey and certification process we would expect a 
hospital to demonstrate its system's compliance with the CoP in a 
variety of ways, subject to the system's capabilities. For instance, if 
a given system sends notifications via Direct messaging, we might 
expect surveyors to review whether the hospital has a process in place 
for capturing Direct addresses of patients' primary care practitioners 
to enable the system to send patient event notifications to these 
recipients.
    Finally, with regard to comments about PAC services providers and 
suppliers that were not eligible for incentives for EHR adoption under 
the EHR Incentive Programs established by the HITECH Act, we again note 
that the requirements in this final rule are limited to only those 
hospitals and CAHs that possess and utilize EHR or other administrative 
systems with the technical capacity to generate information for 
electronic patient event notifications. Moreover, a hospital or CAH 
with such a system must only demonstrate that it has made a 
``reasonable effort'' to ensure that its system sends notifications to 
any of the specified recipients, including all applicable post-acute 
care services providers and suppliers (that is, to those PAC services 
providers and suppliers to whom the patient is being transferred or 
referred).
    Comment: In the CMS Interoperability and Patient Access proposed 
rule, we did not explicitly address the effective implementation date 
for the proposed revisions to the CoPs. However, we note that revisions 
to the CoPs are generally applicable 60 days from the publication of a 
final rule.
    Many commenters recommended CMS allow additional time for 
implementation beyond the usual applicable date of these revisions. 
Commenters stated that additional time was required to allow providers 
to complete technical upgrades and train staff on new workflows. One 
commenter suggested that CMS finalize different timeframes based on 
whether hospitals are in an area with existing infrastructure for 
transmitting patient event notifications. Another commenter suggested 
that CMS develop working groups to determine appropriate timelines for 
implementation.
    Response: We agree with commenters that additional time would be 
appropriate for hospitals and CAHs to implement the proposed 
requirements. Therefore, we are finalizing that the requirements will 
be applicable 12 months after the publication date of this final rule.
    Comment: Multiple commenters addressed privacy implications of the 
proposed requirements. Commenters sought clarity on whether patient 
consent would be required to send a patient event notification, or 
whether hospitals would be able to honor a patient's request to opt-out 
of sharing information with providers in the form of a patient event 
notification. Commenters urged CMS to issue further guidance about 
privacy and security challenges associated with sending patient event 
notifications, for instance, how hospitals should address cases where 
they cannot confirm the identity of a provider, and/or where 
transmission could risk improper disclosure of protected health 
information. Several commenters suggested that concerns about 
noncompliance could lead some hospitals to be overly hasty in sending 
patient event notifications without considering the privacy impact of 
the transmission, potentially leading to inappropriate disclosures of 
information.
    Response: We appreciate commenters' concerns about preserving 
patient privacy. Nothing in this proposed rule should be construed to 
supersede hospitals' compliance with HIPAA or other state or federal 
laws and regulations related to the privacy of patient information. We 
note that hospitals would not be required to obtain patient consent for 
sending a patient event notification for treatment, care coordination, 
or quality improvement purposes as described in this final policy. 
However, we also recognize that it is important for hospitals to be 
able to honor patient preferences to not share their information. While 
the CoP would require hospitals to demonstrate that their systems can 
send patient event notifications, we do not intend to prevent a 
hospital from recording a patient's request to not share their 
information with another provider, and, where consistent with other 
law, restrict the delivery of notifications as requested by the patient 
and consistent with the individual right to request restriction of uses 
and disclosures established in the

[[Page 25602]]

HIPAA Privacy Rule. Similarly, if a hospital is working with an 
intermediary to deliver patient event notifications, the intermediary 
may record information about a patient's preferences for how their 
information is shared, and, where consistent with other law, restrict 
the delivery of notifications accordingly. Based on commenters' 
concerns regarding a patient's ability to request that his or her 
medical information (in the form of a patient event notification) is 
not shared with other settings, we are revising and finalizing a 
requirement in this rule that a hospital (or CAH) must demonstrate that 
its notification system sends notifications, ``to the extent 
permissible under applicable federal and state law and regulations and 
not inconsistent with the patient's expressed privacy preferences.''
    Regarding improper disclosure of health information where a 
hospital cannot confirm the identity of a receiving provider, we note 
that under this policy a hospital would not be under any obligation to 
send a patient event notification in this case. Under our final policy, 
hospitals would be required to make a ``reasonable effort'' to ensure 
their systems send notifications to the specified recipients. We 
believe this standard will account for instances in which a hospital 
(or its intermediary) cannot identify an appropriate recipient for a 
patient event notification despite establishing processes for 
identifying recipients, and thus is unable to send a notification for a 
given patient.
    Comment: Many commenters raised concerns about how hospitals would 
be able to implement the proposed patient event notifications while 
complying with state and federal laws and regulations around the 
transmission of sensitive data. Commenters noted these issues are 
particularly relevant for psychiatric hospitals included in the 
proposal. Commenters noted that some states have more stringent privacy 
and consent requirements that apply to individuals treated in mental 
health facilities which may impact the sending of patient event 
notifications. One commenter noted that hospitals with behavioral 
health units do not disclose patient event information as part of their 
primary system data feed due to requirements that disclosure of this 
information must be accompanied by written consent. Commenters also 
noted that appropriately segregating this data is expensive and time 
consuming.
    Response: Nothing in this requirement should be construed as 
conflicting with hospitals' ability to comply with laws and regulations 
restricting the sharing of sensitive information. While hospitals 
subject to the CoP would need to demonstrate their system sends 
notifications to appropriate recipients, hospitals would not be 
expected to share patient information through a notification unless 
they have obtained any consents necessary to comply with existing laws 
and regulations.
    Comment: Many commenters supported the proposal to require a 
hospital's system demonstrate that it sends patient event notifications 
at the time of admission, and at, or just prior to, the time of 
discharge. Commenters emphasized that it is important for notification 
information to be timely in order for it to be effective in improving 
care coordination. One commenter stated that some providers find that 
notifications triggered by an ADT message are triggered too early, 
prior to the availability of a discharge summary, and sought additional 
information about whether hospitals may use other triggers for a 
patient event notification.
    Response: We appreciate commenters' support for the proposal. We 
believe patient event notifications are most useful when tied to 
admission (or registration, as is the term generally used for patients 
seen in the ED) and discharge events, as receiving near-real time 
information about a patient's hospitalization can ensure receiving 
providers, facilities, and practitioners are able to act quickly to 
ensure successful care coordination. While we agree that sending 
available clinical information along with a patient event notification 
can be helpful, we believe that delaying notifications until all of the 
information about a patient's hospitalization is available would likely 
decrease the value of the notification.
    Comment: Several commenters suggested that the requirements should 
be limited to external providers and not include providers that may 
share the same EHR as the hospital as part of an integrated delivery 
system. Commenters noted that organizations may have other ways to 
notify these providers about a discharge, and that hospitals should be 
exempt from sending notifications to these providers.
    Response: Under the proposed requirements, we are not specifying a 
format or transport method for patient event notifications. 
Accordingly, hospitals could use a mix of approaches to deliver patient 
event notifications, for instance, by partnering with an intermediary 
to deliver notifications to external providers, while using features 
internal to a shared EHR system to transmit information to providers 
that are part of the same organization.
    Comment: Several commenters sought clarity on how the patient event 
notifications would relate to information blocking policy, and urged 
CMS to ensure that any new CoP requirements are aligned with other 
policies around information blocking. Several commenters suggested 
that, as an alternative to the proposed requirements, CMS should 
establish a standard under the CoPs that states hospitals will not 
engage in information blocking, to be aligned with policies established 
by ONC in the 21st Century Cures Act final rule.
    Response: We note that there are currently three prevention of 
information blocking attestation statements under 42 CFR 
495.40(b)(2)(i)(I)(1) through (3) to which eligible hospitals and CAHs 
must attest for purposes of the Promoting Interoperability Program. As 
part of successfully demonstrating that an eligible hospital or CAH is 
a meaningful EHR user for purposes of the Promoting Interoperability 
Program, the eligible hospital or CAH must submit an attestation 
response of ``yes'' for each of these statements. These attestations 
are discussed further in section VIII. of this final rule. We also 
refer commenters to section 3022(b)(2)(B) of the Public Health Service 
Act (PHSA), which provides that any health care provider determined by 
the OIG to have committed information blocking shall be referred to the 
appropriate agency to be subject to appropriate disincentives using 
authorities under applicable federal law, as set forth by the Secretary 
through notice and comment rulemaking. Further, we refer commenters to 
the ONC 21st Century Cures Act proposed rule for additional discussion 
on disincentives (84 FR 7553).
    Final Action: After consideration of the comments received, and for 
the reasons outlined in our response to these comments and in the CMS 
Interoperability and Patient Access proposed rule, we are finalizing 
these proposals with some modifications and reorganization of the 
provisions. These policies are being finalized at 42 CFR 482.24(d), 
482.61(f), and 485.638(d) for Conditions of Participation for 
hospitals, psychiatric hospitals, and specialized providers (CAHs).
    Based on public comments, and to further advance electronic 
exchange of information that supports effective transitions of care for 
patients between hospitals and CAHs and their community PAC services 
providers and suppliers as well as their primary care practitioners, 
the following requirements at 42 CFR 482.24(d),

[[Page 25603]]

482.61(f), and 485.638(d) are being finalized here with modifications 
and reorganization from the proposed requirements (84 FR 7678):
     We are revising 42 CFR 482.24(d) by deleting the reference 
to ``paragraph (d)(2) of this section'';
     We are revising 42 CFR 482.61(f) by deleting the reference 
to ``paragraph (d)(2) of this section'';
     We are revising 42 CFR 485.638(d) by deleting the 
reference to ``paragraph (d)(2) of this section'';
     We are revising 42 CFR 482.24(d) by adding new language to 
the regulatory text so that it now includes ``or other electronic 
administrative system, which is conformant with the content exchange 
standard at 45 CFR 170.205(d)(2),'';
     We are revising 42 CFR 482.61(f) by adding new language to 
the regulatory text so that it now includes ``or other electronic 
administrative system, which is conformant with the content exchange 
standard at 45 CFR 170.205(d)(2),'';
     We are revising 42 CFR 485.638(d) by adding new language 
to the regulatory text so that it now includes ``or other electronic 
administrative system, which is conformant with the content exchange 
standard at 45 CFR 170.205(d)(2),'';
     We are deleting all of the regulatory text proposed at 42 
CFR 482.24(d)(2), 482.61(f)(2), and 485.638(d)(2), including the 
inaccurate references to ``45 CFR 170.205(a)(4)(i);''
     We are redesignating 42 CFR 482.24(d)(3), 482.61(f)(3), 
and 485.638(d)(3) as 42 CFR 482.24(d)(2), 482.61(f)(2), and 
485.638(d)(2), respectively, and also revising the regulatory text to 
now state that the system sends notifications that must include at 
least patient name, treating practitioner name, and sending institution 
name;
     We are redesignating 42 CFR 482.24(d)(4), 482.61(f)(4), 
and 485.638(d)(4) as 42 CFR 482.24(d)(3), 482.61(f)(3), and 
485.638(d)(3), respectively, and also revising the regulatory text to 
now state that, ``to the extent permissible under applicable federal 
and state law and regulations, and not inconsistent with the patient's 
expressed privacy preferences, the system sends notifications directly, 
or through an intermediary that facilitates exchange of health 
information, at the time of: the patient's registration in the 
hospital's [or CAH's] emergency department (if applicable); or the 
patient's admission to the hospital's [or CAH's] inpatient services (if 
applicable).''
     We are redesignating 42 CFR 482.24(d)(5), 482.61(f)(5), 
and 485.638(d)(5) as 42 CFR 482.24(d)(4), 482.61(f)(4), and 
485.638(d)(4), respectively, and also revising the regulatory text to 
state that, ``to the extent permissible under applicable federal and 
state law and regulations, and not inconsistent with the patient's 
expressed privacy preferences, the system sends notifications directly, 
or through an intermediary that facilitates exchange of health 
information, at the time of: the patient's discharge or transfer from 
the hospital's [or CAH's] emergency department (if applicable): or the 
patient's discharge or transfer from the hospital's [or CAH's] 
inpatient services (if applicable).''
     We are deleting the regulatory text proposed at 42 CFR 
482.24(d)(5), 482.61(f)(5), and 485.638(d)(5) and adding new regulatory 
text to state that, ``the hospital [or CAH] has made a reasonable 
effort to ensure that the system sends the notifications to all 
applicable post-acute care services providers and suppliers, as well as 
to any of the following practitioners and entities, which need to 
receive notification of the patient's status for treatment, care 
coordination, or quality improvement purposes: the patient's 
established primary care practitioner; the patient's established 
primary care practice group or entity; or other practitioner, or other 
practice group or entity, identified by the patient as the 
practitioner, or practice group or entity, primarily responsible for 
his or her care.''
    Finally, recognizing that hospitals, including psychiatric 
hospitals and CAHs, are on the front lines of the COVID-19 public 
health emergency, and in response to the number of comments received 
regarding concerns with the applicability date for this rule, we are 
establishing an applicability date of 12 months after finalization of 
this rule for hospitals, including psychiatric hospitals, and CAHs to 
allow for adequate and additional time for these institutions, 
especially small and/or rural hospitals as well as CAHs, to come into 
compliance with the new requirements.

XI. Provisions of the Final Regulations

    Generally, this final rule incorporates the provisions of the CMS 
Interoperability and Patient Access proposed rule as proposed. The 
following provisions of this final rule differ from the proposed rule.
    We are finalizing four proposals with modifications.
    1. We are requiring MA organizations, Medicaid managed care plans, 
CHIP managed care entities, and QHP issuers on the FFEs to maintain a 
process for the electronic exchange of, at a minimum, the data classes 
and elements included in the content and vocabulary standard finalized 
by HHS in the ONC 21st Century Cures Act final rule (published 
elsewhere in this issue of the Federal Register) at 45 CFR 170.213 
(currently version 1 of the USCDI), via a payer-to-payer data exchanged 
as outlined in this section V. of this final rule. Specifically, we are 
finalizing as proposed that impacted payers incorporate the data they 
receive into the enrollee's record. We are finalizing that with the 
approval and at the direction of a current or former enrollee, a payer 
must send the defined information set to any other payer. In addition, 
we specify that a payer is only obligated to send data received from 
another payer under this policy in the electronic form and format it 
was received.
    Starting January 1, 2022, and for QHP issuers on the FFEs starting 
with plan years beginning on or after January 1, 2022, the finalized 
regulation requires these payers to make data available with a date of 
service on or after January 1, 2016 that meets the requirements of this 
section and which the payer maintains. In this way, payers only have to 
prepare an initial historical set of data for sharing via this payer-
to-payer data exchange policy that is consistent with the data set to 
be available through the Patient Access API, as finalized in section 
III. of this final rule.
    2. Regarding the Patient Access API, we are finalizing requirements 
for MA organizations, Medicaid and CHIP FFS programs, Medicaid managed 
care plans, CHIP managed care entities, and QHP issuers on the FFEs to 
implement and maintain a standards-based Patient Access API that meets 
the technical standards as finalized by HHS in the ONC 21st Century 
Cures Act final rule (published elsewhere in this issue of the Federal 
Register) at 45 CFR 170.215, that include the data elements specified 
in this final rule, and that permit third-party applications to 
retrieve, with the approval and at the direction of a current enrollee, 
data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221. 
Specifically, we are finalizing that the Patient Access API must, at a 
minimum, make available adjudicated claims; encounters with capitated 
providers; provider remittances; enrollee cost-sharing; and clinical 
data, including laboratory results (where maintained by the impacted 
payer). We are not finalizing a requirement to include Provider 
Directory information as part of the

[[Page 25604]]

Patient Access API. Instead, to limit burden, we are only requiring 
provider and, in the case of MA-PD plans, pharmacy directory 
information, be included in the Provider Directory API discussed in 
section IV. of this final rule. Data via the Patient Access API must be 
made available no later than one (1) business day after a claim is 
adjudicated or encounter data are received by the impacted payer. We 
are finalizing that MA organizations, Medicaid state agencies, Medicaid 
managed care plans, CHIP state agencies, and CHIP managed care entities 
must make available the date they maintain with a date of service on or 
after January 1, 2016 beginning January 1, 2021, and for QHP issuers on 
the FFEs beginning with plan years beginning on or after January 1, 
2021.
    3. We are finalizing a Provider Directory API for MA organizations, 
Medicaid state agencies, Medicaid managed care plans, CHIP state 
agencies, and CHIP managed care entities making standardized 
information about their provider networks available via a FHIR-based 
API conformant with the technical standards finalized by HHS in the ONC 
21st Century Cures Act final rule (published elsewhere in this issue of 
the Federal Register) at 45 CFR 170.215 (which include HL7 FHIR Release 
4.0.1), excluding the security protocols related to user authentication 
and authorization, or any other protocols that restrict the 
availability of this information to anyone wishing to access it. At a 
minimum, these payers must make available via the Provider Directory 
API provider names, addresses, phone numbers, and specialties. For MA 
organizations that offer MA-PD plans, they must also make available, at 
a minimum, pharmacy directory data, including the pharmacy name, 
address, phone number, number of pharmacies in the network, and mix 
(specifically the type of pharmacy, such as ``retail pharmacy''). This 
Provider Directory API must be fully implemented by January 1, 2021 for 
all payers subject to this new requirement. Under this final rule, MA 
organizations, Medicaid and CHIP FFS programs, Medicaid managed care 
plans, and CHIP managed care entities must make the Provider Directory 
API accessible via a public-facing digital endpoint on their website to 
ensure public discovery and access.
    Modifications being finalized for the timelines for these policies 
will provide impacted payers ample time to build and test the required 
standards-based APIs to meet the new API requirements. In addition, 
providing more time for payer-to-payer data exchange between impacted 
payers will ensure successful implementation, and better enable plans 
to use a standards-based API to meet this requirement if they so 
choose. We are not finalizing the Care Coordination through Trusted 
Exchange Networks proposal. Although some commenters did show support 
for the proposal, others raised strong concerns. Given the concerns 
commenters raised specifically regarding the need for a mature TEFCA to 
be in place first, and appreciating the ongoing work on the TEFCA being 
done at this time, we are not finalizing this trusted exchange proposal 
in this rule.
    4. We are finalizing the Revisions to the Conditions of 
Participation for Hospitals and Critical Access Hospitals proposal with 
modifications that are based on public comments. Additionally, and 
based on strong support from commenters, we are including patient event 
notification requirements for any patient who accesses services in a 
hospital (or CAH) emergency department. In response to the number of 
comments received regarding concerns with the applicable date for this 
policy, we are finalizing an applicability date of 12 months after 
publication of this rule for hospitals, including psychiatric 
hospitals, and CAHs to allow for adequate time for these institutions, 
especially small and/or rural hospitals as well as CAHs, to come into 
compliance with the new requirements.
    All other policies are being substantially finalized as proposed.

XII. Collection of Information Requirements

    Under the Paperwork Reduction Act of 1995, we are required to 
provide 30-day notice in the Federal Register and solicit public 
comment before a collection of information requirement is submitted to 
the Office of Management and Budget (OMB) for review and approval. In 
order to fairly evaluate whether an information collection should be 
approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act 
of 1995 requires that we solicit comment on the following issues:
     The need for the information collection and its usefulness 
in carrying out the proper functions of our agency.
     The accuracy of our estimate of the information collection 
burden.
     The quality, utility, and clarity of the information to be 
collected.
     Recommendations to minimize the information collection 
burden on the affected public, including automated collection 
techniques.
    We solicited public comment on each of these issues for the 
following sections of this document that contain information collection 
requirements (ICRs):

A. Background

    Payers should have the ability to exchange data instantly with 
other payers for care and payment coordination or transitions, and with 
providers to facilitate more efficient care. Payers are in a unique 
position to provide patients a complete picture of their claims and 
encounter data, allowing patients to piece together their own 
information that might otherwise be lost in disparate systems. To 
advance our commitment to interoperability, we are finalizing our 
proposals for the Patient Access API, the Provider Directory API, and 
the payer-to-payer data exchange as discussed above.
    We noted that these proposals were designed to empower patients by 
making sure that they have access to health information about 
themselves in a usable digital format and can make decisions about how, 
with whom, and for what uses they will share it. By making claims data 
readily available and portable to the enrollee, these initiatives 
supported efforts to reduce burden and cost and improve patient care by 
reducing duplication of services, adding efficiency to patient visits 
to providers; and, facilitating identification of fraud, waste, and 
abuse.

B. Wage Estimates

    To derive average costs, we used data from the U.S. Bureau of Labor 
Statistics' (BLS) May 2018 National Occupational Employment and Wage 
Estimates (https://www.bls.gov/oes/current/oes_nat.htm). Table 1 
presents the mean hourly wage, the cost of fringe benefits (calculated 
at 100 percent of salary), and the adjusted hourly wage. In the CMS 
Interoperability and Patient Access proposed rule, Table 1 was based on 
the latest 2017 wage data (84 FR 7658). In this final rule, we have 
updated Table 1 to reflect 2018 wage data, which is now the latest 
available data.

[[Page 25605]]



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

    As indicated, we are adjusting the employee hourly wage estimates 
by a factor of 100 percent. This is necessarily a rough adjustment, 
both because fringe benefits and overhead costs vary significantly from 
employer to employer, and because methods of estimating these costs 
vary widely from study to study. Nonetheless, there is no practical 
alternative and we believe that doubling the hourly wage to estimate 
total cost is a reasonable accurate estimation method.

C. Information Collection Requirements (ICRs)

1. ICRs Regarding MMA File Requirements (42 CFR 423.910)
    States transmit system generated data files, at least monthly, to 
CMS to identify all dually eligible individuals, including full-benefit 
and partial-benefit dually eligible beneficiaries (that is, those who 
get Medicaid help with Medicare premiums, and often for cost-sharing). 
The file is called the MMA file, but is occasionally referred to as the 
``State Phasedown file.'' Section 423.910(d) requires states to 
transmit at least one MMA file each month. However, states have the 
option to transmit multiple MMA files throughout the month (up to one 
per day). Most states transmit at least weekly. This information 
collection activity is currently approved under OMB control number 
0938-0958.
    Ensuring information on dual eligibility status is accurate and up-
to-date by increasing the frequency of federal-state data exchange is 
an important step toward interoperability. As a result, we proposed to 
update the frequency requirements in 42 CFR 423.910(d) to require that 
starting April 1, 2022, all states transmit the required MMA file data 
to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). 
Daily would mean every business day, but if no new transactions are 
available to transmit, data would not need to be transmitted on a given 
business day. We estimate it would take a computer systems analyst 
about 6 months (approximately 960 hours) to complete the systems 
updates necessary to process and transmit the MMA data daily. After 
completion of system updates, these system generated reports would be 
set to run and transmitted to CMS on an automated production schedule.
    As a result of updated information, we are revising the number of 
states currently transmitting MMA daily data from 13 states, as stated 
in the CMS Interoperability and Patient Access proposed rule, to 15 
states. Consequently, we estimate a one-time aggregate burden for 36 
entities (51 total entities (50 states and the District of Columbia) 
minus the 15 states currently transmitting MMA daily data) to comply 
with the requirement of transmission of daily MMA data at an aggregate 
burden of $3,111,091 (36 entities * 960 hours * $90.02 per hour for a 
computer system analyst to perform the updates). We have only estimated 
the cost of system updates since the system transfers are done 
automatically and this has no additional cost. We will be revising the 
information collection request currently approved under 0938-0958 to 
include the requirements discussed in this section.
2. ICRs Regarding API Proposals (42 CFR 422.119, 422.120, 431.60, 
431.70, 438.242, 457.730, 457.760, 457.1233, and 45 CFR 156.221)
    To promote our commitment to interoperability, we are finalizing 
new requirements for a Patient Access API for MA organizations at 42 
CFR 422.119, Medicaid FFS at 42 CFR 431.60, CHIP FFS at 42 CFR 457.730, 
Medicaid managed care at 42 CFR 438.242(b)(5), CHIP managed care at 42 
CFR 457.1233(d), and QHP issuers on the FFEs at 45 CFR 156.221. 
Additionally, we are finalizing a publicly available Provider Directory 
API for MA organizations at 42 CFR 422.120, at 42 CFR 431.70 for 
Medicaid FFS, at 42 CFR 438.242(b)(6) for Medicaid managed care, at 42 
CFR 457.760 for CHIP FFS, and at 42 CFR 457.1233(d)(3) for CHIP managed 
care. We proposed to require these entities to establish standards-
based APIs that permit third-party applications to retrieve 
standardized data for adjudicated claims, encounters with capitated 
providers, provider remittances, beneficiary cost-sharing, reports of 
lab test results, provider directories (and pharmacy directories for 
MA-PDs), and preferred drug lists, where applicable. We finalized the 
requirement for a Patient Access API and a Provider Directory API; this 
final rule requires generally the same information as proposed to be 
available through APIs but we are finalizing the requirement for two 
APIs. Additionally, we proposed and are finalizing at 42 CFR 
422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) to 
require MA organizations, Medicaid managed care plans, CHIP managed 
care entities, and QHP issuers on the FFEs to maintain a process for 
the electronic exchange of, at a minimum, the data classes and elements 
included in the content standard adopted at 45 CFR 170.213 (currently 
version 1 of the USCDI). To implement the new requirements for APIs and 
payer to payer data exchange, we estimate that plans and states will 
conduct three major work phases: Initial design, development and 
testing, and long-term support and maintenance. In the proposed rule, 
we provided detailed

[[Page 25606]]

estimations of the required labor categories and number of hours 
required to implement the API provisions (84 FR 7659). We originally 
estimated a one-time burden of $789,356.00 per organization or state 
per implementation, with an ongoing maintenance cost $158,359.00 per 
organization or state (84 FR 7659). We noted that, in the initial 
design phase, we believed tasks would include: Determining available 
resources (personnel, hardware, cloud space, etc.); assessing whether 
to use in-house resources to facilitate an API connection or contract 
the work to a third party; convening a team to scope, build, test, and 
maintain the API; performing a data availability scan to determine any 
gaps between internal data models and the data required for the 
necessary FHIR resources; and, mitigating any gaps discovered in the 
available data.
    During the development and testing phase, we noted that plans and 
states would need to conduct the following: Map existing data to HL7 
\66\ FHIR standards, which would constitute the bulk of the work 
required for implementation; allocate hardware for the necessary 
environments (development, testing, production); build a new FHIR 
server or leverage existing FHIR servers; determine the frequency and 
method by which internal data are populated on the FHIR server; build 
connections between the databases and FHIR server; perform capability 
and security testing; and vet third-party applications, which includes 
potentially asking third-party applications to attest to certain 
privacy provisions.
---------------------------------------------------------------------------

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

    After the completion of the API development, plans and states would 
need to conduct the following throughout each year: Allocate resources 
to maintain the FHIR server, which includes the cost of maintaining the 
necessary patient data, and perform capability and security testing.
    In the proposed rule, we proposed a new requirement for MA plans, 
Medicaid managed care plans, CHIP managed care entities, and QHP 
issuers on the FFEs to maintain a process to coordinate care between 
plans by exchanging, at a minimum, the USCDI at the enrollee's request 
(84 FR 7640). Originally, we noted that we would allow multiple methods 
for electronic exchange of the information, including use of the APIs. 
Although we considered requiring the use of the FHIR-based API, we 
understood that some geographic areas might have a regional health 
information exchange that could coordinate such transactions. We also 
noted other ways to exchange this data, such as: Direct plan-to-plan 
exchange; leveraging connections to HIEs, or beneficiary-facing third-
party applications. Since the requirements for the payer-to-payer data 
exchange and the API provisions share a content and vocabulary standard 
and because plans will be investing in the development of the APIs in 
this final rule, we believe that plans would overwhelmingly use these 
APIs to meet the payer to payer data exchange requirements. As we had 
no reliable way to determine which plans would utilize any of the 
available methods to meet the payer-to-payer data exchange requirement 
or how to determine the cost of each of these methods, given that each 
plan could be at a different technology maturity level, we accounted 
for costs for all impacted payers assuming the use of a newly developed 
API to implement the payer-to-payer data exchange requirements, as this 
would account for a higher effort options, and included this in our 
original estimates for the API provisions.
    We summarize the public comments we received on concerns raised 
regarding our proposed cost of implementing and maintaining the APIs 
and provide our responses.
    Comment: Some commenters expressed concern that CMS underestimated 
the complexity of implementing the API requirements and did not agree 
with the agency's estimation that the API implementation is a one-time 
cost. These commenters noted that additional costs include: The costs 
to contract with third-party applications, the costs of ongoing 
education, and the cost of answering questions from members about data 
and errors. Commenters argued that the proposed API requirements 
significantly add to overhead costs and will increase costs for 
providers and payers, rather than facilitate information exchange and 
better care for patients. One commenter estimated a range of between $1 
million and $1.5 million to implement the API requirements, with an 
additional $200,000 to maintain the API. Another commenter argued that 
the costs of implementation could be as high as four times the 
estimates CMS provided.
    Response: We thank commenters for their input and understand their 
concerns associated with the cost required to implement the 
requirements of this final rule. We understand that our estimates 
regarding the implementation of the API provisions may vary depending 
on a number of factors, including, but not limited to a payer's current 
knowledge of and experience with implementing FHIR-based APIs, and 
whether an impacted payer will develop this technology in-house or seek 
a third party contractor to support this effort.
    To further develop our cost estimates, we reviewed the cost 
estimates associated with updating Blue Button from Blue Button 1.0 to 
2.0 to include a standards-based API, similar to the requirements of 
this final rule. This update was estimated at $2 million. However, we 
believe that the estimates associated with updating the existing Blue 
Button 1.0 to a standards-based API for Blue Button 2.0 do not 
accurately represent the costs for payers impacted by this final rule. 
Blue Button 1.0 was developed across several federal agencies, 
including the Departments of Defense, Health and Human Services, and 
Veterans Affairs, with a capability to allow beneficiaries online 
access to their own personal health records, such as the ability to 
download PDF documents. Unlike the standards-based APIs required under 
this final rule, Blue Button 1.0 was not originally developed with a 
prescribed set of standards that allow for third-party apps to connect 
and retrieve data via an API. The estimates for Blue Button account for 
upgrading an existing technology platform that was not originally 
developed to allow third-party app access via an API, which we believe 
adds additional cost that may not impact all payers under this final 
rule. Additionally, we note that costs related to federal procurement 
and the need to engage multiple contractors to implement the updates to 
Blue Button, while at the same time maintaining access to the original 
system, caused the cost of implementing standards-based APIs for Blue 
Button 2.0 to be higher than those costs for payers impacted by this 
final rule. Therefore, we believe that the estimates for upgrading Blue 
Button from 1.0 to 2.0 are not truly representative of the cost to 
implement the standards-based API required by this final rule, but 
nonetheless are valuable in further informing our cost estimates.
    As noted above, we did receive one comment that suggested a cost 
range between $1 million and $1.5 million to implement the API 
requirements of this final rule, with another commenter indicating a 
four-fold increase in costs relative to the estimates included in the 
proposed rule. While disagreeing with

[[Page 25607]]

our bottom line, these commenters did not provide where in our detailed 
analysis we underestimated costs. For example, it is unclear if the 
commenters were including voluntary provider costs, or other costs when 
calculating the dollar amounts for compliance. Therefore, without 
specific examples of additional costs that need to be accounted for in 
this impact analysis, we believe that our estimates are reasonable. To 
address commenters' concerns regarding ongoing costs, we remind readers 
that we specifically are accounting for a cost of $157,656 per 
organization, for costs throughout the year to include: Allocating 
resources to maintain the FHIR server, which includes the cost of 
maintaining the necessary patient data, and perform capability and 
security testing.
    However, in an effort to take into account the additional 
information that commenters presented regarding our costs estimates, 
and understanding there are many factors that may influence the cost of 
implementing these policies, as noted above, we are adjusting our cost 
estimates to reflect a range instead of a point estimate. We believe 
that our cost projections for an initial one-time cost to implement the 
API requirements of this final rule of $718,414 per organization, 
reflecting 6 months of work by a team of ten professionals, can now 
serve as a minimum estimate; in other words, we do not believe it is 
technically feasible to implement the requirements of this final rule 
in less than 6 months. For a primary estimate, we have increased our 
cost estimates by a factor of 2 to account for cost variation. We note 
that using this factor of 2, the cost per organization is consistent 
with the commenter stating a $1 million to $1.5 million per 
organization cost. For a high estimate we have increased our cost 
estimates by a factor of 3. Although, one commenter noted a factor of 4 
should be included, all other information available to us, including 
the commenter who noted a range between $1 million and $1.5 million, 
and our estimates for upgrading Blue Button, a factor of 4 does not 
appear to be reflective of the costs for implementation and represents 
more of an outlier for cost estimating purposes. As shown in section 
XIII. of this final rule, we have revised down our estimate of affected 
individual market enrollees from 76 million (all commercial market 
enrollees) to 17.5 million (those individual market enrollees directly 
affected by this final rule). This reduction by a factor of 4 (76 
million former estimate/17.5 million revised estimate) raises the cost 
per individual market enrollee per year by a factor of 4 consistent 
with the commenter's suggested factor of 4. This factor of 4, however, 
only affects cost per enrollee per year; it does not affect total costs 
as calculated in Table 2.
    Additionally, we note that as part of our original estimated costs 
associated with the annual burden of the requirements of this final 
rule, we accounted for additional capability testing and long-term 
support of the APIs, increased data storage needs, such as additional 
servers, or cloud storage to store any additional patient health 
information, and allocation of resources to maintain the FHIR server, 
and perform capability and security testing. Therefore, our estimates 
related to the annual burden account for the ongoing cost, and we are 
not providing additional estimates for maintenance as this is already 
factored in.
    The burden estimate related to the new requirements for 
implementing and maintaining the APIs reflects the time and effort 
needed to collect the information described above and disclose this 
information. We now estimate:
     An initial set one-time costs associated with the 
implementing the API requirements.
     An ongoing maintenance cost after the system is set up, 
and the costs associated with additional data storage, system testing, 
and maintenance.
    Consistent with our discussion above, we now regard this as a low 
or minimum estimate, the argument being that a complex system cannot be 
designed in less than 6 months. Our high estimate now reflects 18 
months of work (4,320 hours) for administrators and network architects. 
This is obtained by using a factor of 3 (4,320 hours (high estimate) = 
3*1440 hours, the original estimate). For a primary estimate, we 
estimate 12 months of work or 2,880 hours (1,440 hours * 2) for 
administrators and network architects. The use of a factor of 2 is 
consistent with a $2 million cost per entity and consistent with the 
commenter who estimated an implementation cost of $1 million to $1.5 
million. We note that, in terms of actual implementation, this 
assumption is focused on the 2,880 hours of work that could be 
conducted in less than 12 months through necessary personnel or third-
party contractor allocation, if needed. As a result, the ``12-month'' 
assumption is also consistent with the implementation of the new API 
requirements, which must be implemented by January 1, 2021.
    As can be seen from the bottom rows of Table 2:
     For a low estimate, first year implementation will require 
a total of 8,400 hours per organization at a cost of $718,414.40 per 
organization (this number is obtained by adding the products of hourly 
wages and hours required in each row, for example 1440*$90.18 + 
960*$95.60, etc.).
     For a high estimate, first year implementation will 
require a total of 25,200 hours per organization at a cost of 
$2,365,243 per organization (this number is obtained by adding the 
products of hourly wages and hours required in each row).
     For a primary estimate, first year implementation will 
require a total of 16,800 hours of work per organization at a cost of 
$1,576,829 per organization.
     Therefore, the aggregate burden of the first year 
implementation across 345 parent organizations \67\ is 2,898,000 hours 
(8400 * 345) at a cost of $272 million ($718,414 * 345) for the low 
estimate. Similar calculations show that the primary estimate is 
5,796,000 hours at an aggregate cost of $544,005,936 million, and the 
high estimate is 8,694,000 hours at a cost of $816,008,904.
---------------------------------------------------------------------------

    \67\ We provide a detailed rationale for how we determined the 
number of parent organizations in section XIII.C.1. of this final 
rule. In that analysis we determined that 288 issuers and 56 states, 
territories, and U.S. commonwealths, which operate FFS programs, 
will be subject to the API provisions for Medicare, Medicaid, and 
the commercial market. To this we added the one state that operates 
its CHIP and Medicaid separately. Thus, we have a total of 345 
parent entities (288+56+1).
---------------------------------------------------------------------------

     Similarly, ongoing maintenance after the first year will 
require a total of 1,710 hours per organization at a cost of 
$157,656.60 per organization.
     Therefore, the aggregate burden of ongoing implementation 
across 345 parent organizations is $54.4 million ($157,656.60 * 345).
    We explicitly note that a low and high estimate were only provided 
for the first year, but not for subsequent years.

[[Page 25608]]



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

3. ICRs Regarding Conditions of Participation for Hospitals and 
Critical Access Hospitals (42 CFR 482.24(d), 482.61(f), 485.638(d))
    We are expanding our requirements for interoperability within the 
hospital and CAH CoPs by focusing on electronic patient event 
notifications. We are implementing new requirements in section X. of 
this final rule for hospitals at 42 CFR 482.24(d), for psychiatric 
hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638(d). 
Specifically, for hospitals, psychiatric hospitals, and CAHs, we are 
finalizing similar requirements to revise the CoPs for Medicare- and 
Medicaid-participating hospitals, psychiatric hospitals, and CAHs by 
adding a new standard, ``Electronic Notifications,'' that will require 
hospitals, psychiatric hospitals, and CAHs to make electronic patient 
event notifications available to applicable post-acute care services 
providers and suppliers, and to community practitioners such as the 
patient's established primary care practitioner, established primary 
care practice group or entity, or other practitioner or practice group 
or entity identified by the patient as primarily responsible for his or 
her care. We are limiting this requirement to only those hospitals, 
psychiatric hospitals, and CAHs that utilize electronic medical records 
systems, or other electronic administrative systems, which are 
conformant with the content exchange standard at 45 CFR 170.205(d)(2), 
recognizing that not all Medicare- and Medicaid-participating hospitals 
have been eligible for past programs promoting adoption of EHR systems. 
If the hospital's (or CAH's) system conforms to the content exchange 
standard at 45 CFR 170.205(d)(2), the hospital (or CAH) must then 
demonstrate that its system's notification capacity is fully 
operational and that the hospital (or CAH) uses it in accordance with 
all state and federal statutes and regulations applicable to the 
hospital's (or CAH's) exchange of patient health information, and that 
its system (to the extent permissible under applicable federal and 
state law and regulations, and not inconsistent with the patient's 
expressed privacy preferences) sends the notifications either directly, 
or through an intermediary that facilitates exchange of health 
information. It must also demonstrate that the notifications include at 
least patient name, treating practitioner name, and sending institution 
name.
    Upon the patient's registration in the emergency department or 
admission to inpatient services, and also either immediately prior to, 
or at the time of, the patient's discharge or transfer (from the 
emergency department or inpatient services), the hospital (or CAH) must 
also demonstrate that it has made a reasonable effort to ensure that 
its system sends the notifications to all applicable post-acute care 
services providers and suppliers, as well as to any of the following 
practitioners and entities, which need to receive notification of the 
patient's status for treatment, care coordination, or quality 
improvement purposes: (1) The patient's established primary care 
practitioner; (2) the patient's established primary care practice group 
or entity; or (3) other practitioner, or other practice group or 
entity, identified by the patient as the

[[Page 25609]]

practitioner, or practice group or entity, primarily responsible for 
his or her care.
    These requirements will help support coordination of a patient's 
care between settings or with services received through different care 
settings. Electronic patient event notifications from these care 
settings, or clinical event notifications, are one type of health 
information exchange intervention that has been increasingly recognized 
as an effective and scalable tool for improving care coordination 
across settings. These notifications are typically automated, 
electronic communications from the admitting or discharging provider to 
applicable post-acute care services providers and suppliers, and also 
to community practitioners identified by the patient, that alert the 
receiving providers or community practitioners that a patient is 
receiving, or has received, care at a different setting.
    These notifications are frequently based on ``admission, discharge, 
and transfer (ADT)'' messages, a standard message used within an EHR as 
the vehicle for communicating information about key changes in a 
patient's status as they are tracked by the system (more information 
about the current standard supporting these messages is available at 
https://www.hl7.org/implement/standards/product_brief.cfm?product_id=144). As noted in the ISA published by 
ONC, this messaging standard has been widely adopted across the health 
care system (see https://www.healthit.gov/isa/sending-a-notification-a-patients-admission-discharge-andor-transfer-status-other-providers).
    We continue to believe that care coordination can have a 
significant positive impact on the quality of life, consumer 
experience, and health outcomes for patients. As we have noted in the 
preamble to this rule, virtually all EHR systems (as well as older 
legacy electronic administrative systems, such as electronic patient 
registrations systems, and which we are including in this final rule) 
generate information to support the basic messages commonly used for 
electronic patient event notifications. While we acknowledge that some 
level of implementation cost would be realized for those providers not 
already transmitting notifications, we also note there is substantial 
agreement that implementation of these basic messaging and notification 
functions within such existing systems constitutes a relatively low 
cost burden for providers, particularly when such costs are considered 
alongside the innovative and beneficial patient care transition 
solutions and models for best practices they provide.
    Although we do not have current data on how many facilities are 
already transmitting electronic patient event notifications, 59 percent 
of hospitals were found to be routinely electronically notifying a 
patient's primary care provider upon his or her entry to the hospital's 
emergency department in 2015, which is an over 50 percent increase 
since 2012.\68\ By using this historical data to plot a power trend 
line (R-Squared: 0.9928), we estimate that approximately 71 percent of 
hospitals may have been routinely transmitting patient event 
notifications by 2018; therefore, we assume that 29 percent of 
hospitals, or approximately 1,392, will incur costs associated with 
updating or configuring their respective EHR systems for electronic 
patient event notifications. While we do not have parallel data for 
CAHs, we assume that a similar percentage, or approximately 394 CAHs, 
will incur this burden. We note that this upwards trend of patient 
event notification adoption may continue to some unknown extent absent 
this final rule; however, we are limiting our projection of hospitals 
that are most affected by these requirements to 2018 due to the amount 
of uncertainty involved in quantifying this burden.
---------------------------------------------------------------------------

    \68\ Office of the National Coordinator. (n.d.). Hospital 
Routine Electronic Notification: Percent of U.S. Hospitals that 
Routinely Electronically Notify Patient's Primary Care Provider upon 
Emergency Room Entry, 2015. Retrieved from https://dashboard.healthit.gov/quickstats/pages/FIG-Hospital-Routine-Electronic-Notification.php.
---------------------------------------------------------------------------

    We assume that this process will primarily require the services of 
two medical records and health information technicians at approximately 
$42.32/hour for 16 hours each, and 3 hours of time from a medical and 
health services manager at approximately $109.36/hour, including the 
costs of overhead and fringe benefits. Thus, the total burden per 
facility is anticipated to be 35 hours, or approximately $1,682.32 ((16 
hours * $42.32/hour * 2 health information technicians) + (3 hours * 
$109.36/hour * 1 manager)). We assume that the ongoing burden 
associated with maintenance of these systems would be approximately one 
quarter of these amounts for the 2 medical records and health 
information technicians, or 4 hours each, for a total of 8 hours and 
$338.56 per facility (4 hours * $42.32/hour * 2 health information 
technicians).
    In this lower-bound scenario, we estimate that the total first-year 
burden for hospitals and psychiatric hospitals is approximately 48,720 
hours (35 hours * 1,392 hospitals) or $2,341,789 ($1,682.32 * 1,392 
hospitals). In subsequent years, we estimate the burden is 
approximately 11,136 hours (8 hours * 1,392 hospitals) or $471,276 
($338.56 * 1,392 hospitals).
    For CAHs we estimate that the total first-year burden is 
approximately 13,790 hours (35 hours * 394 CAHs) or $662,834 ($1,682.32 
* 394 CAHs). In subsequent years, we estimate the burden for CAHs is 
approximately 3,152 hours (8 hours * 394 CAHs) or $133,393 ($338.56 * 
394 CAHs).
    Due to the amount of uncertainty involved in these estimates, we 
are also presenting estimates for a scenario in which the number of 
hospitals that routinely electronically notify primary care providers 
both inside and outside of the hospital's system is assumed to have 
remained static at the 2015 rate of 29 percent. This upper-bound 
scenario would indicate that in 2018 approximately 3,407 hospitals and 
964 CAHs did not routinely utilize patient event notification, and 
therefore several thousand additional providers would incur the 
previously estimated burden per facility.
    For the purposes of the PRA, we are assuming the midpoint of this 
range of effects. In this scenario 2,400 hospitals and psychiatric 
hospitals, and 679 CAHs would incur the estimated burden. The burden 
estimates associated with the revised CoPs are detailed in Table 3. 
This information collection will be submitted to OMB under OMB Control 
Number 0938-New.

[[Page 25610]]



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

4. Summary of Information Collection Burdens

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

XIII. Regulatory Impact Analysis

A. Statement of Need

    As described in detail in section III. of this rule, the changes to 
42 CFR parts 422, 431, 438, 457, and 45 CFR part 156 are part of the 
agency's broader efforts to empower patients by ensuring that they have 
full access to their own health care data, through common technologies 
and without special effort, while keeping that information safe and 
secure. Interoperability and the capability for health information 
systems and software applications to communicate, exchange, and 
interpret data in a usable and readable format, such as PDF or text, is 
vital, but allowing access to health care data through PDF and text 
format also limits the utility and sharing of data. Moving to a system 
in which patients have access to their health care data will help 
empower them to make informed decisions about their health care, as 
well as share their data with providers who can assist these patients 
with their health care. The policies are designed to move Medicare, MA, 
Medicaid, CHIP, and QHP issuers on the FFEs further to that ultimate 
goal of empowering their enrollees. As technology has advanced, we have 
encouraged states, payers, and providers to adopt various forms of 
technology to improve the accurate and timely exchange of standardized 
health care information. The policies in this final rule enable 
patients to be active partners in the exchange of electronic health 
care data by easily monitoring or sharing their data.
    States and CMS routinely exchange data on who is enrolled in 
Medicare, and which parties are liable for paying that beneficiary's 
Parts A and B

[[Page 25611]]

premiums. These ``buy-in'' data exchanges support state, CMS, and SSA 
premium accounting, collections, and enrollment functions. We have 
become increasingly concerned about the limitations of monthly buy-in 
data exchanges with states. The relatively long lag in updating buy-in 
data means that the state is not able to terminate or activate buy-in 
coverage sooner, so the state or beneficiary may be paying premiums for 
longer than appropriate. We note that once the data catch up, states 
and CMS reconcile the premiums by recouping and re-billing, so premiums 
collected are ultimately accurate, but only with an administratively 
burdensome process involving debits and payments between the 
beneficiary, state, CMS, SSA, and potentially providers. Daily buy-in 
data exchange will reduce this administrative burden.
    States submit data on files at least monthly to CMS to identify all 
dually eligible individuals, including full-benefit and partial-benefit 
dually eligible beneficiaries (that is, those who get Medicaid help 
with Medicare premiums, and often for cost-sharing). The MMA file was 
originally developed to meet the need to timely identify dually 
eligible beneficiaries for the then-new Medicare Part D prescription 
drug benefit. Over time, we use these files' data on dual eligibility 
status to support Part C capitation risk-adjustment, and most recently, 
feeding dual eligibility status to Part A and B eligibility and claims 
processing systems so providers, suppliers, and beneficiaries have 
accurate information on beneficiary cost-sharing obligations. As CMS 
now utilizes MMA data on dual eligibility status in systems supporting 
all four parts of the Medicare program, it is becoming even more 
essential that dual eligibility status is accurate and up-to-date. Dual 
eligibility status can change at any time in a month. Waiting up to a 
month for status updates can negatively impact access to the correct 
level of benefit at the correct level of payment. As described in 
detail in section VII. of this rule, the changes to 42 CFR parts 406, 
407, and 423 establish frequency requirements that necessitate all 
states to participate in daily exchange of buy-in data, and updates 
frequency requirements to require all states to participate in daily 
exchange of MMA file data, with CMS by April 1, 2022.

B. Overall Impact

    We have examined the impacts of this final rule as required by 
Executive Order 12866 on Regulatory Planning and Review (September 30, 
1993), Executive Order 13563 on Improving Regulation and Regulatory 
Review (January 18, 2011), the Regulatory Flexibility Act (RFA) 
(September 19, 1980, Pub. L. 96-354), section 1102(b) of the Social 
Security Act, section 202 of the Unfunded Mandates Reform Act of 1995 
(March 22, 1995; Pub. L. 104-4), Executive Order 13132 on Federalism 
(August 4, 1999), the Congressional Review Act (5 U.S.C. 804(2)), and 
Executive Order 13771 on Reducing Regulation and Controlling Regulatory 
Costs (January 30, 2017).
    Executive Orders 12866 and 13563 direct agencies to assess all 
costs and benefits of available regulatory alternatives and, if 
regulation is necessary, to select regulatory approaches that maximize 
net benefits (including potential economic, environmental, public 
health and safety effects, distributive impacts, and equity). Section 
3(f) of Executive Order 12866 defines a ``significant regulatory 
action'' as an action that is likely to result in a rule: (1) Having an 
annual effect on the economy of $100 million or more in any 1 year, or 
adversely and materially affecting a sector of the economy, 
productivity, competition, jobs, the environment, public health or 
safety, or state, local or tribal governments or communities (also 
referred to as ``economically significant''); (2) creating a serious 
inconsistency or otherwise interfering with an action taken or planned 
by another agency; (3) materially altering the budgetary impacts of 
entitlement grants, user fees, or loan programs or the rights and 
obligations of recipients thereof; or (4) raising novel legal or policy 
issues arising out of legal mandates, the President's priorities, or 
the principles set forth in the Executive Order.
    A regulatory impact analysis (RIA) must be prepared for major rules 
with economically significant effects ($100 million or more in any 1 
year). We estimate that this rulemaking is ``economically significant'' 
as measured by the $100 million threshold, and hence also a major rule 
under the Congressional Review Act. Accordingly, we have prepared an 
RIA that to the best of our ability presents the costs and benefits of 
the rulemaking. Table 5 summarizes the estimated costs presented in 
section XII. of this final rule.
    In the proposed rule, we provided detailed estimations of the 
required labor categories and number of hours required to implement 
standards-based APIs (84 FR 7659). We originally estimated a one-time 
burden of $789,356 per organization or state, per implementation, with 
an ongoing maintenance cost $158,359.80 per organization or state (84 
FR 7659). As we detailed in section XII., to account for additional 
information commenters presented regarding our costs estimates, we are 
adjusting our original cost estimates to reflect a range, instead of a 
point estimate. Our original estimate for the initial one-time cost to 
implement the API requirements of this final rule of $788,414 per 
organization will now serve as a minimum estimate. We have increased 
our primary cost estimate by a factor of 2 to an initial one-time cost 
of $1,576,829 per organization or state. Additionally, we are 
increasing our original cost estimate by a factor of 3 for an initial 
one-time cost of $2,365,243 per organization or state to serve as a 
high estimate (detailed cost estimates are located in Table 5).
    Table 5 reflects updated wages for 2018, the latest available from 
the Bureau of Labor Statistics (BLS) website; the CMS Interoperability 
and Patient Access proposed rule used 2017 wage estimates. 
Nevertheless, the change in total impact was small. We note that 
estimates below do not account for enrollment growth or higher costs 
associated with medical care. This is because the cost of requirements 
to implement patient access through APIs and for states to comply with 
data exchange requirements are not impacted by enrollment growth or 
higher costs associated with medical care. Per OMB guidelines, the 
projected estimates are expressed in constant-year dollars (in this 
case, using 2018 prices and wages).
    Table 5 forms the basis for allocating costs by year and program to 
the federal government, state Medicaid agencies, and parent 
organizations.

[[Page 25612]]



                                             Table 5--Estimated Costs (millions) of Final Rule by Provision
--------------------------------------------------------------------------------------------------------------------------------------------------------
             Provision                  Dual        Patient
-----------------------------------   eligible     access API
                                        care          (low
                                    coordination   estimate)
                                   ---------------------------
                                                      Sec.                                                                                    Percent of
                                                    422.119,                                                                     Months in     25 month
                                                      Sec.       Patient      Patient     Total cost   Total cost   Total cost    year for    window for
                                        Sec.        431.60,     access API   access API      (low       (primary      (high      compliance   compliance
          Regulatory text           406.26, Sec.      Sec.       (primary      (high      estimate)    estimate)    estimate)     for dual    with dual
                                        407.40,     438.242,    estimate)    estimate)                                            eligible     eligible
                                        Sec.          Sec.                                                                       provisions   provisions
                                       423.910      457.730,
                                                      Sec.
                                                    457.123,
                                                      Sec.
                                                    156.221
--------------------------------------------------------------------------------------------------------------------------------------------------------
2020..............................           2.8        272.0        544.0        816.0        274.8        546.8        818.8           10           40
2021..............................           3.4         54.4         54.4         54.4         57.8         57.8         57.8           12           48
2022..............................           0.8         54.4         54.4         54.4         55.2         55.2         55.2            3           12
2023..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2024..............................             0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2025..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2026..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2027..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2028..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
2029..............................           0.0         54.4         54.4         54.4         54.4         54.4         54.4  ...........  ...........
                                   ---------------------------------------------------------------------------------------------------------------------
    Total.........................           7.0        761.5       1033.5       1305.5        768.5       1040.5       1312.5         25.0          100
--------------------------------------------------------------------------------------------------------------------------------------------------------
Note: Totals may not equal sum of parts due to rounding.

    Allocation of Cost Impact by Payer: As stated in section XII. of 
this final rule, cost estimates have been aggregated at the parent 
organization level because we believe that an organization that offers 
QHPs on the FFEs, Medicare, Medicaid, and CHIP products would create 
one system that would be used by all ``plans'' to whom it offers access 
to data via APIs. We note that due to the implementation of APIs across 
multiple business lines, there is no straightforward method to 
immediately estimate parent organization expenditures on how much of 
the cost is born by each payer. Although this section provides such 
estimates it is important to understand how they are arrived at. A 
summary by Table in this section is provided in Table 6. As shown in 
Table 6:
     We first ascertain total costs of implementing this final 
rule by provision in (Table 5);
     As indicated earlier, we have no straightforward way of 
ascertaining total costs by payer since we do not have internal data 
for each parent organization on how it allocates costs by program;
     Therefore, to approximate costs we developed approximated 
proportions of total cost of each parent organization by payer 
(Medicare, Medicaid, CHIP, and Individual market, including individual 
market plans sold on and off the Exchanges, as we expect that, among 
parent organizations of issuers that offer QHPs on the FFEs, costs will 
be passed on through all plans the issuers offer in the individual 
market. Since this rule does not apply to QHP issuers offering QHPs 
only on Federally-facilitated Small Business Health Options Program 
Exchanges (FF-SHOPs) they were not included in our analysis.
     Our use of available data includes many approximations due 
to data limitations discussed in detail below (Table 7);
     Table 7 then allows us to obtain proportions of total 
costs for this final rule by payer (Table 8);
     Since we know the way federal payments for both Medicare 
and Medicaid are calculated, we can then obtain total costs by payer 
incurred by the federal government (Table 9);
     We next subtracted federal payments by payer (Table 9) 
from total costs by payer (Table 8) to obtain the non-federal costs of 
this final rule by payer (Table 10);
     Table 11 presents the same data as Table 10; Table 10 
presents total non-federal costs per payer, while Table 11 presents 
average non-federal costs per enrollee per payer;
     Table 12 presents the same data as Table 9; while Table 9 
presents total costs to the federal government by payer, Table 12 
presents average federal costs per enrollee by payer; and
     Table 13 lists potential means for payers to deal with new 
costs.

 Table 6--Outline of the Flow of Logic by Table for This Impact Analysis
------------------------------------------------------------------------
            Table               Content of table      Comments on table
------------------------------------------------------------------------
5...........................  Total costs by        Costs are fully
                               provision (API,       developed in the
                               Dual).                Collection of
                                                     Information section
                                                     of this final rule
                                                     (section XII. of
                                                     this final rule).
7...........................  Proportion of         There is no
                               premiums by program   straightforward way
                               (2016-2018) used,     to directly assess
                               in later tables, as   parent organization
                               a proxy for           cost by payer.
                               proportion of cost    Therefore, for each
                               by program.           payer we develop
                                                     approximate
                                                     percentages of cost
                                                     per payer.
8...........................  API costs total cost  We obtain the total
                               by year and Program   API costs for this
                               (Medicare,            final rule per
                               Medicaid,             program by
                               Individual market     multiplying the API
                               plans, and CHIP).     costs (for all
                               This total cost is    programs) of this
                               divided by cost to    final rule (Table
                               the federal           5) by the
                               government (Table     proportion of
                               9) and non-federal    premiums presented
                               costs to plans and    in Table 7.
                               enrollees (Table
                               10).

[[Page 25613]]

 
9...........................  Total costs incurred  Based on how federal
                               by the federal        payments are
                               government by         calculated in
                               program and year.     Medicare and
                                                     Medicaid, we have
                                                     projected federal
                                                     proportions of the
                                                     total cost and
                                                     these are applied
                                                     to Table 8 to
                                                     obtain Table 9.
10..........................  Non-federal total     Table 9 = Table 8-
                               costs for API by      Table 10--non-
                               program by year.      federal costs are
                                                     obtained by
                                                     subtracting federal
                                                     costs (Table 9)
                                                     from total costs
                                                     (Table 8).
11..........................  Average non-federal   Tables 11 and 10
                               cost per enrollee     present the same
                               per year by program   data in different
                               for plans.            forms. Table 10
                                                     presents total non-
                                                     federal cost by
                                                     program for states
                                                     and plans, while
                                                     Table 11 presents
                                                     average non-federal
                                                     costs per enrollee
                                                     per year for states
                                                     and plans.
12..........................  Average federal cost  Tables 12 and 9
                               per enrollee per      present the same
                               year by program for   data in different
                               the federal           forms. Table 9
                               government.           presents total cost
                                                     to the federal
                                                     government (due to
                                                     matching programs),
                                                     while Table 12
                                                     presents average
                                                     cost per enrollee
                                                     to the federal
                                                     government.
13..........................  How payers would      This table lists
                               defray the            potential means for
                               remaining costs.      a plan to deal with
                                                     extra costs. We
                                                     have no way of
                                                     predicting what
                                                     will actually
                                                     happen.
------------------------------------------------------------------------

    Preliminary Estimates: This section provides several detailed 
estimates of cost by payer (Table 7); we also account for federal 
matching for Medicaid and payments by the Trust Fund for Medicare 
Advantage organizations (Table 9); we indicate remaining burden on 
plans (Tables 10, 11) and how they might account for it (Table 12). 
However, these estimates are approximate as explained in detail below.
    Data Sources for Cost by Payer: To obtain allocation of cost by 
payer we used the CMS public use files for MLR data, for 2016.\69\ The 
MLR data sets are for private insurance plans but the issuers of that 
private insurance in many cases also have contracts to provide MA, 
Medicaid, and CHIP managed care plans and report revenue, expense, and 
enrollment data for these plans on the private insurance MLR reporting 
form.
---------------------------------------------------------------------------

    \69\ Center for Consumer Information and Insurance Oversight. 
(n.d.). Medical Loss Ratio Data and System Resources. Retrieved from 
https://www.cms.gov/CCIIO/Resources/Data-Resources/mlr.html.
---------------------------------------------------------------------------

    Thus, these MLR data sets omit organizations that only have 
Medicare or Medicaid. The data from the CMS MLR files also omit: (1) 
The CHIP program; and (2) state Medicaid agencies. We now discuss these 
omissions to assess the accuracy of using these MLR files.
    CHIP: Eighty-five percent of the 194 CHIP managed care plans also 
offer Medicaid and hence are covered by the parent entity. We believe 
it reasonable that the remaining CHIP plans also have commercial 
offerings since it would be inefficient to operate a CHIP-only plan, as 
the total national CHIP enrollment is currently only about 7 million. 
Similarly, except for one state, CHIP programs are run through the 
state Medicaid agency; again, there would be one interoperability cost 
for the one state agency since the resulting software and systems would 
be used both for Medicaid and CHIP. Thus, while we are leaving out CHIP 
programs in this analysis since they are not in the CMS MLR files, we 
do not believe this materially alters the overall picture.
    Medicare Advantage: We compared the CMS MLR files with the CMS 
Trustee Report.\70\ According to the Trustee Report (Table IV.C2), 
total MA revenue for 2016 was $189.1 billion. Thus, the reported amount 
in the CMS MLR files of $157 billion for MA represents 83 percent (157/
189.1) of all MA activity reflected in the Trustee Report. Therefore, 
we believe the proportions obtained from these MLR files are accurate.
---------------------------------------------------------------------------

    \70\ See Table IV.C2 in, Boards of Trustees (Federal Hospital 
Insurance and Federal Supplementary Medical Insurance Trust Funds). 
(2018, June 5). The 2018 Annual Report of The Boards of Trustees of 
the Federal Hospital Insurance and Federal Supplementary Medical 
Insurance Trust Funds. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf.
---------------------------------------------------------------------------

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

    \71\ Centers for Medicare and Medicaid Services. (2018, November 
8). CMS Proposes Changes to Streamline and Strengthen Medicaid and 
CHIP Managed Care Regulations. Retrieved from https://www.cms.gov/newsroom/press-releases/cms-proposes-changes-streamline-and-strengthen-medicaid-and-chip-managed-care-regulations.
---------------------------------------------------------------------------

    Individual and small group market plans: The MLR files contain data 
on all commercial parent organizations whether these organizations have 
other lines of business, such as Medicare Advantage or Medicaid, or 
not. In discussing commercial plans, we account for: (A) Large group 
market plans; (B) small group market plans, including SHOP plans; (C) 
individual market Exchange plans; and (D) individual market off-
Exchange plans.
     We have carved out the large employer plans since the 
provisions of this final rule do not apply to them, and we do not 
believe that parent organizations would pass on costs for individual 
and small group market plans to large group employer-sponsored plans.
     We have noted that the provisions of this final rule do 
not apply to QHP issuers offering QHPs only on FF-SHOPs, so we are not 
including small group market plans in this analysis.
     We believe it is reasonable, that even though the 
provisions of this final rule do not apply to off-Exchange individual 
market plans, issuers subject to this rule offering QHPs on the FFEs 
will spread the cost to all plans issuers offer in the individual 
market. They will also likely offer the benefits of the APIs to all 
covered lives, as they can be marketed as a value add service, and it 
is logistically more challenging to offer a service to only a limited 
number of enrollees.
     We estimate that off-Exchange plans offered by issuers who 
offer no QHPs on

[[Page 25614]]

FFEs are about 7 percent of total individual market enrollment. 
Therefore, to the extent that we are including off-Exchange plans, the 
calculations below will be an approximation, but given this low 
proportion of off-Exchange-only issuers, we do not believe including 
them in this approximation will have a major impact.
    Best Estimates of Impact per Program and Payer: We present two 
methods to obtain an estimate of cost by program and payer, both for 
purposes of assessing impact on: (1) Small entities; (2) the federal 
government; (3) payers (states and plans); and (4) enrollees. We could 
assume costs proportional to current enrollment, or alternatively, we 
could assume costs proportional to total premium. For purposes of 
analyzing impact on small entities and impacts of the provision on the 
federal government, payers, plans, and enrollees we are using the 
method of assuming costs proportional to total premium (the method of 
assuming costs proportional to current enrollment will be used below to 
assess impact on transfers to enrollees).
    The CMS Interoperability and Patient Access proposed rule used 2016 
CMS MLR files (84 FR 7662). Since its publication, 2017 and 2018 data 
have become available. However, we are only using these data to obtain 
proportions and, as Table 7 shows, the proportions for premiums have 
not changed significantly (only one quarter to one third percent for 
Medicare and Medicaid). Therefore, we retain and continue to use the 
2016 proportions for purposes of this analysis with a note that they 
generally have remained constant. These proportions of premiums are 
being used as a proxy to approximate total cost.
    In the proposed rule we used the full $370 billion in commercial 
premium in determining our proportions (84 FR 7662). As discussed 
above, we are revising the estimates because upon further 
consideration, we have concluded that issuers in the commercial group 
markets are unlikely to spread the costs through increasing premium 
rates on those types of plans because issuers are not required to 
implement and maintain the API requirements of this final rule in the 
group markets and there are no indications that employer groups in 
these markets would be willing to pay for this provision through 
increased premium rates. Consequently, the $370 billion commercial 
premium is being reduced to $77 billion and the 76 million enrollees 
are being reduced to 17.5 million.
    As discussed above, the $370 billion (and 76 million enrollees) 
represented both individual and small group and large group market 
plans; the $77 billion and 17.5 million enrollees represent all 
individual market plans whether they are sold on and/or off-Exchange. 
We note that this reduction from our original estimate is due to the 
fact that most plans are large employer plans, and the individual 
market is only 20 to 23 percent of the full health insurance market. 
This refinement better aligns with the proportion of the market 
impacted by this final rule.
    Among issuers with products in both the individual market and MA or 
the individual market and Medicaid, the 2016 CMS MLR files show $77 
billion reported in premium for individual market plans, $157 billion 
reported for MA, and $113 billion reported for Medicaid. Consequently, 
the proportion of interoperability cost for each of the programs is 
22.19 percent (77/(77+157+113)), 45.24 percent (157/(77+157+113)), and 
32.56 percent (113/(77+157+113)) for individual market plans, MA, and 
Medicaid respectively. Table 7 shows similar proportions for 2017 and 
2018.

        Table 7--Proportion of Premiums (in Billions) for Medicare, Medicaid, and Individual Market Plans
----------------------------------------------------------------------------------------------------------------
                                                                     Medicare       Individual
                      Year                           Medicaid        Advantage     market plans       Totals
----------------------------------------------------------------------------------------------------------------
2016 Premium (billions).........................             113             157              77             347
2017 Premium (billions).........................           119.5           170.3              86             376
2018 Premium (billions).........................             127             184              91             402
2016 Percentage (used in this RIA in all                  32.56%          45.24%          22.19%         100.00%
 estimates) of total costs by program...........
2017 Percentage.................................          31.78%          45.29%          22.93%         100.00%
2018 Percentage.................................          31.62%          45.81%          22.56%         100.00%
----------------------------------------------------------------------------------------------------------------

    As indicated earlier, since cost allocation at the parent 
organization level and the allocations of each parent organization may 
differ by program (Medicare, Medicaid, CHIP, and Individual market 
plans) and is an internal business decision, we cannot directly assess 
per-payer costs. However, using the MLR tables, we can assess the 
proportions of cost by program. We can then multiply these proportions 
(as presented in Table 7) by the total costs of this final rule as 
presented in Table 5 to obtain Table 8, which breaks out the total 
column in Table 5, the total cost by year of implementing and 
maintaining the API, to offer API costs by year and program.

                              Table 8--API Costs (in Millions) by Year and Program
----------------------------------------------------------------------------------------------------------------
                                                Full
                                           implementation
                                           and maintenance     Individual                           Medicare
                  Year                    costs (millions)    market plans      Medicaid and        Advantage
                                           (from Table 5)       (22.19%)        CHIP (32.56%)       (45.24%)
                                               for API
                                              provision
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).....................             272.0              60.4              88.6             123.1
2020 (Primary estimate).................             544.0             120.7             177.2             246.1
2020 (High Estimate)....................             816.0             181.1             265.7             369.2
2021....................................              54.4              12.1              17.7              24.6
2022....................................              54.4              12.1              17.7              24.6

[[Page 25615]]

 
2023....................................              54.4              12.1              17.7              24.6
2024....................................              54.4              12.1              17.7              24.6
2025....................................              54.4              12.1              17.7              24.6
2026....................................              54.4              12.1              17.7              24.6
2027....................................              54.4              12.1              17.7              24.6
2028....................................              54.4              12.1              17.7              24.6
2029....................................              54.4              12.1              17.7              24.6
                                         -----------------------------------------------------------------------
    Total (Low Estimate)................             761.5             169.0             248.0             344.6
    Total (Primary Estimate)............            1033.5             229.3             336.6             467.6
    Total (High Estimate)...............            1305.5             289.7             425.1             590.7
----------------------------------------------------------------------------------------------------------------

Methods of Bearing Cost by Payer

    QHPs on the FFEs: Individual market plans have the option to deal 
with increased costs by either temporarily absorbing them (for purposes 
of market competitiveness), increasing premiums to enrollees, or 
reducing non-essential health benefits. To the extent that issuers 
increase premiums for individual market plans on the FFEs, there would 
be federal premium tax credit (PTC) impacts. The purpose of the PTC is 
to assist enrollees in paying premium costs. Since PTCs are only 
available if an individual purchases an individual market plan on an 
Exchange, the PTC estimates apply only to Exchange plans. In the PTC 
estimate, we have accounted for the fact that some issuers have both 
Exchange and non-Exchange plans, and some issuers have only non-
Exchange plans. We reflected these assumptions with global adjustments, 
so we believe the estimates are reasonable in aggregate.
    Medicare Advantage: MA organizations may increase bids to reflect 
the costs of this final rule. Some of these expected increased bid 
costs may increase Medicare Trust Fund payments. For those (most) MA 
organizations whose bid amount is below the benchmark, the Trust Fund 
provides total expenditures to the MA organizations consisting of: (1) 
Full payment of the bid amount; and (2) the rebate, a portion of the 
difference between the benchmark and the bid amount. Since MA 
organizations are increasing their bid amounts to reflect the costs of 
this final rule, it follows that the rebate, equaling the difference 
between the benchmark and bid, is decreased, resulting in less rebates 
paid to the MA organizations. Based on our past experience and 
projections for the future, the rebate is estimated as 34 percent of 
the difference between benchmark and bid. Thus, although the Trust Fund 
pays the bid in full, nevertheless, 66 percent of the increased bid 
costs arising from this final rule, are reduced from the rebates. The 
MA organizations in its submitted bid, can address this reduction of 
rebates by either: (1) Temporarily, for marketing purposes, absorbing 
the loss by reducing its profit margin; (2) reducing the supplemental 
benefits it provides the enrollee paid for by the rebate; or (3) 
raising enrollee premiums in order to provide supplemental benefits for 
which premiums are not paid by the rebate. The decision of what 
approach to use is an internal business decision in part motivated by 
unforeseen forces of marketing; we therefore have no way of predicting 
what will happen.
    Medicaid: State Medicaid agencies may be allowed to allocate the 
costs of state information retrieval systems between the costs 
attributable to design, development, installation, or enhancement of 
the system--at a 90 percent federal match--and for ongoing operations 
of the system--at a 75 percent federal match.
    For Medicaid managed care entities, we assume an MCO, PIHP, and 
PAHP cost for implementing the standards-based API provisions would be 
built into the capitation rates and paid for by the state Medicaid 
agency, with the state Medicaid agency being reimbursed at the state's 
medical assistance match rate. For purposes of these estimates we use 
the weighted FMAP, 58.44, which is based on our past experience with 
this program.
    Medicaid managed care costs constitute 52 percent of the Medicaid 
program costs.\72\
---------------------------------------------------------------------------

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

    Consequently, for the first year (implementation year), the federal 
matching is (0.48*0.90+0.52*0.5844) of the total program costs, 
reflecting the 90 percent first year implementation matching for state 
agencies which comprise 48 percent of the program cost plus 58.44 
percent matching for the Medicaid managed care plans which comprise 52 
percent of the program costs. Similarly, for years after the first the 
federal costs are (0.48*0.75+0.52*0.5844) of total program costs.
    CHIP: Most states operate Medicaid and CHIP from the same state 
agency. One state is a notable exception in that it has a separate 
Medicaid and CHIP agency. The federal government pays an enhanced 
federal medical assistance percentage (EFMAP) to states for all costs 
associated with CHIP, including systems costs (this is unlike Medicaid 
where there are different FMAPs for different types of costs). For 
federal FY 2019, the EFMAPs will range from 88 to 100 percent. For 
federal FY 2020, the EFMAPs will range from approximately 76.5 to 93 
percent. After federal FY 2020, the EFMAPs will range from 
approximately 65 to 81.5 percent. Since the CHIP program federal rebate 
ranges include the 90 percent and 75 percent federal matching 
proportions of the Medicaid program, we are applying the 90 percent and 
75 percent from Medicaid to the CHIP programs. Since the CHIP program 
is small relative to the Medicaid program, we believe this approach 
reasonable.
    Table 9 uses these proportions to estimate the impact of the API on 
the federal government. For example, the $65.2 million cost to the 
federal government for Medicaid/CHIP for 2020

[[Page 25616]]

(low estimate), the implementation year of the API, is obtained by 
multiplying the total $88.6 million (low estimate) cost listed in Table 
8 by (0.48*0.90+0.52*0.5844) the ratio indicated in the previous 
paragraphs.
    These assumptions on all first-year federal expenses are reflected 
in Table 9 which includes PTC payments as well as federal matching in 
Medicaid and Medicare. For PTC and Medicare we have assumed Federal 
payment in 2021. We note that we are not discussing at this point how 
parent organizations will bear these costs. This will be discussed 
below. However, the basis for the discussion is the calculation of non-
federal cost born by enrollees and plans which is obtained by 
subtracting federal costs from total costs.

                         Table 9--Costs Incurred by Federal Government Program and Year
                                                  [In Millions]
----------------------------------------------------------------------------------------------------------------
                                                                  For individual   For Medicaid    For Medicare
                              Year                                 market plans        CHIP          Advantage
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).............................................             0.0            65.2             0.0
2020 (Primary estimate).........................................             0.0           130.4             0.0
2020 (High Estimate)............................................             0.0           195.5             0.0
2021 (Low estimate).............................................             6.1            11.8            50.2
2021 (Primary Estimate).........................................             6.1            11.8            92.1
2022 (High Estimate)............................................             6.1            11.8           133.9
2022............................................................             6.2            11.8             8.4
2023............................................................             6.2            11.8             8.4
2024............................................................             6.3            11.8             8.4
2025............................................................             6.3            11.8             8.4
2026............................................................             6.3            11.8             8.4
2027............................................................             6.3            11.8             8.4
2028............................................................             6.3            11.8             8.4
2029............................................................             6.4            11.8             8.4
                                                                 -----------------------------------------------
    Total (Low Estimate)........................................            56.4           171.0           117.1
                                                                 -----------------------------------------------
    Total (Primary Estimate)....................................            56.4           236.2           159.0
                                                                 -----------------------------------------------
    Total (High Estimate).......................................            56.4           301.4           200.8
----------------------------------------------------------------------------------------------------------------
Note: The following percentages were applied to Table 8 to obtain Table 9: 0 percent for individual market
  plans, 34 percent for Medicare advantage plans and 0.48*0.90+0.52*0.5844 (1st year) and 0.48*0.75+0.52*0.5844
  (later years) for Medicaid. Furthermore, as discussed above, federal payments to Medicare Advantage for
  implementation occurs fully in 2021.

    By taking the difference between the respective cells in Tables 8 
(total costs by program) and 9 (total matching by the federal 
government), we obtain the remaining costs for the API for Medicare 
Advantage plans and for state Medicaid agencies. To this amount (which 
only deals with the API provisions) must be added the coordination cost 
for the dual eligible (column 3 of Table 5) multiplied by the 
proportion of costs presented in Table 7. This remaining cost born by 
Medicare Advantage plans and state Medicaid agencies is presented in 
Table 10. Since the federal government does not match QHP costs, the 
total cost for QHPs on the FFEs is born in its entirety by the plans. 
This also is listed in Table 10; however, in subtracting Table 9 from 
Table 8, we exclude PTC costs. These are federal costs, but unlike 
Medicare Advantage and Medicaid, the QHPs on the FFEs must account for 
the full cost of implementation. These PTC costs are not used to defray 
API costs.
    For example, Table 10 lists for 2020 (low estimate), Medicaid/CHIP 
a remaining cost to states of $24.3 million ($88.6 million total (low 
estimate) cost for 2020 (Table 8)-$65.2 million matched by the federal 
government (Table 9) + ($2.8 million total cost for coordination of 
dual eligibles (Table 5) * 32.56 percent (proportion of total costs 
incurred by Medicaid/CHIP (Table 7)). (There are minor differences due 
to rounding.)

                              Table 10--Remaining Costs by Program for API by Year
                                                  [In millions]
----------------------------------------------------------------------------------------------------------------
                                                                  For individual   For Medicaid/   For Medicare
                              Year                                  market plans       CHIP          Advantage
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).............................................            61.0            24.3           124.3
2020 (Primary estimate).........................................           121.3            47.7           247.4
2020 (High Estimate)............................................           181.7            71.1           370.1
2021 (Low estimate).............................................            12.8             7.0           -24.1
2021(Primary Estimate)..........................................            12.8             7.0           -65.9
2021 (High Estimate)............................................            12.8             7.0          -107.8
2022............................................................            12.3             6.2            16.6
2023............................................................            12.1             6.0            16.2
2024............................................................            12.1             6.0            16.2
2025............................................................            12.1             6.0            16.2
2026............................................................            12.1             6.0            16.2
2027............................................................            12.1             6.0            16.2
2028............................................................            12.1             6.0            16.2

[[Page 25617]]

 
2029............................................................            12.1             6.0            16.2
                                                                 -----------------------------------------------
    Total (Low Estimate)........................................           170.5            79.3           230.6
                                                                 -----------------------------------------------
    Total (Primary Estimate)....................................           230.9           102.6           311.8
                                                                 -----------------------------------------------
    Total (High Estimate).......................................           291.3           126.0           392.7
----------------------------------------------------------------------------------------------------------------

    We next discuss in Tables 11 through 13 how payers and the federal 
government will deal with these extra costs. We also discuss whether 
the costs are excessive for existing plans as well as how new plans 
might deal with these costs.
    The further discussion of bearing these costs is illustrated by 
reformulating the costs in terms of costs per enrollee (per year), 
which is obtained by dividing the total cost to the payer for all 
programs in which it participates (Medicare, Medicaid, CHIP, and 
Individual market plans) by its total enrollment. As an example, if a 
payer hypothetically spent $1 billion in a year for 100,000 enrollees 
then the cost per enrollee per year is $10,000 ($1 billion/100,000).
    As can be seen from this example, the cost per enrollee metric 
facilitates comparison of costs. Since program expenditures for both 
Medicaid and MA are typically hundreds of millions (or billions) of 
dollars, concepts like burden and negligibility may not have intuitive 
meaning, as opposed to the costs per enrollee, which are more 
manageable and understandable.
    To provide background, the 2018 Medicare Trust Fund Report \73\ 
states that costs per enrollee are projected to be roughly $12,000--
$14,000 for contract years 2020--2023 (Table IV.C3). The costs per 
enrollee for the Medicaid program are similarly several thousand 
dollars. The estimates in the 2019 Medicare Trust Fund Report are 
identical.\74\
---------------------------------------------------------------------------

    \73\ Boards of Trustees (Federal Hospital Insurance and Federal 
Supplementary Medical Insurance Trust Funds). (2018, June 5). The 
2018 Annual Report of The Boards of Trustees of the Federal Hospital 
Insurance and Federal Supplementary Medical Insurance Trust Funds. 
Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2018.pdf.
    \74\ See page 154 in, Boards of Trustees (Federal Hospital 
Insurance and Federal Supplementary Medical Insurance Trust Funds). 
(2019, April 22). The 2019 Annual Report of The Boards of Trustees 
of the Federal Hospital Insurance and Federal Supplementary Medical 
Insurance Trust Funds. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/ReportsTrustFunds/Downloads/TR2019.pdf.
---------------------------------------------------------------------------

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

    \75\ Centers for Medicare and Medicaid Services. (n.d.). October 
2019 Medicaid & CHIP Enrollment Data Highlights. Retrieved from 
https://www.medicaid.gov/medicaid/program-information/medicaid-and-chip-enrollment-data/report-highlights/.
    \76\ Centers for Medicare and Medicaid Services. (n.d.). Monthly 
Contract Summary Report--August 2018. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/MCRAdvPartDEnrolData/Monthly-Contract-and-Enrollment-Summary-Report-Items/Contract-Summary-2018-08.html?DLPage=1&DLEntries=10&DLSort=1&DLSortDir=descending.
    \77\ Centers for Medicare and Medicaid Services. (n.d.). October 
2019 Medicaid & CHIP Enrollment Data Highlights. Retrieved from 
https://www.medicaid.gov/medicaid/program-information/medicaid-and-chip-enrollment-data/report-highlights/.
---------------------------------------------------------------------------

    For example, the 2020 (low estimate) cost per enrollee for 
commercial individual market plans is $3.48 (Table 11), which is 
obtained by dividing the total, 2020, low-estimate, non-federal, 
individual market plan cost of $61 million (Table 10) by 17.5 million 
enrollees. (This is based on the low estimate of cost for API; the high 
estimate of cost would be $10.38 = $181.7 million/17.5 million).
    The 2022 cost per enrollee for state Medicaid agencies after 
federal matching is 9 cents per enrollee (Table 11), which is obtained 
by dividing the total non-federal cost per program after federal 
matching, $6.2 million (Table 10) by 73 million enrollees (66 million 
in Medicaid + 7 million in CHIP). Each of these three calculations 
restates total spending per program per stakeholder (government, state 
Medicaid agencies, or Medicare Advantage plans) in terms of cost per 
enrollee.

             Table 11--Average Cost per Enrollee per Year (Dollars and Cents) by Program for Payers
----------------------------------------------------------------------------------------------------------------
                                                                    Individual                       Medicare
             Current enrollment by payer (millions)                market plans      Medicaid        Advantage
                                                                      (17.5)        plans (73)      plans (20)
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).............................................            3.48            0.33            6.22
2020 (Primary estimate).........................................            6.93            0.65           12.37
2020 (High Estimate)............................................           10.38            0.97           18.51
2021 (Low estimate).............................................            0.73            0.10           -1.20
2021(Primary Estimate)..........................................            0.73            0.10           -3.30
2021 (High Estimate)............................................            0.73            0.10           -5.39
2022............................................................            0.70            0.09            0.83
2023............................................................            0.69            0.08            0.81
2024............................................................            0.69            0.08            0.81
2025............................................................            0.69            0.08            0.81

[[Page 25618]]

 
2026............................................................            0.69            0.08            0.81
2027............................................................            0.69            0.08            0.81
2028............................................................            0.69            0.08            0.81
    2029........................................................            0.69            0.08            0.81
                                                                 -----------------------------------------------
    Total (Low Estimate)........................................             9.7             1.1            11.5
                                                                 -----------------------------------------------
    Total (Primary Estimate)....................................            13.2             1.4            15.6
                                                                 -----------------------------------------------
    Total (High Estimate).......................................            16.6             1.7            19.6
----------------------------------------------------------------------------------------------------------------


       Table 12--Average Cost per Enrollee per Year (Dollars and Cents) by Program for Federal Government
----------------------------------------------------------------------------------------------------------------
                                                                    Individual                       Medicare
             Current enrollment by payer (millions)                market plans      Medicaid        Advantage
                                                                      (17.5)        plans (73)      plans (20)
----------------------------------------------------------------------------------------------------------------
2020 (Low estimate).............................................            0.00            0.89            0.00
2020 (Primary estimate).........................................            0.00            1.79            0.00
2020 (High Estimate)............................................            0.00            2.68            0.00
2021 (Low estimate).............................................            0.35            0.16            2.51
2021(Primary Estimate)..........................................            0.35            0.16            4.60
2021 (High Estimate)............................................            0.35            0.16            6.69
2022............................................................            0.35            0.16            0.42
2023............................................................            0.35            0.16            0.42
2024............................................................            0.36            0.16            0.42
2025............................................................            0.36            0.16            0.42
2026............................................................            0.36            0.16            0.42
2027............................................................            0.36            0.16            0.42
2028............................................................            0.36            0.16            0.42
2029............................................................            0.37            0.16            0.42
                                                                 -----------------------------------------------
    Total (Low Estimate)........................................             3.2             2.3             5.9
                                                                 -----------------------------------------------
    Total (Primary Estimate)....................................             3.2             3.2             7.9
                                                                 -----------------------------------------------
    Total (High Estimate).......................................             3.2             4.1            10.0
----------------------------------------------------------------------------------------------------------------

    In Table 13, we explain possible ways payers may deal with these 
extra costs. We emphasize that Table 13 lists potential legal 
possibilities. What actually happens will depend on market dynamics and 
internal business decisions, and we have no straightforward way of 
predicting what these actual behaviors and responses will be.
    Individual Market Plans: As noted above, individual market plans 
have the option of absorbing costs or passing costs to enrollees either 
in the form of higher premiums or reduced benefits that are non-
essential health benefits (EHBs). The average estimated cost per 
enrollee in 2021 through 2028 is under a dollar, which we assume 
issuers would pass on to enrollees. However, for purposes of market 
competitiveness, it is possible that some of the 2020 average estimated 
cost of $3.48 per enrollee (low estimate) or $10.38 per enrollee per 
year (high estimate) would be absorbed by each QHP issuer on an FFE.
    Medicaid: State Medicaid agencies and CHIP are adding a cost under 
10 cents per enrollee for 2021 through 2029. Total costs per enrollee 
for the Medicaid program are several thousand dollars. We note, the 
federal government is incurring costs capped at $2.68 per enrollee per 
year in 2020 and at 16 cents per enrollee per year in 2021 through 
2029.
    Medicare Advantage: In their bids (submitted the June prior to the 
beginning of the coverage year), Medicare Advantage plans would address 
the reduced rebates (arising from increased bid costs due to the 
increased costs of this final rule being included in the bid) by 
either: (1) Temporarily absorbing costs by reducing profit margins; (2) 
reducing the supplemental benefits paid for by the rebates; or (3) 
raising enrollee cost sharing or premiums (however, we believe many 
plans for competitive reasons would chose to remain zero premium and 
either absorb losses for one year or reduce rebate-funded supplemental 
benefits in the amount per enrollee shown in Table 9). Table 13 
summarizes these methods of bearing the remaining costs.

[[Page 25619]]



            Table 13--How Payers Would Defray Remaining Costs
------------------------------------------------------------------------
 
------------------------------------------------------------------------
Individual Market Plans...........  Individual market plans generally
                                     have the option of absorbing costs
                                     (for example, for reasons of market
                                     competitiveness), increasing
                                     premiums to enrollees, or modifying
                                     cost-sharing or non-EHB covered
                                     benefits. Cost would be spread over
                                     all parent organization enrollees
                                     in a specified state and the
                                     individual market in FFE states.
                                     Small commercial individual market
                                     issuers seeking certification of
                                     plans as QHPs on the FFEs may
                                     request an exception to the API
                                     provisions.
Medicaid/CHIP.....................  State Medicaid agencies would bear
                                     the cost (under 10 cents per
                                     enrollee). Medicaid plans are fully
                                     capitated but may have to defer
                                     first year costs.
Medicare Advantage (MA)...........  MA plans in their June-submitted
                                     bids would address the reduced
                                     rebates (arising from increased bid
                                     costs due to the increased costs of
                                     this final rule being included in
                                     the bid) by either: (1) Temporarily
                                     absorbing costs by reducing profit
                                     margins; (2) reducing additional
                                     benefits paid for by the rebates;
                                     or (3) raising enrollee cost
                                     sharing (however, many plans for
                                     competitive reasons would chose to
                                     remain zero premium and either
                                     absorb losses for one year or
                                     reduce additional, rebate-funded
                                     benefits in the amount per enrollee
                                     shown in Table 9). Tax deferment
                                     and amortization as applicable
                                     ameliorates cost. Capital costs are
                                     spread over entire parent
                                     organization enrollees. New plans
                                     are allowed to enter with initial
                                     negative margins with the
                                     expectation that they will
                                     stabilize over the first few years.
------------------------------------------------------------------------

    PTC Impact: First, we note that there will be no impact on the 
expected 2020 PTC payment because 2020 premium rates were finalized 
last year, so even if issuers incur expenses that they did not 
anticipate when setting rates, they will not be able to reflect those 
expenses in the premium rates, and therefore, the expected PTC payments 
for 2020 will not change.
    Table 10 shows that for 2021 through 2029 the estimated impact to 
QHPs on the FFEs is a $12 million expense. This estimated $12 million 
expense burden represents an increase to annual FFE premium of 
approximately 0.03 percent.
    Within the FFE states, the estimated expense burden will impact 
premium rates in the individual market, and is spread across both 
Exchange and non-Exchange QHPs. PTCs are only paid for QHPs offered 
through Exchanges, and are calculated as a function of the second 
lowest cost silver plan. Because of the wide variability of Exchange 
plans we make the simplifying assumption that the industry would 
increase the second-lowest-cost silver plan premium rate in the same 
amount as the overall premium rate increase as a result of the RIA 
expense estimate. We can then apply the overall rate increase to the 
projected PTC payments in the FFE states to estimate the impact to PTC 
payments.
    Therefore, we estimate that impact to PTCs in the FFE states will 
be approximately $6 million per year starting in 2021, which is about 
0.02 percent of the total 2021 expected PTC payment in FFE states. 
Again, the calculated PTC impacts in 2021 through 2029 are included 
with all federal impacts in Table 9.
    We next summarize the public comments we received on our estimated 
impacts and provide our responses.
    Comment: Some commenters requested that the government share more 
in the associated costs of the open, standards-based API implementation 
for both MA and Medicaid plans. These commenters noted that additional 
financial sharing by the federal government would help remedy offsets 
potentially being absorbed by the health plan that may result in 
decreased benefits and/or increase premiums.
    Medicare Advantage: Some commenters requested that the costs be 
included in MA bids. Other commenters recommended that if CMS is going 
to make specific technological requirements around implementation of 
the CMS Interoperability and Patient Access proposed rule then health 
plans should be allowed to include a percentage of these costs in their 
MA bids. One commenter recommended that CMS could consider adding a 
fixed dollar amount to MA bids if health plans complied with the 
requirements of the proposed rule, or CMS could add it into the bid 
tool.
    Medicaid: Similar comments were made for Medicaid plans. One 
commenter recommended that CMS provide states with a 100 percent 
federal matching to facilitate implementation and that state Medicaid 
agencies be required to include plan implementation costs into 
capitation rates. Another commenter requested that CMS require state 
Medicaid agencies to include a fixed amount of dollars or a percentage 
of implementation costs into plan administrative costs to remedy the 
cost impact of implementation.
    Response: We appreciate the commenters' concerns and suggestions. 
As noted previously in this RIA, we have assumed traditional federal 
sharing of costs for both the MA and Medicaid programs. The results 
have been presented in Tables 9 through 12 with Table 13 indicating how 
payers and the federal government would defray costs. In Tables 11 and 
12 the average estimated costs per enrollee (under $15) is compared 
with overall costs per enrollee (several thousand dollars). 
Additionally, we have been careful in our analysis to distinguish 
between federal matching to state Medicaid entities in the first year, 
federal matching to state Medicaid entities in later years, and federal 
matching of state payment of capitation rates to state Medicaid 
agencies. We take note that the commenter's concerns for specific 
federal matching for the provisions of this final rule would require 
legislative action. Consequently, when writing the CMS Interoperability 
and Patient Access proposed rule, we did not believe it was necessary 
to propose additional federal spending beyond the already existing 
federal reimbursement to MA, Medicaid plans, and state agencies.
    Comment: A few commenters expressed concern that the CMS 
Interoperability and Patient Access proposed rule was not clear with 
regard to whether or not state Medicaid agencies would be allowed to 
allocate the costs of this implementation--at a 90 percent federal 
match--and for ongoing operations of the system--at a 75 percent 
federal match. Commenters requested that CMS provide clarity around the 
use of such language and exactness of ``pay fors'' since this is vital 
for state Medicaid agencies' cost estimates in implementing the 
requirements of this rule.
    Response: We agree with the commenters. We therefore have revised 
the calculations to Table 10 to reflect the following more precise 
accounting of costs: (1) 90 percent of state Medicaid costs are paid or 
matched by the federal government in the first year of implementing new 
systems; (2) 75 percent of Medicaid costs are matched for maintenance 
costs; and (3) on average, state Medicaid agencies are

[[Page 25620]]

matched 58.44 percent. We believe this heightened level of detail 
should satisfy commenter concerns. The revised numbers are reflected in 
Tables 10 and Table 11.
    Comment: One commenter noted that the developers of APIs may want 
additional fees to implement or provide access to their APIs. The 
commenter noted that these fees severely limit innovation in the 
marketplace for health IT solutions for storing and utilizing patient 
data, both on the patient and provider side of the equation.
    Response: The data that must be shared via the API under this 
policy are data that the payers have and must currently make available 
to patients. We also anticipate that many payers will develop the APIs 
in-house. If this commenter is more referencing the vendors creating 
apps, versus APIs for payers, we also do not believe it is appropriate 
to charge a fee, as discussed in section III. of this final rule. If 
fees are charged for certain apps, it is not the data that are 
generating the fee, it is the product or services; indeed, there is a 
logical connection between the potential benefits of this rule 
(facilitated by new or enhanced services) and non-quantified potential 
costs (possibly including those associated with the development or 
improvement of such services). Currently there are vendors that collect 
the publicly available directory data, clean these data, supplement 
these data, and offer this enhanced data product back to payers and 
providers. It is not the data the vendors are charging for as much as 
it is the service of cleaning and enhancing these data. Vendors may 
generate revenue from their third-party apps, but a major component of 
this is the service they are providing--building the app, making the 
data the patient directs to them most usable and valuable--that 
generates the revenue. Payers must already make these data available to 
patients. These data alone may also drive revenue, but it is the 
patient's prerogative to provide their data to a third party in order 
to get a service in exchange
    Comment: A few commenters noted that RIA does not contain any costs 
for provider EHR connectivity. One commenter noted that EHR developers' 
contracts with providers and health systems do not include the cost of 
system updates that will be required to comply with this proposal. 
Another commenter was concerned that EHR developers will charge 
providers significant fees to perform the updates required to comply 
with CMS' proposals, and providers will likely need to make additional 
investments to learn how to use standards-based APIs and other new 
technologies. Another commenter believes that for the clinical data to 
be available in any API, the CEHRT used by providers needs to be 
connected to a trusted exchange network. For many clinicians, the 
commenter noted the costs for connecting their CEHRT to a trusted 
network continues to remain a barrier.
    Response: To address commenters' concerns with API connectivity to 
an EHR, we note that there is no requirement for a payer to link the 
Patient Access API to an EHR in this final rule, and there are 
associated challenges, as discussed elsewhere in this RIA, with 
attributing impacts to various interacting regulatory and other 
policies. Indeed, we do note that if a provider does elect to connect 
an EHR to the APIs finalized in this rule, they would be required to 
meet all the requirements of ONC's Health IT Certification Program.\78\ 
As part of that program, the 2015 CEHRT includes, for example, 
``application access'' certification criteria that requires health IT 
to demonstrate it can provide application access to the Common Clinical 
Data Set (CCDS) via an API.\79\ Furthermore, nearly a third of EHR 
vendors are also using the FHIR standard to meet 2015 CEHRT 
requirements.\80\
---------------------------------------------------------------------------

    \78\ Office of the National Coordinator. (2019, March 27). About 
the ONC Health IT Certification Program. Retrieved from https://www.healthit.gov/topic/certification-ehrs/about-onc-health-it-certification-program.
    \79\ Centers for Medicare and Medicaid Services. (n.d.). 2019 
Promoting Interoperability Programs: 2015 Edition Certified EHR 
Technology Fact Sheet. Retrieved from https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/CEHRT2015Ed_FactSheet-.pdf.
    \80\ Posnack, S. & Baker, W. (2018, October 1). Heat Wave: The 
U.S. is Poised to Catch FHIR in 2019. Retrieved from https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019.
---------------------------------------------------------------------------

C. Anticipated Effects

    The RFA, as amended, requires agencies to analyze options for 
regulatory relief of small businesses, if a rule has a significant 
impact on a substantial number of small entities. For purposes of the 
RFA, small entities include small businesses, nonprofit organizations, 
and small governmental jurisdictions.
    The API requirements in this final rule affect: 1) QHP issuers on 
the FFEs, 2) MA organizations, including those that are also Part D 
sponsors of MA-PD plans, as well as 3) Medicaid MCOs with a minimum 
threshold for small business size of $41.5 million (https://www.sba.gov/federal-contracting/contracting-guide/size-standards).
    Assessment of impact is complicated by the fact that costs have 
been aggregated at the parent organization level. A typical parent 
organization might have products with QHP issuers on the FFEs, MA, or 
Medicaid/CHIP programs. We have no way of directly assessing the size 
of parent organizations. Therefore, as a proxy, we analyze each payer 
separately.
    Medicare Advantage: We first assess the impact on MA plans. To 
clarify the flow of payments between these entities and the federal 
government, we note that MA organizations submit proposed plan designs 
and estimates of the amount of revenue necessary to cover the cost of 
those plan designs (called bids) by the first Monday in June of the 
year preceding the coverage year. Regulations governing this process 
are in 42 CFR part 422, subpart F. These bids must be broken down in 
the following:
    (1) The revenue requirements for providing Medicare Part A and Part 
B benefits with actuarially equivalent cost sharing (this is the 
``basic benefit bid'');
    (2) The revenue requirements for providing supplemental benefits;
    (3) The revenue requirements for Non-Benefit Expenses such as Sales 
& Marketing, Direct and Indirect Administration, Net Cost of 
Reinsurance, and Insurance Fees; and
    (4) For MA-PD plans, a Part D bid consistent with Part D 
regulations in 42 CFR part 423.
    These bids project payments to hospitals, providers and staff for 
covered benefits, as well as the cost of plan administration and 
profits. Because the API requirements finalized in this rule will apply 
to every MA plan and each MA plan must furnish at least the Medicare 
Part A and Part B benefits, the cost of the API will be built into the 
administrative component of the basic benefit bid. These bids in turn 
determine one component of the payments of the Medicare Trust Fund to 
the MA organizations who reimburse providers and subcontractors for 
their services. A second component of the Trust Fund payment to MA 
organizations are the rebates, which are a portion of the difference 
between the basic benefit bid compared to an administratively-set 
benchmark for the MA plan's service area (currently, based on our past 
and projected experience, rebates vary by plan and are approximately 66 
percent). Benchmarks are based on a formula using an estimate of the 
Medicare FFS per capita cost for the geographic area, which are 
adjusted to reflect the per capita cost of each county in the U.S. and 
its territories and adjusted for the enrollees' health status

[[Page 25621]]

which is also known as the risk score. Payments from the Medicare Trust 
Funds for monthly capitation rates (for basic benefits) are capped at 
the benchmark; for basic benefit bids under the benchmark, a portion, 
currently approximately 66 percent, of the difference between the bid 
and benchmark is made available to the MA organization to either: (1) 
Pay for additional supplemental benefits; (2) include reductions in 
cost sharing in the plan design; or (3) provide buy-downs of Part B or 
Part D premiums. Basic benefit bids that are at or above the benchmark 
receive payment from the Trust Funds of the benchmark amount, with any 
excess charged to the enrollee as a premium.
    MA organizations are made aware of the benchmark through the annual 
CMS publication, ``Announcement of Calendar Year [X] Medicare Advantage 
Capitation Rates and Medicare Advantage and Part D Payment Policies,'' 
which, consistent with section 1853 of the Act, is released prior to MA 
organizations submission of bids. This publication of the benchmark 
when coupled with plan awareness that they will receive rebates if 
their plan bids fall below the benchmark facilitates that bids of most 
MA organizations are below the benchmark and consequently most MA 
organizations receive from the Trust Fund a total expenditure equaling 
payment for the bid plus the rebate.
    Because of these API provisions, we assume that MA organizations 
will be raising the June-submitted bid amount to reflect additional 
administrative costs. While the Trust Fund pays these bid amounts in 
full, the rebate goes down as the bid increases: That is, since the bid 
amount goes up, the rebate, equaling the difference between the 
benchmark and bid, decreases and results in less rebate payment to the 
MA organization. The MA organization has several options of dealing 
with these increased bid costs and reduced rebates: The MA organization 
might decide to: (1) Temporarily absorb the loss by reducing its profit 
margin (so as to reduce the bid amount and thereby increase the 
rebates); (2) reduce additional benefits paid to the enrollee from the 
rebates; or (3) raise enrollee premiums so as to compensate for the 
reduction of enrollee premium that would have happened if the bid had 
not been increased (note: for marketing purposes, many plans operate at 
zero premium, and we do not consider this third option a likely 
possibility). In this RIA, we have referred to options (2) and (3) 
(reduction of additional benefits and raising of enrollee premiums) as 
``passing the costs to the enrollee'' so that the ``effect'' of reduced 
rebates is fewer supplemental benefits or higher enrollee premiums than 
would have happened had the cost of the complying with the API 
provisions of this final rule not been imposed.
    There are various types of Medicare health plans, including MA 
HMOs, POS plans, and PPOs; Demonstration plans; Cost Plans; 
Prescription Drug Plans (PDP); and Programs of All-Inclusive Care for 
the Elderly (PACE) organization plans. This final rule affects MA HMOs, 
MA POS plans, and MA PPOs including those that are MA-PDs, but does not 
affect Cost Plans, stand-alone Prescription Drug Plans, nor PACE 
organizations.
    There are a variety of ways to assess whether MA organizations meet 
the $41.5 million threshold for small businesses. The assessment can be 
done by examining net worth, net income, cash flow from operations and 
projected claims as indicated in their bids. Using projected monetary 
requirements and projected enrollment for 2018 from submitted bids, 
approximately 30 percent of the MA organizations fell below the $41.5 
million threshold for small businesses. Additionally, an analysis of 
2016 data, the most recent year for which we have actual data on MA 
organization net worth, shows that approximately 30 percent of all MA 
organizations fall below the minimum threshold for small businesses.
    Medicaid: We next assess the impact on Medicaid managed care plans. 
Since Medicaid managed care plans receive 100 percent capitation from 
the state, we generally expect that the costs associated with the API 
provisions of this final rule, will be included in their capitation 
rates and may be reasonable, appropriate, and attainable costs whether 
they are a small business or not.
    QHP issuers on the FFEs: Based on the 2016 CMS MLR data, 
approximately 85 out of 494, or 17 percent of companies (that either 
had only individual market business, or had individual market plus 
Medicare and/or Medicaid business) had total premium revenue of less 
than $41,500,000. In other words, for MA, Medicaid, and QHP issuers on 
the FFEs, a significant number of small plans are affected. The RFA 
requires us to assess whether the rule has a significant impact on the 
plans, which we do next.
    If a rule has a substantial impact on a substantial number of small 
entities, the rule must discuss steps taken, including alternatives, to 
minimize burden on small entities. While a significant number (more 
than 5 percent) of not-for-profit organizations and small businesses 
are affected by this final rule, the impact is not significant. To 
assess impact, we use the data in Table 5, which shows that the total 
raw (not discounted) net effect of this final rule over 10 years is 
$714 million.
    Medicare Advantage: We first assess impact on MA plans. Comparing 
the $714 million number to the total monetary amounts projected to be 
needed just for 2018, the most recent year on which we have finalized 
plan submitted bid data (and which is expected to be less than the need 
in future years including 2019), we find that that the impact of this 
final rule is significantly below the 3 percent-5 percent threshold for 
significant impact for MA plans.
    Medicaid: We next assess impact on Medicaid managed care plans. The 
total projected capitation payment and premiums for 2019 is projected 
to be $337.6 billion.\81\ Hence, the total cost of this final rule over 
10 years, $714 million, is significantly below the 3 percent-5 percent 
threshold for significant impact to Medicaid managed care plans.
---------------------------------------------------------------------------

    \81\ See ``Capitation payments & premiums'' in Table 17 of 
Appendix D in, Office of the Actuary (Centers for Medicare and 
Medicaid Services). (2016). 2016 Actuarial Report on the Financial 
Outlook for Medicaid. Retrieved from https://www.medicaid.gov/medicaid/finance/downloads/medicaid-actuarial-report-2016.pdf.
---------------------------------------------------------------------------

    QHP issuers on the FFEs: As discussed prior to Table 6 based on 
data in the public CMS MLR files, commercial health insurance issuers 
had premium revenue of $77 billion for individual market plan coverage 
in 2016. Therefore, the aggregate raw cost of this final rule over 10 
years, $762 million (low estimate) and $1.3 billion (high estimate), is 
significantly below the 3 percent to 5 percent threshold for 
significant impact to commercial plans. We believe, that although a 
significant number of small plans under each program are affected by 
this rule, on average this impact is not significant. Additionally, we 
note that for those small entities that do find the cost of the 
provisions of this final rule burdensome, an exception process has been 
described in section III.C. of this final rule. Specifically, we note 
that we may provide an exceptions process through which the FFEs may 
certify health plans that do not provide patient access through a 
standards-based API, but otherwise meet the requirements for QHP 
certification. This process could apply for small issuers, issuers who 
are only in the individual or small group market, financially 
vulnerable issuers, or new entrants to the FFEs who demonstrate that 
deploying standards-

[[Page 25622]]

based API technology consistent with the required interoperability 
standards would pose a significant barrier to the issuer's ability to 
provide coverage to consumers, and not certifying the issuer's QHP or 
QHPs would result in consumers having few or no plan options in certain 
areas.
    Consequently, the Secretary has determined that this final rule 
will not have a significant economic impact on a substantial number of 
small entities and the requirements of the RFA have been met. Please 
see our detailed analysis of apportionment of costs per payer in Tables 
6 through 13 and section XIII.H. of this final rule for further 
details.
    In addition, section 1102(b) of the Act requires CMS to prepare an 
RIA if a rule may have a significant impact on the operations of a 
substantial number of small rural hospitals. This analysis must conform 
to the provisions of section 604 of the RFA. For purposes of section 
1102(b) of the Act, we define a small rural hospital as a hospital that 
is located outside a Metropolitan Statistical Area and has fewer than 
100 beds. We are not preparing an analysis for section 1102(b) of the 
Act because we have determined, and the Secretary certifies, that this 
final rule would not have a significant impact on the operations of a 
substantial number of small rural hospitals.
    Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) 
(Pub. L. 104-04, enacted March 22, 1995) also requires that agencies 
assess anticipated costs and benefits before issuing any rule whose 
mandates, except those that are conditions of federal program 
participation, require spending in any 1 year of $100 million in 1995 
dollars, updated annually for inflation. In 2020, that is approximately 
$156 million. This rule does not impose any such unfunded mandates.
    Executive Order 13132 establishes certain requirements that an 
agency must meet when it promulgates a proposed rule (and subsequent 
final rule) that imposes substantial direct requirement costs on state 
and local governments, preempts state law, or otherwise has federalism 
implications. This final rule will not have a substantial direct effect 
on state or local governments, preempt state law, or otherwise have a 
federalism implication. Therefore, the requirements of Executive Order 
13132 are not applicable.
    If regulations impose administrative costs, such as the time needed 
to read and interpret this final rule, we should estimate the cost 
associated with regulatory review. There are currently 288 
organizations and 56 states and territories. We assume each 
organization will have one designated staff member who will read the 
entire rule.
    Using the wage information from the BLS for medical and health 
service managers (Code 11-9111), we estimate that the cost of reviewing 
this rule is $139.14 per hour, including overhead and fringe benefits 
(https://www.bls.gov/oes/current/naics5_524114.htm). Assuming an 
average reading speed, we estimate that it would take approximately 6 
hours for each person to review this final rule. For each payer that 
reviews the rule, the estimated cost is $834.84 (6 hours x $139.14). 
Therefore, we estimate that the total cost of reviewing this regulation 
is $288,020 ($834.84 x 345 reviewers).
1. Requirements for Patient Access Through APIs
    To promote our commitment to interoperability, we are implementing 
new requirements in section III. of this final rule for MA 
organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, 
Medicaid managed care at 42 CFR 438.242, CHIP FFS at 42 CFR 457.730, 
CHIP managed care at 42 CFR 457.1233, and QHP issuers on the FFEs, 
excluding QHP issuers offering only SADPs or only FF-SHOP plans, at 45 
CFR 156.221 to implement standards-based APIs for making certain data 
available to current enrollees. The Patient Access API will permit 
third-party applications to retrieve data concerning adjudicated 
claims, encounters with capitated providers, provider remittances, 
patient cost-sharing, a subset of clinical data including lab test 
results, if maintained by the payer, and, preferred drug lists, and for 
MA-PD plans only, formulary data that includes covered Part D drugs, 
and any tiered formulary structure or utilization management procedure, 
which pertains to those drugs for MA-PD plans.
    At 42 CFR 422.120 for MA organizations, at 42 CFR 431.70 for state 
Medicaid agencies, at 42 CFR 438.242(b)(6) for Medicaid managed care 
plans, at 42 CFR 457.760 for CHIP state agencies, and at 42 CFR 
457.1233(d)(3) for CHIP managed care entities, we are finalizing the 
Provider Directory API. We believe that these policies are designed to 
empower patients by requiring that impacted payers take steps--by 
implementing the two required APIs--to enable enrollees to have access 
to their data in a usable digital format and have (potentially) easier 
means to share that data. By making these data readily available and 
portable to the patient, these initiatives may help patients have the 
ability to move from payer to payer, provider to provider, and have 
both their clinical and administrative information travel with them 
throughout their health care journey. Payers are in a unique position 
to provide enrollees with a comprehensive picture of their claims and 
encounter data, allowing patients to piece together their own 
information that might otherwise be lost in disparate systems. This 
information can contribute to better informed decision making, helping 
to inform the patient's choice of coverage options and care providers 
to more effectively manage their own health, care, and costs. By 
encouraging them to take charge of and better manage their health and 
having access to their health information, patients will have the 
ability to share this information with their other providers, which may 
reduce duplication of services, add efficiency to provider visits, and 
facilitate identification of fraud, waste, and abuse.
    To estimate the number of impacted payers, we reviewed parent 
organizations of health plans across MA organizations, Medicaid MCOs, 
and QHP issuers on the FFEs to remove organizations that would not be 
subject to the policy, such as issuers that offer only SADPs; 
transportation plans, and brokers such as non-emergency medical 
transportation (NEMTs) brokers; PACE; visiting nurse and home health 
care organizations; senior organizations such as Area Agencies on 
Aging; and other organizations such as community action programs. After 
removing these organizations, we then reviewed the remaining names of 
parent organizations and health plans in the National Association of 
Insurance Commissioners (NAIC) Consumer Information Support (CIS) 
system to determine the legal name of the entity and whether the entity 
was registered with the NAIC. We also used the 2018 NAIC Listing of 
Companies to determine whether various health plans had associated 
parent organizations using the NAIC's Group coding and numbering 
system. If the health plan or parent organization did not appear in the 
NAIC CIS or in the 2018 NAIC Listing of Companies, we then reviewed the 
name of the entity in the Securities and Exchange online Edgar system 
to locate the entity's Form 10-K filing, which includes an Exhibit 
(Exhibit 21) that requires the entity to list its subsidiaries. If the 
health plan or organization did not appear in these online systems or 
listings, an online internet search using Google search

[[Page 25623]]

engine was conducted. After review, we have determined that 288 issuers 
and 56 states, territories, and U.S. commonwealths, which operate FFS 
programs, will be subject to the API provisions for Medicare, Medicaid, 
and QHP issuers on the FFEs. To this we add the one state that operates 
its CHIP and Medicaid separately. Thus, we have a total of 345 parent 
organizations (288+56+1). We note that although 42 states have some 
lower-income children in an expansion of Medicaid, and some higher-
income children or pregnant women in a separate CHIP, all but one of 
these programs are operated out of the same agency. Although the CHIP 
programs may be distinct, we believe they will use the same 
infrastructure built for Medicaid. Thus, the addition of 1 parent 
organization for CHIP is reasonable and plausible.
    As noted in section XII.C.3. of this final rule, to implement the 
Patient Access API together with the payer-to-payer data exchange 
policies to facilitate a payer maintaining a cumulative health record 
for their current enrollees, we estimated that organizations and states 
would conduct three major work phases: Initial design; development and 
testing; and long-term support of the APIs, including increased data 
storage, such as additional servers, or cloud storage to store patient 
health information and maintain it, and allocation of resources to 
maintain the FHIR server, and perform capability and security testing. 
(For a detailed description of these phases, see section XII.C.3. of 
this final rule.)
    As part of our research into the regulatory impact, we reviewed a 
sample of health plan organizations offering MA plans to determine 
whether any currently offer patient portal functionality with the MA 
plan. If yes, we reviewed whether they offered the opportunity to 
connect to Medicare's Blue Button 2.0. Health plan organizations 
offering MA plans were identified from June 2018 data and statistics 
compiled at https://www.cms.gov/Research-Statistics-Data-and-Systems/Statistics-Trends-and-Reports/MCRAdvPartDEnrolData/. We 
initially reviewed the functionality offered by three organizations, 
which together enroll over half of MA members through review of 
publicly-available information such as press releases and website 
informational materials. We found from this review that these 
organizations not only offered patient portals primarily focused on 
claims and user-entered data on their website, but that all three also 
offered enrollees the opportunity to connect to Blue Button. We then 
identified a selection of other health plan organizations at random and 
conducted the same evaluation. Results indicate that the majority of 
the health plan organizations we reviewed offer patients a way to 
access claims data and other information via their websites and 
sometimes via applications.
    We also cross-referenced health plan organizations offering MA 
plans with health plan organizations that offer plans in the Federal 
Employees Health Benefits (FEHB) Program because a percentage of those 
organizations offer plans with patient portal access and Blue Button 
functionality. The FEHB Program, administered by the Office of 
Personnel Management (OPM), reported in 2014 that 90 percent of its 
participating plans offered enrollees access to a personal health 
record on the organization's website. In addition, OPM reported that 
over half of the FEHB participating plans expected to offer Blue Button 
functionality by January 1, 2016. We sought to learn whether there was 
any overlap between these two lists of organizations to gauge whether 
additional organizations may already have the capability to offer 
either patient portals or Blue Button, albeit in a different business 
arm, as having internal capability may assuage some of the cost of 
building out a new API to support patient access to claims data. While 
we found significant overlap between UnitedHealthcare and the Blue 
Cross Blue Shield Affiliates, we also were able to identify other 
organizations that offer both MA plans and plans included in the FEHB. 
While not definitive, this data allows us to draw the conclusion that a 
number of health plan organizations have the technology in place to 
offer patient portals to MA enrollees and, further, also have the 
ability to offer MA enrollees Blue Button functionality.
    As detailed in section XII. of this final rule and summarized in 
Table 5, given the current state of interoperability, we estimate the 
burden related to the new requirements for APIs to have an initial set 
one-time costs of $788,414 per implementation or an aggregate cost of 
$272 million ($788,414 x 345 parent organizations) minimum estimate; an 
initial one-time cost of $1,576,829 per organization or state or an 
aggregate cost of $544 million ($1,576,829 x 345 parent organizations) 
primary estimate; and, an initial one-time cost of $2,365,243 per 
organization or organization or an aggregate $816 million ($2,365,243 x 
345 parent organizations) high estimate. For a detailed discussion of 
the one-time costs associated with implementing the API requirements we 
refer readers to section XII.C.3. of this final rule. Once the API is 
established, we believe that there will be an annual cost for 
performing necessary capability and security testing, performing 
necessary upgrades, vetting of third-party applications, and 
maintaining patient health information. We estimate the burden related 
to the requirements for APIs to have an annual cost of $157,657 per 
implementation or an aggregate cost of $54 million (345 parent 
organizations x $157,657). For a detailed discussion of the annual 
costs associated with implementing the API requirements, we refer 
readers to section XII.C.3. of this final rule.
    We are committed to fulfilling our role in promoting 
interoperability, putting patients first and ensuring they have access 
to their health care data. We recognize that there are significant 
opportunities to modernize access to patient data and its ability to 
share across the health ecosystem. We realize the importance of 
interoperability and the capability for health information systems and 
software applications to communicate, exchange, and interpret data in a 
usable and readable format. Although allowing access to health care 
data through pdf and text format is vital, it limits the utility of the 
data, and its ability to be easily accessed and shared. Additionally, 
we realize that moving to a system in which patients have access to 
their health care data will ultimately empower them to make informed 
decisions about their health care. Our policies here do not go as far 
as our goals for how patients will be ultimately empowered, but take 
steps in that direction.
    We note that the federal government has spent over $35 billion 
under the EHR Incentive Programs \82\ to incentivize the adoption of 
EHR systems; however, despite the fact that 78 percent of physicians 
and 96 percent of hospitals now use an EHR system,\83\ progress on 
system-wide data sharing has been limited. Previous attempts to advance 
interoperability have made incremental progress but have failed to 
align the necessary stakeholders to drive momentum in a single 
direction. In 2018, the Administration launched the

[[Page 25624]]

MyHealthEData initiative.\84\ This government-wide initiative aims to 
empower patients by ensuring that they have access to their own health 
care data and the ability to decide how their data will be used, while 
keeping that information safe and secure. MyHealthEData aims to break 
down the barriers that prevent patients from gaining electronic access 
to their health care data and allow them to access that data from the 
device or application of their choice that will connect to a plan's 
API, empowering patients and taking a critical step toward 
interoperability and patient data exchange.
---------------------------------------------------------------------------

    \82\ Centers for Medicare and Medicaid Services. (2018, May). 
EHR Incentive Program, Payment Summary Report. Retrieved from 
https://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/Downloads/May2018_SummaryReport.pdf.
    \83\ Office of the National Coordinator. (2015). Health IT 
Dashboard--Office-based Physician Health IT Adoption: State rates of 
physician EHR adoption, health information exchange & 
interoperability, and patient engagement. Retrieved from https://dashboard.healthit.gov/apps/physician-health-it-adoption.php.
    \84\ Centers for Medicare and Medicaid Services. (2018, May 6). 
Trump Administration Announces MyHealthEData Initiative to Put 
Patients at the Center of the US Healthcare System. Retrieved from 
https://www.cms.gov/Newsroom/MediaReleaseDatabase/Press-releases/2018-Press-releases-items/2018-03-06.html.
---------------------------------------------------------------------------

    Payers should have the ability to exchange data instantly with 
other payers for care coordination or transitions, and with providers 
to facilitate more efficient care. Payers are in a unique position to 
provide enrollees a complete picture of their claims and encounter 
data, allowing patients to piece together their own information that 
might otherwise be lost in disparate systems. We are committed to 
solving the issue of interoperability and achieving complete patient 
access in the U.S. health care system and are taking an active approach 
using all available policy levers and authorities available to move all 
participants in the health care market toward interoperability and the 
secure exchange of health care data. The modern internet app economy 
thrives on a standards-based API software environment. Part of the 
health care API evolution is incorporating many of the current 
protocols from leading standards development organizations with the 
newer FHIR web developer-friendly way of representing clinical data.
2. Increasing the Frequency of Federal-State Data Exchanges for Dually 
Eligible Individuals
    We routinely exchange data with states on who is enrolled in 
Medicare, and which parties are liable for paying that beneficiary's 
Part A and B premiums. These buy-in data exchanges support state, CMS, 
and SSA premium accounting, collections, and enrollment functions. CMS 
subregulatory guidance, specifically Chapter 3 of the State Buy-in 
Manual, specifies that states should exchange buy-in data with CMS at 
least monthly, but provides the option for states to exchange buy-in 
data with CMS daily or weekly. Likewise, states can choose to receive 
the CMS response data on a file daily or monthly.
    We are establishing the frequency requirements in the regulation 
itself to require all states to participate in daily exchange of buy-in 
data to CMS, with ``daily'' meaning every business day, but that if no 
new transactions are available to transmit, data would not need to be 
submitted on a given business day. States will be required to begin 
participating in daily exchange of buy-in data with CMS by April 1, 
2022.
    To estimate impact, we first note that there are a total of 51 
entities, consisting of the 50 states and the District of Columbia that 
can be affected by buy-in. Currently, 25 entities (24 states and the 
District of Columbia) now submit buy-in data files to CMS daily and 32 
entities (31 states and the District of Columbia) receive buy-in data 
files from CMS daily. Consequently, we expect a one-time burden for 26 
states (51 total entities minus 25 entities currently submitting daily 
buy-in data) to comply with the daily buy-in data submissions, and a 
similar one-time burden for 19 states (51 total entities minus 32 
entities currently receiving buy-in data) to comply with the receipt of 
daily buy-in data.
    These numbers changed from those in the CMS Interoperability and 
Patient Access proposed rule to reflect the most current data available 
to CMS as of July 1, 2019. Between July 1 and publication of the final 
rule it is likely that the numbers may change more. However, as can be 
seen from Table 5, this aspect of the rule has minor impact (only a few 
million dollars) compared with the overall impact of the rule (several 
hundred million). Consequently, we are using these July 1 numbers in 
the final rule.
    We estimate that each required change, whether to submit buy-in 
data or receive buy-in data, would take 6 months of work (approximately 
960 hours) by a programmer working at an hourly rate of $90.02 per 
hour. Since there are 45 required changes (19 states that need to 
comply with receiving data plus 26 states that need to comply with 
submitting data) we estimate an aggregate burden of $3,888,864 (45 
changes * 960 hours of programming work * $90.02/hour).
    The cost per state per change is approximately $85,000 (960 * 
$90.02 = $86,419 exactly) and the costs for both changes (to both send 
and receive buy-in data daily would be approximately $170,000 (2 * 
$85,000).
    We did not estimate any savings related to exchanging buy-in data 
with greater frequency, as data lags only delay when states are billed 
for premium costs; delays do not impact the applicability date and 
total costs. While we did not estimate premium savings (since premium 
collection is ultimately correct), we anticipate that states may 
experience longer term reduction in administrative burden of making 
those corrections.
    As noted in section XII.C. of this final rule, we are updating the 
frequency requirements in 42 CFR 423.910(d) to require that starting 
April 1, 2022, all states submit the required MMA file data to CMS 
daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily 
would mean every business day, but that if no new transactions are 
available to transmit, data would not need to be submitted on a given 
business day. As noted in section XII.C. of this final rule, the 
estimated burden across impacted states is $3,111,091.
    Thus, the total burden to comply with increased frequency of 
submission of MMA files and increased frequency of submission and 
receipt of daily buy-in data files is $7 million ($3,888,864 total cost 
for the buy-in provision plus $3,111,091 total cost for the MMA file 
requirements).
    We estimate a 25-month implementation period for these system 
updates, from March 2020 to and including March 2022. In the CMS 
Interoperability and Patient Access proposed rule, we assumed a 3-year 
implementation period reflecting a May 1st start date and an April 1, 
2022 applicability date. The revised 25-month implementation period 
reflects an expected publication of this final rule in March 2020, with 
implementation beginning March 2020, and with the applicability date of 
April 1, 2022 unchanged. Although the implementation period is shorter 
(25 months versus 36 months) the purpose of the 25-month window is to 
give organizations flexibility in finding a 6-month period to perform 
updates as indicated in section XII. of this final rule. Although the 
flexibility window for this 6-month period is shortened (plans have 
less choice of which 6 months to work in), data are lacking with which 
to refine the cost estimates to reflect the shortened compliance 
period.
    States will have the ability to choose, in consultation with CMS, 
when in the 25-month implementation period they want to make this 
change, with numerous factors impacting in which year they would do so. 
For the purposes of this impact analysis, we estimated a uniform 
distribution beginning in March 2020 and ending in April 2022 as 
calculated in Table 5.

[[Page 25625]]

    Therefore, since, as noted above, the total cost impact over 25 
months is $7 million, when apportioned uniformly over the 25 months, 
the resulting impacts $2.8, $3.4, and $0.8 million for 2020, 2021, and 
2022 respectively corresponding to 10 months, 12 months, and 3 months 
in 2020, 2021 and 2022 respectively. These calculations are 
transparently presented in Table 5.
3. Revisions to the Conditions of Participation for Hospitals and 
Critical Access Hospitals (CAHs)
    We are expanding CMS' requirements for interoperability within the 
hospital and CAH CoPs by focusing on electronic patient event 
notifications. We are implementing new requirements in section X. of 
this final rule for hospitals at 42 CFR 482.24(d), for psychiatric 
hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638(d). 
Specifically, for hospitals, psychiatric hospitals, and CAHs, we are 
finalizing similar requirements to revise the CoPs for Medicare- and 
Medicaid-participating hospitals, psychiatric hospitals, and CAHs by 
adding a new standard, ``Electronic Notifications,'' that will require 
hospitals, psychiatric hospitals, and CAHs to make electronic patient 
event notifications available to applicable post-acute care services 
providers and suppliers, and to community practitioners, such as the 
patient's established primary care practitioner, established primary 
care practice group or entity, or other practitioner or practice group 
or entity identified by the patient as primarily responsible for his or 
her care. We are limiting this requirement to only those hospitals, 
psychiatric hospitals, and CAHs that utilize electronic medical records 
systems, or other electronic administrative systems, which are 
conformant with the content exchange standard at 45 CFR 170.205(d)(2), 
recognizing that not all Medicare- and Medicaid-participating hospitals 
have been eligible for past programs promoting adoption of EHR systems. 
If the hospital's (or CAH's) system conforms to the content exchange 
standard at 45 CFR 170.205(d)(2), the hospital (or CAH) must then 
demonstrate that its system's notification capacity is fully 
operational and that it operates in accordance with all state and 
federal statutes and regulations regarding the exchange of patient 
health information, and that its system, to the extent permissible 
under applicable federal and state law and regulations, and not 
inconsistent with the patient's expressed privacy preferences, sends 
the notifications either directly, or through an intermediary that 
facilitates exchange of health information. It must also demonstrate 
that the notifications include at least patient name, treating 
practitioner name, and sending institution name.
    Upon the patient's registration in the emergency department or 
admission to inpatient services, and also either immediately prior to, 
or at the time of, the patient's discharge or transfer (from the 
emergency department or inpatient services), the hospital (or CAH) must 
also demonstrate that it has made a reasonable effort to ensure that 
its system sends the notifications to all applicable post-acute care 
services providers and suppliers, as well as to any of the following 
practitioners and entities, which need to receive notification of the 
patient's status for treatment, care coordination, or quality 
improvement purposes: (1) The patient's established primary care 
practitioner; (2) the patient's established primary care practice group 
or entity; or (3) other practitioner, or other practice group or 
entity, identified by the patient as the practitioner, or practice 
group or entity, primarily responsible for his or her care.
    As we noted, infrastructure supporting the exchange of electronic 
health information across settings has matured substantially in recent 
years. Research studies have increasingly found that health information 
exchange interventions can effectuate positive outcomes in health care 
quality and public health outcomes, in addition to more longstanding 
findings around reductions in utilization and costs. Electronic patient 
event notifications from hospitals, or clinical event notifications, 
are one type of health information exchange intervention that has been 
increasingly recognized as an effective and scalable tool for improving 
care coordination across settings, especially for patients at 
discharge. This approach has been identified with a reduction in 
readmissions following implementation.\85\
---------------------------------------------------------------------------

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

    In addition, the CMS Innovation Center has been partnering with 
states through the State Innovation Models Initiative to advance multi-
payer health care payment and delivery system reform models. Through 
this initiative 34 states have been awarded over $900 million to 
implement their respective State Health Care Innovation Plans, many of 
which included enhancements in HIT and HIE. While these models are 
ongoing, evaluation reports thus far are reporting that many states are 
experiencing favorable outcomes on ED visit rates and other quality 
measures.\86\ Although patient event notifications are only a small 
piece of these models, we want to continue the momentum towards 
nationwide adoption.
---------------------------------------------------------------------------

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

    These notifications are automated, electronic communications from 
the provider to applicable post-acute care services providers and 
suppliers, and also to community practitioners identified by the 
patient. These automated communications alert the receiving provider or 
practitioner that the patient has received care at a different setting. 
Information included with these notifications can range from simply 
conveying the patient's name, basic demographic information, and the 
sending institution, to a richer set of clinical data depending upon 
the level of technical implementation. Even with a minimum set of 
information included, these notifications can help ensure that a 
receiving provider or community practitioner is aware that the patient 
has received care elsewhere. The notification triggers a receiving 
provider or practitioner to reach out to the patient to deliver 
appropriate follow-up care in a timely manner. By providing timely 
notifications, the alert may improve post-discharge transitions and 
reduce the likelihood of complications resulting from inadequate 
follow-up care.
    We believe that care coordination can have a significant positive 
impact on the quality of life, consumer experience, and health outcomes 
for patients. As we have noted in the preamble to this rule, virtually 
all EHR systems (as well as older legacy electronic administrative 
systems, such as electronic patient registrations systems, and which we 
are including in this final rule) generate the basic messages commonly 
used to support electronic patient event notifications. In addition, 
while we acknowledge that some level of implementation cost would be 
realized for those providers not already sending notifications, we also 
note there is also substantial agreement that implementation of these 
basic messaging and notification functions within such existing systems 
constitutes a relatively low cost burden for providers, particularly 
when such costs are considered alongside the innovative and beneficial 
patient care transition

[[Page 25626]]

solutions and models for best practices they provide.
    As detailed in section XI., we estimate that the total cost imposed 
on hospitals, psychiatric hospitals, and CAHs by these provisions to be 
approximately $5,179,863 in the first year and $1,042,426 in subsequent 
years.
4. Effects of Other Policy Changes
    In addition to those policy changes discussed previously that we 
are able to model, we are finalizing various other changes in this 
final rule. Generally, we have limited or no specific data available 
with which to estimate the impacts of the policy changes. Our estimates 
of the likely impacts associated with these other changes are discussed 
in this section.
a. Care Coordination Across Payers
    The majority of the 64 million people on Medicare are covered by 
FFS, however, about 34 percent are covered in MA plans. Since 2003, the 
number of beneficiaries enrolled in MA plans has increased fivefold 
from 4.6 million in 2010 to 22 million in 2019.\87\ Given the growth in 
MA enrollment and the ability for MA beneficiaries to change plans, we 
believe it is important to supporting efficient care coordination by 
requiring the sharing of key patient health information when an 
enrollee requests it. Therefore, we are requiring MA organizations, 
Medicaid managed care plans, CHIP managed care entities, and QHP 
issuers on the FFEs to maintain a process for the electronic exchange 
of, at a minimum, the data classes and elements included in the content 
standard finalized by HHS in the ONC 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register) at 45 CFR 
170.213 (currently version 1 of the USCDI), via a payer-to-payer data 
exchanged as outlined in this section V. of this final rule. 
Furthermore, we are finalizing as proposed a regulatory requirement at 
42 CFR 422.119(f)(1) and 438.62(b)(1)(vi), and at 45 CFR 156.221(f)(1) 
to require MA organizations, Medicaid managed care plans, CHIP managed 
care entities, and QHP issuers on the FFEs to incorporate the data they 
receive into the payer's record about the enrollee. We are also 
finalizing that with the approval and at the direction of an enrollee, 
a payer must send the defined information set to any other payer. We 
specify that a payer is only obligated to send data received from 
another payer under this policy in the electronic form and format it 
was received. However, we have noted that such transactions will need 
to be made in compliance with any other applicable laws.
---------------------------------------------------------------------------

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

    We believe that sending and receiving these data will help both 
plan enrollees and health care providers in coordinating care and 
reducing administrative burden. We believe that this entails utilizing 
all tools available to us to ensure that plans provide coordinated 
high-quality care in an efficient and cost-effective way that protects 
program integrity. Leveraging interoperability to facilitate care 
coordination among plans can, with thoughtful execution, significantly 
reduce unnecessary care, as well as ensure that health care providers 
are able to spend their time providing care rather than performing 
unnecessary administrative tasks. For instance, effective information 
exchange between plans could improve care coordination by reducing the 
need for health care providers to write unneeded letters of medical 
necessity; by reducing instances of inappropriate step therapy; and by 
reducing repeated utilization reviews, risk screenings, and 
assessments.
    We believe that this policy will impose minimal additional costs on 
plans. We note that we are not specifying a transport standard and 
anticipate that plans may opt to use APIs, such as the Patient Access 
API that this final rule also requires. We also anticipate that plans 
may choose to utilize a regional health information exchange. We 
believe it is difficult to quantify the impact of this change because 
plans will likely implement different transport methods, and we cannot 
predict the selected method plans will choose.
b. Care Coordination Through Trusted Exchange Networks
    In section VI. of the CMS Interoperability and Patient Access 
proposed rule, we proposed requiring MA organization, Medicaid managed 
care plans, CHIP managed care entities, and QHP issuers on the FFEs to 
participate in trust networks in order to improve interoperability. We 
also listed the requirements for participation in a trusted exchange 
network.
    As a result of comments and re-examination of our desired policies, 
we have decided not to finalize this provision. However, as pointed out 
in the proposed rule, had this provision been finalized, it would 
impose minimal additional costs on plans. Consequently, not finalizing 
this policy does not impact this RIA.
5. Non-Mandatory Effects and Regulatory Interaction
    We note in this RIA when we had difficulty quantifying costs due to 
lack of applicable research or data. More specifically, the 
establishment of a health care information ecosystem could only be 
achieved with new actions that are conducted widely throughout the 
health care field--including by entities, especially non-hospital 
providers, for whom costs have not been estimated in either this RIA or 
the RIA for the accompanying ONC 21st Century Cures Act final rule 
(published elsewhere in this issue of the Federal Register). Although 
data limitations have prevented the quantification of these costs, the 
benefits of the two rules--some of which have been quantified in the 
ONC RIA--and the rules' potential transfer impacts--including 
reductions in fraudulent payments, as discussed by Parente et al. 
(2008) \88\--are largely contingent upon such costs being incurred. 
Additionally, there are ongoing regulatory and policy activities 
outside of this final rule that might influence the rule's impact in an 
unquantifiable manner. When possible, we acknowledge these complexities 
as well.
---------------------------------------------------------------------------

    \88\ Parente, Stephen T., Karen Mandelbaum, Susan P. Hanson, 
Bonnie S. Cassidy and Donald W. Simborg. ``Crime and Punishment: Can 
the NHIN Reduce the Cost of Healthcare Fraud?'' Journal of 
Healthcare Information Management 22(3): 42-51. June 2008.
---------------------------------------------------------------------------

D. Alternatives Considered

    In March 2018, the White House Office of American Innovation and 
the CMS Administrator announced the launch of MyHealthEData, and CMS's 
direct, hands-on role in improving patient access and advancing 
interoperability. As part of the MyHealthEData initiative, we are 
taking a patient-centered approach to health information access and 
moving to a system in which patients have immediate access to their 
electronic health information and can be assured that their health 
information will follow them as they move throughout the health care 
system from provider to provider, payer to payer. This final rule 
contains a range of policies. It provides descriptions of the statutory 
provisions that are addressed, identifies the policies, and presents 
rationales for our decisions and, where relevant, alternatives that 
were considered. We carefully considered alternatives to the policies 
we are adopting in this final rule but concluded that none of the

[[Page 25627]]

alternatives would adequately and immediately begin to address the 
critical issues of the lack of patient access and interoperability, or 
the difficulty exchanging health care data within the health care 
system.
    As we noted in the CMS Interoperability and Patient Access proposed 
rule, we believe the following three attributes of standards-based APIs 
are particularly important to achieving the goal of offering 
individuals convenient access, through applications they choose, to 
available and relevant electronic health and health-related 
information: the API technologies themselves, not just the data 
accessible through them, are standardized; the APIs are technically 
transparent; and the APIs are implemented in a pro-competitive manner 
(84 FR 7620). The API requirements proposed and finalized in this rule 
were developed to ensure these goals are met.
    Some of the reasons that we selected the FHIR standard were due to 
the flexibility it provides and the wide industry adoption that it 
offers. The open and extensible nature of FHIR allows for health care 
integration to be transparent and accessible. FHIR is open source, and 
as such, it has garnered a community that includes developers and 
vendors. For example, large consumer brands are becoming a driving 
force behind the adoption of FHIR. Apple is implementing FHIR in Apple 
Health as part of iOS 11.3, and serves as a member of the Argonaut 
Project and CARIN Alliance--two HL7 FHIR Accelerators; \89\ Google 
supports FHIR by partnering with HL7, as well as through its membership 
in the CARIN Alliance; and Microsoft published an Azure API for FHIR to 
create and deploy FHIR service health data solutions.\90\ Furthermore, 
according to an ONC report, nearly 51 percent of health IT developers 
appear to be using a version of FHIR combined with OAuth 2.0 to respond 
to requests for patient data. Additionally, of the hospitals and Merit-
based Incentive Payment System (MIPS) eligible clinicians that use 
certified products, almost 87 percent of hospitals and 69 percent of 
MIPS eligible clinicians are served by health IT developers with 
product(s) certified to any FHIR version.\91\
---------------------------------------------------------------------------

    \89\ The HL7 FHIR Accelerator Program is designed to assist 
communities and collaborative groups across the global health care 
spectrum in the creation and adoption of high quality FHIR 
Implementation Guides or other standard artifacts to move toward the 
realization of global health data interoperability. For further 
details, see https://www.hl7.org/about/fhir-accelerator/.
    \90\ Shrestha, R., Mohan, S., & Grieve, G. (2018, February 14). 
State of the Healthcare API Economy (An Innovation Forum Session: 
Session 217). Retrieved from https://365.himss.org/sites/himss365/files/365/handouts/552739129/handout-219_FINAL.pdf. See also https://azure.microsoft.com/en-us/services/azure-api-for-fhir/ and https://www.apple.com/healthcare/health-records/.
    \91\ Posnack, S. & Baker, W. (2018, October 1). Heat Wave: The 
U.S. is Poised to Catch FHIR in 2019. Retrieved from https://www.healthit.gov/buzz-blog/interoperability/heat-wave-the-u-s-is-poised-to-catch-fhir-in-2019.
---------------------------------------------------------------------------

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

    \92\ Patel, V. & Johnson, C. (2018, April). Individuals' Use of 
Online Medical Records and Technology for Health Needs (ONC Data 
Brief No. 40). Retrieved from https://www.healthit.gov/sites/default/files/page/2018-03/HINTS-2017-Consumer-Data-Brief-3.21.18.pdf.
---------------------------------------------------------------------------

    Other alternatives that we considered were how broadly or narrowly 
to apply the policies and requirements. For example, we could have 
required health plans to provide more data elements via a standards-
based API then just data for adjudicated claims, encounters with 
capitated providers, provider remittances, beneficiary cost-sharing, 
clinical data including laboratory results, provider directories (and 
pharmacy directories for MA-PDs), and preferred drug lists, where 
applicable. In the CMS Interoperability proposed rule, we originally 
required MA organizations, state Medicaid FFS programs, Medicaid 
managed care plans, CHIP FFS programs, and CHIP managed care entities 
to make available provider directory data through the Patient Access 
API (84 FR 7633) and publicly available to current and prospective 
enrollees (84 FR 7639). After consideration of public comments, we have 
removed the requirements that these impacted payers make provider 
directory information available through the Patient Access API. MA 
organizations, state Medicaid FFS programs, Medicaid managed care 
plans, CHIP FFS programs, and CHIP managed care entities will only need 
to make provider directory information available via a publicly 
accessible Provider Directory API. We note the Provider Directory API 
does not need to conform to the security protocols finalized by HHS at 
45 CFR 170.215(a)(3) and (b) that are specific to authenticating users 
and confirming individuals' authorization or request to disclose their 
personal information to a specific application through an API, namely 
the SMART IG (using the OAuth 2.0 standard) and OpenID Connect Core 
1.0. By only requiring the Provider Directory API make these otherwise 
publicly accessible data available, we are seeking to avoid duplicative 
effort and additional burden.
    Additionally, several commenters suggested additional information 
be added to the requirement for provider directory information to be 
available through an API, such as NPIs for individual and group 
providers, practice group name, health system name, as well as the 
specific plan(s) and tiers a provider participates in ``provider 
demographics;'' whether the provider is accepting new patients; and 
information about which providers are in-network for a plan by 
geography and/or specialty. While we agreed with commenters that this 
information would be helpful to patients, we did not modify the 
proposed requirements for the information that is required to be made 
available by the Provider Directory API because we believe additional 
data would be a cost driver. By not adding additional required

[[Page 25628]]

information we are seeking to minimize the burden for the regulated 
payers that must comply with this policy. Instead we are identifying a 
minimum set of provider directory information that aligns with existing 
requirements applicable to MA organizations (including MA organizations 
that offer MA-PD plans), state Medicaid and CHIP FFS programs, Medicaid 
managed care plans, and CHIP managed care entities that beneficiaries 
can currently access.
    We also looked at policy alternatives related to specific aspects 
of the API requirements. For instance, we considered whether to modify 
the requirement to make claims and encounter data, as well as clinical 
data, available through the Patient Access API no later than one (1) 
business day after a payer receives it. We reviewed several suggested 
alternatives such as increasing the timeframe to three (3) or five (5) 
business days to account for vendor-adjudicated claims. While we 
considered these alternatives, we ultimately decided not to adjust the 
proposed requirements because having access to this information within 
one (1) business day could empower patients to have the information 
they need, when they need it to inform care coordination. Patients have 
a right to see the full lifecycle of their claims and encounter 
information as soon as it is available, even if the payment amounts may 
change due to appeal. Additionally, as we noted in section XII. of this 
final rule, the burden related to API requirements is in the initial 
implementation of the system to make this information available in one 
(1) business day once received. This requirement is being implemented 
in the design and build phase and the system update cost for electronic 
availability would be the same regardless of the number of days the 
system is set up to accommodate. There is also no data on whether 
providing three (3) or five (5) days, versus one (1) day, will provide 
patients with more complete or accurate data.
    As an alternative, we considered requiring all QHP issuers on all 
Exchanges to meet the new API requirements as part of QHP 
certification. Consistent with some other QHP certification 
requirements, we opted not to require SBEs to include this as part of 
their certification requirements, but we strongly urge them to do so to 
ensure equitable treatment of issuers nationally and to allow consumers 
to access their health information through a third-party application no 
matter where they are insured across the country. States are the most 
knowledgeable about their consumers and insurance markets and are 
responsible for issuer compliance activities. While we believe that 
these API requirements have the potential to provide great benefit to 
consumers, complying with them will be mainly operational and SBE 
states would be required to assess QHP issuer compliance. Therefore, we 
believe that SBE states should be given the flexibility to determine 
whether or not these requirements are required of their QHP issuers.
    An additional alternative that we considered was based off one 
commenter's suggestion to incentivize plans who meet the required 
implementation dates through higher Healthcare Effectiveness Data and 
Information Set (HEDIS) scores. Although the commenter was not clear 
regarding a specific recommendation as to how to implement changes to 
the HEDIS score, we evaluated options such as adding a new measure 
specific to data exchange using HL7 FHIR-based APIs between payers and 
third-parties on the behalf of patients, or adding bonus points to the 
total score or some appropriate measure set for implementing the FHIR-
based APIs required. However, after further evaluation, we believe that 
this is not a viable alternative at this time. CMS cannot give a higher 
HEDIS score for using a digital specification because it would not be 
an accurate measure of plan performance. To consider adding a bonus to 
the highest rating if the plan meets certain standards would 
necessitate requiring a new adjustment to the star rating methodology. 
This would be a significant change to how the current star ratings are 
calculated and would have to be proposed through notice and comment 
rulemaking. Given the implementation date for the API provisions for MA 
organizations, Medicaid FFS programs, Medicaid managed care plans, CHIP 
FFS programs, and CHIP managed care entities is January 1, 2021, and 
for QHP issuers on the FFEs beginning with plan years beginning on or 
after January 1, 2021, implementing changes to the star ratings would 
not be achievable within the available timeframe to incentivize 
implementation as the commenter suggested.
    As we recognize that advancing interoperability is no small or 
simple matter, we continue to explore alternatives and potential future 
policies. In the CMS Interoperability and Patient Access proposed rule, 
we requested comment for consideration in future rulemaking or 
subregulatory guidance on a number of alternatives related to whether 
additional policies or requirements, beyond those proposed, should be 
imposed to promote interoperability. For example, the CMS Innovation 
Center sought comment on general principles around promoting 
interoperability as part of the design and testing of innovative 
payment and service delivery models. Additionally, we sought comment on 
how we may leverage our program authority to provide support to those 
working on improving patient matching. For example, we requested 
comment on whether CMS should require impacted payers use a particular 
patient matching software solution with a proven success rate of a 
certain percentage validated by HHS or a third party. We also noted 
that we will continue to consider feedback received from RFIs issued in 
various rules over the course of the past 2 years and incorporate those 
suggestions into our strategy. We thank commenters for their input on 
these RFIs. We will consider the comments received for potential future 
rulemaking.

E. Accounting Statement and Table

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

[[Page 25629]]



                                         Table 14--Accounting Statement
----------------------------------------------------------------------------------------------------------------
                                                                                       Units
                                                      Primary    -----------------------------------------------
                    Category                         estimate                      Discount rate      Period
                                                                   Year dollars      (percent)        covered
----------------------------------------------------------------------------------------------------------------
                                                    Benefits
----------------------------------------------------------------------------------------------------------------
Qualitative.....................................      API requirements will alleviative the burden for
                                                   patients to go through separate processes to obtain access to
                                                    each system, and the need to manually aggregate information
                                                   that is delivered in various, often non-standardized, formats
                                                    (not necessarily additional to the benefits assessed in the
                                                     RIA for the accompanying ONC 21st Century Cures Act final
                                                      rule, (published elsewhere in this issue of the Federal
                                                                            Register)).
                                                     API requirement allows for the administration of a
                                                      more efficient and effective Medicaid program by taking
                                                   advantage of commonly used methods of information sharing and
                                                                       data standardization.
                                                    API requirements would help to create a health care
                                                    information ecosystem that allows and encourages the health
                                                    care market to tailor products and services to compete for
                                                      patients, thereby increasing quality, decreasing costs,
                                                    providing potential benefits (not necessarily additional to
                                                     the benefits assessed in the RIA for the accompanying ONC
                                                    final rule), and helping them live better, healthier lives.
                                                    Privacy and security policies are being implemented
                                                    that permit payers to request third-party apps to attest to
                                                    privacy and security provisions prior to providing the app
                                                                    access to the payer's API.
----------------------------------------------------------------------------------------------------------------
                                                      Costs
----------------------------------------------------------------------------------------------------------------
Annualized Monetized $ millions/year (low                   85.2            2019               7       2020-2029
 estimate)......................................            80.8            2019               3       2020-2029
Annualized Monetized $ millions/year (primary              122.0            2019               7       2020-2029
 estimate)......................................           112.4            2019               3       2020-2029
Annualized Monetized $ millions/year (high                 158.8            2019               7       2020-2029
 estimate)......................................           144.0            2019               3       2020-2029
----------------------------------------------------------------------------------------------------------------
Non-Quantified Costs: Non-hospital provider costs associated with development of a broad health care information
 ecosystem (regulatory benefits and fraud reduction are largely contingent upon these non-mandatory costs being
 incurred).
----------------------------------------------------------------------------------------------------------------
                  Transfers from the Federal Government to Enrollees of Commercial Plans (PTC)
----------------------------------------------------------------------------------------------------------------
Annualized Monetized $ millions.................             5.4            2019               7       2020-2029
Annualized Monetized $ millions.................             5.5            2018               3       2020-2029
----------------------------------------------------------------------------------------------------------------
Non-Quantified Transfers: Reduced fraudulent payments to providers from the federal government and other payers.
----------------------------------------------------------------------------------------------------------------

    The preceding discussion was an actual cost impact (not a transfer) 
since goods and computer services are being paid for. Plans have the 
option of transferring their expenses to enrollees. In practice, 
because of market competitive forces a plan may decide to operate at a 
(partial) loss and not transfer the entire cost. It is important to 
estimate the maximum the transfer could be. Some costs are transferred 
to the states (for Medicaid and CHIP) and ultimately to the federal 
government (for Medicare, Medicaid, and CHIP, and potentially for QHP 
issuers on the FFEs in the form of higher PTCs)), mitigating the amount 
transferred to enrollees. One approach to estimate impact on enrollees 
was made in section XII.B. of this RIA. However, this analysis did not 
take into account transfers.
    We now re-estimate the potential full transfer. As noted in Tables 
5 through 10, we have in 2021 through 2029 under a dollar increase in 
premiums as the worst-case scenario, and we used actual costs per year. 
In this alternate analysis, we use actual amounts for each of 2021 
through 2029 with the initial 1-year cost amortized over 9 years. In 
other words, we assume an aggregate annual cost of $84.6 million ($272 
million/9 + $54.4 million), this is based on the low estimate 1st year 
cost of $272 million. If we use the high estimate cost $816 million we 
obtain $145 million average ($816 million/9 + $54.4 million).
    We note that this premium increase could be counterbalanced by 
projected savings arising from the provisions in this final rule. More 
specifically, we expect the availability of portable electronic 
transfer of medical data proposed by this rule will help patients have 
the ability to move from payer to payer, provider to provider, and have 
both their clinical and administrative information travel with them 
throughout their health care journey. Allowing patients to piece 
together their own information that might otherwise be lost in 
disparate systems could help make better informed patients and may lead 
to increase prevention of future medical illnesses due to improvements 
in care coordination due to better data accessibility. The savings from 
avoiding one illness or one cheaper procedure would offset the under 
one-dollar impact. However, we have no way, at this point, of 
estimating this aspect of the future savings of the rule.

[[Page 25630]]

    We present two estimates. First, we estimate using the enrollment 
figures used in Table 9 of this RIA. Table 9 shows that we have 110.5 
million enrollees (17.5+73+20) in programs that will be spending about 
$84.6 million per year. Ignoring federal subsidies, and assuming that 
all costs will be passed on to enrollees (which is contrary to our 
experience), the 110.5 million enrollees would each incur an extra 77 
cents per enrollee ($84.6 million/110.5 million) a year to achieve the 
$84.6 million goal. This is the low estimate cost. The corresponding 
high estimate cost would be $1.31 per enrollee per year ($145 million/
110.5 million). We next estimate using premium versus enrollment as was 
done in section XII.B. of this RIA.
    Prior to discussing potential transfers to enrollees, we discuss 
how this final rule may affect patients not covered by plans subject to 
this rule. It is both possible and likely that an organization offering 
a plan subject to this rule may also offer plans not subject to this 
rule, and comply with the requirements of this rule for all of its 
plans, including those not subject to this rule. Consequently, it is 
possible that to cover the cost of complying with this rule for plans 
that are subject to this rule and plans that are not subject to this 
rule, organizations may raise premiums for their plans that are subject 
to this rule and their plans that are not subject to this rule. It is 
possible (and we contend likely) that this final rule will affect 
enrollees in individual market plans other than QHPs on the FFEs, even 
though there is no requirement for such coverage to comply with this 
rule. Therefore, we calculate the cost impact per enrollee should 
organizations offering plans not subject to this rule choose to comply 
with this rule with regard to those plans. The rest of the discussion 
below explores this possibility.
    QHP issuers on the FFEs: Rebates are required under section 
2718(b)(1)(A) of the PHSA and the implementing regulations at 45 CFR 
part 158 when an issuer does not meet the applicable threshold. The 
commercial market MLR is generally calculated as the percent of each 
dollar of after-tax premium revenue spent by the issuer on 
reimbursement for clinical services, and activities that improve the 
quality of health care. If the issuer's MLR for a state market is below 
the applicable threshold, then the issuer must return the difference to 
policyholders. It follows, that if costs of complying with this rule 
raise plan costs, and if additionally, the issuers pass on the full 
cost in the form of premium and/or are able to treat these costs as 
QIAs, then premiums and rebates will change. The following two highly 
simplified examples are illustrative.
    Suppose the MLR threshold is 80 percent (in practice it can vary by 
state market), but the issuer's MLR is below the threshold at 70 
percent. Then, the issuer would have to return the 10 percent as a 
rebate. If the costs of complying with this rule for an issuer are on 
average 6 percent of premium and the issuer treats these expenses as 
QIA, the issuer will now have to rebate only 4 percent instead of 10 
percent (that is, the issuer's MLR would be 76 percent rather than 70 
percent). Similarly, if both the applicable threshold and issuer MLR 
are 80 percent, then the issuer would not owe a rebate.
    There are two effects of recognizing these costs as QIA: (1) For 
issuers subject to this rule who are below the applicable MLR 
threshold, the rebate from issuers to policyholders would go down by 
some amount between $0 and the cost of complying with this rule; and 
(2) for issuers subject to this rule who are at or above the MLR 
standards, the premium transfers from enrollees to issuers will go up 
by some amount between $0 and the cost of complying with this rule. We 
note that both MLR and rebates are calculated by combining all of an 
issuer's business (on- and off-Exchange) within a state and market.
    To estimate these amounts, we used the public use 2016 MLR files on 
the CMS website that were used for Tables 6 through 9 of this RIA. The 
total reported 2016 premium revenue on the commercial side for 
individual market plans was approximately $77 billion (See Table 7). Of 
the $77 billion, the total reported 2016 premium revenue of issuers 
that were below the commercial MLR standard (80 or 85 percent, 
depending on the market) was approximately $4 billion.
    As mentioned earlier, to proceed further we use the estimates of 
the costs of complying with this rule, which are $84.6 million per 
year. This cost is for all parent organizations with each parent 
organization possibly dealing with up to four lines of business subject 
to MLR requirements and the requirements of this rule: MA (including 
Part D sponsors); Medicaid; CHIP; and QHP issuers on the FFEs. Thus, of 
the $84.6 million level annual cost of complying with this rule, we 
estimate $18.8 million (22.19 percent commercial proportion * $84.6 
million level annual cost complying with this rule) to be the cost for 
individual market plans.
    In estimating the transfers to policyholders in individual market 
plans, we must distinguish between the $4 billion of premium revenues 
of issuers whose MLR was below the applicable threshold and the $73 
billion of premium revenues ($77 billion total revenue for individual 
market plans- $4 billion) of individual market issuers whose MLR was at 
or above the applicable threshold. We can now calculate the estimated 
aggregate transfer in the commercial health insurance market from 
individual market policyholders to issuers whether through premium or 
rebates as follows:
     Percentage cost of complying with this rule = 0.0244 
percent of revenue premium ($18.8 million cost/$77 billion total 
revenue).
     Reduced MLR rebates = $1 million (0.0244 percent x $4 
billion premium from issuers below the applicable MLR threshold).
     Increased premiums = Up to $17.8 million (0.0244 percent x 
($77 billion total revenue-$4 billion premium from issuers below the 
applicable MLR threshold)).
     Total transfer from enrollees = Up to $418.8 million 
($17.8 million increased premium + $1 million reduced rebate).
     Transfer per enrollee = $1.07 ($418.8 million/17.5 million 
commercial health insurance enrollees).
    We note that the $1.07 (under a dollar per enrollee) is consistent 
with the results obtained in Tables 6 through 10 (with exact raw 
amounts by year without amortization of a large first year expense). 
These calculations are summarized in Table 15. The $1.07 is the low 
estimate of first year costs. The high estimate $1.85 per enrollee per 
year is obtained by replacing the low estimate cost of $272 million 
with $816 million.

                          Table 15--Transfers to Enrollee Resulting From the Final Rule
----------------------------------------------------------------------------------------------------------------
         Label                      Item                Amount             Source                Comments
----------------------------------------------------------------------------------------------------------------
(A)....................  First year cost of                  272.0  Estimated in this     In millions.
                          interoperability (Low                      proposed rule.
                          estimate).

[[Page 25631]]

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

F. Regulatory Reform Analysis Under E.O. 13771

    Executive Order 13771, titled Reducing Regulation and Controlling 
Regulatory Costs, was issued on January 30, 2017 and requires that the 
costs associated with significant new regulations ``shall, to the 
extent permitted by law, be offset by the elimination of existing costs 
associated with at least two prior regulations.'' This final rule is 
considered an E.O. 13771 regulatory action. We estimate that this rule 
generates $77.8 million in annualized costs, discounted at 7 percent 
relative to year 2016, over an infinite time horizon estimate. Details 
on the estimated costs of this final rule can be found in the preceding 
analysis.

G. Conclusion

    The analysis above, together with the preceding preamble, provides 
an RIA.
    In accordance with the provisions of Executive Order 12866, this 
regulation was reviewed by the Office of Management and Budget.

List of Subjects

42 CFR Part 406

    Health facilities, Diseases, Medicare.

42 CFR Part 407

    Medicare.

42 CFR Part 422

    Administrative practice and procedure, Health facilities, Health 
maintenance organizations (HMO), Medicare, Penalties, Privacy, 
Reporting and recordkeeping requirements.

42 CFR Part 423

    Administrative practice and procedure, Emergency medical services, 
Health facilities, Health maintenance organizations (HMO), Medicare, 
Penalties, Privacy, Reporting and recordkeeping requirements.

[[Page 25632]]

42 CFR Part 431

    Grant programs--health, Health facilities, Medicaid, Privacy, 
Reporting and recordkeeping requirements.

42 CFR Part 438

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

42 CFR Part 457

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

42 CFR Part 482

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

42 CFR Part 485

    Grant programs--health, Health facilities, Medicaid, Privacy, 
Reporting and recordkeeping requirements.

45 CFR Part 156

    Administrative practice and procedure, Advertising, Advisory 
committees, Brokers, Conflict of interests, Consumer protection, Grant 
programs--health, Grants administration, Health care, Health insurance, 
Health maintenance organization (HMO), Health records, Hospitals, 
Indians, Individuals with disabilities, Loan programs--health, 
Medicaid, Organization and functions (Government agencies), Public 
assistance programs, Reporting and recordkeeping requirements, State 
and local governments, Sunshine Act, Technical assistance, Women, 
Youth.

    For the reasons set forth in the preamble, the Centers for Medicare 
& Medicaid Services (CMS) amends 42 CFR chapter IV and the Office of 
the Secretary (HHS) amends 45 CFR subtitle A, subchapter B, as set 
forth below:

TITLE 42--PUBLIC HEALTH

CHAPTER IV--CENTERS FOR MEDICARE & MEDICAID SERVICES, DEPARTMENT OF 
HEALTH AND HUMAN SERVICES

PART 406--HOSPITAL INSURANCE ELIGIBLIITY AND ENTITLEMENT

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

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


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


Sec.  406.26  Enrollment under State buy-in.

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

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

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

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


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


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

* * * * *
    (c) * * *
    (4) Any State that has a buy-in agreement in effect must 
participate in daily exchanges of enrollment data with CMS.

PART 422--MEDICARE ADVANTAGE PROGRAM

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

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


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


Sec.  422.119  Access to and exchange of health data and plan 
information.

    (a) Application Programming Interface to support MA enrollees. A 
Medicare Advantage (MA) organization must implement and maintain a 
standards-based Application Programming Interface (API) that permits 
third-party applications to retrieve, with the approval and at the 
direction of a current individual MA enrollee or the enrollee's 
personal representative, data specified in paragraph (b) of this 
section through the use of common technologies and without special 
effort from the enrollee.
    (b) Accessible content. (1) An MA organization must make the 
following information accessible to its current enrollees or the 
enrollee's personal representative through the API described in 
paragraph (a) of this section:
    (i) Data concerning adjudicated claims, including claims data for 
payment decisions that may be appealed, were appealed, or are in the 
process of appeal, and provider remittances and enrollee cost-sharing 
pertaining to such claims, no later than one (1) business day after a 
claim is processed;
    (ii) Encounter data from capitated providers, no later than one (1) 
business day after data concerning the encounter is received by the MA 
organization; and
    (iii) Clinical data, including laboratory results, if the MA 
organization maintains any such data, no later than one (1) business 
day after the data is received by the MA organization.
    (2) In addition to the information specified in paragraph (b)(1) of 
this section, an MA organization that offers an MA-PD plan must make 
the following information accessible to its enrollees through the API 
described in paragraph (a) of this section:
    (i) Data concerning adjudicated claims for covered Part D drugs, 
including remittances and enrollee cost-sharing, no later than one (1) 
business day after a claim is adjudicated; and,
    (ii) Formulary data that includes covered Part D drugs, and any 
tiered formulary structure or utilization management procedure which 
pertains to those drugs.
    (c) Technical requirements. An MA organization implementing an API 
under paragraph (a) of this section:
    (1) Must implement, maintain, and use API technology conformant 
with 45 CFR 170.215;
    (2) Must conduct routine testing and monitoring, and update as 
appropriate, to ensure the API functions properly, including 
assessments to verify that the API is fully and successfully 
implementing privacy and security features such as, but not limited to, 
those required to comply with HIPAA privacy and security requirements 
in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable 
law protecting the privacy and security of individually identifiable 
data;
    (3) Must comply with the content and vocabulary standard 
requirements in paragraphs (c)(3)(i) and (ii) of this section, as 
applicable to the data type or data element, unless alternate standards 
are required by other applicable law:
    (i) Content and vocabulary standards at 45 CFR 170.213 where such 
standards are applicable to the data type or element, as appropriate; 
and
    (ii) Content and vocabulary standards at 45 CFR part 162 and Sec.  
423.160 of this chapter where required by law or where such standards 
are applicable to the data type or element, as appropriate.
    (4) May use an updated version of any standard or all standards 
required under paragraph (c)(1) or (3) of this section, where:
    (i) Use of the updated version of the standard is required by other 
applicable law; or

[[Page 25633]]

    (ii) Use of the updated version of the standard is not prohibited 
under other applicable law, provided that:
    (A) For content and vocabulary standards other than those at 45 CFR 
170.213, the Secretary has not prohibited use of the updated version of 
a standard for purposes of this section or 45 CFR part 170;
    (B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the 
National Coordinator has approved the updated version for use in the 
ONC Health IT Certification Program; and
    (C) Use of the updated version of a standard does not disrupt an 
end user's ability to access the data described in paragraph (b) of 
this section through the API described in paragraph (a) of this 
section.
    (d) Documentation requirements for APIs. For each API implemented 
in accordance with paragraph (a) of this section, an MA organization 
must make publicly accessible, by posting directly on its website or 
via publicly accessible hyperlink(s), complete accompanying 
documentation that contains, at a minimum the information listed in 
this paragraph. For the purposes of this section, ``publicly 
accessible'' means that any person using commonly available technology 
to browse the internet could access the information without any 
preconditions or additional steps, such as a fee for access to the 
documentation; a requirement to receive a copy of the material via 
email; a requirement to register or create an account to receive the 
documentation; or a requirement to read promotional material or agree 
to receive future communications from the organization making the 
documentation available;
    (1) API syntax, function names, required and optional parameters 
supported and their data types, return variables and their types/
structures, exceptions and exception handling methods and their 
returns;
    (2) The software components and configurations an application must 
use in order to successfully interact with the API and process its 
response(s); and
    (3) All applicable technical requirements and attributes necessary 
for an application to be registered with any authorization server(s) 
deployed in conjunction with the API.
    (e) Denial or discontinuation of access to the API. An MA 
organization may deny or discontinue any third party application's 
connection to the API required under paragraph (a) of this section if 
the MA organization:
    (1) Reasonably determines, consistent with its security risk 
analysis under 45 CFR part 164 subpart C, that allowing an application 
to connect or remain connected to the API would present an unacceptable 
level of risk to the security of protected health information on the MA 
organization's systems; and
    (2) Makes this determination using objective, verifiable criteria 
that are applied fairly and consistently across all applications and 
developers through which enrollees seek to access their electronic 
health information, as defined at 45 CFR 171.102, including but not 
limited to criteria that may rely on automated monitoring and risk 
mitigation tools.
    (f) Coordination among payers. (1) An MA organization must maintain 
a process for the electronic exchange of, at a minimum, the data 
classes and elements included in the content standard adopted at 45 CFR 
170.213. Such information received by an MA organization must be 
incorporated into the MA organization's records about the current 
enrollee. With the approval and at the direction of a current or former 
enrollee or the enrollee's personal representative, the MA organization 
must:
    (i) Receive all such data for a current enrollee from any other 
payer that has provided coverage to the enrollee within the preceding 5 
years;
    (ii) At any time an enrollee is currently enrolled in the MA plan 
and up to 5 years after disenrollment, send all such data to any other 
payer that currently covers the enrollee or a payer the enrollee or the 
enrollee's personal representative specifically requests receive the 
data; and
    (iii) Send data received from another payer under this paragraph 
(f) in the electronic form and format it was received.
    (2) [Reserved]
    (g) Enrollee resources regarding privacy and security. An MA 
organization must provide in an easily accessible location on its 
public website and through other appropriate mechanisms through which 
it ordinarily communicates with current and former enrollees seeking to 
access their health information held by the MA organization, 
educational resources in non-technical, simple and easy-to-understand 
language explaining at a minimum:
    (1) General information on steps the individual may consider taking 
to help protect the privacy and security of their health information 
including factors to consider in selecting an application including 
secondary uses of data, and the importance of understanding the 
security and privacy practices of any application to which they will 
entrust their health information; and
    (2) An overview of which types of organizations or individuals are 
and are not likely to be HIPAA covered entities, the oversight 
responsibilities of the Office for Civil Rights (OCR) and the Federal 
Trade Commission (FTC), and how to submit a complaint to:
    (i) The HHS Office for Civil Rights (OCR); and
    (ii) The Federal Trade Commission (FTC).
    (h) Applicability. (1) An MA organization must comply with the 
requirements in paragraphs (a) through (e) and (g) of this section 
beginning January 1, 2021, and with the requirements in paragraph (f) 
beginning January 1, 2022 with regard to data:
    (i) With a date of service on or after January 1, 2016; and
    (ii) That are maintained by the MA organization.
    (2) [Reserved]

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


Sec.  422.120  Access to published provider directory information.

    (a) An MA organization must implement and maintain a publicly 
accessible, standards-based Application Programming Interface (API) 
that is conformant with the technical requirements at Sec.  422.119(c), 
excluding the security protocols related to user authentication and 
authorization and any other protocols that restrict the availability of 
this information to particular persons or organizations, the 
documentation requirements at Sec.  422.119(d), and is accessible via a 
public-facing digital endpoint on the MA organization's website.
    (b) The API must provide a complete and accurate directory of--
    (1) The MA plan's network of contracted providers, including names, 
addresses, phone numbers, and specialties, updated no later than 30 
calendar days after the MA organizations receives provider directory 
information or updates to provider directory information; and
    (2) For an MA organization that offers an MA-PD plan, the MA-PD's 
pharmacy directory, including the pharmacy name, address, phone number, 
number of pharmacies in the network, and mix (specifically the type of 
pharmacy, such as ``retail pharmacy'') updated no later than 30 
calendar days after the MA organization receives pharmacy directory 
information or updates to pharmacy directory information.
    (c) This section is applicable beginning January 1, 2021.

[[Page 25634]]


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


Sec.  422.504  Contract provisions.

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

PART 423--VOLUNTARY MEDICARE PERSCRIPTION DRUG BENEFIT

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

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


0
10. Section 423.910 is amended--
0
a. In paragraph (b)(1) introductory text by removing the phrase 
``monthly reporting requirement for the monthly enrollment reporting'' 
and adding in its place the phrase ``state enrollment reporting 
requirement described in paragraph (d) of this section'';
0
b. In paragraph (d) by revising the paragraph heading and by 
redesignating the text of paragraph (d) introductory text as paragraph 
(d)(1).
0
c. In newly redesignated paragraph (d)(1), by removing the phrase 
``Effective June 2005, and each subsequent month, States must submit an 
electronic file, in a manner specified by CMS'' and by adding the 
following phrase ``States must submit an electronic file as specified 
in paragraph (d)(2) of this section,''; and
0
d. By adding paragraph (d)(2).
    The revision and addition read as follows:


Sec.  423.910  Requirements.

* * * * *
    (d) * * *
    (2)(i) For the period prior to April 1, 2022, States must submit 
the file at least monthly and may submit updates to that file on a more 
frequent basis.
    (ii) For the period beginning April 1, 2022, States must submit the 
file at least monthly and must submit updates to that file on a daily 
basis.
* * * * *

PART 431--STATE ORGANIZATION AND GENERAL ADMINISTRATION

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

    Authority:  42 U.S.C. 1302.


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


Sec.  431.60  Beneficiary access to and exchange of data.

    (a) Application Programming Interface to support Medicaid 
beneficiaries. A State must implement and maintain a standards-based 
Application Programming Interface (API) that permits third-party 
applications to retrieve, with the approval and at the direction of a 
current beneficiary or the beneficiary's personal representative, data 
specified in paragraph (b) of this section through the use of common 
technologies and without special effort from the beneficiary.
    (b) Accessible content. A State must make the following information 
accessible to its current beneficiaries or the beneficiary's personal 
representative through the API described in paragraph (a) of this 
section:
    (1) Data concerning adjudicated claims, including claims data for 
payment decisions that may be appealed, were appealed, or are in the 
process of appeal, and provider remittances and beneficiary cost-
sharing pertaining to such claims, no later than one (1) business day 
after a claim is processed;
    (2) Encounter data no later than one (1) business day after 
receiving the data from providers, other than MCOs, PIHPs, and PAHPs, 
compensated on the basis of capitation payments;
    (3) Clinical data, including laboratory results, if the State 
maintains any such data, no later than one (1) business day after the 
data is received by the State; and
    (4) Information about covered outpatient drugs and updates to such 
information, including, where applicable, preferred drug list 
information, no later than one (1) business day after the effective 
date of any such information or updates to such information.
    (c) Technical requirements. A State implementing an API under 
paragraph (a) of this section:
    (1) Must implement, maintain, and use API technology conformant 
with 45 CFR 170.215;
    (2) Must conduct routine testing and monitoring, and update as 
appropriate, to ensure the API functions properly, including 
assessments to verify that the API is fully and successfully 
implementing privacy and security features such as, but not limited to, 
those required to comply with HIPAA privacy and security requirements 
in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable 
law protecting the privacy and security of individually identifiable 
data;
    (3) Must comply with the content and vocabulary standards 
requirements in paragraphs (c)(3)(i) and (ii) of this section, as 
applicable to the data type or data element, unless alternate standards 
are required by other applicable law:
    (i) Content and vocabulary standards at 45 CFR 170.213 where such 
standards are applicable to the data type or element, as appropriate; 
and
    (ii) Content and vocabulary standards at 45 CFR part 162 and Sec.  
423.160 of this chapter where required by law, or where such standards 
are applicable to the data type or element, as appropriate.
    (4) May use an updated version of any standard or all standards 
required under paragraph (c)(1) or (3) of this section, where:
    (i) Use of the updated version of the standard is required by other 
applicable law, or
    (ii) Use of the updated version of the standard is not prohibited 
under other applicable law, provided that:
    (A) For content and vocabulary standards other than those at 45 CFR 
170.213, the Secretary has not prohibited use of the updated version of 
a standard for purposes of this section or 45 CFR part 170;
    (B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the 
National Coordinator has approved the updated version for use in the 
ONC Health IT Certification Program; and
    (C) Use of the updated version of a standard does not disrupt an 
end user's ability to access the data described in paragraph (b) of 
this section through the API described in paragraph (a) of this 
section.
    (d) Documentation requirements for APIs. For each API implemented 
in accordance with paragraph (a) of this section, a State must make 
publicly accessible, by posting directly on its website or via publicly 
accessible hyperlink(s), complete accompanying documentation that 
contains, at a minimum the information listed in this paragraph. For 
the purposes of this section, ``publicly accessible'' means that any 
person using commonly available technology to browse the internet could 
access the information without any preconditions or additional steps, 
such as a fee for access to the documentation; a requirement to receive 
a copy of the material via email; a requirement to register or create 
an account to receive the documentation; or a requirement to read 
promotional material or agree to receive future communications from the 
organization making the documentation available;
    (1) API syntax, function names, required and optional parameters 
supported and their data types, return

[[Page 25635]]

variables and their types/structures, exceptions and exception handling 
methods and their returns;
    (2) The software components and configurations an application must 
use in order to successfully interact with the API and process its 
response(s); and
    (3) All applicable technical requirements and attributes necessary 
for an application to be registered with any authorization server(s) 
deployed in conjunction with the API.
    (e) Denial or discontinuation of access to the API. A State may 
deny or discontinue any third-party application's connection to the API 
required under paragraph (a) of this section if the State:
    (1) Reasonably determines, consistent with its security risk 
analysis under 45 CFR part 164 subpart C, that allowing an application 
to connect or remain connected to the API would present an unacceptable 
level of risk to the security of protected health information on the 
State's systems; and
    (2) Makes this determination using objective, verifiable criteria 
that are applied fairly and consistently across all applications and 
developers through which beneficiaries seek to access their electronic 
health information as defined at 45 CFR 171.102, including but not 
limited to criteria that may rely on automated monitoring and risk 
mitigation tools.
    (f) Beneficiary resources regarding privacy and security. The State 
must provide in an easily accessible location on its public website and 
through other appropriate mechanisms through which it ordinarily 
communicates with current and former beneficiaries seeking to access 
their health information held by the State Medicaid agency, educational 
resources in non-technical, simple and easy-to-understand language 
explaining at a minimum:
    (1) General information on steps the individual may consider taking 
to help protect the privacy and security of their health information, 
including factors to consider in selecting an application including 
secondary uses of data, and the importance of understanding the 
security and privacy practices of any application to which they will 
entrust their health information; and
    (2) An overview of which types of organizations or individuals are 
and are not likely to be HIPAA covered entities, the oversight 
responsibilities of the Office for Civil Rights (OCR) and the Federal 
Trade Commission (FTC), and how to submit a complaint to:
    (i) The HHS Office for Civil Rights (OCR); and
    (ii) The Federal Trade Commission (FTC).
    (g) Data availability. (1) The State must comply with the 
requirements in paragraph (a) through (f) of this section beginning 
January 1, 2021 with regard to data:
    (i) With a date of service on or after January 1, 2016; and
    (ii) That are maintained by the State.
    (2) [Reserved]

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


Sec.  431.70  Access to published provider directory information.

    (a) The State must implement and maintain a publicly accessible, 
standards-based Application Programming Interface (API) that is 
conformant with the technical requirements at Sec.  431.60(c), 
excluding the security protocols related to user authentication and 
authorization and any other protocols that restrict the availability of 
this information to particular persons or organizations, the 
documentation requirements at Sec.  431.60(d), and is accessible via a 
public-facing digital endpoint on the State's website.
    (b) The API must provide a complete and accurate directory of--
    (1) The State's provider directory information specified in section 
1902(a)(83) of the Act, updated no later than 30 calendar days after 
the State receives provider directory information or updates to 
provider directory information.
    (2) [Reserved]
    (c) This section is applicable beginning January 1, 2021.

PART 438--MANAGED CARE

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

    Authority:  42 U.S.C. 1302.


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


Sec.  438.62  Continued services to enrollees.

* * * * *
    (b) * * *
    (1) * * *
    (vi) A process for the electronic exchange of, at a minimum, the 
data classes and elements included in the content standard adopted at 
45 CFR 170.213. Such information received by the MCO, PIHP, or PAHP 
must be incorporated into the MCO's, PIHP's, or PAHP's records about 
the current enrollee. With the approval and at the direction of a 
current or former enrollee or the enrollee's personal representative, 
the MCO, PIHP, or PAHP must:
    (A) Receive all such data for a current enrollee from any other 
payer that has provided coverage to the enrollee within the preceding 5 
years;
    (B) At any time the enrollee is currently enrolled in the MCO, 
PIHP, or PAHP and up to 5 years after disenrollment, send all such data 
to any other payer that currently covers the enrollee or a payer the 
enrollee or the enrollee's personal representative specifically 
requests receive the data; and
    (C) Send data received from another payer under this paragraph in 
the electronic form and format it was received.
    (vii) Applicability.
    (A) The MCO, PIHP, or PAHP must comply with the requirements in 
paragraph (b)(1)(vi) of this section beginning January 1, 2022 with 
regard to data:
    (1) With a date of service on or after January 1, 2016; and
    (2) That are maintained by the MCO, PIHP, or PAHP.
    (B) [Reserved]
* * * * *

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


Sec.  438.242  Health information systems.

* * * * *
    (b) * * *
    (5) Implement an Application Programming Interface (API) as 
specified in Sec.  431.60 of this chapter as if such requirements 
applied directly to the MCO, PIHP, or PAHP and include--
    (i) All encounter data, including encounter data from any network 
providers the MCO, PIHP, or PAHP is compensating on the basis of 
capitation payments and adjudicated claims and encounter data from any 
subcontractors.
    (ii) [Reserved]
    (6) Implement, by January 1, 2021, and maintain a publicly 
accessible standards-based API described in Sec.  431.70, which must 
include all information specified in Sec.  438.10(h)(1) and (2) of this 
chapter.
* * * * *

PART 457--ALLOTMENTS AND GRANTS TO STATES

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

    Authority:  42 U.S.C. 1302.


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

[[Page 25636]]

Sec.  457.700   Basis, scope, and applicability.

    (a) * * *
    (1) Section 2101(a) of the Act, which sets forth that the purpose 
of title XXI is to provide funds to States to provide child health 
assistance to uninsured, low-income children in an effective and 
efficient manner that is coordinated with other sources of health 
benefits coverage;
* * * * *
    (c) Applicability. The requirements of this subpart apply to 
separate child health programs and Medicaid expansion programs, except 
that Sec.  457.730 does not apply to Medicaid expansion programs. 
Separate child health programs that provide benefits exclusively 
through managed care organizations may meet the requirements of Sec.  
457.730 by requiring the managed care organizations to meet the 
requirements of Sec.  457.1233(d)(2).

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


Sec.  457.730  Beneficiary access to and exchange of data.

    (a) Application Programming Interface to support CHIP 
beneficiaries. A State must implement and maintain a standards-based 
Application Programming Interface (API) that permits third-party 
applications to retrieve, with the approval and at the direction of the 
current individual beneficiary or the beneficiary's personal 
representative, data specified in paragraph (b) of this section through 
the use of common technologies and without special effort from the 
beneficiary.
    (b) Accessible content. A State must make the following information 
accessible to its current beneficiaries or the beneficiary's personal 
representative through the API described in paragraph (a) of this 
section:
    (1) Data concerning adjudicated claims, including claims data for 
payment decisions that may be appealed, were appealed, or are in the 
process of appeal, and provider remittances and beneficiary cost-
sharing pertaining to such claims, no later than one (1) business day 
after a claim is processed;
    (2) Encounter data no later than 1 business day after receiving the 
data from providers, other than MCOs, PIHPs, or PAHPs, compensated on 
the basis of capitation payments;
    (3) Clinical data, including laboratory results, if a State 
maintains any such data, no later than one (1) business day after the 
data is received by the State; and
    (4) Information, about covered outpatient drugs and updates to such 
information, including, where applicable, preferred drug list 
information, no later than one (1) business day after the effective 
date of the information or updates to such information.
    (c) Technical requirements. A State implementing an API under 
paragraph (a) of this section:
    (1) Must implement, maintain, and use API technology conformant 
with 45 CFR 170.215;
    (2) Must conduct routine testing and monitoring, and update as 
appropriate, to ensure the API functions properly, including 
assessments to verify that the API technology is fully and successfully 
implementing privacy and security features such as, but not limited to, 
those required to comply with HIPAA privacy and security requirements 
in 45 CFR parts 160 and 164, 42 CFR parts 2 and 3, and other applicable 
law protecting the privacy and security of individually identifiable 
data;
    (3) Must comply with the content and vocabulary standard 
requirements in paragraphs (c)(3)(i) and (ii) of this section, as 
applicable to the data type or data element, unless alternate standards 
are required by other applicable law:
    (i) Content and vocabulary standards at 45 CFR 170.213 where such 
standards are applicable to the data type or element, as appropriate; 
and
    (ii) Content and vocabulary standards at 45 CFR part 162 and Sec.  
423.160 of this chapter where required by law, or where such standards 
are applicable to the data type or element, as appropriate.
    (4) May use an updated version of any standard or all standards 
required under paragraphs (c)(1) or (3) of this section, where:
    (i) Use of the updated version of the standard is required by other 
applicable law, or
    (ii) Use of the updated version of the standard is not prohibited 
under other applicable law, provided that:
    (A) For content and vocabulary standards other than those at 45 CFR 
170.213, the Secretary has not prohibited use of the updated version of 
a standard for purposes of this section or 45 CFR part 170;
    (B) For standards at 45 CFR 170.213 and 170.215, the National 
Coordinator has approved the updated version for use in the ONC Health 
IT Certification Program; and
    (C) Use of the updated version of a standard does not disrupt an 
end user's ability to access the data described in paragraph (b) of 
this section through the API described in paragraph (a) of this 
section.
    (d) Documentation requirements for APIs. For each API implemented 
in accordance with paragraph (a) of this section, a State must make 
publicly accessible, by posting directly on its website or via publicly 
accessible hyperlink(s), complete accompanying documentation that 
contains, at a minimum the information listed in this paragraph. For 
the purposes of this section, ``publicly accessible'' means that any 
person using commonly available technology to browse the internet could 
access the information without any preconditions or additional steps, 
such as a fee for access to the documentation; a requirement to receive 
a copy of the material via email; a requirement to register or create 
an account to receive the documentation; or a requirement to read 
promotional material or agree to receive future communications from the 
organization making the documentation available;
    (1) API syntax, function names, required and optional parameters 
supported and their data types, return variables and their types/
structures, exceptions and exception handling methods and their 
returns;
    (2) The software components and configurations that an application 
must use in order to successfully interact with the API and process its 
response(s); and
    (3) All applicable technical requirements and attributes necessary 
for an application to be registered with any authorization server(s) 
deployed in conjunction with the API.
    (e) Denial or discontinuation of access to the API. A State may 
deny or discontinue any third-party application's connection to the API 
required under paragraph (a) of this section if the State:
    (1) Reasonably determines, consistent with its security risk 
analysis under 45 CFR part 164 subpart C, that allowing an application 
to connect or remain connected to the API would present an unacceptable 
level of risk to the security of protected health information on the 
State's systems; and
    (2) Makes this determination using objective, verifiable criteria 
that are applied fairly and consistently across all applications and 
developers through which beneficiaries seek to access their electronic 
health information as defined at 45 CFR 171.102, including but not 
limited to criteria that may rely on automated monitoring and risk 
mitigation tools.
    (f) Beneficiary resources regarding privacy and security. A State 
must provide in an easily accessible location on its public website and 
through other appropriate mechanisms through which it ordinarily 
communicates with current and former beneficiaries seeking to

[[Page 25637]]

access their health information held by the State CHIP agency, 
educational resources in non-technical, simple and easy-to-understand 
language explaining at a minimum:
    (1) General information on steps the individual may consider taking 
to help protect the privacy and security of their health information, 
including factors to consider in selecting an application including 
secondary uses of data, and the importance of understanding the 
security and privacy practices of any application to which they will 
entrust their health information; and
    (2) An overview of which types of organizations or individuals are 
and are not likely to be HIPAA covered entities, the oversight 
responsibilities of OCR and FTC, and how to submit a complaint to:
    (i) The HHS Office for Civil Rights (OCR); and
    (ii) The Federal Trade Commission (FTC).
    (g) Data availability. (1) The State must comply with the 
requirements in paragraphs (a) through (f) of this section beginning 
January 1, 2021 with regard to data:
    (i) With a date of service on or after January 1, 2016; and
    (ii) That are maintained by the State.
    (2) [Reserved]

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


Sec.  457.760  Access to published provider directory information.

    (a) The State must implement and maintain a publicly accessible, 
standards-based Application Programming Interface (API) that is 
conformant with the technical requirements at Sec.  457.730(c), 
excluding the security protocols related to user authentication and 
authorization and any other protocols that restrict the availability of 
this information to particular persons or organizations, the 
documentation requirements at Sec.  457.730(d), and is accessible via a 
public-facing digital endpoint on the State's website.
    (b) The API must provide a complete and accurate directory of--
    (1) The State's provider directory information including provider 
names, addresses, phone numbers, and specialties, updated no later than 
30 calendar days after the State receives provider directory 
information or updates to provider directory information.
    (2) [Reserved]
    (c) This section is applicable beginning January 1, 2021.

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


Sec.  457.1233  Structure and operations standards.

* * * * *
    (d) Health information systems. (1) The State must ensure, through 
its contracts, that each MCO, PIHP, and PAHP complies with the health 
information systems requirements as provided in Sec.  438.242(a), 
(b)(1) through (4), (c), (d), and (e) of this chapter.
    (2) Each MCO, PIHP, and PAHP must implement an Application 
Programming Interface (API) as specified in Sec.  457.730 as if such 
requirements applied directly to the MCO, PIHP, or PAHP, and include--
    (i) All encounter data, including encounter data from any network 
providers the MCO, PIHP, or PAHP is compensating on the basis of 
capitation payments and adjudicated claims and encounter data from any 
subcontractors.
    (ii) [Reserved]
    (3) Implement, by January 1, 2021, and maintain a publicly 
accessible standards-based API described in Sec.  457.760, which must 
include all information specified in Sec.  438.10(h)(1) and (2) of this 
chapter.
* * * * *

PART 482--CONDITIONS OF PARTICIPATION: HOSPITALS

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

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


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


Sec.  482.24  Conditions of participation: Medical record services.

* * * * *
    (d) Standard: Electronic notifications. If the hospital utilizes an 
electronic medical records system or other electronic administrative 
system, which is conformant with the content exchange standard at 45 
CFR 170.205(d)(2), then the hospital must demonstrate that--
    (1) The system's notification capacity is fully operational and the 
hospital uses it in accordance with all State and Federal statutes and 
regulations applicable to the hospital's exchange of patient health 
information.
    (2) The system sends notifications that must include at least 
patient name, treating practitioner name, and sending institution name.
    (3) To the extent permissible under applicable federal and state 
law and regulations, and not inconsistent with the patient's expressed 
privacy preferences, the system sends notifications directly, or 
through an intermediary that facilitates exchange of health 
information, at the time of:
    (i) The patient's registration in the hospital's emergency 
department (if applicable).
    (ii) The patient's admission to the hospital's inpatient services 
(if applicable).
    (4) To the extent permissible under applicable federal and state 
law and regulations and not inconsistent with the patient's expressed 
privacy preferences, the system sends notifications directly, or 
through an intermediary that facilitates exchange of health 
information, either immediately prior to, or at the time of:
    (i) The patient's discharge or transfer from the hospital's 
emergency department (if applicable).
    (ii) The patient's discharge or transfer from the hospital's 
inpatient services (if applicable).
    (5) The hospital has made a reasonable effort to ensure that the 
system sends the notifications to all applicable post-acute care 
services providers and suppliers, as well as to any of the following 
practitioners and entities, which need to receive notification of the 
patient's status for treatment, care coordination, or quality 
improvement purposes:
    (i) The patient's established primary care practitioner;
    (ii) The patient's established primary care practice group or 
entity; or
    (iii) Other practitioner, or other practice group or entity, 
identified by the patient as the practitioner, or practice group or 
entity, primarily responsible for his or her care.

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


Sec.  482.61  Condition of participation: Special medical record 
requirements for psychiatric hospitals.

* * * * *
    (f) Standard: Electronic notifications. If the hospital utilizes an 
electronic medical records system or other electronic administrative 
system, which is conformant with the content exchange standard at 45 
CFR 170.205(d)(2), then the hospital must demonstrate that--
    (1) The system's notification capacity is fully operational and the 
hospital uses it in accordance with all State and Federal statutes and 
regulations applicable to the hospital's exchange of patient health 
information.
    (2) The system sends notifications that must include at least 
patient name, treating practitioner name, and sending institution name.

[[Page 25638]]

    (3) To the extent permissible under applicable federal and state 
law and regulations, and not inconsistent with the patient's expressed 
privacy preferences, the system sends notifications directly, or 
through an intermediary that facilitates exchange of health 
information, at the time of:
    (i) The patient's registration in the hospital's emergency 
department (if applicable).
    (ii) The patient's admission to the hospital's inpatient services 
(if applicable).
    (4) To the extent permissible under applicable federal and state 
law and regulations, and not inconsistent with the patient's expressed 
privacy preferences, the system sends notifications directly, or 
through an intermediary that facilitates exchange of health 
information, either immediately prior to, or at the time of:
    (i) The patient's discharge or transfer from the hospital's 
emergency department (if applicable).
    (ii) The patient's discharge or transfer from the hospital's 
inpatient services (if applicable).
    (5) The hospital has made a reasonable effort to ensure that the 
system sends the notifications to all applicable post-acute care 
services providers and suppliers, as well as to any of the following 
practitioners and entities, which need to receive notification of the 
patient's status for treatment, care coordination, or quality 
improvement purposes:
    (i) The patient's established primary care practitioner;
    (ii) The patient's established primary care practice group or 
entity; or
    (iii) Other practitioner, or other practice group or entity, 
identified by the patient as the practitioner, or practice group or 
entity, primarily responsible for his or her care.

PART 485--CONDITIONS OF PARTICIPATION: SPECIALIZED PROVIDERS

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

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


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


Sec.  485.638  Conditions of participation: Clinical records.

* * * * *
    (d) Standard: Electronic notifications. If the CAH utilizes an 
electronic medical records system or other electronic administrative 
system, which is conformant with the content exchange standard at 45 
CFR 170.205(d)(2), then the CAH must demonstrate that--
    (1) The system's notification capacity is fully operational and the 
CAH uses it in accordance with all State and Federal statutes and 
regulations applicable to the CAH's exchange of patient health 
information.
    (2) The system sends notifications that must include at least 
patient name, treating practitioner name, and sending institution name.
    (3) To the extent permissible under applicable federal and state 
law and regulations, and not inconsistent with the patient's expressed 
privacy preferences, the system sends notifications directly, or 
through an intermediary that facilitates exchange of health 
information, at the time of:
    (i) The patient's registration in the CAH's emergency department 
(if applicable).
    (ii) The patient's admission to the CAH's inpatient services (if 
applicable).
    (4) To the extent permissible under applicable federal and state 
law and regulations, and not inconsistent with the patient's expressed 
privacy preferences, the system sends notifications directly, or 
through an intermediary that facilitates exchange of health 
information, either immediately prior to, or at the time of:
    (i) The patient's discharge or transfer from the CAH's emergency 
department (if applicable).
    (ii) The patient's discharge or transfer from the CAH's inpatient 
services (if applicable).
    (5) The CAH has made a reasonable effort to ensure that the system 
sends the notifications to all applicable post-acute care services 
providers and suppliers, as well as to any of the following 
practitioners and entities, which need to receive notification of the 
patient's status for treatment, care coordination, or quality 
improvement purposes:
    (i) The patient's established primary care practitioner;
    (ii) The patient's established primary care practice group or 
entity; or
    (iii) Other practitioner, or other practice group or entity, 
identified by the patient as the practitioner, or practice group or 
entity, primarily responsible for his or her care.

TITLE 45--PUBLIC WELFARE

SUBTITLE A--DEPARTMENT OF HEALTH AND HUMAN SERVICES

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

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

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


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


Sec.  156.221  Access to and exchange of health data and plan 
information.

    (a) Application Programming Interface to support enrollees. Subject 
to paragraph (h) of this section, a QHP issuer on a Federally-
Facilitated Exchange must implement and maintain a standards-based 
Application Programming Interface (API) that permits third-party 
applications to retrieve, with the approval and at the direction of a 
current individual enrollee or the enrollee's personal representative, 
data specified in paragraph (b) of this section through the use of 
common technologies and without special effort from the enrollee.
    (b) Accessible content. (1) A QHP issuer on a Federally-facilitate 
Exchange must make the following information accessible to its current 
enrollees or the enrollee's personal representative through the API 
described in paragraph (a) of this section:
    (i) Data concerning adjudicated claims, including claims data for 
payment decisions that may be appealed, were appealed, or are in the 
process of appeal, and provider remittances and enrollee cost-sharing 
pertaining to such claims, no later than one (1) business day after a 
claim is processed;
    (ii) Encounter data from capitated providers, no later than one (1) 
business day after data concerning the encounter is received by the QHP 
issuer; and
    (iii) Clinical data, including laboratory results, if the QHP 
issuer maintains any such data, no later than one (1) business day 
after data is received by the issuer.
    (2) [Reserved]
    (c) Technical requirements. A QHP issuer on a Federally-facilitated 
Exchange implementing an API under paragraph (a) of this section:
    (1) Must implement, maintain, and use API technology conformant 
with 45 CFR 170.215;

[[Page 25639]]

    (2) Must conduct routine testing and monitoring, and update as 
appropriate, to ensure the API functions properly, including 
assessments to verify the API is fully and successfully implementing 
privacy and security features such as, but not limited to, those 
required to comply with HIPAA privacy and security requirements in 
parts 160 and 164, 42 CFR parts 2 and 3, and other applicable law 
protecting privacy and security of individually identifiable data;
    (3) Must comply with the content and vocabulary standard 
requirements in paragraphs (c)(3)(i) and (ii) of this section, as 
applicable, to the data type or data element, unless alternate 
standards are required by other applicable law:
    (i) Content and vocabulary standards at 45 CFR 170.213 where such 
are applicable to the data type or element, as appropriate; and
    (ii) Content and vocabulary standards at part 162 of this 
subchapter and 42 CFR 423.160 where required by law, or where such 
standards are applicable to the data type or element, as appropriate.
    (4) May use an updated version of any standard or all standards 
required under paragraphs (c)(1) or (3) of this section, where:
    (i) Use of the updated version of the standard is required by other 
applicable law, or
    (ii) Use of the updated version of the standard is not prohibited 
under other applicable law, provided that:
    (A) For content and vocabulary standards other than those at 45 CFR 
170.213, the Secretary has not prohibited use of the updated version of 
a standard for purposes of this section or part 170 of this subchapter;
    (B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the 
National Coordinator has approved the updated version for use in the 
ONC Health IT Certification Program; and
    (C) Use of the updated version of a standard does not disrupt an 
end user's ability to access the data described in paragraph (b) of 
this section through the API described in paragraph (a) of this 
section.
    (d) Documentation requirements for APIs. For each API implemented 
in accordance with paragraph (a) of this section, a QHP issuer on a 
Federally-Facilitated Exchange must make publicly accessible, by 
posting directly on its website and/or via publicly accessible 
hyperlink(s), complete accompanying documentation that contains, at a 
minimum the information listed in this paragraph. For the purposes of 
this section, ``publicly accessible'' means that any person using 
commonly available technology to browse the internet could access the 
information without any preconditions or additional steps, such as a 
fee for access to the documentation; a requirement to receive a copy of 
the material via email; a requirement to register or create an account 
to receive the documentation; or a requirement to read promotional 
material or agree to receive future communications from the 
organization making the documentation available;
    (1) API syntax, function names, required and optional parameters 
supported and their data types, return variables and their types/
structures, exceptions and exception handling methods and their 
returns;
    (2) The software components and configurations an application must 
use in order to successfully interact with the API and process its 
response(s); and
    (3) All applicable technical requirements and attributes necessary 
for an application to be registered with any authorization server(s) 
deployed in conjunction with the API.
    (e) Denial or discontinuation of access to the API. A QHP issuer on 
a Federally-Facilitated Exchange may deny or discontinue any third 
party application's connection to the API required under paragraph (a) 
of this section if the QHP issuer:
    (1) Reasonably determines, consistent with its security risk 
analysis under 45 CFR part 164 subpart C, that allowing an application 
to connect or remain connected to the API would present an unacceptable 
level of risk to the security of personally identifiable information, 
including protected health information, on the QHP issuer's systems; 
and
    (2) Makes this determination using objective, verifiable criteria 
that are applied fairly and consistently across all applications and 
developers through which enrollees seek to access their electronic 
health information as defined at Sec.  171.102 of this subchapter, 
including but not limited to criteria that may rely on automated 
monitoring and risk mitigation tools.
    (f) Coordination among payers. (1) A QHP issuer on a Federally-
facilitated Exchange must maintain a process for the electronic 
exchange of, at a minimum, the data classes and elements included in 
the content standard adopted at 45 CFR 170.213. Such information 
received by a QHP issuer on a Federally-facilitated Exchange must be 
incorporated into the QHP issuer's records about the current enrollee. 
With the approval and at the direction of a current or former enrollee 
or the enrollee's personal representative, a QHP issuer on a Federally-
facilitated Exchange must:
    (i) Receive all such data for a current enrollee from any other 
payer that has provided coverage to the enrollee within the preceding 5 
years;
    (ii) At any time the enrollee is currently enrolled in the plan and 
up to 5 years after disenrollment, send all such data to any other 
payer that currently covers the enrollee or a payer the enrollee or the 
enrollee's personal representative specifically requests receive the 
data; and
    (iii) Send data received from another payer under this paragraph 
(f) in the electronic form and format it was received.
    (2) [Reserved]
    (g) Enrollee resources regarding privacy and security. A QHP issuer 
on a Federally-facilitated Exchange must provide in an easily 
accessible location on its public website and through other appropriate 
mechanisms through which it ordinarily communicates with current and 
former enrollees seeking to access their health information held by the 
QHP issuer, educational resources in non-technical, simple and easy-to-
understand language explaining at a minimum:
    (1) General information on steps the individual may consider taking 
to help protect the privacy and security of their health information, 
including factors to consider in selecting an application including 
secondary uses of data, and the importance of understanding the 
security and privacy practices of any application to which they will 
entrust their health information; and
    (2) An overview of which types of organizations or individuals are 
and are not likely to be HIPAA covered entities, the oversight 
responsibilities of the Office for Civil Rights (OCR) and the Federal 
Trade Commission (FTC), and how to submit a complaint to:
    (i) The HHS Office for Civil Rights (OCR); and
    (ii) The Federal Trade Commission (FTC).
    (h) Exception. (1) If a plan applying for QHP certification to be 
offered through a Federally-facilitated Exchange believes it cannot 
satisfy the requirements in paragraphs (a) through (g) of this section, 
the issuer must include as part of its QHP application a narrative 
justification describing the reasons why the plan cannot reasonably 
satisfy the requirements for the applicable plan year, the impact of 
non-compliance upon enrollees, the current or proposed means of 
providing health information to enrollees, and solutions and a timeline 
to achieve compliance with the requirements of this section.

[[Page 25640]]

    (2) The Federally-facilitated Exchange may grant an exception to 
the requirements in paragraphs (a) through (g) of this section if the 
Exchange determines that making such health plan available through such 
Exchange is in the interests of qualified individuals in the State or 
States in which such Exchange operates.
    (i) Applicability. A QHP issuer on an individual market Federally-
facilitated Exchange, not including QHP issuers offering only stand-
alone dental plans, must comply with the requirements in paragraphs (a) 
through (e) and (g) of this section beginning with plan years beginning 
on or after January 1, 2021, and with the requirements in paragraph (f) 
of this section beginning with plan years beginning on or after January 
1, 2022 with regard to data:
    (1) With a date of service on or after January 1, 2016; and
    (2) That are maintained by the QHP issuer for enrollees in QHPs.

    Dated: January 21, 2020.
Seema Verma,
Administrator, Centers for Medicare & Medicaid Services.
    Dated: March 5, 2020.
Alex M. Azar II,
Secretary, Department of Health and Human Services.
[FR Doc. 2020-05050 Filed 4-21-20; 4:15 pm]
 BILLING CODE P
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.