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

DEPARTMENT OF HEALTH AND Sharon Donovan, (410) 786–9187, for B. Request for Stakeholder Input HUMAN SERVICES issues related to federal-state data VIII. Information Blocking Background and exchange. Public Reporting Provisions, and Centers for Medicare & Medicaid Daniel Riner, (410) 786–0237, for Analysis of and Responses to Public Services issues related to Physician Compare. Comments Ashley Hain, (410) 786–7603, for A. Information Blocking Background B. Public Reporting and Prevention of 42 CFR Parts 406, 407, 422, 423, 431, issues related to hospital public Information Blocking on Physician 438, 457, 482, and 485 reporting. Compare Melissa Singer, (410) 786–0365, for C. Public Reporting and Prevention of Office of the Secretary issues related to provider directories. Information Blocking for Eligible CAPT Scott Cooper, USPHS, (410) Hospitals and Critical Access Hospitals 45 CFR Part 156 786–9465, for issues related to hospital (CAHs) and critical access hospital conditions IX. Provider Digital Contact Information [CMS–9115–F] of participation. Provisions, and Analysis of and Russell Hendel, (410) 786–0329, for Responses to Public Comments RIN 0938–AT79 issues related to the Collection of A. Background Information or the Regulation Impact B. Public Reporting of Missing Digital Medicare and Medicaid Programs; Contact Information Patient Protection and Affordable Care Analysis sections. X. Conditions of Participation for Hospitals Act; Interoperability and Patient SUPPLEMENTARY INFORMATION: and Critical Access Hospitals (CAHs) Access for Medicare Advantage Table of Contents Provisions, and Analysis of and Organization and Medicaid Managed Responses to Public Comments Care Plans, State Medicaid Agencies, I. Background and Summary of Provisions A. Background A. Purpose B. Provisions for Hospitals (42 CFR CHIP Agencies and CHIP Managed B. Overview 482.24(d)) Care Entities, Issuers of Qualified C. Executive Order and MyHealthEData C. Provisions for Psychiatric Hospitals (42 Health Plans on the Federally- D. Past Efforts CFR 482.61(f)) Facilitated Exchanges, and Health Care E. Challenges and Barriers to D. Provisions for CAHs (42 CFR Providers Interoperability 485.638(d)) F. Summary of Major Provisions XI. Provisions of the Final Regulations AGENCY: Centers for Medicare & II. Technical Standards Related to XII. Collection of Information Requirements Medicaid Services (CMS), HHS. Interoperability Provisions, and Analysis A. Background ACTION: Final rule. of and Responses to Public Comments B. Wage Estimates A. Technical Approach and Standards C. Information Collection Requirements SUMMARY: This final rule is intended to B. Content and Vocabulary Standards (ICRs) move the health care ecosystem in the C. Application Programming Interface XIII. Regulatory Impact Analysis (API) Standard direction of interoperability, and to A. Statement of Need D. Updates to Standards B. Overall Impact signal our commitment to the vision set III. Provisions of Patient Access Through C. Anticipated Effects out in the 21st Century Cures Act and APIs, and Analysis of and Responses to D. Alternatives Considered Executive Order 13813 to improve the Public Comments E. Accounting Statement and Table quality and accessibility of information A. Background on Medicare Blue Button F. Regulatory Reform Analysis Under E.O. that Americans need to make informed B. Expanding the Availability of Health 13771 health care decisions, including data Information G. Conclusion about health care prices and outcomes, C. Standards-based API Proposal for MA, Regulation Text Medicaid, CHIP, and QHP Issuers on the while minimizing reporting burdens on FFEs I. Background and Summary of affected health care providers and IV. API Access to Published Provider Provisions payers. Directory Data Provisions, and Analysis In the March 4, 2019 Federal Register, of and Responses to Public Comments DATES: These regulations are effective we published the ‘‘Medicare and on June 30, 2020. A. Interoperability Background and Use Cases Medicaid Programs; Patient Protection FOR FURTHER INFORMATION CONTACT: B. Broad API Access to Provider Directory and Affordable Care Act; Alexandra Mugge, (410) 786–4457, for Data Interoperability and Patient Access for issues related to interoperability, CMS V. The Health Information Exchange and Medicare Advantage Organization and health IT strategy, and technical Care Coordination Across Payers: Medicaid Managed Care Plans, State standards. Establishing a Coordination of Care Medicaid Agencies, CHIP Agencies and Denise St. Clair, (410) 786–4599, for Transaction To Communicate Between CHIP Managed Care Entities, Issuers of issues related API policies and related Plans Provisions, and Analysis of and Qualified Health Plans on the Federally- Responses to Public Comments standards. VI. Care Coordination Through Trusted facilitated Exchanges and Health Care Natalie Albright, (410) 786–1671, for Exchange Networks: Trust Exchange Providers’’ proposed rule (84 FR 7610) issues related to Medicare Advantage. Network Requirements for MA Plans, (hereinafter referred to as the ‘‘CMS Laura Snyder, (410) 786–3198, for Medicaid Managed Care Plans, CHIP Interoperability and Patient Access issues related to Medicaid. Managed Care Entities, and QHPs on the proposed rule’’). The proposed rule Rebecca Zimmermann, (301) 492– FFEs Provisions, and Analysis of and outlined our proposed policies that 4396, for issues related to Qualified Responses to Public Comments were intended to move the health care Health Plans. VII. Improving the Medicare-Medicaid Dually ecosystem in the direction of Meg Barry, (410) 786–1536, for issues Eligible Experience by Increasing the interoperability, and to signal our Frequency of Federal-State Data related to CHIP. Exchanges Provisions, and Analysis of commitment to the vision set out in the Thomas Novak, (202) 322–7235, for and Responses to Public Comments 21st Century Cures Act and Executive issues related to trust exchange A. Increasing the Frequency of Federal- Order 13813 to improve quality and networks and payer to payer State Data Exchanges for Dually Eligible accessibility of information that coordination. Individuals Americans need to make informed

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00002 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25511

health care decisions, including data caring for them are often presented with patient’s health, providing insights into about health care prices and outcomes, an incomplete picture of their health everything from the frequency and types while minimizing reporting burdens on and care as pieces of their information of care provided and for what reason, affected health care providers and are stored in various, unconnected medication history and adherence, and payers. We solicited public comments systems and do not accompany the the evolution and adherence to a care on the CMS Interoperability and Patient patient to every care setting. Although plan. This information can empower Access proposed rule. In this final rule, more than 95 percent of hospitals 1 and patients to make better decisions and we address those public comments and 75 percent of office-based clinicians 2 inform providers to support better outline our final policies in the are utilizing certified health IT, health outcomes. respective sections of this rule. challenges remain in creating a For providers in clinical and comprehensive, longitudinal view of a community settings, health information A. Purpose patient’s health history.345 This siloed technology (health IT) should be a This final rule is the first phase of nature of health care data prevents resource, enabling providers to deliver policies centrally focused on advancing physicians, pharmaceutical companies, high quality care, creating efficiencies interoperability and patient access to manufacturers, and payers from and allowing them to access all payer health information using the authority accessing and interpreting important and provider data for their patients. available to the Centers for Medicare & data sets, instead, encouraging each Therefore, health IT should not detract Medicaid Services (CMS). We believe group to make decisions based upon a from the clinician-patient relationship, this is an important step in advancing part of the information rather than the from the patient’s experience of care, or interoperability, putting patients at the whole. Without an enforced standard of from the quality of work life for center of their health care, and ensuring interoperability, data exchanges are physicians, nurses, other health care they have access to their health often complicated and time-consuming. professionals, and social service information. We are committed to We believe patients should have the providers. Through standards-based working with stakeholders to solve the ability to move from payer to payer, interoperability and information issue of interoperability and getting provider to provider, and have both exchange, health IT has the potential to patients access to information about their clinical and administrative facilitate efficient, safe, high-quality their health care, and we are taking an information travel with them care for individuals and populations. active approach to move participants in throughout their journey. When a All payers should have the ability to the health care market toward patient receives care from a new exchange data seamlessly with other interoperability and the secure and provider, a record of their health payers for timely benefits coordination timely exchange of health information information should be readily available or transitions, and with health care and by adopting policies for the Medicare to that care provider, regardless of social service providers to facilitate and Medicaid programs, the Children’s where or by whom care was previously more coordinated and efficient care. Health Insurance Program (CHIP), and provided. When a patient is discharged Payers are in a unique position to qualified health plan (QHP) issuers on from a hospital to a post-acute care provide enrollees with a comprehensive the individual market Federally- (PAC) setting there should be no picture of their claims and encounter facilitated Exchanges (FFEs). For question as to how, when, or where data, allowing patients to piece together purposes of this rule, references to QHP their data will be exchanged. Likewise, their own information that might issuers on the FFEs excludes issuers when an enrollee changes payers or ages otherwise be lost in disparate systems. offering only stand-alone dental plans into Medicare, the enrollee should be This information can contribute to (SADPs), unless otherwise noted for a able to have their claims history and better informed decision making, specific proposed or finalized policy. encounter data follow so that helping to inform the patient’s choice of Likewise, we are also excluding QHP information is not lost. As discussed in coverage options and care providers to issuers only offering QHPs in the more detail in section III. of this final more effectively manage their own Federally-facilitated Small Business rule, claims and encounter data can health, care, and costs. We are committed to working with Health Options Program Exchanges (FF– offer a more holistic understanding of a SHOPs) from the provisions of this rule stakeholders to solve the issue of and so, for purposes of this rule 1 Office of the National Coordinator. (2019). interoperability and patient access in references to QHP issuers on the FFEs Hospitals’ Use of Electronic Health Records Data, the U.S. health care system while excludes issuers offering QHPs only on 2015–2017. Retrieved from https:// reducing administrative burdens on the FF–SHOPs. We note that, in this www.healthit.gov/sites/default/files/page/2019-04/ providers and are taking an active final rule, FFEs include FFEs in states AHAEHRUseDataBrief.pdf. approach using all available policy 2 Office of the National Coordinator. (2019, that perform plan management December 18). Health IT Playbook, Section 1: levers and authorities to move functions. State-Based Exchanges on the Electronic Health Records. Retrieved from https:// participants in the health care market Federal Platform (SBE–FPs) are not www.healthit.gov/playbook/electronic-health- toward interoperability and the secure FFEs, even though consumers in these records/. and timely exchange of health care 3 Powell, K. R. & Alexander, G. L. (2019). states enroll in coverage through Mitigating Barriers to Interoperability in Health information. HealthCare.gov, and QHP issuers in Care. Online Journal of Nursing Informatics, 23(2). C. Executive Order and MyHealthEData SBE–FPs are not subject to the Retrieved from https://www.himss.org/library/ requirements in this rule. mitigating-barriers-interoperability-health-care. On October 12, 2017, President 4 Hochman, M., Garber, J., & Robinson, E. J. (2019, Trump issued Executive Order 13813 to B. Overview August 14). Health Information Exchange After 10 Promote Healthcare Choice and Years: Time For A More Assertive, National We are dedicated to enhancing and Approach. Retrieved from https:// Competition Across the United States. protecting the health and well-being of www.healthaffairs.org/do/10.1377/hblog20190807. Section 1(c)(iii) of Executive Order all Americans. One critical issue in the 475758/full/. 13813 states that the Administration U.S. health care system is that people 5 Payne, T. H., Lovis, C., Gutteridge, C., Pagliari, will improve access to, and the quality C., Natarajan, S., Yong, C., & Zhao, L. (2019). Status cannot easily access their health of health information exchange: A comparison of of, information that Americans need to information in interoperable forms. six countries. Journal of Global Health, 9(2). doi: make informed health care decisions, Patients and the health care providers 10.7189/jogh.09.020427. including information about health care

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00003 Fmt 4701 Sfmt 4700 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 access to health information about their D. Past Efforts reporting burdens on impacted patients, regardless of where the patient The Department of Health and Human providers, and payers, meaning may have previously received care. We Services (HHS) has been working to providers and payers subject to this are also implementing policies to advance the interoperability of rule. prevent health care providers from electronic health information for over 15 In support of Executive Order 13813, inappropriately restricting the flow of years. For a detailed explanation of past the Administration launched the information to other health care efforts, see the CMS Interoperability and MyHealthEData initiative. This providers and payers. Finally, we are Patient Access proposed rule (84 FR government-wide initiative aims to working to ensure that better 7612 through 7614). empower patients by ensuring that they interoperability reduces the burden on have access to their own health health care providers. E. Challenges and Barriers to information and the ability to decide • Interoperability how their data will be used, while Payers: Implementing requirements Through significant stakeholder keeping that information safe and to ensure that payers (that is, entities feedback, we understand that there are secure. MyHealthEData aims to break and organizations that pay for health many barriers to interoperability, which down the barriers that prevent patients care), such as payers in Medicare have obstructed progress over the years. from gaining electronic access to their Advantage, Medicaid, and CHIP, make We have conducted stakeholder health information from the device or enrollee electronic health information meetings and roundtables; solicited application of their choice, empowering held by the payer available through an comments via RFIs; and received patients and taking a critical step API such that, with use of software toward interoperability and patient data expected to be developed by payers and additional feedback through letters and exchange. third parties, the information becomes rulemaking. All of this input together In March 2018, the White House easily accessible to the enrollee and data contributed to the policies in our Office of American Innovation and the flow seamlessly with the enrollee as Interoperability and Patient Access CMS Administrator announced the such enrollees change health care and proposed rule, and when combined launch of MyHealthEData, and CMS’s social service providers and payers. with the comments we received on the direct, hands-on role in improving Additionally, our policies ensure that proposed rule, the content of this final patient access and advancing payers make it easy for current and rule. Some of the main barriers shared interoperability. As part of the prospective enrollees to identify which with us, specifically patient MyHealthEData initiative, we are taking providers are within a given plan’s identification, lack of standardization, a patient-centered approach to health network in a way that is simple and information blocking, the lack of information access and moving to a easy for enrollees to access and adoption and use of certified health IT system in which patients have understand, and thus find the providers among post-acute care (PAC) providers, immediate access to their computable that are right for them. privacy concerns, and uncertainty about health information such that they can be the requirements of the Health As a result of our efforts to Insurance Portability and assured that their health information standardize data and technical will follow them as they move Accountability Act of 1996 (HIPAA) approaches to advance interoperability, throughout the health care system from Privacy, Security, and Breach we believe health care providers and provider to provider, payer to payer. To Notification Rules, were discussed in their patients, as well as other key accomplish this, we have launched the proposed rule (84 FR 7614 through participants within the health care several initiatives related to data sharing 7617). While we have made efforts to ecosystem such as payers, will have and interoperability to empower address some of these barriers in this patients and encourage payer and appropriate access to the information final rule and through prior rules and provider competition. We continue to necessary to coordinate individual care; actions, we believe there is still advance the policies and goals of the analyze population health trends, considerable work to be done to MyHealthEData initiative through outcomes, and costs; and manage overcome some of these challenges various provisions included in this final benefits and the health of populations, toward achieving interoperability, and rule. while tracking progress through quality we will continue this work as we move As finalized in this rule, our policies improvement initiatives. We are forward with our interoperability are wide-reaching and will have an working with other federal partners efforts. including the Office of the National impact on all facets of the health care F. Summary of Major Provisions system. Several key touch points of the Coordinator for Health Information policies in this rule include: Technology (ONC) on this effort with This final rule empowers patients in • Patients: Enabling patients to access the clear objectives of improving patient MA organizations, Medicaid and CHIP their health information electronically access and care, alleviating provider FFS programs, Medicaid managed care without special effort by requiring the burden, and reducing overall health care plans, CHIP managed care entities, and payers subject to this final rule to make costs, all while taking steps to protect QHP issuers on the FFEs, by finalizing data available through an application the privacy and security of patients’ several initiatives that will break down programming interface (API) to which personal health information. As those barriers currently keeping patients third-party software applications evidence of this partnership, ONC is from easily accessing their electronic connect to make data available to releasing the ONC 21st Century Cures health care information. Additionally, patients for their personal use. This Act final rule (published elsewhere in the rule creates and implements new encourages patients to take charge of this issue of the Federal Register) in mechanisms to enable patients to access and better manage their health care, and tandem with this final rule. It is this their own health care information thus these initiatives are imperative to coordinated federal effort, in through third-party software improving a patient’s long-term health conjunction with strong support and applications, thereby providing them outcomes. innovation from our stakeholders, that with the ability to decide how, when, • Clinicians and Hospitals: Ensuring will help us move ever closer to true and with whom to share their that health care providers have ready interoperability. information.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00004 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25513

We are finalizing with modifications and authorization and any other requires these payers, as finalized at 42 our proposal to require MA protocols that restrict availability of this CFR 422.119(f) for MA organizations, at organizations, Medicaid and CHIP FFS information to particular persons or 42 CFR 438.62(b)(1)(vi) for Medicaid programs, Medicaid managed care organizations. Authentication and managed care plans (and by extension plans, CHIP managed care entities, and authorization protocols are not under § 457.1216 CHIP managed care QHP issuers on the FFEs to implement necessary when making publicly entities), and at 45 CFR 156.221(f) for and maintain a standards-based Patient available data accessible via an API. We QHP issuers on the FFEs, to send, at a Access API. This Patient Access API are finalizing that the Provider Directory current or former enrollee’s request, must meet the technical standards API must be accessible via a public- specific information they maintain with finalized by HHS in the ONC 21st facing digital endpoint on the payer’s a date of service on or after January 1, Century Cures Act final rule (published website to ensure public discovery and 2016 to any other payer identified by elsewhere in this issue of the Federal access. At a minimum, these payers the current enrollee or former enrollee. Register) at 45 CFR 170.215 (currently must make available via the Provider This is consistent with the Patient including Health Level 7® (HL7) Fast Directory API provider names, Access API detailed in section III. of this Healthcare Interoperability Resources® addresses, phone numbers, and final rule. We are also finalizing a (FHIR) Release 4.0.1) and the content specialties. For MA organizations that provision that a payer is only obligated and vocabulary standards finalized by offer MA–PD plans, they must also to share data received from another HHS in the ONC 21st Century Cures Act make available, at a minimum, payer under this regulation in the final rule (published elsewhere in this pharmacy directory data, including the electronic form and format it was issue of the Federal Register) at 45 CFR pharmacy name, address, phone received. This is intended to reduce 170.213, as well as content and number, number of pharmacies in the burden on payers. We are finalizing that vocabulary standards at 45 CFR part 162 network, and mix (specifically the type this payer-to-payer data exchange must and the content and vocabulary of pharmacy, such as ‘‘retail be fully implemented by January 1, standards at 42 CFR 423.160. We are pharmacy’’). All directory information 2022. finalizing that through the Patient must be made available to current and In response to comments discussed Access API, payers must permit third- prospective enrollees and the public more fully below, we are not finalizing party applications to retrieve, with the through the Provider Directory API our proposal to require MA approval and at the direction of a within 30 calendar days of a payer organizations, Medicaid managed care current enrollee, data specified at 42 receiving provider directory information plans, CHIP managed care entities, and CFR 422.119, 431.60, 457.730, and 45 or an update to the provider directory QHP issuers on the FFEs to participate CFR 156.221. Specifically, we are information. The Provider Directory API in a trusted exchange network given the requiring that the Patient Access API is being finalized at 42 CFR 422.120 for concerns commenters raised regarding must, at a minimum, make available MA organizations, at 42 CFR 431.70 for the need for a mature Trusted Exchange adjudicated claims (including provider Medicaid state agencies, at 42 CFR Framework and Common Agreement remittances and enrollee cost-sharing); 438.242(b)(6) for Medicaid managed (TEFCA) to be in place first, and encounters with capitated providers; care plans, at 42 CFR 457.760 for CHIP appreciating that work on TEFCA is and clinical data, including laboratory state agencies, and at 42 CFR ongoing at this time. results (when maintained by the 457.1233(d)(3) for CHIP managed care We are finalizing the requirements impacted payer). Data must be made entities. Here we are finalizing that that all states participate in daily available no later than one (1) business access to the published Provider exchange of buy-in data, which includes day after a claim is adjudicated or Directory API must be fully both sending data to CMS and receiving encounter data are received. We are implemented by January 1, 2021. We do responses from CMS daily, and that all requiring that beginning January 1, strongly encourage payers to make their states submit the MMA file data to CMS 2021, impacted payers make available Provider Directory API public as soon as daily by April 1, 2022 in accordance through the Patient Access API the possible to make and show progress with 42 CFR 406.26, 407.40, and specified data they maintain with a date toward meeting all the API requirements 423.910, respectively, as proposed. of service on or after January 1, 2016. being finalized in this rule. These requirements will improve the This is consistent with the requirements We are finalizing our proposal, with experience of dually eligible individuals for the payer-to-payer data exchange certain modifications as detailed in by improving the ability of providers detailed in section V. of this final rule. section V. of this final rule, to require and payers to coordinate eligibility, Together these policies facilitate the MA organizations, Medicaid managed enrollment, benefits, and/or care for this creation and maintenance of a patient’s care plans, CHIP managed care entities, population. cumulative health record with their and QHP issuers on the FFEs to We are finalizing our proposal to current payer. coordinate care between payers by include an indicator on Physician We are finalizing regulations to exchanging, at a minimum, the data Compare for the eligible clinicians and require that MA organizations, Medicaid elements specified in the current groups that submit a ‘‘no’’ response to and CHIP FFS programs, Medicaid content and vocabulary standard any of the three prevention of managed care plans, and CHIP managed finalized by HHS in the ONC 21st information blocking statements for care entities make standardized Century Cures Act final rule (published MIPS. In the event that these statements information about their provider elsewhere in this issue of the Federal are left blank, the attestations will be networks available through a Provider Register) at 45 CFR 170.213 (currently considered incomplete, and we will not Directory API that is conformant with the ‘‘United States Core Data for include an indicator on Physician 6 the technical standards finalized by Interoperability’’ (USCDI) version 1 ). Compare. The indicator will be posted HHS in the ONC 21st Century Cures Act This payer-to-payer data exchange on Physician Compare, either on the final rule (published elsewhere in this profile pages or in the downloadable 6 Office of the National Coordinator. (n.d.). U.S. issue of the Federal Register) at 45 CFR Core Data for Interoperability (USCDI). Retrieved database, starting with the 2019 170.215, excluding the security from https://www.healthit.gov/isa/us-core-data- performance period data available for protocols related to user authentication interoperability-uscdi. public reporting starting in late 2020.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00005 Fmt 4701 Sfmt 4700 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 suppliers, primary care practitioners organizations, Medicaid Managed Care include information on a publicly and groups, and other practitioners and plans (managed care organizations available CMS website indicating that groups identified by the patient as (MCOs), prepaid inpatient health plans an eligible hospital or critical access primarily responsible for his or her care, (PIHPs), and prepaid ambulatory health hospital (CAH) attesting under the and who or which need to receive plans (PAHPs)), CHIP Managed Care Medicare FFS Promoting notification of the patient’s status for entities (MCOs, PIHPs, and PAHPs), and Interoperability Program had submitted treatment, care coordination, or quality QHP issuers on the FFEs. We use the a ‘‘no’’ response to any of the three improvement purposes. We are term ‘‘payer’’ in the preamble of this attestation statements related to the establishing that this policy will be final rule as an inclusive term for all prevention of information blocking. In applicable 12 months after publication these programs (and plan types in the the event that an eligible hospital or of this rule for hospitals, including case of plans), but we also use specific CAH leaves a ‘‘blank’’ response, the psychiatric hospitals, and CAHs to terms as applicable in sections of this attestations will be considered allow for adequate and additional time final rule. Finally, we use the term incomplete, and no information will be for these institutions, especially small ‘‘provider,’’ too, as an inclusive term posted related to these attestation and/or rural hospitals as well as CAHs, comprising individuals, organizations, statements. We will post this to come into compliance with the new and institutions that provide health information starting with the requirements. services, such as clinicians, hospitals, attestations for the EHR reporting period Finally, we note that we included two skilled nursing facilities, home health in 2019 and expect this information will RFIs in the proposed rule: one related to agencies, hospice settings, laboratories, be posted in late 2020. interoperability and health IT adoption suppliers of durable medical equipment, Additionally, as detailed in section in PAC settings and one related to the community based organizations, etc., as IX. of this final rule, we are finalizing role of patient matching in appropriate in the context used. our proposal to publicly report the interoperability and improved patient names and NPIs of those providers who II. Technical Standards Related to care. We thank commenters for the Interoperability Provisions, and do not have digital contact information insights shared on these two topics. We included in the National Plan and Analysis of and Responses to Public are reviewing these comments and will Comments Provider Enumeration System (NPPES) take them into consideration for system beginning in the second half of potential future rulemaking. A. Technical Approach and Standards 2020 as proposed. Additionally, we will Throughout this final rule, we refer to 1. Use of Health Level 7® (HL7) Fast continue to ensure providers are aware terms such as ‘‘patient,’’ ‘‘consumer,’’ ® of the benefits of including digital Healthcare Interoperability Resources ‘‘beneficiary,’’ ‘‘enrollee,’’ and (FHIR) for APIs contact information in NPPES, and ‘‘individual.’’ We note that every reader when and where their names and NPIs of this final rule is a patient and has or Section 106(b)(1)(B)(ii) of the will be posted if they do not include will receive medical care at some point Medicare Access and CHIP this information. We do strongly in their life. In this final rule, we use the Reauthorization Act of 2015 (MACRA) encourage providers to include FHIR term ‘‘patient’’ as an inclusive term, but defines health IT ‘‘interoperability’’ as endpoint information in NPPES if and because we have historically referred to the ability of two or more health when they have the information, as patients using the other terms noted information systems or components to exchange clinical and other information well. above in our regulations, we use specific and to use the information that has been To further advance electronic terms as applicable in sections of this exchanged using common standards to exchange of information that supports final rule to refer to individuals covered provide access to longitudinal effective transitions of care we are under the health care programs that finalizing the requirement for a hospital, information for health care providers in CMS administers and regulates. We also psychiatric hospital, and CAH, which order to facilitate coordinated care and note that when we discuss patients, we utilizes an electronic medical records improved patient outcomes. acknowledge a patient’s personal system or other electronic Interoperability is also defined in representative. Per the HIPAA privacy administrative system that is section 3000 of the Public Health regulations at 45 CFR 164.502(g), a conformant with the content exchange Service Act (PHSA) (42 U.S.C. 300jj), as personal representative is someone standard at 45 CFR 170.205(d)(2) to amended by section 4003 of the 21st authorized under state or other demonstrate that: (1) Its system’s Century Cures Act. Under that applicable law to act on behalf of the notification capacity is fully operational definition, ‘‘interoperability,’’ with individual in making health care related and that it operates in accordance with respect to health IT, means such health all state and federal statutes and decisions (such as a parent, guardian, or IT that enables the secure exchange of person with a medical power of electronic health information with, and regulations regarding the exchange of 7 patient health information; (2) its attorney). Policies in this final rule that use of electronic health information system sends notifications that must require a patient’s action could be from, other health IT without special include the minimum patient health addressed by a patient’s personal effort on the part of the user; allows for information specified in section X. of representative. complete access, exchange, and use of this final rule; and (3) its system sends We also use terms such as ‘‘payer,’’ all electronically accessible health notifications directly, or through an ‘‘plan,’’ and ‘‘issuer’’ in this final rule. information for authorized use under intermediary that facilitates exchange of Certain portions of this final rule are applicable state or federal law; and does health information, and at the time of a applicable to the Medicare Fee-for- not constitute information blocking as patient’s registration in the emergency Service (FFS) Program, the Medicaid defined in section 3022(a) of the PHSA, department or admission to inpatient FFS Program, the CHIP FFS program, which was added by section 4004 of the services, and also prior to, or at the time Medicare Advantage (MA) Cures Act. We believe the PHSA of, a patient’s discharge and/or transfer definition is consistent with the 7 See OCR guidance regarding personal from the emergency department or representatives at https://www.hhs.gov/hipaa/for- MACRA definition of ‘‘interoperability’’. inpatient services, to all applicable post- professionals/faq/2069/under-hipaa-when-can-a- Consistent with the CMS acute care services providers and family-member/index.html. Interoperability and Patient Access

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00006 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25515

proposed rule (84 FR 7619), we will use individual, such as their current and actuality, an ‘‘open API’’ is a secure, the PHSA definition of past medical conditions and care standards-based API that has certain ‘‘interoperability’’ for the purposes of received; and information that is of technical information openly published this final rule. general interest and should be widely to facilitate uniform use and data We believe the PHSA definition of available, such as plan provider sharing in a secure, standardized way. ‘‘interoperability’’ is useful as a networks, the plan’s formulary, and To avoid this misinterpretation, we will foundational reference for our approach coverage policies (84 FR 7619). use the term ‘‘standards-based API’’ in to advancing the interoperability and We also discussed that while many this final rule where we used ‘‘open exchange of electronic health consumers today can often access their API’’ in the proposed rule. This is also information for individuals throughout own electronic health information in better alignment with the terminology the United States, and across the entire through patient or enrollee portals and used in the ONC 21st Century Cures Act spectrum of provider types and care proprietary applications made available proposed rule (84 FR 7453) and final settings with which health insurance by various providers and health plans, rule (published elsewhere in this issue issuers and administrators need to they must typically go through separate of the Federal Register). We noted that efficiently exchange multiple types of processes to obtain access to each having certain data available through relevant data. We noted the PHSA system, and often need to manually standards-based APIs would allow definition of ‘‘interoperability’’ is not aggregate information that is delivered impacted enrollees to use the limited to a specific program or in various, often non-standardized, application of their choice to access and initiative, but rather can be applied to formats. The complex tasks of accessing use their own electronic health all activities under the title of the PHSA and piecing together this information information and other related that establishes ONC’s responsibilities can be burdensome and frustrating to information to manage their health. See to support and shape the health consumers. section III.C.2.a. of the CMS information ecosystem, including the An API can be thought of as a set of Interoperability and Patient Access exchange infrastructure for the U.S. commands, functions, protocols, or proposed rule for further discussion (84 health care system as a whole. The tools published by one software FR 7629). PHSA definition is also consistent with developer (‘‘A’’) that enable other software developers to create programs Much like our efforts under Medicare HHS’s vision and strategy for achieving Blue Button 2.0, also part of the a health information ecosystem within (applications or ‘‘apps’’) that can interact with A’s software without MyHealthEData initiative, which made which all individuals, their personal Parts A, B, and D claims and encounter representatives, their health care needing to know the internal workings of A’s software, all while maintaining data available via an API to Medicare providers, and their payers are able to beneficiaries, the policies in this rule send, receive, find, and use electronic consumer privacy data standards.9 This is how API technology enables the extend these benefits to even more health information in a manner that is patients. As of January 2020, over appropriate, secure, timely, and reliable seamless user experiences associated with applications familiar from other 53,000 Medicare beneficiaries have to support the health and wellness of taken advantage of Blue Button. individuals through informed, shared aspects of many consumers’ daily lives, 8 such as travel and personal finance. Currently, there are 55 production decision-making, as well as to support applications and over 2,500 developers consumer choice of payers and Standardized, transparent, and pro- competitive API technology can enable working in the Blue Button sandbox. providers. For more information on Blue Button We summarize the public comment similar benefits to consumers of health 10 2.0 see section III. of this final rule. As we received on use of the PHSA care services. we noted in the CMS Interoperability definition of ‘‘interoperability’’ and While acknowledging the limits of our and Patient Access proposed rule, we provide our response. authority to require use of APIs to Comment: One commenter address our goals for interoperability believe that our Patient Access API, in specifically supported the use of the and data access, we proposed to use our particular, will result in claims and PHSA definition of ‘‘interoperability’’. programmatic authority to require that a encounter information becoming easily Response: We appreciate the variety of data be made accessible by accessible for the vast majority of commenter’s support. requiring that MA organizations, patients enrolled with payers regulated A core policy principle we aim to Medicaid state agencies, Medicaid by CMS. As finalized, these policies will support across all policies in this rule is managed care plans, CHIP agencies, apply to all MA organizations, all that every American should be able, CHIP managed care entities, and QHP Medicaid and CHIP FFS programs, all without special effort or advanced issuers on the FFEs, adopt and types of Medicaid managed care plans technical skills, to see, obtain, and use implement ‘‘openly published,’’ or (MCOs, PIHPs, and PAHPs), as well as all electronically available information secure, standards-based APIs. In the CHIP managed care entities, and QHP that is relevant to their health, care, and CMS Interoperability and Patient Access issuers on the FFEs. We hope that states choices—of plans, providers, and proposed rule, we used the short form operating Exchanges might consider specific treatment options. In the terminology, ‘‘open API’’. We appreciate adopting similar requirements for QHPs proposed rule, we explained this that this term can be misunderstood to on the State-Based Exchanges (SBEs), included two types of information: mean ‘‘open’’ as in ‘‘not secure’’. In and that other payers in the private personal health information that health sector might consider voluntarily care providers and health plans, or 9 See https://www.hl7.org/fhir/security.html for offering data accessibility of the type information on how FHIR servers and resources included in the policies being finalized payers, must make available to an integrate privacy and security protocols into the data exchange via an API. here so that even more patients across 8 See, for example, Office of the National 10 ONC has made available a succinct, non- the American health care system can Coordinator. (2015). Connecting Health and Care for technical overview of APIs in context of consumers’ easily have and use such information to the Nation: A Shared Nationwide Interoperability access to their own medical information across advance their choice and participation Roadmap, Final Version 1.0. Retrieved from https:// multiple providers’ EHR systems, which is available www.healthit.gov/sites/default/files/hie- at the HealthIT.gov website at https:// in their health care. In this way, we interoperability/nationwide-interoperability- www.healthit.gov/api-education-module/story_ hope that the example being set by CMS roadmap-final-version-1.0.pdf. html5.html. will raise consumers’ expectations and

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00007 Fmt 4701 Sfmt 4700 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 • The API technologies themselves, to ensure an individual’s information is take similar steps to advance patient not just the data accessible through only disclosed as permitted or required access and empowerment outside the them, are standardized; by applicable law. The entity must take scope of the requirements being • The APIs are technically greater care in configuring and finalized in this rule. transparent; and maintaining the security functionalities We explained in the CMS • The APIs are implemented in a pro- of the API and the covered entities’ Interoperability and Patient Access competitive manner. electronic information systems to which proposed rule (84 FR 7620) that those In that section of the CMS it connects than would be needed if it seeking further information regarding Interoperability and Patient Access was implementing an API simply to what a standards-based API is are proposed rule, we discussed these allow easier access to widely available encouraged to review the discussion of concepts generally and how they were public information. In accordance with the standardized API criterion and applicable in the health care context for the HIPAA Privacy and Security Rules, associated policy principles and all payers, and explained how these the covered entity is required to technical standards included in ONC’s were relevant to our specific proposals, implement reasonable safeguards to 21st Century Cures Act proposed rule which are discussed in detail in section protect PHI while in transit. If an (84 FR 7424) and final rule (published III. of this final rule. To revisit this full individual requests their PHI in an EHR elsewhere in this issue of the Federal discussion, see the proposed rule (84 FR be sent to the third party by Register). These rules provide more 7620 through 7621). We did not receive unencrypted email or in another detailed information on API comments on this general discussion. unsecure manner, which the individual functionality and interoperability Any comments on specific proposals has a right to request, reasonable standards relevant to electronic health that refer to these three attributes are safeguards could include, for example, information. We noted that while that discussed in this final rule in the carefully checking the individual’s discussion was specific to health IT, context of the specific proposals. email address for accuracy and warning including Electronic Health Records the individual of risks associated with 2. Privacy and Security Concerns in the the unsecure transmission. We note that (EHR) systems, certified under ONC’s Context of APIs Health IT Certification Program rather the standards-based APIs discussed in than the information systems generally As we noted in the CMS this final rule are secure methods of used by payers and plan issuers for Interoperability and Patient Access data exchange. claims, encounters, or other proposed rule, HHS has received a wide HIPAA covered entities and their business associates continue to be administrative or plan operational data, range of stakeholder feedback on responsible for compliance with the it included information applicable to privacy and security issues in response 11 HIPAA Rules, the Federal Trade interoperability standards, as well as to prior proposals about policies Commission Act (FTC Act), and all considerations relevant to establishing related to APIs that would allow other laws applicable to their business reasonable and non-discriminatory consumers to use an app of their activities including but not limited to terms of service for applications seeking choosing to access protected health their handling of enrollees’ PHI and to connect to the standards-based API information (PHI) held by or on behalf other data. As we stated in the CMS discussed in this rule. While we of a HIPAA covered entity. Such Interoperability and Patient Access reiterate that we did not propose to feedback included concerns about proposed rule (84 FR 7610), nothing require payers to use Health IT Modules potential security risks to PHI created by an API connecting to third-party proposed in that rule was intended to certified under ONC’s program to make alter or should be construed as altering administrative data such as claims applications and the implications of an individual’s data being shared with existing responsibilities to protect PHI history or provider directory under the HIPAA Rules or any other information available to enrollees, we these third-party apps at the direction of the individual. laws that are currently applicable. believe that the discussion of APIs and However, we acknowledged that a related standards in the ONC 21st As we discussed in our Interoperability and Patient Access number of industry stakeholders may Century Cures Act rules will be of use mistakenly believe that they are to those seeking to better understand the proposed rule (84 FR 7621), deploying API technology would offer consumers responsible for determining whether an role of APIs in health care information application to which an individual exchange. the opportunity to access their electronic health information held by directs their PHI employs appropriate We also discussed in our proposed covered entities (including, but not safeguards regarding the information it rule how other industries have limited to MA organizations, the receives. In the proposed rule we advanced the sort of standards-based Medicare Part A and B programs, the discussed Office for Civil Rights (OCR) API-driven interoperability and Medicaid program, CHIP, QHP issuers guidance that noted that covered innovation that we seek in the health on the FFEs, and other health insurance entities are not responsible under the system (84 FR 7620). We have sought to issuers in the private markets), and HIPAA Rules for the security of PHI collaborate and align with ONC’s would not lessen any such covered once it has been received by a third- proposed and final policies specifically entity’s duties under HIPAA and other party application chosen by an related to APIs under the Cures Act as laws to protect the privacy and security individual (84 FR 7621 through 7622). we developed and finalized these Further, we noted in the CMS of information it creates, receives, policies. In general, as we noted in our Interoperability and Patient Access maintains, or transmits, including but proposed rule, we believe the following proposed rule that the HIPAA Privacy not limited to PHI. A covered entity three attributes of standards-based APIs Rule 12 established the individual’s right implementing an API to enable are particularly important to achieving of access, including a right to inspect individuals to access their health the goal of offering individuals information must take reasonable steps convenient access, through applications 12 More information on the Privacy Rule, they choose, to available and relevant including related rulemaking actions and additional 11 For instance, see discussion of stakeholder interpretive guidance, is available at https:// electronic health and health-related comments in the 2015 Edition final rule at 80 FR www.hhs.gov/hipaa/for-professionals/privacy/ information: 62676. index.html.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00008 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25517

