Justia Department Of Health And Human Services Centers For Medicare & Medicaid Services 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]

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.