and/or receive a copy of PHI held in opportunity to become more informed an electronic health record with respect designated record sets by covered about how to protect their PHI, to [protected health information] of an entities and their business associates as important things to consider in selecting individual . . . in an electronic detailed at 45 CFR 164.524. We an application, and where they can format.’’ 17 Generally, the court order specifically noted in the proposed rule submit a complaint if they believe a vacates a portion of the HIPAA Privacy that OCR had indicated in regulations HIPAA covered entity or business Rule that provides an individual the and guidance, that an individual could associate may not be in compliance with right to direct a covered entity to send exercise their right of access by their duties under the HIPAA Rules, or protected health information that is not requesting that their information be sent if they believe they have been subjected in an EHR to a third party identified by to a third party.13 to unfair or deceptive acts or practices the individual. As we also noted in the proposed rule related to a direct-to-consumer This decision does not affect CMS’ (84 FR 7622), we are aware of application’s privacy practices or terms programmatic authorities, as discussed stakeholder concerns about which of use. A full discussion of the Enrollee in detail in section III. of the CMS protections apply to non-covered and Beneficiary Resources Regarding Interoperability and Patient Access entities, such as direct-to-consumer Privacy and Security provision can be proposed rule (83 FR 7629 through applications. As we explained in the found in section III.C.2.h. of this final 7630) and section III. of this final rule, proposed rule, when a non–covered rule. to propose and finalize the Patient entity discloses an individual’s In some circumstances, we noted that Access API for the programs specified. confidential information in a manner or the information that we proposed to Additionally, the court’s decision did for a purpose not consistent with the require be made available through an not alter individuals’ right under HIPAA privacy notice and terms of use to API per a patient’s request, under the to request and obtain a copy of their which the individual agreed, the FTC various program-specific authorities records. Because the goal of the Patient has authority under section 5 of the FTC authorizing this rulemaking, were also Access API in our programs is to give Act (15 U.S.C. Sec. 45(a)) to investigate consistent with the enrollee’s right of patients access to their own information and take action against unfair or access for their data held by a covered for their own personal use through a deceptive trade practices. The FTC has entity or their business associate under third-party app, we believe these applied this authority to a wide variety the HIPAA Privacy Rule. But we also policies as adopted in this rule remain of entities.14 The FTC also enforces the noted that some data to which an consistent with the spirit of access FTC Health Breach Notification Rule, individual is entitled to access under rights under HIPAA. which applies to certain types of HIPAA may not be required to be As discussed in detail below, many entities, including vendors of personal transferred through the API. For commenters discussed the issues of health records and third-party service instance, when the covered entity does privacy and security in regard to providers, that fall outside of the scope not hold certain information information made available to third- of HIPAA, and therefore, are not subject electronically. In those instances, we party applications. Here, we summarize to the HIPAA Breach Notification noted that the inability to access data the public comments we received on Rule.15 This FTC Health Breach via an API would in no way limit or general issues and concerns around Notification Rule explains the process alter responsibilities and requirements privacy and security of a standards- and steps third parties must follow under other law (including though not based API, and provide our responses. when they discover a breach of limited to the HIPAA Privacy, Security, Comment: A few commenters identifiable personal health record and Breach Notification Rules) that supported OCR’s efforts to more clearly information they maintain. Any apply to the organizations that would be account for use cases, or specific violation of this Rule is enforced by the subject to this regulation. Even as these situations, in which apps are used to FTC as an unfair or deceptive act or requirements are finalized, the exchange patients’ electronic health practice under the FTC Act. organization may still be called upon to information. Some commenters noted We recognized that this is a complex respond to individuals’ request for support for OCR’s FAQ that specifies landscape for patients, who we information not available through the that covered entities are not responsible anticipate will want to exercise due API, or for all of their information or liable for the privacy and security of diligence on their own behalf in through means other than the API. We PHI once it is transmitted at the reviewing the terms of service and other encouraged HIPAA covered entities and individual’s direction to and received information about the applications they business associates to review the OCR by a third-party application. One consider selecting. Therefore, we website for resources on the individual commenter expressed concern that CMS proposed specific requirements on access standard at https://www.hhs.gov/ and ONC proposed requirements would payers to ensure enrollees have the hipaa/for-professionals/privacy/ make the safeguards of HIPAA moot if guidance/access/index.html to ensure HIPAA is not extended to third-party 13 See 45 CFR 164.524(c)(2) and (3), and they understand their responsibilities. applications that are able under this rule 164.308(a)(1), OCR HIPAA Guidance/FAQ–2036: We again encourage HIPAA covered https://www.hhs.gov/hipaa/for-professionals/faq/ to display patient data. Without 2036/can-an-individual-through-the-hipaa-right/ entities and business associates to extending HIPAA, the commenter fears index.html, and OCR HIPAA Guidance/FAQ–2037: review their responsibilities under payers and providers will be liable if the https://www.hhs.gov/hipaa/for-professionals/faq/ HIPAA in light of the recent decision in third-party misuses patient data. 2037/are-there-any-limits-or-exceptions-to-the- Ciox Health, LLC v. Azar, et al., No. 18- Response: We appreciate the individuals-right/index.html. cv-0040 (D.D.C. January 23, 2020).16 The 14 See also cases where this authority was used, commenters’ support. We reiterate that such as 2012 FTC action against Facebook (see court order vacates a portion of the HIPAA covered entities and business https://www.ftc.gov/enforcement/cases- HIPAA Privacy Rule related to the associates are responsible for meeting proceedings/092-3184/facebook-inc) and 2012 FTC individual right of access ‘‘insofar as it their HIPAA privacy and security action against MySpace (see https://www.ftc.gov/ expands the HITECH Act’s third-party enforcement/cases-proceedings/102-3058/myspace- obligations to protect patient data they llc-matter). directive beyond requests for a copy of 15 See 16 CFR part 318; see also https:// 17 See, https://hds.sharecare.com/wp-content/ www.healthit.gov/sites/default/files/non-covered_ 16 See, https://ecf.dcd.uscourts.gov/cgi-bin/show_ uploads/2020/01/CiOX-Health-v.-HHS-Court-Order- entities_report_june_17_2016.pdf. public_doc?2018cv0040-51. 3-24-2020.pdf.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00009 Fmt 4701 Sfmt 4700 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 Interoperability and Patient Access are responsible for meeting their HIPAA the contrary, are obligated to take proposed rule and the ONC 21st privacy and security obligations to reasonable measures to protect these Century Cures Act proposed rule, and protect patient data they maintain, and data in transit. Once these data are suggested that any terminology absent patient requests to the contrary, transmitted and no longer under the inconsistencies be addressed and are obligated to take reasonable control of the covered entity or business harmonized. These commenters noted measures to protect these data in transit. associate, those entities no longer have that the OCR FAQ pertains to Once these data are received by a third- any obligations under HIPAA for the ‘‘electronic protected health party and no longer under the control of privacy and security of the PHI, because information’’ (ePHI), and uses the term the covered entity or its business these data are no longer subject to ‘‘electronic health record (EHR) system associate, the covered entity and HIPAA. We stress, as discussed in the developer’’, which differs from terms business associate are not liable for the CMS Interoperability and Patient Access used in the CMS Interoperability and privacy and security of the PHI or any proposed rule, nothing in this rule alters Patient Access and the ONC 21st electronic health information sent. covered entities’ or business associates’ Century Cures Act proposed rules. While HIPAA covered entities and their responsibilities to protect PHI under the Response: We appreciate comments business associates may notify patients HIPAA Privacy and Security Rules. regarding variance in the terminology of their potential concerns regarding The only instance per the policies used in OCR guidance and the CMS exchanging data with a specific third- proposed in this rule that would allow Interoperability and Patient Access party not covered by HIPAA, they are a payer to deny access to an app, as proposed rule. Regarding the not required to do so, and they may not discussed in the proposed rule and relationship between ePHI and substitute their own judgment for that of underlying the rationale for finalizing electronic health information (EHI), we the patient requesting the data be 42 CFR 422.119(e), 431.60(e), refer readers to the discussion in the transferred. 438.242(b)(6) (redesignated as ONC 21st Century Cures Act final rule Comment: Several commenters § 438.242(b)(5) see section VI. in this (published elsewhere in this issue of the recommended that CMS include a safe rule), 457.730(e), 457.1233(d)(2), and 45 Federal Register). OCR guidance uses harbor provision in the regulatory text CFR 156.221(e), would be if the covered the term ‘‘electronic health record of this final rule to indicate that plans entity or its business associate’s own system developer’’ 18 to refer to a health and providers are not responsible for the systems would be endangered if it were IT developer that develops and downstream privacy and security of to engage with a specific third-party maintains electronic health record PHI. application through an API, for instance systems containing PHI for a covered Response: Regarding commenters’ if allowing such access would result in entity, and therefore is a business interest in a ‘‘safe harbor’’ provision for an unacceptable security risk. Therefore, associate of those covered entities. The covered entities when data is as we also noted, covered entities and guidance also uses ‘‘app developer’’ to transmitted to a third-party app, we do business associates are free to offer describe the creator of the app that is not have the authority, nor do we advice to patients on the potential risks designated to receive an individual’s believe it is necessary, to incorporate involved with requesting data transfers PHI. ONC uses related terms that have these principles in a safe harbor provision under the HIPAA Privacy and to an application or entity not covered a specific meaning within the context of Security Rules. Covered entities and by HIPAA, but such efforts generally ONC programs. For instance, ONC uses business associates are not responsible must stop at education and awareness or the term ‘‘health IT developer’’ for the for the data after the data have been advice regarding concerns related to a purposes of the ONC Health IT received by the intended recipient. This specific app. For instance, if a payer Certification Program to refer to a has been taken into account in notes that an app a patient requests vendor, self-developer, or other entity developing the requirements for the receive their data does not lay out in its that presents health IT for certification Patient Access API. privacy policy specifically how the or has health IT certified under the patient’s personal data will be used, the Comment: Several commenters program. In addition, the ONC 21st payer could choose to inform the patient expressed concerns that app developers Century Cures Act proposed rule they may not want to share their data are not subject to many of the current proposed to define the term ‘‘health IT with that app without a clear laws protecting the privacy and security developer of certified health IT’’ for the understanding of how the app may use of electronic health information. Several purposes of implementing provisions of the data, including details about the commenters requested that HHS specify the Cures Act (84 FR 7510). We do not app’s secondary data use policy. If the what requirements non-HIPAA covered use these ONC program-specific terms patient still wants their data to be app developers will be subject to. in this CMS rule. We simply refer to any shared, or does not respond to the Response: We appreciate the developer of a third-party app, of which payer’s warning, the payer would need commenters’ concerns. As discussed in to share these data via the API absent an an electronic record systems developer the CMS Interoperability and Patient unacceptable security risk to the payer’s may be one. Access proposed rule (84 FR 7622), Comment: One commenter requested own system. For more information on HIPAA protections do not extend to clarification on a covered entity’s this ability to inform patients, see third-party apps (that is, software liability under HIPAA if a patient section III.C.2.g. of this final rule. The applications from entities that are not requirements finalized in this rule do transfers their health information from a covered entities or business associates). not impact or change obligations under covered entity’s mobile access portal or However, the FTC has the authority to the HIPAA Privacy and Security Rules application to a third-party application investigate and take action against in any way. not covered under HIPAA. unfair or deceptive trade practices Comment: A few commenters noted Response: As noted above, HIPAA under the FTC Act and the FTC Health discrepancies in the terminology used covered entities and business associates Breach Notification Rule when a third- in the OCR FAQ mentioned in the CMS party app does not adhere to the stated 18 See Office of the National Coordinator. (n.d.). Interoperability and Patient Access Health Information Technology. Retrieved from privacy policy. We have shared these proposed rule compared to terminology https://www.hhs.gov/hipaa/for-professionals/faq/ comments with the FTC. State laws may used throughout the CMS health-information-technology/index.html. provide additional protections as well.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00010 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25519

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00012 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25521

factors related to the technical aspect of clear and consistent goals for all payers, adoption at 45 CFR 170.215 as finalized implementing these requirements. providers, vendors, and developers. (84 FR 7589). By requiring compliance We summarize the public comments CMS and ONC will continue to with 45 CFR 170.215, we proposed to we received regarding separately coordinate closely on standards, require use of the foundational Health adopting standards in this CMS rule and including content and vocabulary Level 7® (HL7) 19 Fast Healthcare provide our responses. standards and impacted data elements Interoperability Resources® (FHIR) Comment: Many commenters and use cases, and we will continue to standard,20 several implementation supported CMS’ proposed alignment work closely with all stakeholders to specifications specific to FHIR, and with the standards proposed in ONC’s ensure that this process is consensus- complementary security and app 21st Century Cures Act proposed rule to based. Regarding the recommendation registration protocols, specifically the be adopted by HHS to promote to add data elements from the EOB not Substitutable Medical Applications, interoperability, noting it was the most yet included in the USCDI, we have Reusable Technologies (SMART) effective and efficient approach. shared these recommendations with Application Launch Implementation Commenters explained that this ONC, and we refer readers to the Guide (IG) 1.0.0 (including mandatory alignment was critical to ensure discussion in ONC’s 21st Century Cures support for ‘‘refresh tokens,’’ interoperability across the health care Act final rule on the USCDI and the ‘‘Standalone Launch,’’ and ‘‘EHR industry, and overwhelmingly preferred Standards Version Advancement Launch’’ requirements), which is a ‘‘one source of truth’’ for all standards Process (published elsewhere in this profile of the OAuth 2.0 specification, as referenced in the CMS Interoperability issue of the Federal Register). well as the OpenID Connect Core 1.0 and Patient Access proposed rule. These standard, incorporating errata set 1. A B. Content and Vocabulary Standards commenters explained having highly further discussion of these proposals technical standards, including content The content and vocabulary standards can be found in section II.C. (84 FR 7624 and vocabulary standards, in different HHS ultimately adopts applicable to the through 7625) and the proposals are CMS and ONC regulations would create data provided through the standards- detailed in section III. of the CMS the potential for error and misalignment based API will, by necessity, vary by use Interoperability and Patient Access of standards or versions of standards case and within a use case. For instance, proposed rule (84 FR 7626 through across HHS programs. Commenters content and vocabulary standards 7639). Comments received on these supported alignment across agencies, supporting consumer access vary proposals are summarized with our and indicated concern that if the according to what specific data elements responses in section III. of this final standards were adopted in different MA organizations, Medicaid and CHIP rule. regulations, it would complicate the FFS programs, Medicaid managed care We proposed to adopt the technical process of updating the standards when plans, CHIP managed care entities, and standards as finalized by HHS in the necessary, and increase the cost and QHP issuers on the FFEs have available ONC 21st Century Cures Act final rule burden of data capture, data electronically. Where another law does (published elsewhere in this issue of the management, and data exchange. not require use of a specific standard, Federal Register) at 45 CFR 170.215. Commenters did note opportunities for we proposed to require use of, in effect, HHS is finalizing adoption of HL7 FHIR even greater alignment across the CMS a catalogue of content and vocabulary Release 4.0.1 as the foundational and ONC rulemakings at the data standards from which the regulated standard for APIs at 45 CFR element level, indicating that the ONC entities may choose in order to satisfy 170.215(a)(1). Instead of the Argonaut IG rule should include all data elements the proposed requirements in 42 CFR and server to support exchange of the required in the CMS rule, specifically 422.119, 431.60, 457.730, 438.252, and USCDI proposed at 45 CFR 170.215(a)(3) calling out data elements in an 457.1233, and 45 CFR 156.221. A and (a)(4) (84 FR 7424), HHS is Explanation of Benefits (EOB) not further discussion of these proposals finalizing the HL7 FHIR US Core IG specifically included in the USCDI can be found in section II.B. of the CMS STU 3.1.0 at 45 CFR 170.215(a)(2). The (proposed for codification at 45 CFR Interoperability and Patient Access HL7 SMART Application Launch 170.213). proposed rule (84 FR 7623 through Framework IG Release 1.0.0 was Response: We appreciate the 7624). These proposals are detailed in proposed at 45 CFR 170.215(a)(5) (84 FR commenters’ support for alignment of section III.C.2.b. of the CMS 7424). HHS is finalizing the HL7 the regulations adopted in this final rule Interoperability and Patient Access SMART Application Launch Framework with the standards as finalized by HHS proposed rule (84 FR 7626 through IG Release 1.0.0 (which is a profile of in the ONC 21st Century Cures Act final 7639), and comments received on these the OAuth 2.0 specification), including rule (published elsewhere in this issue proposals are summarized with our mandatory support for the ‘‘SMART on of the Federal Register). We agree that responses in section III.C.2.b. of this FHIR Core Capabilities,’’ at 45 CFR the best way to ensure continued final rule. Specifically, we note that we 170.215(a)(3). HHS is finalizing as alignment is to have the regulations we proposed to adopt the content and proposed adoption of OpenID Connect are adopting here—governing MA vocabulary standards as finalized by Core 1.0, incorporating errata set 1 at 45 organizations, state Medicaid FFS HHS in ONC’s 21st Century Cures Act CFR 170.215(b), as well as adoption of programs, Medicaid managed care final rule (published elsewhere in this version 1.0.0: STU 1 of the FHIR Bulk plans, CHIP FFS programs, CHIP issue of the Federal Register) at 45 CFR Data Access specification at 45 CFR managed care entities, and QHP issuers 170.213. This standard is currently the on the FFEs—cross reference the USCDI version 1. 19 Health Level Seven International® (HL7) is a specific regulations codifying the not-for-profit, ANSI-accredited standards standards adopted by HHS in the ONC C. Application Programming Interface development organization (SDO) focused on (API) Standard developing consensus standards for the exchange, 21st Century Cures Act final rule. Our integration, sharing, and retrieval of electronic intent is to ensure alignment and In section III.C.2.b. of the CMS health information that supports clinical practice consistent standards across the Interoperability and Patient Access and the management, delivery and evaluation of health services. Learn more at ‘‘About HL7’’ web regulated programs. We agree that this proposed rule, we proposed to require page, last accessed 06/27/2018. will help support interoperability across compliance with the API technical 20 FHIR Overview. (n.d.). Retrieved from https:// the health care industry and help set standard proposed by ONC for HHS www.hl7.org/fhir/overview.html.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00013 Fmt 4701 Sfmt 4700 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 guides (IGs) as discussed above),22 we Medicare Blue Button 2.0 is a new, adoption of FHIR Release 2 or FHIR proposed to allow the use of an updated modernized version of the original Blue Release 3, API Resource Collection in version of a standard adopted by HHS, Button service. It enables beneficiaries Health (ARCH) Version 1, or the HL7 provided such updated version has been to access their Medicare Parts A, B, and Consent2Share FHIR Consent Profile approved by the National Coordinator D claims and encounter data and share Design that were proposed at 45 CFR through the Standards Version that electronic health information 170.215(a)(1), (c)(1), (a)(2), or (c)(2), Advancement Process described in the through an Application Programming respectively (84 FR 7424). For a full ONC 21st Century Cures Act proposed Interface (API) with applications, discussion, see the ONC 21st Century rule (84 FR 7424), as finalized. A further services, and research programs they Cures Act final rule (published discussion of these proposals can be select. As discussed in section II.A. of elsewhere in this issue of the Federal found in section II.D. of the CMS the CMS Interoperability and Patient Register). The content and vocabulary Interoperability and Patient Access Access proposed rule (see 84 FR 7618 standards and technical standards proposed rule (84 FR 7625 through through 7623), API technology allows finalized by HHS in the ONC 21st 7626). These proposals are also detailed software from different developers to Century Cures Act final rule provide the in section III. of the CMS connect with one another and exchange foundation needed to support Interoperability and Patient Access electronic health information in implementation of the policies as proposed rule (84 FR 7626 through electronic formats that can be more proposed and now finalized in this rule. 7639), and comments received on these easily compiled and leveraged by D. Updates to Standards proposals are summarized with our patients and their caregivers. Beneficiaries may also select third-party In addition to efforts to align responses in section III. of this final rule. applications to compile and leverage standards across HHS, we recognized in their electronic health information to the proposed rule that while we must III. Provisions of Patient Access help them manage their health and codify in regulation a specific version of Through APIs, and Analysis of and engage in a more fully informed way in each standard, the need for continually Responses to Public Comments their health care. evolving standards development has historically outpaced our ability to A. Background on Medicare Blue Button Today, Blue Button 2.0 contains 4 amend regulatory text. To address how years of Medicare Part A, B, and D data As discussed in the CMS standards development can outpace our for 53 million Medicare beneficiaries. rulemaking schedule, we proposed in Interoperability and Patient Access These data are available to patients to section III.C.2.b. of the CMS proposed rule (84 FR 7626), we are help them make more informed Interoperability and Patient Access committed to advancing decisions. Beneficiaries dictate how proposed rule (84 FR 7630 through interoperability, putting patients at the their data can be used and by whom, 7631) that regulated entities may use center of their health care, and ensuring with identity and authorization updated versions of required standards they have simple and easy access, controlled through MyMedicare.gov. if use of the updated version is required without special effort, to their health Medicare beneficiaries can authorize by other applicable law. In addition, information. With the establishment of sharing their information with an ® under certain circumstances, we the initial Medicare Blue Button application using their MyMedicare.gov proposed to allow use of an updated service in 2010, Medicare beneficiaries account information. Beneficiaries version of a standard if the standard is became able to download their Part A, authorize each application, service, or not prohibited under other applicable Part B, and Part D health care claims research program they wish to share law. and encounter data through their data with individually. A For content and vocabulary standards MyMedicare.gov in either PDF or text beneficiary can go back to at 45 CFR part 162 or 42 CFR 423.160, format. While the original Blue Button MyMedicare.gov at any time and change we proposed to allow the use of an effort was a first step toward liberating the way an application uses their updated version of the content or patient health information, we information. Using Blue Button 2.0, vocabulary standard adopted under recognized that significant opportunities beneficiaries can access their health rulemaking, unless the use of the remain to modernize access to that information; share it with doctors, updated version of the standard: Is health information and the ability to caregivers, or anyone they choose; and prohibited for entities regulated by that share health information across the get help managing and improving their part or the program under that section; health ecosystem. We believe that health through a wide range of apps and Is prohibited by the Secretary for moving to a system in which patients other computer-based services. Blue purposes of these policies or for use in have access to and use of their health Button 2.0 is an optional service— ONC’s Health IT Certification Program; information will empower them to make beneficiaries choose the apps and or is precluded by other applicable law. better informed decisions about their services they want to use. We remind readers that other applicable health care. Additionally, Today, Medicare beneficiaries using law includes statutes and regulations interoperability, and the ability for Blue Button 2.0 can connect with apps that govern the specific entity. For the health information systems and software that keep track of tests and services they content and vocabulary standards applications to communicate, exchange, need and receive reminders, track their proposed by ONC for HHS adoption at and interpret health information in a medical claims, make appointments and 45 CFR 170.213 (84 FR 7589) (currently, usable and readable format, is vital to send messages to their doctors, get USCDI version 1),21 as well as for API improving health care. Allowing access personalized information about their technical standards proposed by ONC to health information only through PDF symptoms and medical conditions, find for HHS adoption at 45 CFR 170.215 (84 and text formats limit the utility of and health and drug plans, keep track of FR 7589) (including HL7 FHIR and the ability to effectively share the health their medical notes and questions, and other standards and implementation information. connect to research projects.23 These are

21 For more information on the USCDI, see 22 For more information on FHIR, see https:// 23 To review a list of apps currently available to https://www.healthit.gov/USCDI. www.hl7.org/fhir/overview.html. Blue Button 2.0 users, visit https://

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 25523

just some of the ways Blue Button 2.0 provider the ability to use the combined CMS’ programmatic authorities, as is using a standards-based, FHIR- information, with relevant clinical discussed in detail in section III. of the enabled API to lead the charge and decision support tools, as part of normal CMS Interoperability and Patient Access unleash the power of health data. care delivery in a less burdensome way, proposed rule (83 FR 7629 through leading to improved care. This may be 7630) and later in this section of this B. Expanding the Availability of Health particularly important during times of final rule. Prior to this decision, in the Information system surge, an event that generates a CMS Interoperability and Patient Access 1. Patient Benefits of Information Access large and sudden demand for health proposed rule, we discussed that the services, for example, when access to As discussed in the CMS HIPAA Privacy Rule, at 45 CFR 164.524, such information may help to inform Interoperability and Patient Access provides that an individual has a right patient triage, transfer, and care proposed rule, we believe there are of access to inspect and obtain a copy decisions. of their PHI 24 that is maintained by or numerous benefits associated with Further, we noted that we believe individuals having simple and easy on behalf of a covered entity (a health patients who have immediate electronic 25 access to their health care data under a plan or covered health care provider ) access to their health information are 26 standard that is widely used. Whereas in a designated record set. It was empowered to make more informed noted that, at that time, a covered entity EHR data are frequently locked in decisions when discussing their health closed, disparate health systems, care was required to provide the access in needs with providers, or when any readily producible form and format and treatment information in the form of considering changing to a different claims and encounter data is requested by the individual, and that health plan. We discussed that currently the right of access also includes comprehensively combined in a not all beneficiaries enrolled in MA patient’s claims and billing history. individual’s right to direct a covered plans have immediate electronic access entity to transmit PHI directly to a third Claims and encounter data, used in to their claims and encounter data and conjunction with EHR data, can offer a party the individual designates to those who do have it, cannot easily receive it.27 broader and more holistic share it with providers or others. The understanding of an individual’s We explained that software same is true of Medicaid beneficiaries applications using the Patient Access interactions with the health care system and CHIP enrollees, whether enrolled in than EHR data alone. As one example, API proposed at 42 CFR 422.119, FFS or managed care programs, and 431.60, 438.242(b)(6) (finalized as inconsistent benefit utilization patterns enrollees in QHPs on the FFEs. As in an individual’s claims data, such as 438.242(b)(5) in this rule; see section industries outside of health care VI.), 457.730, and 457.1233(d)(2), and a failure to fill a prescription or receive continue to integrate multiple sources of recommended therapies, can indicate 45 CFR 156.221, and further discussed data to understand and predict their below, would provide an additional that the individual has had difficulty consumers’ needs, we believe it is financing a treatment regimen and may mechanism through which the important to position MA organizations, individuals who so choose could require less expensive prescription Medicaid and CHIP FFS programs and drugs or therapies, additional exercise the HIPAA right of access to managed care entities, and QHP issuers their PHI, by giving them a simple and explanation about the severity of their on the FFEs to do the same to encourage condition, or other types of assistance. easy electronic way to request, receive, competition, innovation, and value. and share data they want and need, Identifying and finding opportunities to We noted that CMS has programmatic including with a designated third party. address the individual’s non-adherence authority over MA organizations, However, as discussed in section II. of to a care plan are critical to keeping Medicaid programs (both FFS and people with chronic conditions healthy managed care), CHIP (both FFS and the CMS Interoperability and Patient and engaged so they can avoid managed care), and QHP issuers on the Access proposed rule (84 FR 7621 hospitalizations. While a health plan FFEs. We proposed to leverage CMS through 7622), due to limitations in the can use claims and encounter data to authority to make claims and encounter current availability of interoperability help it identify which enrollees could data available through APIs as a means standards for some types of health benefit from an assessment of why they to further access for patients in these information, or data, we noted the API are not filling their prescriptions or who programs along with other plan data requirement may not be sufficient to might be at risk for particular problems, (such as provider directory data) as support access to all of the PHI subject putting this information into the hands detailed in sections III.C. and IV. of the to the HIPAA right of access because a of the individual’s chosen care CMS Interoperability and Patient Access patient’s PHI may not all be transferable provider—such as the doctor or nurse proposed rule. For a complete through the API. For instance, we practitioner prescribing the medications discussion of these proposals, see the proposed to require payers to make or the pharmacist who fills the proposed rule (84 FR 7626 through claims and encounter data as well as a prescriptions—helps them to engage the 7640). specified set of clinical data (that is, patient in shared decision making that clinical data maintained by the 2. Alignment with the HIPAA Right of can help address some of the reasons applicable payer in the form of the Access the individual might not be willing or USCDI version 1 data set) available able to take medications as prescribed. As discussed in section II. of this final through the Patient Access API. By authorizing their providers to access rule, the recent decision in Ciox Health, LLC v. Azar, et al. vacates a portion of 24 See 45 CFR 160.103, definition of protected the same information through a health information. standards-based API, individuals can the HIPAA Privacy Rule that provides 25 The third type of HIPAA covered entity, a further facilitate communication with an individual the right to direct a health care clearinghouse, is not subject to the same their care teams. Enabling the provider covered entity to send protected health requirements as other covered entities with respect to integrate claims and encounter information that is not in an EHR to a to the right of access. See 45 CFR 164.500(b). third party identified by the individual. 26 See 45 CFR 164.501, definition of designated information with EHR data gives the record set. It does not alter a patient’s right to 27 For more information, see https:// www.medicare.gov/manage-your-health/medicares- request access to their records. In www.hhs.gov/hipaa/for-professionals/privacy/ blue-button-blue-button-20/blue-button-apps. addition, the decision does not affect guidance/access/index.html.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00015 Fmt 4701 Sfmt 4700 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 responses are noted below in this final Access proposed rule similarly and to an X-ray image as well. Currently, the rule. starting with similar text is an important X-ray image itself is not captured under step to communicate that to the 2. The Standards-Based API Proposal the USCDI version 1 data set, and applicable entities that would be though the necessary FHIR resources to In the proposed rule, we addressed required to comply (except as noted share this information via an API like the following components of the below with regard to specific proposals). the Patient Access API are available, use standards-based API. Specifically, we In paragraph (a) of each applicable is not required under this rulemaking discussed: proposed regulation, we proposed that and so a payer may not be able to share • Authority to require the regulated entity (that is, the MA such information via the API. Therefore, implementation of a standards-based organization, the state Medicaid or CHIP under our proposal, a HIPAA covered API by MA organizations, Medicaid and agency, the Medicaid managed care entity would have to share this type of CHIP state agencies, Medicaid managed plan, the CHIP managed care entity, or information in a form and format other care plans, CHIP managed care entities, the QHP issuer on an FFE, as than the Patient Access API in order to and QHP issuers on the FFEs; applicable) would be required to comply with our program proposals and • The API technical standard and implement and maintain a standards- in keeping with the HIPAA Privacy Rule content and vocabulary standards; based API that permits third-party right of access. • Data required to be available applications to retrieve, with the through the standards-based API and approval and at the direction of the C. Standards-Based API Proposal for timeframes for data availability; individual patient, data specified in MA, Medicaid, CHIP, and QHP Issuers • Documentation requirements for paragraph (b) of each regulation through on the FFEs APIs; the use of common technologies and 1. Introduction • Routine testing and monitoring of without special effort from the standards-based APIs; beneficiary. By ‘‘common technologies We proposed to add new provisions at • Compliance with existing privacy and without special effort’’ by the 42 CFR 422.119, 431.60, 438.242(b)(6) and security requirements; enrollee, we explained that the (finalized as § 438.242(b)(5) in this rule; • Denial or discontinuation of access regulation means use of common see section VI.), 457.730, 457.1233(d), to the API; consumer technologies, like smart and 45 CFR 156.221, that would, • Enrollee and beneficiary resources phones, home computers, laptops, or respectively, require each MA regarding privacy and security; tablets, to request, receive, use, and organization, Medicaid FFS program, • Exceptions or provisions specific to approve transfer of the data that would Medicaid managed care plan, CHIP FFS certain programs or sub-programs; and be available through the standards- program, CHIP managed care entity, and • Applicability and timing. based API technology. By ‘‘without QHP issuer on an FFE to implement, We also included an RFI on information special effort,’’ we proposed to codify test, and monitor a standards-based API our expectation that third-party that is accessible to third-party sharing between payers and providers through APIs. software, as well as proprietary applications and developers. We noted applications and web portals operated that states with CHIPs were not required Specifically, we proposed nearly by the payer could be used to connect to operate FFS systems and that some identical language for the regulations to the API and provide access to the states’ CHIPs were exclusively operated requiring standards-based APIs at 42 data to the enrollee. In the CMS by managed care entities. We did not CFR 422.119; 431.60, and 457.730, and Interoperability and Patient Access intend to require CHIPs that do not 45 CFR 156.221 for MA organizations, proposed rule (84 FR 7628 through operate a FFS program to establish an Medicaid state agencies, state CHIP 7638), we addressed the data that must API; rather, we noted that these states agencies, and QHP issuers on the FFEs; be made available through the API in may rely on each of their contracted Medicaid managed care plans would be paragraph (b); the regulation regarding plans, referred to throughout the CMS required, at 42 CFR 438.242(b)(6) the technical standards for the API and Interoperability and Patient Access (finalized as 438.242(b)(5) in this rule; the data it contains in paragraph (c); the proposed rule and this final rule as see section VI.), to comply with the documentation requirements for the API CHIP managed care entities, to set up requirement at 42 CFR 431.60, and CHIP in paragraph (d); explicit authority for such a system. managed care entities would be required the payer regulated under each As discussed, the API would allow by 42 CFR 457.1233(d)(2) to comply regulation to deny or discontinue access enrollees and beneficiaries of MA with the requirement at 42 CFR 457.730. to the API in paragraph (e); and, organizations, Medicaid and CHIP FFS As discussed in detail in the CMS requirements for posting information programs, Medicaid managed care Interoperability and Patient Access about resources on security and privacy plans, CHIP managed care entities, and proposed rule, we proposed similar if for beneficiaries in paragraphs (f) or (g). QHP issuers on the FFEs to exercise not identical requirements for these Additional requirements specific to their HIPAA right of access to certain various entities to establish and certain programs, discussed in sections health information specific to their plan maintain a standards-based API, make IV. and V. of the CMS Interoperability electronically, through the use of specified data available through that and Patient Access proposed rule, were common technologies and without API, disclose API documentation, also included in some of the regulations special effort. We explained how provide access to the API, and make that address the API. We address those ‘‘common technologies,’’ for purposes of resources available to enrollees. We additional requirements in sections IV. the proposal, means those that are noted that we believed that such nearly and V. of this final rule. widely used and readily available, such identical text is appropriate as the as computers, smartphones, or tablets. reasons and need for the proposal and a. Authority To Require Implementation The proposals are detailed in section the associated requirements are the of a Standards-Based API III.C. of the CMS Interoperability and same across these programs. We As noted in the CMS Interoperability Patient Access proposed rule (84 FR intended to interpret and apply the and Patient Access proposed rule (84 FR 7626 through 7639), and comments regulations proposed in section III.C. of 7629 through 7630), the proposal would received on these proposals and our the CMS Interoperability and Patient apply to MA organizations, Medicaid

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00016 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25525

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00018 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25527

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00019 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25528 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

Response: We appreciate the care decisions. Several commenters recommendations. As discussed in commenters’ suggestions. The proposed were concerned that certain patient section XIII. of this final rule, we are rule did not specify a historical look- groups, such as those with low providing updated cost estimates for back period for the Patient Access API technology access and/or health implementing and maintaining the or limit the timeframe of the data that literacy, would not make use of Patient Access API, moving from a must be available through the API. To electronic applications for making single point estimate to a range— ensure consistent implementation and health care decisions. A few including a low, primary, and high minimize the burden on payers, we are commenters recommended CMS not estimate—to better take into account the finalizing additional text in the limit patient access to health many factors that impact the cost of applicable regulations to specify that information through apps alone, implementation. We have revised our MA organizations at 42 CFR 422.119(h), especially for populations with low original estimate of $788,414 per payer, state Medicaid FFS programs at 42 CFR technology access and/or literacy. to a primary estimate of $1,576,829 per 431.60(g), Medicaid managed care plans Response: We appreciate the payer, increasing our original estimate at 42 CFR 438.62(b)(1)(vii), CHIP FFS commenters’ concerns. However, more by a factor of 2 to account for additional programs at 42 CFR 457.730(g), CHIP and more Americans are using portable information that was provided by managed care entities at 42 CFR technology like smart phones and commenters, which we still believe is 457.1233(d), and QHP issuers on the tablets to conduct a myriad of daily relatively minimal in relation to the FFEs at 45 CFR 156.221(i), beginning activities. Approximately 81 percent of overall budget of these impacted payers. January 1, 2021 (or plan years beginning U.S. adults reported owning a We have included a low estimate of on or after January 1, 2021 for QHPs on smartphone and 52 percent reported $718,414.40 per organization, and a the FFEs), must make available through owning a tablet computer in 2019.28 An high estimate of $2,365,243 per the Patient Access API data that they American Community Survey Report organization. We refer readers to maintain with a date of service on or from the U.S. Census Bureau reported sections XII. and XIII. of this final rule after January 1, 2016. This means that that in 2016, 82 percent of households for a detailed discussion of our revised no information with a date of service reported an internet subscription and 83 cost estimates. earlier than January 1, 2016 will need to percent reported a cellular data plan.29 We acknowledge that payers may pass be made available through the Patient People have a right to be able to these costs to patients via increased Access API. By ‘‘date of service,’’ we manage their health information in this premiums. In this way, patients could mean the date the patient received the way should they choose. We appreciate absorb the cost of the API. However, we item or service, regardless of when it that not everyone is comfortable with, note the costs of ‘‘premiums’’ for MA, was paid for or ordered. This is has access to, or uses electronic Medicaid, and CHIP enrollees are consistent with how we are finalizing applications in making health care primarily borne by the government, as the payer-to-payer data exchange decisions. Such patients will maintain are some premium costs for enrollees of requirement for MA organizations at 42 the same access that they have to their QHP issuers on the FFEs who receive CFR 422.119(f), Medicaid managed care personal health information today. This premium tax credits. We believe that the plans at § 438.62(b)(1)(vi) (made regulation does not change any existing benefits created by the Patient Access applicable to CHIP managed care patient information rights. This API outweigh the costs to patients if entities through incorporation in regulation simply adds new options to payers choose to increase premiums as § 457.1216), and QHP issuers on the ensure patients have the information a result. FFEs at 45 CFR 156.221(f). Aligning the they need, when, and how they need it. At this time, we are not able to offer years of data available through the Comment: Several commenters support for the implementation of this Patient Access API with the payer-to- indicated concerns over what they policy through federal grant funding. payer data exchange will minimize cost believe would be a costly Regarding costs for Medicaid managed and burden specific to this regulatory implementation. A few commenters care plans—since the Patient Access requirement and will provide patients questioned who would be required to API requirements must be contractual with the same timeframe of information bear the costs of implementation and obligations under the Medicaid as payers, furthering transparency. maintenance of the APIs, with one managed care contract—the state must Together these policies facilitate the commenter requesting CMS explicitly include these costs in the development creation and maintenance of a patient’s permit payers to charge patients and of a plan’s capitation rates. These cumulative health record with their other third-party partners for the costs capitation rates would be matched at the current payer. of API implementation and state’s medical assistance match rate. We do not believe limiting the Patient maintenance. In contrast, a few State Medicaid agency implementation Access API to data only from January 1, commenters recommended that payers costs would be shared by the state and 2019 forward is sufficient to help should not be allowed to charge patients federal government, based on the patients most benefit from this data to access their information through relevant level of Federal Financial availability. However, we do appreciate APIs. A few commenters requested CMS Participation, which is 50 percent for that making older data available for provide federal grant funding to support general administrative costs and 90 electronic data exchange via the Patient payers in implementing the proposed percent for system development costs. Access API is part of the cost of the API. APIs. Comment: A few commenters As a result, limiting this to data with a Response: We appreciate the described concerns with the maturity of date of service of January 1, 2016 commenters’ concerns and APIs for data exchange, as well as the forward minimizes cost and burden fact that implementation of FHIR-based while maximizing patient benefit. 28 Pew Research Center. (2019, June 12). APIs is so new in health care, and Comment: A few commenters Retrieved from https://www.pewinternet.org/fact- expressed that they believed there were expressed concerns and indicated that sheet/mobile. challenges with meeting the proposed they did not believe the Patient Access 29 Ryan, C. (2018). Computer and internet Use in requirement given the newness of the the United States: 2016 (American Community API proposal would move the health Survey Reports, ACS–39). Retrieved from https:// needed standards, particularly regarding care industry toward the stated goal of www.census.gov/content/dam/Census/library/ standardizing the required data helping patients make more informed publications/2018/acs/ACS-39.pdf. elements and vocabularies. Several

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00020 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25529

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00022 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25531

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00024 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25533

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00026 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25535

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00028 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25537

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00030 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25539

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00032 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25541

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00034 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25543

Commenters believed third parties prerogative to provide their data to a would need to be appropriate security should be charged a fee to maintain the third-party in order to get a service in tokens in place between the two parties API. One commenter expressed concern exchange. Being sure patients are as engaged in the data exchange. that the business model of the third- informed as possible about secondary Response: We appreciate the party applications hinges on their uses of data and how this may impact commenters’ concerns. We note, ability to sell the data they collect for them is important. As a result, we however, that making the secondary uses while payers and discuss this issue more below. documentation available publicly does providers would be required to provide Comment: Some commenters not impact the security of the standards- information to vendors absent a fee. indicated support for permitting access based API itself. This level of This commenter argued that charging to documentation without access fees, transparency is common in other third-party vendors a fee for citing concern that the fees would be industries and across standards, and has documentation could be one way for extended to consumers as well as been shown to lead to innovation and vendors to absorb some of the cost of logistical concerns for how they would competition. HL7 is built on free and maintaining the API in exchange for the be paid. A few commenters specifically open documentation to ensure that all data they could potentially use to make recommended alignment with the ONC developers can equally access a profit. 21st Century Cures Act proposed rule information. Reviewing the Response: We also appreciate the API documentation requirement by documentation available for FHIR is one concerns raised around the secondary using the language included in the way of appreciating the value of this uses of data shared with third-parties. discussion of the proposed requirement information and how having it freely We note that under section 5 of the FTC at 45 CFR 170.315(g)(10) stating that the accessible can allow innovators to Act (15 U.S.C. Sec. 45(a)), it is documentation should be ‘‘accessible to engage with health care data in the most considered a deceptive act to use a the public via a hyperlink without meaningful ways.32 Having access to the person’s sensitive information without additional access requirements, documentation is not the same as access disclosing in product documentation including, without limitation, any form to the actual API for the purposes of how this information will be shared.31 of registration, account creation, ‘click- data exchange. In addition, we do not believe that through’ agreements, or requirement to Appreciating the comments received charging a fee to access API provide contact details or other and the need to have documentation documentation is appropriate to offset information prior to accessing the available to ensure successful secondary data use concerns. We refer documentation’’ (84 FR 7484). implementation and use of the Patient readers to the additional discussion Response: We do appreciate the Access API, we are finalizing our below regarding informing patients requests to explicitly state what we proposal to make publicly accessible about potential secondary uses of data. mean by ‘‘public access’’ and ensure it documentation that includes, at a The data that must be shared via the is clear this does not permit any minimum: (1) API syntax, function API under this policy are data that the additional restrictions or fees. As a names, required and optional payers have and must currently share result, to further align with the parameters supported and their data with patients under existing law. The discussion in the ONC 21st Century types, return variables and their types/ public directory data is already public Cures Act proposed rule (84 FR 7477), structures, exceptions and exception information. We do not believe it is and the CMS Interoperability and handling methods and their returns; (2) appropriate to charge a fee for Patient Access proposed rule (84 FR The software components and documentation required to access such 7620), we are finalizing regulation text configurations an application must use available data. Taking the example of stating that ‘‘publicly accessible’’ means in order to successfully interact with the provider directory data raised by we expect that any person using API and process its response(s); and (3) commenters, currently there are vendors commonly available technology to All applicable technical requirements that collect the publicly available browse the internet could access the and attributes necessary for an directory data, clean these data, information without any preconditions application to be registered with any supplement these data, and offer this or additional steps, such as a fee for authorization server(s) deployed in enhanced data product back to payers access to the documentation; a conjunction with the API. As noted, we and providers. It is not the data the requirement to receive a copy of the have made one modification by adding vendors are charging for as much as it material via email; a requirement to the definition of ‘‘publicly accessible’’ is the service of cleaning and enhancing register or create an account to receive to the relevant regulation text. these data. Vendors may generate the documentation; or a requirement to revenue from their third-party apps, but read promotional material or agree to e. Routine Testing and Monitoring of a major component of this is the service receive future communications from the Standards-Based APIs they are providing—building the app, organization making the documentation At 42 CFR 422.119(c)(2), 431.60(c)(2), making the data the patient directs to available. We are finalizing this 457.730(c)(2), and 45 CFR 156.221(c)(2) them most usable and valuable—that requirement at 42 CFR 422.119(d), for MA organizations, state Medicaid generates the revenue. Payers must 431.60(d), 438.242(b)(5) (through cross- and CHIP FFS programs, and QHP already make these data available to reference to Medicaid FFS), 457.730(d), issuers on the FFEs, respectively, we patients. These data alone may also 457.1233(d)(2) (through cross-reference proposed that the API must be routinely drive revenue, but it is the patient’s to CHIP FFS), and 45 CFR 156.221(d). tested and monitored to ensure it is Comment: One commenter did not functioning properly, including 31 See also cases where this authority was used, support this documentation proposal for such as 2012 FTC action against Facebook (see assessments to verify that the API is security reasons as the commenter fully and successfully implementing https://www.ftc.gov/enforcement/cases- believed that if the documentation was proceedings/092-3184/facebook-inc), the 2012 FTC privacy and security features such as action against MySpace (see https://www.ftc.gov/ public, any third-party or organization but not limited to those required to enforcement/cases-proceedings/102-3058/myspace- could potentially call, or connect to, a llc-matter), and the 2017 FTC action against VIZIO payer’s API. This commenter preferred (see https://www.ftc.gov/enforcement/cases- 32 HL7 International. (n.d.). FHIR Overview. proceedings/162-3024/vizio-inc-vizio-inscape- an alternate approach where CMS Retrieved from https://www.hl7.org/fhir/ services-llc). stipulates in order to call an API, there overview.html.

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00036 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25545

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00037 Fmt 4701 Sfmt 4700 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 Collectively, HHS has been working to record of when and with whom their option that could significantly increase evaluate various technical specifications data have been shared via the API. security. for data segmentation to enhance Comment: Many commenters Though we appreciate commenters’ privacy protections and comply with expressed concerns over the complexity requests to leave flexibility here, we do applicable law (such as laws regarding with parsing or segmenting electronic believe adopting the standards as privacy for minors or 42 CFR part 2). health information that is considered finalized by HHS in ONC’s 21st Century Both HHS and the industry as a whole sensitive and/or is subject to 42 CFR Cures Act final rule regarding the use of are currently evaluating future use cases part 2 rules. Commenters requested the SMART IG (using the OAuth 2.0 related to segmenting data at the patient CMS take into account these situations standard) and OpenID Connect Core 1.0 request. At this time, however, the with these API proposals and cited use is an important starting point. In policies as they are being finalized cases such as women’s health, sexual addition, we note that the technical under this rule require that the payers, health, young adult health, mental standards at 45 CFR 170.215 address the with the approval and at the direction health, and substance abuse treatment. comments regarding tokens, as HHS is of the patient, provide all of the data as A few commenters noted concerns that finalizing use of tokens at 45 CFR specified in the applicable regulation some health care providers may 170.215 as part of the SMART IG. We text. Beyond this, payers, providers, and discriminate or treat a patient note that ONC is requiring that a token patients cannot direct specific segments differently if they were able to access be valid for at least 3 months for of data be made available via this certain patient’s health information. A certified health IT; we encourage payers Patient Access API. The necessary few commenters recommended that subject to this final rule to align with technical specifications to allow a HHS align part 2 and HIPAA this best practice. We appreciate patient to request some data elements be regulations. One commenter recommendations for a centralized shared but not others are not widely recommended the use of the solution to patient authentication and adopted.33 If the patient requests their Consent2Share (C2S) FHIR Consent identity proofing, and caregiver access, data via the Patient Access API from a Profile developed by SAMHSA. Another and will take these under consideration payer, the payer must make available all commenter suggested CMS defer as appropriate. of the data allowed per current law, adoption of the Data Segmentation for Comment: Many commenters such as 42 CFR part 2 and relevant state Privacy standards until an API FHIR expressed that patients should have laws, including the data as specified in standard version is finalized and the ultimate authority and the ability to this final rule. We reiterate, however, Consent2Share guide is revised to consent to what type of information can that the data that are available to be conform to that version. be shared as well as who can access shared are only to be shared at the Response: We appreciate the their health information. One patient’s request. If there are data commenters concerns and commenter recommended CMS require elements the patient does not want to be recommendations. We are currently that patients have the ability to filter or shared, they can choose not to make the evaluating future options around request only the specific data that they request. In addition, we note that this parsing or segmenting data, generally, want to be shared. One commenter policy allows data to be exchanged from using the API. As noted above, HHS is requested that payers be able to access the payer to a third-party app of the collectively working to explore the specific types of data a patient patient’s choice for their personal use. standards and technical supports for authorized the app to access. One This rule does not require any data data segmentation for privacy and commenter added patients should also exchange directly between or with consent management and point have an accounting of disclosures or providers. commenters to the ONC 21st Century access to their data. Specifically regarding the comment Cures Act final rule for additional A few commenters expressed on sharing family history, we note that discussion on this. We also note that concerns over the sharing of patient the health information required to be using the appropriate FHIR profiles, electronic health information with shared under this policy includes such as those being finalized by HHS in health care providers that the patient claims and encounter data as well as the the ONC 21st Century Cures Act final has not consented to share with. A few data included in the USCDI version 1. rule (published elsewhere in this issue commenters expressed specific concerns At this time, ‘‘family history’’ is not a of the Federal Register) for API with sharing electronic health specific data class within the USCDI. As technical standards, including the information beyond the immediate a result, we do not believe this should SMART IG (using the OAuth 2.0 health care provider, such as with be an issue under this current policy. standard) and OpenID Connect as providers with which a patient may be We will, however, take this into finalized at 45 CFR 170.215, can be seeking a second opinion or additional consideration as we consider future leveraged to support this. Again, we care. One commenter was concerned policy options. note that additional information and with the sharing of family health history We appreciate the recommendation implementation guidance can be found data particularly for family members for patients to have a full record of at http://hl7.org/fhir/smart-app-launch/. who have not consented. disclosures or access to their health However, we reiterate that payers’ A few commenters recommended that information via the API. At present, the privacy and security obligations under providers be able to pre-filter or select HIPAA Privacy Rule requires the HIPAA Rules and 42 CFR part 2 are which data can be made available to the accountings of certain disclosures. not impacted by this final rule. patient, citing concerns with the Consistent with the spirit of this Comment: A few commenters sensitivity of some provider notes or accounting of disclosures, we encourage expressed particular concern for patient confusion in interpreting certain payers to consider setting up appropriate authorization of parent/ information. A few commenters also functionality to allow patients to view a guardian proxies for minor patients. suggested that providers be able to One commenter recommended CMS select which information can be made 33 For information on adoption levels for align the CMS Interoperability and technical specifications related to data Patient Access proposed rule with the available to the payer. segmentation, see the Interoperability Standards Response: We appreciate the Advisory at https://www.healthit.gov/isa/data- Children’s Online Privacy Protection commenters’ concerns and suggestions. segmentation-sensitive-information. Act (COPPA), which was created to

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00038 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25547

protect the privacy of children under 13 g. Issues Related to Denial or application’s connection to the API and has been in effect since 2000. Discontinuation of Access to the API when it makes a similar determination Response: We appreciate the We believe patients have a right to about risk to its systems. However, commenters concerns and their health information. However, a depending on how the organization’s systems are designed and configured, recommendations, which we are covered entity is not expected to tolerate we recognize that the criteria and reviewing for future possible unacceptable levels of risk to the PHI tolerable risk levels appropriate to consideration in regulation. We note held by the covered entity in its systems, as determined by its own risk assessing an application for connection that this current regulation does not to an API for access to publicly available change any existing privacy analysis. Accordingly, it may be appropriate for an organization to deny information may differ from those relationships between minors and required for API access to non- or terminate specific applications’ parents. If, for instance, a teenage minor published personally identifiable connection to its API under certain has asserted their protections to not information (PII). have their guardians see their circumstances in which the application We also anticipated that, where an Explanation of Benefits, the payer poses an unacceptable risk to the PHI on application’s connection has been its systems. would be obligated to maintain these terminated under these circumstances, At 42 CFR 422.119(e), § 431.60(e), it might be feasible in some instances protections when sharing data via the 438.242(b)(6) (redesignated as for the organization to allow the API. For non-minor dependents, again § 438.242(b)(5) in this rule; see section the existing policies hold true. application to reconnect to the API if VI.), 457.730(e), 457.1233(d)(2) and 45 and when the flaw or compromise of the Regarding privacy in an enrollment CFR 156.221(e) for MA organizations, application has been addressed group, at this time, a policyholder can state Medicaid and CHIP FFS programs, sufficiently that the organization can no see the claims for all members of their Medicaid managed care plans, CHIP longer fairly say the application’s API enrollment group unless there is an managed care entities, and QHP issuers connection continues to pose an agreed upon privacy provision available on the FFEs, respectively, we proposed unacceptable risk. and in place. The HIPAA Privacy Rule to specify the circumstances under We summarize the public comments states at 45 CFR 164.522 that which these regulated entities, which we received on denial or individuals have a right to request are all HIPAA covered entities subject to discontinuation of service and provide restrictions on how a covered entity will HIPAA privacy and security our responses. use and disclose protected health requirements, may decline to establish Comment: Several commenters information about them for treatment, or may terminate a third-party supported the proposal to allow payers payment, and health care operations. application’s connection to the covered to deny or discontinue access to apps However, a covered entity is not entity’s API while remaining in that pose security risks. One commenter compliance with the proposed generally required to agree to an specifically supported that the proposal requirement to offer patients access individual’s request for a restriction does not allow payers to deny requests through standards-based APIs. We noted unless certain limited exceptions are based on concerns about the worthiness in the CMS Interoperability and Patient of the third-party as a recipient of PHI, met 34, but is bound by any restrictions Access proposed rule that we intended because patients have the right to share to which it does agree. After the for the proposal to be consistent with their health information with the app Affordable Care Act extended the age the HIPAA Rules, and we noted that they choose. that group health plans and issuers of these circumstances apply to specific Several commenters encouraged CMS health insurance coverage in the group applications, rather than the third party to develop and/or further define or individual market that offer itself (84 FR 7635 through 7636). guidelines for identifying ‘‘unacceptable dependent coverage of children must Specifically, we proposed that a payer risk’’ and establish a clearer standard for continue to make such coverage subject to our API proposal could deny acceptable circumstances when API available to adult children until age 26, access to the API if the payer reasonably access can be restricted or denied. A few some states, including California, determined that allowing that commenters expressed concerns that the Colorado, Washington, Oregon, and application to connect or remain proposed requirements may be Maryland, have enacted stricter connected to the API would present an interpreted differently among payers, protections regarding privacy rights, and unacceptable level of risk to the security apps, users, and providers. One although all of these states operate their of PHI on the payer’s systems. We commenter expressed concern because own SBEs and issuers on these further proposed that this determination payers are liable for breaches that occur Exchanges are not implicated in this would be made consistent with the during data exchange and the rule, to the extent issuers are operating payer’s HIPAA Security Rule obligations commenter does not believe the in both these and FFE states and have and based on objective, verifiable proposal provides clear authority to applied their privacy policies across criteria that would be applied fairly and deny access based on such security concerns. A few commenters requested markets, consumers in FFE states may consistently across all applications through which enrollees seek to access that CMS provide more information also benefit from these stricter their electronic health information as regarding whether payers may delay protections. This final rule does not defined at 45 CFR 171.102, including and/or deny certain apps that are alter obligations under any existing but not limited to criteria that may rely suspected, or proven to be bad actors. federal, state, local, or tribal law. Again, on automated monitoring and risk One commenter requested that CMS we note that this data sharing is mitigation tools. make the distinction between the risk currently ongoing; the API just provides Where we proposed to require access posed by providing PHI and providing an additional way to facilitate this through standards-based APIs to other widely available payer data. A few exchange. otherwise publicly available commenters requested CMS define a information, such as provider time period for how long the ban on 34 See 45 CFR 154.522(a)(1)(vi) for a discussion of directories, the entities subject to the access may remain in place. One the limited exceptions. proposal may also deny or terminate an commenter sought additional

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00039 Fmt 4701 Sfmt 4700 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 this assessment must be based on cannot be validated. One commenter able to deny third-party access across objective, verifiable criteria in stated the payers should be able to the board for all patient queries and accordance with obligations under the refuse to connect to non-vetted apps. plans. A few commenters suggested that HIPAA Security Rule. Having Another commenter stated that payers CMS should develop a clear process for considered comments, we are finalizing should be able to restrict access if the app developers to follow in the event that payers may deny or discontinue information exchanged is not permitted that a covered entity denies access to an any third-party application’s connection under the HIPAA Privacy Rule or if the API. A few commenters recommended to their API if the payer reasonably exchange or use would compromise the that CMS include in the final rule a determines, consistent with its security confidentiality, integrity, and reference to ONC’s information blocking analysis under 45 CFR part 164 subpart availability of the information. One definition and clarify that unacceptable C, that allowing an application to commenter recommended that CMS levels of risk could be an exception to connect or remain connected to the API allow covered entities to remove an app would present an unacceptable level of information blocking. from their system if the app does not Response: We appreciate the risk to the security of protected health follow the approved privacy policy. One commenters’ concerns. As discussed in information on the payer’s systems or in the CMS Interoperability and Patient transit in instances in which the commenter recommended that Access proposed rule, the criteria and individual did not tell the payer to providers should be allowed to require process for assessing unacceptable risk disregard in-transit risk. For example, a business associate agreement (BAA) to a payer’s system are part of the where an individual requests that their with third-party app developers that payer’s responsibilities under the unencrypted ePHI be transmitted to an connect to the API required under this HIPAA Security Rule (84 FR 7635). The app, the payer would not be responsible final rule. One commenter suggested HIPAA Security Rule requires a covered for unauthorized access to the allowing restrictions on data mining. entity to perform risk analysis as part of individual’s ePHI while in transmission However, one commenter expressed its security management processes.35 to the app. When access has been concern that payers may place HHS makes a number of tools available denied or discontinued due to security unnecessary barriers and burdens on to assess risk.36 Additional tools are concerns, we encourage payers and third-party app developers. The available through the National Institute third parties to work together to address commenter encouraged CMS to ensure of Standards and Technology (NIST).37 the concerns if and as possible to best that payers cannot place additional We note that this policy regarding serve patients. We are not able to set a constraints on apps, such as requiring a denial or discontinuation of service specific time period or process for this BAA, additional security audits, or refers to a payer’s determination that as it is beyond our authority, however, requiring that apps make commitments allowing access to their API by a third we do note that the HIPAA Privacy Rule about how it will or will not use the party would result in risk to their requires access to be provided to the information patients store on it. system. As also noted previously, individual in a timely manner. Response: We appreciate the covered entities, in accordance with Regarding information blocking, we commenters’ recommendations. HIPAA privacy and security obligations, refer readers to the ONC 21st Century Specifically, regarding the ability to should take reasonable measures to Cures Act final rule (published protect data in transit, unless an elsewhere in this issue of the Federal deny access to a third-party app, we are individual expressly asks that the Register). finalizing this policy as proposed with information be conveyed in an unsecure Comment: One commenter requested one modification to add additional form or format (assuming the individual that CMS indicate whether third-party clarity around what it means to was warned of and accepted the risks applications will be subject to HIPAA or reasonably determine risk. As such, and associated with the unsecure FTC regulations. One commenter as noted above, we are finalizing that transmission). As explained in this requested information about whether payers may deny or discontinue any section above, it is the responsibility of patients will be able to terminate third- third-party application’s connection to payers to assess the risk to their system party access to their health data. their API if the payer reasonably and act accordingly regardless of Response: We appreciate the determines, consistent with its security whether the data being accessed via the commenters’ request for more analysis under 45 CFR part 164 subpart API is PHI or not. If the concern is the information. We refer commenters to C, that allowing an application to security of the payer’s system, the type OCR and FTC for additional information connect or remain connected to the API of data being transferred is not at issue. about jurisdiction over third-party apps. would present an unacceptable level of Absent an individual’s instruction to We do note, as discussed earlier, that risk to the security of protected health disregard in-transit security, if while under section 5 of the FTC Act (15 information on the payer’s systems and assessing the security of the app’s U.S.C. Sec. 45(a)), the FTC does regulate the payer makes this determination connection to the API, the covered such third-party apps. Regarding a using objective, verifiable criteria that entity determines the data could be patient’s ability to terminate third-party are applied fairly and consistently access, this would be something compromised in transit, the payer could across all applications and developers. determined in the terms and conditions discontinue or deny access in order to As patients have a right to their data and of each app. project the ePHI on its system. Again, Comment: A few commenters this proposal provides the payers the recommended that covered payers ability to appropriately protect their 35 45 CFR 164.308(a)1)(ii)(A). should have the flexibility to establish systems and the data they hold on it, we 36 For more information, see https:// do not believe any additional www.hhs.gov/hipaa/for-professionals/security/ additional terms and conditions when index.html. denying third-party applications access restrictions are needed at this time. We 37 Brooks, S., Garcia, M., Lefkovitz, Ligthman, S., to their systems. One commenter stated also note it would not be appropriate to & Nadeau, E. (2017, January). NISTIR 8062 that payers should be able to develop require a patient-designated third party An Introduction to Privacy Engineering and Risk their own validation process for to enter into a BAA with a payer as the Management in Federal Systems. Retrieved from API-facilitated exchange is taking place https://nvlpubs.nist.gov/nistpubs/ir/2017/ enrollees and have the right to not NIST.IR.8062.pdf. release the data where the full scope per the request of the patient and not by,

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00040 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25549

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00041 Fmt 4701 Sfmt 4700 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 should make it clear that the app has current and former enrollees certain are not required to, ask a third-party app not attested to having the basic privacy information about: factors to consider in to attest that: and security protections and indicate selecting a health information • The app has a publicly available what those are, and that the patient management application, practical privacy policy, written in plain should exercise caution before opting to strategies to help them safeguard the language,39 that has been affirmatively disclose their information to the app. If privacy and security of their data, and shared with the patient prior to the the patient still requests the payer make how to submit complaints to OCR or patient authorizing app access to their their data available to the third-party FTC. The proposed obligations would health information. To ‘‘affirmatively app, the payer must provide API access apply to Medicaid managed care plans share’’ means that the patient had to to the app unless doing so would and CHIP managed care entities through take an action to indicate they saw the endanger the security of PHI on the cross-references proposed in 42 CFR privacy policy, such as click or check a payer’s systems. This process should 438.242(b)(6) (finalized as box or boxes. not overly delay the patient’s access. If § 438.242(b)(5) in this final rule; see • The app’s privacy policy includes, the app does not attest positively or at section VI. of this final rule) and at a minimum, the following important all, the payer must work to quickly § 457.1233(d)(2). information: inform the patient and provide a short The general information about the ++ How a patient’s health information window for the patient to cancel their steps individuals can take to help may be accessed, exchanged, or used by request the data be shared. If the patient protect the privacy and security of their any person or other entity, including does not actively respond, the payer health information should not be whether the patient’s health information must move forward as the patient has limited to, but should specifically may be shared or sold at any time already directed their data be shared include and emphasize the importance (including in the future); and this initial request must be honored. of understanding the privacy and ++ A requirement for express consent We believe it is important for patients security practices of any application to from a patient before the patient’s health to have a clear understanding of how which they entrust their data. information is accessed, exchanged, or their health information may be used by Information about submitting used, including receiving express a third-party, as well as how to stop complaints should include both specific consent before a patient’s health sharing their health information with a contact information for the OCR and information is shared or sold (other than third-party, if they so choose. We FTC complaints processes and a brief disclosures required by law or believe the use of this attestation, in overview, in simple and easy-to- disclosures necessary in connection combination with patient education, understand language, of: What with the sale of the application or a will help patients be as informed as organizations are HIPAA covered similar transaction); possible while providing payers with a entities, OCR’s responsibility to oversee ++ If an app will access any other lower burden vetting option. We believe compliance with HIPAA, and FTC’s information from a patient’s device; or this will better help protect patient complementary responsibility to take ++ How a patient can discontinue app privacy and security and mitigate many action against unfair or deceptive access to their data and what the app’s of the concerns raised. Together, this practices, including by non-covered policy and process is for disposing of a framework and the requirement for entities that may offer direct-to- patient’s data once the patient has payers to provide patients with consumer health information withdrawn consent. educational resources will help management applications. Payers can look to industry best continue to move us toward a safer data We proposed that this information practices, including the CARIN exchange environment. This is a critical must be made available on the website Alliance’s Code of Conduct 40 and the focus for CMS, and we look forward to of the payers subject to the proposed ONC Model Privacy Notice41 for other continuing to work with stakeholders to requirement, and through other provisions to include in their attestation keep patient privacy and data security a appropriate mechanisms through which request that best meet the needs of their top priority. the payer ordinarily communicates with patient population. If a payer chooses to enrollees that are seeking to access their h. Enrollee and Beneficiary Resources health information held by the payer. request third-party apps provide this Regarding Privacy and Security attestation, the payer must not This could include customer portals, discriminate in its implementation, As discussed in section II.A. of the online customer service help desks, and including for the purposes of CMS Interoperability and Patient Access other locations, such as any portals competitive advantage. Specifically, if a proposed rule (84 FR 7618 through through which enrollees and former payer requests this attestation of one 7623), we are committed to maximizing enrollees might request disclosure of app, it must request it of all apps that enrollees’ access to and control over their data to a third-party application seek to obtain data. If the third-party their health information. We noted that through the payer’s API. We also app does not attest that their privacy we believed this calls for providing proposed that the payer must make this policy meets the provisions indicated by enrollees that would access data under information available in non-technical, the payer, the payer may inform patients the proposal with essential information simple, and easy to understand that the app did not attest and advise about the privacy and security of their language. them to reconsider using this third-party information, and what to do if they We explained in the proposed rule how we anticipate that payers could app. The notification to the patient believe they have been misled or deceived about an application’s terms of meet the requirement to provide 39 Plain Language Action and Information use or privacy policy. information to current and former Network. (2011, May). Federal Plain Language At 42 CFR 422.119(g), 431.60(f), and enrollees in whole or in part using Guidelines. Retrieved from https:// 457.730(f), and 45 CFR 156.221(g), we materials designed for consumer www.plainlanguage.gov/media/FederalPL proposed to require MA organizations, audiences that are available on the HHS Guidelines.pdf. state Medicaid and CHIP FFS programs, website. However, we noted that 40 See https://www.carinalliance.com/our-work/ trust-framework-and-code-of-conduct/. Medicaid managed care plans, CHIP whether the organization chooses to 41 See https://www.healthit.gov/topic/privacy- managed care entities, and QHP issuers draft its own resource materials to security-and-hipaa/model-privacy-notice-mpn. on the FFEs, to make available to their provide the required information or to

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00042 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25551

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00044 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25553

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00046 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25555

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00047 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25556 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00048 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25557

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00050 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25559

change for readability only at 42 CFR on or after January 1, 2016, consistent arise. For example, such information 422.119(c)(3) and (4)(ii)(C), 431.60(c)(3) with the payer-to-payer data exchange might include hours of operation, and (4)(ii)(C), 438.242(b)(5), requirement discussed in section V. of languages spoken, specialty/services, 457.730(c)(3) and (4)(ii)(C), this final rule. and availability for new patients. 457.1233(d)(1), and 45 CFR IV. API Access to Published Provider Provider directories also function as a 156.221(c)(3) and (4)(ii)(C). In addition, Directory Data Provisions, and Analysis resource used by the provider we have refined the language at 42 CFR of and Responses to Public Comments community to discover contact 422.119(g), 431.60(f), and 457.730(f), information of other providers to and 45 CFR 156.221(g) to state the payer A. Interoperability Background and Use facilitate referrals, transitions of care, must make education materials Cases and care coordination for enrollees. available ‘‘in an easily accessible In section III. of the CMS As discussed in the CMS location on its public website,’’ and at Interoperability and Patient Access 42 CFR 422.119(g)(1), 431.60(f)(1), and Interoperability and Patient Access proposed rule (84 FR 7626 through proposed rule, the current applicable 457.730(f)(1), and 45 CFR 156.221(g)(1) 7639), we focused on patient access to to include a reference to ‘‘secondary regulations for MA plans (42 CFR their own data through a standardized, 422.111) and Medicaid and CHIP uses of data.’’ transparent API—the Patient Access At 42 CFR 422.119(d), 431.60(d), managed care plans (42 CFR API. As part of this proposal, we 457.730(d), and 45 CFR 156.221(d), we 438.10(e)(2)(vi) and (h) and 457.1207, discussed and sought comment on are finalizing additional text to specify respectively) already require that requiring payers at 42 CFR that ‘‘publicly accessible’’ means that provider directories be made available 422.119(b)(1)(iii) and (b)(2)(ii) for MA any person using commonly available to enrollees and potential enrollees in technology to browse the internet could organizations, 42 CFR 431.60(b)(3) for Medicaid FFS programs, 42 CFR hard copy and on the plan’s website. access the information without any Section 1902(a)(83) of the Act requires preconditions or additional steps, such 438.242(b)(6)(ii) for Medicaid managed care plans, 42 CFR 457.730(b)(3) for state Medicaid agencies to publish a as a fee for access to the documentation; directory of certain physicians on the a requirement to receive a copy of the CHIP FFS programs, and 42 CFR 457.1233(d)(2)(ii) for CHIP managed public website of the State agency. A material via email; a requirement to regulation for QHP issuers (45 CFR register or create an account to receive care entities to provide their provider directory information through that same 156.230(b)) requires public access to the the documentation; or a requirement to QHP’s provider directory in addition to read promotional material or agree to Patient Access API. In addition, the distribution and access for enrollees. In receive future communications from the proposed rule sought comment on addition to mandating that this organization making the documentation making the provider directory available. information available through a public- information be accessible, the current In the CMS Interoperability and facing standards-based API. As we regulations also address the content of Patient Access proposed rule, the discussed in the CMS Interoperability such directories and the format and criteria and process for assessing and Patient Access proposed rule (84 FR manner in which MA plans, Medicaid unacceptable risk to a payers system 7639), making provider directory managed care plans, CHIP managed care was explained as part of the payer’s information available through a public- entities, and QHP issuers on the FFEs responsibilities under the HIPAA facing API raised different issues than must make the information available. Security Rule (84 FR 7635). At 42 CFR API access proposals related to patient Making this required provider 422.119(e)(1), 431.60(e)(1), data. Based on our consideration of directory information available to 438.242(b)(5), 457.730(e)(1), and public comments summarized and enrollees and prospective enrollees 457.1233(d), as well as 45 CFR responded to below, and in an effort to through an API could support 156.221(e)(1) we are finalizing avoid duplicative effort and additional development of third-party software additional text to note that payers burden resulting from having the applications, or apps, (whether provider directory information included should determine risk consistent with standalone or integrated with providers’ in both the Patient Access API and the its security risk analysis under 45 CFR EHR technology) that would pull in Provider Directory API, we are part 164 subpart C to indicate the current information about available finalizing the requirement for a public- specific section of the HIPAA Security providers to meet enrollees’ current facing Provider Directory API at 42 CFR Rule implicated here. We are modifying needs. Broad availability of provider 45 CFR 156.221(h)(2) to remove the 422.120 for MA organizations, 42 CFR directory data through interoperable API reference to ‘‘qualified employers’’ and 431.70 for Medicaid FFS programs, 42 technology would also allow for 45 CFR 156.221(i) to include CFR 438.242(b)(6) for Medicaid innovation in applications or other applicability to ‘‘individual market’’ managed care plans, 42 CFR 457.760 for FFEs to exclude issuers offering plans CHIP FFS programs, and 42 CFR services that help enrollees and through the FF–SHOPs. Finally, we are 457.1233(d)(3) for CHIP managed care prospective enrollees to more easily finalizing for MA organizations at 42 entities, but we will not finalize our compare provider networks while they CFR 422.119(h), Medicaid FFS programs proposal to also provide access to this are considering their options for at 42 CFR 431.60(g), Medicaid managed provider directory information through changing health plans. Finally, we care plans at 42 CFR 438.62(b)(1)(vii), the Patient Access API at 422.119, 42 noted in our proposal that a consistent, CHIP FFS programs at 42 CFR CFR 431.60, 42 CFR 438.242(b)(6), 42 FHIR-based API-driven approach to 457.730(g), CHIP managed care entities CFR 457.730, and 42 CFR making provider directory data at 42 CFR 457.1233(d), that beginning 457.1233(d)(2), respectively. accessible could reduce provider burden January 1, 2021, and for QHP issuers on Provider directories make key by enabling payers to more widely share the FFEs at 45 CFR 156.221(i) beginning information about health care basic information about the providers in with plan years beginning on or after professionals and organizations their networks, such as provider type, January 1, 2021, these payers must make available to help consumers identify a specialty, contact information, and available through the Patient Access API provider when they enroll in an whether or not they are accepting new data they maintain with a date of service insurance plan or as new health needs patients.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00051 Fmt 4701 Sfmt 4700 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 confirming individuals’ authorization or other coverage issues related to whether Directory Data request to disclose their personal providers are in or out-of-network. Response: We thank commenters for In sections III.C. and IV. of the CMS information to a specific application their support. Appreciating that Interoperability and Patient Access through an API, namely the SMART IG provider information is already publicly proposed rule (84 FR 7633, 7639 (using the OAuth 2.0 standard) and available, and unlike the other through 7642), we proposed to require OpenID Connect Core 1.0, should not information included in the Patient at 42 CFR 422.119(b)(1)(iii) for MA apply to our proposed public access to Access API discussed in section III. of organizations, 42 CFR 431.60(b)(3) for provider directory information through APIs (84 FR 7639). We noted that while this final rule, is of a less sensitive Medicaid FFS programs, 42 CFR nature, to avoid potential confusion and 438.242(b)(6)(ii) for Medicaid managed we were aware the organization will nevertheless need to take appropriate reduce burden resulting from having the care plans, 42 CFR 457.730(b)(3) for provider directory information included CHIP FFS programs, and 42 CFR steps to mitigate the potential security risks of allowing any application to in both the Patient Access API and the 457.1233(d)(2)(ii) for CHIP managed Provider Directory API, we are only care entities that payers subject to the connect to the API through which it offers provider directory access, we requiring that one API—the Provider proposed rule make standardized Directory API—provide access to information about their provider emphasized that these steps should be appropriate to the level of risk provider directory information. As a networks available through API result, we are finalizing additional technology, so that the public, including associated with the specific use case of accessing otherwise public information regulation text to require the Provider third-party app developers and patients, Directory API at 42 CFR 422.120 for MA could access and use that information, through API technology. We also noted that those wishing to access these data organizations; at 42 CFR 431.70 for including republishing the information Medicaid state agencies; at 42 CFR or information derived from that should not be unduly burdened by security protocols that are not necessary 438.242(b)(6) for managed care plans; at information in a user-friendly way. As 42 CFR 457.760 for CHIP state agencies; discussed in the preamble of the CMS to provide the appropriate degree of protection for the organization’s systems and at 42 CFR 457.1233(d)(3) for CHIP Interoperability and Patient Access managed care entities. This Provider proposed rule, we sought comment on and data. As referenced in sections II. and III. of Directory API must include the same making provider directory information information about the provider directory more generally available (84 FR 7639 the CMS Interoperability and Patient Access proposed rule (84 FR 7618 as originally proposed for the Patient through 7642). We discussed requiring Access API. Specifically, the Provider that the API technology conform to the through 7639), we intended to develop additional guidance, incorporating Directory API must include provider API standards proposed by ONC for directory data on a payer’s network of feedback from industry that provides HHS adoption at 45 CFR 170.215 (84 FR contracted providers, including names, implementation best practices relevant 7589). Currently, because QHP issuers addresses, phone numbers, and to FHIR-conformant standards-based on the FFEs are already required to specialties, updated no later than 30 APIs to help organizations subject to the make provider directory information calendar days after a payer receives requirements proposed in this available in a specified, machine- provider directory information or rulemaking. To that end, we solicited readable format,42 we did not propose updates to provider directory comment on what specific resources that QHP issuers would have to make information. We are finalizing the would be most helpful to organizations provider directory information available applicable regulation text with the implementing APIs under requirements through an API. However, we requested phrase ‘‘complete and accurate’’ to information regarding whether this proposed in the proposed rule. emphasize our intent that the directory same requirement should apply to QHP We summarize all public comments data meet this standard. For MA issuers, or if such a requirement would we received on making provider organizations that offer MA–PD plans, be overly burdensome for them. We directory information available through the Provider Directory API must also thank commenters for their insights on an API—in terms of requiring a make available pharmacy directory data, this request for information and are dedicated, publicly accessible Provider we are specifying that the plans must reviewing the comments received for Directory API and more generally make available, at a minimum, inclusion in potential future sharing provider directory information pharmacy name, address, phone rulemaking. via an API, including as proposed under number, number of pharmacies in the We noted in the preamble of the the Patient Access API discussed in network, and mix (specifically the type proposed rule that, since this provider section III. of this final rule and provide of pharmacy, such as ‘‘retail directory information is already our responses. pharmacy’’). As with the provider available and accessible to enrollees Comment: Many commenters directory information, we are finalizing without cost to them under existing law, supported a requirement for MA that pharmacy directory information this information should be as accessible organizations, state Medicaid and CHIP must be updated no later than 30 through the API as it is required to be FFS programs, Medicaid managed care calendar days after the MA organization when posted on the organization’s plans, and CHIP managed care entities that offers the MA–PD plan receives websites. Therefore, we proposed that to make standardized information about pharmacy directory information or the technical standards proposed (now their provider networks available updates to pharmacy directory finalized) by HHS in the ONC 21st through API technology to current information. Century Cures Act final rule (published enrollees, prospective enrollees, and Comment: Some commenters elsewhere in this issue of the Federal possibly the general public. disagreed with the proposal. They stated Register) at 45 CFR 170.215 (specifically Commenters stated that they believe that payers are already required to make at paragraphs (a)(3) and (b)) that are accurate provider directory data will this information available and this specific to authenticating users and improve transparency and accessibility proposal could result in unnecessary of information regarding a provider’s duplication of effort and additional 42 Available at http://cmsgov.github.io/QHP- network status, which will help with costs. One commenter suggested CMS provider-formulary-APIs/developer/index.html. efforts to address surprise billing and provide an exemption for payers that are

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00052 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25561

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00054 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25563

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00055 Fmt 4701 Sfmt 4700 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 Cures Act proposed rule as the USCDI reference at 42 CFR 457.1216, the name, address, phone number, number (version 1) (84 FR 7441 through 7444). Medicaid managed care plan of pharmacies in the network, and mix Understanding that enrollees’ requirements codified at 42 CFR (specifically the type of pharmacy, such information is already exchanged 438.62(b)(1)(vi). Therefore, the proposal as ‘‘retail pharmacy’’), updating the between plans for use in carrying out for Medicaid managed care plans regulation text from the proposed rule, various plan functions,43 payers have described also applied to CHIP managed which simply stated ‘‘number, mix, and experience exchanging, receiving, and care entities even though we did not addresses of network pharmacies’’. All incorporating data from other plans into propose new regulation text in part 457. directory information must be available an enrollee’s record. We proposed We proposed that this new requirement through the API within 30 calendar days requiring the USCDI data set be would be applicable starting January 1, of a payer receiving the directory exchanged at the enrollee’s direction, 2020 for MA organizations, Medicaid information or an update to the and when received by a payer, managed care plans, CHIP managed care directory information. We note we have incorporated into the recipient payer’s entities, and beginning with plan years also revised the proposed regulation text data system. As proposed, upon request beginning on or after January 1, 2020 for for making directory information from an enrollee, the USCDI data set QHP issuers on the FFEs. Among other available through an API to specify would have to be sent to another payer topics related to the proposal, we consistently that the directory that covers the enrollee or a payer solicited comments on the proposed information must be complete and identified by the enrollee at any time date these policies would be applicable. accurate and that updates must be made during coverage or up to 5 years after We proposed to codify this new in ‘‘calendar’’ days. coverage ends, and the payer would requirement at 42 CFR 422.119(f) for The Provider Directory API is being have to receive the USCDI data set from MA organizations; at 42 CFR finalized at 42 CFR 422.120 for MA any payer that covered the enrollee 438.62(b)(1)(vi) for Medicaid managed organizations, at 42 CFR 431.70 for within the preceding 5 years. These care plans (and by extension under Medicaid state agencies, at 42 CFR proposals were intended to support existing rules at 42 CFR 457.1216, to 438.242(b)(6) for Medicaid managed patient directed coordination of care; CHIP managed care entities); and at 45 care plans, at 42 CFR 457.760 for CHIP that is, each of the payers subject to the CFR 156.221(f) for QHP issuers on the state agencies, and at 42 CFR requirement would be required to, upon FFEs. The proposed new requirement 457.1233(d)(3) for CHIP managed care an enrollee’s request: (1) Receive the was virtually identical for MA entities. We are finalizing that access to data set from another payer that had organizations, Medicaid managed care the published Provider Directory API covered the enrollee within the previous plans, CHIP managed care entities, and must be fully implemented by January 5 years; (2) send the data set at any time QHP issuers on the FFEs, with 1, 2021 for all payers subject to this new during an enrollee’s enrollment and up modifications in the proposal necessary requirement. We encourage payers to to 5 years later, to another payer that for specific payer types to account for implement this Provider Directory API currently covers the enrollee; and (3) the program needs of each. The as soon as they are able to make and send the data set at any time during proposed regulation text references the show progress toward the API enrollment or up to 5 years after content standard adopted at 45 CFR requirements in this final rule and to enrollment has ended to a recipient 170.213, which ONC proposed as the signal their commitment to making the identified by the enrollee. USCDI (version 1) data set (84 FR 7441 information that will empower their We identified in the proposed rule through 7444). We noted we believed patients easily accessible and usable. that this proposal is based on our that exchanging this data set would help Under this final rule, MA organizations, authority under sections 1856(b) and both enrollees and health care providers Medicaid and CHIP FFS programs, 1857(e) of the Act to adopt standards coordinate care and reduce Medicaid managed care plans, and CHIP and contract terms for MA plans; administrative burden to ensure that managed care entities must make the section 1902(a)(4) of the Act to adopt payers provide coordinated high-quality Provider Directory API accessible via a methods of administration for state care in an efficient and cost-effective public-facing digital endpoint on their Medicaid plans, including requirements way that protects program integrity. For website to ensure public discovery and for Medicaid managed care plans a full discussion of the benefits we access. (MCOs, PIHPs, and PAHPs); section anticipate from this data exchange 2101(a) of the Act for CHIP managed requirement, see the discussion in the V. The Health Information Exchange care entities (MCOs, PIHPs, and CMS Interoperability and Patient Access and Care Coordination Across Payers: PAHPs); and section 1311(e)(1)(B) of the proposed rule (84 FR 7640). Establishing a Coordination of Care Affordable Care Act for QHP issuers on In addition to the benefits for care Transaction To Communicate Between the FFEs. We explained in the CMS coordination at the payer level and Plans Provisions, and Analysis of and reduced provider burden, we noted that Responses To Public Comments Interoperability and Patient Access proposed rule our belief that the once the requested information, as We proposed a new requirement for proposal will help to reduce provider specified by the USCDI standard, was MA organizations, Medicaid managed burden and improve patient access to made available to the patient’s current care plans, CHIP managed care entities, their health information through plan, the enrollee would have access to and QHP issuers on the FFEs to require coordination of care between payers (84 multiple years of their health these payers to maintain a process to FR 7640 through 7642). We also noted information through the proposed coordinate care between payers by that the CHIP regulations incorporate Patient Access API, discussed in section exchanging, at a minimum, the USCDI and apply, through an existing cross- III.C. of the CMS Interoperability and at the enrollee’s request as specified in Patient Access proposed rule and in this the proposed regulation text. Instead of 43 See Office for Civil Rights. (2016, August 16). final rule. This is the case because the specifically proposing use of the USCDI, 3014–HIPAA and Health Plans—Uses and proposal required the receiving payer to we proposed use of a content standard Disclosures for Care Coordination and Continuity of incorporate the received data into its Care. Retrieved from https://www.hhs.gov/hipaa/ adopted by ONC at 45 CFR 170.213, for-professionals/faq/3014/uses-and-disclosures- records about the patient, therefore which was proposed in a companion for-care-coordination-and-continuity-of-care/ making these data the payer maintains, proposed rule, the ONC 21st Century index.html. and data available to share with the

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00056 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25565

patient via the Patient Access API. The We also proposed that a patient set. On behalf of HHS, ONC proposed to USCDI data set includes clinical data should be able to request his or her adopt the USCDI as a standard (84 FR points essential for care coordination. information from their prior payer up to 7441 through 7444), to be codified at 45 Access to these data would provide the 5 years after dis-enrollment, which is CFR 170.213, and the proposed patient with a more comprehensive considerably less than existing data regulation text cross-references this history of their medical care, helping retention policies for some of the regulation. These data exchanges would them to make better informed health payers.44 Further, we proposed that the provide the enrollee’s new payer with a care decisions. We sought comment on health information received as part of core set of data that could be used to how plans might combine records and the USCDI (version 1) data set under our support better care coordination and address error reconciliation or other proposal would have to be incorporated improved outcomes for the enrollee. We factors in establishing a more into the IT and data systems of each considered requiring plans to exchange longitudinal record for each patient. payer that receives the USCDI data set all the data that we proposed be We proposed to allow multiple under the proposed requirement, such available through an API (see section III. methods for electronic exchange of the that the enrollee’s data would be of the CMS Interoperability and Patient information, including use of the APIs cumulative and move with the enrollee Access proposed rule (84 FR 7627 proposed in section III. of the CMS as he or she changes enrollment. For through 7639)) but we understood that Interoperability and Patient Access example, if a patient is enrolled in Plan ingesting data and reconciling errors has proposed rule (84 FR 7627 through 1 in 2020 and Plan 2 in 2021, then challenges and proposed this more 7639), to allow for patient-mediated requests the data from Plan 1 to be sent limited data set to address those exchange of payer information or direct to Plan 2, Plan 2 would have at least 2 concerns. We sought comment on payer-to-payer communication, subject years (2020 and 2021) of health whether the USCDI data set would be to HIPAA requirements, 42 CFR part 2, information for that patient. If the comprehensive enough to facilitate the and other applicable federal and state patient moves to Plan 3 in 2022, Plan 3 type of care coordination and patient laws. We noted that we considered should receive both 2020 and 2021 data access described in the proposal, or requiring the use of the FHIR-based API from Plan 2 at the patient’s request. whether additional data fields and data discussed in section III. of the proposed While the proposal would require elements that would be available under compliance (and thus exchange of these the API proposal in section III. of the rule for this information exchange; data sets) only by MA plans, Medicaid CMS Interoperability and Patient Access however, we understood that some managed care plans, CHIP managed care proposed rule (84 FR 7627 through geographic areas might have a regional entities, and QHP issuers on the FFEs, 7639) should also be required. For a full health information exchange (HIE) that we noted that we hoped that discussion of the benefits of the USCDI could coordinate such data transfers for compliance by these payers could be the for this data exchange, see the CMS any HIE-participating MA plans, first step toward adoption and Interoperability and Patient Access Medicaid managed care plans, CHIP implementation of these standards on a proposed rule (84 FR 7641). managed care entities, and QHP issuers voluntary basis by other payers We stated that we believed that the on the FFEs that are subject to the throughout the health care system. proposed requirement would also proposal. We sought comment on Research indicates that the support dually eligible individuals who whether it would be beneficial to completeness of a patient record and the are concurrently enrolled in MA plans interoperability and patient care availability of up-to-date and relevant and Medicaid managed care plans. coordination for us to require the use of health information at the point of care Under the proposal, both of the dually the FHIR-based API otherwise proposed, can have a significant impact on patient eligible individual’s payers would be and whether this should be the only outcomes.45 We noted that we believe subject to the requirement to exchange mechanism allowed for this exchange, the proposal for MA organizations, that individual’s data in the form of the or whether multiple methods for Medicaid managed care plans, CHIP USCDI, which should improve the electronic exchange of the information managed care entities, and QHP issuers ability of both payers to coordinate care should be allowed under the proposed on the FFEs to exchange the USCDI data based on that data, as discussed in the policy and whether CMS might be able set in particular scenarios would CMS Interoperability and Patient Access to leverage its program authority to support improvement in care proposed rule (84 FR 7642). We sought facilitate the data exchanges coordination by allowing for sharing of comment on how payers should contemplated by the proposal. We key patient health information when an coordinate care and exchange expected enrollees to have constant enrollee requests it. information for dually eligible access to requesting an exchange of data We proposed that the payers subject individuals. We also sought comment as the proposal would require exchange to this new requirement would be on the associated burden on plans to of the USCDI data set whenever an required to exchange, at a minimum, the exchange the USCDI data set under the enrollee makes such a request, which data classes and elements included in proposal. In addition, we noted that we may occur at times other than the content standard proposed to be were interested in comments about enrollment or disenrollment. We adopted at 45 CFR 170.213 in the ONC potential legal barriers to exchanging acknowledged that in some cases payers 21st Century Cures Act proposed rule, the USCDI data set as would be required subject to the proposed requirement specifically, the USCDI (version 1) data under the proposal; for example, may be exchanging patient health whether there were federal, state, local, information with other payers that are 44 Under 42 CFR 422.504(d) and 438.3(u), MA and tribal laws governing privacy for not similarly required to exchange organizations and Medicaid managed care plans, specific use cases (such as in the care of and CHIP plans must retain records for at least 10 USCDI data sets for enrollees, for years. Under 45 CFR 156.705; 45 CFR minors or for certain behavioral health example, if a consumer changes their 155.1210(b)(2), (3) and (5), QHP issuers on the FFEs treatments) that would raise additional health coverage from a QHP on an FFE must also retain records for 10 years. considerations that we should address to employer-sponsored coverage, and 45 Office of the National Coordinator. (2019, June in this regulation or in guidance. we requested comment on how to 4). Improved Diagnostics & Patient Outcomes. We stated that activities related to the Retrieved from https://www.healthit.gov/topic/ support patients and providers in those health-it-and-health-information-exchange-basics/ proposed requirement could qualify as a situations. improved-diagnostics-patient-outcomes. quality improvement activity (QIA)

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00058 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25567

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00060 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25569

Patient Access API, as finalized in proposed to use our program authority networks that are operating successfully section III. of this final rule. in the MA program, Medicaid managed be leveraged in further advancing care program, CHIP managed care interoperability; thus, we considered a VI. Care Coordination Through Trusted program, and QHP certification program possible future approach to payer-to- Exchange Networks: Trust Exchange for the FFEs to increase participation in payer and payer-to-provider Network Requirements for MA Plans, trust networks and to bring the potential interoperability that leverages existing Medicaid Managed Care Plans, CHIP benefits of participating in such trust networks to support care Managed Care Entities, and QHP programs, including improved coordination and improve patient access Issuers on the FFEs Provisions, and interoperable communication and care to their data. We requested comments Analysis of and Responses to Public coordination, which result in on this approach and how it might be Comments opportunities for improved patient aligned in the future with section We proposed to require MA plans, outcomes and burden reduction. 4003(b) of the Cures Act. We also Medicaid managed care plans, CHIP We proposed to require, beginning requested comments on the managed care entities, and QHP issuers January 1, 2020, that MA plans, applicability date we proposed for the on the FFEs to participate in trust Medicaid managed care plans, CHIP trusted exchange network participation networks in order to improve managed care entities, and QHP issuers requirement and what benefits and interoperability in these programs. We on the FFEs participate in a trusted challenges the payers subject to our noted that we would codify this exchange network. The proposal was proposal might face meeting this requirement in, respectively, 42 CFR based on our authority under: Sections requirement for additional 422.119(f)(2), § 438.242(b)(5), and 1856(b) and 1857(e) of the Act to adopt consideration in future rulemaking. § 457.1233(d) (which cross-references standards and contract terms for MA We summarize the public comments the requirements in 42 CFR plans; section 1902(a)(4) of the Act to we received on this topic and provide 438.242(b)(5)) and 45 CFR 156.221(f). In adopt methods of administration for the our responses. general, payers and patients’ ability to administration state Medicaid plans, Comment: Although many communicate between themselves and including requirements for Medicaid stakeholders supported the concept of with health care providers could managed care plans (MCOs, PIHPs, and this proposal, there were strong considerably improve patient access to PAHPs); section 2101(a) for CHIP exceptions. Many commenters, data, reduce provider burden, and managed care entities (MCOs, PIHPs, particularly payers, indicated that it was reduce redundant and unnecessary and PAHPS); and section premature for CMS to finalize a procedures. Trusted exchange networks 3001(c)(9)(F)(iii) of the PHSA and proposal related to trusted exchange allow for broader interoperability section 1311(e)(1)(B) of the Affordable network participation before the first beyond one health system or point to Care Act for QHP issuers on an FFE. version of the Common Agreement point connections among payers, Under the proposal, and consistent with under ONC’s TEFCA was finalized. providers, and patients. Such networks section 4003(b) of the Cures Act, Commenters noted that, even though establish rules of the road for participation would be required in a they supported using a trusted exchange interoperability, and with maturing trusted exchange framework that met network, it would not be advisable until technology, such networks are scaling the following criteria: after TEFCA as outlined in section 4003 interoperability and gathering (1) The trusted exchange network of the 21st Century Cures Act was momentum with participants, including must be able to exchange PHI, defined available to facilitate this proposal. several federal agencies, EHR vendors, at 45 CFR 160.103, in compliance with Response: We appreciate that retail pharmacy chains, large provider all applicable state and federal laws although commenters supported the associations, and others. across jurisdictions. general concept of trusted exchange The importance of a trusted exchange (2) The trusted exchange network network participation and how it could framework to such interoperability is must be capable of connecting both advance interoperability and data reflected in section 4003(b) of the Cures inpatient EHRs and ambulatory EHRs. exchange, the true value of this concept Act, which was discussed in more detail (3) The trusted exchange network might be best realized via TEFCA in the in section I.D. of the CMS must support secure messaging or future. We agree that trusted exchange Interoperability and Patient Access electronic querying by and between networks can play a positive role, but proposed rule (84 FR 7612 through patients, providers, and payers. given the concerns commenters raised 7614). In section VI. of the CMS We proposed to codify these regarding the need for a mature TEFCA, Interoperability and Patient Access requirements for these payers at 42 CFR and appreciating the ongoing work on proposed rule (84 FR 7642), we 422.119(f)(2) for MA organizations, TEFCA being done at this time, we are discussed and explained our proposal to § 438.242(b)(5) for Medicaid managed not finalizing this policy at this time. require certain payers to participate in care plans, § 457.1233(d)(2) for CHIP Comment: Some commenters noted trusted exchange networks. A trusted managed care entities, and 45 CFR that more detail would be needed to exchange framework allows for the 156.221(f) for QHPs on the FFEs. understand how this proposal would be secure exchange of electronic health On April 19, 2019, ONC released the operationalized. These commenters also information with, and use of electronic draft Trusted Exchange Framework and indicated more information would be health information from, other health Common Agreement (TEFCA Draft 2) for needed to understand how this policy IT. Widespread payer participation in public comment.48 Previous would relate to existing Health such a framework might allow for more commenters on draft 1 of the TEFCA, Information Exchanges (HIEs) and complete access and exchange of all particularly payers providing Health Information Networks (HINs) electronically accessible health comments, requested that existing trust and whether these entities would information for authorized use under qualify as trusted exchange networks. A applicable state or federal law, which 48 See https://www.healthit.gov/sites/default/ few commenters indicated this policy we believe would lead to better use of files/page/2019-04/FINALTEFCA may be redundant appreciating the QTF41719508version.pdf. For additional such data. We noted that while we information about TEFCA, see https:// existing role of HIEs and HINs. cannot require widespread payer www.healthit.gov/topic/interoperability/trusted- Response: We appreciate the participation in trust networks, we exchange-framework-and-common-agreement. commenters’ concerns and requests for

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00061 Fmt 4701 Sfmt 4700 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 beneficiary experience for dually premiums for Qualified Medicare these in mind as we consider possible eligible individuals, while reducing Beneficiaries (QMBs). For Medicare Part future proposals around participation in administrative burden for providers, B, 42 CFR 406.26 codifies the process trusted exchange networks. health plans, and states. The for modifying the buy-in agreement to Comment: Many commenters interoperability of state and CMS identify the eligibility groups covered. expressed concerns with the proposed eligibility and Medicaid Management CMS subregulatory guidance, implementation timeline. They did not Information System (MMIS) systems is a specifically Chapter 3 of the State Buy- believe this policy could be critical part of modernizing the in Manual,49 specifies that states should implemented by January 1, 2020. programs and improving beneficiary exchange buy-in data with CMS at least Commenters indicated it would take and provider experiences. Improving monthly, but describes the option for more time to meet the necessary the accuracy of data on dual eligibility states to exchange buy-in data with CMS requirements and fully understand the by increasing the frequency of federal- daily or weekly. Likewise, states can implications of the policy, particularly state data exchanges is a strong first step choose to receive the CMS response data for HIEs and HINs. Many commenters in improving how these systems work file daily or monthly. We note that 35 suggested a delay ranging from 12 to 24 together. states and the District of Columbia are months. Other commenters suggested now submitting buy-in data to CMS CMS align the timeline of this proposal 2. Data Exchanges To Support State Buy-In for Medicare Parts A and B daily; 31 states and the District of with TEFCA implementation Columbia are now receiving buy-in milestones. In addition to a delay, some States and CMS routinely exchange response files from CMS daily. commenters suggested an exemption data on who is enrolled in Medicare and While many states submit and receive process. Medicaid, and which parties are liable buy-in files daily, some continue to only Response: We appreciate the for paying that beneficiary’s Parts A and do so on a monthly basis. We have commenters concerns, and based on B premiums. These data exchanges become increasingly concerned about support state, CMS, and Social Security these concerns and those summarized the limitations of monthly buy-in data Administration (SSA) premium from other commenters, we are not exchanges with states. The relatively accounting, collections, and enrollment finalizing this proposal at this time. To long lag in updating buy-in data means functions. Section 1843 of the Act reflect this in this final rule, the that the state is not able to terminate or regulation text proposed for all permits states to enter into an agreement activate buy-in coverage sooner, so the impacted payers is not being finalized. with the Secretary to facilitate state state or beneficiary may be paying In addition, as 42 CFR 438.242(b)(5) is ‘‘buy-in,’’ that is, payment of Medicare premiums for longer than appropriate. not being finalized, the regulation text premiums, in this case Part B premiums, In most cases, funds must be recouped proposed at 42 CFR 438.242(b)(6) is on behalf of certain individuals. For and redistributed—a burdensome being redesignated as 42 CFR those beneficiaries covered under the administrative process involving debits 438.242(b)(5). agreement, the state pays the Final Action: After consideration of beneficiary’s monthly Part B premium. and payments between the beneficiary, the comments received, and for the Section 1818(g) of the Act establishes state, CMS, and SSA. Additionally, reasons outlined in our response to the option for states to amend their buy- transaction errors do occur in the these comments, we are not finalizing in agreement to include enrollment and current data exchange processes. In a this proposal to require MA payment of the Part A premium for monthly exchange, it can take multiple organizations, Medicaid managed care certain specified individuals. All states months to correct and resubmit an plans, CHIP managed care entities, and and the District of Columbia have a Part improperly processed transaction, QHP issuers on the FFEs to participate B buy-in agreement; 36 states and the exacerbating the delays in appropriately in a trusted exchange network. District of Columbia have a Part A buy- assigning premium liability, leading to in agreement. larger mispayment, recoupment, and VII. Improving the Medicare-Medicaid To effectuate the state payment of redistribution of premiums. Exchanging Dually Eligible Experience by Medicare Part A or Part B premiums, a the buy-in data with greater frequency Increasing the Frequency of Federal- state submits data on a buy-in file to supports more timely access to State Data Exchanges Provisions, and CMS via an electronic file transfer (EFT) coverage. Analysis of and Responses to Public exchange setup. The state’s input file All states’ systems already have the Comments includes a record for each Medicare capacity to exchange buy-in data. We A. Increasing the Frequency of Federal- beneficiary for whom the state is adding acknowledge that states that do not State Data Exchanges for Dually Eligible or deleting coverage, or changing buy-in already exchange data daily will need Individuals status. In response, CMS returns an an initial, one-time systems change to updated transaction record that do so. However, moving to a daily data 1. Background provides data identifying, for each exchange would result in a net The Medicare and Medicaid programs transaction on the state file, whether reduction of burden for states, and were originally created as distinct CMS accepted, modified, or rejected it, further, reduce administrative programs with different purposes. The as well a Part A or Part B billing record complexity for beneficiaries and programs have different rules for showing the state’s premium providers. More frequent submission of eligibility, covered benefits, and responsibility. In addition, the CMS file updates to individuals’ buy-in status payment. The programs have operated may ‘‘push’’ new updates obtained from positively impacts all involved. For a as separate and distinct systems despite SSA to the state, for example, changes full discussion of the benefits, see the a growing number of people who to the Medicare Beneficiary Identifier CMS Interoperability and Patient Access depend on both programs (known as number or a change of address. dually eligible individuals) for their We have issued regulations for certain 49 Centers for Medicare and Medicaid Services. health care. There is an increasing need details of the state buy-in processes. For (2003). State Buy-In Manual: Chapter 3—Data Exchange. Retrieved from https://www.cms.gov/ to align these programs—and the data Medicare Part A, 42 CFR 407.40 Regulations-and-Guidance/Guidance/Manuals/ and systems that support them—to describes the option for states to amend downloads/buyin_c03.pdf. (Last accessed June 24, improve care delivery and the the buy-in agreement to cover Part A 2019).

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00062 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25571

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00064 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25573

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00065 Fmt 4701 Sfmt 4700 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 articulated in the CMS Interoperability Health Information Blocking 51 specific information on the costs in and Patient Access proposed rule and (hereinafter referred to as the excess of our assessment, we find that our responses to comments, we are ‘‘Information Blocking Congressional we have no basis to make a reasonable finalizing 42 CFR 423.910 as proposed. Report’’), in which ONC commented on adjustment. As such, we are the then current state of technology, B. Request for Stakeholder Input maintaining our estimate of the number health IT, and health care markets. of hours required, as detailed in sections In addition to the proposals discussed Notably, ONC observed that prevailing XII. and XIII. of this final rule. above, we sought public comment for market conditions create incentives for Comment: One commenter opposed consideration in potential future some individuals and entities to increasing states submission of the rulemaking on how we can achieve exercise their control over electronic MMA file from monthly to daily, greater interoperability of federal-state health information in ways that limit its recommending instead that the data for dually eligible individuals, availability and use. Since that time, frequency be increased to weekly. The including in the areas of program ONC and other divisions of HHS have commenter stated that determining on a integrity and care coordination, continued to receive feedback from daily basis whether there was any new coordination of benefits and crossover patients, clinicians, health care information to send would be a claims, beneficiary eligibility and executives, payers, app developers and significant effort, as multiple upstream enrollment, and their underlying data other technology companies, registries systems may have to be changed, and infrastructure. For more information on and health information exchanges, further, that there would seldom be new our request for comment, see the CMS professional and trade associations, and data to send on a daily basis. The Interoperability and Patient Access many other stakeholders regarding commenter requested that if CMS proposed rule (84 FR 7645). We thank practices which may constitute finalized the regulation to require daily commenters for their input. We will information blocking. Despite exchanges that states be permitted to consider the information received for significant public and private sector continue to existing processing cycles potential future rulemaking. efforts to improve interoperability and that cross business, for example, run Final Action: We will require all data liquidity, engagement with overnight between 6:00 p.m. to 6:00 a.m. states to participate in daily exchange of stakeholders confirms that adverse Response: We acknowledge the buy-in data, which includes both incentives remain and continue to commenter’s concerns about resources, sending data to CMS and receiving undermine progress toward a more but note that other commenters—even responses from CMS daily, and require connected health system. those who echoed concerns about all states submit the required MMA file Based on these economic realities and resources—uniformly supported the data to CMS daily by April 1, 2022. first-hand experience working with the value of daily exchanges in improving These policies are being finalized in 42 health IT industry and stakeholders, the experience of dually eligible CFR 406.26, 407.40, and 423.910, ONC concluded in the Information individuals and the ability of providers respectively, as proposed. These Blocking Congressional Report that and plans to coordinate eligibility, requirements will improve the information blocking is a serious enrollment, benefits, and/or care for this problem and recommended that the experience of dually eligible individuals population. As we note above, we are Congress prohibit information blocking and the ability of providers and payers committed to providing technical and provide penalties and enforcement to coordinate eligibility, enrollment, assistance and federal matching funds to mechanisms to deter these harmful benefits, and/or care for this population. support needed systems changes at the practices. state. As a result, we decline to make Federal matching funds of 50 percent MACRA became law in the same the recommended change. for administration are available to month that the Information Blocking With respect to the point that there support states’ costs. States may also be Congressional Report was published. would not be updates on a daily basis, eligible for enhanced 90 percent federal Section 106(b)(2)(A) of MACRA we reiterate that no file would be matching funds for the costs of amended section 1848(o)(2)(A)(ii) of the required on business days when there developing and implementing any Act to require that an eligible were no updates. We expect that states necessary system changes required by professional must demonstrate that he would be able to automate their systems this regulation, and enhanced 75 or she has not knowingly and willfully so that they check daily for changes to percent federal matching funds for their taken action (such as to disable data that would need to be submitted to system’s maintenance and operation functionality) to limit or restrict the CMS on the MMA file, but also costs. CMS will provide technical compatibility or interoperability of automate a process by which the system assistance to the states that need to certified EHR technology, as part of only generates an MMA file upon make changes to submit their files daily, being a meaningful EHR user. Section identifying such a change. We including best practices on the upstream 106(b)(2)(B) of MACRA made appreciate the additional coding data sets necessary to implement daily corresponding amendments to section required to implement this logic but that MMA file submissions. 1886(n)(3)(A)(ii) of the Act for eligible that once implemented, no additional VIII. Information Blocking Background hospitals and, by extension, under interventions would be needed. We will and Public Reporting Provisions, and section 1814(l)(3) of the Act for CAHs. work with states that have implemented Analysis of and Responses to Public Sections 106(b)(2)(A) and (B) of MACRA these changes to identify and share best Comments provide that the manner of this practices in identifying data changes to demonstration is to be through a process trigger daily submissions. A. Information Blocking Background specified by the Secretary, such as the Finally, in response to the concern 1. Legislative Background and Policy use of an attestation. To implement about states that have an overnight Considerations these provisions, as discussed further processing cycle to continue so to meet the definition of ‘‘daily,’’ the proposed The nature and extent of information 51 Office of the National Coordinator. (2015, April regulation would permit this. blocking has come into focus in recent 9). Report to Congress on Health Information years. In 2015, at the request of the Blocking. Retrieved from https://www.healthit.gov/ After consideration of the public sites/default/files/reports/info_blocking_ comments and for the reasons Congress, ONC submitted a Report on 040915.pdf.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00066 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25575

below, we established and codified activities that would not constitute provided that to the extent scientifically attestation requirements to support the information blocking. In addition to the sound measures that are developed prevention of information blocking, attestation discussed in this section, all consistent with the requirements of which consist of three statements health care providers would also be section 10331 of the Affordable Care Act containing specific representations subject to the separate information are available, such information shall about a health care provider’s blocking regulations proposed by ONC include, to the extent practicable, an implementation and use of CEHRT. To for HHS adoption at 45 CFR part 171 (84 assessment of the coordination of care review our discussion of these FR 7601 through 7605). and other information as determined requirements, we refer readers to the CY B. Public Reporting and Prevention of appropriate by the Secretary. We noted 2017 Quality Payment Program final Information Blocking on Physician our belief that section 10331(a)(2) of the rule (81 FR 77028 through 77035). Compare Affordable Care Act provided the Recent empirical and economic statutory authority to publicly report research further underscores the Physician Compare (http:// certain data about the prevention of complexity of the information blocking www.medicare.gov/physiciancompare) information blocking attestation problem and its harmful effects. For a draws its operating authority from statements as an assessment of care full discussion of the research, see the section 10331(a)(1) of the Affordable coordination and as other information CMS Interoperability and Patient Access Care Act. Consistent with section determined appropriate by the proposed rule (84 FR 7645 through 10331(a)(2) of the Affordable Care Act, Secretary. Furthermore, the prevention 7646). Physician Compare initiated a phased of information blocking attestation In December 2016, section 4004 of the approach to publicly reporting statements are required for a clinician to Cures Act added section 3022 of the performance scores that provide earn a Promoting Interoperability PHSA (the ‘‘PHSA information blocking comparable information on quality and performance category score, which is provision’’), which defines conduct by patient experience measures. A then incorporated into the final score for health care providers, health IT complete history of public reporting on MIPS, and we are required to publicly developers, and health information Physician Compare is detailed in the CY report both of these scores under section exchanges and networks that constitutes 2016 Physician Fee Schedule (PFS) final 1848(q)(9)(A) of the Act. Publicly information blocking. The PHSA rule with comment period (80 FR 71117 posting this information as an indicator information blocking provision was through 71122). More information about is consistent with our finalized policy to enacted in response to ongoing concerns Physician Compare, including the publicly report, either on the profile history of public reporting and regular that some individuals and entities are pages or in the downloadable database, updates about what information is engaging in practices that unreasonably other aspects of the Promoting currently available, can also be accessed limit the availability and use of Interoperability performance category, electronic health information for on the Physician Compare Initiative such as objectives, activities, or authorized and permitted purposes (see website at https://www.cms.gov/ measures specified in the CY 2018 the definition of electronic health medicare/quality-initiatives-patient- Quality Payment Program final rule (82 information proposed by ONC for HHS assessment-instruments/physician- FR 53826 through 53827). We note that adoption at 45 CFR 171.102 (84 FR compare-initiative/. we finalized at 42 CFR 414.1395(b), that, 7588)). These practices undermine As discussed in the CY 2018 Quality with the exception of data that must be public and private sector investments in Payment Program final rule (82 FR mandatorily reported on Physician the nation’s health IT infrastructure and 53820), Physician Compare has Compare, for each program year, we rely frustrate efforts to use modern continued to pursue a phased approach on the established public reporting technologies to improve health care to public reporting under MACRA in quality and efficiency, accelerate accordance with section 1848(q)(9) of standards to guide the information research and innovation, and provide the Act. For a discussion of public available for inclusion on Physician greater value and choice to health care reporting on Physician Compare, see the Compare. The public reporting consumers. CMS Interoperability and Patient Access standards require data included on The information blocking provision proposed rule (84 FR 7646 through Physician Compare to be statistically defines and creates possible penalties 7647). valid, reliable, and accurate; be and disincentives for information Building upon the continuation of our comparable across submission blocking in broad terms, working to phased approach to public reporting mechanisms; and, meet the reliability deter the entire spectrum of practices and understanding the importance of threshold. To be included on the public likely to interfere with, prevent, or preventing information blocking, facing profile pages, the data must also materially discourage access, exchange, promoting interoperability, and the resonate with website users, as or use of electronic health information. sharing of information, we proposed to determined by CMS. The PHSA information blocking make certain data about the attestation There are three prevention of provision applies to health care statements on the prevention of information blocking attestation providers, health IT developers, information blocking referenced in the statements under 42 CFR exchanges, and networks. The CMS Interoperability and Patient Access 414.1375(b)(3)(ii)(A) through (C) to information blocking provision also proposed rule (84 FR 7645) available for which eligible clinicians reporting on provides that the ‘‘Secretary, through public reporting on Physician Compare, the Promoting Interoperability rulemaking, shall identify reasonable drawing upon our authority under performance category of MIPS must and necessary activities that do not section 10331(a)(2) of Affordable Care attest. To report successfully on the constitute information blocking for Act, which required us to make publicly Promoting Interoperability performance purposes of the definition at section available on Physician Compare category, in addition to satisfying other 3022(a)(1) of the PHSA.’’ ONC’s 21st information on physician performance requirements, an eligible clinician must Century Cures Act proposed rule that provides comparable information submit an attestation response of ‘‘yes’’ proposed ‘‘exceptions’’ to the for the public on quality and patient for each of these statements. For more information blocking provision. These experience measures. Section information about these statements, we exceptions are reasonable and necessary 10331(a)(2) of the Affordable Care Act refer readers to the preamble discussion

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00068 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25577

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00070 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25579

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00071 Fmt 4701 Sfmt 4700 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 Comment: One commenter suggested open exchange of patient health eligible hospitals and CAHs are being a collaboration between CMS, ONC, and information. Congress gave the held accountable for the practices of OIG in order to address information Secretary the authority to use an health IT vendors. Many commenters blocking together, to combat existing index or to facilitate the were concerned that vendors are information blocking consistently and creation of a new index. In comments restricting the transfer of data by data from all angles. received on the FY 2019 IPPS proposed embargoing, actively blocking, and Response: We appreciate the rule RFI, there was strong support for a refusing or prohibiting the transfer of commenter’s suggestion, and note that single, public directory of provider data. Further, there were concerns that CMS, ONC, and OIG are consistently digital contact information. Commenters vendors are requiring complex working together on issues such as noted that digital communication could programs, the purchase of many costly information blocking so that our improve interoperability by facilitating programs, and requiring excessive fees policies are complementary and work efficient exchange of patient records, to conduct data transfer. Last, several together to address the issue. eliminating the burden of working with commenters requested that vendors be Final Action: After consideration of scanned paper documents, and penalized equally, and in the same the comments received, and for the ultimately enhancing care coordination. manner, as eligible hospitals and CAHs. reasons outlined in our response to To ensure the index is accessible to Response: We appreciate the these comments and in the CMS all clinicians and facilities, we updated commenters’ support for the proposal, Interoperability and Patient Access the National Plan and Provider 52 and we also appreciate their concerns. proposed rule, we are finalizing this Enumeration System (NPPES) to be We emphasize that the information policy as proposed. We will include able to capture digital contact blocking provision (section 4004 of the information on a CMS website available information for both individuals and Cures Act) applies to health IT to the public indicating that an eligible facilities. It is important to note that the developers of certified health IT. hospital or CAH attesting under the aforementioned updates to the NPPES Section 3022(a)(1) of the PHSA, in Medicare FFS Promoting entailed the addition of two additional defining information blocking, refers to Interoperability Program submitted a data fields. However, due to an four classes of individuals and entities ‘‘no’’ response to any of the three administrative oversight, the data that may engage in information blocking prevention of information blocking elements which allow for the digital and which include: Health care attestation statements under 42 CFR capture of contact information are not providers, health IT developers of 495.40(b)(2)(i)(I)(1) through (3). We will OMB approved. CMS acknowledges this violation of the Paperwork Reduction certified health IT, networks, and post this information starting with the Act of 1995 (PRA) and is currently exchanges. In the ONC 21st Century attestations for the EHR reporting period working to remediate the issue by Cures Act proposed rule, ONC proposed in 2019, and expect the information will creating a new PRA package and thereby to adopt definitions of these terms to be posted in late 2020. In the event that come into compliance with the PRA. provide clarity regarding the types of an eligible hospital or CAH leaves a Prior to its submission for OMB individuals and entities to whom the ‘‘blank’’ response to an attestation approval, the new information information blocking provision applies statement, where a ‘‘yes’’ or a ‘‘no’’ collection request will be made (84 FR 7601 through 7602). response is not submitted, the attestations will be considered available for public review and Regarding penalties, section 4004 of comment as required by the PRA. the Cures Act identifies potential incomplete, and no information will be posted related to these attestation NPPES currently supplies National penalties and disincentives for Provider Identifier (NPI) numbers to information blocking. Health IT statements. We will establish a process for each eligible hospital and CAH to health care providers (both individuals developers, health information and facilities), maintains their NPI networks, and health information review the information related to their specific prevention of information record, and publishes the records exchanges that the Inspector General, online. The Secretary adopted the NPI following an investigation, determines blocking attestation statements before it is publicly posted on the CMS website. as the HIPAA administrative to have committed information blocking simplification standard identifier for shall be subject to a civil monetary For each program year, we will have a 30-day preview period for an eligible health care providers (69 FR 3434). penalty determined by the Secretary for HIPAA covered entities, including all such violations identified through hospital or CAH to review this information before it is publicly posted. health care providers, health plans, and such investigation, which may not health care clearinghouses, must use the exceed $1,000,000 per violation. Such During the 30-day preview period, all of the information that we will publicly NPI in HIPAA transactions. All health determination shall take into account care providers that transmit health factors such as the nature and extent of post will be available for the eligible hospital or CAH to review, and we will information in electronic form in the information blocking and harm connection with a HIPAA transaction resulting from such information consider making changes to the information on a case-by-case basis. must obtain an NPI. blocking, including, where applicable, Health care providers are required to the number of patients affected, the IX. Provider Digital Contact communicate to the NPPES any number of providers affected, and the Information Provisions, and Analysis of information that has changed within 30 number of days the information and Responses to Public Comments days of the change (45 CFR blocking persisted. Health care A. Background 162.410(a)(4)). We review NPPES to providers determined by the Inspector ensure a provider has a valid NPI as part General to have committed information Congress required the Secretary to of the Medicare enrollment process, as blocking shall be referred to the create a provider digital contact well as the revalidation process, which appropriate agency to be subject to information index in section 4003 of the occurs every 3 to 5 years depending on appropriate disincentives using Cures Act. This index must include all the provider or supplier type. authorities under applicable Federal individual health care providers and law, as the Secretary sets forth through health care facilities, or practices, in 52 The NPPES website at https:// notice and comment rulemaking. order to facilitate a comprehensive and nppes.cms.hhs.gov/.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00072 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25581

Information in NPPES is publicly Medicaid Programs; Electronic Health information included in the NPPES accessible via both an online search Record Incentive Program-Stage 3 and system. We proposed to begin this option and a downloadable database Modifications to Meaningful Use in public reporting in the second half of option. As a result, adding digital 2015 Through 2017’’ (80 FR 62901), we 2020, to allow individuals and facilities contact information to this existing finalized a policy to collect information time to review their records in NPPES index is an efficient and effective way in NPPES about the electronic addresses and update the system with appropriate to meet the Congressional requirement of participants in the EHR Incentive digital contact information. We also to establish a digital contact information Program (specifically, a Direct address requested comment from stakeholders index and to promote the sharing of and/or other ‘‘electronic service on the most appropriate way to pursue information. information’’ as available). However, this public reporting initiative, As of June 2018, NPPES has been this policy was not fully implemented at including where these names should be updated to include the capability to the time, in part due to the limitations posted, with what frequency, and any capture one or more pieces of digital of the NPPES system which have since other information stakeholders believed contact information that can be used to been addressed. As a result, many would be helpful. facilitate secure sharing of health providers have not yet added their We noted that we believed this information. For instance, providers can digital contact information to NPPES information would be extremely submit a Direct address, which and digital contact information is valuable to facilitate interoperability, functions similar to a regular email frequently out of date. and we appreciated Congress’ address, but includes additional In light of these updates to the NPPES leadership in requiring the security measures to ensure that system, all individual health care establishment of this directory. We messages are only accessible to the providers and facilities can take requested stakeholder comment on intended recipient in order to keep the immediate action to update their NPPES additional possible enforcement information confidential and secure. record online to add digital contact authorities to ensure that individuals ‘‘Direct’’ is a technical standard for information. This simple step will and facilities make their digital contact exchanging health information. Direct significantly improve interoperability by information publicly available through addresses are available from a variety of making valuable contact information NPPES. For example, we questioned if sources, including EHR vendors, State easily accessible. For those providers Medicare reporting programs, such as Health Information Exchange entities, who continue to rely on the use of MIPS, should require eligible clinicians regional and local Health Information cumbersome, fax-based modes of to update their NPPES data with their Exchange entities, as well as private sharing information, we hope that digital contact information? Should service providers offering Direct greater availability of digital contact CMS require this information to be exchange capabilities called Health information will help to reduce barriers included as part of the Medicare Information Service Providers (HISPs) to electronic communication with a enrollment and revalidation process? (https://www.healthit.gov/sites/default/ wider set of providers with whom they How can CMS work with states to files/directbasicsforprovidersqa_ share patients. Ubiquitous, public promote adding information to the 05092014.pdf). NPPES can also capture availability of digital contact directory through state Medicaid information about a wide range of other information for all providers is a crucial programs and CHIP? Should CMS types of endpoints that providers can step towards eliminating the use of fax require providers to submit digital use to facilitate secure exchange of machines for the exchange of health contact information as part of program health information, for instance a FHIR information. We urged all providers to integrity processes related to prior server URL or query endpoint associated take advantage of this resource to authorization and submission of with a health information exchange. We implement Congress’ requirement that medical record documentation? We strongly encourage the inclusion of this the Secretary establish a digital contact noted that we would review comments FHIR endpoint information in NPPES in information index. for possible consideration in future support of the Patient Access API policy rulemaking on these questions. B. Public Reporting of Missing Digital discussed in section III. of this final rule We summarize the public comments Contact Information and the Provider Directory API policy we received on this topic and provide discussed in section IV. of this final Entities seeking to engage in our responses. rule. Using NPPES as one way to make electronic health information exchange Comment: Many stakeholders shared these endpoints publicly known will need accurate information about the our goal of improving the accuracy and significantly support interoperability electronic addresses (for example, Direct completeness of data in the NPPES. throughout the health care system. address, FHIR server URL, query Response: We thank commenters for In addition, NPPES can now maintain endpoint, or other digital contact their support and are finalizing this information about the type of contact information) of potential exchange policy as proposed. information providers and organizations partners. A common directory of the Comment: Many commenters, while are associated with, along with the electronic addresses of health care supporting the ultimate goal of the preferred uses for each address. Each providers and organizations could proposal, noted doubts about whether provider in NPPES can maintain their enhance interoperability and the proposal would be effective at own unique information or associate information exchange by providing a increasing the accuracy and themselves with information shared resource where users can obtain completeness of digital contact among a group of providers. Finally, in information about how to securely information in NPPES. Commenters March 2019, NPPES added a public API transmit electronic health information believed that a public reporting which can be used to obtain the digital to a provider. mechanism would not serve as a contact information stored in the We proposed to increase the number meaningful deterrent to providers database. Although NPPES is now better of providers with valid and current leaving their information blank. One equipped to maintain provider digital digital contact information available commenter stated that they believed, contact information, many providers through NPPES by publicly reporting even with the implementation of this have not submitted this information. In the names and NPIs of those providers proposal, high rates of inaccuracies the 2015 final rule, ‘‘Medicare and who do not yet have their digital contact would persist in NPPES, and

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00074 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25583

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00075 Fmt 4701 Sfmt 4700 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 Comment: Several commenters exchange of information that supports for storing digital contact information. suggested that CMS develop a digital safe, effective transitions of care Response: While we understand the contact information interoperability between hospitals and community interest in using PECOS as the location standard for facilitating efficient providers. Specifically, we requested for storing digital contact information, exchange of patient records. comment on revisions to the current we are not considering this as an option Response: We appreciate commenters’ CMS CoPs for hospitals such as: at this time. PECOS collects information suggestions, and note that we continue Requiring that hospitals transferring specific to provider and supplier to collaborate with ONC, other federal medically necessary information to enrollment in the Medicare program and partners, and industry stakeholders, to another facility upon a patient transfer the system is limited to the fields on the develop more robust provider directory or discharge do so electronically; CMS 855 Enrollment forms. Any other standards that can support exchange of requiring that hospitals electronically data outside of this is optional. There this information. We also direct send required discharge information to are also many operational and commenters to the discussion of the a community provider via electronic systematic issues that prevent PECOS Provider Directory API in section IV. of means if possible and if a community from being utilized to implement the this final rule. provider can be identified; and digital contact information requirement. Final Action: After consideration of requiring that hospitals make certain Comment: Several commenters raised the comments received, and for the information available to patients or a questions about what entities would reasons outlined in our response to specified third-party application (for have access to the information in these comments and in the CMS example, required discharge NPPES. One commenter stated that any Interoperability and Patient Access instructions) via electronic means if entity should be able to gain access to proposed rule, we are finalizing to requested. NPPES in order to advance publicly report the names and NPIs of The RFI discussed several steps we interoperability. Another noted that those providers who do not have digital have taken in recent years to update and making digital endpoints publicly contact information included in the modernize the CoPs and other health accessible via an API that may be NPPES system beginning in the second and safety standards to reflect current accessible to third parties could pose a half of 2020 as proposed. Additionally, best practices for clinical care, risk to the security of protected health we will engage in continued public especially in the area of care information available through those education efforts to ensure providers are coordination and discharge planning. APIs, and recommended that CMS make aware of the benefits of including digital For a complete discussion of this work, this information available to other contact information in NPPES, see the proposed rule (84 FR 7649 entities only if the third-party entity including FHIR API endpoints, and through 7650). requests access from the API owner. when and where this information will In the September 30, 2019 Federal Response: NPPES already furnishes a be posted. Register, we published a final rule, public downloadable data ‘‘Medicare and Medicaid Programs; dissemination file as well as a public X. Conditions of Participation for Revisions to Requirements for Discharge API that provides the public Hospitals and Critical Access Hospitals Planning’’ (84 FR 51836) (‘‘Discharge information available in the NPI (CAHs) Provisions, and Analysis of and Planning final rule’’), that revises the Registry. Both files are publicly Responses to Public Comments discharge planning requirements that accessible. Please note that this proposal A. Background hospitals (including psychiatric is not related to the Patient Access API hospitals, long-term care hospitals, and discussed in section III. of this final rule As noted in the CMS Interoperability inpatient rehabilitation facilities), that can include patient protected and Patient Access proposed rule (84 FR critical access hospitals (CAHs), and health information. 7649 through 7653), we appreciate the home health agencies, must meet to Comment: A number of commenters pathways Congress has created for participate in Medicare and Medicaid requested additional information on action on interoperability and have been programs. The rule supports CMS’ issues related to NPPES functionality, working diligently with ONC to interoperability efforts by promoting the and sought guidance on how to enter implement them. In order to ensure exchange of patient information digital contact information. For broad stakeholder input to inform the between health care settings, and by instance, numerous commenters proposals, we published a Request for ensuring that a patient’s necessary believed that the NPPES does not allow Information (RFI) on interoperability in medical information is transferred with for a provider to enter information for several proposed rules, including the FY the patient after discharge from a multiple practice and billing locations. 2019 IPPS proposed rule (83 FR 20550). hospital, CAH, or post-acute care Several commenters sought information Specifically, we published the RFI services provider. By requiring that all about whether a provider could enter entitled, ‘‘Promoting Interoperability of the patient’s necessary medical multiple digital endpoints, for instance and Electronic Healthcare Information information, including his or her post- if they employ different endpoints for Exchange Through Possible Revisions to discharge goals of care and treatment different types of communication. One the CMS Patient Health and Safety preferences, must be documented in the commenter requested information on Requirements for Hospitals and Other patient’s medical record and transferred whether a provider could enter digital Medicare- and Medicaid-Participating along with the patient at the time of contact information for his or her Providers and Suppliers.’’ We requested discharge to an appropriate receiving employer, rather than individual stakeholders’ input on how we could health care facility, such as a PAC information. use the CMS health and safety standards service provider or agency, and to other Response: For more information on that are required for providers and outpatient service providers and how information is captured in NPPES, suppliers participating in the Medicare practitioners responsible for the we encourage commenters to review and Medicaid programs (that is, the patient’s follow-up or ancillary care, the information available on the NPPES Conditions of Participation (CoPs), rule aims to better prepare patients and website at https://nppes.cms.hhs.gov/ Conditions for Coverage (CfCs), and their caregivers to be active partners and webhelp/nppeshelp/HEALTH%20 Requirements for long term care advocates for their health care and INFORMATION%20EXCHANGE.html. facilities) to further advance electronic community support needs upon

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00076 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25585

discharge from the hospital or post- other post-acute care services providers, authors identified a number of studies acute care setting. was especially important during care demonstrating positive effects on While we finalized a broad transitions when maintaining access to outcomes associated with better care requirement for sending necessary patient health information, including coordination, such as reductions in 30- medical information in accordance with medication information, and is day readmissions,54 55 56 and improved all applicable laws, rather than listing extremely relevant to the patient’s next medication reconciliation.57 specific data elements (such as those phase of care. Additionally, Electronic patient event notifications explicitly aligned with the data stakeholders noted that giving patients from hospitals, or clinical event referenced as part of the Common and their caregivers access to important notifications, are one type of health Clinical Data Set (CCDS) that was health information (such as discharge information exchange intervention that finalized in the 2015 final rule, information along with accurately has been increasingly recognized as an ‘‘Medicare and Medicaid Programs; reconciled lists of discharge effective and scalable tool for improving Electronic Health Record Incentive medications) created a more patient- care coordination across settings, Program—Stage 3 and Modifications to centered health care system, and especially for patients at discharge. This Meaningful Use in 2015 Through 2017’’ reduced the risk of errors and hospital approach has been associated with a (80 FR 62762), we also ensured that the readmissions. But many stakeholders reduction in readmissions following revisions to the CoPs did not conflict also expressed concerns about implementation of such notifications.58 with the CCDS, or future standards implementing policy changes within the We noted that the evidence cited in this proposed for adoption for electronic CoPs that might increase the compliance section to support the use of innovative exchange of health information, burden on hospitals. However, several health information exchange specifically the USCDI. The discharge stakeholders also strongly interventions and approaches, such as planning CoPs do not bar providers recommended that CMS add details to the patient event notifications that we from sending all additional appropriate the CoPs, and require that hospitals proposed to require, can be applied to medical information regarding the share not only medically necessary various types of hospitals, including patient’s current course of illness and information with physician offices, psychiatric hospitals, as well as to treatment, post-discharge goals of care, HHAs, and SNFs (such as pending tests CAHs, as discussed below. and treatment preferences in accordance and discharge summaries), but also Patient event notifications are with applicable laws. However, we note notifications of when patients were automated, electronic communications here that the Discharge Planning final admitted to the hospital as well as from the discharging provider to another rule does not require hospitals, CAHs, discharged or transferred from the facility, or to another applicable and HHAs to transfer the necessary hospital and admitted to the care of community provider as identified by the patient medical information exclusively applicable PAC services providers and patient (such as a patient’s primary care by electronic means nor does it require suppliers. practitioner or practice group, post- that providers notify the appropriate Given responses to the RFI, as well as acute care services providers and providers, suppliers, and practitioners previous rulemaking activities, we suppliers, and other practitioners and receiving the necessary medical sought to further expand CMS providers that need the notification for information of the patient’s discharge as requirements for interoperability within post-acute care coordination, treatment, we are now requiring in this final rule. the hospital and CAH CoPs as part of and/or quality improvement purposes), Additionally, the Discharge Planning the CMS Interoperability and Patient final rule further supports Access proposed rule by focusing on the American Medical Informatics Association, interoperability and a patient’s access to electronic patient event notifications. In 25(9), 1259–1265. doi: 10.1093/jamia/ocy035. 54 his or her own medical records by addition, we noted that we were Yeaman, B., Ko, K., del Castillo, R. (2015). Care updating the hospital Patient Rights CoP transitions in long-term care and acute care: Health committed to taking further steps to information exchange and readmission rates. The to now state that the patient has the ensure that facilities that are Online Journal of Issues in Nursing, 20(3). doi: right to access his or her medical electronically capturing information are 10.3912/OJIN.Vol20No03Man05. records in the form and format electronically exchanging that 55 Vest, J.R., Kern, L.M., Silver, M.D., & Kaushal, requested (including in an electronic information with providers who have R. (2015). The potential for community-based form or format when such medical health information exchange systems to reduce the capacity to accept it. hospital readmissions. Journal of the American records are maintained electronically). Infrastructure supporting the Medical Informatics Association, 22(2), 435–442. Therefore, the hospital CoPs now exchange of electronic health doi: 10.1136/amiajnl-2014–002760. include an explicit requirement that, as information across settings has matured 56 Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest, J.R. (2017). Hospitalization event notifications and a condition of participation, hospitals substantially in recent years. Research must provide patients with access to reductions in readmissions of Medicare fee-for- studies have increasingly found that service beneficiaries in the Bronx, New York. their medical records in an electronic health information exchange Journal of the American Medical Informatics format upon the patient’s request if the interventions can affect positive Association, 24(e1), e150–e156. doi: 10.1093/jamia/ ocw139. hospital has the capacity to do so. outcomes in health care quality and In response to the RFI in the FY 2019 57 Boockvar, K.S., Ho, W., Pruskowski, J., Dipalo, public health, in addition to more IPPS proposed rule, many stakeholders K.E., Wong, J.J., Patel, J., . . . Hung, W. (2017). longstanding findings around Effect of health information exchange on supported our goals of increasing reductions in utilization and costs. A recognition of medication discrepancies is interoperability, and acknowledged the recent review of how health information interrupted when data charges are introduced: important role that hospital settings Results of a cluster-randomized controlled trial. exchange interventions can improve play in supporting care coordination. Journal of the American Medical Informatics cost and quality outcomes identified a Association, 24(6), 1095–1101. doi: 10.1093/jamia/ Stakeholders agreed that use of growing body of high-quality studies ocx044. electronic technology was an important 58 showing that these interventions are Unruh, M.A., Jung, H.-Y., Kaushal, R., & Vest, factor in ensuring safe transitions. J.R. (2017). Hospitalization event notifications and associated with beneficial results.53 The Multiple stakeholders emphasized that reductions in readmissions of Medicare fee-for- service beneficiaries in the Bronx, New York. electronic data exchange between 53 Menachemi, N., Rahurkar, S., Harle, C.A., & Journal of the American Medical Informatics hospitals and physician offices, as well Vest, J.R. (2018). The benefits of health information Association, 24(e1), e150–e156. doi: 10.1093/jamia/ as with hospices, HHAs, SNFs, and exchange: An updated systematic review. Journal of ocw139.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00077 Fmt 4701 Sfmt 4700 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’s clinical status and care the time of the patient’s admission to the patient has received care at a received from the sending provider. the hospital and either immediately different setting. Depending on the prior to or at the time of the patient’s B. Provisions for Hospitals (42 CFR implementation, information included discharge and/or transfer from the 482.24(d)) with these notifications can range from hospital. conveying the patient’s name, other We proposed to revise the CoPs for We proposed to limit this requirement basic demographic information, and the Medicare- and Medicaid-participating to only those hospitals which currently sending institution to a richer set of hospitals at 42 CFR 482.24 by adding a possess EHR systems with the technical clinical data on the patient. Even with new standard at paragraph (d), capacity to generate information for a minimum set of information included, ‘‘Electronic Notifications,’’ that would electronic patient event notifications as these notifications can help ensure that require hospitals to send electronic discussed below, recognizing that not a receiving provider, facility, or patient event notifications of a patient’s all Medicare- and Medicaid- practitioner is aware that the patient has admission, discharge, and/or transfer to participating hospitals have been received care elsewhere. The another health care facility or to another eligible for past programs promoting notification triggers a receiving community provider or practitioner. We adoption of EHR systems. We noted our provider, facility, or practitioner to proposed to require hospitals to convey, goal in proposing the requirement was reach out to the patient and deliver at a minimum, the patient’s basic to ensure that hospital EHR systems appropriate follow-up care in a timely personal or demographic information, as have a basic capacity to generate manner. By notifying the individuals well as the name of the sending messages that can be utilized for and entities that need notification of the institution (that is, the hospital), and, if notifications by a wide range of patient’s status for treatment, care not prohibited by other applicable law, receiving providers, enabled by coordination, or quality improvement the patient’s diagnosis. In proposing common standards. We believed that a purposes, the notification can help to that patient event notifications sent by system that utilizes the ADT messaging improve post-discharge transitions and a hospital’s medical records system standard, which is widely used as the reduce the likelihood that a patient include diagnosis, where not prohibited basis for implementing these would face complications from by other applicable law, we requested notifications and other similar use inadequate follow-up care. comment on the technical feasibility of cases, would meet this goal by In addition to their effectiveness in this proposal, noting that we recognize supporting the availability of supporting care coordination, virtually some existing ADT messages might not information that can be used to generate all EHR systems generate the basic include diagnosis, as well as the information for patient event messages commonly used to support challenges in appropriately segmenting notifications. Specifically, we proposed electronic patient event notifications. this information in instances where the that the system utilize the ADT These notifications are based on diagnosis may not be permitted for messaging standard incorporated by disclosure under other applicable laws. admission, discharge, and transfer reference at 45 CFR 170.205(a)(4)(i).59 We also encouraged hospitals, as their (ADT) messages, a standard message We noted that, while there are no systems and those of the receiving used within an EHR as the vehicle for criteria under the ONC Health IT providers allowed, to work with communicating information about key Certification Program which certifies patients and their practitioners to offer changes in a patient’s status as they are health IT to create and send electronic more robust patient information and tracked by the system (more information patient event notifications, the ADT clinical data upon request in accordance about the current standard supporting standard is referenced by other with applicable law. these messages is available at http:// certification criteria under the program. www.hl7.org/implement/standards/ For a hospital that currently possesses _ _ an EHR system with the capacity to Specifically, this standard supports product brief.cfm?product id=144). As certification criteria related to noted in the Interoperability Standards generate the basic patient personal or demographic information for electronic transferring information to Advisory (ISA) published by ONC, this immunization registries, as well as messaging standard has been widely patient event notifications, we proposed that compliance with the proposed transmission of laboratory results to adopted across the health care system public health agencies as described at (see https://www.healthit.gov/isa/ standard within the Medical records services CoP (42 CFR 482.24) would be 45 CFR 170.315(f) under the 2015 sending-a-notification-a-patients- Edition certification criteria, and at 45 admission-discharge-andor-transfer- determined by the hospital CFR 170.314(f) under the 2014 Edition. status-other-providers). demonstrating to the surveyor or Thus, we expect systems that include ADT messages provide each patient’s accrediting organization that its system: personal or demographic information (1) Is fully operational and that it Health IT Modules certified to meet (such as the patient’s name, insurance, operates in accordance with all state criteria which reference this standard next of kin, and attending physician), and federal statutes and regulations will possess the basic capacity to when that information has been regarding the exchange of patient health generate information for notification updated, and also indicate when an information; (2) utilizes the content messages. We further noted that ADT status has changed. To create an exchange standard incorporated by adopting certified health IT that meets electronic patient event notification, a reference at 45 CFR 170.205(a)(4)(i); (3) these criteria has been required for any system can use the change in ADT sends notifications that would have to hospital seeking to qualify for the status to trigger a message to a receiving include the minimum patient health Promoting Interoperability Programs provider or to a health information information (which, as noted above, (formerly the EHR Incentive Programs). exchange system that can then route the would be the patient’s name, treating We recognized that there is currently message to the appropriate provider. In practitioner name, sending institution significant variation in how hospitals addition to the basic demographic name, and, if not prohibited by other have utilized the ADT messages to information contained in the ADT applicable law, patient diagnosis); and 59 Health Level Seven Messaging Standard message, some patient event notification (4) sends notifications directly, or Version 2.5.1 (HL7 2.5.1), an Application Protocol implementations attach more detailed through an intermediary that facilitates for Electronic Data Exchange in Healthcare information to the message regarding exchange of health information, and at Environments, February 21, 2007.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00078 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25587

support implementation of patient event emergency room, and initiate outreach or work with an intermediary that notifications. We also recognized that to the patient to ensure that appropriate maintains information about care many hospitals, which have already follow-up for the emergency visit was relationships. In other cases, we noted implemented notifications, may be pursued. While we encouraged that hospitals may, directly or through delivering additional information hospitals to extend the coverage of their an intermediary, identify appropriate beyond the basic information included notification systems to serve additional notification recipients through the in the ADT message (both automatically patients, outside of those admitted and analysis of care patterns or other when a patient’s status changes and seen as inpatients, we also sought attribution methods that seek to then upon request from receiving comment on whether we should determine the provider most likely to be providers) to receiving practitioners, identify a broader set of patients to able to effectively coordinate care post- patient care team members, and post- whom this requirement would apply, discharge for a specific patient. The acute care services providers and and if so, how we should implement hospital or intermediary might also suppliers with whom they have such a requirement in a way that develop processes to allow a provider to established patient care relationships minimizes administrative burden on specifically request notifications for a and agreements for patient health hospitals. given patient for whom they are information exchange as allowed by Additionally, we proposed that the responsible for care coordination as law. We believe consensus standards for hospital would have to demonstrate that confirmed through conversations with ADT-based notifications may become its system sends notifications that the patient. more widely adopted in the future (we include the minimum patient health Additionally, we expected hospitals, refer readers to ONC’s ISA 60 for more information (specifically, patient name, psychiatric hospitals, and CAHs to information about standards under treating practitioner name, sending comply with the HIPAA Rules set out at consideration). However, at this time, institution name, and, if not prohibited 45 CFR parts 160 and 164 if these we stated that we did not wish to by other applicable law, patient proposed CoP requirements for patient restrict hospitals from pursuing more diagnosis). We proposed that the event notifications were finalized. As advanced content as part of patient hospital would also need to demonstrate required at 42 CFR 482.11 for hospitals notifications, nor to create redundant that the system sends notifications and psychiatric hospitals and at 42 CFR requirements where hospitals already directly, or through an intermediary that 485.608 for CAHs, these providers must have a suitable notification system in facilitates exchange of health comply with all pertinent currently place. Accordingly, while we specified information, at the time of the patient’s existing federal laws, including the that hospitals subject to the proposal hospital admission, discharge, or HIPAA Privacy and Security Rules. The possess a system utilizing this standard, transfer, to licensed and qualified Privacy Rule permits patient event we proposed that hospitals could utilize practitioners, other patient care team notifications as disclosures for treatment other standards or features to support members, and PAC services providers purposes (the proposed required their notification systems. We requested and suppliers that: (1) Receive the notifications, when finalized, also may comment on the proposal, including notification for treatment, care be treated as disclosures required by law whether this requirement would achieve coordination, or quality improvement (see 45 CFR 164.502(a)). the goal of setting a baseline for purposes; (2) have an established care We also recognized that factors hospitals’ capacity to generate relationship with the patient relevant to outside of the hospital’s control might information for electronic notifications, his or her care; and (3) the hospital has determine whether or not a notification while still allowing for innovative reasonable certainty that such was successfully received and utilized approaches that would potentially notifications are received. We noted that by a practitioner. Accordingly, we increase the effectiveness of these we believed the proposal would allow proposed that a hospital would only notifications toward improving patient for a diverse set of strategies that need to send notifications to those outcomes and safety during transitions hospitals might use when implementing practitioners for whom the hospital has in care. patient event notifications. reasonable certainty of receipt. While Through these provisions, we sought We further proposed that the hospital we stated that we expected hospitals to allow for different ways that a would need to demonstrate that the would, to the best of their ability, seek hospital might identify those system’s notification capacity was fully to ensure that notification recipients practitioners, other patient care team operational, that it operated in were able to receive notifications (for members, and PAC services providers accordance with all state and federal instance, by obtaining a recipient’s and suppliers that are most relevant to statutes and regulations regarding the Direct address 61 both the pre-admission and post- ), we understood that exchange of patient health information. discharge care of a patient. We proposed technical issues beyond the hospital’s We intended for these notifications to be that hospitals send notifications to those control could prevent successful receipt required, at minimum, for inpatients practitioners or providers that had an and use of a notification. admitted to, and discharged and/or Finally, we noted that hospitals have established care relationship with the transferred from the hospital. However, patient relevant to his or her care. We an existing responsibility under the we also noted that patient event recognized that hospitals and their CoPs at 42 CFR 482.43(d) to ‘‘transfer or notifications are an effective tool for partners may identify appropriate refer patients, along with necessary coordinating care across a wider set of recipients through various methods. For medical information, to appropriate patients that may be cared for by a instance, hospitals might identify facilities, agencies, or outpatient hospital. For instance, a patient event appropriate practitioners by requesting services, as needed, for follow-up or notification could ensure that a primary this information from patients or ancillary care.’’ We emphasized that the care physician was aware that his or her caregivers upon arrival, or by obtaining proposal regarding patient event patient had received care at the information about care team members notifications would be separate from the from the patient’s record. We expected 60 Office of the National Coordinator. (n.d.). 61 For more information about obtaining a Direct Admission, Discharge, and Transfer. Retrieved from hospitals might develop or optimize addresses, see https://www.healthit.gov/sites/ https://www.healthit.gov/isa/admission-discharge- processes to capture information about default/files/directbasicsforprovidersqa_ and-transfer. established care relationships directly, 05092014.pdf.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00079 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25588 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

requirement regarding necessary (1) Is fully operational and that it admission, discharge, and/or transfer to medical information at 42 CFR operated in accordance with all state another health care facility or to another 482.43(d). However, we recognized that and federal statutes and regulations community provider. processes to implement the proposal, if regarding the exchange of patient health We proposed to limit this requirement finalized, could intersect with the information; (2) utilizes the content to only those CAHs which currently hospital’s discharge planning process. exchange standard incorporated by possess EHR systems with the technical We noted that nothing in the proposal reference at 45 CFR 170.205(a)(4)(i); (3) would affect the hospital’s sends notifications that would have to capacity to generate information for responsibilities under 42 CFR 482.43(d). include the minimum patient health electronic patient event notifications, However, we noted if the proposal was information (specifically, patient name, defined as systems that utilize the finalized, hospitals might wish to treating practitioner name, sending content exchange standard incorporated consider ways to fulfill these institution name, and, if not prohibited by reference at 45 CFR 170.205(a)(4)(i). requirements in ways that reduce by other applicable law, patient We proposed that for a CAH that redundancy while still remaining diagnosis); and (4) sends notifications currently possessed an EHR system with compliant with existing requirements. directly, or through an intermediary that the capacity to generate the basic patient For instance, where appropriate and facilitates exchange of health personal or demographic information allowed by law, hospitals might seek to information, and at the time of the for electronic patient event (ADT) include required necessary medical patient’s admission to the hospital and notifications, compliance with the information within the same message as either immediately prior to or at the proposed standard within the Clinical a patient event notification. time of the patient’s discharge and/or records services CoP (42 CFR 485.638) transfer from the hospital. We requested C. Provisions for Psychiatric Hospitals would be determined by the CAH comment on the policy as part of this (42 CFR 482.61(f)) demonstrating that its system: (1) Is hospital proposal in section X.B. of the fully operational and that it operates in Medicare- and Medicaid-participating CMS Interoperability and Patient Access psychiatric hospitals must comply with accordance with all state and federal proposed rule (84 FR 7650 through statutes and regulations regarding the all of the hospital CoPs at 42 CFR 482.1 7652). through 482.23 and at 42 CFR 482.25 We also proposed that the hospital exchange of patient health information; through 482.57. They also must adhere would need to demonstrate that the (2) utilizes the content exchange to special provisions regarding medical system sends notifications directly, or standard incorporated by reference at 45 records at 42 CFR 482.61 and staffing through an intermediary that facilitates CFR 170.205(a)(4)(i); (3) sends requirements at 42 CFR 482.62. Since exchange of health information, and notifications that would have to include the medical records requirements are either immediately prior to or at the the minimum patient health information different for psychiatric hospitals, and time of the patient’s hospital admission, (specifically, patient name, treating since these hospitals do not have to discharge, or transfer, to licensed and practitioner name, sending institution comply with the regulations at 42 CFR qualified practitioners, other patient name, and, if not prohibited by other 482.24, we proposed a new electronic care team members, and PAC services applicable law, patient diagnosis); and notification standard at 42 CFR 482.61(f) providers and suppliers that: (1) Receive (4) sends notifications directly, or within the special provisions for the notification for treatment, care through an intermediary that facilitates psychiatric hospitals in this section. coordination, or quality improvement exchange of health information, and at Similar to the proposal for hospitals at purposes; (2) have an established care the time of the patient’s admission to 42 CFR 482.24(d), we proposed a new relationship with the patient relevant to the CAH and either immediately prior to standard at 42 CFR 482.61(f), his or her care; and (3) the hospital is or at the time of the patient’s discharge ‘‘Electronic Notifications,’’ that would reasonably certain will receive such require psychiatric hospitals to send and/or transfer from the CAH. We notifications. requested comment on the policy as part electronic patient event notifications of We referred readers to the extended a patient’s admission, discharge, and/or discussion of the proposals in sections of the hospital proposal in section X.B. transfer to another health care facility or X.A. and B. of the CMS Interoperability of the CMS Interoperability and Patient to another community provider. and Patient Access proposed rule (84 FR Access proposed rule (84 FR 7650 As we proposed for hospitals, we 7649 through 7652). We sought through 7652). proposed to limit this requirement to comment on these proposals. Additionally, we proposed that the only those psychiatric hospitals which CAH would need to demonstrate that currently possess EHR systems with the D. Provisions for CAHs (42 CFR 485.638(d)) the system sends notifications directly, technical capacity to generate or through an intermediary that information for electronic patient event We believe implementation of patient facilitated exchange of health notifications, defined as systems that event notifications are also important information, and at or immediately prior utilize the content exchange standard for CAHs to support improved care to the time of the patient’s CAH incorporated by reference at 45 CFR coordination from these facilities to admission, discharge, or transfer, to 170.205(a)(4)(i). We proposed that that other providers in their communities. licensed and qualified practitioners, for a psychiatric hospital that currently Therefore, similar to the proposals for possessed an EHR system with the the hospital and psychiatric hospital other patient care team members, and capacity to generate the basic patient medical records requirements as PAC services providers and suppliers personal or demographic information discussed in the preceding sections, we that: (1) Receive the notification for for electronic patient event (ADT) proposed to revise 42 CFR 485.638, by treatment, care coordination, or quality notifications, compliance with the adding a new standard to the CAH improvement purposes; (2) have an proposed standard within the Special Clinical records CoP at paragraph (d), established care relationship with the medical records requirements for ‘‘Electronic Notifications.’’ As patient relevant to his or her care; and psychiatric hospitals CoP (42 CFR discussed, the proposed standard would (3) the CAH is reasonably certain will 482.61) would be determined by the require CAHs to send electronic patient receive such notifications. hospital demonstrating that its system: event notifications of a patient’s

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00080 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25589

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00081 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25590 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00082 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25591

in this fashion was inconsistent with improving healthcare quality and patient event notification requirements congressional intent for how HHS safety.’’ 62 According to the authors of are premature or duplicative in relation should regulate the use of health IT. the review, evidence from a number of to the final discharge planning Commenters also noted that HHS is studies shows that health IT offers requirements for hospitals, CAHs, and currently seeking to establish a range of numerous opportunities for improving HHAs. new policies designed to advance the and transforming health care that Regarding concerns that it will be interoperable exchange of health includes the potential to reduce human challenging to update the CoPs to reflect information. Commenters believed these errors, improve clinical outcomes, changing technology requirements, our policies could have a significant impact facilitate care coordination, improve proposal sought to focus primarily on on the sharing of health information, practice efficiencies, and track data over functional requirements that will allow including the sharing of patient event time. Based on this evidence as well as hospitals the flexibility to pursue notifications, and that CMS should the evidence directly related to patient innovation and adapt their systems over refrain from rulemaking through the event notifications that we cited time, similar to other functional CoPs until these polices have been previously, we believe that the requirements under the Medical finalized. One commenter also noted requirements for patient event Records Services CoP. Where we do that, at the time the comment period on notifications that we have proposed and reference a specific standard, in order to the CMS Interoperability and Patient that we are finalizing in this rule will determine whether or not a hospital’s Access proposed rule closed, CMS’ have a positive impact on many of these system would be subject to the proposed Discharge Planning rule (80 FR 68125) same areas, especially regarding the ‘‘Electronic notifications’’ standard, we had not yet been finalized, and that it facilitation of care coordination for reference a content exchange standard at would be premature to add this patients, leading to improved outcomes 45 CFR 170.205(d)(2) common to many requirement in advance of finalizing and enhanced patient health and safety. EHRs that we believe is unlikely to related revisions to the discharge While we appreciate the importance undergo changes that would require planning section of the CoPs. of aligning policies across different frequent updates. Commenters further stated that HHS programs to minimize provider burden, Comment: Commenters stated that has a variety of other mechanisms for we believe that the proposed including these requirements under the advancing electronic information requirements are not addressed CoPs would significantly increase the exchange and improving the elsewhere and are appropriate for compliance burden for providers. infrastructure for exchange that would inclusion in the CoPs. Additionally, we Commenters believed that the proposed be more effective than adding disagree with commenters who stated policy was contrary to other recent HHS requirements to the CoPs. Several that the proposed requirements will burden reduction initiatives for commenters expressed concern that require hospitals to engage in providers. Commenters also believed using the CoPs would set static duplicative reporting on information that this proposal would add additional requirements that are ill-suited to an exchange since the proposed layers of regulation to what is a common evolving technology environment and requirements do not require hospitals practice for many hospitals today, the innovation needed to increase and CAHs to do any type of reporting further increasing provider burden. adoption of notifications across to CMS in order to comply with the Several commenters stated that CMS providers. requirements. We also understand that had underestimated the burden Response: We appreciate commenters’ other proposed or recently finalized associated with this proposal. They disagreed that implementing patient input. As noted above, we disagree with policies may be relevant to the proposed commenters who stated that the CoPs event notifications would be largely requirements in this rule; however, we are not an appropriate mechanism for limited to a one-time cost, and stated believe these policies will complement policy related to interoperability or the that there would be substantial work one another and serve to enable the use of health IT. Existing CoPs address required prior to implementing the proposed requirements around patient requirements related to medical records proposal and continuous work around event notifications. As we noted above systems as well as the transfer of health receiving notifications from other regarding the final rule published on information, and we believe there is no providers. Commenters suggested that September 30, 2019, Discharge Planning reason that these regulations should not CMS pursue other initiatives to alleviate final rule (84 FR 51836), the revised address technology issues where the use costs, such as standardizing the data set discharge planning CoPs do not require of technology may be relevant to patient for patient event notifications. health and safety, provided that such hospitals, CAHs, and HHAs to transfer Stakeholders also urged CMS to ensure references to technology in the CoPs do necessary patient medical information that providers have cost-effective not lead to ‘‘static requirements’’ as exclusively by electronic means, nor do choices for required technology noted by the commenter, and which we they require that providers notify the solutions, and to not create an believe we have avoided doing in both appropriate providers, suppliers, and environment that encourages over- the proposed and final rules. practitioners receiving the necessary pricing of solutions. Furthermore, while a 2017 review of the medical information of the patient’s Response: We appreciate commenters’ current available scientific evidence on discharge (or admission) as we are now concerns about additional provider the impact of different health are requiring in this final rule. We burden. While we understand that this information technologies on improving believe that the two rules, as written new requirement may impose some patient safety outcomes, warned that and finalized, do not conflict, but additional implementation burden on health care organizations ‘‘need to be instead complement and support each hospitals, commenters also expressed selective in which technology to invest other in CMS’ goal of improving patient that there are many ways for hospitals in, as literature shows that some care transitions. Therefore, we disagree to minimize this burden through the use technologies have limited evidence in with the comments stating that the of existing technologies and services, improving patient safety outcomes,’’ the such as health information exchanges 62 Alotaibi, Y., & Federico, F. (2017). The impact review also stated that there ‘‘should be of health information technology on patient safety. and other service providers which no doubt that health information Saudi Medical Journal, 38(12), 1173–1180. doi: capture notification information from a technology is an important tool for 10.15537/smj.2017.12.20631. hospital’s EHR and route it to

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00084 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25593

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00085 Fmt 4701 Sfmt 4700 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 and suppliers with whom the patient primary care practitioner is more likely patient event notification system, or has an established care relationship to lead to more accurate and timely through recording information received prior to admission or to whom the transfer of patient health information from patients about their providers. patient is being transferred or referred. from hospital-based practitioners to Comment: Commenters stated that Similar to our modification to reference community-based primary care obtaining information about providers the patient’s established primary care practitioners. Additionally, early who have an ‘‘established care practitioner, these PAC services identification of a patient’s primary care relationship’’ with a given patient and providers and suppliers would be those practitioner along with the patient event maintaining lists of these providers and with an established care relationship notification to the practitioner that his contact information for delivery of immediately preceding the hospital or her patient is about to be discharged patient event notifications would registration or admission (such as a PAC from the hospital is most likely to have impose significant burden on hospitals. services provider or supplier from a net positive effect on scheduled post- One commenter noted that patients may which the patient was transferred to the discharge follow-up rates for patients not reliably provide information about hospital) or those with which a most at risk for avoidable readmissions. their providers, and recommended that relationship is being established for We appreciate commenters concerns in those cases the recipient of the purposes of treatment and/or care about patient matching challenges. This patient event notification should coordination post-discharge from the is a larger issue beyond the scope of this identify their relationship with a patient hospital. The potential recipients of CoP proposal and this current rule, but in advance. patient event notifications will be we will consider this issue for future Several commenters noted that, to the limited to only those that need to revisions and updates to the CoPs. With extent hospitals already have receive notification of the patient’s the continued increase in the use of operational processes and infrastructure status for treatment, care coordination, electronic data in health care in place to determine destinations for or quality improvement purposes. We organizations and among providers of notifications, these processes should be believe that this final policy will reduce health care services, there has been a left in place. Several commenters noted potential operational burden associated continued need for patient matching, or that, in order to successfully route with a broader ‘‘established care patient identity management (PIM) messages to the appropriate provider, relationship’’ definition. We believe that processes, in health care organizations, hospitals would need to be able to increasing numbers of hospitals now including hospitals. PIM has been overcome challenges associated with commonly seek to identify patients’ defined as the ability to uniquely patient matching: The ability for a primary care practitioners and their ascertain the identity of a patient, assign hospital to accurately match records contact information, including any that patient’s record an identifier that is about a patient with the records held by digital contact information, or partner unique within the organization, system, a receiving provider. Commenters stated with intermediaries that identify or exchange network, and match that that challenges with patient matching primary care practitioners, and that patient’s record within and between could inhibit patient event notifications many hospitals will be able to continue systems using a number of demographic from being received by the correct to use their existing processes to satisfy data elements, such as the patient’s first provider and will lead to frequent the CoP. If a hospital has processes in name, last name, address, and date of pushback from providers about place for identifying patients’ primary birth. Effective PIM supports patient receiving notifications regarding care practitioners and other applicable identity integrity, which the National patients they are not affiliated with. providers, but is not able to identify an Association of Healthcare Access Commenters also noted the importance appropriate recipient for a patient event Management defines as accurately of community-wide directories that map notification for a specific patient, the identifying and matching the right the address of a provider to their hospital would not be expected to send patient with his or her complete electronic endpoint destination, which medical record, every time, in every a notification for that patient. 64 would allow a hospital to query a Research using CMS data on provider setting. Accurate patient directory and find the destination of the readmission rates in Medicare- identity management is critical to patient’s choice. participating hospitals from 2007 to successfully delivering the right care to Response: As noted, we are finalizing 2015 shows that the readmission rates the correct patients. a more limited minimum set of Capturing incorrect or incomplete for targeted conditions (that is, a set of recipients for patient event notifications data can result in critical patient care specific diagnoses measured by than originally proposed. This set of issues and risk privacy breaches. Health Medicare) declined from 21.5 percent to recipients is focused on a patient’s care organizations are more likely to 17.8 percent, and rates for non-targeted established primary care practitioner (or have their EHR system filled with conditions declined from 15.3 percent established primary care practice group duplicate patient records and inaccurate to 13.1 percent.63 While this decline in or entity) or any other practitioner (or information about their patients when readmissions rates is attributable to practice group or entity) identified by they are not managing an effective PIM multiple factors, we believe that one of the patient as primarily responsible for process. Having an ineffective PIM his or her care. However, we are the significant factors driving down process will most definitely negatively retaining inclusion in this final rule of avoidable patient readmissions is impact a hospital’s patient event PAC providers and suppliers as required identification by the hospital of the notification system, which is one of the recipients of notifications as originally patient’s established primary care many reasons why a rigorous PIM proposed. In order to clarify the PAC practitioner (or practice group) and his process is essential to patient care as services providers and suppliers that are or her contact information prior to health IT moves forward. Additionally, required recipients, we are modifying discharge and/or transfer. Increased and PIM has become crucial in order to (1) this proposal to refer to ‘‘all applicable early identification of the patient’s PAC services providers and suppliers.’’ 64 National Association of Healthcare Access 63 For purposes of this policy, applicable Alper, E., O’Malley, T.A., & Greenwald, J. Management. (2016, March 17). NAHAM Public (n.d.). Hospital discharge and readmission. Policy Statement on Patient Identity Integrity. PAC services providers and suppliers Retrieved from https://www.uptodate.com/ Retrieved from https://nahamnews.blogspot.com/ would be those PAC services providers contents/hospital-discharge-and-readmission. 2016/03/naham-public-policy-statement-on.html.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00086 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25595

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00088 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25597

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00090 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25599

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00092 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25601

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00094 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25603

482.61(f), and 485.638(d) are being • We are redesignating 42 CFR managed care entities, and QHP issuers finalized here with modifications and 482.24(d)(5), 482.61(f)(5), and on the FFEs to maintain a process for reorganization from the proposed 485.638(d)(5) as 42 CFR 482.24(d)(4), the electronic exchange of, at a requirements (84 FR 7678): 482.61(f)(4), and 485.638(d)(4), minimum, the data classes and elements • We are revising 42 CFR 482.24(d) respectively, and also revising the included in the content and vocabulary by deleting the reference to ‘‘paragraph regulatory text to state that, ‘‘to the standard finalized by HHS in the ONC (d)(2) of this section’’; extent permissible under applicable 21st Century Cures Act final rule • We are revising 42 CFR 482.61(f) by federal and state law and regulations, (published elsewhere in this issue of the deleting the reference to ‘‘paragraph and not inconsistent with the patient’s Federal Register) at 45 CFR 170.213 (d)(2) of this section’’; expressed privacy preferences, the (currently version 1 of the USCDI), via • We are revising 42 CFR 485.638(d) system sends notifications directly, or a payer-to-payer data exchanged as by deleting the reference to ‘‘paragraph through an intermediary that facilitates outlined in this section V. of this final (d)(2) of this section’’; exchange of health information, at the rule. Specifically, we are finalizing as • We are revising 42 CFR 482.24(d) time of: the patient’s discharge or proposed that impacted payers by adding new language to the transfer from the hospital’s [or CAH’s] incorporate the data they receive into regulatory text so that it now includes emergency department (if applicable): the enrollee’s record. We are finalizing ‘‘or other electronic administrative or the patient’s discharge or transfer that with the approval and at the system, which is conformant with the from the hospital’s [or CAH’s] inpatient direction of a current or former enrollee, services (if applicable).’’ a payer must send the defined content exchange standard at 45 CFR • 170.205(d)(2),’’; We are deleting the regulatory text information set to any other payer. In • We are revising 42 CFR 482.61(f) by proposed at 42 CFR 482.24(d)(5), addition, we specify that a payer is only adding new language to the regulatory 482.61(f)(5), and 485.638(d)(5) and obligated to send data received from text so that it now includes ‘‘or other adding new regulatory text to state that, another payer under this policy in the electronic administrative system, which ‘‘the hospital [or CAH] has made a electronic form and format it was is conformant with the content reasonable effort to ensure that the received. Starting January 1, 2022, and for QHP exchange standard at 45 CFR system sends the notifications to all applicable post-acute care services issuers on the FFEs starting with plan 170.205(d)(2),’’; providers and suppliers, as well as to years beginning on or after January 1, • We are revising 42 CFR 485.638(d) any of the following practitioners and 2022, the finalized regulation requires by adding new language to the entities, which need to receive these payers to make data available with regulatory text so that it now includes notification of the patient’s status for a date of service on or after January 1, ‘‘or other electronic administrative treatment, care coordination, or quality 2016 that meets the requirements of this system, which is conformant with the improvement purposes: the patient’s section and which the payer maintains. content exchange standard at 45 CFR established primary care practitioner; In this way, payers only have to prepare 170.205(d)(2),’’; the patient’s established primary care an initial historical set of data for • We are deleting all of the regulatory practice group or entity; or other sharing via this payer-to-payer data text proposed at 42 CFR 482.24(d)(2), practitioner, or other practice group or exchange policy that is consistent with 482.61(f)(2), and 485.638(d)(2), entity, identified by the patient as the the data set to be available through the including the inaccurate references to practitioner, or practice group or entity, Patient Access API, as finalized in ‘‘45 CFR 170.205(a)(4)(i);’’ primarily responsible for his or her section III. of this final rule. • We are redesignating 42 CFR care.’’ 2. Regarding the Patient Access API, 482.24(d)(3), 482.61(f)(3), and Finally, recognizing that hospitals, we are finalizing requirements for MA 485.638(d)(3) as 42 CFR 482.24(d)(2), including psychiatric hospitals and organizations, Medicaid and CHIP FFS 482.61(f)(2), and 485.638(d)(2), CAHs, are on the front lines of the programs, Medicaid managed care respectively, and also revising the COVID–19 public health emergency, plans, CHIP managed care entities, and regulatory text to now state that the and in response to the number of QHP issuers on the FFEs to implement system sends notifications that must comments received regarding concerns and maintain a standards-based Patient include at least patient name, treating with the applicability date for this rule, Access API that meets the technical practitioner name, and sending we are establishing an applicability date standards as finalized by HHS in the institution name; ONC 21st Century Cures Act final rule • of 12 months after finalization of this We are redesignating 42 CFR rule for hospitals, including psychiatric (published elsewhere in this issue of the 482.24(d)(4), 482.61(f)(4), and hospitals, and CAHs to allow for Federal Register) at 45 CFR 170.215, 485.638(d)(4) as 42 CFR 482.24(d)(3), adequate and additional time for these that include the data elements specified 482.61(f)(3), and 485.638(d)(3), institutions, especially small and/or in this final rule, and that permit third- respectively, and also revising the rural hospitals as well as CAHs, to come party applications to retrieve, with the regulatory text to now state that, ‘‘to the into compliance with the new approval and at the direction of a extent permissible under applicable requirements. current enrollee, data specified at 42 federal and state law and regulations, CFR 422.119, 431.60, 457.730, and 45 and not inconsistent with the patient’s XI. Provisions of the Final Regulations CFR 156.221. Specifically, we are expressed privacy preferences, the Generally, this final rule incorporates finalizing that the Patient Access API system sends notifications directly, or the provisions of the CMS must, at a minimum, make available through an intermediary that facilitates Interoperability and Patient Access adjudicated claims; encounters with exchange of health information, at the proposed rule as proposed. The capitated providers; provider time of: the patient’s registration in the following provisions of this final rule remittances; enrollee cost-sharing; and hospital’s [or CAH’s] emergency differ from the proposed rule. clinical data, including laboratory department (if applicable); or the We are finalizing four proposals with results (where maintained by the patient’s admission to the hospital’s [or modifications. impacted payer). We are not finalizing CAH’s] inpatient services (if 1. We are requiring MA organizations, a requirement to include Provider applicable).’’ Medicaid managed care plans, CHIP Directory information as part of the

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00095 Fmt 4701 Sfmt 4700 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 Modifications being finalized for the • The accuracy of our estimate of the burden, we are only requiring provider timelines for these policies will provide information collection burden. and, in the case of MA–PD plans, impacted payers ample time to build • The quality, utility, and clarity of pharmacy directory information, be and test the required standards-based the information to be collected. APIs to meet the new API requirements. included in the Provider Directory API • Recommendations to minimize the In addition, providing more time for discussed in section IV. of this final information collection burden on the payer-to-payer data exchange between rule. Data via the Patient Access API affected public, including automated impacted payers will ensure successful must be made available no later than collection techniques. one (1) business day after a claim is implementation, and better enable plans We solicited public comment on each adjudicated or encounter data are to use a standards-based API to meet this requirement if they so choose. We of these issues for the following sections received by the impacted payer. We are of this document that contain finalizing that MA organizations, are not finalizing the Care Coordination through Trusted Exchange Networks information collection requirements Medicaid state agencies, Medicaid (ICRs): managed care plans, CHIP state proposal. Although some commenters agencies, and CHIP managed care did show support for the proposal, A. Background entities must make available the date others raised strong concerns. Given the concerns commenters raised specifically Payers should have the ability to they maintain with a date of service on regarding the need for a mature TEFCA exchange data instantly with other or after January 1, 2016 beginning to be in place first, and appreciating the payers for care and payment January 1, 2021, and for QHP issuers on ongoing work on the TEFCA being done coordination or transitions, and with the FFEs beginning with plan years at this time, we are not finalizing this providers to facilitate more efficient beginning on or after January 1, 2021. trusted exchange proposal in this rule. care. Payers are in a unique position to 3. We are finalizing a Provider 4. We are finalizing the Revisions to provide patients a complete picture of Directory API for MA organizations, the Conditions of Participation for their claims and encounter data, Medicaid state agencies, Medicaid Hospitals and Critical Access Hospitals allowing patients to piece together their managed care plans, CHIP state proposal with modifications that are own information that might otherwise agencies, and CHIP managed care based on public comments. be lost in disparate systems. To advance entities making standardized Additionally, and based on strong our commitment to interoperability, we information about their provider support from commenters, we are are finalizing our proposals for the networks available via a FHIR-based API including patient event notification Patient Access API, the Provider conformant with the technical standards requirements for any patient who Directory API, and the payer-to-payer finalized by HHS in the ONC 21st accesses services in a hospital (or CAH) data exchange as discussed above. Century Cures Act final rule (published emergency department. In response to We noted that these proposals were elsewhere in this issue of the Federal the number of comments received designed to empower patients by Register) at 45 CFR 170.215 (which regarding concerns with the applicable making sure that they have access to include HL7 FHIR Release 4.0.1), date for this policy, we are finalizing an health information about themselves in excluding the security protocols related applicability date of 12 months after a usable digital format and can make to user authentication and publication of this rule for hospitals, decisions about how, with whom, and authorization, or any other protocols including psychiatric hospitals, and for what uses they will share it. By that restrict the availability of this CAHs to allow for adequate time for making claims data readily available information to anyone wishing to access these institutions, especially small and/ and portable to the enrollee, these it. At a minimum, these payers must or rural hospitals as well as CAHs, to initiatives supported efforts to reduce make available via the Provider come into compliance with the new burden and cost and improve patient Directory API provider names, requirements. care by reducing duplication of services, All other policies are being addresses, phone numbers, and adding efficiency to patient visits to substantially finalized as proposed. specialties. For MA organizations that providers; and, facilitating identification offer MA–PD plans, they must also XII. Collection of Information of fraud, waste, and abuse. make available, at a minimum, Requirements B. Wage Estimates pharmacy directory data, including the Under the Paperwork Reduction Act pharmacy name, address, phone of 1995, we are required to provide 30- To derive average costs, we used data number, number of pharmacies in the day notice in the Federal Register and from the U.S. Bureau of Labor Statistics’ network, and mix (specifically the type solicit public comment before a (BLS) May 2018 National Occupational of pharmacy, such as ‘‘retail collection of information requirement is Employment and Wage Estimates pharmacy’’). This Provider Directory submitted to the Office of Management (https://www.bls.gov/oes/current/oes_ API must be fully implemented by and Budget (OMB) for review and nat.htm). Table 1 presents the mean January 1, 2021 for all payers subject to approval. In order to fairly evaluate hourly wage, the cost of fringe benefits this new requirement. Under this final whether an information collection (calculated at 100 percent of salary), and rule, MA organizations, Medicaid and should be approved by OMB, section the adjusted hourly wage. In the CMS CHIP FFS programs, Medicaid managed 3506(c)(2)(A) of the Paperwork Interoperability and Patient Access care plans, and CHIP managed care Reduction Act of 1995 requires that we proposed rule, Table 1 was based on the entities must make the Provider solicit comment on the following issues: latest 2017 wage data (84 FR 7658). In Directory API accessible via a public- • The need for the information this final rule, we have updated Table facing digital endpoint on their website collection and its usefulness in carrying 1 to reflect 2018 wage data, which is to ensure public discovery and access. out the proper functions of our agency. now the latest available data.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00096 Fmt 4701 Sfmt 4700 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

Mean Adjusted Occupation hourly Fringe hourly Occupation title code wage benefit 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 Technician ...... 29–2071 21.16 21.16 42.32 Medical and Health Service Managers ...... 11–9111 54.68 54.68 109.36

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00097 Fmt 4701 Sfmt 4700 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 allow multiple methods for electronic required to implement the requirements categories and number of hours required exchange of the information, including of this final rule. We understand that to implement the API provisions (84 FR use of the APIs. Although we our estimates regarding the 7659). We originally estimated a one- considered requiring the use of the implementation of the API provisions time burden of $789,356.00 per FHIR-based API, we understood that may vary depending on a number of organization or state per some geographic areas might have a factors, including, but not limited to a implementation, with an ongoing regional health information exchange payer’s current knowledge of and maintenance cost $158,359.00 per that could coordinate such transactions. experience with implementing FHIR- organization or state (84 FR 7659). We We also noted other ways to exchange based APIs, and whether an impacted noted that, in the initial design phase, this data, such as: Direct plan-to-plan payer will develop this technology in- we believed tasks would include: exchange; leveraging connections to house or seek a third party contractor to Determining available resources HIEs, or beneficiary-facing third-party support this effort. (personnel, hardware, cloud space, etc.); applications. Since the requirements for To further develop our cost estimates, assessing whether to use in-house the payer-to-payer data exchange and we reviewed the cost estimates resources to facilitate an API connection the API provisions share a content and associated with updating Blue Button or contract the work to a third party; vocabulary standard and because plans from Blue Button 1.0 to 2.0 to include convening a team to scope, build, test, will be investing in the development of a standards-based API, similar to the and maintain the API; performing a data the APIs in this final rule, we believe requirements of this final rule. This availability scan to determine any gaps that plans would overwhelmingly use update was estimated at $2 million. between internal data models and the these APIs to meet the payer to payer However, we believe that the estimates data required for the necessary FHIR data exchange requirements. As we had associated with updating the existing resources; and, mitigating any gaps no reliable way to determine which Blue Button 1.0 to a standards-based discovered in the available data. plans would utilize any of the available API for Blue Button 2.0 do not During the development and testing methods to meet the payer-to-payer data accurately represent the costs for payers phase, we noted that plans and states exchange requirement or how to impacted by this final rule. Blue Button would need to conduct the following: determine the cost of each of these 1.0 was developed across several federal Map existing data to HL7 66 FHIR methods, given that each plan could be agencies, including the Departments of standards, which would constitute the at a different technology maturity level, Defense, Health and Human Services, bulk of the work required for we accounted for costs for all impacted and Veterans Affairs, with a capability implementation; allocate hardware for payers assuming the use of a newly to allow beneficiaries online access to the necessary environments developed API to implement the payer- their own personal health records, such (development, testing, production); to-payer data exchange requirements, as as the ability to download PDF build a new FHIR server or leverage this would account for a higher effort documents. Unlike the standards-based existing FHIR servers; determine the options, and included this in our APIs required under this final rule, Blue frequency and method by which original estimates for the API Button 1.0 was not originally developed internal data are populated on the FHIR provisions. with a prescribed set of standards that server; build connections between the We summarize the public comments allow for third-party apps to connect databases and FHIR server; perform we received on concerns raised and retrieve data via an API. The capability and security testing; and vet regarding our proposed cost of estimates for Blue Button account for third-party applications, which includes implementing and maintaining the APIs upgrading an existing technology potentially asking third-party and provide our responses. platform that was not originally Comment: Some commenters applications to attest to certain privacy developed to allow third-party app expressed concern that CMS provisions. access via an API, which we believe underestimated the complexity of After the completion of the API adds additional cost that may not implementing the API requirements and development, plans and states would impact all payers under this final rule. did not agree with the agency’s need to conduct the following Additionally, we note that costs related estimation that the API implementation throughout each year: Allocate to federal procurement and the need to is a one-time cost. These commenters resources to maintain the FHIR server, engage multiple contractors to noted that additional costs include: The implement the updates to Blue Button, which includes the cost of maintaining costs to contract with third-party while at the same time maintaining the necessary patient data, and perform applications, the costs of ongoing access to the original system, caused the capability and security testing. education, and the cost of answering In the proposed rule, we proposed a cost of implementing standards-based questions from members about data and new requirement for MA plans, APIs for Blue Button 2.0 to be higher errors. Commenters argued that the than those costs for payers impacted by Medicaid managed care plans, CHIP proposed API requirements significantly this final rule. Therefore, we believe managed care entities, and QHP issuers add to overhead costs and will increase that the estimates for upgrading Blue on the FFEs to maintain a process to costs for providers and payers, rather Button from 1.0 to 2.0 are not truly coordinate care between plans by than facilitate information exchange and representative of the cost to implement exchanging, at a minimum, the USCDI better care for patients. One commenter the standards-based API required by this at the enrollee’s request (84 FR 7640). estimated a range of between $1 million final rule, but nonetheless are valuable Originally, we noted that we would and $1.5 million to implement the API in further informing our cost estimates. requirements, with an additional As noted above, we did receive one 66 Health Level Seven International (HL7®) is a not-for-profit, ANSI-accredited standards $200,000 to maintain the API. Another comment that suggested a cost range development organization (SDO) focused on commenter argued that the costs of between $1 million and $1.5 million to developing consensus standards for the exchange, implementation could be as high as four implement the API requirements of this integration, sharing, and retrieval of electronic times the estimates CMS provided. final rule, with another commenter health information that supports clinical practice and the management, delivery and evaluation of Response: We thank commenters for indicating a four-fold increase in costs health services. Learn more at ‘‘About HL7’’ web their input and understand their relative to the estimates included in the page, last accessed June 27, 2018. concerns associated with the cost proposed rule. While disagreeing with

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00098 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25607

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00099 Fmt 4701 Sfmt 4700 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

Mean Adjusted First year Occupation hourly Fringe hourly First year hours First year Maintenance Occupation title code wage benefit wage hours (primary hours hours ($/hr) ($/hr) ($/hr) (low estimate) estimate) (high 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 Infor- mation 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 Infor- mation Systems Managers ...... 11–3021 73.49 73.49 146.98 720 1440 2160 90 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 Com- puter Systems Ad- ministrators ...... 15–1142 41.86 41.86 83.72 ...... 0 0 420 Total Hours per System ...... 8,400 16,800 25,200 1,710 Total Cost per system (Dol- lars) (millions) ...... 788,414 1,576,829 2,365,243 157,657 Total hours for 345 Organiza- tions (hours)...... 2,898,000 5,796,000 8,694,000 589,950 Total Cost for 345 Organiza- tions (millions $) ...... 272,002,968 544,005,936 816,008,904 54,391,527

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00100 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25609

practitioner, or practice group or entity, we also note there is substantial per facility is anticipated to be 35 hours, primarily responsible for his or her care. agreement that implementation of these or approximately $1,682.32 ((16 hours * These requirements will help support basic messaging and notification $42.32/hour * 2 health information coordination of a patient’s care between functions within such existing systems technicians) + (3 hours * $109.36/hour settings or with services received constitutes a relatively low cost burden * 1 manager)). We assume that the through different care settings. for providers, particularly when such ongoing burden associated with Electronic patient event notifications costs are considered alongside the maintenance of these systems would be from these care settings, or clinical innovative and beneficial patient care approximately one quarter of these event notifications, are one type of transition solutions and models for best amounts for the 2 medical records and health information exchange practices they provide. health information technicians, or 4 intervention that has been increasingly Although we do not have current data hours each, for a total of 8 hours and recognized as an effective and scalable on how many facilities are already $338.56 per facility (4 hours * $42.32/ tool for improving care coordination transmitting electronic patient event hour * 2 health information across settings. These notifications are notifications, 59 percent of hospitals technicians). typically automated, electronic were found to be routinely In this lower-bound scenario, we communications from the admitting or electronically notifying a patient’s estimate that the total first-year burden discharging provider to applicable post- primary care provider upon his or her for hospitals and psychiatric hospitals is acute care services providers and entry to the hospital’s emergency approximately 48,720 hours (35 hours * suppliers, and also to community department in 2015, which is an over 50 1,392 hospitals) or $2,341,789 practitioners identified by the patient, percent increase since 2012.68 By using ($1,682.32 * 1,392 hospitals). In that alert the receiving providers or this historical data to plot a power trend subsequent years, we estimate the community practitioners that a patient line (R-Squared: 0.9928), we estimate burden is approximately 11,136 hours (8 is receiving, or has received, care at a that approximately 71 percent of hours * 1,392 hospitals) or $471,276 different setting. hospitals may have been routinely ($338.56 * 1,392 hospitals). These notifications are frequently transmitting patient event notifications For CAHs we estimate that the total based on ‘‘admission, discharge, and by 2018; therefore, we assume that 29 first-year burden is approximately transfer (ADT)’’ messages, a standard percent of hospitals, or approximately 13,790 hours (35 hours * 394 CAHs) or message used within an EHR as the 1,392, will incur costs associated with $662,834 ($1,682.32 * 394 CAHs). In vehicle for communicating information updating or configuring their respective subsequent years, we estimate the about key changes in a patient’s status EHR systems for electronic patient event burden for CAHs is approximately 3,152 as they are tracked by the system (more notifications. While we do not have hours (8 hours * 394 CAHs) or $133,393 information about the current standard parallel data for CAHs, we assume that ($338.56 * 394 CAHs). supporting these messages is available a similar percentage, or approximately Due to the amount of uncertainty at http://www.hl7.org/implement/ 394 CAHs, will incur this burden. We standards/product_brief.cfm?product_ involved in these estimates, we are also note that this upwards trend of patient presenting estimates for a scenario in id=144). As noted in the ISA published event notification adoption may by ONC, this messaging standard has which the number of hospitals that continue to some unknown extent routinely electronically notify primary been widely adopted across the health absent this final rule; however, we are care system (see https://www.healthit. care providers both inside and outside limiting our projection of hospitals that of the hospital’s system is assumed to gov/isa/sending-a-notification-a- are most affected by these requirements patients-admission-discharge-andor- have remained static at the 2015 rate of to 2018 due to the amount of 29 percent. This upper-bound scenario transfer-status-other-providers). uncertainty involved in quantifying this We continue to believe that care would indicate that in 2018 burden. approximately 3,407 hospitals and 964 coordination can have a significant We assume that this process will CAHs did not routinely utilize patient positive impact on the quality of life, primarily require the services of two event notification, and therefore several consumer experience, and health medical records and health information thousand additional providers would outcomes for patients. As we have noted technicians at approximately $42.32/ incur the previously estimated burden in the preamble to this rule, virtually all hour for 16 hours each, and 3 hours of per facility. EHR systems (as well as older legacy time from a medical and health services For the purposes of the PRA, we are electronic administrative systems, such manager at approximately $109.36/hour, assuming the midpoint of this range of as electronic patient registrations including the costs of overhead and effects. In this scenario 2,400 hospitals systems, and which we are including in fringe benefits. Thus, the total burden this final rule) generate information to and psychiatric hospitals, and 679 support the basic messages commonly 68 Office of the National Coordinator. (n.d.). CAHs would incur the estimated used for electronic patient event Hospital Routine Electronic Notification: Percent of burden. The burden estimates notifications. While we acknowledge U.S. Hospitals that Routinely Electronically Notify associated with the revised CoPs are Patient’s Primary Care Provider upon Emergency detailed in Table 3. This information that some level of implementation cost Room Entry, 2015. Retrieved from https:// would be realized for those providers dashboard.healthit.gov/quickstats/pages/FIG- collection will be submitted to OMB not already transmitting notifications, Hospital-Routine-Electronic-Notification.php. under OMB Control Number 0938–New.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00101 Fmt 4701 Sfmt 4700 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 CAHs Subsequent Subsequent Year 1 years Year 1 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

Total labor Burden per Total annual Hourly labor Total labor cost Regulation OMB control No. Number of Number of response burden cost of cost 1st subsequent section(s) respondents responses (hours) (hours) reporting year years ($) ($) ($)

§ 423.910 ...... 0938–0958 * ...... 36 36 960 34,560 $90.02 3,111,091 3,111,091 § 422.119, 0938–New ...... 345 345 16,800 5,796,000 Varies 544,005,936 0 § 431.60, § 457.730, § 438.242, § 457.1233 and § 156.221. § 422.119, 0938–New ...... 345 345 1,710 589,950 Varies ...... 54,391,527 § 431.60, § 457.730, § 438.242, § 457.1233, and § 156.221. § 482.24(d) and 0938–New ...... 2,400 2,400 35 84,000 Varies 4,037,568 ...... § 482.61(f). § 482.24(d) and 0938–New ...... 2,400 2,400 8 19,200 Varies ...... 812,544 § 482.61(f). § 485.638(d) ...... 0938–New ...... 679 679 35 23,765 Varies 1,142,295 ...... § 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 communicate, exchange, and interpret that ultimate goal of empowering their data in a usable and readable format, enrollees. As technology has advanced, A. Statement of Need such as PDF or text, is vital, but we have encouraged states, payers, and As described in detail in section III. allowing access to health care data providers to adopt various forms of of this rule, the changes to 42 CFR parts through PDF and text format also limits technology to improve the accurate and 422, 431, 438, 457, and 45 CFR part 156 the utility and sharing of data. Moving timely exchange of standardized health are part of the agency’s broader efforts to a system in which patients have care information. The policies in this to empower patients by ensuring that access to their health care data will help final rule enable patients to be active they have full access to their own health empower them to make informed partners in the exchange of electronic care data, through common technologies decisions about their health care, as health care data by easily monitoring or and without special effort, while well as share their data with providers sharing their data. keeping that information safe and who can assist these patients with their States and CMS routinely exchange secure. Interoperability and the health care. The policies are designed to data on who is enrolled in Medicare, capability for health information move Medicare, MA, Medicaid, CHIP, and which parties are liable for paying systems and software applications to and QHP issuers on the FFEs further to that beneficiary’s Parts A and B

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00102 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25611

premiums. These ‘‘buy-in’’ data MMA file data, with CMS by April 1, by the $100 million threshold, and exchanges support state, CMS, and SSA 2022. hence also a major rule under the premium accounting, collections, and Congressional Review Act. Accordingly, B. Overall Impact enrollment functions. We have become we have prepared an RIA that to the best increasingly concerned about the We have examined the impacts of this of our ability presents the costs and limitations of monthly buy-in data final rule as required by Executive benefits of the rulemaking. Table 5 exchanges with states. The relatively Order 12866 on Regulatory Planning summarizes the estimated costs long lag in updating buy-in data means and Review (September 30, 1993), presented in section XII. of this final that the state is not able to terminate or Executive Order 13563 on Improving rule. activate buy-in coverage sooner, so the Regulation and Regulatory Review In the proposed rule, we provided state or beneficiary may be paying (January 18, 2011), the Regulatory detailed estimations of the required premiums for longer than appropriate. Flexibility Act (RFA) (September 19, labor categories and number of hours We note that once the data catch up, 1980, Pub. L. 96–354), section 1102(b) of required to implement standards-based states and CMS reconcile the premiums the Social Security Act, section 202 of APIs (84 FR 7659). We originally by recouping and re-billing, so the Unfunded Mandates Reform Act of estimated a one-time burden of premiums collected are ultimately 1995 (March 22, 1995; Pub. L. 104–4), $789,356 per organization or state, per accurate, but only with an Executive Order 13132 on Federalism implementation, with an ongoing administratively burdensome process (August 4, 1999), the Congressional maintenance cost $158,359.80 per involving debits and payments between Review Act (5 U.S.C. 804(2)), and organization or state (84 FR 7659). As the beneficiary, state, CMS, SSA, and Executive Order 13771 on Reducing we detailed in section XII., to account potentially providers. Daily buy-in data Regulation and Controlling Regulatory for additional information commenters exchange will reduce this Costs (January 30, 2017). presented regarding our costs estimates, administrative burden. Executive Orders 12866 and 13563 we are adjusting our original cost States submit data on files at least direct agencies to assess all costs and estimates to reflect a range, instead of a monthly to CMS to identify all dually benefits of available regulatory point estimate. Our original estimate for eligible individuals, including full- alternatives and, if regulation is the initial one-time cost to implement benefit and partial-benefit dually necessary, to select regulatory the API requirements of this final rule eligible beneficiaries (that is, those who approaches that maximize net benefits of $788,414 per organization will now get Medicaid help with Medicare (including potential economic, serve as a minimum estimate. We have premiums, and often for cost-sharing). environmental, public health and safety increased our primary cost estimate by The MMA file was originally developed effects, distributive impacts, and a factor of 2 to an initial one-time cost to meet the need to timely identify equity). Section 3(f) of Executive Order of $1,576,829 per organization or state. dually eligible beneficiaries for the then- 12866 defines a ‘‘significant regulatory Additionally, we are increasing our new Medicare Part D prescription drug action’’ as an action that is likely to original cost estimate by a factor of 3 for benefit. Over time, we use these files’ result in a rule: (1) Having an annual an initial one-time cost of $2,365,243 data on dual eligibility status to support effect on the economy of $100 million per organization or state to serve as a Part C capitation risk-adjustment, and or more in any 1 year, or adversely and high estimate (detailed cost estimates most recently, feeding dual eligibility materially affecting a sector of the are located in Table 5). status to Part A and B eligibility and economy, productivity, competition, Table 5 reflects updated wages for claims processing systems so providers, jobs, the environment, public health or 2018, the latest available from the suppliers, and beneficiaries have safety, or state, local or tribal Bureau of Labor Statistics (BLS) website; accurate information on beneficiary governments or communities (also the CMS Interoperability and Patient cost-sharing obligations. As CMS now referred to as ‘‘economically Access proposed rule used 2017 wage utilizes MMA data on dual eligibility significant’’); (2) creating a serious estimates. Nevertheless, the change in status in systems supporting all four inconsistency or otherwise interfering total impact was small. We note that parts of the Medicare program, it is with an action taken or planned by estimates below do not account for becoming even more essential that dual another agency; (3) materially altering enrollment growth or higher costs eligibility status is accurate and up-to- the budgetary impacts of entitlement associated with medical care. This is date. Dual eligibility status can change grants, user fees, or loan programs or the because the cost of requirements to at any time in a month. Waiting up to rights and obligations of recipients implement patient access through APIs a month for status updates can thereof; or (4) raising novel legal or and for states to comply with data negatively impact access to the correct policy issues arising out of legal exchange requirements are not impacted level of benefit at the correct level of mandates, the President’s priorities, or by enrollment growth or higher costs payment. As described in detail in the principles set forth in the Executive associated with medical care. Per OMB section VII. of this rule, the changes to Order. guidelines, the projected estimates are 42 CFR parts 406, 407, and 423 establish A regulatory impact analysis (RIA) expressed in constant-year dollars (in frequency requirements that necessitate must be prepared for major rules with this case, using 2018 prices and wages). all states to participate in daily economically significant effects ($100 Table 5 forms the basis for allocating exchange of buy-in data, and updates million or more in any 1 year). We costs by year and program to the federal frequency requirements to require all estimate that this rulemaking is government, state Medicaid agencies, states to participate in daily exchange of ‘‘economically significant’’ as measured and parent organizations.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00103 Fmt 4701 Sfmt 4700 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 Patient care access API coordination (low Percent of estimate) Months in 25 month Patient Patient Total cost Total cost Total cost year for window for § 422.119, access API access API (low (primary (high compliance compliance Regulatory § 406.26, § 431.60, (primary (high estimate) estimate) estimate) for dual with dual text § 407.40, § 438.242, estimate) estimate) eligible eligible § 423.910 § 457.730, provisions provisions § 457.123, § 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: costs by payer since we do not have • Table 7 then allows us to obtain As stated in section XII. of this final internal data for each parent proportions of total costs for this final rule, cost estimates have been organization on how it allocates costs by rule by payer (Table 8); aggregated at the parent organization program; • Since we know the way federal level because we believe that an • Therefore, to approximate costs we payments for both Medicare and organization that offers QHPs on the developed approximated proportions of Medicaid are calculated, we can then FFEs, Medicare, Medicaid, and CHIP obtain total costs by payer incurred by products would create one system that total cost of each parent organization by payer (Medicare, Medicaid, CHIP, and the federal government (Table 9); would be used by all ‘‘plans’’ to whom • Individual market, including individual We next subtracted federal it offers access to data via APIs. We note payments by payer (Table 9) from total that due to the implementation of APIs market plans sold on and off the Exchanges, as we expect that, among costs by payer (Table 8) to obtain the across multiple business lines, there is non-federal costs of this final rule by parent organizations of issuers that offer no straightforward method to payer (Table 10); immediately estimate parent QHPs on the FFEs, costs will be passed • Table 11 presents the same data as organization expenditures on how much on through all plans the issuers offer in Table 10; Table 10 presents total non- of the cost is born by each payer. the individual market. Since this rule federal costs per payer, while Table 11 Although this section provides such does not apply to QHP issuers offering presents average non-federal costs per estimates it is important to understand QHPs only on Federally-facilitated enrollee per payer; how they are arrived at. A summary by Small Business Health Options Program • Table 12 presents the same data as Table in this section is provided in Exchanges (FF–SHOPs) they were not Table 9; while Table 9 presents total Table 6. As shown in Table 6: included in our analysis. • costs to the federal government by We first ascertain total costs of • implementing this final rule by Our use of available data includes payer, Table 12 presents average federal provision in (Table 5); many approximations due to data costs per enrollee by payer; and • As indicated earlier, we have no limitations discussed in detail below • Table 13 lists potential means for straightforward way of ascertaining total (Table 7); 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) ...... Costs are fully developed in the Collection of Informa- tion section of this final rule (section XII. of this final rule). 7 ...... Proportion of premiums by program (2016–2018) used, There is no straightforward way to directly assess par- in later tables, as a proxy for proportion of cost by ent organization cost by payer. Therefore, for each program. payer we develop approximate percentages of cost per payer. 8 ...... API costs total cost by year and Program (Medicare, We obtain the total API costs for this final rule per pro- Medicaid, Individual market plans, and CHIP). This gram by multiplying the API costs (for all programs) total cost is divided by cost to the federal government of this final rule (Table 5) by the proportion of pre- (Table 9) and non-federal costs to plans and enroll- miums presented in Table 7. ees (Table 10).

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 pro- Based on how federal payments are calculated in Medi- gram and year. care and Medicaid, we have projected federal propor- tions of the total cost and these are applied to Table 8 to obtain Table 9. 10 ...... Non-federal total costs for API by program by year ...... Table 9 = Table 8–Table 10—non-federal costs are ob- tained by subtracting federal costs (Table 9) from total costs (Table 8). 11 ...... Average non-federal cost per enrollee per year by pro- Tables 11 and 10 present the same data in different gram for plans. forms. Table 10 presents total non-federal cost by program for states and plans, while Table 11 pre- sents average non-federal costs per enrollee per year for states and plans. 12 ...... Average federal cost per enrollee per year by program Tables 12 and 9 present the same data in different for the federal government. forms. Table 9 presents total cost to the federal gov- ernment (due to matching programs), while Table 12 presents average cost per enrollee to the federal government. 13 ...... How payers would defray the remaining costs ...... 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 as the total national CHIP enrollment is omit state agencies, we believe that the provides several detailed estimates of currently only about 7 million. 70 percent of Medicaid enrollees cost by payer (Table 7); we also account Similarly, except for one state, CHIP enrolled in Medicaid managed care for federal matching for Medicaid and programs are run through the state provides a good approximation. payments by the Trust Fund for Medicaid agency; again, there would be Individual and small group market Medicare Advantage organizations one interoperability cost for the one plans: The MLR files contain data on all (Table 9); we indicate remaining burden state agency since the resulting software commercial parent organizations on plans (Tables 10, 11) and how they and systems would be used both for whether these organizations have other might account for it (Table 12). Medicaid and CHIP. Thus, while we are lines of business, such as Medicare However, these estimates are leaving out CHIP programs in this Advantage or Medicaid, or not. In approximate as explained in detail analysis since they are not in the CMS discussing commercial plans, we below. MLR files, we do not believe this account for: (A) Large group market Data Sources for Cost by Payer: To materially alters the overall picture. plans; (B) small group market plans, obtain allocation of cost by payer we Medicare Advantage: We compared including SHOP plans; (C) individual used the CMS public use files for MLR the CMS MLR files with the CMS market Exchange plans; and (D) data, for 2016.69 The MLR data sets are Trustee Report.70 According to the individual market off-Exchange plans. for private insurance plans but the Trustee Report (Table IV.C2), total MA • We have carved out the large issuers of that private insurance in revenue for 2016 was $189.1 billion. employer plans since the provisions of many cases also have contracts to Thus, the reported amount in the CMS this final rule do not apply to them, and provide MA, Medicaid, and CHIP MLR files of $157 billion for MA we do not believe that parent managed care plans and report revenue, represents 83 percent (157/189.1) of all organizations would pass on costs for expense, and enrollment data for these MA activity reflected in the Trustee individual and small group market plans on the private insurance MLR Report. Therefore, we believe the plans to large group employer- reporting form. proportions obtained from these MLR sponsored plans. Thus, these MLR data sets omit files are accurate. • We have noted that the provisions organizations that only have Medicare Medicaid: For the year for which of this final rule do not apply to QHP these MLR files provide data (2016), or Medicaid. The data from the CMS issuers offering QHPs only on FF– about 70 percent of Medicaid enrollees MLR files also omit: (1) The CHIP SHOPs, so we are not including small were enrolled in Medicaid managed program; and (2) state Medicaid group market plans in this analysis. care.71 Thus, although the MLR files agencies. We now discuss these • We believe it is reasonable, that omissions to assess the accuracy of even though the provisions of this final 70 See Table IV.C2 in, Boards of Trustees (Federal using these MLR files. Hospital Insurance and Federal Supplementary rule do not apply to off-Exchange CHIP: Eighty-five percent of the 194 Medical Insurance Trust Funds). (2018, June 5). The individual market plans, issuers subject CHIP managed care plans also offer 2018 Annual Report of The Boards of Trustees of to this rule offering QHPs on the FFEs Medicaid and hence are covered by the the Federal Hospital Insurance and Federal Supplementary Medical Insurance Trust Funds. will spread the cost to all plans issuers parent entity. We believe it reasonable Retrieved from https://www.cms.gov/Research- offer in the individual market. They will that the remaining CHIP plans also have Statistics-Data-and-Systems/Statistics-Trends-and- also likely offer the benefits of the APIs commercial offerings since it would be Reports/ReportsTrustFunds/Downloads/ to all covered lives, as they can be inefficient to operate a CHIP-only plan, TR2018.pdf. 71 Centers for Medicare and Medicaid Services. marketed as a value add service, and it (2018, November 8). CMS Proposes Changes to is logistically more challenging to offer 69 Center for Consumer Information and Streamline and Strengthen Medicaid and CHIP a service to only a limited number of Insurance Oversight. (n.d.). Medical Loss Ratio Data Managed Care Regulations. Retrieved from https:// enrollees. and System Resources. Retrieved from https:// www.cms.gov/newsroom/press-releases/cms- • www.cms.gov/CCIIO/Resources/Data-Resources/ proposes-changes-streamline-and-strengthen- We estimate that off-Exchange plans mlr.html. medicaid-and-chip-managed-care-regulations. offered by issuers who offer no QHPs on

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

TABLE 7—PROPORTION OF PREMIUMS (IN BILLIONS) FOR MEDICARE, MEDICAID, AND INDIVIDUAL MARKET PLANS

Individual Year Medicaid Medicare market Totals Advantage plans

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 estimates) of total costs by pro- gram ...... 32.56% 45.24% 22.19% 100.00% 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 internal business decision, we cannot the total costs of this final rule as allocation at the parent organization directly assess per-payer costs. presented in Table 5 to obtain Table 8, level and the allocations of each parent However, using the MLR tables, we can which breaks out the total column in organization may differ by program assess the proportions of cost by Table 5, the total cost by year of (Medicare, Medicaid, CHIP, and program. We can then multiply these implementing and maintaining the API, Individual market plans) and is an proportions (as presented in Table 7) by to offer API costs by year and program.

TABLE 8—API COSTS (IN MILLIONS) BY YEAR AND PROGRAM

Full implementation and maintenance Individual Medicaid and Medicare Year costs (millions) market plans CHIP Advantage (from Table 5) (22.19%) (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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00106 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 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 Individual Medicaid and Medicare Year costs (millions) market plans CHIP Advantage (from Table 5) (22.19%) (32.56%) (45.24%) for API provision

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 percent of the difference between Consequently, for the first year QHPs on the FFEs: Individual market benchmark and bid. Thus, although the (implementation year), the federal plans have the option to deal with Trust Fund pays the bid in full, matching is (0.48*0.90+0.52*0.5844) of the total program costs, reflecting the 90 increased costs by either temporarily nevertheless, 66 percent of the increased percent first year implementation absorbing them (for purposes of market bid costs arising from this final rule, are matching for state agencies which competitiveness), increasing premiums reduced from the rebates. The MA comprise 48 percent of the program cost to enrollees, or reducing non-essential organizations in its submitted bid, can plus 58.44 percent matching for the health benefits. To the extent that address this reduction of rebates by Medicaid managed care plans which issuers increase premiums for either: (1) Temporarily, for marketing comprise 52 percent of the program individual market plans on the FFEs, purposes, absorbing the loss by reducing costs. Similarly, for years after the first there would be federal premium tax its profit margin; (2) reducing the the federal costs are credit (PTC) impacts. The purpose of the supplemental benefits it provides the (0.48*0.75+0.52*0.5844) of total PTC is to assist enrollees in paying enrollee paid for by the rebate; or (3) raising enrollee premiums in order to program costs. premium costs. Since PTCs are only CHIP: Most states operate Medicaid available if an individual purchases an provide supplemental benefits for which premiums are not paid by the and CHIP from the same state agency. individual market plan on an Exchange, One state is a notable exception in that the PTC estimates apply only to rebate. The decision of what approach to use is an internal business decision it has a separate Medicaid and CHIP Exchange plans. In the PTC estimate, we agency. The federal government pays an have accounted for the fact that some in part motivated by unforeseen forces of marketing; we therefore have no way enhanced federal medical assistance issuers have both Exchange and non- percentage (EFMAP) to states for all Exchange plans, and some issuers have of predicting what will happen. Medicaid: State Medicaid agencies costs associated with CHIP, including only non-Exchange plans. We reflected may be allowed to allocate the costs of systems costs (this is unlike Medicaid these assumptions with global state information retrieval systems where there are different FMAPs for adjustments, so we believe the estimates between the costs attributable to design, different types of costs). For federal FY are reasonable in aggregate. development, installation, or 2019, the EFMAPs will range from 88 to Medicare Advantage: MA enhancement of the system—at a 90 100 percent. For federal FY 2020, the organizations may increase bids to percent federal match—and for ongoing EFMAPs will range from approximately reflect the costs of this final rule. Some operations of the system—at a 75 76.5 to 93 percent. After federal FY of these expected increased bid costs percent federal match. 2020, the EFMAPs will range from may increase Medicare Trust Fund For Medicaid managed care entities, approximately 65 to 81.5 percent. Since payments. For those (most) MA we assume an MCO, PIHP, and PAHP the CHIP program federal rebate ranges organizations whose bid amount is cost for implementing the standards- include the 90 percent and 75 percent below the benchmark, the Trust Fund based API provisions would be built federal matching proportions of the provides total expenditures to the MA into the capitation rates and paid for by Medicaid program, we are applying the organizations consisting of: (1) Full the state Medicaid agency, with the state 90 percent and 75 percent from payment of the bid amount; and (2) the Medicaid agency being reimbursed at Medicaid to the CHIP programs. Since rebate, a portion of the difference the state’s medical assistance match the CHIP program is small relative to the between the benchmark and the bid rate. For purposes of these estimates we Medicaid program, we believe this amount. Since MA organizations are use the weighted FMAP, 58.44, which is approach reasonable. increasing their bid amounts to reflect based on our past experience with this Table 9 uses these proportions to the costs of this final rule, it follows that program. estimate the impact of the API on the the rebate, equaling the difference Medicaid managed care costs federal government. For example, the between the benchmark and bid, is constitute 52 percent of the Medicaid $65.2 million cost to the federal decreased, resulting in less rebates paid program costs.72 government for Medicaid/CHIP for 2020 to the MA organizations. Based on our past experience and projections for the 72 Allen, K. (2019, April 18). Medicaid Managed www.healthmanagement.com/blog/medicaid- future, the rebate is estimated as 34 Care Spending in 2018. Retrieved from https:// managed-care-spending-in-2018/.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 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 These assumptions on all first-year this point how parent organizations will of the API, is obtained by multiplying federal expenses are reflected in Table bear these costs. This will be discussed the total $88.6 million (low estimate) 9 which includes PTC payments as well below. However, the basis for the cost listed in Table 8 by as federal matching in Medicaid and discussion is the calculation of non- (0.48*0.90+0.52*0.5844) the ratio Medicare. For PTC and Medicare we federal cost born by enrollees and plans indicated in the previous paragraphs. have assumed Federal payment in 2021. which is obtained by subtracting federal We note that we are not discussing at 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 ad- vantage 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 Medicaid agencies is presented in Table For example, Table 10 lists for 2020 respective cells in Tables 8 (total costs 10. Since the federal government does (low estimate), Medicaid/CHIP a by program) and 9 (total matching by not match QHP costs, the total cost for remaining cost to states of $24.3 million the federal government), we obtain the QHPs on the FFEs is born in its entirety ($88.6 million total (low estimate) cost remaining costs for the API for Medicare by the plans. This also is listed in Table for 2020 (Table 8)¥$65.2 million Advantage plans and for state Medicaid 10; however, in subtracting Table 9 from matched by the federal government agencies. To this amount (which only Table 8, we exclude PTC costs. These (Table 9) + ($2.8 million total cost for deals with the API provisions) must be are federal costs, but unlike Medicare coordination of dual eligibles (Table 5) added the coordination cost for the dual Advantage and Medicaid, the QHPs on * 32.56 percent (proportion of total costs eligible (column 3 of Table 5) multiplied the FFEs must account for the full cost incurred by Medicaid/CHIP (Table 7)). by the proportion of costs presented in of implementation. These PTC costs are (There are minor differences due to Table 7. This remaining cost born by not used to defray API costs. rounding.) Medicare Advantage plans and state

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00108 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25617

TABLE 10—REMAINING COSTS BY PROGRAM FOR API BY YEAR—Continued [In millions]

For individual For Medicaid/ For Medicare Year market plans CHIP 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 and negligibility may not have intuitive 12 presents costs per enrollee by 13 how payers and the federal meaning, as opposed to the costs per program for the federal government. government will deal with these extra enrollee, which are more manageable For example, the 2020 (low estimate) costs. We also discuss whether the costs and understandable. cost per enrollee for commercial are excessive for existing plans as well To provide background, the 2018 individual market plans is $3.48 (Table as how new plans might deal with these Medicare Trust Fund Report 73 states 11), which is obtained by dividing the costs. that costs per enrollee are projected to total, 2020, low-estimate, non-federal, The further discussion of bearing be roughly $12,000—$14,000 for individual market plan cost of $61 these costs is illustrated by million (Table 10) by 17.5 million contract years 2020—2023 (Table reformulating the costs in terms of costs enrollees. (This is based on the low IV.C3). The costs per enrollee for the per enrollee (per year), which is estimate of cost for API; the high Medicaid program are similarly several obtained by dividing the total cost to the estimate of cost would be $10.38 = thousand dollars. The estimates in the payer for all programs in which it $181.7 million/17.5 million). 2019 Medicare Trust Fund Report are participates (Medicare, Medicaid, CHIP, 74 The 2022 cost per enrollee for state and Individual market plans) by its total identical. Medicaid agencies after federal enrollment. As an example, if a payer For purposes of indicating the cost matching is 9 cents per enrollee (Table hypothetically spent $1 billion in a year per enrollee, we estimate 110.5 million 11), which is obtained by dividing the for 100,000 enrollees then the cost per enrollees will be affected by these total non-federal cost per program after enrollee per year is $10,000 ($1 billion/ provisions since currently there are federal matching, $6.2 million (Table 100,000). 17.5, 66,75 20,76 and 7 77 million 10) by 73 million enrollees (66 million As can be seen from this example, the enrollees covered by payers in the in Medicaid + 7 million in CHIP). Each cost per enrollee metric facilitates individual market, Medicaid, MA, and of these three calculations restates total comparison of costs. Since program separate CHIP programs, respectively. spending per program per stakeholder expenditures for both Medicaid and MA Table 11 presents costs per enrollee by (government, state Medicaid agencies, are typically hundreds of millions (or program for payers after reducing total or Medicare Advantage plans) in terms billions) of dollars, concepts like burden costs by federal matching, while Table 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

73 Boards of Trustees (Federal Hospital Insurance Supplementary Medical Insurance Trust Funds. 2018. Retrieved from https://www.cms.gov/ and Federal Supplementary Medical Insurance Retrieved from https://www.cms.gov/Research- Research-Statistics-Data-and-Systems/Statistics- Trust Funds). (2018, June 5). The 2018 Annual Statistics-Data-and-Systems/Statistics-Trends-and- Trends-and-Reports/MCRAdvPartDEnrolData/ Report of The Boards of Trustees of the Federal Reports/ReportsTrustFunds/Downloads/ Monthly-Contract-and-Enrollment-Summary- Hospital Insurance and Federal Supplementary TR2019.pdf. Report-Items/Contract-Summary-2018-08.html? Medical Insurance Trust Funds. Retrieved from 75 Centers for Medicare and Medicaid Services. DLPage=1&DLEntries=10& https://www.cms.gov/Research-Statistics-Data-and- DLSort=1&DLSortDir=descending. Systems/Statistics-Trends-and-Reports/Reports (n.d.). October 2019 Medicaid & CHIP Enrollment TrustFunds/Downloads/TR2018.pdf. Data Highlights. Retrieved from https:// 77 Centers for Medicare and Medicaid Services. 74 See page 154 in, Boards of Trustees (Federal www.medicaid.gov/medicaid/program-information/ (n.d.). October 2019 Medicaid & CHIP Enrollment Hospital Insurance and Federal Supplementary medicaid-and-chip-enrollment-data/report- Data Highlights. Retrieved from https:// Medical Insurance Trust Funds). (2019, April 22). highlights/index.html. www.medicaid.gov/medicaid/program-information/ The 2019 Annual Report of The Boards of Trustees 76 Centers for Medicare and Medicaid Services. medicaid-and-chip-enrollment-data/report- of the Federal Hospital Insurance and Federal (n.d.). Monthly Contract Summary Report—August highlights/index.html.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00109 Fmt 4701 Sfmt 4700 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 Medicare Current enrollment by payer (millions) market plans Medicaid Advantage (17.5) plans (73) plans (20)

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00111 Fmt 4701 Sfmt 4700 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 learn how to use standards-based APIs Assessment of impact is complicated heightened level of detail should satisfy and other new technologies. Another by the fact that costs have been commenter concerns. The revised commenter believes that for the clinical aggregated at the parent organization numbers are reflected in Tables 10 and data to be available in any API, the level. A typical parent organization Table 11. CEHRT used by providers needs to be might have products with QHP issuers Comment: One commenter noted that connected to a trusted exchange on the FFEs, MA, or Medicaid/CHIP the developers of APIs may want network. For many clinicians, the programs. We have no way of directly additional fees to implement or provide commenter noted the costs for assessing the size of parent access to their APIs. The commenter connecting their CEHRT to a trusted organizations. Therefore, as a proxy, we noted that these fees severely limit network continues to remain a barrier. analyze each payer separately. innovation in the marketplace for health Response: To address commenters’ Medicare Advantage: We first assess IT solutions for storing and utilizing concerns with API connectivity to an the impact on MA plans. To clarify the patient data, both on the patient and EHR, we note that there is no flow of payments between these entities provider side of the equation. requirement for a payer to link the and the federal government, we note Response: The data that must be Patient Access API to an EHR in this that MA organizations submit proposed shared via the API under this policy are final rule, and there are associated plan designs and estimates of the data that the payers have and must challenges, as discussed elsewhere in amount of revenue necessary to cover currently make available to patients. We this RIA, with attributing impacts to the cost of those plan designs (called also anticipate that many payers will various interacting regulatory and other bids) by the first Monday in June of the develop the APIs in-house. If this policies. Indeed, we do note that if a year preceding the coverage year. commenter is more referencing the provider does elect to connect an EHR Regulations governing this process are vendors creating apps, versus APIs for to the APIs finalized in this rule, they in 42 CFR part 422, subpart F. These payers, we also do not believe it is would be required to meet all the bids must be broken down in the appropriate to charge a fee, as discussed requirements of ONC’s Health IT following: in section III. of this final rule. If fees Certification Program.78 As part of that (1) The revenue requirements for are charged for certain apps, it is not the program, the 2015 CEHRT includes, for providing Medicare Part A and Part B data that are generating the fee, it is the example, ‘‘application access’’ benefits with actuarially equivalent cost product or services; indeed, there is a certification criteria that requires health sharing (this is the ‘‘basic benefit bid’’); logical connection between the potential IT to demonstrate it can provide (2) The revenue requirements for benefits of this rule (facilitated by new application access to the Common providing supplemental benefits; or enhanced services) and non- Clinical Data Set (CCDS) via an API.79 (3) The revenue requirements for Non- quantified potential costs (possibly Furthermore, nearly a third of EHR Benefit Expenses such as Sales & including those associated with the vendors are also using the FHIR Marketing, Direct and Indirect development or improvement of such standard to meet 2015 CEHRT Administration, Net Cost of services). Currently there are vendors requirements.80 Reinsurance, and Insurance Fees; and that collect the publicly available (4) For MA–PD plans, a Part D bid directory data, clean these data, C. Anticipated Effects consistent with Part D regulations in 42 supplement these data, and offer this The RFA, as amended, requires CFR part 423. enhanced data product back to payers agencies to analyze options for These bids project payments to and providers. It is not the data the regulatory relief of small businesses, if hospitals, providers and staff for vendors are charging for as much as it a rule has a significant impact on a covered benefits, as well as the cost of is the service of cleaning and enhancing substantial number of small entities. For plan administration and profits. Because these data. Vendors may generate purposes of the RFA, small entities the API requirements finalized in this revenue from their third-party apps, but include small businesses, nonprofit rule will apply to every MA plan and a major component of this is the service organizations, and small governmental each MA plan must furnish at least the they are providing—building the app, jurisdictions. Medicare Part A and Part B benefits, the making the data the patient directs to The API requirements in this final cost of the API will be built into the them most usable and valuable—that rule affect: 1) QHP issuers on the FFEs, administrative component of the basic generates the revenue. Payers must 2) MA organizations, including those benefit bid. These bids in turn already make these data available to that are also Part D sponsors of MA–PD determine one component of the patients. These data alone may also plans, as well as 3) Medicaid MCOs payments of the Medicare Trust Fund to drive revenue, but it is the patient’s with a minimum threshold for small the MA organizations who reimburse prerogative to provide their data to a business size of $41.5 million (https:// providers and subcontractors for their third party in order to get a service in www.sba.gov/federal-contracting/ services. A second component of the exchange contracting-guide/size-standards). Trust Fund payment to MA Comment: A few commenters noted organizations are the rebates, which are that RIA does not contain any costs for 78 Office of the National Coordinator. (2019, a portion of the difference between the provider EHR connectivity. One March 27). About the ONC Health IT Certification basic benefit bid compared to an Program. Retrieved from https://www.healthit.gov/ commenter noted that EHR developers’ topic/certification-ehrs/about-onc-health-it- administratively-set benchmark for the contracts with providers and health certification-program. MA plan’s service area (currently, based systems do not include the cost of 79 Centers for Medicare and Medicaid Services. on our past and projected experience, system updates that will be required to (n.d.). 2019 Promoting Interoperability Programs: rebates vary by plan and are 2015 Edition Certified EHR Technology Fact Sheet. comply with this proposal. Another Retrieved from https://www.cms.gov/Regulations- approximately 66 percent). Benchmarks commenter was concerned that EHR and-Guidance/Legislation/EHRIncentivePrograms/ are based on a formula using an estimate developers will charge providers Downloads/CEHRT2015Ed_FactSheet-.pdf. of the Medicare FFS per capita cost for significant fees to perform the updates 80 Posnack, S. & Baker, W. (2018, October 1). Heat the geographic area, which are adjusted Wave: The U.S. is Poised to Catch FHIR in 2019. required to comply with CMS’ Retrieved from https://www.healthit.gov/buzz-blog/ to reflect the per capita cost of each proposals, and providers will likely interoperability/heat-wave-the-u-s-is-poised-to- county in the U.S. and its territories and need to make additional investments to catch-fhir-in-2019. adjusted for the enrollees’ health status

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00112 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25621

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

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00114 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25623

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00115 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25624 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00116 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25625

Therefore, since, as noted above, the intermediary that facilitates exchange of in HIT and HIE. While these models are total cost impact over 25 months is $7 health information. It must also ongoing, evaluation reports thus far are million, when apportioned uniformly demonstrate that the notifications reporting that many states are over the 25 months, the resulting include at least patient name, treating experiencing favorable outcomes on ED impacts $2.8, $3.4, and $0.8 million for practitioner name, and sending visit rates and other quality measures.86 2020, 2021, and 2022 respectively institution name. Although patient event notifications are corresponding to 10 months, 12 months, Upon the patient’s registration in the only a small piece of these models, we and 3 months in 2020, 2021 and 2022 emergency department or admission to want to continue the momentum respectively. These calculations are inpatient services, and also either towards nationwide adoption. transparently presented in Table 5. immediately prior to, or at the time of, These notifications are automated, the patient’s discharge or transfer (from electronic communications from the 3. Revisions to the Conditions of the emergency department or inpatient provider to applicable post-acute care Participation for Hospitals and Critical services), the hospital (or CAH) must services providers and suppliers, and Access Hospitals (CAHs) also demonstrate that it has made a also to community practitioners We are expanding CMS’ requirements reasonable effort to ensure that its identified by the patient. These for interoperability within the hospital system sends the notifications to all automated communications alert the and CAH CoPs by focusing on electronic applicable post-acute care services receiving provider or practitioner that patient event notifications. We are providers and suppliers, as well as to the patient has received care at a implementing new requirements in any of the following practitioners and different setting. Information included section X. of this final rule for hospitals entities, which need to receive with these notifications can range from at 42 CFR 482.24(d), for psychiatric notification of the patient’s status for simply conveying the patient’s name, hospitals at 42 CFR 482.61(f), and for treatment, care coordination, or quality basic demographic information, and the CAHs at 42 CFR 485.638(d). improvement purposes: (1) The patient’s sending institution, to a richer set of Specifically, for hospitals, psychiatric established primary care practitioner; clinical data depending upon the level hospitals, and CAHs, we are finalizing (2) the patient’s established primary of technical implementation. Even with similar requirements to revise the CoPs care practice group or entity; or (3) other a minimum set of information included, for Medicare- and Medicaid- practitioner, or other practice group or these notifications can help ensure that participating hospitals, psychiatric entity, identified by the patient as the a receiving provider or community hospitals, and CAHs by adding a new practitioner, or practice group or entity, practitioner is aware that the patient has standard, ‘‘Electronic Notifications,’’ primarily responsible for his or her care. received care elsewhere. The that will require hospitals, psychiatric As we noted, infrastructure notification triggers a receiving provider hospitals, and CAHs to make electronic supporting the exchange of electronic or practitioner to reach out to the patient event notifications available to health information across settings has patient to deliver appropriate follow-up applicable post-acute care services matured substantially in recent years. care in a timely manner. By providing providers and suppliers, and to Research studies have increasingly timely notifications, the alert may community practitioners, such as the found that health information exchange improve post-discharge transitions and patient’s established primary care interventions can effectuate positive reduce the likelihood of complications practitioner, established primary care outcomes in health care quality and resulting from inadequate follow-up practice group or entity, or other public health outcomes, in addition to care. practitioner or practice group or entity more longstanding findings around We believe that care coordination can identified by the patient as primarily reductions in utilization and costs. have a significant positive impact on the responsible for his or her care. We are Electronic patient event notifications quality of life, consumer experience, limiting this requirement to only those from hospitals, or clinical event and health outcomes for patients. As we hospitals, psychiatric hospitals, and notifications, are one type of health have noted in the preamble to this rule, CAHs that utilize electronic medical information exchange intervention that virtually all EHR systems (as well as records systems, or other electronic has been increasingly recognized as an older legacy electronic administrative administrative systems, which are effective and scalable tool for improving systems, such as electronic patient conformant with the content exchange care coordination across settings, registrations systems, and which we are standard at 45 CFR 170.205(d)(2), especially for patients at discharge. This including in this final rule) generate the recognizing that not all Medicare- and approach has been identified with a basic messages commonly used to Medicaid-participating hospitals have reduction in readmissions following support electronic patient event been eligible for past programs implementation.85 notifications. In addition, while we promoting adoption of EHR systems. If In addition, the CMS Innovation acknowledge that some level of the hospital’s (or CAH’s) system Center has been partnering with states implementation cost would be realized conforms to the content exchange through the State Innovation Models for those providers not already sending standard at 45 CFR 170.205(d)(2), the Initiative to advance multi-payer health notifications, we also note there is also hospital (or CAH) must then care payment and delivery system substantial agreement that demonstrate that its system’s reform models. Through this initiative implementation of these basic notification capacity is fully operational 34 states have been awarded over $900 messaging and notification functions and that it operates in accordance with million to implement their respective within such existing systems constitutes all state and federal statutes and State Health Care Innovation Plans, a relatively low cost burden for regulations regarding the exchange of many of which included enhancements providers, particularly when such costs patient health information, and that its are considered alongside the innovative system, to the extent permissible under 85 Unruh, M. A., Jung, H., Kaushal, R., & Vest, J. and beneficial patient care transition applicable federal and state law and R. (2017). Hospitalization event notifications and regulations, and not inconsistent with reductions in readmissions of Medicare fee-for- 86 Centers for Medicare and Medicaid Services. the patient’s expressed privacy service beneficiaries in the Bronx, New York. (2019, December 6). State Innovation Models Journal of the American Medical Informatics Initiative: General Information. Retrieved from preferences, sends the notifications Association, 24(e1), e150–e156. doi: 10.1093/jamia/ https://innovation.cms.gov/initiatives/State- either directly, or through an ocw139. Innovations/.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00117 Fmt 4701 Sfmt 4700 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 is only obligated to send data received Consequently, not finalizing this policy they provide. from another payer under this policy in does not impact this RIA. As detailed in section XI., we estimate the electronic form and format it was 5. Non-Mandatory Effects and that the total cost imposed on hospitals, received. However, we have noted that Regulatory Interaction psychiatric hospitals, and CAHs by such transactions will need to be made these provisions to be approximately in compliance with any other applicable We note in this RIA when we had $5,179,863 in the first year and laws. difficulty quantifying costs due to lack $1,042,426 in subsequent years. We believe that sending and receiving of applicable research or data. More these data will help both plan enrollees specifically, the establishment of a 4. Effects of Other Policy Changes and health care providers in health care information ecosystem could In addition to those policy changes coordinating care and reducing only be achieved with new actions that discussed previously that we are able to administrative burden. We believe that are conducted widely throughout the model, we are finalizing various other this entails utilizing all tools available health care field—including by entities, changes in this final rule. Generally, we to us to ensure that plans provide especially non-hospital providers, for have limited or no specific data coordinated high-quality care in an whom costs have not been estimated in available with which to estimate the efficient and cost-effective way that either this RIA or the RIA for the impacts of the policy changes. Our protects program integrity. Leveraging accompanying ONC 21st Century Cures estimates of the likely impacts interoperability to facilitate care Act final rule (published elsewhere in associated with these other changes are coordination among plans can, with this issue of the Federal Register). discussed in this section. thoughtful execution, significantly Although data limitations have a. Care Coordination Across Payers reduce unnecessary care, as well as prevented the quantification of these ensure that health care providers are costs, the benefits of the two rules— The majority of the 64 million people able to spend their time providing care some of which have been quantified in on Medicare are covered by FFS, rather than performing unnecessary the ONC RIA—and the rules’ potential however, about 34 percent are covered administrative tasks. For instance, transfer impacts—including reductions in MA plans. Since 2003, the number of effective information exchange between in fraudulent payments, as discussed by beneficiaries enrolled in MA plans has plans could improve care coordination Parente et al. (2008) 88—are largely increased fivefold from 4.6 million in by reducing the need for health care contingent upon such costs being 87 2010 to 22 million in 2019. Given the providers to write unneeded letters of incurred. Additionally, there are growth in MA enrollment and the medical necessity; by reducing ongoing regulatory and policy activities ability for MA beneficiaries to change instances of inappropriate step therapy; outside of this final rule that might plans, we believe it is important to and by reducing repeated utilization influence the rule’s impact in an supporting efficient care coordination reviews, risk screenings, and unquantifiable manner. When possible, by requiring the sharing of key patient assessments. we acknowledge these complexities as health information when an enrollee We believe that this policy will well. requests it. Therefore, we are requiring impose minimal additional costs on D. Alternatives Considered MA organizations, Medicaid managed plans. We note that we are not care plans, CHIP managed care entities, specifying a transport standard and In March 2018, the White House and QHP issuers on the FFEs to anticipate that plans may opt to use Office of American Innovation and the maintain a process for the electronic APIs, such as the Patient Access API CMS Administrator announced the exchange of, at a minimum, the data that this final rule also requires. We also launch of MyHealthEData, and CMS’s classes and elements included in the anticipate that plans may choose to direct, hands-on role in improving content standard finalized by HHS in utilize a regional health information patient access and advancing the ONC 21st Century Cures Act final exchange. We believe it is difficult to interoperability. As part of the rule (published elsewhere in this issue quantify the impact of this change MyHealthEData initiative, we are taking of the Federal Register) at 45 CFR because plans will likely implement a patient-centered approach to health 170.213 (currently version 1 of the different transport methods, and we information access and moving to a USCDI), via a payer-to-payer data cannot predict the selected method system in which patients have exchanged as outlined in this section V. plans will choose. immediate access to their electronic of this final rule. Furthermore, we are health information and can be assured finalizing as proposed a regulatory b. Care Coordination Through Trusted that their health information will follow requirement at 42 CFR 422.119(f)(1) and Exchange Networks them as they move throughout the 438.62(b)(1)(vi), and at 45 CFR In section VI. of the CMS health care system from provider to 156.221(f)(1) to require MA Interoperability and Patient Access provider, payer to payer. This final rule organizations, Medicaid managed care proposed rule, we proposed requiring contains a range of policies. It provides plans, CHIP managed care entities, and MA organization, Medicaid managed descriptions of the statutory provisions QHP issuers on the FFEs to incorporate care plans, CHIP managed care entities, that are addressed, identifies the the data they receive into the payer’s and QHP issuers on the FFEs to policies, and presents rationales for our record about the enrollee. We are also participate in trust networks in order to decisions and, where relevant, finalizing that with the approval and at improve interoperability. We also listed alternatives that were considered. We the direction of an enrollee, a payer the requirements for participation in a carefully considered alternatives to the must send the defined information set to trusted exchange network. policies we are adopting in this final any other payer. We specify that a payer As a result of comments and re- rule but concluded that none of the examination of our desired policies, we 87 Medicare Payment Advisory Commission. have decided not to finalize this 88 Parente, Stephen T., Karen Mandelbaum, Susan (2019, July 19). A Data Book: Health Care Spending provision. However, as pointed out in P. Hanson, Bonnie S. Cassidy and Donald W. and the Medicare Program—June 2019. Retrieved Simborg. ‘‘Crime and Punishment: Can the NHIN from http://www.medpac.gov/docs/default-source/ the proposed rule, had this provision Reduce the Cost of Healthcare Fraud?’’ Journal of data-book/jun19_databook_entirereport_ been finalized, it would impose Healthcare Information Management 22(3): 42–51. sec.pdf?sfvrsn=0. minimal additional costs on plans. June 2008.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00118 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25627

alternatives would adequately and products, almost 87 percent of hospitals plans to provide more data elements via immediately begin to address the and 69 percent of MIPS eligible a standards-based API then just data for critical issues of the lack of patient clinicians are served by health IT adjudicated claims, encounters with access and interoperability, or the developers with product(s) certified to capitated providers, provider difficulty exchanging health care data any FHIR version.91 remittances, beneficiary cost-sharing, within the health care system. For additional ways to allow clinical data including laboratory As we noted in the CMS consumers access to their health data, results, provider directories (and Interoperability and Patient Access we note that we did receive comments pharmacy directories for MA–PDs), and proposed rule, we believe the following that CMS could consider allowing preferred drug lists, where applicable. three attributes of standards-based APIs payers and providers to upload patient In the CMS Interoperability proposed are particularly important to achieving data directly to a patient portal that is rule, we originally required MA the goal of offering individuals owned and managed by the patient. One organizations, state Medicaid FFS convenient access, through applications option would allow for HIEs and HINs programs, Medicaid managed care they choose, to available and relevant to serve as a central source for patients plans, CHIP FFS programs, and CHIP electronic health and health-related to obtain aggregated data in a single managed care entities to make available information: the API technologies location. While HIEs and HINs can provider directory data through the themselves, not just the data accessible provide patients with valuable Patient Access API (84 FR 7633) and through them, are standardized; the information via a portal, research has publicly available to current and APIs are technically transparent; and indicated that portals have not gained prospective enrollees (84 FR 7639). the APIs are implemented in a pro- widespread use by patients. According After consideration of public comments, competitive manner (84 FR 7620). The to ONC, as of 2017, 52 percent of we have removed the requirements that API requirements proposed and individuals have been offered online these impacted payers make provider finalized in this rule were developed to access to their medical records by a directory information available through ensure these goals are met. health provider or payer. Of the 52 the Patient Access API. MA Some of the reasons that we selected percent that were offered access, only organizations, state Medicaid FFS 92 the FHIR standard were due to the half of those viewed their record. programs, Medicaid managed care flexibility it provides and the wide Additionally, we believe that there plans, CHIP FFS programs, and CHIP industry adoption that it offers. The would be additional burden associated managed care entities will only need to open and extensible nature of FHIR with using portals because providers make provider directory information allows for health care integration to be and patients would need to access available via a publicly accessible transparent and accessible. FHIR is open multiple portals and websites to access Provider Directory API. We note the source, and as such, it has garnered a patient data, instead of a single app. Provider Directory API does not need to community that includes developers Unlike portals that would require conform to the security protocols and vendors. For example, large developers to link systems or ensure finalized by HHS at 45 CFR consumer brands are becoming a driving system-level compatibility, FHIR-based 170.215(a)(3) and (b) that are specific to force behind the adoption of FHIR. APIs have the ability to make data authenticating users and confirming Apple is implementing FHIR in Apple available without the need to link individuals’ authorization or request to Health as part of iOS 11.3, and serves as multiple systems or portals and would disclose their personal information to a a member of the Argonaut Project and provide a patient a single-point of specific application through an API, CARIN Alliance—two HL7 FHIR access to their data. Having APIs that namely the SMART IG (using the OAuth Accelerators; 89 Google supports FHIR can be accessed by third-party apps 2.0 standard) and OpenID Connect Core by partnering with HL7, as well as permits the patient to choose how they 1.0. By only requiring the Provider through its membership in the CARIN want to access their data, and it Directory API make these otherwise Alliance; and Microsoft published an promotes innovation in industry to find publicly accessible data available, we Azure API for FHIR to create and deploy ways to best help patients interact with are seeking to avoid duplicative effort FHIR service health data solutions.90 their data in a way that is most and additional burden. Furthermore, according to an ONC meaningful and helpful to them. report, nearly 51 percent of health IT Additionally, we believe it would be Additionally, several commenters developers appear to be using a version very difficult to evaluate the cost suggested additional information be of FHIR combined with OAuth 2.0 to impacts of making individual portals added to the requirement for provider respond to requests for patient data. available via an HIE or HIN because directory information to be available Additionally, of the hospitals and Merit- business models and process are varied, through an API, such as NPIs for based Incentive Payment System (MIPS) and there is a lack of standardization in individual and group providers, practice eligible clinicians that use certified the way the information is stored and group name, health system name, as transmitted across HIEs and HINs. well as the specific plan(s) and tiers a 89 The HL7 FHIR Accelerator Program is designed Other alternatives that we considered provider participates in ‘‘provider to assist communities and collaborative groups were how broadly or narrowly to apply demographics;’’ whether the provider is across the global health care spectrum in the the policies and requirements. For accepting new patients; and information creation and adoption of high quality FHIR Implementation Guides or other standard artifacts example, we could have required health about which providers are in-network to move toward the realization of global health data for a plan by geography and/or interoperability. For further details, see https:// 91 Posnack, S. & Baker, W. (2018, October 1). Heat specialty. While we agreed with www.hl7.org/about/fhir-accelerator/. Wave: The U.S. is Poised to Catch FHIR in 2019. commenters that this information would 90 Shrestha, R., Mohan, S., & Grieve, G. (2018, Retrieved from https://www.healthit.gov/buzz-blog/ February 14). State of the Healthcare API Economy interoperability/heat-wave-the-u-s-is-poised-to- be helpful to patients, we did not (An Innovation Forum Session: Session 217). catch-fhir-in-2019. modify the proposed requirements for Retrieved from https://365.himss.org/sites/ 92 Patel, V. & Johnson, C. (2018, April). the information that is required to be himss365/files/365/handouts/552739129/handout- Individuals’ Use of Online Medical Records and made available by the Provider _ 219 FINAL.pdf. See also https:// Technology for Health Needs (ONC Data Brief No. Directory API because we believe azure.microsoft.com/en-us/services/azure-api-for- 40). Retrieved from https://www.healthit.gov/sites/ fhir/ and https://www.apple.com/healthcare/health- default/files/page/2018-03/HINTS-2017-Consumer- additional data would be a cost driver. records/. Data-Brief-3.21.18.pdf. By not adding additional required

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00120 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 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 ad- ditional to the benefits assessed in the RIA for the accom- panying ONC 21st Century Cures Act final rule, (published else- where 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 com- monly used methods of information sharing and data standard- ization. • 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 bet- ter, healthier lives. • Privacy and security policies are being implemented that permit payers to request third-party apps to attest to privacy and secu- rity provisions prior to providing the app access to the payer’s API.

Costs

Annualized Monetized $ millions/year (low estimate) ...... 85.2 2019 7 2020–2029 80.8 2019 3 2020–2029 Annualized Monetized $ millions/year (primary estimate) ...... 122.0 2019 7 2020–2029 112.4 2019 3 2020–2029 Annualized Monetized $ millions/year (high estimate) ...... 158.8 2019 7 2020–2029 144.0 2019 3 2020–2029

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

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

TABLE 15—TRANSFERS TO ENROLLEE RESULTING FROM THE FINAL RULE

Label Item Amount Source Comments

(A) ...... First year cost of interoperability (Low estimate) ...... 272.0 Estimated in this proposed In millions. rule.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00122 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25631

TABLE 15—TRANSFERS TO ENROLLEE RESULTING FROM THE FINAL RULE—Continued

Label Item Amount Source Comments

(B) ...... First year cost amortized over 9 years ...... 30.2 (A) / 9 ...... In millions. (C) ...... Continuation year cost of interoperability ...... 54.4 Estimated in this proposed In millions. rule. (D) ...... Level interoperability cost per year ...... 84.6 (B) + (C) ...... In millions.

Commercial Percent of Premium Revenues

(E) ...... Total premium revenues in Individual market, Medicaid and 347 Table 7 ...... In billions. Medicare. (F) ...... Individual market plans premium revenues (dollar amount 77 22.19% ...... Table 7. and percent). (G) ...... Medicare Advantage premium revenues (Dollar amount and 157 45.24% ...... Table 7. percent). (H) ...... Medicaid premium revenues (Dollar amount and percent) ... 113 32.56% ...... Table 7.

Annual interoperability cost as a percent of commercial individual market health insurance premium revenues

(I) ...... Annual Level interoperability cost ...... 84.6 (D) ...... In millions. (J) ...... Percent of total individual market plans revenues ...... 22.19% (F). (K) ...... Interoperability cost for individual market plans ...... 18.8 (I) × (J) ...... In millions. (L) ...... Commercial premium revenues for individual market plans .. 77,000 (E) ...... 2016 data in millions. (M) ...... Interoperability cost as a percent of total commercial rev- 0.0244% (K) / (L). enue for individual market plans.

Individual market plans revenue broken out by whether above or below MLR threshold (requiring rebate)

(N) ...... Total individual market plan revenue ...... 77,000 (E) ...... In millions. (O) ...... Revenues of individual market health plans whose MLR is 4,037 2016 CMS MLR Data in mil- In millions. below regulatory threshold. lions. (P) ...... Revenues of individual market plans whose MLR is below 72,963 (N)¥(O) ...... In millions. regulatory threshold.

Transfer to enrollee per enrollee from decreased rebates and increased premium

(Q) ...... Reduction in rebates from interoperability in those plans 1.0 (N) × (O) ...... In millions. paying rebates. (R) ...... Premium increase from interoperability in those plans not 17.8 (N) × (P). paying rebates. (S) ...... Total increase to commercial individual market plans enroll- 18.8 (Q) + (R) ...... In millions. ees from interoperability. (T) ...... Number commercial enrollees in individual market plans ..... 17.5 From 2016 MLR files, in mil- In millions. lions. (U) ...... Dollar increase in premium per enrollee (Low estimate) ...... $1.07 (S) / (T). (V) ...... Dollar increase in premium per enrollee (Medium Estimate) $1.46 Obtained by replacing 272 million in row (A) with $544 million. (W) ...... Dollar increase in premium per enrollee (High Estimate) ...... $1.84 Obtained by replacing 272 million in row (A) with $816 million.

F. Regulatory Reform Analysis Under on the estimated costs of this final rule 42 CFR Part 422 E.O. 13771 can be found in the preceding analysis. Administrative practice and Executive Order 13771, titled G. Conclusion procedure, Health facilities, Health Reducing Regulation and Controlling The analysis above, together with the maintenance organizations (HMO), Regulatory Costs, was issued on January preceding preamble, provides an RIA. Medicare, Penalties, Privacy, Reporting 30, 2017 and requires that the costs In accordance with the provisions of and recordkeeping requirements. associated with significant new Executive Order 12866, this regulation regulations ‘‘shall, to the extent 42 CFR Part 423 was reviewed by the Office of permitted by law, be offset by the Management and Budget. elimination of existing costs associated Administrative practice and with at least two prior regulations.’’ List of Subjects procedure, Emergency medical services, This final rule is considered an E.O. Health facilities, Health maintenance 42 CFR Part 406 13771 regulatory action. We estimate organizations (HMO), Medicare, that this rule generates $77.8 million in Health facilities, Diseases, Medicare. Penalties, Privacy, Reporting and annualized costs, discounted at 7 recordkeeping requirements. 42 CFR Part 407 percent relative to year 2016, over an infinite time horizon estimate. Details Medicare.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00123 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25632 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

42 CFR Part 431 (i) Any State that has a buy-in (ii) Encounter data from capitated Grant programs—health, Health agreement in effect must participate in providers, no later than one (1) business facilities, Medicaid, Privacy, Reporting daily exchanges of enrollment data with day after data concerning the encounter and recordkeeping requirements. CMS. is received by the MA organization; and (ii) [Reserved] (iii) Clinical data, including 42 CFR Part 438 * * * * * laboratory results, if the MA Grant programs—health, Medicaid, organization maintains any such data, Reporting and recordkeeping PART 407—SUPPLEMENTARY no later than one (1) business day after requirements. MEDICAL INSURANCE (SMI) the data is received by the MA ENROLLMENT AND ENTITLEMENT organization. 42 CFR Part 457 (2) In addition to the information Administrative practice and ■ 3. The authority citation for part 407 specified in paragraph (b)(1) of this procedure, Grant programs—health, is revised to read as follows: section, an MA organization that offers Health insurance, Reporting and Authority: 42 U.S.C 1302 and 1395hh. an MA–PD plan must make the recordkeeping requirements. following information accessible to its ■ 4. Section 407.40 is amended by enrollees through the API described in 42 CFR Part 482 adding paragraph (c)(4) to read as paragraph (a) of this section: follows: Grant programs—health, Hospitals, (i) Data concerning adjudicated claims Medicaid, Medicare, Reporting and § 407.40 Enrollment under a State buy-in for covered Part D drugs, including recordkeeping requirements. agreement. remittances and enrollee cost-sharing, 42 CFR Part 485 * * * * * no later than one (1) business day after (c) * * * a claim is adjudicated; and, Grant programs—health, Health (4) Any State that has a buy-in (ii) Formulary data that includes facilities, Medicaid, Privacy, Reporting agreement in effect must participate in covered Part D drugs, and any tiered and recordkeeping requirements. daily exchanges of enrollment data with formulary structure or utilization 45 CFR Part 156 CMS. management procedure which pertains Administrative practice and to those drugs. PART 422—MEDICARE ADVANTAGE procedure, Advertising, Advisory (c) Technical requirements. An MA PROGRAM committees, Brokers, Conflict of organization implementing an API interests, Consumer protection, Grant under paragraph (a) of this section: ■ 5. The authority citation for part 422 (1) Must implement, maintain, and programs—health, Grants continues to read as follows: administration, Health care, Health use API technology conformant with 45 insurance, Health maintenance Authority: 42 U.S.C 1302 and 1395hh. CFR 170.215; organization (HMO), Health records, ■ 6. Section 422.119 is added to read as (2) Must conduct routine testing and Hospitals, Indians, Individuals with follows: monitoring, and update as appropriate, disabilities, Loan programs—health, to ensure the API functions properly, Medicaid, Organization and functions § 422.119 Access to and exchange of including assessments to verify that the health data and plan information. (Government agencies), Public API is fully and successfully assistance programs, Reporting and (a) Application Programming implementing privacy and security recordkeeping requirements, State and Interface to support MA enrollees. A features such as, but not limited to, local governments, Sunshine Act, Medicare Advantage (MA) organization those required to comply with HIPAA Technical assistance, Women, Youth. must implement and maintain a privacy and security requirements in 45 CFR parts 160 and 164, 42 CFR parts 2 For the reasons set forth in the standards-based Application and 3, and other applicable law preamble, the Centers for Medicare & Programming Interface (API) that protecting the privacy and security of Medicaid Services (CMS) amends 42 permits third-party applications to individually identifiable data; CFR chapter IV and the Office of the retrieve, with the approval and at the (3) Must comply with the content and Secretary (HHS) amends 45 CFR subtitle direction of a current individual MA vocabulary standard requirements in A, subchapter B, as set forth below: enrollee or the enrollee’s personal representative, data specified in paragraphs (c)(3)(i) and (ii) of this TITLE 42—PUBLIC HEALTH paragraph (b) of this section through the section, as applicable to the data type or CHAPTER IV—CENTERS FOR MEDICARE & use of common technologies and data element, unless alternate standards MEDICAID SERVICES, DEPARTMENT OF without special effort from the enrollee. are required by other applicable law: HEALTH AND HUMAN SERVICES (b) Accessible content. (1) An MA (i) Content and vocabulary standards organization must make the following at 45 CFR 170.213 where such standards PART 406—HOSPITAL INSURANCE information accessible to its current are applicable to the data type or ELIGIBLIITY AND ENTITLEMENT enrollees or the enrollee’s personal element, as appropriate; and representative through the API (ii) Content and vocabulary standards ■ 1. The authority citation for part 406 described in paragraph (a) of this at 45 CFR part 162 and § 423.160 of this is revised to read as follows: section: chapter where required by law or where Authority: 42 U.S.C 1302 and 1395hh. (i) Data concerning adjudicated such standards are applicable to the ■ 2. Section 406.26 is amended by claims, including claims data for data type or element, as appropriate. adding paragraph (a)(1)(i) and adding payment decisions that may be (4) May use an updated version of any and reserving paragraph (a)(1)(ii) to read appealed, were appealed, or are in the standard or all standards required under as follows: process of appeal, and provider paragraph (c)(1) or (3) of this section, remittances and enrollee cost-sharing where: § 406.26 Enrollment under State buy-in. pertaining to such claims, no later than (i) Use of the updated version of the (a) * * * one (1) business day after a claim is standard is required by other applicable (1) * * * processed; law; or

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00124 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25633

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00125 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25634 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

■ 8. Section 422.504 is amended by § 431.60 Beneficiary access to and (3) Must comply with the content and adding paragraph (a)(18) to read as exchange of data. vocabulary standards requirements in follows: (a) Application Programming paragraphs (c)(3)(i) and (ii) of this Interface to support Medicaid section, as applicable to the data type or § 422.504 Contract provisions. beneficiaries. A State must implement data element, unless alternate standards * * * * * and maintain a standards-based are required by other applicable law: (a) * * * Application Programming Interface (i) Content and vocabulary standards (18) To comply with the requirements (API) that permits third-party at 45 CFR 170.213 where such standards for access to health data and plan applications to retrieve, with the are applicable to the data type or information under §§ 422.119 and approval and at the direction of a element, as appropriate; and 422.120 of this chapter. current beneficiary or the beneficiary’s (ii) Content and vocabulary standards * * * * * personal representative, data specified at 45 CFR part 162 and § 423.160 of this in paragraph (b) of this section through chapter where required by law, or where PART 423—VOLUNTARY MEDICARE the use of common technologies and such standards are applicable to the PERSCRIPTION DRUG BENEFIT without special effort from the data type or element, as appropriate. beneficiary. (4) May use an updated version of any ■ 9. The authority citation for part 423 (b) Accessible content. A State must standard or all standards required under is revised to read as follows: make the following information paragraph (c)(1) or (3) of this section, accessible to its current beneficiaries or where: Authority: 42 U.S.C. 1302, 1306, 1395w– (i) Use of the updated version of the 101 through 1395w–152, and 1395hh. the beneficiary’s personal representative through the API described in paragraph standard is required by other applicable ■ 10. Section 423.910 is amended— (a) of this section: law, or (ii) Use of the updated version of the ■ a. In paragraph (b)(1) introductory text (1) Data concerning adjudicated standard is not prohibited under other by removing the phrase ‘‘monthly claims, including claims data for reporting requirement for the monthly applicable law, provided that: payment decisions that may be (A) For content and vocabulary enrollment reporting’’ and adding in its appealed, were appealed, or are in the place the phrase ‘‘state enrollment standards other than those at 45 CFR process of appeal, and provider 170.213, the Secretary has not reporting requirement described in remittances and beneficiary cost-sharing paragraph (d) of this section’’; prohibited use of the updated version of pertaining to such claims, no later than a standard for purposes of this section ■ b. In paragraph (d) by revising the one (1) business day after a claim is paragraph heading and by redesignating or 45 CFR part 170; processed; (B) For standards at 45 CFR 170.213 the text of paragraph (d) introductory (2) Encounter data no later than one and 45 CFR 170.215, the National text as paragraph (d)(1). (1) business day after receiving the data Coordinator has approved the updated ■ c. In newly redesignated paragraph from providers, other than MCOs, version for use in the ONC Health IT (d)(1), by removing the phrase ‘‘Effective PIHPs, and PAHPs, compensated on the Certification Program; and June 2005, and each subsequent month, basis of capitation payments; (C) Use of the updated version of a States must submit an electronic file, in (3) Clinical data, including laboratory standard does not disrupt an end user’s a manner specified by CMS’’ and by results, if the State maintains any such ability to access the data described in adding the following phrase ‘‘States data, no later than one (1) business day paragraph (b) of this section through the must submit an electronic file as after the data is received by the State; API described in paragraph (a) of this specified in paragraph (d)(2) of this and section. section,’’; and (4) Information about covered (d) Documentation requirements for ■ d. By adding paragraph (d)(2). outpatient drugs and updates to such APIs. For each API implemented in The revision and addition read as information, including, where accordance with paragraph (a) of this follows: applicable, preferred drug list section, a State must make publicly information, no later than one (1) accessible, by posting directly on its § 423.910 Requirements. business day after the effective date of website or via publicly accessible * * * * * any such information or updates to such hyperlink(s), complete accompanying (d) * * * information. documentation that contains, at a (2)(i) For the period prior to April 1, (c) Technical requirements. A State minimum the information listed in this 2022, States must submit the file at least implementing an API under paragraph paragraph. For the purposes of this monthly and may submit updates to that (a) of this section: section, ‘‘publicly accessible’’ means file on a more frequent basis. (1) Must implement, maintain, and that any person using commonly (ii) For the period beginning April 1, use API technology conformant with 45 available technology to browse the 2022, States must submit the file at least CFR 170.215; internet could access the information monthly and must submit updates to (2) Must conduct routine testing and without any preconditions or additional that file on a daily basis. monitoring, and update as appropriate, steps, such as a fee for access to the to ensure the API functions properly, * * * * * documentation; a requirement to receive including assessments to verify that the a copy of the material via email; a PART 431—STATE ORGANIZATION API is fully and successfully requirement to register or create an AND GENERAL ADMINISTRATION implementing privacy and security account to receive the documentation; features such as, but not limited to, or a requirement to read promotional ■ 11. The authority citation for part 431 those required to comply with HIPAA material or agree to receive future is revised to read as follows: privacy and security requirements in 45 communications from the organization CFR parts 160 and 164, 42 CFR parts 2 Authority: 42 U.S.C. 1302. making the documentation available; and 3, and other applicable law (1) API syntax, function names, ■ 12. Section 431.60 is added to subpart protecting the privacy and security of required and optional parameters B to read as follows: individually identifiable data; supported and their data types, return

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00126 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25635

variables and their types/structures, (g) Data availability. (1) The State provided coverage to the enrollee within exceptions and exception handling must comply with the requirements in the preceding 5 years; methods and their returns; paragraph (a) through (f) of this section (B) At any time the enrollee is (2) The software components and beginning January 1, 2021 with regard to currently enrolled in the MCO, PIHP, or configurations an application must use data: PAHP and up to 5 years after in order to successfully interact with the (i) With a date of service on or after disenrollment, send all such data to any API and process its response(s); and January 1, 2016; and other payer that currently covers the (3) All applicable technical (ii) That are maintained by the State. enrollee or a payer the enrollee or the requirements and attributes necessary (2) [Reserved] enrollee’s personal representative for an application to be registered with ■ 13. Section 431.70 is added to subpart specifically requests receive the data; any authorization server(s) deployed in B to read as follows: and conjunction with the API. (C) Send data received from another (e) Denial or discontinuation of access § 431.70 Access to published provider payer under this paragraph in the directory information. to the API. A State may deny or electronic form and format it was discontinue any third-party (a) The State must implement and received. application’s connection to the API maintain a publicly accessible, (vii) Applicability. required under paragraph (a) of this standards-based Application (A) The MCO, PIHP, or PAHP must section if the State: Programming Interface (API) that is comply with the requirements in (1) Reasonably determines, consistent conformant with the technical paragraph (b)(1)(vi) of this section with its security risk analysis under 45 requirements at § 431.60(c), excluding beginning January 1, 2022 with regard to CFR part 164 subpart C, that allowing an the security protocols related to user data: application to connect or remain authentication and authorization and (1) With a date of service on or after connected to the API would present an any other protocols that restrict the January 1, 2016; and unacceptable level of risk to the security availability of this information to (2) That are maintained by the MCO, of protected health information on the particular persons or organizations, the PIHP, or PAHP. State’s systems; and documentation requirements at (B) [Reserved] (2) Makes this determination using § 431.60(d), and is accessible via a * * * * * objective, verifiable criteria that are public-facing digital endpoint on the ■ applied fairly and consistently across all State’s website. 16. Section 438.242 is amended by applications and developers through (b) The API must provide a complete adding paragraphs (b)(5) and (6) to read which beneficiaries seek to access their and accurate directory of— as follows: electronic health information as defined (1) The State’s provider directory § 438.242 Health information systems. information specified in section at 45 CFR 171.102, including but not * * * * * limited to criteria that may rely on 1902(a)(83) of the Act, updated no later (b) * * * automated monitoring and risk than 30 calendar days after the State (5) Implement an Application mitigation tools. receives provider directory information Programming Interface (API) as (f) Beneficiary resources regarding or updates to provider directory specified in § 431.60 of this chapter as privacy and security. The State must information. if such requirements applied directly to (2) [Reserved] provide in an easily accessible location the MCO, PIHP, or PAHP and include— (c) This section is applicable on its public website and through other (i) All encounter data, including beginning January 1, 2021. appropriate mechanisms through which encounter data from any network it ordinarily communicates with current PART 438—MANAGED CARE providers the MCO, PIHP, or PAHP is and former beneficiaries seeking to compensating on the basis of capitation access their health information held by ■ 14. The authority citation for part 438 payments and adjudicated claims and the State Medicaid agency, educational is revised to read as follows: encounter data from any subcontractors. resources in non-technical, simple and Authority: 42 U.S.C. 1302. (ii) [Reserved] easy-to-understand language explaining (6) Implement, by January 1, 2021, at a minimum: ■ 15. Section 438.62 is amended by and maintain a publicly accessible (1) General information on steps the adding paragraphs (b)(1)(vi) and (vii) to standards-based API described in individual may consider taking to help read as follows: § 431.70, which must include all protect the privacy and security of their § 438.62 Continued services to enrollees. information specified in § 438.10(h)(1) health information, including factors to and (2) of this chapter. consider in selecting an application * * * * * including secondary uses of data, and (b) * * * * * * * * (1) * * * the importance of understanding the PART 457—ALLOTMENTS AND (vi) A process for the electronic security and privacy practices of any GRANTS TO STATES application to which they will entrust exchange of, at a minimum, the data their health information; and classes and elements included in the ■ 17. The authority citation for part 457 (2) An overview of which types of content standard adopted at 45 CFR is revised to read as follows: organizations or individuals are and are 170.213. Such information received by not likely to be HIPAA covered entities, the MCO, PIHP, or PAHP must be Authority: 42 U.S.C. 1302. the oversight responsibilities of the incorporated into the MCO’s, PIHP’s, or ■ 18. Section 457.700 is amended by— Office for Civil Rights (OCR) and the PAHP’s records about the current ■ a. Redesignating paragraphs (a)(1) and Federal Trade Commission (FTC), and enrollee. With the approval and at the (2) as paragraphs (a)(2) and (3), how to submit a complaint to: direction of a current or former enrollee respectively; (i) The HHS Office for Civil Rights or the enrollee’s personal representative, ■ b. Adding paragraph (a)(1); and (OCR); and the MCO, PIHP, or PAHP must: ■ c. Revising paragraph (c). (ii) The Federal Trade Commission (A) Receive all such data for a current The addition and revision reads as (FTC). enrollee from any other payer that has follows:

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00127 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 25636 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00128 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25637

access their health information held by ■ 21. Section 457.1233 is amended by the patient’s expressed privacy the State CHIP agency, educational revising paragraph (d) to read as preferences, the system sends resources in non-technical, simple and follows: notifications directly, or through an easy-to-understand language explaining intermediary that facilitates exchange of at a minimum: § 457.1233 Structure and operations health information, at the time of: standards. (1) General information on steps the (i) The patient’s registration in the individual may consider taking to help * * * * * hospital’s emergency department (if (d) Health information systems. (1) protect the privacy and security of their applicable). The State must ensure, through its health information, including factors to (ii) The patient’s admission to the contracts, that each MCO, PIHP, and consider in selecting an application hospital’s inpatient services (if PAHP complies with the health including secondary uses of data, and applicable). information systems requirements as the importance of understanding the (4) To the extent permissible under provided in § 438.242(a), (b)(1) through security and privacy practices of any applicable federal and state law and (4), (c), (d), and (e) of this chapter. application to which they will entrust regulations and not inconsistent with (2) Each MCO, PIHP, and PAHP must their health information; and the patient’s expressed privacy implement an Application Programming preferences, the system sends (2) An overview of which types of Interface (API) as specified in § 457.730 notifications directly, or through an organizations or individuals are and are as if such requirements applied directly intermediary that facilitates exchange of not likely to be HIPAA covered entities, to the MCO, PIHP, or PAHP, and health information, either immediately the oversight responsibilities of OCR include— prior to, or at the time of: and FTC, and how to submit a (i) All encounter data, including (i) The patient’s discharge or transfer complaint to: encounter data from any network from the hospital’s emergency (i) The HHS Office for Civil Rights providers the MCO, PIHP, or PAHP is department (if applicable). (OCR); and compensating on the basis of capitation (ii) The patient’s discharge or transfer (ii) The Federal Trade Commission payments and adjudicated claims and from the hospital’s inpatient services (if (FTC). encounter data from any subcontractors. applicable). (g) Data availability. (1) The State (ii) [Reserved] (5) The hospital has made a must comply with the requirements in (3) Implement, by January 1, 2021, reasonable effort to ensure that the paragraphs (a) through (f) of this section and maintain a publicly accessible system sends the notifications to all beginning January 1, 2021 with regard to standards-based API described in applicable post-acute care services data: § 457.760, which must include all providers and suppliers, as well as to (i) With a date of service on or after information specified in § 438.10(h)(1) any of the following practitioners and January 1, 2016; and and (2) of this chapter. entities, which need to receive (ii) That are maintained by the State. * * * * * notification of the patient’s status for treatment, care coordination, or quality (2) [Reserved] PART 482—CONDITIONS OF improvement purposes: ■ 20. Section 457.760 is added to PARTICIPATION: HOSPITALS (i) The patient’s established primary subpart G to read as follows: care practitioner; ■ 22. The authority citation for part 482 (ii) The patient’s established primary § 457.760 Access to published provider is revised to read as follows: care practice group or entity; or directory information. (iii) Other practitioner, or other (a) The State must implement and Authority: 42 U.S.C. 1302, 1395hh, and 1395rr, unless otherwise noted. practice group or entity, identified by maintain a publicly accessible, the patient as the practitioner, or standards-based Application ■ 23. Section 482.24 is amended by practice group or entity, primarily Programming Interface (API) that is adding paragraph (d) to read as follows: responsible for his or her care. conformant with the technical § 482.24 Conditions of participation: ■ 24. Section 482.61 is amended by requirements at § 457.730(c), excluding Medical record services. adding paragraph (f) to read as follows: the security protocols related to user authentication and authorization and * * * * * § 482.61 Condition of participation: (d) Standard: Electronic notifications. any other protocols that restrict the Special medical record requirements for If the hospital utilizes an electronic psychiatric hospitals. availability of this information to medical records system or other particular persons or organizations, the * * * * * electronic administrative system, which documentation requirements at (f) Standard: Electronic notifications. is conformant with the content § 457.730(d), and is accessible via a If the hospital utilizes an electronic exchange standard at 45 CFR public-facing digital endpoint on the medical records system or other 170.205(d)(2), then the hospital must State’s website. electronic administrative system, which demonstrate that— is conformant with the content (b) The API must provide a complete (1) The system’s notification capacity exchange standard at 45 CFR and accurate directory of— is fully operational and the hospital 170.205(d)(2), then the hospital must (1) The State’s provider directory uses it in accordance with all State and demonstrate that— information including provider names, Federal statutes and regulations (1) The system’s notification capacity addresses, phone numbers, and applicable to the hospital’s exchange of is fully operational and the hospital specialties, updated no later than 30 patient health information. uses it in accordance with all State and calendar days after the State receives (2) The system sends notifications Federal statutes and regulations provider directory information or that must include at least patient name, applicable to the hospital’s exchange of updates to provider directory treating practitioner name, and sending patient health information. information. institution name. (2) The system sends notifications (2) [Reserved] (3) To the extent permissible under that must include at least patient name, (c) This section is applicable applicable federal and state law and treating practitioner name, and sending beginning January 1, 2021. regulations, and not inconsistent with institution name.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00129 Fmt 4701 Sfmt 4700 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 170.205(d)(2), then the CAH must TITLE 45—PUBLIC WELFARE applicable federal and state law and demonstrate that— SUBTITLE A—DEPARTMENT OF regulations, and not inconsistent with (1) The system’s notification capacity HEALTH AND HUMAN SERVICES the patient’s expressed privacy is fully operational and the CAH uses it preferences, the system sends in accordance with all State and Federal PART 156—HEALTH INSURANCE notifications directly, or through an statutes and regulations applicable to ISSUER STANDARDS UNDER THE intermediary that facilitates exchange of the CAH’s exchange of patient health AFFORDABLE CARE ACT, INCLUDING health information, at the time of: information. STANDARDS RELATED TO (i) The patient’s registration in the EXCHANGES hospital’s emergency department (if (2) The system sends notifications applicable). that must include at least patient name, ■ 27. The authority citation for part 156 (ii) The patient’s admission to the treating practitioner name, and sending continues to read as follows: hospital’s inpatient services (if institution name. Authority: 42 U.S.C. 18021–18024, 18031– applicable). (3) To the extent permissible under 18032, 18041–18042, 18044, 18054, 18061, (4) To the extent permissible under applicable federal and state law and 18063, 18071, 18082, 26 U.S.C. 36B, and 31 U.S.C. 9701. applicable federal and state law and regulations, and not inconsistent with regulations, and not inconsistent with the patient’s expressed privacy ■ 28. Section 156.221 is added to read the patient’s expressed privacy preferences, the system sends as follows: preferences, the system sends notifications directly, or through an notifications directly, or through an § 156.221 Access to and exchange of intermediary that facilitates exchange of intermediary that facilitates exchange of health data and plan information. health information, at the time of: health information, either immediately (a) Application Programming prior to, or at the time of: (i) The patient’s registration in the Interface to support enrollees. Subject to (i) The patient’s discharge or transfer CAH’s emergency department (if paragraph (h) of this section, a QHP from the hospital’s emergency applicable). issuer on a Federally-Facilitated department (if applicable). Exchange must implement and maintain (ii) The patient’s admission to the a standards-based Application (ii) The patient’s discharge or transfer CAH’s inpatient services (if applicable). from the hospital’s inpatient services (if Programming Interface (API) that applicable). (4) To the extent permissible under permits third-party applications to (5) The hospital has made a applicable federal and state law and retrieve, with the approval and at the reasonable effort to ensure that the regulations, and not inconsistent with direction of a current individual system sends the notifications to all the patient’s expressed privacy enrollee or the enrollee’s personal applicable post-acute care services preferences, the system sends representative, data specified in providers and suppliers, as well as to notifications directly, or through an paragraph (b) of this section through the any of the following practitioners and intermediary that facilitates exchange of use of common technologies and entities, which need to receive health information, either immediately without special effort from the enrollee. notification of the patient’s status for prior to, or at the time of: (b) Accessible content. (1) A QHP issuer on a Federally-facilitate Exchange treatment, care coordination, or quality (i) The patient’s discharge or transfer improvement purposes: must make the following information from the CAH’s emergency department accessible to its current enrollees or the (i) The patient’s established primary (if applicable). enrollee’s personal representative care practitioner; through the API described in paragraph (ii) The patient’s established primary (ii) The patient’s discharge or transfer (a) of this section: care practice group or entity; or from the CAH’s inpatient services (if applicable). (i) Data concerning adjudicated (iii) Other practitioner, or other claims, including claims data for (5) The CAH has made a reasonable practice group or entity, identified by payment decisions that may be the patient as the practitioner, or effort to ensure that the system sends appealed, were appealed, or are in the practice group or entity, primarily the notifications to all applicable post- process of appeal, and provider responsible for his or her care. acute care services providers and remittances and enrollee cost-sharing suppliers, as well as to any of the PART 485—CONDITIONS OF pertaining to such claims, no later than following practitioners and entities, one (1) business day after a claim is PARTICIPATION: SPECIALIZED which need to receive notification of the PROVIDERS processed; patient’s status for treatment, care (ii) Encounter data from capitated ■ 25. The authority citation for part 485 coordination, or quality improvement providers, no later than one (1) business is revised to read as follows: purposes: day after data concerning the encounter is received by the QHP issuer; and Authority: 42 U.S.C. 1302 and 1395hh. (i) The patient’s established primary care practitioner; (iii) Clinical data, including ■ 26. Section 485.638 is amended by laboratory results, if the QHP issuer adding paragraph (d) to read as follows: (ii) The patient’s established primary maintains any such data, no later than care practice group or entity; or one (1) business day after data is § 485.638 Conditions of participation: (iii) Other practitioner, or other received by the issuer. Clinical records. practice group or entity, identified by (2) [Reserved] * * * * * the patient as the practitioner, or (c) Technical requirements. A QHP (d) Standard: Electronic notifications. practice group or entity, primarily issuer on a Federally-facilitated If the CAH utilizes an electronic responsible for his or her care. Exchange implementing an API under medical records system or other paragraph (a) of this section: electronic administrative system, which (1) Must implement, maintain, and is conformant with the content use API technology conformant with 45 exchange standard at 45 CFR CFR 170.215;

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00130 Fmt 4701 Sfmt 4700 E:\FR\FM\01MYR2.SGM 01MYR2 Federal Register / Vol. 85, No. 85 / Friday, May 1, 2020 / Rules and Regulations 25639

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

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00131 Fmt 4701 Sfmt 4700 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 offering only stand-alone dental plans, Dated: January 21, 2020. may grant an exception to the must comply with the requirements in Seema Verma, requirements in paragraphs (a) through paragraphs (a) through (e) and (g) of this Administrator, Centers for Medicare & (g) of this section if the Exchange section beginning with plan years Medicaid Services. determines that making such health beginning on or after January 1, 2021, Dated: March 5, 2020. plan available through such Exchange is and with the requirements in paragraph Alex M. Azar II, in the interests of qualified individuals (f) of this section beginning with plan Secretary, Department of Health and Human in the State or States in which such years beginning on or after January 1, Services. Exchange operates. 2022 with regard to data: [FR Doc. 2020–05050 Filed 4–21–20; 4:15 pm] (1) With a date of service on or after (i) Applicability. A QHP issuer on an January 1, 2016; and BILLING CODE P individual market Federally-facilitated (2) That are maintained by the QHP Exchange, not including QHP issuers issuer for enrollees in QHPs.

VerDate Sep<11>2014 08:09 May 01, 2020 Jkt 250001 PO 00000 Frm 00132 Fmt 4701 Sfmt 9990 E:\FR\FM\01MYR2.SGM 01MYR2