2019-02200. Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed ...

AGENCY:

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

ACTION:

Proposed rule.

SUMMARY:

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

DATES:

To be assured consideration, comments must be received at one of the addresses provided below, no later than 5 p.m. on May 3, 2019.

ADDRESSES:

In commenting, please refer to file code CMS-9115-P. Because of staff and resource limitations, we cannot accept comments by facsimile (FAX) transmission.

Comments, including mass comment submissions, must be submitted in one of the following three ways (please choose only one of the ways listed):

1. Electronically. You may submit electronic comments on this regulation to http://www.regulations.gov. Follow the “Submit a comment” instructions.

2. By regular mail. You may mail written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-9115-P, P.O. Box 8016, Baltimore, MD 21244-8016.

Please allow sufficient time for mailed comments to be received before the close of the comment period.

3. By express or overnight mail. You may send written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-9115-P, Mail Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.

For information on viewing public comments, see the beginning of the SUPPLEMENTARY INFORMATION section.

FOR FURTHER INFORMATION CONTACT:

Alexandra Mugge, [phone], for issues related to interoperability, CMS health IT strategy, technical standards and patient matching.

Natalie Albright, [phone], for issues related to Medicare Advantage.

John Giles, [phone], for issues related to Medicaid.

Emily Pedneau, [phone], for issues related to Qualified Health Plans.

Meg Barry, [phone], for issues related to CHIP.

Thomas Novak, [phone], for issues related to trust exchange networks and payer to payer coordination.

Sharon Donovan, [phone], for issues related to federal-state data exchange.

Daniel Riner, [phone], for issues related to Physician Compare.

Ashley Hain, [phone], for issues related to hospital public reporting.

Melissa Singer, [phone], for issues related to provider directories.

CAPT Scott Cooper, USPHS, [phone], for issues related to hospital and critical access hospital conditions of participation.

Lisa Bari, [phone], for issues related to advancing interoperability in innovative models.

Russell Hendel, [phone], for issues related to the Collection of Information or the Regulation Impact Analysis sections.

SUPPLEMENTARY INFORMATION:

Inspection of Public Comments: All comments received before the close of the comment period are available for viewing by the public, including any personally identifiable or confidential business information that is included in a comment. We post all comments received before the close of the comment period on the following website as soon as possible after they have been received: http://www.regulations.gov. Follow the search instructions on that website to view public comments.

I. Background and Summary of Provisions

A. Purpose

This proposed rule is the first phase of proposed policies centrally focused on advancing interoperability and patient access to health information using the authority available to the Centers for Medicare & Medicaid Services (CMS). We believe this is an important step in advancing interoperability, putting patients at the center of their health care and ensuring they have access to their health information. We are committed to solving the issue of interoperability and achieving complete access to health information for patients in the United States (U.S.) health care system, and are taking an active approach to move participants in the health care market toward interoperability and the secure and timely exchange of health information by proposing and adopting policies for the Medicare and Medicaid programs, the Children's Health Insurance Program (CHIP), and issuers of qualified health plans (QHPs).

Throughout this proposed rule, we refer to terms such as patient, consumer, beneficiary, enrollee, and individual. We note that every reader of this proposed rule is a patient and has or will receive medical care at some point in their life. In this proposed rule, we use the term “patient” as an inclusive term, but because we have historically referred to patients using other terms in our regulations, we use specific terms as applicable in sections of this proposed rule to refer to individuals covered under the health care programs that CMS administers and regulates. We also use terms such as payer, plan, and issuer in this proposed rule. Certain portions of this proposed rule are applicable to the Medicare Fee-for-Service (FFS) Program, the Medicaid FFS Program, the CHIP FFS program, Medicare Advantage (MA) Organizations, Medicaid Managed Care plans (managed care organizations (MCOs), prepaid inpatient health plans (PIHPs) and prepaid ambulatory health plans (PAHPs)), CHIP Managed Care entities (MCOs, PIHPs, and PAHPs), and QHP issuers in Federally-facilitated Exchanges (FFEs). We use the term “payer” as an inclusive term, but we use specific terms as applicable in sections of this proposed rule.

B. Overview

We are dedicated to enhancing and protecting the health and well-being of all Americans. One critical issue in the U.S. health care system is that people cannot easily access their complete health information in interoperable forms. Patients and the health care providers caring for them are often presented with an incomplete picture of their health and care as pieces of their information are stored in various, unconnected systems and do not accompany the patient to every care setting.

We believe patients should have the ability to move from health plan to health plan, provider to provider, and have both their clinical and administrative information travel with them throughout their journey. When a patient receives care from a new provider, a complete record of their health information should be readily available to that care provider, regardless of where or by who care was previously provided. When a patient is discharged from a hospital to a post-acute care (PAC) setting there should be no question as to how, when, or where their data will be exchanged. Likewise, when an enrollee changes health plans or ages into Medicare, the enrollee should be able to have their claims history and encounter data follow so that information is not lost.

For providers in clinical settings, health information technology (health IT) should be a resource, designed to make it faster and easier for providers to deliver high quality care, creating efficiencies and allowing them to access all available data for their patients. Health IT should not detract from the clinician-patient relationship, from the patient's experience of care, or from the quality of work life for physicians, nurses, and other health care professionals. Through standards-based interoperability and exchange, health IT has the potential to be a resource and facilitator for efficient, safe, high-quality care for individuals and populations.

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

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

C. Executive Order and MyHealthEData

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

In support of Executive Order 13813, the Administration launched the MyHealthEData initiative. This government-wide initiative aims to empower patients by ensuring that they have full access to their own health information and the ability to decide how their data will be used, while keeping that information safe and secure. MyHealthEData aims to break down the barriers that prevent patients from gaining electronic access to their health information from the device or application of their choice, empowering patients and taking a critical step toward interoperability and patient data exchange.

In March 2018, the White House Office of American Innovation and the CMS Administrator announced the launch of MyHealthEData, and CMS's direct, hands-on role in improving patient access and advancing interoperability. As part of the MyHealthEData initiative, we are taking a patient-centered approach to health information access and moving to a system in which patients have immediate access to their computable health information and can be assured that their health information will follow them as they move throughout the health care system from provider to provider, payer to payer. To accomplish this, we have launched several initiatives related to data sharing and interoperability to empower patients and encourage plan and provider competition. In this proposed rule, we continue to advance the policies and goals of the MyHealthEData initiative through various proposals as outlined in the following sections.

Our proposals are wide-reaching and would have an impact on all facets of the health care system. Several key touch points of the proposals in this rule include:

• Patients: Enabling patients to access their health information electronically without special effort by requiring the payers subject to this proposed rule to make the data available through an application programming interface (API) to which third party software applications connect to make the data available to patients. This encourages them to take charge of and better manage their health care, and thus these initiatives are imperative to improving a patient's long-term health outcomes.
• Clinicians and Hospitals: Ensuring that health care providers have ready access to health information about their patients, regardless of where the patient may have previously received care. We are also proposing policies to prevent health care providers from inappropriately restricting the flow of information to other health care providers and payers. Finally, we are working to ensure that better interoperability reduces the burden on health care providers.
• Payers: Proposing requirements to ensure that payers (that is, entities and organizations that pay for health care), such as MA plans and Medicaid and CHIP programs, make enrollee electronic health information held by the plan available through an API such that, with use of software we expect payers and third parties to develop, the information becomes easily accessible to the enrollee, and that the data flows seamlessly with the enrollee as they change providers, plans, and issuers. Additionally, our proposals would ensure that payers make it easy for current and prospective enrollees to identify which providers are within a given plan's network in a way that is simple and easy for enrollees to access and understand, and thus find the providers that are right for them.

Under our proposals to standardize data and technical approaches to advance interoperability, we believe health care providers and their patients, as well as other key participants within the health care ecosystem such as plans and payers, will have appropriate access to the information necessary to coordinate individual care, analyze population health trends, outcomes, and costs, and manage benefits and the health of populations, while tracking progress through quality improvement initiatives. We are working with other federal partners including the Office of the National Coordinator for Health Information Technology (ONC) on this effort with the clear objective to improve patient access and care, alleviate provider burden, and reduce overall health care costs.

D. Past Efforts

The Department of Health and Human Services (HHS) has been working to advance the interoperability of electronic health information since 2004, when the ONC was initially created via Executive Order 13335. From 2004 to 2009, ONC worked with a variety of federal and private sector stakeholders to coordinate private and public actions, began harmonizing data standards, and worked to advance nationwide health information exchange. In 2009, the National Coordinator position, office, and statutory duties were codified by the Health Information Technology for Economic and Clinical Health Act (HITECH Act), enacted as part of the American Recovery and Reinvestment Act of 2009 (Pub. L. 111-5, enacted February 17, 2009), at Title 42—Health Information Technology and Quality (42 U.S.C. 300jj et seq.) of the Public Health Service Act (PHSA). Under section 3001(c)(5) of the PHSA, ONC established a voluntary certification program to certify that health IT met standards, implementation specifications, and certification criteria adopted by the Secretary. ONC is organizationally located within HHS' Office of the Secretary and is the principal federal entity charged with coordination of nationwide efforts to implement and use the most advanced health IT and the electronic exchange of health information.

The HITECH Act provided the opportunity to move interoperability forward in many additional meaningful ways. A few are particularly worth noting in relation to this proposed rule. For instance, HITECH also amended the Social Security Act (the Act), authorizing CMS to make incentive payments (and in later years, make downward adjustments to Medicare payments) to eligible professionals, eligible hospitals and critical access hospitals (CAHs), and MA organizations to promote the adoption and meaningful use of certified electronic health record technology (CEHRT). In 2010, through rulemaking, we established criteria for the Medicare and Medicaid Electronic Health Record (EHR) Incentive Programs to encourage eligible professionals, eligible hospitals, and CAHs to adopt, implement, upgrade, and demonstrate the meaningful use of CEHRT. The programs were implemented in three stages:

• Stage 1 set the foundation for the EHR Incentive Programs by establishing requirements for the electronic capture of clinical data, including providing patients with electronic copies of health information.
• Stage 2 expanded upon the Stage 1 criteria with a focus on advancing clinical processes and ensuring that the meaningful use of EHRs supported the aims and priorities of the National Quality Strategy. Stage 2 criteria encouraged the use of CEHRT for continuous quality improvement at the point of care and the exchange of information in the most structured format possible.
• Stage 3 focuses on using CEHRT to improve health outcomes.

The federal government has spent over $35 billion under the EHR Incentive Programs to incentivize the adoption and meaningful use of EHR systems by eligible professionals, eligible hospitals, and CAHs; however, despite the fact that 78 percent of physicians ^[1] and 96 percent of hospitals ^[2] now use a certified EHR system, progress on system-wide data sharing has been limited.

In 2010, under the HITECH Act, ONC adopted an initial set of standards, implementation specifications, and certification criteria, and established the Temporary Certification Program for Health Information Technology, under which health IT developers could begin to obtain certification of the EHR technology that eligible professionals, eligible hospitals, and CAHs would need to adopt and use to satisfy CMS Stage 1 requirements for demonstration of meaningful use of CEHRT. In January 2011, ONC replaced the Temporary Certification Program with the Permanent Certification Program for Health Information Technology (45 CFR part 170). The Secretary has adopted iterative editions of the set of standards, implementation specifications, and certification criteria included in the Programs to keep pace with advances in standards, health information exchange, and the health IT market. In addition, this helps to maintain alignment with the needs of health care providers seeking to succeed within health IT-linked federal programs.

In April 2015, Congress passed the Medicare Access and CHIP Reauthorization Act of 2015 (MACRA) (Pub. L. 114-10, enacted April 16, 2015), which declared it a national objective to achieve widespread exchange of health information through interoperable CEHRT nationwide. Section 106(b)(1)(B)(ii) of MACRA defines “interoperability” as the ability of two or more health information systems or components to exchange clinical and other information and to use the information that has been exchanged using common standards as to provide access to longitudinal information for health care providers in order to facilitate coordinated care and improved patient outcomes. The MACRA charges the Secretary to establish metrics to be used to determine if widespread interoperability had been achieved, and the heading of section 106(b)(2) of the MACRA refers to “preventing blocking the sharing of information.” Specifically, section 106(b)(2) of the MACRA amended section 1848(o)(2)(A)(ii) of the Act for eligible professionals and section 1886(n)(3)(A)(ii) of the Act for eligible hospitals and CAHs to require that the professional or hospital demonstrate that they have not knowingly and willfully taken action to limit or restrict the compatibility or interoperability of CEHRT. For a discussion of the attestation requirements that we established and codified to support the prevention of information blocking, we refer readers to the CY 2017 Quality Payment Program final rule (81 FR 77028 through 77035).

In April 2018, we renamed the EHR Incentive Programs and the MIPS Advancing Care Information performance category to the Promoting Interoperability (PI) Programs and Promoting Interoperability performance category, respectively (83 FR 41635). This refocusing and rebranding of the initiatives is just one part of the CMS strategic shift in focus to advancing health IT and interoperability.

CMS appreciates the pathways Congress opened for action on interoperability, as will be discussed in more detail throughout this proposed rule and has been working diligently with ONC to support implementation. In addition, in order to make sure we have as much stakeholder feedback on all the options CMS specifically has available to best take advantage of this new opportunity to promote interoperability, over a span of several months in 2018, we released interoperability Requests for Information (RFIs) in several Medicare payment rules, including in the FY 2019 Inpatient Prospective Payment System (IPPS) proposed rule (83 FR 20164). While the Interoperability RFI in the FY 2019 IPPS proposed rule was focused primarily on how and whether changes to Hospital Conditions of Participation and other like program requirements could impact or contribute to advancing interoperability, stakeholders provided additional input that we are taking under advisement for the purposes of advancing interoperability generally in this proposed rule. For example, some commenters recommended aligning existing standards and adopting common standards and/or data elements across the health care industry as a whole (not just focusing on providers), incentivizing the use of standards, and removing barriers as possible ways to address gaps in interoperability. Commenters also expressed support for the use of open APIs but cautioned CMS to consider the need to ensure health information security. Support was also expressed for enhancing applications that are designed for patient, or consumer use, such as Blue Button 2.0 (CMS' Medicare FFS open API for patient access to health information), and the development of patient-facing consumer applications that aggregate various longitudinal health information for the patient into one location. We plan to continue to review the public comments we receive to help identify opportunities for CMS to advance interoperability in future rulemaking and subregulatory guidance.

CMS is also working with partners in the private sector to promote interoperability. In 2018, CMS began participating in the Da Vinci project, a private-sector initiative led by Health Level 7 (HL7), a standards development organization. For one of the use cases under this project—called “Coverage Requirements and Documentation Rules Discovery”—the Da Vinci project developed a draft Fast Healthcare Interoperability Resources (FHIR) standard during the summer and fall of 2018. In June 2018, in support of the Da Vinci project, the CMS Medicare FFS program began: (1) Developing a prototype Documentation Requirement Lookup Service for the Medicare FFS program; (2) populating it with the list of items/services for which prior authorization is required by the Medicare FFS program; and (3) populating it with the documentation rules for oxygen and Continuous Positive Airway Pressure (CPAP) devices. More information about the FFS Medicare program's efforts to support these Da Vinci use cases are available at go.cms.gov/MedicareRequirementsLookup.

We encourage all payers, including but not limited to MA organizations, Medicaid managed care plans and CHIP managed care entities, and QHP issuers in FFEs to follow CMS's example and align with the Da Vinci Project to: (1) Develop a similar lookup service; (2) populate it with their list of items/services for which prior authorization is required; and (3) populate it with the documentation rules for at least oxygen and CPAP. By taking this step, health plans can join CMS in helping to build an ecosystem that will allow providers to connect their EHRs or practice management systems and efficient work flows with up-to-date information on which items and services require prior authorization and what the documentation requirements are for various items and services under that patient's current plan enrollment.

In the 8 years since the first HHS rulemakings to implement HITECH, significant progress has been made in the adoption of EHRs by hospitals and clinicians; however, progress on interoperability needs to be accelerated.

In section 106(b) of MACRA, Congress declared it a national objective to achieve widespread exchange of health information through interoperable certified EHR technology nationwide by December 31, 2018. Not later than July 1, 2016, the Secretary was to establish metrics to be used to determine if and to the extent this objective was achieved. If the objective is not achieved by December 31, 2018, the Secretary must submit a report not later than December 31, 2019, that identifies barriers to the objective and recommends actions that the federal government can take to achieve the objective. In April 2016, ONC published the “Office of the National Coordinator for Health Information Technology; Medicare Access and CHIP Reauthorization Act of 2015; Request for Information Regarding Assessing Interoperability for MACRA” RFI (81 FR 20651). Based on stakeholder input received in response to the RFI, ONC subsequently identified the following two metrics for interoperability (see https://www.healthit.gov/​sites/​default/​files/​fulfilling_​section_​106b1c_​of_​the_​medicare_​access_​and_​chip_​reauthorization_​act_​of_​2015_​06.30.16.pdf):

• Measure #1: Proportion of health care providers who are electronically engaging in the following core domains of interoperable exchange of health information: sending, receiving, finding (querying), and integrating information received from outside sources.
• Measure #2: Proportion of health care providers who report using the information they electronically receive from outside providers and sources for clinical decision-making.

ONC recently provided an update on these metrics in its 2018 Report to Congress—Annual Update on the Adoption of a Nationwide System for the Electronic Use and Exchange of Health Information (see https://www.healthit.gov/​sites/​default/​files/​page/​2018-12/​2018-HITECH-report-to-congress.pdf). ONC will continue to evaluate nationwide performance according to the identified metrics, and believes current developments, such as policy changes being implemented under the 21st Century Cures Act (Cures Act) (Pub. L. 114-255, enacted December 13, 2016) will contribute to increasingly improved performance under these metrics.

In addition, the Cures Act included provisions to advance interoperability and health information exchange, including, for example, enhancements to ONC's Health IT certification program and a definition of “information blocking” (as discussed further in section VIII. of this proposed rule). These provisions have been addressed in depth in ONC's proposed rule “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (published elsewhere in this issue of the Federal Register).

Section 4003 of the Cures Act added a definition of “interoperability” as paragraph 10 of section 3000 of the PHSA (42 U.S.C. 300jj (9)) (as amended). Under section 3000 of the PHSA, `interoperability', with respect to health IT, means technology that enables the secure exchange of electronic health information with, and use of electronic health information from, other health IT without special effort on the part of the user. It also allows for complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state or federal law and does not constitute information blocking as defined in section 3022(a) of the PHSA.

This definition aligns with the definition under MACRA and the HHS vision and strategy for achieving a health information ecosystem within which all individuals and their health care providers are able to send, receive, find, and use electronic health information in a manner that is appropriate, secure, timely, and reliable to support the health and wellness of individuals through informed shared decision-making, as well as through patient choice of health plans and providers. Accordingly, except where we further or otherwise specify for a specific policy or purpose, when we use the term “interoperability” within this proposed rule we are referring to the definition in section 3000 of the PHSA.

E. Challenges and Barriers to Interoperability

Through significant stakeholder feedback, we understand that there are many barriers to interoperability which have obstructed progress over the years. We have conducted stakeholder meetings and roundtables; solicited comments via RFIs; and received additional feedback through letters and rulemaking. All of this input together has contributed to our proposals in this proposed rule. Some of the main barriers shared with us are addressed in the following sections. While we have made efforts to address some of these barriers in this proposed rule and through prior rules and actions, we believe there is still considerable work to be done to overcome some of these considerable challenges toward achieving interoperability.

1. Patient Identifier and Interoperability

In the Interoperability RFI in the FY 2019 IPPS proposed rule (83 FR 20550), we solicited feedback on positive solutions to better achieve interoperability or the sharing of health care information between providers. A number of commenters noted that the lack of a unique patient identifier (UPI) inhibited interoperability efforts because, without a unique identifier for each patient, the safe and secure electronic exchange of health information is constrained because it is difficult to ensure that the relevant records are all for the same patient.

As part of efforts to reduce the administrative costs of providing and paying for health care, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) (Pub. L. 104-191, enacted August 21, 1996) required the adoption of a “unique individual identifier for healthcare purposes,” commonly referred to as a UPI. At the time HIPAA was enacted, HHS began to consider what information would be needed to develop a rule to adopt a UPI standard. An initial Notice of Intent to issue a proposed rule on requirements for a unique health identifier for individuals was published in the November 2, 1998 Federal Register (63 FR 61773-61774).

Such an identifier has the potential to facilitate the accurate portability of health information by allowing correct patient matching because the universal identifier allows for accurate and timely patient record linking between providers across the care continuum and it allows a patient's complete record to easily move with them from provider to provider. However, stakeholders immediately raised significant concerns regarding the impact of this UPI on health information security and privacy. Stakeholders were concerned that if there was a single identifier used across systems, it would be easier for that information to be compromised, exposing protected health information (PHI) more easily than in the current medical record environment that generally requires linking several pieces of personally identifying information to link health records.

The National Committee on Vital Health Statistics (NCVHS), the statutory public advisory body to the Secretary of Health and Human Services (the Secretary) for health data, statistics, privacy, and national health information policy and HIPAA, conducted extensive hearings in the first year after HIPAA was enacted to evaluate this and other HIPAA-related implementation issues. The NCVHS First Annual Report to the Congress on the Implementation of the Administrative Simplification Provisions of the Health Insurance Portability and Accountability Act, February 3, 1998, outlines the NCVHS' efforts to obtain feedback on the UPI (https://ncvhs.hhs.gov/​wp-content/​uploads/​2018/​03/​yr1-rpt-508.pdf). Through this process, NCVHS found a lack of consensus on how best to define a UPI and controversy around the use of a UPI due to privacy and data security concerns. Those in favor of adopting a UPI believe a UPI is the most efficient way to foster information sharing and accurate patient record linking, where those against it are concerned about patient privacy and data security. NCVHS found these privacy and data security concerns outweighed the benefits of a UPI.

The NCVHS recommended that the Secretary not move forward with a proposed rule on a patient identifier until further discussions could be had to fully understand the privacy and data security concerns, as well as the full breadth of options beyond a single identifier. NCVHS suggested the Secretary work to maximize public participation in soliciting a variety of options for establishing an identifier or an alternative approach for identifying individuals and linking health information of individuals for health purposes.

Appreciating the significant concerns raised by stakeholders regarding implementing a UPI, Congress included language in the Omnibus Consolidated and Emergency Supplemental Appropriations Act of 1999 (Pub. L. 105-277, enacted October 21, 1998) and in each subsequent Appropriations bill, stating “None of the funds made available in this Act may be used to promulgate or adopt any final standard under section 1173(b) of the Act (42 U.S.C. 1320d-2(b)) providing for, or providing for the assignment of, a unique health identifier for an individual (except in an individual's capacity as an employer or a health care provider), until legislation is enacted specifically approving the standard.” This language has effectively prohibited HHS from engaging in rulemaking to adopt a UPI standard. Consequently, the Secretary withdrew the Notice of Intent to pursue rulemaking on this issue on August 9, 2000 (https://www.reginfo.gov/​public/​do/​eAgendaViewRule?​pubId=​200010&​RIN=​0938-AI91).

In recent years, concerns regarding the privacy and security of information have only increased. For example, in the first quarter through third quarter of FY 2018 (October 1, 2017 through June 30, 2018), 276 breach incidents were reported to the HHS Office of Civil Rights (OCR) affecting 4,341,595 individuals (https://ocrportal.hhs.gov/​ocr/​breach/​breach_​report.jsf).

Although the appropriations language regarding the UPI standard has remained unchanged, in the report accompanying the 2017 appropriations bill, Congress additionally stated, “Although the Committee continues to carry a prohibition against HHS using funds to promulgate or adopt any final standard providing for the assignment of a unique health identifier for an individual until such activity is authorized, the Committee notes that this limitation does not prohibit HHS from examining the issues around patient matching. Accordingly, the Committee encouraged the Secretary, acting through ONC and CMS, to provide technical assistance to private-sector led initiatives to develop a coordinated national strategy that will promote patient safety by accurately identifying patients to their health information.” (H.R. Rep. No. 114-699, p. 110, https://www.gpo.gov/​fdsys/​pkg/​CRPT-114hrpt699/​pdf/​CRPT-114hrpt699.pdf). Congress has repeated this guidance for 2018 and 2019. This guidance directed HHS to focus on examining issues around patient matching and to provide technical assistance to private sector-led initiatives focusing on a patient matching solution.

Unlike a UPI, which assigns a unique identifier—either numerical or otherwise—to each patient, patient matching is a process by which health information from multiple sources is compared to identify common elements, with the goal of identifying records representing a single patient. This is generally done by using multiple demographic data fields such as name, birth date, gender, and address. The goal of patient matching is to link one patient's data across multiple databases within and across health care providers in order to obtain a comprehensive view of that patient's health care information.

ONC has stated that patient matching is critically important to interoperability and the nation's health IT infrastructure as health care providers must be able to share patient health information and accurately match a patient to his or her data from a different provider in order for many anticipated interoperability benefits to be realized.

Patient matching can be less precise than a UPI due to the reliance on demographic attributes (such as name and date of birth) which are not unique traits to a particular patient; further, patient matching is often dependent on manual data entry and data maintained in varying formats. Matching mistakes can contribute to adverse events, compromised safety and privacy, and increased health care costs (see https://www.healthit.gov/​sites/​default/​files/​hie-interoperability/​nationwide-interoperability-roadmap-final-version-1.0.pdf). However, a wide range of strategies and best practices currently being deployed across the industry have been shown to improve patient matching rates, suggesting that patient matching approaches can be an effective solution when appropriately implemented (see https://www.healthit.gov/​sites/​default/​files/​patient_​identification_​matching_​final_​report.pdf).

Many stakeholders commenting on the interoperability RFIs included in the 2019 proposed payment rules indicated that patient matching is a “core functionality” of patient identification and necessary to ensure care coordination and the best patient outcomes. Commenters also noted that a consistently used matching strategy could accomplish the original goals of a UPI with a diminished risk to individual privacy and health information security.

Several commenters noted that the lack of a UPI impacted interoperability, but finding a suitable and consistent matching strategy could address this issue. These commenters often specifically supported Congress' guidance to have ONC and CMS provide technical assistance to the private sector to identify this strategy. To help jump start the process of finding a solution to patient matching, ONC launched the Patient Matching Algorithm Challenge in 2017, awarding six winners $75,000 in grants in late 2017 (https://www.patientmatchingchallenge.com/​challenge-information/​challenge-details). The goal of the Patient Matching Algorithm Challenge was to bring about greater transparency and data on the performance of existing patient matching algorithms, spur the adoption of performance metrics for patient data matching algorithm vendors, and positively impact other aspects of patient matching such as deduplication and linking to clinical data.

We continue to support ONC's work promoting the development of patient matching initiatives. Per Congress' guidance, ONC is looking at innovative ways to provide technical assistance to private sector-led initiatives to further develop accurate patient matching solutions in order to promote interoperability without requiring a UPI.

We understand the significant health information privacy and security concerns raised around the development of a UPI standard and the current prohibition against using HHS funds to adopt a UPI standard. Recognizing Congress' statement regarding patient matching and stakeholder comments stating that a patient matching solution would accomplish the goals of a UPI, we seek comment for future consideration on ways for ONC and CMS to continue to facilitate private sector efforts on a workable and scalable patient matching strategy so that the lack of a specific UPI does not impede the free flow of information. We also seek comment on how we may leverage our program authority to provide support to those working to improve patient matching. In addition, we intend to use comments for the development of policy and future rulemaking.

2. Lack of Standardization

Lack of standardization inhibits the successful exchange of health information without additional effort on the part of the end user. To achieve secure exchange of health information across health IT products and systems that can be readily used without special effort by the user, both the interface technology and the underlying data must be standardized, so all systems are “speaking the same language.” Consistent use of modern computing standards and applicable content standards (such as clinical vocabularies) are fundamental to achieving full-scale technical interoperability (systems can connect and exchange data unaltered) and semantic interoperability (systems can interpret and use the information that has been exchanged). Lack of such standards creates a barrier to interoperability. Where specific standards are not consistently used, particularly to structure exchange interfaces such as APIs, the exchange is more difficult and expensive than it needs to be and the recipient of exchanged data must often undertake substantial special effort to make sense of the information.

In this proposed rule, similar to CMS' Blue Button 2.0 approach for Medicare FFS,^[3] we propose to require that all MA organizations, Medicaid managed care plans, CHIP managed care entities, Medicaid state agencies, CHIP agencies that operate FFS systems, and issuers of QHPs in the FFEs, deploy standardized, open APIs to make certain information available to enrollees as discussed in section III. of this proposed rule.

The lack of a sufficiently mature API functionality technical standard has posed a challenge and impediment to advancing interoperability. In 2015, ONC finalized an API functionality certification criterion in the “2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications” Final Rule (2015 Edition final rule) (80 FR 62602). However, while a consensus technical standard specific to the API technical functionality was in development, it had not yet matured enough for inclusion in the 2015 Edition final rule, which does not identify a specific standard for API functionality.

As discussed in greater detail in section II of this proposed rule, we believe that a specific foundational standard for API functionality has matured sufficiently enough for ONC to propose it for HHS adoption (published elsewhere in this issue of the Federal Register). To take full advantage of this proposed standard, as well as already adopted standards applicable to content exchanged via APIs, we propose in sections II. and III. of this proposed rule to require that MA organizations, Medicaid managed care plans, Medicaid state agencies, CHIP managed care entities, CHIP agencies that operate FFS systems, and QHP issuers in FFEs comply with the ONC-proposed regulations for this standard. Those proposed regulations would require deployment of API technologies conformant with the API technical standard proposed by ONC for HHS adoption at 45 CFR 170.215 and other applicable standards such as content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and proposed by ONC for HHS adoption at 45 CFR 170.213 (published elsewhere in this issue of the Federal Register). Furthermore, we note that we intend to continue to work with stakeholders to develop standards that will advance interoperability.

3. Information Blocking

As explained above, information blocking is defined in section 3022(a) of the PHSA. Understanding this definition, information blocking could be considered to include the practice of withholding data, or intentionally taking action to limit or restrict the compatibility or interoperability of health IT. Through stakeholder outreach, roundtables, and letters we have received, we understand that health care providers may limit or prevent data exchange in an effort to retain patients. By withholding a patient's health information from competing health care providers, a health care provider can effectively inhibit a patient from freely moving within the health care market because that patient would not otherwise have access to their complete health information.

We additionally understand from stakeholder feedback that in certain cases a health IT vendor has prohibited the movement of data from one health IT system to another in an effort to maintain their customer base.

Information blocking is a significant threat to interoperability and can limit the ability for providers to coordinate care and treat a patient based on the most comprehensive information available. In sections VIII.B. and C. of this proposed rule we propose to publicly report the names of clinicians and hospitals who submit a “no” response to certain attestation statements related to the prevention of information blocking in order to deter health care providers from engaging in conduct that could be considered information blocking.

Preventing and avoiding information blocking is important to advancing interoperability. We believe this proposal would help discourage health care providers from information blocking and clearly indicates CMS's commitment to preventing such practices.

4. Lack of Adoption/Use of Certified Health IT Among Post-Acute Care (PAC) Providers

PAC facilities are critical in the care of patients' post-hospital discharge, and can be a determining step in the health progress for those patients.^[4] Interoperable health IT can improve the ability of these facilities to coordinate and provide care; however, long-term care and PAC providers, such as nursing homes, home health agencies (HHAs), long-term care providers, and others, were not eligible for the EHR Incentive Programs under the HITECH Act. Based on the information we have, we understand that this was a contributing factor to these providers not adopting CEHRT at the same rate as eligible hospitals and physicians, who were able to adopt CEHRT using the financial incentives provided under the programs.^[5 6]

While a majority of skilled nursing facilities (SNFs) used an EHR in 2016 (64 percent), there is considerable work to be done to increase adoption and the exchange of data in this provider population. In that same year, only three out of 10 SNFs electronically exchanged (that is, sent or received) key clinical health information, and only 7 percent had the ability to electronically send, receive, find, and integrate patient health information. In 2017, an ONC survey found that more HHA) (78 percent) adopted EHRs than SNFs (66 percent), but integration of received information continued to lag behind for both HHAs (36 percent) and SNFs (18 percent). While both ONC surveys focused on SNFs, it is important to note the large provider overlap between SNFs and other nursing facilities. In 2014, 14,409 out of 15,640 (92 percent) of nursing homes were certified for both Medicare and Medicaid.^[7]

Long-term hospitals, inpatient rehabilitation facilities (IRFs), SNFs, and HHAs are required to submit to CMS standardized patient assessment data described in section 1899B(b)(1) of the Act (as added by section 2(a) of the Improving Medicare Post-Acute Care Transformation Act of 2014 (IMPACT Act) (Pub. L. 113-185, enacted October 6, 2014)). We have defined the term “standardized patient assessment data” (or “standardized resident assessment data” for purposes of SNFs) as patient or resident assessment questions and response options that are identical in all four PAC assessment instruments, and to which identical standards and definitions apply. Section 1899B(b)(1)(B) of the Act states that the categories for which standardized patient or resident assessment data must be submitted include, at a minimum, functional status; cognitive function; medical conditions and co-morbidities; special services, treatments and interventions; and impairments. Section 1899B(b)(1)(A) of the Act requires that such data must be submitted through the applicable reporting provision that applies to each PAC provider type using the PAC assessment instrument that applies to the PAC provider. Section 1899B(a)(1)(B) of the Act additionally requires that these data be standardized and interoperable so as to allow for their exchange among health care providers, including PAC providers, to ensure coordinated care and improved Medicare beneficiary outcomes as these patients transition throughout the care continuum. To enable the interoperable exchange of such information, we have adopted certain patient assessment data elements as standardized patient or resident assessment data and mapped them to appropriate health IT standards which can support the exchange of this information. For more information, we refer the reader to the CMS website at https://del.cms.gov/​DELWeb/​pubHome.

5. Privacy Concerns and HIPAA

The Privacy, Security, and Breach Notification Rules under HIPAA (45 CFR parts 160 and 164) support interoperability by providing assurance to the public that PHI as defined in 45 CFR 160.103 is maintained securely and shared only for appropriate purposes or with express authorization of the individual. For more than a decade, the HIPAA Rules have provided a strong privacy and security foundation for the health care system. However, we have heard that lack of harmonization between federal and state privacy and security standards can create uncertainty or confusion for HIPAA covered entities that want to exchange health information. Resources about how the HIPAA Rule permits health care providers and health plans to share health information using health IT for purposes like treatment or care coordination is available on the HHS OCR website. See https://www.hhs.gov/​hipaa/​for-professionals/​privacy/​guidance/​permitted-uses/​index.html.

Although barriers to interoperability do exist, HHS and private industry are actively working to address them. On June 6, 2018, the HHS Deputy Secretary initiated the Regulatory Sprint to Coordinated Care (RS2CC). In support of this effort, the HHS Office of Inspector General (OIG) released an RFI on barriers to coordinated care or value-based care, which was out for public comment through October 26, 2018 (83 FR 43607). Together, CMS and ONC are working to address information blocking via rulemaking. We are actively working to improve data standardization, particularly through the use of APIs. And, we are using available policy levers to encourage greater adoption of EHR technology and interoperability among PAC providers. We provide resources to help providers see how HIPAA and interoperability work together. And, we are leveraging private sector relationships to find patient matching solutions in lieu of a patient identifier.

F. Summary of Major Provisions

To empower beneficiaries of Medicaid and CHIP FFS programs and enrollees in MA organizations, Medicaid and CHIP managed care entities, and QHP issuers in the FFEs (when mentioned throughout this proposed rule, this includes QHPs certified by FFEs regardless of whether enrollees enroll through the FFE or off the FFE), we are proposing several initiatives to break down the barriers that impede patients' ease of access to their electronic health care information; we propose to create and implement new mechanisms for them to access to their own health care information, as well as the ability to decide how, when, and with whom to share their information. We are proposing to require that a variety of information be made accessible to these impacted patients via “openly published” (or simply “open”) APIs- that is, APIs for which the technical and other information required for a third-party application to connect to them is publicly available. This will provide these patients with convenient access to their health care information in accordance with the HIPAA Privacy Rule access standard at 45 CFR 164.524, and an increase in their choice of applications with which to access and use their own electronic health information, as discussed above, and other information relevant to managing their health, enabling open APIs to improve competition and choice as they have in other industries. We propose to require MA organizations, Medicaid state agencies, state CHIP agencies, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs (by requiring them to comply with the proposed ONC standard) to implement open APIs consistent with the API technical standards proposed by ONC for adoption by HHS and to use content and vocabulary standards adopted by HHS at 45 CFR part 162 and 42 CFR 423.160, and proposed by ONC for adoption by HHS at 45 CFR 170.213 (published elsewhere in this issue of the Federal Register).

Effective coordination and appropriate sharing of enrollee information between health plans can reduce the need for providers to write duplicative letters of medical necessity, or it could reduce instances of subjecting beneficiaries to unnecessary repetition of step therapy, or repeated utilization reviews, risk screenings and assessments. It could also help to streamline prior authorization procedures or reduce instances where the clinician might need to intervene personally with a payer to ensure his or her patient received the treatment necessary. We are proposing to require payers to support beneficiaries in coordinating their own care via payer to payer care coordination. In addition to existing care coordination efforts between plans, we propose that a plan must, if asked by the beneficiary, forward his or her information to a new plan or other entity designated by the beneficiary for up to 5 years after the beneficiary has disenrolled with the plan. Such transactions would be made in compliance with applicable laws. We are proposing a requirement for MA Plans, Medicaid and CHIP Managed Care entities (MCOs, PIHPs, PAHPs), and QHP issuers in FFEs to coordinate care between plans by exchanging, at a minimum, the data elements in the United States Core Data for Interoperability (USCDI) standard ^[8] at enrollee request at specified times.

We believe that payers' ability to share enrollee claims, encounter data, utilization history, and clinical health information they may have for their enrollees with one another, as well as their ability to share that information with patients and health care providers, when approved by the patient and appropriate under applicable law, using interoperable electronic means will considerably improve patient access to information, reduce provider burden, and reduce redundant and otherwise unnecessary data-related policies and procedures. We are proposing to require that all MA organizations, Medicaid and CHIP Managed Care entities (MCOs, PIHPs, and PAHPs), and QHP issuers in FFEs (with the exception of stand-alone dental plans (SADPs)) must participate in a trusted health information exchange network meeting criteria for interoperability. Further, we discuss an approach to payer-to-payer and payer-to-provider interoperability which leverages such existing trusts networks.

States and CMS routinely exchange data to support the administration of benefits to Medicare-Medicaid dually eligible beneficiaries. This includes “buy-in” data on who is enrolled in Medicare, and who is liable for paying the dual eligible beneficiary's Part A and B premiums. Buy-in data exchanges support state, CMS, and Social Security Administration (SSA) premium accounting, collections, and enrollment functions. This also includes “MMA” data on dual eligibility status (called the “MMA file” after the Medicare Prescription Drug, Improvement and Modernization Act of 2003 (MMA) (Pub. L. 108-173, enacted December 8, 2003)), which are used in all four Parts of Medicare. We are proposing to establish frequency requirements to require all states to participate in daily exchange of buy-in data with CMS by April 1, 2022, and to update frequency requirements to require all states to submit MMA file data to CMS daily by April 1, 2022.

We are actively working with our partners throughout HHS to deter the practice of information blocking. We believe it would benefit patients to know if their health care providers attested negatively to any of the prevention of information blocking attestation statements under the Quality Payment Program (QPP) or the Medicare FFS Promoting Interoperability Program. In previous testing with patients and caregivers, we have learned that effective use of CEHRT is important to them when making informed health care decisions. To address this issue, we are proposing to publicly post information about negative attestations on appropriate CMS websites.

Section 4003 of the Cures Act recognized the importance of making provider digital contact information available through a common directory. To facilitate this, CMS has updated the National Plan and Provider Enumeration System (NPPES) to be able to capture this digital contact information. Now that the systems are in place, we seek to increase the number of clinicians with valid and current digital contact information available through NPPES. We are proposing to publicly identify those clinicians who have not submitted digital contact information in NPPES. Further, we are proposing to align program requirements for MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP agencies that operate FFS systems, CHIP managed care entities, and QHP issuers in FFEs (with the exception of issuers of SADPs) such that each payer/plan issuer would make provider directory information publicly available via an API.

Electronic patient event notifications from hospitals, or clinical event notifications, are widely recognized as an effective tool for improving care coordination across settings, especially for patients at admission, discharge, and transfer. We are proposing to revise the conditions of participation for hospitals (including short-term acute care hospitals, long-term care hospitals (LTCHs), rehabilitation hospitals, psychiatric hospitals, children's hospitals, and cancer hospitals) and CAHs to require that these entities send patient event notifications to another health care facility or to another community provider. We propose to limit this requirement to only those Medicare- and Medicaid-participating hospitals and CAHs that possess EHRs systems with the technical capacity to generate information for electronic patient event notifications.

We also plan to test ways to promote interoperability across the health care spectrum through models tested by the Center for Medicare and Medicaid Innovation (“Innovation Center”). Innovation Center models offer a unique opportunity to engage with health care providers and other entities in innovative ways and to test concepts that have the ability to accelerate change in the U.S. health care system, including to promote interoperability. As such, we are soliciting public comment on general principles around interoperability within Innovation Center models for integration into new models, through provisions in model participation agreements or other governing documents. In applying these general principles, we intend to be sensitive to the details of individual model design, and the characteristics and capacities of the participants in each specific model.

One of the many proposals we considered but did not include in this proposed rule was a proposal to make updates to the Promoting Interoperability Program (formerly the Medicare and Medicaid EHR Incentive Programs) to encourage eligible hospitals and CAHs to engage in certain activities focused on interoperability. This concept was initially introduced in a request for public comment in the FY 2019 IPPS/LTCH PPS proposed rule (83 FR 20537 through 20538). We discussed a possible future strategy in which we would create a set of priority health IT or “interoperability” activities that would serve as alternatives to measures in the Promoting Interoperability Program. We discussed creating a set of priority health IT activities with a focus on interoperability and simplification to reduce health care provider burden while allowing flexibility to pursue innovative applications of health IT to improve care delivery. We offered three different examples of activities which might be included under such an approach, including:

• Participation in, or serving as, a health information network which is part of the Trusted Exchange Framework and Common Agreement (TEFCA);
• Maintaining an open API which allows persistent access to third parties which enables patients to access their health information; and
• Participating in piloting and testing of new standards that support emerging interoperability use cases.

While we are not proposing this here, we expect to introduce a proposal for establishing “interoperability activities” in the FY 2020 IPPS/LTCH PPS rulemaking in conjunction with other updates to the Promoting Interoperability Program. To help inform future rulemaking, we invite comments on the concepts discussed above, as well as other ideas for “interoperability activities” for which eligible hospitals and CAHs could receive credit in lieu of reporting on program measures.

Finally, we include two RFIs. One related to interoperability and health IT adoption in PAC settings, and one related to the role of patient matching in interoperability and improved patient care.

II. Technical Standards Related to Interoperability

A. Technical Approach and Standards

1. Use of FHIR for APIs

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

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

A core policy principle we aim to support across all proposals in this proposed rule is that every American should be able, without special effort or advanced technical skills, to see, obtain, and use all electronically available information that is relevant to their health, care, and choices—of plans, providers, and specific treatment options. This includes two types of information: Information specifically about the individual that requires appropriate diligence to protect the individual's privacy, such as their current and past medical conditions and care received, as well as information that is of general interest and should be widely available, such as plan provider networks, the plan's formulary, and coverage policies.

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

In contrast, consider the ease with which consumers can choose and use a navigation application which integrates information on their current location, preferences, and real-time traffic conditions to choose the best route to a chosen destination. Consumers do not have to log into a different “location” portal to learn their current geographic coordinates, write them down, and then log into a separate “map” portal to enter their current coordinates to request directions to their destination.

An API can be thought of as a set of commands, functions, protocols, or tools published by one software developer (“A”) that enable other software developers to create programs (applications or “apps”) that can interact with A's software without needing to know the internal workings of A's software, all while maintaining consumer privacy data standards. This is how API technology enables the seamless user experiences associated with applications familiar from other aspects of many consumers' daily lives, such as travel and personal finance. Standardized, transparent, and pro-competitive API technology can enable similar benefits to consumers of health care services.^[10]

While acknowledging the limits of our authority to require use of APIs to address our goals for interoperability and data access, we are proposing in this rule to use our programmatic authority in Medicare, Medicaid, CHIP, and over QHPs in FFEs to advance these goals. Therefore, we are proposing to require that a variety of data be made accessible to MA enrollees, Medicaid beneficiaries, CHIP enrollees, and enrollees in QHPs in FFEs, by requiring that MA organizations, Medicaid state agencies, Medicaid managed care plans, CHIP agencies, CHIP managed care entities, and QHPs in FFEs, adopt and implement “openly published” (or simply “open”) APIs. Having certain data available through open APIs would allow these enrollees to use the application of their choice to access and use their own electronic health information and other information relevant to managing their health.

Much like our efforts under the Medicare Blue Button 2.0 and MyHealthEData initiatives, which made Parts A, B, and D claims data available to Medicare beneficiaries, our proposal would result in claims and coverage information being accessible for the vast majority of Medicare beneficiaries by requiring MA organizations to take new steps—by implementing the API described in this proposed rule—to make claims data available to their enrollees. We expect that our proposal would also benefit all Medicaid beneficiaries because our proposal applies to Medicaid state agencies (which administer Medicaid FFS programs), and all types of Medicaid managed care plans (MCOs, PIHPs, and PAHPs), and CHIP agencies (which administer CHIP FFS) and CHIP managed care entities (MCOs, PIHPs, and PAHPs). Finally, while our proposal is only applicable to QHPs in FFEs, we hope that states operating Exchanges might consider adopting similar requirements for QHPs in State-Based Exchanges (SBEs), and that other payers in the private sector might consider voluntarily offering data accessibility of the type included in this proposal so that even more patients across the American health care system can easily have and use such information to advance their choice and participation in their health care. We hope that the example being set by CMS will raise consumers' expectations and encourage other payers in the market to take similar steps to advance patient access and empowerment outside the scope of our proposed requirements.

An “open API,” for purposes of this proposed rule, is simply one for which the technical and other information required for a third-party application to connect to it is openly published. Open API does not imply any and all applications or application developers would have unfettered access to people's personal or sensitive information. Rather, an open API's published technical and other information specifically includes what an application developer would need to know to connect to and obtain data available through the API.

We recommend reviewing the discussion of the standardized API criterion and associated policy principles and technical standards included in ONC's proposed rule “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” (published elsewhere in this issue of the Federal Register) for those seeking more detailed information on API functionality and interoperability standards relevant to electronic health information. While that discussion is specific to health IT certified under ONC's Health IT Certification Program rather than the information systems generally used by payers and plan issuers for claims, encounters, or other administrative or plan operational data, it includes information applicable to interoperability standards, as well as considerations relevant to establishing reasonable and non-discriminatory terms of service for applications seeking to connect to the open API. However, it is important to reiterate that we are not proposing to require health plan issuers to use Health IT Modules certified under ONC's program to make administrative data such as claims history or provider directory information available to enrollees.

In developing this proposed rule, we considered how to advance the sort of interoperability and innovation in the health system supported by open APIs in other industries. We have also collaborated with ONC to align with and leverage relevant API policies ONC has proposed to implement Cures Act requirements. In general, we believe three attributes of open APIs are particularly important to achieve the goal of offering individuals convenient access, through applications they choose, to available and relevant electronic health information. The three API attributes are:

• The API technologies themselves, not just the data accessible through them, are standardized;
• The APIs are technically transparent; and
• The APIs are implemented in a pro-competitive manner.

In this section, we discuss these concepts generally and how they are applicable in the health care context for all payers, as well as explain how these are relevant to our specific proposals, which are discussed in detail in section III. of this proposed rule.

a. Standardized

Technical consistency and implementation predictability are fundamental to scale API-enabled interoperability and reduce the level and costs of custom development otherwise necessary to access, exchange, and use health information. From an industry standpoint, a consistent and predictable set of API functions, as well as content and formatting standards, provide the health IT ecosystem with known technical requirements against which application developers can build applications (including but not limited to “mobile apps”) and other innovative services which users can select to access and manage the data they need. Therefore, to achieve interoperability consistent with the PHSA definition, the proposals in section III. of this proposed rule would effectively require that API technologies deployed by health plans subject to this rule use modern computing standards (such as RESTful interfaces ^[11] and XML/JSON), and present the requested information using widely recognized content standards (such as standardized vocabularies of clinical terms), where applicable.

b. Transparent

Transparency and openness around API documentation is commonplace in many other industries and has fueled innovation, growth, and competition. Documentation associated with APIs deployed by health care providers, health plans, and other entities engaged in exchanging electronic health information typically addresses the information that would be material to persons and entities that use or create software applications that interact with the API (API users). Information material to API users includes, but is not necessarily limited to, all terms and conditions for use of the API, including terms of service, restrictions, limitations, obligations, registration process requirements, or other similar requirements that would be needed to:

• Develop software applications to interact with the API;
• Connect software applications to the API to access electronic health information through the API;
• Use any electronic health information obtained by means of the API technology; and
• Register software applications to connect with the API.

As discussed in section III. of this proposed rule, we are proposing that certain entities (MA organizations, State Medicaid agencies, Medicaid managed care plan, State CHIP agencies, CHIP managed care entities, and QHPs in FFEs), supported by the suppliers of their API technology, and for the API technology they use to comply with the requirements we propose in this proposed rule, be required to make freely and publicly accessible the specific business and technical documentation necessary to interact with these APIs. Thus, we propose to require that these entities comply with the requirements that ONC has proposed that the Secretary adopt for developers and users of health IT certified to the API criteria at 45 CFR 170.315 (published elsewhere in this issue of the Federal Register).

c. Pro-Competitive

Pro-competitive practices in selecting, configuring, and maintaining APIs are those business practices that promote the efficient access to, exchange of, and use of electronic health information to support a competitive marketplace that enhances consumer value and choice of direct-to-consumer technology, health coverage, and care. We believe that an ultimate goal of all participants in the health care ecosystem is that individuals should be able to use an application they choose to connect and access, without special effort, their electronic health information held by health care providers, health plans, or any health information networks, within practical and prudent limits that do not needlessly hinder their ability to connect to the API in a persistent manner.

Such acceptable limits include technical compatibility and ensuring the application does not pose an unacceptable level of risk to a system when connecting to an API offered by that system, consistent with the HIPAA Privacy and Security Rules and guidance issued by the HHS OCR,^[12] to which the Secretary delegated the authority to enforce HIPAA privacy and security requirements. Organizational policies and procedures needed to comply with any additional requirements under state laws that would apply in a given situation would also be viewed as necessary and not anti-competitive. Examples of practices we would view as pro-competitive might include proactively advising enrollees they are not required to use only the organization's own or preferred applications to access, use, and share their health information. Such advice would be publicly available and include information relevant to the enrollee about how they could request access to their information through a third-party application of their choosing.

We recognize that organizations subject to the open API requirements proposed in section III. of this proposed rule need to take reasonable and necessary steps to fulfill the organizations' duties under all applicable laws and regulations to protect the privacy and security of personally identifiable information (PII), including but not limited to PHI under HIPAA as defined at 45 CFR 160.103; those privacy and security protection obligations remain applicable even in the context of complying with our proposal. However, we do not believe it is appropriate to use security and privacy concerns as an opportunity to engage in anti-competitive practices. Anti-competitive practices might include declining to assess the technical compatibility or security risk of an application provided to prospective enrollees by a competing plan, despite an enrollee request to disclose their PHI to that application through the API.

2. Privacy and Security Concerns in the Context of APIs

We have received a wide range of stakeholder feedback on privacy and security issues in response to prior proposals ^[13] about policies related to APIs that would allow consumers to use any app of their choosing to access PHI held by a HIPAA covered entity. This feedback includes concerns about potential security risks to PHI created by an API connecting to third-party applications.

We appreciate these concerns. Deploying API technology that offers consumers the opportunity to access their electronic health information that is held by a covered entity (which includes but is not limited to MA organizations, the Medicare Part A and B programs, the Medicaid program, CHIP, QHP issuers on the FFE, and other health plan issuers) does not lessen the covered entity's duties under HIPAA and other law to protect the privacy and security of information it holds, including but not limited to PHI. A covered entity implementing an API to enable individuals to access their health information must take reasonable steps to ensure an individual's information is only disclosed as permitted or required by applicable law. The entity must take greater care in configuring and maintaining the security functionalities of the API and the covered entities' electronic information systems to which it connects than would be needed if it was implementing an API simply to allow easier access to widely available public information.

HIPAA covered entities and their business associates continue to be responsible for compliance with the HIPAA Rules, the Federal Trade Commission Act (FTC Act), and all other laws applicable to their business activities including but not limited to their handling of enrollees' PHI and other data. As we state repeatedly throughout this proposed rule, nothing in this proposed rule is intended to alter or should be construed as altering existing responsibilities to protect PHI under the HIPAA Rules and requirements.

However, we note that a number of stakeholders may believe that they are responsible for determining whether an application to which an individual directs their PHI be disclosed applies appropriate safeguards for the information it receives. Based on the OCR guidance discussed below, covered entities are not responsible under the HIPAA Rules for the security of PHI once it has been received by a third-party application chosen by an individual.

Under the HIPAA Privacy Rule,^[14] individuals have the right of access to inspect and receive a copy of a defined set of their PHI as detailed at 45 CFR 164.501. Specifically, as OCR has indicated in regulations and guidance, an individual can exercise their right of access to direct a covered entity to send their information to a third party. When responding to an access request, “the same requirements for providing the PHI to the individual, such as the timeliness requirements, fee limitations, prohibition on imposing unreasonable measures, and form and format requirements, apply when an individual directs that the PHI be sent to another person or entity.” ^[15] Moreover, a covered entity may not impose unreasonable measures on an individual requesting access that serve as barriers to or unreasonably delay the individual from obtaining access to their PHI.^[16]

We refer readers to further OCR guidance on related issues, including: The liability of a covered entity in responding to an individual's access request to send the individual's PHI to a third party (FAQ 2039); ^[17] individuals' rights under HIPAA to have copies of their PHI transferred or transmitted to them in the manner they request, even if the requested mode of transfer or transmission is unsecure (FAQ 2060); ^[18] and, a covered entity's obligation under the HIPAA Breach Notification Rule if it transmits an individual's PHI to a third party designated by the individual in an access request, and the entity discovers the information was breached in transit (FAQ 2040).^[19] Under the HIPAA Privacy Rule, as explained in OCR's interpretive guidance, “individuals have the right under HIPAA to have copies of their PHI transferred or transmitted to them in the manner they request . . . as long as the PHI is `readily producible' in the manner requested, based on the capabilities of the covered entity and transmission or transfer in such a manner would not present an unacceptable level of security risk to the PHI on the covered entity's systems, such as risks that may be presented by connecting an outside system, application, or device directly to a covered entity's systems (as opposed to security risks to PHI once it has left the systems)” (HIPAA FAQ 2060).^[20]

We have also noted stakeholder concerns about protections which apply to non-covered entities such as direct-to-consumer applications. Stakeholders, as well as covered entities who may be required to send PHI to these applications, have noted concerns that unscrupulous actors could deploy direct-to-consumer applications specifically in order to profit from obtaining, using, or disclosing individuals' PHI (and potentially other information) in ways the individual either did not authorize or to which the individual would not knowingly consent.

When a non-HIPAA-covered entity discloses an individual's confidential information in a manner or for a purpose not consistent with the privacy notice and terms of use to which the individual agreed, the FTC has authority under the FTC Act to investigate and take action against unfair or deceptive trade practices. The FTC has applied this authority to a wide variety of entities. The FTC also enforces the FTC Health Breach Notification Rule, which applies to certain types of entities that fall outside of the scope of HIPAA, and therefore, are not subject to the HIPAA Breach Notification Rule.^[21]

We recognize that this is a complex landscape for patients, who we anticipate will want to exercise due diligence on their own behalf in reviewing the terms of service and other information about the applications they consider selecting. Therefore, we propose in section III. of this proposed rule specific requirements on the payers subject to these proposed regulations to ensure enrollees have the opportunity to become more informed about how to protect their PHI, important things to consider in selecting an application, and where they can lodge a complaint if they believe a HIPAA covered entity or business associate may have breached their duties under HIPAA or if they believe they have been subjected to unfair or deceptive actions or practices related to a direct-to-consumer application's privacy practices or terms of use.

In some circumstances, information that would be required to be made available through an API per an enrollee's information request under this proposed rule—which we view as consistent with the enrollee's right of access from a covered entity under the Privacy Rule—may not be readily transferable through the API. For instance, the covered entity may not hold certain information electronically. However, such a scenario would in no way limit or alter responsibilities and requirements under other law (including though not limited to HIPAA Privacy, Security, and Breach Notification Rules) that apply to the organizations that would be subject to our proposed regulations. Even if the open API access requirements proposed in section III.C. of this proposed rule were to be finalized and implemented, the organization may still be called upon to respond to individuals' request for information not available through the API, or for all of their information through means other than the API. We encourage HIPAA covered entities or business associates to review the OCR website for resources on the individual access standard at https://www.hhs.gov/​hipaa/​for-professionals/​privacy/​guidance/​access/​index.html to ensure they understand their responsibilities.

3. Specific Technical Approach and Standards

Achieving interoperability throughout the health system is essential to achieving an effective, value-conscious health system within which consumers are able to choose from an array of health plans and providers. An interoperable system should ensure that consumers can both easily access their electronic health information held by plans and routinely expect that their claims, encounter, and other relevant health history information will follow them smoothly from plan to plan and provider to provider without burdensome requirements for them or their providers to reassemble or re-document the information. Ready availability of health information can be especially helpful when an individual cannot access their usual source of care, for instance if care is needed outside their regular provider's business hours, while traveling, or in the wake of a natural disaster.

The specific proposals within this rule as described in section III.C.2. would impose new requirements on MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs (excluding issuers of SADPs) to implement standardized, transparent APIs. Using the API, these entities would be required to provide current and former enrollees with certain claims and encounter data and certain specific clinical information. These entities would also be required to make available through the API information already required to be widely available, such as provider directory and plan coverage information. In developing our proposal delineating the information that must be available through an API consistent with the proposed technical requirements, we were guided by an intent to have available through the API all of the individual's electronic health information held by the plan in electronic format that is compatible with the API or that can, through automated means, be accurately rendered compatible with representation through the API. We were also guided by an intent to make available through standardized, transparent API technology all of the provider directory and plan coverage information that is held in formats readily compatible with the API.

Both the API technology itself and the data it makes available must be standardized to support true interoperability. Therefore, we propose in section III.C.2.b. of this proposed rule to require compliance with both (1) ONC's 21st Century Cures Act proposed regulations regarding content and vocabulary standards for representing electronic health information and (2) technical standards for an API by which the electronic health information must be made available. For the proposals described in section III.C.2.b. of this proposed rule (which include purposes other than a HIPAA transaction, which is required to comply with standards adopted at 45 CFR part 162), we are proposing these requirements to comply with interoperability standards proposed for HHS adoption in ONC's 21st Century Cures Act proposed rule (published elsewhere in this issue of the Federal Register).

In proposing to require that regulated entities comply with ONC-proposed regulations (published elsewhere in this issue of the Federal Register), and therefore, use specified standards, we intend to preclude regulated entities from implementing API technology using alternative technical standards to those ONC proposes for HHS adoption at 45 CFR 170.215, including but not limited to those not widely used to exchange electronic health information in the U.S. health system. We further intend to preclude entities from using earlier versions of the technical standards adopted at 45 CFR 170.215 by requiring compliance with only specified provisions of 45 CFR part 170 and deliberately excluding others. Likewise, by proposing to require use of the content and vocabulary standards by requiring compliance with 42 CFR 423.160 and 45 CFR part 162, and proposed at 45 CFR 170.213, we intend to prohibit use of alternative technical standards that could potentially be used for these same data classes and elements, as well as earlier versions of the adopted standards named in 42 CFR 423.160, 45 CFR part 162 and proposed at 45 CFR 170.213.

While we intend to preclude regulated entities from using content and vocabulary standards other than those described in 42 CFR 423.160, 45 CFR part 162, or proposed 45 CFR 170.213 and 170.215, we recognize there may be circumstances which render the use of other content and vocabulary alternatives necessary. As discussed below, we propose to allow the use of other alternatives in two circumstances. First, where other content or vocabulary standards are expressly mandated by applicable law, we would allow for use of those other mandated standards. Second, where no appropriate content or vocabulary standard exists within 45 CFR part 162, 42 CFR 423.160, or proposed 45 CFR 170.213 and 170.215, we would allow for use of any suitable gap-filling options, as may be applicable to the specific situation.

We are using two separate rulemakings because ONC's 21st Century Cures Act proposed rule, which includes API interoperability standards proposed for HHS adoption, would have broader reach than the scope of this proposed rule. At the same time, we wish to assure stakeholders that the API standards required of MA organizations, state Medicaid agencies, state CHIP agencies, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs under this proposal would be consistent with the API standards proposed by ONC for HHS adoption because we would require that the regulated entities follow specified, applicable provisions of the ONC-proposed requirements.

Requiring that regulated entities comply with the regulations regarding standards in ONC's 21st Century Cures Act proposed rule will support greater interoperability across the health care system, as health IT products and applications that will be developed for different settings and use cases would be developed according to a consistent base of standards that supports more seamless exchange of information. We welcome public comment on the proposed required compliance with regulations regarding standards in this proposed rule to those proposed for adoption by HHS through ONC' 21st Century Cures Act proposed rule, as well as on the best method to provide support in identifying and implementing the applicable content and vocabulary standards for a given data element.

Finally, while we believe that the proposed required compliance with regulations regarding standards requirements in this proposed rule to those proposed by ONC for HHS adoption is the best approach, we seek public comment on an alternative by which CMS would separately adopt the proposed ONC standards identified throughout this proposed rule, as well as future interoperability, content and vocabulary standards. We anticipate that any such alternative would include incorporating by reference the FHIR and OAuth technical standards and the USCDI content and vocabulary standard (described in sections II.A.3.b. and II.A.3.a. of this proposed rule, respectively) in CMS regulation, and replacing references to ONC regulations at 45 CFR 170.215, 170.213, and 170.205, respectively. However, we specifically seek comment on whether this alternative would present an unacceptable risk of creating multiple regulations requiring standards or versions of standards across HHS' programs, and an assessment of the benefits or burdens of separately adopting new standards and incorporating updated versions of standards in CFR text on a program by program basis. Furthermore, we seek comment on: How such an option might impact health IT development timelines; how potentially creating multiple regulations regarding standards over time across HHS might impact system implementation; and other factors related to the technical aspect of implementing these requirements.

B. Content and Vocabulary Standards

The HHS-adopted content and vocabulary standards applicable to the data provided through the API will vary by use case and within a use case. For instance, content and vocabulary standards supporting consumer access vary according to what specific data elements MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP's in FFEs have available electronically. Where another law does not require use of a specific standard, we are proposing to require use of, in effect, a catalogue of content and vocabulary standards from which the regulated entities may choose in order to satisfy the proposed requirements in 42 CFR 422.119, 431.60, 457.730, 438.252, and 457.1233, and 45 CFR 156.221.

We propose in section III.C.2.b. of this proposed rule that the applicable entity must comply with regulations regarding certain content and vocabulary standards for data available through the API, where applicable to the data type or data element, unless an alternate standard is required by other applicable law. Specifically, we propose the applicable entity must use:

• Content and vocabulary standard ONC proposes for HHS adoption at 45 CFR 170.213 (USCDI Version 1) where such standards are the only available standards for the data type or element;
• HIPAA Administrative Simplification transaction standards under 45 CFR part 162 or the Part D e-prescribing transaction standards at 42 CFR 423.160 where required by other applicable law, or where such standards are the only available standards for the data type or element; or
• Where a specific data type or element might be encoded or formatted using either a 45 CFR part 162 or 42 CFR 423.160 standard or the USCDI Version 1 standard at 45 CFR 170.213, the applicable entity may use any of these content and vocabulary standards as determined appropriate for the data type or element. We describe these proposals in more detail below.

First, we propose in section III.C.2.b. of this proposed rule to require compliance with the ONC-proposed regulations regarding the content and vocabulary standard at 45 CFR 170.213 as applicable to the data type or data element. This is the USCDI Version 1 set of data classes that can be supported by commonly used standards, and establishes a minimum set of data classes that would be required to be interoperable nationwide.^[22] The USCDI is designed to be expanded in an iterative and predictable way over time. On behalf of HHS, ONC has proposed to adopt the USCDI as a standard in its 21st Century Cures Act proposed rule (published elsewhere in this issue of the Federal Register). The USCDI Version 1 data sets proposed by ONC for HHS adoption at 45 CFR 170.213 also includes the standards that are referenced by certification criteria that are also adopted in 45 CFR part 170, to which health IT, such as Health IT Modules presented for certification under ONC's Health IT Certification Program, must conform. Developers of applications are already familiar with and commonly using these standards in products that interact with ONC-certified health IT. The payer and purchaser communities are also aware of and commonly using the 45 CFR part 170 standards, and many members of these communities actively participate in health-data-focused standards development organizations responsible for the creation of these standards. As a result, we believe that compliance with regulations requiring these standards for CMS' programs should not add new burdens to the industry. All standards adopted within 45 CFR part 170, including the USCDI standard ONC proposes for HHS adoption at 45 CFR 170.213, are, or are proposed by ONC to be incorporated by reference by HHS, at 45 CFR 170.299 (published elsewhere in this issue of the Federal Register).

Second, we propose to require that entities use standards specified at 45 CFR part 162 for HIPAA transactions as required by applicable law, as well as the standards specified at 42 CFR 423.160 for Part D e-prescribing transactions, as required by applicable law. We reiterate that this proposed rule would not alter these other regulations, and should not be construed as altering any organization's compliance requirements for these other regulations. The standards proposed in this regulation are intended for instances where other statutes and regulations do not dictate the standard by which regulated parties are to convey or otherwise make available electronic information.

Where there is no legally mandated standard applicable to a specific data type or data element in a particular exchange context, and the HIPAA Administrative Simplification transaction standards under 45 CFR part 162 or the Part D e-prescribing transaction standards at 42 CFR 423.160 are the only standards available for a specific data element or type, we propose to require entities subject to these proposals to use these HIPAA standards when making data available through the API. We further clarify that, for purposes of formatting, making available, and sending electronic data under this proposed rule, we would require compliance with: (1) The content and vocabulary standards identified in 45 CFR part 162 regardless of whether the entities are covered entities, and (2) the Part D e-prescribing standards in 42 CFR 423.160 to exchange e-prescribing and related data (such as drug formulary and preferred drug list data) regardless of whether they are conducting a Part D e-prescribing transaction.

Third, in information exchanges where applicable law does not mandate a certain standard and where a specific data type or element might be encoded or formatted using the 45 CFR part 162 or 42 CFR 423.160 standard, or the USCDI Version 1 standard at 45 CFR 170.213, we propose in section III.C.2.b. of this proposed rule that the regulated entities subject to our proposal would have the freedom to provide data through the API that complies with any of these format or encoding standards. Specifically, we believe payers should use standards that are most efficient and effective based on their existing systems, data mapping considerations, or those standards that best meets enrollees' needs, while remaining technically practicable for use in conjunction with API technology conformant to the 45 CFR 170.215 proposed standards (published elsewhere in this issue of the Federal Register), and so long as such action is in accordance with applicable laws. For example, for data types for which 45 CFR part 162 standards are the only ones widely used throughout the payer community, and for specific content that payers typically only receive according to these HIPAA standards, we believe use of the 45 CFR part 162 content standards to represent the information is appropriate and efficient at this juncture. We note that for data made available through the API, entities subject to this proposal would be required to use the standards identified in this proposal even if the exact information to be exchanged through the API is also required to be available through other mechanisms.

Finally, we encourage payers or plans to implement additional, widely used, consensus-based standards identified by other means—such as by HHS for other purposes or through a consensus standards development organization—for additional data in their information systems for which no standard is adopted at 45 CFR part 162, 42 CFR 423.160, or 45 CFR 170.213 to the extent feasible, while maintaining compatibility with the required API technical standards. We also encourage entities to pilot emerging standards identified by HHS, or by a consensus standards development organization through development or approval for trial use, where such a pilot maintains compatibility with the proposed API technical standards. However, MA organizations, state Medicaid and CHIP agencies, Medicaid managed care plans, CHIP managed care entities, and QHPs in FFEs that choose to make non-standardized data available through their APIs would be required to ensure that their API documentation provides sufficient information to an application developer for their applications to handle this information accurately and automatically. We welcome public comment on these proposals.

C. API Standard

In section III.C.2.b. of this proposed rule, we propose to require compliance with the API technical standard proposed by ONC for HHS adoption at 45 CFR 170.215 (published elsewhere in this issue of the Federal Register). By requiring compliance with 45 CFR 170.215, we are proposing in section III.C.2.b. of this proposed rule to require use of the foundational Health Level 7 (HL7®) ^[23] Fast Healthcare Interoperability Resources (FHIR®) standard,^[24] several implementation specifications specific to FHIR, and complementary security and app registration protocols (OAuth 2.0 and OpenID Connect Core).

The FHIR standard holds great potential for supporting interoperability and enabling new entrants and competition throughout the health care industry. FHIR leverages modern computing techniques to enable users to access health care “resources” over the internet via a standardized RESTful API. Developers can create tools that interact with FHIR APIs to provide actionable data to their stakeholders. In the short time since FHIR was first created, the health care industry has rapidly embraced the standard through substantial investments in industry pilots, specification development, and the deployment of FHIR APIs supporting a variety of business needs. With the exception of the API Resource Collection in Health (ARCH) (proposed by ONC for HHS adoption at 45 CFR 170.215(a)(2)), the API technology standards and implementation specifications proposed at 45 CFR 170.215 (published elsewhere in this issue of the Federal Register) are consensus technical standards that, under the National Technology Transfer & Advancement Act of 1995 (Pub. L. 104-113, enacted March 7, 1996) and OMB Circular No. A-119, are, where available and their use not impracticable, preferred for use in government programs over both government-unique standards and standards developed using less rigorous consensus processes.

We note that while all APIs that would be used by software applications to provide consumers access to their electronic health information would be required to adhere to the foundational FHIR standard, and other essential standards such as security protocols applicable to the data exchanged, we do not anticipate that all of the standards, implementation specifications, and protocols proposed at 45 CFR 170.215 will be directly relevant to every use case reflected within the policies proposed in this rule. For example, authenticating end users' identities may not be needed where the information requested and released to an application through the API is limited to information otherwise published, such as provider directory information otherwise required by the programs' regulations to be made widely available.

We note that an API implemented by regulated entities described in section III.C. of this proposed rule is not required to be certified by ONC under the ONC Health IT Certification Program for the related certification criteria. Furthermore, because the data required to be made available by an API as proposed in section III.C. of this proposed rule includes information beyond the USCDI Version 1 data set (proposed by ONC for HHS adoption at 45 CFR 170.213), certification to the ONC certification criteria at 45 CFR 170.215 would not alone be sufficient to ensure the API's capacity to support the full range of data elements required under the proposal in section III.C. of this proposed rule.

Finally, we are aware that the implementation specifications currently proposed by ONC for HHS adoption at 45 CFR 170.215 (published elsewhere in this issue of the Federal Register), in complement to the base FHIR foundational standards, leave substantial work to be done by health IT developers and their customers to build and deploy technology to support the proposals described in section III.C.2.b. of this proposed rule. Supplemental technical resources to support efficient and successful implementation of the foundational FHIR standard can be developed by a variety of organizations. However, we recognize that there may be fewer applicable resources to support the development required under this rule. Thus, HHS expects to provide organizations subject to the policies proposed in this proposed rule with technical assistance and subregulatory guidance that incorporates feedback from industry. We recommend readers review ONC's 21st Century Cures Act proposed rule to fully understand the scope and detail of the API standard and content and vocabulary standards proposed by ONC for HHS adoption which apply to the proposals included in this proposed rule. We further recommend readers review the publicly available resources available on the HL7 FHIR standard (https://www.hl7.org/​fhir/​overview.html) and the USCDI Version 1 standard (https://www.healthit.gov/​USCDI), respectively. These publicly available materials will inform readers understanding of the requirements under this proposed rule and, we expect, will also assist stakeholders in drafting comments submitted within this rulemaking proceeding.

As noted in our proposal in section III.C.2.b. of this proposed rule, we have determined to align our proposal to the types of data, technology use, and available standards that are consistent with an overall HHS approach to support interoperability while mitigating provider and developer burden by requiring compliance with applicable HHS regulations. We hope to see continued innovation and advancement in standards development for identified gaps in health information data classes and data elements, as well as improved bi-directional patient engagement functionalities. For example, we are not proposing to require that organizations subject to the requirements proposed in section III.C. of this proposed rule offer patients or providers the ability through the API to write information directly to patient records held by the organization. However, we hope that organizations and their health IT developers build on the API technology we do propose to require and accelerate innovation responsive to providers' and patients' calls for API write functionality at the fastest pace practicable given the maturity of needed standards. We believe this innovation may be fostered by the concrete steps forward in data exchange and API capabilities we are proposing to require across the significant segment of payers subject to this proposed rule.

D. Updates to Standards

In addition to our efforts to align standards across HHS, we recognize that while we must codify in regulation a specific version of each standard, the need for continually evolving standards development has historically outpaced our ability to amend regulatory text. In order to address how standards development can outpace our rulemaking schedule, we propose in section III.C.2.b. of this proposed rule that regulated entities may use updated versions of required standards if use of the updated version is required by other applicable law.

In addition, under certain circumstances, we propose to allow use of an updated version of a standard if the standard is not prohibited under other applicable law. Where a single standard is updated more than once in a brief period of time and upon review of the standard HHS determines that—to reduce fragmentation and preserve efficacy—only the latest of the updated versions should be used. We will publish subregulatory guidance to that effect.

For content and vocabulary standards at 45 CFR part 162 or 42 CFR 423.160, we propose to allow the use of an updated version of the content or vocabulary standard adopted under this rulemaking, unless the use of the updated version of the standard is prohibited for entities regulated by that part or the program under that section, or prohibited by the Secretary for purposes of these policies or for use in ONC's Health IT Certification Program, or is precluded by other applicable law.

For the content and vocabulary standards proposed by ONC for HHS adoption at 45 CFR 170.213 (USCDI Version 1),^[25] as well as for API interoperability standards proposed by ONC for HHS adoption at 45 CFR 170.215 (including HL7 FHIR and other standards discussed above),^[26] we propose to allow the use of an updated version of a standard adopted by HHS, provided such updated version has been approved by the National Coordinator through the standards version advancement process described in ONC's 21st Century Cures Act proposed rule (published elsewhere in this issue of the Federal Register).

As described in the ONC 21st Century Cures Act proposed rule, under the proposed ONC Standards Version Advancement Process, ONC would allow health IT developers participating in the ONC Health IT certification program to voluntarily use updated versions of adopted standards in their certified Health IT Modules, so long as certain conditions are met. The proposed Standards Version Advancement Process flexibility gives health IT developers the option to avoid unnecessary costs and is expected to help reduce market confusion by enabling certified Health IT Modules to keep pace with standards advancement and market needs. Once a standard has been adopted for use in ONC's Health IT Certification Program through notice and comment rulemaking, ONC would undertake an annual, open and transparent process, including opportunity for public comment, to timely ascertain whether a more recent version of that standard or implementation specification should be approved for developers' voluntary use. ONC expects to use an expanded section of the Interoperability Standards Advisory (ISA) web platform to facilitate the public transparency and engagement process, and to publish each year's final list of National Coordinator-approved advanced versions that health IT developers could elect to use consistent with the Standards Version Advancement Process. (For more detail, please see section VIII.B.5. of ONC's 21st Century Cures Act proposed rule (published elsewhere in this issue of the Federal Register).) We believe that permitting the use of updates to standards at 45 CFR 170.213 and 170.215 consistent with the ONC Standards Version Advancement Process will enhance alignment and foster improved interoperability across the health system.

In providing flexibility to the plans and payers that will be required to implement APIs that use the content and vocabulary standards identified in this proposed rule, we also believe it is important to maintain compatibility and avoid a disruption or reduction in data availability to the end user. Entities subject to the proposed regulations seeking to use an updated version of a standard must consider factors such as the impact of differences between standards versions and the potential burden on developers and end users to support transitioning between versions. We expect that these practical considerations to maintain compatibility and avoid disruption will discourage premature use of new versions of a standard.

Therefore, we propose in section III.C.2.b. of this proposed rule that an entity may use an updated version of a required standard so long as use of the updated version does not disrupt an end user's ability to access the data available through the API proposed in section III. of this proposed rule. Entities that would be required to implement an open API under this rulemaking would be free to upgrade to newer versions of the required standards, subject only to those limiting conditions noted here, at any pace they wish. However, they must continue to support connectivity, and make the same data available, for end users using applications that have been built to support only the HHS-adopted version(s) of the API standards.

We welcome public comment on this proposed approach to allow voluntary use of updated versions of these standards.

III. Patient Access Through APIs

A. Background on Medicare Blue Button

We are committed to advancing interoperability, putting patients at the center of their health care, and ensuring they have simple and easy access, without special effort, to their health information. With the establishment of the initial Medicare Blue Button® service in 2010, Medicare beneficiaries became able to download their Part A, Part B, and Part D health care claims data through MyMedicare.gov in either PDF or text format. While the original Blue Button effort was a first step towards liberating patient health information, we recognize that significant opportunities remain to modernize access to that health information and the ability to share health information across the health ecosystem. We believe that moving to a system in which patients have access to and use of their health information will empower them to make better informed decisions about their health care. Additionally, interoperability, and the ability for health information systems and software applications to communicate, exchange, and interpret health information in a usable and readable format, is vital to improving health care. Allowing access to health information only through PDF and text format limits the utility and sharing of the health information.

Medicare Blue Button 2.0 is a new, modernized version of the original Blue Button service. It enables beneficiaries to access their Medicare Parts A, B, and D claims data and share that electronic health information through an Application Program Interface (API) with applications, services, and research programs they select. As discussed in more detail in section II.A. of this proposed rule, API technology allows software from different developers to connect with one another and exchange electronic health information in electronic formats that can be more easily compiled and leveraged by patients and their caregivers. Beneficiaries may also select third-party applications to compile and leverage their electronic health information to help them manage their health and engage in a more fully informed way in their health care.

Medicare Blue Button 2.0 is expected to foster increased competition among technology innovators who serve Medicare patients and their caregivers, such as through finding better ways to use claims data to address their health needs. Patients should have the ability to access their health information, in a format of their choosing, to receive a full picture of their health records. API technology can be an effective way to share data because health information from various sources can be retrieved through these secure interfaces and consolidated by a single tool, such as a third-party application chosen by, in the case of Medicare, the beneficiary or their caregiver.

The Medicare Blue Button 2.0 API is also expected to improve the Medicare beneficiary experience by providing beneficiaries secure access to their claims data in a standardized, computable format. We recognize that data security is of the utmost importance and are dedicated to safeguarding patient health information so that only the beneficiary and their authorized personal representative would have the ability to authorize release of their health information through Medicare Blue Button 2.0 to a third-party software application.

Medicare Blue Button 2.0 will provide beneficiaries with a longitudinal view of their Medicare claims data, which can then be combined with other health information within third party applications. One benefit of making records available via an API is that it enables a beneficiary to pull Medicare health information along with other heath information into a single application not dictated by any specific health plan, provider, or portal. APIs allow health information to move through the health ecosystem with the patient and ensure comprehensive and timely information is accessible even if the patient changes health plans, providers, or both over time, facilitating continuity of care.

B. Expanding the Availability of Health Information

1. Benefits of Information Access

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

Further, consumers who have immediate electronic access to their health information are empowered to make more informed decisions when discussing their health needs with providers, or when considering changing to a different health plan. In many cases, claims and encounter data can provide a more holistic and comprehensive view of a patient's care history than EHR data alone. Whereas EHR data is frequently locked in closed, disparate health systems, care and treatment information in the form of claims and encounter data is comprehensively combined in a patient's claims and billing history. Currently, not all beneficiaries enrolled in MA plans have immediate electronic access to their claims and encounter data and those who do have it, cannot easily share it with providers or others. The same is true of Medicaid beneficiaries and CHIP enrollees, whether enrolled in FFS or managed care programs, and enrollees in QHPs in FFEs. As industries outside of health care continue to integrate multiple sources of data to understand and predict their consumers' needs, we believe it is important to position MA organizations, Medicaid and CHIP managed care entities, and QHP issuers in FFEs to do the same to encourage competition, innovation, and value. Further, we believe that beneficiaries in Medicaid FFS programs administered by state Medicaid agencies and CHIP enrollees in both FFS and managed care should benefit from similar advances and the benefits of innovation and value.

CMS has programmatic authority over MA organizations, Medicaid programs (both FFS and managed care), CHIP (including FFS and managed care), and QHP issuers in FFEs. This proposed rule seeks to leverage that CMS authority to make claims and encounter data available to patients in these programs along with other plan data (such as provider directory data) as detailed in sections III.C. and IV. of this proposed rule. We propose that regulated entities make this data available in a standardized format and through a specific technological means so that third parties can develop and make available applications that make the data available for patient use in a convenient and timely manner. Our proposal would require compliance with specific regulations regarding interoperability standards adopted by the Secretary in implementing and complying with the proposed requirement to use an API to make this data available. We are proposing to require compliance with 45 CFR 170.215 to require the API technical standards that ONC is proposing for HHS adoption in its 21st Century Cures Act proposed rule (published elsewhere in this issue of the Federal Register). We are also proposing to require that the data elements made available through the proposed API technology must be formatted and presented in accordance with applicable content and vocabulary standards as described in section II. of this proposed rule. This means that the software receiving and using the data can readily consume the data to support consumer-friendly display and other functionalities.

Ultimately, the goal of this proposal is to require that patient data be made available in a standardized format through an API, so that third parties can develop and offer applications that make the data available in a convenient and timely manner for enrollees and beneficiaries in MA plans, Medicaid and CHIP FFS and managed care delivery systems, and FFEs that are specified in our proposal as detailed below.

2. Alignment With the HIPAA Right of Access

The HIPAA Privacy Rule, at 45 CFR 164.524, provides that individuals have a right of access to inspect and obtain a copy of PHI, defined at 45 CFR 160.103, about them that is maintained by a health plan or covered health care provider in a designated record set, defined at 45 CFR 164.501. The right of access also provides individuals with the right to initiate disclosures to third parties.

Software applications using the API proposed in 42 CFR 422.119, 431.60, 438.242(b)(6), 457.730, 457.1233(d)(2), and 45 CFR 156.221 would provide an additional mechanism through which the individuals in that coverage who so choose can exercise the HIPAA right of access to their PHI, by giving them a simple and easy electronic way to request, receive, and share data that they want and need, including with a designated third party. However, as discussed in section II of this proposed rule, due to limitations in current availability of interoperability standards for some types of data and patient's rights to be granted access in the form and manner of their own choosing, the API requirement may not be sufficient to support access to all of the health information subject to the HIPAA right of access because it may not all be transferable through the API.

C. Open API Proposal for MA, Medicaid, CHIP, and QHP Issuers in FFEs

1. Introduction

We are proposing to add new provisions at 42 CFR 422.119, 431.60, 438.242(b)(6), 457.730, 457.1233(d) and 45 CFR 156.221, that would, respectively, require MA organizations, state Medicaid FFS programs, Medicaid managed care plans, CHIP FFS programs, CHIP managed care entities, and QHP issuers in FFEs (excluding issuers of SADPs) to implement, test, and monitor an openly-published API that is accessible to third-party applications and developers. We note that states with CHIPs are not required to operate FFS systems and that some states' CHIPs are exclusively operated by managed care entities. We do not intend to require CHIPs that do not operate a FFS program to establish an API; rather, these states may rely on their contracted plans, referred to throughout this proposed rule as CHIP managed care entities, to set up such a system.

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

We are proposing that the API would be required to meet certain interoperability standards, consistent with the API technical standards proposed by ONC for HHS adoption in its proposed rule (published elsewhere in this issue of the Federal Register), as well as to require the use of content and vocabulary standards adopted by HHS and that the use of these standards would be applicable across the specific entities subject to proposed 42 CFR 422.119, 431.60, 438.242(b)(6), 457.730, and 457.1233(d), and 45 CFR 156.221. In this context, these standards are critical to ensure that enrollees of those plans and programs have electronic access to their health information in interoperable form and that access to their health information and information about their coverage are not obstructed by, or confined to, certain propriety systems.

Under our proposal, the scope and volume of the information to be provided or made accessible through the open API would include: Adjudicated claims (including cost); encounters with capitated providers; provider remittances; enrollee cost-sharing; and clinical data, including laboratory results (where available). We propose that these programs and organizations, with the exception of the QHP issuers in FFEs, would also be required to make information regarding provider directories and formularies available through the open API. Sections 1852(c), 1932(a)(5), and 2103(f)(3) of the Act require that MA organizations and Medicaid MCOs, and CHIP managed care entities provide basic information to their enrollees on how to get covered benefits in the plan and to facilitate decision making about plan choice, providers, and benefits. These statutory provisions indicate information enrollees could use to make decisions about their health care. The API proposals at 42 CFR 422.119(a), 438.242(b)(6), and 457.1233(d) support and complement existing implementation of these provisions in a robust and modern way. We believe the health information that would be available through the proposed API would greatly supplement the benefit, provider directory, and, if applicable, formulary information from states and managed care plans by providing important details and context, thus enabling enrollees to make more informed, proactive decisions.

Additionally, we believe that since most of the information required to be provided by these statutory sections of the Act, such as the provider directory, is currently accessible to enrollees and potential enrollees electronically online, making such standardized health information available through the proposed API could allow easy integration for use by more enrollees. Further, the proposal would enable these enrollees to more easily share their information with providers, family, caregivers, and others. As a general matter, providing important details and context to patients gives them more visibility into their treatment record through adjudicated claims, allowing them to be true partners in their health care. This goal is related to the disclosure requirements in sections 1852, 1932 and 2103 of the Act and our proposal furthers each.

We also believe the proposed API allows for the administration of more efficient and effective Medicaid and CHIP programs by taking advantage of commonly used methods of information sharing and data standardization. Consumers routinely perform many daily tasks on their mobile phones—banking, shopping, paying bills, scheduling—using secure applications. We believe that obtaining their health information should be just as easy, convenient, and user-friendly. Our proposal is a step toward that vision for enrollees in MA plans, Medicaid FFS and managed care programs, CHIP FFS programs and managed care entities, and QHPs in FFEs. Finally, our proposal includes a number of parameters and standards for the API and for adopting, implementing, testing, and monitoring the API; the specific pieces of our proposal are addressed in turn in sections III.C.2 of this proposed rule.

2. The Open API Proposal

This section outlines the components of the open API proposal. Specifically, this section will discuss:

• Authority to require implementation of an open API;
• The API technical standard and content and vocabulary standards;
• Data Required To Be Available Through the Open API & Timeframes for Data Availability;
• Documentation Requirements for APIs;
• Routine Testing and Monitoring of Open APIs;
• Compliance with Existing Privacy and Security Requirements;
• Denial or Discontinuation of Access to the API;
• Enrollee and Beneficiary Resources Regarding Privacy and Security;
• Exceptions or Provisions Specific to Certain Programs or Sub-Programs;
• Applicability and Timing; and
• Request for Information on Information Sharing Between Payers and Providers Through APIs.

We are proposing nearly identical language for the regulations requiring open APIs at 42 CFR 422.119; 431.60, and 457.730 and 45 CFR 156.221 for MA organizations, Medicaid state agencies, state CHIP agencies, and QHPs in FFEs; Medicaid managed care plans would be required at 42 CFR 438.242(b)(6), to comply with the requirement at 42 CFR 431.60, and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730. As discussed in detail in this proposed rule, we are proposing similar if not identical requirements for these various entities to establish and maintain an open API, make specified data available through that API, disclose API documentation, provide access to the API, and make resources available to enrollees. We believe that such nearly identical text is appropriate here as the reasons and need for the proposal and the associated requirements are the same across these programs. Except as noted below with regard to specific proposals, we intend to interpret and apply the regulations proposed in this section, III.C. of this proposed rule, similarly and starting with similar text is an important step to communicate that to the applicable entities that would be required to comply.

In paragraph (a) of each of the proposed regulations, we propose that the regulated entity (that is, the MA organization, the State Medicaid or CHIP agency, the Medicaid managed care plan, the CHIP managed care entity or the QHP in an FFE, as applicable) would be required to implement and maintain an open API that permits third-party applications to retrieve, with the approval and at the direction of the individual beneficiary, data specified in paragraph (b) of each regulation through the use of common technologies and without special effort from the beneficiary. By “common technologies and without special effort” by the enrollee, we mean use of common consumer technologies, like smart phones, home computers, laptops or tablets, to request, receive, use and approve transfer of the data that would be available through the open API technology. By “without special effort,” we codify our expectation that third-party software, as well as proprietary applications and web portals operated by the payer could be used to connect to the API and provide access to the data to the enrollee. In our proposed regulations, we address the data that must be made available through the API in paragraph (b); the regulation regarding the technical standards for the API and the data it contains in paragraph (c); the documentation requirements for the API in paragraph (d); explicit authority for the payer regulated under each regulation to deny or discontinue access to the API in paragraph (e); and requirements for posting information about resources on security and privacy for beneficiaries in paragraphs (f) or (g). Additional requirements specific to each program, discussed in sections IV. and V. of this proposed rule, are also included in some of the regulations that address the API.

We solicit comment on our use of virtually identical language in these regulations and our overall proposal to require implementation and maintenance of an open API.

a. Authority To Require Implementation of an Open API

Our proposal would apply to MA organizations, Medicaid state agencies and managed care plans, state CHIP agencies and managed care entities, and QHP issuers in FFEs. We note that our proposal for Medicaid managed care plans, at 42 CFR 438.242(b)(6), would require MCOs, PIHPs, and PAHPs to comply with the regulation that we are proposing for Medicaid state agencies at 42 CFR 431.60 as if that regulation applied to the Medicaid managed care plan. Similarly, we intend for CHIP managed care entities to comply with the requirements we propose at 42 CFR 457.730 via the regulations proposed at 42 CFR 457.1233(d)(2). We propose to structure the regulations this way to avoid ambiguity and to ensure that this API proposal would result in consistent access to information for Medicaid beneficiaries and CHIP enrollees, regardless of whether they are in a FFS delivery system administered by the state or in a managed care delivery system. CHIP currently adopts the Medicaid requirements at 42 CFR 438.242 in whole. We propose revisions to 42 CFR 457.1233(d)(1) to indicate CHIP's continued adoption of 42 CFR 438.242(a), (b)(1) through (5), (c), (d), and (e), while proposing specific text for CHIP managed care entities to comply with the regulations proposed at 42 CFR 457.1233(d)(2) in lieu of the proposed Medicaid revision, which would add 42 CFR 438.242(b)(6). In our discussion of the specifics of this proposal and how we propose to codify it at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221, we refer only generally to 42 CFR 438.242(b)(6) and 457.1233(d)(2) for this reason.

(1) Medicare Advantage

Sections 1856(b) and 1857(e) of the Act provide CMS with the authority to add standards and requirements for MA organizations that the Secretary finds necessary and appropriate and not inconsistent with Part C of the Medicare statute; section 1852(c) of the Act requires disclosure by MA organizations of specific information about the plan, covered benefits, and the network of providers; section 1852(h) of the Act requires MA organizations to provide their enrollees with timely access to medical records and health information insofar as MA organizations maintain such information. As technology evolves to allow for faster, more efficient methods of information transfer, so do expectations as to what is generally considered “timely.” Currently, consumers across public and private sectors have become increasingly accustomed to accessing a broad range of personal records, such as bank statements, credit scores, and voter registrations, immediately through electronic means and with updates received in near real time. Thus, we believe that in order to align our standards with 21st century demands, we must take steps for MA enrollees to have immediate, electronic access to their health information and plan information. The proposed requirements in this rule are intended to achieve this goal.

We believe that the scope of the information that would be made available through an API under this proposal (described in section III. of this proposed rule) is consistent with the access and disclosure requirements in section 1852 of the Act, and we rely on our authority in sections 1856(b) and 1857(e) of the Act, which provide CMS with the authority to add standards and requirements for MA organizations, to require MA organizations to make specific types of information, at minimum, accessible through an open API and require timeframes for update cycles. Throughout this section III.C. of this proposed rule, we explain how and why the open API proposal is necessary and appropriate for MA organizations and the MA program; the goals and purposes of achieving interoperability for the health care system as a whole are equally applicable to MA organizations and their enrollees; thus, the discussion in section II of this proposed rule serves to provide further explanation as to how an open API proposal is necessary and appropriate in the MA program. Further, having easy access to their claims, encounter, and other health information would also facilitate beneficiaries' ability to detect and report fraud, waste, and abuse—a critical component of an effective program.

To the extent necessary, we also rely on section 1860D-12(b)(3) of the Act to add provisions specific to the Part D benefit offered by certain MA organizations. For MA organizations that offer MA Prescription Drug plans, we are proposing requirements in 42 CFR 422.119(b)(2) regarding electronic health information for Part D coverage. That aspect of our proposal is also supported by the disclosure requirements imposed under section 1860D-4(a) of the Act, which requires Part D claims information, pharmacy directory information, and formulary information to be disclosed to enrollees.

(2) Medicaid and CHIP

We are proposing new provisions at 42 CFR 431.60(a), 457.730, 438.242(b)(6), and 457.1233(d)(2) that would require states administering Medicaid FFS or CHIP FFS, Medicaid managed care plans, and CHIP managed care entities to implement an open API that permits third-party applications authorized by the beneficiary or enrollee to retrieve certain standardized data. This proposed requirement would provide Medicaid beneficiaries' and CHIP enrollees simple and easy access to their information through common technologies, such as smartphones, tablets, or laptop computers, and without special effort on the part of the user.

For Medicaid, we are proposing these new requirements under the authority in section 1902(a)(4) of the Act, which requires that a state Medicaid plan for medical assistance provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the plan and section 1902(a)(19) of the Act, which requires that care and services be provided in a manner consistent with simplicity of administration and the best interests of the recipients. For CHIP, we propose these requirements under the authority in section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. Together these provide us with authority (in conjunction with our delegation of authority from the Secretary) to adopt requirements for Medicaid and CHIP that are necessary to ensure the provision of quality care in an efficient and cost-effective way, consistent with simplicity of administration and the best interest of the beneficiary.

We believe that requiring state Medicaid and CHIP agencies and managed care plans/entities to take steps to make Medicaid beneficiaries' and CHIP enrollees' claims, encounters, and other health information available through interoperable technology will ultimately lead to these enrollees accessing that information in a convenient, timely, and portable way, which is essential for these programs to be effectively and efficiently administered in the best interests of beneficiaries. Further, as noted in this proposed rule, there are independent statutory provisions that require the disclosure and delivery of information to Medicaid beneficiaries and CHIP enrollees; this proposal assists in the implementation of those requirements in a way that is appropriate and necessary in the 21st century. We believe making this information available in this format would result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire health care system, including Medicaid and CHIP. Having easy access to their claims, encounter, and other health information would also facilitate beneficiaries' ability to detect and report fraud, waste, and abuse—a critical component of an effective program.

As technology has advanced, we have encouraged states, health plans, and providers to adopt various forms of technology to improve the accurate and timely exchange of standardized health care information. This proposal would move Medicaid and CHIP programs in the direction of enabling better information access by Medicaid beneficiaries and CHIP enrollees, which would make them active partners in their health care through the exchange of electronic health information by easily monitoring and sharing their data. By requiring that certain information be available in and through standardized formats and technologies, our proposal moves these programs toward interoperability, which is key for data sharing and access, and ultimately, improved health outcomes. As an additional note, states will be expected to implement the CHIP provisions using CHIP administrative funding, which is limited under section 2105(a)(1)(D)(v) and 2105(c)(2)(A) of the Act to 10 percent of a State's total annual CHIP expenditures.

(3) Qualified Health Plan Issuers in Federally-Facilitated Exchanges

We propose a new QHP minimum certification standard at 45 CFR 156.221(a) that would require QHP issuers in FFEs, not including SADPs, to implement an open API that permits third-party applications, with the approval and at the direction of the individual enrollee, to retrieve standardized data concerning adjudicated claims (including cost), encounters with capitated providers, and provider remittances, enrollee cost-sharing, and clinical data, including laboratory results (where available). We are also proposing to require that the data be made available to QHP enrollees through common technologies, such as smartphones or tablets, and without special effort from enrollees.

We are proposing these new requirements under our authority in section 1311(e)(1)(B) of the Patient Protection and Affordable Care Act, as amended by the Health Care and Education Reconciliation Act of 2010 (Pub. L. 111-148, enacted March 23, 2010, and Pub. L. 111-152, enacted March 30, 2010, respectively) (collectively referred to as the Affordable Care Act), which affords the Exchanges the discretion to certify QHPs that are in the best interests of qualified individuals and qualified employers. Specifically, section 1311(e) of the Affordable Care Act authorizes Exchanges to certify QHPs that meet the QHP certification standards established by the Secretary, and if the Exchange determines that making available such health plan through such Exchange is in the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates.

We believe there are numerous benefits associated with individuals having access to their health plan data that is built upon widely used standards. The ability to easily obtain, use, and share claims, encounter, and other health data enables enrollees to more effectively and easily use the health care system. For example, by being able to easily access a comprehensive list of their adjudicated claims, the plan enrollee can ensure their providers know what services have already been received, avoid receiving duplicate services; and verify when prescriptions were filled. We believe these types of activities would result in better health outcomes and enrollee satisfaction and improve the cost effectiveness of the entire health care system. Having simple and easy access, without special effort, to their health information, including cost and payment information, also facilitates enrollees' ability to detect and report fraud, waste, and abuse—a critical component of an effective program. Existing and emerging technologies provide a path to make information and resources for health and health care management universal, integrated, equitable, accessible to all, and personally relevant. Therefore, we believe generally certifying only health plans that make enrollees' health information available to them in a convenient, timely, and portable way is in the interests of qualified individuals and qualified employers in the state or states in which an FFE operates. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange.

b. API Technical Standard and Content and Vocabulary Standards

We propose to require compliance with proposed 45 CFR 170.215 at 42 CFR 422.119(a) and (c), 431.60(a) and (c) and 457.730(a) and (c), 438.242(b)(6) and 457.1233(d)(2), and 45 CFR 156.221(a) and (c), so that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs implement open API technology conformant with the proposed API technical standards (published elsewhere in this issue of the Federal Register) (see also section II.A.3. of this proposed rule). We further propose to require compliance with the regulations regarding the following content and vocabulary standards for data available through the API, where applicable to the data type or data element, unless an alternate standard is required by other applicable law: standards adopted at 45 CFR part 162 and 42 CFR 423.160; and standards proposed by ONC for adoption by HHS at 45 CFR 170.213 (USCDI Version 1). See section II.A.3. of this proposed rule for further information about our proposals regarding how entities subject to this rule would be required to utilize these standards. We are proposing that both the API technical standard and the content and vocabulary standards would be required across the MA program, Medicaid program, and CHIP, and by QHP issuers in FFEs (not including issuers of SADPs).

Further, with the new proposed requirements to implement and maintain an API at 42 CFR 422.119(a), 431.60(a), and 457.730(a), we are proposing corresponding requirements at proposed 42 CFR 422.119(c) for MA plans, 431.60(c) for Medicaid FFS programs, and 457.730(c) for CHIP FFS programs implementing the proposed API technology. In proposed paragraphs 42 CFR 422.119(c), 431.60(c), 457.730(c), MA plans and the state Medicaid or CHIP (for CHIP agencies that operate FFS systems) agency would be required to implement API technology conformant with the standards proposed by ONC for HHS adoption at 45 CFR 170.215; for data available through the API, to use content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and proposed for adoption at 45 CFR 170.213; and to maintain and use the technology in compliance with applicable law, including but not limited to 45 CFR parts 162, 42 CFR part 2, and the HIPAA Privacy and Security Rules.

We similarly propose at 45 CFR 156.221(c) that QHP issuers in FFEs must implement API technology conformant with the API technical standards proposed by ONC for HHS adoption at 45 CFR 170.215; for data available through the API, use content and vocabulary standards adopted at 45 CFR part 162 and 42 CFR 423.160, and proposed for adoption at 45 CFR 170.213; and maintain and use the technology in compliance with applicable law, including but not limited to 45 CFR part 162, 42 CFR part 2, and the HIPAA Privacy and Security Rules.

We believe that these proposals would serve to create a health care information ecosystem that allows and encourages the health care market to tailor products and services to better serve and compete for patients, thereby increasing quality, decreasing costs, and empowering patients with information that helps them live better, healthier lives. Additionally, under these proposals, clinicians would be able to review information on their patient's current prescriptions and services received by the enrollee on the enrollee's smartphone. Also, the enrollee could allow clinicians to access such information by sharing data received through the API with the clinician's EHR system—by forwarding the information once the enrollee receives it or by authorizing release of the data through the API directly to the clinician's EHR system.

We also encourage payers to consider using the proposed API infrastructure as a means to exchange PHI for other health care purposes, such as to health care providers for treatment purposes. Sharing interoperable information directly with the enrollee's health care provider's EHR in advance of a patient visit would save time during appointments and ultimately improve the quality of care delivered to patients. Most clinicians and patients have access to the internet, providing many access points for viewing health information over secure connections. We believe that these proposed requirements would significantly improve patients' experiences by providing a mechanism through which they can access their data in a standardized, computable, and digital format in alignment with other public and private health care entities. We also believe that these proposals are designed to empower patients to have simple and easy access to their data in a usable digital format, and therefore, can empower them to decide how their health information is going to be used. However, we remind payers that this proposed regulation regarding the API would not lower or change their obligations as HIPAA covered entities to comply with regulations regarding standard transactions in 45 CFR part 162.

As discussed in section II.A.3. of this proposed rule, we recognize that while we must codify in regulation a specific version of each standard, the need for continually evolving standards development has historically outpaced our ability to amend regulations. To address how standards development can outpace our rulemaking schedule, we offer several proposals. We propose that regulated entities may use an updated version of a standard where required by other applicable law. We also propose that regulated entities may use an updated version of the standard where not prohibited by other applicable law, under certain circumstances. First, we propose to allow the use of an updated version of content or vocabulary standards adopted at 45 CFR part 162 or 42 CFR 423.160, unless the use of the updated version of the standard is prohibited for entities regulated by that part or the program under that section, is prohibited by the Secretary for purposes of these policies, is prohibited for use in ONC's Health IT Certification Program, or is prohibited by other applicable law.

Second, for the content and vocabulary standards proposed by ONC for HHS adoption at 45 CFR 170.213 (USCDI Version 1), as well as for API interoperability standards proposed by ONC for HHS adoption at 45 CFR 170.215 (including HL7 FHIR and other standards discussed above), we propose to allow the use of an updated version, provided such updated version has been approved by the National Coordinator through the Standards Version Advancement Process described in ONC's 21st Century Cures Act proposed rule (published elsewhere in this issue of the Federal Register).

Finally, we propose that use of an updated standard by a payer that is subject to these proposed regulations must not disrupt an end user's ability to access the data available through the API proposed in section III. of this proposed rule using an application that was designed to work with an API that conforms to the API standard proposed under ONC's 21st Century Cures Act proposed rule (published elsewhere in this issue of the Federal Register). Entities that would be required to implement an open API under this rulemaking would be free to upgrade to newer versions of the required standards, subject only to those limiting conditions noted here, and at any pace they wish. However, they must continue to support connectivity and make the same data available to applications that have been built to support only the adopted version(s) of the API standards. For further discussion of these proposals, see section II.A.3.D. of this proposed rule.

c. Data Required To Be Available Through the Open API & Timeframes for Data Availability

We propose the content that must be accessible for each enrollee of an entity subject to our open API proposal as set out at paragraph (b) of 42 CFR 422.119, 431.60, and 457.730 and 45 CFR 156.221; as noted previously, the regulations for Medicaid managed care plans and CHIP managed care entities cross-reference and incorporate the regulations we propose for Medicaid and CHIP programs. We note that the types of content proposed here would represent the minimum threshold for compliance; at their discretion, MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs would have the option to use the API required by this proposed rule to make additional types of health information or plan information available, exceeding these minimum requirements.

We request comment on the data proposed to be made available as detailed in the subsections below, the appropriateness of the proposed timeframes, and suggestions for alternative timeframes that consider the utility to the beneficiary, as well as challenges that the proposed timeframe may create for the entities that would have to comply.

(1) Patient Claims and Encounter Data

We propose that MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs, permit third-party applications to retrieve, with the approval of an enrollee, certain specific data: adjudicated claims data, including provider remittances and beneficiary or enrollee cost-sharing data; encounters from capitated providers; and clinical data, including laboratory results (but only if managed by the payer). Adjudicated claims data would include on approved and denied claims; under this proposal, adjudicated claims data includes that for which the plan has made an initial payment decision even when the period during which an enrollee can file an appeal is still in effect, or when the enrollee has filed an appeal and is awaiting a reconsideration decision. We specifically request comments from plans regarding the feasibility of including such claims data, including any possible timing issues. In addition, the open APIs required for these entities must make available formulary information (for MA-PD plans) or information about covered outpatient drugs and preferred drug lists (for state Medicaid and CHIP agencies, Medicaid managed care plans and CHIP managed care entities).

Our proposal includes timeframe requirements for making these various categories of data available through the open API. For MA organizations, proposed 42 CFR 422.119(b)(1)(i), (1)(ii), and (2)(i) would require open API access to all claims activity pertaining to adjudicated claims (including cost) and encounter data for benefits covered by the plan (that is, Medicare Part A and Part B items and services, Part D prescription drugs if covered by the MA plan, and any supplemental benefits) no later than one (1) business day after a claim is adjudicated or the encounter data is received by the MA organization. For clinical data, including laboratory results, MA organizations that manage such data would be required under 42 CFR 422.119(b)(1)(iv) to provide access through the open API to that data no later than one business day after it is received by the MA plan. For Medicaid state agencies and managed care plans, claims data, encounter data, and clinical data, including laboratory results (if available) would be required (specifically at 42 CFR 431.60(b)(1),(2), and (4)) through the API no later than one business day after the claim is processed or the data is received. For State Medicaid agencies in connection with the FFS program, the API would have to include all claims data concerning adjudicated claims and standardized encounter data from providers (other than MCOs, PIHPs or PAHPs) that are paid using capitated payments. The requirement for Medicaid managed care plans to provide encounter data is specified at 42 CFR 438.242(b)(6)(i); encounter data would include any data from subcontractors and providers compensated by the managed care plan on the basis of capitation payments, such as behavioral health organizations, dental management organizations, and pharmacy benefit managers. The API of Medicaid managed care plans would have to include all claims and encounter data would be included regardless if it is adjudicated or generated by the managed care plan itself, subcontractor, or provider compensated on the basis of capitation payments. All data would need to be obtained in a timely manner to comply with these proposed requirements.

For CHIP agencies and managed care entities, claims data, encounter data, and reports of lab test results (if available) would be required (specifically at 42 CFR 457.730(b)(1),(2), and (4)) through the API as soon as possible but no later than one business day. The proposal for CHIP state agencies (regarding FFS programs) and CHIP managed care entities is identical to the proposal for Medicaid State agencies (regarding FFS programs) and Medicaid managed care plans. For QHP issuers in FFEs, our proposed regulation at 45 CFR 156.221(b) would require claims, encounter, and lab data to be available within one business day of adjudication and receipt, respectively.

These proposed timeframes would ensure that data provided through the API would be the most current data available, which may be critical if the data is provided by an enrollee to his or her health care provider to use in making clinical decisions. Under our proposal, the claims and encounter data to be disclosed should include information such as enrollee identifiers, dates of service, payment information (provider remittance if applicable and available), and enrollee cost-sharing. The ability for enrollees—created and facilitated by the API required under our proposal—to access this information electronically would make it easier for them to take it with them as they move from payer to payer or among providers across the care continuum.

Regarding the provision of standardized encounter data through the API within one (1) business day of the receiving the data, we note that this proposal would mean that a payer must rely on capitated providers submitting their encounter data in a timely manner to ensure that patients receive a timely and complete set of data. To the extent providers do not submit in a timely manner, there would be a delay in patients having access to their data. We recommend that MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs that would need this information in order to meet the proposed API requirements should consider whether their contracts with network providers should include timing requirements for the submission of encounter data and claims so that the payer can comply with the API requirements. For Medicaid and CHIP FFS programs, we encourage states to consider other means to ensure that necessary encounter data from providers is also provided on a timely basis.

We note that the data for claims and remittances that would be available through the API is much of the same data that is required for the ASC X12 837, ASC X12 835, and ASC X12 863 standards which are required for certain transactions between certain entities under 45 CFR 162.1102, 162.1602 and 162.1603, as well as the Part D eRx transaction standards that use for conveying prescription and prescription-related information between Part D plans, providers, and pharmacies as specified in 42 CFR 423.160. As most claims are submitted to payers electronically utilizing these industry standard transaction types, we believe this maximizes efficiency and reduces programming burden. As noted previously, our proposed regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) and for CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same standard transaction types.

Specifically regarding QHP issuers in FFEs, in 45 CFR 156.221(b)(1)(i) and (ii), we propose to require that QHP issuers participating in an FFE make available through the API standardized data concerning adjudicated claims (including cost) and encounters with capitated providers. Under proposed paragraph (b)(1)(i), QHP issuers in FFEs would be required to make available standardized adjudicated claim, provider remittance, and enrollee cost-sharing data through the API within one (1) business day after the claim is processed. Under proposed paragraph (b)(1)(ii), QHP issuers in FFEs would be required to provide standardized encounter data through the API within one (1) business day of the issuer receiving the data.

We are also considering requiring the encounter data to be available through the API within a certain period after the encounter, within one (1) business day after the encounter data is received. We seek comment on what a reasonable period from the encounter date would be for us to consider as part of future rulemaking. In addition, we solicit comment on our authority to require MA organizations, States (for FFS Medicaid programs and CHIP), Medicaid and CHIP managed care plans, and QHPs in the FFEs to require submission of such data on a particular timeframe.

(2) Provider Directory Data

We are also proposing at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), 438.242(b)(6)(ii), 457.730(b)(3), and 457.1233(d)(2)(ii) that the required API make available provider directory data, including updates to such data. Our proposal at 45 CFR 156.221 would not require QHP issuers to permit third-party retrieval of provider directory and preferred drug list information because such information is already required to be provided by QHPs in FFEs.

For MA organizations, at proposed 42 CFR 422.119(b)(1)(iii), we propose to specify that MA organizations make specific provider directory information for their network of contracted providers accessible through their APIs: The names of providers; addresses; phone numbers; and specialty. This information is the same information MA organizations are already required to disclose to their enrollees under 42 CFR 422.111(b)(3) and make available online under 42 CFR 422.111(h)(2)(ii). MA organizations would be required to ensure the availability of this information through their APIs for all MA plans. Including this information in an open API allows non- MA third-party applications to consume, aggregate, and display plan data in different contexts, allowing patients to understand and compare plan information in a way that can best serve their individual needs. MA plans would be required to update provider directory information available through the API no later than 30 calendar days after changes to the provider directory are made. In addition, we are adding a new MA contract requirement at 42 CFR 422.504(a)(18) specifying that MA organizations must comply with the requirement for access to health data and plan information under 42 CFR 422.119.

Under proposed 42 CFR 431.60(b)(3) and 457.730(b)(3), state Medicaid and CHIP agencies respectively would be required to make provider directory information available through the API, including updated provider information no later than 30 calendar days after the state receives updated provider information. As noted previously, our proposed regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) and for CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same standard, with the addition of specific provider directory information as noted in 42 CFR 438.242(b)(6)(ii) and 457.1233(d)(2)(ii). For Medicaid managed care plans and CHIP managed care entities, the provider directory information available through the API must include all information that is specified in 42 CFR 438.10(h)(1) for disclosure to managed care enrollees. We note that we have proposed that the API be updated with new provider directory information within 30 calendar days from when the updated information is received by the State (or the managed care plan under 42 CFR 438.242(b)(6) and 457.1233(d)(2)) to be consistent with existing Medicaid managed care rules at 42 CFR 438.10(h)(3). We propose that the API implemented by the State Medicaid agency would include the data elements specified for disclosure by Medicaid state agencies in section 1902(a)(83) of the Act; we propose in 42 CFR 438.242(b)(6)(ii) that the API implemented by Medicaid managed care plans would have the data elements specified for disclosure at 42 CFR 438.10(h)(1). For CHIP agencies that operate FFS systems and CHIP managed care entities at 42 CFR 457.730(b)(3) and 457.1233(d)(2)(ii), respectively, we have also proposed 30 calendar days.

We are not proposing a similar requirement for QHP issuers in FFEs. These issuers are already required, under 45 CFR 156.230(c) and implementing guidance, to make provider directory information accessible in a machine-readable format. Because this information is already highly accessible in this format, we do not believe the benefits of making it also available through an open API outweigh the burden for QHP issuers in FFEs. However, we seek comment as to whether this same requirement should apply to QHP issuers, or if such a requirement would be overly burdensome for them.

We request comment on these proposals.

(3) Clinical Data Including Laboratory Results

Regarding the provision of clinical data, including laboratory results, we propose at 42 CFR 422.119(b)(1)(iv) that MA organizations make clinical data, such as laboratory test results available through the API if the MA organization manages such data. Because we propose in paragraph (c) that the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be used as the content and vocabulary standard for this clinical data as provided in the API, we intend our proposal to mean that the data required under paragraph (b)(1)(iv) be the same as the data that is specified in that content and vocabulary standard. In effect, we are proposing any clinical data included in the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be available through the API if such data is managed by the MA organization. We recognize that some MA organizations receive this information regularly or as a part of their contracted arrangements for health services, but that not all MA organizations do. Therefore, this proposed requirement applies to MA organizations, regardless of the type of MA plan offered by the MA organization, but only under circumstances when the MA organization receives and maintains this data as a part of its normal operations. This proposed requirement aligns with existing regulations at 42 CFR 422.118, which require MA organizations to disclose to individual enrollees any medical records or other health or enrollment information the MA organizations maintain with respect to their enrollees. We propose that this data be available in the API no later than 1 business day from its receipt by the MA organization.

Similarly, the proposed regulations for Medicaid and CHIP FFS programs and managed care plans (proposed 42 CFR 431.60(b)(4) and 457.730(b)(4)), require provision of standardized data for clinical data, including laboratory results, through the API, if available, no later than one (1) business day after a claim is adjudicated or the data is received (by the state or the managed care plan/entity). This would ensure that data provided through the API would be the most current data available, which may be critical if the data is being shared by an enrollee with a health care provider who is basing clinical decisions on the data. Like proposed 42 CFR 422.119(c), these Medicaid and CHIP regulations propose compliance with the regulations regarding the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, as the content and vocabulary standard for the clinical data available through the API; therefore, we are, in effect, proposing any clinical data included in the USCDI standard, proposed by ONC for HHS adoption at 45 CFR 170.213, be available through the API. For state agencies managing Medicaid or CHIP FFS programs, such data must be included through the API under our proposal only if the state manages clinical data. Our proposed regulation for Medicaid managed care plans at 42 CFR 438.242(b)(6) and CHIP managed care entities at 42 CFR 457.1233(d)(2) would require MCOs, PIHPs, and PAHPs to comply with the same standard in terms of the scope of information and the timing of its availability through the API; the limitation about the availability of clinical data through the API would carry through to managed care plans and entities under our proposal.

Proposed 45 CFR 156.221(b)(3) requires QHP issuers in FFEs to also make available, with the approval of the enrollee, clinical data, including laboratory results, if the QHP maintains such data.

We recognize not all of the entities subject to this requirement have uniform access to this type of data and seek comment on what barriers exist that would discourage them from obtaining, maintaining, and sharing this data. We request comment on these proposals.

(4) Drug Benefit Data, Including Pharmacy Directory, and Formulary Data

We are also proposing that drug benefit data, including pharmacy directory information and formulary or preferred drug list data, also be available through the API at proposed 42 CFR 422.119(b)(2)(ii) and (iii), 431.60(b)(5), and 457.730(b)(5). As previously discussed, Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) to comply with the requirement at 42 CFR 431.60(b)(5), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(b)(5).

We propose at 42 CFR 422.119(b)(2)(ii) and (iii) that MA organizations offering MA-PD plans make available pharmacy directory data, including the number, mix, and addresses of pharmacies in the plan network, as well as formulary data including covered Part D drugs and any tiered formulary structure or utilization management procedure which pertains to those drugs. The pharmacy directory information is the same information that MA-PD plans—like all Part D plans—must provide on their websites under 42 CFR 423.128(b)(5) and (d)(2). While prescription drug claims would have to be made available through the API no later than 1 business day of the MA-PD plan's receipt of that information, we are not proposing a specific timeframe for pharmacy directory or formulary information to be available (or updated) through the API. We intend that the requirements in 42 CFR part 423 requiring when and how information related to pharmacy directories be updated will apply to the provision of this information through the API; we solicit comment specifically whether we should address this in the regulation text or otherwise impose a time-frame for this information to be made available through the API.

At proposed 42 CFR 431.60(b)(5), for Medicaid FFS programs, and at 42 CFR 457.730(b)(5) for CHIP FFS programs, states would be required to include and update covered outpatient drug lists (including, where applicable, preferred drug lists) through the API no later than one (1) business day after the effective date of the information or any changes. We are proposing to set this timeframe at one (1) business day because we believe that it is critical for beneficiaries and prescribers to have this information as soon as the information is applicable to coverage or in near real time since this information could improve care and health outcomes. Having timely data is particularly important during urgent or emergency situations. Medicaid managed care plans and CHIP managed care entities would be required to comply with these requirements as well under proposed 42 CFR 438.242(b)(6) and 457.1233(d)(2). We also note that adjudicated claims and encounter data referenced in 42 CFR 431.60(b)(1) and (2), 438.242(b)(6), and 457.730(b)(1) and (2) include claims and encounter data for covered outpatient drugs. To the extent that a state or managed care plan utilizes a pharmacy benefit manager (PBM), we anticipate that, as a practical matter, the state or managed care plan would need to obtain the data from the PBM in a timely manner to comply with these proposed requirements.

We request comment on these proposals.

d. Documentation Requirements for APIs

We are proposing that the specific business and technical documentation necessary to interact with the proposed APIs be made freely and publicly accessible. As discussed in section II.A.1 of this proposed rule, we believe transparency about API technology is needed to ensure that any interested third-party application developer can easily obtain the information needed to develop applications technically compatible with the organization's API. Transparency is also needed so that third-parties can understand how to successfully interact with an organization's API, including by satisfying any requirements the organization may establish for verification of developers' identity and their applications' authenticity, consistent with its security risk analysis and related organizational policies and procedures to ensure it maintains an appropriate level of privacy and security protection for data on its systems.

Specifically, at 42 CFR 422.119(d), 431.60(d), 457.730(d), and 45 CFR 156.221(d), we propose virtually identical text to require publication of complete accompanying documentation regarding the API by posting this documentation directly on the applicable entity's website or via a publicly accessible hyperlink. As previously discussed, Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) to comply with the requirement at 42 CFR 431.60(d), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(d). In requiring that this documentation is “publicly accessible,” we expect that any person using commonly available technology to browse the internet could access the information without any preconditions or additional steps beyond downloading and using a third-party application to access data through the API. This is not intended to preclude use of links the user would click to review the full text of lengthy documents or access sources of additional information, such as if the technology's supplier prefers to host technical documentation at a centralized location. Rather, we mean “additional steps” to include actions such as: Collecting a fee for access to the documentation; requiring the reader to receive a copy of the material via email; or requiring the user to read promotional material or agree to receive future communications from the organization making the documentation available. We specifically solicit comments on these points.

We propose that the publicly accessible documentation would be required to include, at a minimum, the following information:

• API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns.
• The software components and configurations an application must use in order to successfully interact with the API (for example, to connect and receive data through the API) and process its response(s).
• All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.

We note that these information requirements are similar to those ONC has proposed for adoption by HHS for developers and users of health IT certified to the API criteria proposed at 45 CFR 170.315 (published elsewhere in this issue of the Federal Register), but are proposed here to apply specifically to the API technology deployed by organizations subject to the API requirements proposed in section III. of this proposed rule. We request comments on this proposal.

e. Routine Testing and Monitoring of Open APIs

At 42 CFR 422.119(c)(2), 431.60(c)(2), 457.730(c)(2), and 45 CFR 156.221(c)(2) for MA organizations, state Medicaid and CHIP FFS programs, and QHP issuers in FFEs, respectively, we are proposing that the API be routinely tested and monitored to ensure it is functioning properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as but not limited to those minimally required to comply with the HIPAA privacy and security requirements in 45 CFR part 164, 42 CFR parts 2 and 3, and other applicable law protecting privacy and security of individually identifiable health information. Medicaid managed care plans would be required by 42 CFR 438.242(b)(6) to comply with the requirement at 42 CFR 431.60(c), and CHIP managed care entities would be required by 42 CFR 457.1233(d)(2) to comply with the requirement at 42 CFR 457.730(c).

Additionally, we note that while federal laws that regulate MA organizations and MA plans supersede any state law except where noted under section 1856(b)(3) of the Act, some state, local, or tribal laws that pertain to privacy and security of individually identifiable information generally and are not specific to health insurance may also apply to MA organizations and MA plans in the context of our proposal. For the other entities regulated under our proposals in these various programs, we also intend the phrase “other applicable law” to include federal, state, tribal or local laws that apply to the entity.

We propose this requirement to establish and maintain processes to routinely test and monitor the open APIs to ensure they are functioning properly, especially with respect to their privacy and security features. Under our proposal, MA organizations, Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs would have to implement, properly maintain, update (as appropriate), and routinely test authentication features that will be used to verify the identity of individual enrollees who seek to access their claims and encounter data and other PHI through the API. Similarly, compliance with our proposed requirements would mean that these entities must implement, maintain, update (as appropriate), and routinely test authorization features to ensure an individual enrollee or their personal representative can only access claims and encounter data or other PHI that belongs to that enrollee. As is the case under existing HIPAA requirements, where an enrollee is also a properly designated personal representative of another enrollee, the HIPAA covered entity must provide for appropriate access to the information of the enrollee that has designated the personal representative, just as they would if the personal representative were an enrollee of the same plan.

Similarly, at proposed 45 CFR 156.221(c)(2), QHP issuers in FFEs would be required to routinely test and monitor their API to confirm that it is functioning properly.

We request comment on these proposals.

f. Compliance With Existing Privacy and Security Requirements

In the hands of a HIPAA covered entity or its business associate, individually identifiable patient claims, encounter data, and other health information are PHI as defined at 45 CFR 160.103. Ensuring the privacy and security of the claims, encounter, and other health information when it is transmitted through the API is of critical importance. Therefore, we remind MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs that mechanisms and practices to release PHI, including but not limited to authorization and authentication protocols and practices must provide protection sufficient to comply with HIPAA privacy and security regulations at 45 CFR part 164 and other law (whether federal, state, tribal or local) that may apply based on the specific circumstances. Under this proposal, the entities subject to these requirements would need to continuously ensure that all authorization and authentication mechanisms provide sufficient protections to enrollee PHI and that they function as intended. We specifically request public comment on whether existing privacy and security standards, including but not limited to those in 45 CFR part 164, are sufficient with respect to these proposals, or whether additional privacy and security standards should be required by CMS as part of this proposal.

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

As discussed in section II.A of this proposed rule, HIPAA covered entities must comply with patients' requests to receive their data under the HIPAA Right of Access, including having to transmit patient data to a third party. As noted in guidance from OCR, disagreement with the individual about the worthiness of the third party as a recipient of PHI, or even concerns about what the third party might do with the PHI, are not grounds for denying a request.^[27] However, a covered entity is not expected to tolerate unacceptable levels of risk to the PHI held by the covered entity in its systems, as determined by its own risk analysis.^[28] Accordingly, it may be appropriate for an organization to deny or terminate specific applications' connection to its API under certain circumstances in which the application poses an unacceptable risk to the PHI on its systems or otherwise violates the terms of use of the API technology.

At 42 CFR 422.119(e), 431.60(e), 438.242(b)(6), 457.730(e), 457.1233(d)(2) and 45 CFR 156.221(e) for MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs, we are proposing to specify the circumstances under which these regulated entities, which are all HIPAA-covered entities subject to HIPAA privacy and security requirements, may decline to establish or may terminate a third-party application's connection to the covered entity's API while remaining in compliance with our proposed requirement to offer patients access through open APIs. We intend for this proposal to be consistent with the HIPAA rules, and we note that these circumstances apply to specific applications, rather than the third party itself. For instance, were the individual to request that the HIPAA covered entity provide the individual's information through other means than through an API to the same third party that would have received it on the individual's behalf through an application which has been denied access, the covered entity would be required to approach that request as if the application's API request or connection had not occurred.

Specifically, we propose that an MA organization, state Medicaid and CHIP FFS program, Medicaid managed care plan, CHIP managed care entity, or QHP issuer in an FFE, may, in accordance with HIPAA, deny access to the API if the entity reasonably determines that allowing that application to connect or remain connected to the API would present an unacceptable level of risk to the security of PHI on the organization's systems. We further propose that this determination must be based on objective, verifiable criteria that are applied fairly and consistently across all applications through which enrollees seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.

Where we propose to require access through open APIs to otherwise publicly available information, such as provider directories, the entities subject to our proposal may also deny or terminate an application's connection to the API when it makes a similar determination about risk to its systems. However, depending on how the organization's systems are designed and configured, we recognize that the criteria and tolerable risk levels appropriate to assessing an application for connection to an API for access to publicly available information may differ from those required for API access to non-published PII.

We also anticipate that, where an application's connection has been terminated under these circumstances, it might be feasible in some instances for the organization to allow the application to re-connect to the API if and when the flaw or compromise of the application has been addressed sufficiently that the organization can no longer fairly say the application's API connection continues to pose an unacceptable risk.

We request comment on these proposals.

h. Enrollee and Beneficiary Resources Regarding Privacy and Security

As discussed in section II.A. of this proposed rule, we are committed to maximizing enrollees' access to and control over their health information. We believe this calls for providing enrollees that would access data under our proposal with essential information about the privacy and security of their information, and what to do if they believe they have been misled or deceived about an application's terms of use or privacy policy.

At 42 CFR 422.119(g), 431.60(f), and 457.730(f), and 45 CFR 156.221(g), we propose to require MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs, to make available to their current and former enrollees certain information about: Factors to consider in selecting a health information management application, practical strategies to help them safeguard the privacy and security of their data, and how to submit complaints to OCR or FTC. These proposed obligations are proposed to apply to Medicaid managed care plans and CHIP managed care entities through cross-references proposed in 42 CFR 438.242(b)(6) and 457.1233(d)(2).

The general information about the steps individuals can take to help protect the privacy and security of their health information should not be limited to, but should specifically include and emphasize the importance of understanding the privacy and security practices of any application to which they entrust their data. Information about submitting complaints should include both specific contact information for the OCR and FTC complaints processes and a brief overview, in simple and easy-to-understand language, of: What organizations are HIPAA covered entities, OCR's responsibility to oversee compliance with HIPAA, and FTC's complementary responsibility to oversee unfair and deceptive practices, including by non-covered entities that may offer direct-to-consumer health information management applications.

We propose that this information must be made available on the website of the organization subject to this proposed requirement, and through other appropriate mechanisms through which the organization ordinarily communicates with enrollees. This could include customer portals, online customer service help desks, and other locations, such as any portals through which enrollees and former enrollees might request disclosure of their data to a third-party application through the organization's API. We are also proposing that the entity must make this information available in non-technical, consumer-friendly language.

We anticipate that organizations could meet the requirement to provide information to current and former enrollees in whole or in part using materials designed for consumer audiences that are available on the HHS website (for example, content and materials such as those available at https://www.hhs.gov/​hipaa/​for-individuals/​right-to-access/​index.html) and FTC website (for example, content and materials such as those available at https://www.consumer.ftc.gov/​topics/​online-security). However, we note that whether the organization chooses to draft its own resource materials to provide the required information or to rely on governmental or other sources for such materials, the organization will be responsible for ensuring that the content of the materials remains current as relevant law and policy may evolve over time. We seek comment on this proposal, and we invite additional comments on what specific information resources in addition to those already available on the websites noted above would be most useful to entities in meeting this requirement. We anticipate using this feedback to help inform HHS planning and prioritization of informational resource development work in addition to making a decision on the final rule regarding this proposal.

i. Exceptions or Provisions Specific to Certain Programs or Sub-Programs

We are proposing certain exceptions or specific additional provisions as part of this proposed rule for certain QHPs in FFEs and certain types of MA plans, respectively. Under sections 1856, 1857, and 1860D-12(b)(3) of the Act, we proposed at 42 CFR 422.119(b)(2) to include additional requirements that would apply specifically to MA organizations that offer Medicare Advantage-Prescription Drug (MA-PD) plans. The organizations offering these MA-PD plans must comply with MA requirements in 42 CFR part 422 for Part A, Part B and non-drug supplemental benefits; they must comply with Part D requirements in 42 CFR part 423 for the Part D prescription drug benefit. These additional requirements would ensure that enrollees of MA-PD plans can easily access the information they need in order to adhere to their care plans. Including this information in an open API allows non- MA third-party applications to properly use, aggregate, and display plan data in different contexts, enabling another means of accessing information for patients and more options for comparing and understanding plan information in a way that can best serve their individual needs.

Specifically, at 42 CFR 422.119 (b)(2)(i), we propose to require MA organizations make standardized data concerning adjudicated Part D claims, including remittances and enrollee cost-sharing, available through the API to enrollees covered under a MA-PD plan. We propose to require that this information be made available no later than one (1) business day after a claim is adjudicated. This would ensure that data provided through the API would be the most current data available, which may be critical if the data is being used by a provider who is basing clinical decisions on the data. To the extent that an MA organization offering MA-PD plans utilizes a PBM, the MA organization would be required to obtain the data from the PBM in order to comply with these requirements.

Related to QHP issuers, we propose two exceptions to this proposed rule. First, we propose that the requirements proposed in 45 CFR 156.221(a) not apply to issuers of SADPs in the FFEs. In contrast to QHP issuers of medical plans, issuers of SADPs offer enrollees access to a unique and specialized form of medical care. We believe the proposed standards and health IT investment would be overly burdensome for SADP issuers as related to their current enrollment and premium intake and could result in SADP issuers no longer participating in FFEs, which would not be in the best interest of enrollees. Additionally, we believe much of the benefit to enrollees from requiring issuers of QHPs to make patient data more easily available through a standard format depends upon deployment of open API technology that conforms to standards proposed by ONC for HHS adoption at 45 CFR 170.215 (published elsewhere in this issue of the Federal Register) and a corresponding energetic response by the developer community in developing innovative, useful, usable, and affordable consumer-facing applications through which plan enrollees can conveniently access, use, and share their information as they choose. Through our proposals in this section to require implementation of open API technology in the Medicare, Medicaid and CHIP programs, as well as by QHP issuers in FFEs, we would anticipate significantly expanding the implementation of open APIs by medical plans. However, we do not anticipate similar widespread usage with respect to SADPs. Therefore, we believe that the utility of access to issuers' data is less applicable to dental coverage, and do not believe it would be in the interest of qualified individuals and qualified employers in the state in which an FFE operates to not certify SADPs because they do not provide patient access to their data through an openly-published API. We seek comment on whether we should apply this policy to SADP issuers in the future.

We also propose to provide an exceptions process through which an FFE may certify health plans that do not provide patient access through an openly-published API, but otherwise meet the requirements for QHP certification. We propose in 45 CFR 156.221(h)(1) that if a plan applying for QHP certification to be offered through an FFE does not provide patient access to their data through an open API, the issuer must include as part of its QHP application a narrative justification outlining the reasons why the plan cannot reasonably satisfy the requirements in proposed 45 CFR 156.221(a),(b), or (c), the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and proposed solutions and timeline to achieve API compliance. In 45 CFR 156.221(h)(2), we propose that an FFE may grant an exception to the requirement to provide enrollees access to data through open API technology if the FFE determines that making available such health plan is in the interest of qualified individuals and qualified employers in the state in which the FFE operates. We anticipate that this exception would be provided in limited situations. For example, we would consider providing an exception for small issuers, issuers who are only in the individual or small group market, financially vulnerable issuers, or new entrants to the market who demonstrate that deploying open API technology consistent with the required interoperability standards would pose a significant barrier to the issuer's ability to provide coverage to consumers, and not certifying the issuer's QHP or QHPs would result in consumers having few or no plan options in certain areas. We seek comment on other circumstances in which the FFE should consider providing an exception.

j. Applicability and Timing

At 42 CFR 422.119(h) and 45 CFR 156.221(i), we are proposing specific provisions regarding applicability and timing for MA organizations and QHP issuers in FFEs that would be subject to our proposal. We are not proposing specific regulation text for 42 CFR 431.60 or 438.242 because we intend to make the regulation text effective on the applicable date discussed below. We expect that state Medicaid and CHIP agencies will be aware of upcoming new regulations and planning for compliance with them when they are effective and applicable, even if the new regulation is not yet codified in the CFR; we similarly expect that such agencies will ensure that their managed care plans/entities will be prepared for compliance. Unlike Medicaid state agencies and managed care plans and state CHIP agencies and managed care entities, MA organizations and QHP issuers in FFEs generally are subject to rules regarding bid and application submissions to CMS in advance of the coverage period; for example, MA organizations must submit bids to CMS by the first Monday in June of the year before coverage starts in order to be awarded an MA contract. In order to ensure that these requirements for MA organizations and QHP issuers in FFEs are enforceable and reflected in the bids and applications these entities submit to us in advance of when the actual requirements must be met, we propose to codify the actual compliance and applicability dates of these requirements. We solicit comment on this approach.

For MA organizations, under 42 CFR 422.119(h), we are proposing that the requirements would be effective beginning January 1, 2020. Under this proposal, the requirements we propose for 42 CFR 422.119 would be applicable for all MA organizations with contracts to offer any MA plan on that date and thereafter. We request feedback about this proposed timing from the industry. In particular, we are interested in information and request comment from MA organizations about their current capability to implement an API consistent with this proposal and the costs associated with compliance by January 1, 2020, versus compliance by a future date.

For Medicaid FFS at 42 CFR 431.60, CHIP agencies that operate FFS systems at 42 CFR 457.730, Medicaid managed care plans at 42 CFR 438.242(b)(6), and CHIP managed care entities at 42 CFR 457.1233(d)(2), we are proposing that the API requirements would be effective beginning July 1, 2020, regardless of when the managed care contract started. Given the expected date of publication of this proposed rule and potential final rule, we believe July 1, 2020, would provide state Medicaid agencies and CHIP agencies that operate FFS systems, Medicaid managed care plans, and CHIP managed care entities sufficient time to implement. We solicit comment on this proposal and whether additional flexibility would be necessary to take into account the contract terms that states use for their Medicaid managed care plans.

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

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

We believe that these proposals would help to create a health care information ecosystem that allows and encourages the health care market to tailor products and services to compete for patients, thereby increasing quality, decreasing costs, and helping them live better, healthier lives. Additionally, under these proposals, physicians would be able to access information on their patient's current prescriptions and services by reviewing the information with the patient on the patient's personal device or by the patient sharing data with the provider's EHR system, which would save time during appointments and ultimately improve the quality of care delivered to beneficiaries. Most health care professionals and consumers have widespread access to the internet, providing many access points for viewing health care data over secure connections. We believe that these proposed requirements would significantly improve beneficiaries' experiences by providing a secure mechanism through which they can access their data in a standardized, computable format.

These proposals are designed to empower patients by making sure that they have access to health information about themselves in a usable digital format and can make decisions about how, with whom, and for what uses they will share it. By making claims data readily available and portable to the enrollee, these initiatives support efforts to move our health care system away from a FFS payment system that pays for volume and toward a payment system that pays for value and quality by reducing duplication of services, adding efficiency to patient visits to providers; and, facilitating identification of fraud, waste, and abuse. Data interoperability is critical to the success of new payment models and approaches that incentivize high quality, efficient care. All of the health care providers for a patient need to coordinate their care for a value-based system to work, and that requires information to be securely shareable in standardized, computable formats. Moreover, patients need to understand and be actively involved in their care under a value-based framework. We are committed to supporting requirements that focus on these goals, and we believe that these specific proposals in this proposed rule support these efforts.

k. Request for Information on Information Sharing Between Payers and Providers Through APIs

This proposed rule requires the implementation of open APIs for making accessible data that a third-party could use to create applications for patients to access data in order to coordinate and better participate in their medical treatment. While in some instances, direct provider to health plan transmission of health information may be more appropriate than sharing data through an open API, in other instances a patient may wish to send a provider a copy of their health information via another health care provider's API. In such cases, patients could direct the payer to transmit the health information to a third party application (for example, an application offered by a health care provider to obtain patient claims and encounter data, as well as lab test results (if applicable) on a one-off and as-needed basis. To the extent a HIPAA covered entity uses a third party application to offer patients access to their records, another HIPAA covered entity may be able to obtain an individual's health information from the app for treatment, payment, or certain health care operations, if it could do so in accordance with HIPAA without need of an individual's authorization. (See 45 CFR 164.506.) Under other laws, providers may need to obtain specific individual consent to obtain health information related to care provided by a behavioral health provider, treatment received at a substance use disorder treatment facility, certain 42 CFR part 2-covered diagnoses or other claims-related information, or labs that suggest a part 2 diagnosis. We do not intend to expand any scope of authority to access patient data nor to contravene existing requirements related to disclosure of PHI under the HIPAA Rules and other legal standards, but instead specify a new and additional mechanism by which to share health information as directed by the individual, through the use of API technology in compliance with all existing federal, state, local, and tribal privacy and security laws.

In the future, we anticipate payers and providers may seek to coordinate care and share information in such a way as to request data on providers' or a plan's patient/insured overlapping population(s) in one transaction. Effective care coordination between plans and providers can inform health care providers about where their patients are receiving care to better understand the totality of their healthcare needs and manage their care. We have heard that being aware of urgent care or emergency department visits allows clinicians to arrange appropriate follow-up, modify treatments, and update records if services are provided (for example, tetanus boosters given with a laceration treated in urgent care). The accompanying proposals in Section X. of this proposed rule, to amend the conditions of participation regarding notification of patient discharge, further support the ability of clinicians to arrange and affirm such appropriate follow-up care. Having a complete record of tests done at specialists' offices can reduce duplicate testing. Having a complete list of clinicians caring for a patient facilitates appropriate notification if treatments are changed or procedures are planned that may impact the other clinicians' treatment plan. We have heard from participants in our accountable care programs and models that organizations taking risk for their patient populations need to have a complete picture of the patients' needs to better budget for appropriate resources. This may be particularly relevant during disasters or public health emergencies when patients are not able to access their normal sources of care and/or health care facilities are overwhelmed due to patient surge.

We believe there are a variety of transmission solutions that may be employed to share data regarding a provider's and plan's overlapping patient populations. For instance, some geographic areas might have regional health information exchanges that could coordinate such transmissions. Elsewhere, direct provider-to-provider and plan-to-plan exchange might be more appropriate. Plans could participate in direct exchange through existing trusted networks, or beneficiary-facing third party applications could meet this potential future requirement.

We seek comment for possible consideration in future rulemaking on the feasibility of providers being able to request a download on a shared patient population, and whether such a process could leverage the APIs described in sections II.A.3. and III.C. of this proposed rule. We seek comment on requirements for patient notice and consent, and applicable legal and regulatory requirements, and whether or how this data transfer could be cumulative over time and between various providers. We seek input on the utility to providers of obtaining all of their patients' utilization history in a timely and comprehensive fashion. We also seek input on potential unintended consequences that could result from allowing a provider to access or download information about a shared patient population from payers through an open API. Finally, we seek comment on the associated burden on plans to exchange this data, as well as the identification other potential statutory or regulatory barriers to exchanging this data.

IV. API Access to Published Provider Directory Data

A. Interoperability Background and Use Cases

The proposals described in section III of this proposed rule primarily focus on patient access to their data through a standardized, transparent API; however, we have also proposed that entities subject to these proposals make available certain plan-level data through the API. In this section, we provide additional context for the proposal related to making provider directory information available through the API, including ways in which this proposal may differ from our other proposals related to accessibility of patient data.

Provider directories make key information about health care professionals and organizations available to help consumers identify a provider when they enroll in an insurance plan or as new health needs arise. For example, such information might include hours of operation, languages spoken, specialty/services, availability for new patients. Provider directories also function as a resource used by the provider community to discover contact information of other providers to facilitate referrals, transitions of care, and care coordination for enrollees.

The current applicable regulations for MA plans (42 CFR 422.111) and Medicaid and CHIP managed care plans (42 CFR 438.10(e)(2)(vi) and (h) and 457.1207, respectively) require that provider directories be made available to enrollees and potential enrollees in hard copy and on the plan's website. Section 1902(a)(83) of the Act requires state Medicaid agencies to publish a directory of certain physicians on the public website of the State agency. A regulation for QHPs in FFEs (45 CFR 156.230(b)) requires public access to the QHP's provider directory in addition to distribution and access for enrollees. In addition to directing that this information be accessible, the current regulations also address the content of such directories and the format and manner in which MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs make the information available.

Making this required provider directory information available to enrollees and prospective enrollees through an API could support development of applications (whether standalone or integrated with providers' EHR technology) that would pull in current information about available providers to meet enrollees' current needs. For instance, as part of a referral lookup use case, API access to a provider directory could allow for a referring provider's health IT to enable either the enrollee or the provider to easily identify up-to-date contact information obtained from the directory through an API, and securely send the receiving health care provider the patient information needed to provide safe, high-quality care sensitive to the patient's preferences. Broad availability of provider directory data through interoperable API technology would also allow for innovation in applications or other services that help enrollees and prospective enrollees to more easily compare provider networks while they are considering their options for changing health plans. Finally, a consistent, FHIR-based API-driven approach to making provider directory data accessible could reduce provider burden by enabling payers/plans to share more widely basic information about the providers in their networks, such as provider type, specialty, contact information, and whether or not they are accepting new patients.

B. Broad API Access to Provider Directory Data

In sections II.A.3. and III.C. of this proposed rule, we propose to require MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities to make standardized information about their provider networks available through API technology, so that third party software could access and publish that information. Such availability would be for current enrollees, prospective enrollees and possibly the general public to the extent existing regulations require that information to be disclosed beyond current enrollees. We propose to require that the API technology conform to the API standards proposed by ONC for HHS adoption at 45 CFR 170.215 (published elsewhere in this issue of the Federal Register). At this time, because QHP issuers in FFEs are already required to make provider directory information available in a specified, machine-readable format,^[29] we do not propose these as requirements for QHP issuers. However, we seek comment as to whether this same requirement should apply to QHP issuers, or if such a requirement would be overly burdensome for them.

We note that, since the provider directory information we are proposing to require be available through the API is already available and accessible to enrollees without cost to them, this information should be as accessible through the API as it is required to be when posted on the organization's websites. Therefore, the security protocols proposed at 45 CFR 170.215 that are specific to authenticating users and confirming individuals' authorization or request to disclose their personal information to a specific application would not apply to public access to provider directory information through APIs. While we are aware the organization will nevertheless need to take appropriate steps to mitigate the potential security risks of allowing any application to connect to the API through which it offers provider directory access, we emphasize that these steps should be appropriate to the level of risk associated with the specific use case of accessing otherwise public information through API technology. Those wishing to access this data should not be unduly burdened by security protocols that are not necessary to provide the appropriate degree of protection for the organization's systems and data.

As referenced in sections II. and III. of this proposed rule, we intend to develop additional guidance, incorporating feedback from industry that provides implementation best practices relevant to FHIR-conformant open APIs to help organizations subject to the requirements proposed in this rulemaking. To that end, we solicit comment on what specific resources would be most helpful to organizations implementing APIs under requirements proposed in this proposed rule.

V. Health Information Exchange and Care Coordination Across Payers: Establishing a Coordination of Care Transaction To Communicate Between Plans

We are proposing a new requirement for Medicare Advantage (MA) plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs to require these plans to maintain a process to coordinate care between plans by exchanging, at a minimum, the USCDI at enrollee request at the specific times specified in the proposed regulation text. Understanding that this information could already be available for exchange between plans, this proposal is specifically requiring this information sharing not only occur when initiated by an enrollee request, but that the information requested, in the form of the USCDI data set, would then be incorporated into the recipient plan's systems. The USCDI (Version 1) data set would have to be sent to another plan that covers the enrollee or a recipient identified by the enrollee at any time during coverage or up to 5 years after coverage ends, and the plan would have to receive the USCDI (version 1) data set from any health plan that covered the enrollee within the preceding 5 years. Under our proposal we are supporting patient directed coordination of care and each of the plans subject to the requirement would, upon an enrollee's request: (1) Accept the data set from another plan that had covered the enrollee within the previous 5 years; (2) send the data set at any time during an enrollee's enrollment and up to 5 years later, to another plan that currently covers the enrollee; and (3) send the data set at any time during enrollment or up to 5 years after enrollment has ended to a recipient identified by the enrollee.

As we discussed in section III.C.2. of this proposed rule, this proposal is based on our authority under sections 1856(b) and 1857(e) of the Act to adopt standards and contract terms for MA plans; section 1902(a)(4) of the Act to adopt methods of administration for state Medicaid plans, including requirements for Medicaid managed care plans (MCOs, PIHPs, and PAHPs); section 2101(a) of the Act for CHIP managed care entities (MCOs, PIHPs, and PAHPs); and section 1311(e)(1)(B) of the ACA for QHP issuers in an FFE (not including SADP issuers). We believe that our proposal will help to reduce provider burden and improve patient access to their health information through coordination of care between health plans. We also note that the CHIP regulations incorporate and apply, through an existing cross-reference at 42 CFR 457.1216, the Medicaid managed care plan requirements codified at 42 CFR 438.62(b)(1)(vi). Therefore, the proposal for Medicaid managed care plans described above will also apply to CHIP managed care entities without new regulation text in part 457. We are proposing that this new requirement would be effective starting January 1, 2020 for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs. Among other topics related to this proposal, we solicit comments on this proposed effective date.

We propose to codify this new requirement at 42 CFR 422.119(f)(1) for MA organizations; at 42 CFR 438.62(b)(1)(vi) for Medicaid managed care plans (and by extension under existing rules in part 457, to CHIP managed care entities); and at 45 CFR 156.221(c) for QHPs in FFEs. This proposed new requirement is virtually identical for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs, with modifications in the proposal necessary for specific plans types to account for the program needs of the MA program, Medicaid and CHIP managed care programs, and QHP program. Our proposed regulation text references the content standard adopted at 45 CFR 170.213, which ONC is proposing as the USCDI Version 1 data set (published elsewhere in this issue of the Federal Register). We believe that exchanging this minimum data would help both plan enrollees and health care providers coordinate care and reduce administrative burden to ensure that plans provide coordinated high-quality care in an efficient and cost-effective way that protects program integrity.

Leveraging interoperability to facilitate care coordination among plans can, with thoughtful execution, significantly reduce unnecessary care, as well as ensure that health care providers are able to spend their time providing care rather than performing unnecessary administrative tasks. We believe that use of the USCDI to exchange information furthers care coordination. For instance, effective information exchange between plans could improve care coordination by reducing the need for health care providers to write unneeded letters of medical necessity; by reducing instances of inappropriate step therapy; and by reducing repeated utilization reviews, risk screenings, and assessments. It can also streamline prior authorization processes and reduce instances where an enrollee's health care provider needs to intervene personally with the enrollee's MA plan, Medicaid managed care plan, CHIP managed care entity, or QHP in the FFE to ensure his or her patient received the necessary treatment. This addresses concerns stakeholders have previously raised with CMS and ONC regarding such administrative burdens, as the USCDI standard contains many of the data points required to more effectively coordinate care.

In addition to the benefits for care coordination at the plan level and reduced provider burden, we note that once the combined health information, specified by the USCDI standard, from a prior plan is available to the patient's current plan, the enrollee would also have access to multiple years of their health information through the proposed patient access API discussed in section III of this proposed rule. The USCDI (Version 1) data set includes laboratory results and tests, medications, health concerns, assessment and plan of treatment, care teams, clinical notes, and other data points essential for care coordination. This would provide the patient with a more comprehensive history of their medical care, helping them to make better informed health care decisions. We seek comments on how plans might combine records and address error reconciliation or other factors in establishing a more longitudinal record for each patient.

We propose to allow multiple methods for electronic exchange of the information, including use of the APIs proposed in section III. of this proposed rule, to allow for patient-mediated exchange of payer information or direct payer-to-payer communication, subject to HIPAA requirements, 42 CFR part 2, and other applicable laws. We considered requiring the use of the FHIR-based API discussed in section III. of this proposed rule for the information exchange; however, we understand that some geographic areas might have a regional health information exchange that could coordinate such transitions for the MA plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs that are subject to this proposal. We seek comment on whether it would be beneficial to interoperability and patient care coordination for us to require the use of the FHIR-based API discussed in section III. of this proposed rule, and whether this should be the only mechanism allowed for this exchange, or whether multiple methods for electronic exchange of the information should be allowed under this proposed policy.

We also propose that a patient should be able to request his or her information from their prior plan up to 5 years after dis-enrollment, which is considerably less than existing data retention policies for some of the plans.^[30] Further, if a plan has access to multiple years of health information for a patient, either due to the fact that the patient has been enrolled with the plan for multiple years, or because the enrollee has requested transfer of the health information from prior plans which previously covered the enrollee, we propose that the health information would be incorporated into the IT and data systems of each plan that receives the USCDI data set under this proposed requirement, such that the enrollee's data would be cumulative and move with the enrollee as he or she changes enrollment. For example, if a patient is enrolled in Plan 1 in 2020 and Plan 2 in 2021, then requests the data from Plan 1 to be sent to Plan 2, Plan 2 would have at least 2 years (2020 and 2021) of health information for that patient. If the patient moves to Plan 3 in 2022, Plan 3 should receive both 2020 and 2021 data from Plan 2 at the patient's request. While our proposal is to require compliance (and thus exchange of these data sets) only by MA plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs, we hope that compliance by these plans could be the first step toward adoption and implementation of these standards on a voluntary basis by other health plans and health issuers throughout the health care system.

Research indicates that the completeness of a patient record and the availability of up-to-date and relevant health information at the point of care can have a significant impact on patient outcomes.^[31] Our proposal here for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs to exchange a minimum data set in particular scenarios would support improvement in care coordination by allowing for sharing of key patient health information when an enrollee requests it. The USCDI (Version 1) data set would have to be sent to another plan that covers the enrollee or a recipient identified by the enrollee at any time during coverage or up to 5 years after coverage ends and the plan would have to receive the USCDI (version 1) data set from any health plan that covered the enrollee within the preceding 5 years.

We propose that the plans subject to this new requirement would be required to exchange, at a minimum, the USCDI Version 1 data set. On behalf of HHS, ONC has proposed to adopt the USCDI as a standard (published elsewhere in this issue of the Federal Register), to be codified at 45 CFR 170.213, and our proposed regulation text cross-references this regulation. These data exchanges would provide the enrollee's new plan with a core set of data that can be used to support better care coordination and improved outcomes for the enrollee. We considered requiring plans to exchange all the data that we proposed be available through an API (see section III. of this proposed rule) but we understand that ingesting data and reconciling errors has challenges and proposed this more limited data set to address those concerns. We are seeking comment on whether the USCDI data set is comprehensive enough to facilitate the type of care coordination and patient access described in this proposal, or whether additional data fields and data elements that would be available under our API proposal in section III of this proposed rule, should also be required.

Many key attributes of the USCDI make it suitable for the purpose outlined in our proposal. The USCDI includes data classes that can be supported by commonly used standards, including the Health Level Seven (HL7®) Consolidated Clinical Data Architecture (C-CDA) Version 2.1 and the Fast Healthcare Interoperability Resources (FHIR®) standards for essential patient health information like vital signs, lab results, medications and medication allergies. The USCDI establishes a minimum set of data elements that would be required to be interoperable nationwide and is designed to be expanded in an iterative and predictable way over time. The USCDI, at a minimum, transferred for each enrollee moving among the plans subject to our proposal would greatly improve each plan's coordination of care efforts and spotlight areas of urgent need. Having this information would allow the new MA plan, Medicaid managed care plan, CHIP managed care entity or a QHP in the FFE to evaluate and review an enrollee's utilization history in a timely and comprehensive fashion and thus assist each enrollee to transition to the new plan with minimal disruption to care. By being able to perform timely outreach to enrollees based on past and current utilization, these plans could take steps to prevent unnecessary emergency room visits and lapses in medication and ongoing care; further, they could proactively address any network deficiencies that may impact the enrollee. We believe that having an enrollee's utilization history in a timely and comprehensive fashion would facilitate outreach and coordination efforts in ways heretofore unavailable on a broad basis. In all, this ability would mean that these plans could help new enrollees transition to new coverage rules and a new network with minimal disruptions to care.

While our proposal is to require, at a minimum, exchange of the USCDI Version 1 data set, we reiterate that we do not propose to specify the means of exchanging this data at this time. While we anticipate that plans may opt to use APIs (such as those described in section III of this proposed rule) as the means to exchange this data, we intend to not be overly prescriptive as to how USCDI data set information for applicable enrollees is exchanged as we expect there are a variety of transmission solutions that may be employed. For instance, some geographic areas might have a regional health information exchange that could coordinate such transitions for the MA plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs that are subject to this proposal. Elsewhere, direct plan-to-plan exchange might be more appropriate, or beneficiary-facing third party applications could be used by MA plans, Medicaid managed care plans, CHIP managed care entities, and QHPs in the FFEs to meet this proposed requirement. We also expect there may be instances where these plans may leverage their connections to Health Information Exchanges to engage in the information exchanges necessary to comply with this proposed rule. We expect enrolled beneficiaries to have constant access to requesting an exchange of data as our proposal would require exchange of the USCDI data set whenever an enrollee makes such a request, which may occur at times other than enrollment or disenrollment. We request comments on other means that the applicable plans may prefer to use for meeting this requirement and whether CMS might be able to leverage its program authority to facilitate the data exchanges contemplated by this proposal. We acknowledge that in some cases plans subject to this proposed requirement may be exchanging patient health information with other plans that are not similarly required to exchange USCDI data sets for enrollees, and we request comment on how to support patients and providers in those situations.

We believe that this proposed requirement would also support dual eligible individuals who are concurrently enrolled in MA plans and Medicaid managed care plans. Under our proposal, both of the dual eligible individual's plans would be subject to the requirement to exchange that individual's data in the USCDI Version 1, which should improve the ability of both plans to coordinate care based on that data. For example, when an enrollee is initially eligible for only one program (that is, only for Medicare and enrolled in a MA plan, or only for Medicaid and enrolled in a Medicaid MCO) and then becomes dually eligible for a second program, the sharing of data between the existing plan and the new plan reduces the burden on the new plan, on the enrollee, and on health care providers in the new plan regarding collecting information about prior utilization or health information. Rather than completing a lengthy health assessment, the enrollee in this example would benefit from having similar (or possibly the same) information transferred directly between the MA plan and the Medicaid managed care plan under our proposal. We seek comment on how plans should coordinate care and exchange information in those situations. We also seek comment on the associated burden on plans to exchange the USCDI data set under our proposal. In addition, we are interested in comments about potential legal barriers to exchanging the USCDI data set as would be required under our proposal; for example, are there federal, state, local and tribal laws governing privacy for specific use cases (such as in the care of minors or for certain behavioral health treatments) that raise additional considerations we should address in this regulation or guidance.

We believe that activities related to this proposal may qualify as a quality improvement activity (QIA) meeting the criteria described in section 2718(a)(2) of the PHSA for purposes of the Medical Loss Ratio (MLR) requirements for QHP issuers in an FFE (excluding SADP issuers),^[32] and similar standards for treatment of quality improvement standards applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP managed care entities under 42 CFR 457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490. We request comments related to this assumption and its implications.

VI. Care Coordination Through Trusted Exchange Networks: Trust Exchange Network Requirements for MA Plans, Medicaid Managed Care Plans, CHIP Managed Care Entities, and QHPs in the FFEs

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

The importance of a trusted exchange framework to such interoperability is reflected in section 4003(b) of the Cures Act, as discussed in more detail in section I.D. of this proposed rule. A trusted exchange framework allows for the secure exchange of electronic health information with, and use of electronic health information from, other health IT without special effort on the part of the user. Widespread payer participation in such a framework might allow for more complete access and exchange of all electronically accessible health information for authorized use under applicable state or federal law, which we believe would lead to better use of such data. While we cannot require widespread payer participation in trust networks, we are proposing here to use our program authority in the MA program, Medicaid managed care program, CHIP managed care program, and QHP certification program for the FFEs to increase participation in trust networks and to bring the benefits of such participation to those programs.

We are proposing to require, effective beginning January 1, 2020, that MA plans, Medicaid managed care plans, CHIP managed care entities and QHPs in the FFEs (excluding not stand alone SADPs) participate in a trusted exchange network. This proposal is based on our authority under: Sections 1856(b) and 1857(e) of the Act to adopt standards and contract terms for MA plans; section 1902(a)(4) of the Act to adopt methods of administration for the administration state Medicaid plans, including requirements for Medicaid Managed Care Plans (MCOs, PIHPs, and PAHPs); section 2101(a) for CHIP managed care entities (MCOs, PIHPs, and PAHPS); and section 3001(c)(9)(F)(iii) of the Public Health Service Act and section 1311(e)(1)(B) of the Affordable Care Act for QHP issuers in an FFE. Under our proposal, participation would be required in a trusted exchange framework that meets the following criteria:

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

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

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

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

On January 5, 2018, ONC released the draft Trusted Exchange Framework for public comment. Commenters to the draft framework, particularly payers providing comments, requested that existing trust networks operating successfully be leveraged in further advancing interoperability; thus, we are considering proposing in the future an approach to payer to payer and payer to provider interoperability that leverages existing trust networks to support care coordination and improve patient access to their data. We request comments on this approach and how it might be aligned in the future with section 4003(b) of the Cures Act. We also request comments on the effective date we have proposed for this requirement and what benefits and challenges the plans (MA organization, Medicare managed care plans, CHIP managed care entities and QHPs in the FFE) may face meeting this requirement for additional consideration in future rulemaking.

We believe that activities related to this proposal may qualify as a QIA meeting the criteria described in section 2718(a)(2) of the PHSA for purposes of the MLR requirements for QHP issuers in an FFE (excluding SADP issuers),^[33] and similar standards for treatment of quality improvement standards applicable to Medicaid managed care plans (MCOs, PIHPs, and PAHPs) under 42 CFR 438.8, CHIP managed care entities under 42 CFR 457.1203(f), and MA plans under 42 CFR 422.2400 through 422.2490. We request comments related to this assumption and its implications.

VII. Improving the Medicare-Medicaid Dually Eligible Experience by Increasing the Frequency of Federal-State Data Exchanges

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

1. Background

The Medicare and Medicaid programs were originally created as distinct programs with different purposes. The programs have different rules for eligibility, covered benefits, and payment, and the programs have operated as separate and distinct systems despite a growing number of people who depend on both programs for their health care. There is an increasing need to align these programs—and the data and systems that support them—to improve care delivery and the beneficiary experience for dually eligible beneficiaries, while reducing administrative burden for providers, health plans, and states. The interoperability of state and CMS eligibility systems is a critical part of modernizing the programs and improving beneficiary and provider experiences. Improving the accuracy of data on dual eligibility status by increasing the frequency of federal-state data exchanges is a strong first step in improving how these systems work together.

2. Data Exchanges To Support State Buy-in for Medicare Parts A and B

States and CMS routinely exchange data on who is enrolled in Medicare, and which parties are liable for paying that beneficiary's Parts A and B premiums. These data exchanges support state, CMS, and SSA premium accounting, collections, and enrollment functions. Section 1843 of the Act permits states to enter into an agreement with the Secretary to facilitate state “buy-in,” that is, payment of Medicare premiums, in this case Part B premiums, on behalf of certain individuals. For those beneficiaries covered under the agreement, the state pays the beneficiary's monthly Part B premium. Section 1818(g) of the Act establishes the option for states to amend their buy-in agreement to include enrollment and payment of the Part A premium for certain specified individuals. All states and the District of Columbia have a Part B buy-in agreement; 36 states and the District of Columbia have a Part A buy-in agreement.

To effectuate the state payment of Medicare Part A or Part B premiums, a state submits data on a buy-in file to CMS via an electronic file transfer (EFT) exchange setup. The state's input file includes a record for each Medicare beneficiary for whom the state is adding or deleting coverage, or changing buy-in status. In response, CMS returns an updated transaction record that provides data identifying, for each transaction on the state file, whether CMS accepted, modified, or rejected it, as well a Part A or Part B billing record showing the state's premium responsibility. In addition, the CMS file may “push” new updates obtained from SSA to the state, for example, changes to the Medicare Beneficiary Identifier number or a change of address.

We have issued regulations for certain details of the state buy-in processes. For Medicare Part A, 42 CFR 407.40 describes the option for states to amend the buy-in agreement to cover Part A premiums for Qualified Medicare Beneficiaries (QMBs). For Medicare Part B, 42 CFR 406.26 codifies the process for modifying the buy-in agreement to identify the eligibility groups covered. CMS subregulatory guidance, specifically Chapter 3 of the State Buy-in Manual,^[34] specifies that states should exchange buy-in data with CMS at least monthly, but describes the option for states to exchange buy-in data with CMS daily or weekly. Likewise, states can choose to receive the CMS response data file daily or monthly. We note that 31 states and the District of Columbia are now submitting buy-in data to CMS daily; 28 states and the District of Columbia are now receiving buy-in response files from CMS daily.

While many states submit and receive buy-in files daily, some continue to only do so on a monthly basis. We have become increasingly concerned about the limitations of monthly buy-in data exchanges with states. The relatively long lag in updating buy-in data means that the state is not able to terminate or activate buy-in coverage sooner, so the state or beneficiary may be paying premiums for longer than appropriate. In most cases, funds must be recouped and redistributed—a burdensome administrative process involving debits and payments between the beneficiary, state, CMS, and SSA. Additionally, transaction errors do occur in the current data exchange processes. In a monthly exchange, it can take multiple months to correct and resubmit an improperly processed transaction, exacerbating the delays in appropriately assigning premium liability, leading to larger mispayment, recoupment, and redistribution of premiums.

Exchanging the buy-in data with greater frequency supports more timely access to coverage. All states' systems already have the capacity to exchange buy-in data. We acknowledge that states who do not already exchange data daily will need an initial, one-time systems change to do so. However, moving to a daily data exchange would result in a net reduction of burden for states, and further, reduce administrative complexity for beneficiaries and providers. More frequent submission of updates to individuals' buy-in status positively impacts all involved. Based on our experience with the states currently exchanging buy-in data daily, we have found:

• States can terminate buy-in coverage sooner and lower the risk of paying Part A or Part B premiums for individuals once they no longer qualify. Enrollees for whom the buy-in is ending have less risk of a retroactive deduction from their Social Security check due to delayed Part B buy-in terminations (while 42 CFR 407.48(c) limits retroactive recoupments to a maximum of 2 months, an unexpected deduction of up to $268 [2 months of Part B premiums in 2018] is significant for those with incomes low enough to be dually eligible);
• States can detect and fix errors sooner, limiting the impact of such errors;
• State staff can spread the workload of resolving rejected records across the whole month rather than a spike when they receive the monthly CMS response file;
• States can effectuate an earlier shift to Medicare as primary payer for many health care services, for those already covered by Medicaid;
• Beneficiaries newly eligible for buy-in who had been paying premiums themselves can stop having the Part B premium deducted from their Social Security check sooner; and,
• Beneficiaries newly eligible for buy-in who could not afford Medicare premiums can access Medicare Parts A and B services and providers can be assured of coverage sooner.

While there exist opportunities to modernize the platform for buy-in data exchange, we believe that an important first step is to promote the exchange of the most current available data. Section 1843(f) of the Act specifies that Part B buy-in agreements shall contain such provisions as will facilitate the financial transactions of the State and the carrier with respect to deductions, coinsurance, and otherwise, and as will lead to economy and efficiency of operation. Further, section 1818(g)(2)(A) of the Act on Part A buy-in identifies this section 1843(f) requirement as applicable to Part A buy-in. While the regulations governing buy-in agreements (see 42 CFR 406.26 and 407.40) are silent on the frequency of buy-in data exchanges, current guidance articulates that the required buy-in data may be submitted daily, weekly, or monthly. We are proposing to establish frequency requirements in the regulations at 42 CFR 406.26(a)(1) and 407.40(c) to require all states to participate in daily exchange of buy-in data to CMS, with “daily” meaning every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. We believe these requirements will improve the economy and efficiency of operation of the “buy-in” process. We propose that states would be required to begin participating in daily exchange of buy-in data with CMS by April 1, 2022. We believe this effective date will allow states to phase in any necessary operational changes or bundle this required change with any new systems implementation. There are 19 states that we anticipate will need to make a system change to send buy-in data to CMS daily, and 22 states that we anticipate will need to make a system change to receive buy-in data from CMS daily. We estimate the one-time cost to be a little less than $80,000 per state, per change. So a state that needs to make systems updates to both send buy-in data daily, and receive buy-in data daily would have a one-time cost of just under $160,000. We seek comment on these proposals.

3. Exchange of State MMA Data Files

States submit data on files at least monthly to CMS to identify all dually eligible individuals, including full-benefit and partial-benefit dually eligible beneficiaries (that is, those who get Medicaid help with Medicare premiums, and often for cost-sharing). The file is called the “MMA file,” but is occasionally referred to as the “State Phasedown file.” The MMA file was originally developed to meet the need to timely identify dually eligible beneficiaries for the then-new Medicare Part D prescription drug benefit. The Medicare Modernization Act (MMA) established that beginning January 1, 2006, Medicare would be primarily responsible for prescription drug coverage for full-benefit dually eligible individuals; established auto-enrollment of full-benefit dually eligible beneficiaries into Medicare prescription drug plans (with regulations further establishing facilitated enrollment into prescription drug plans for partial-benefit dually eligible beneficiaries), provided that dually eligible beneficiaries are treated as eligible for the Medicare Part D Low Income Subsidy (LIS), sometimes called Extra Help; defined phased down state contributions to partly finance Part D costs for dually eligible beneficiaries; and required risk-adjusting capitation payments for low-income subsidy (which include dually eligible) enrollees of Part D plans. To support these new requirements, we issued 42 CFR 423.910, establishing monthly reporting by states, in which states would submit, at least monthly, a data file identifying dually eligible individuals in their state. Over time, we used these files' data on dual eligibility status to support Part C capitation risk-adjustment, and most recently, to feed dual eligibility status to Part A and B eligibility and claims processing systems so providers, suppliers, and beneficiaries have accurate information on beneficiary cost-sharing obligations.

It is required at 42 CFR 423.910 that states to submit at least one MMA file each month. However, states have the option to submit multiple MMA files throughout the month (up to one per day). Most states submit MMA data files at least weekly; however, only 13 states submit MMA data files daily. As CMS now leverages MMA data on dual eligibility status into systems supporting all four parts of the Medicare program, it is becoming even more essential that dual eligibility status is accurate and up-to-date. Dual eligibility status can change at any time in a month. Waiting up to a month for status updates can negatively impact access to the correct level of benefit at the correct level of payment. Based on our experience with states that exchange data daily, more frequent MMA file submissions benefit states, beneficiaries, and providers, in a number of ways including:

• Enabling an earlier transition to Medicare coverage for prescription drugs, which reduces the number of claims the state pays erroneously and has to recoup from pharmacists (that then have the burden of reaching out to reconcile with the new Part D plan);
• Effectuating an earlier shift to Medicare as primary payer for many health care services;
• Aiding timely error identification and resolution, mitigating the payment and other implications of the error;
• Supporting states that promote enrollment in integrated care by expediting the enrollment into Medicare, since beneficiaries must have Medicare Parts A and B, as well as Medicaid to be eligible for integrated products such as Dual-eligible Special Needs Plans, Medicare-Medicaid Plans, and the Programs for All-inclusive Care for the Elderly (PACE);
• Supporting beneficiaries to obtain access to Medicare Part D benefits and related subsidies sooner, as dual eligibility status on the MMA file prompts CMS to deem individuals automatically eligible for the Medicare Part D LIS and make changes to LIS status (for example, reducing copayments to $0 when data indicate a move to a nursing facility or use of home and community based long term care services) and auto-enroll them into Medicare prescription drug coverage back to the start of dual eligibility status; and,
• Promoting protections for QMBs by improving the accuracy of data for providers and QMBs on zero cost-sharing liability for services under Medicare Parts A and B.

As noted, current regulation requires that the MMA files be submitted at least monthly. We have implemented “work-arounds” for lags in dual eligibility status for Part D, including the “Best Available Evidence” policy (see 42 CFR 423.800(d)), as well as the Limited Income Newly Eligible Transition demonstration, which provides short term drug coverage for dually eligible beneficiaries with no Part D plan enrollment in a given month (see Medicare Prescription Drug Benefit Manual, Chapter 3, Section 40.1.4).^[35] While these work-arounds provide needed protections, more frequent data exchanges would mitigate the need for them.

Ensuring information on dual eligibility status is accurate and up-to-date by increasing the frequency of federal-state data exchange is an important step in the path to interoperability. As a result, we are proposing to update the frequency requirements in 42 CFR 423.910(d) to require that starting April 1, 2022, all states submit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily would mean every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. We propose that states will be required to begin submitting these data daily to CMS by April 1, 2022, because we believe this effective date will allow states to phase in any necessary operational changes or bundle this required change with any new systems implementation. There are 37 states and the District of Columbia that we anticipate will need to make a system change to send MMA data to CMS daily. We estimate the one-time cost for a state to be a little less than $80,000 for this MMA data systems change. For a detailed discussion of the costs associated with these requirements we refer readers to section XVI. of this proposed rule. We seek comment on these proposals.

B. Request for Stakeholder Input

In addition to the proposals recommended above, we seek public comment for consideration in future rulemaking on how we can achieve greater interoperability of federal-state data for dually eligible beneficiaries, including in the areas of program integrity and care coordination, coordination of benefits and crossover claims, beneficiary eligibility and enrollment, and their underlying data infrastructure. Specifically, we seek comment on:

• Whether existing regulations, as well as those proposed here, sufficiently support interoperability among those serving dually eligible beneficiaries, and if not, what additional steps would advance interoperability.
• How to enhance the interoperability of existing CMS processes to share Medicare data with states for care coordination and program integrity.
• How to improve the CMS and state data infrastructure to support interoperability (for example, more frequent data exchanges, common data environment, etc.).
• For eligibility, how interoperability can provide timely, integrated eligibility and enrollment status across Medicare, Medicaid, and related agencies (for example, SSA), and reduce the need for persons to provide, and states to collect/process, the same demographic information (for example, address, income).
• For provider enrollment in both Medicaid and Medicare, how interoperability can streamline provider enrollment and reduce provider and state burden to increase systems accuracy and beneficiary utilization of provider enrollment data (for example, disability competence, hours of service, types of insurance accepted, etc.).
• For coordination of benefits, including crossover claims, the underlying changes that would need to be made to support interoperability (for example, coding, file formats, provider/beneficiary identifier, and encounter versus FFS data).

Please include specific examples when possible while avoiding the transmission of protected information. Please also include a point of contact who can provide additional information upon request.

VIII. Information Blocking Background and Public Reporting

A. Information Blocking Background

1. Legislative Background and Policy Considerations

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

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

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

Recent empirical and economic research further underscores the complexity of the information blocking problem and its harmful effects. In a national survey of health information organizations, half of respondents reported that EHR developers routinely engage in information blocking, and a quarter of respondents reported that hospitals and health systems routinely do so.^[37] Perceived motivations for information blocking described by respondents included, for EHR vendors, maximizing short term revenue and competing for new clients, and for hospitals and health systems, strengthening their competitive position relative to other hospitals and health systems. Other research suggests that these practices weaken competition among health care providers by limiting patient mobility, encouraging consolidation, and creating barriers to entry for developers of new and innovative applications and technologies that enable more effective uses of clinical data to improve population health and the patient experience.^[38]

In December 2016, section 4004 of the Cures Act added section 3022 of the PHSA (the “PHSA information blocking provision”), which defines conduct by health care providers, health IT developers, and health information exchanges and networks, that constitutes information blocking. The PHSA information blocking provision was enacted in response to ongoing concerns that some individuals and entities are engaging in practices that unreasonably limit the availability and use of electronic health information for authorized and permitted purposes (see the definition of electronic health information proposed by ONC for HHS adoption at 45 CFR 171.102 (published elsewhere in this issue of the Federal Register)). These practices undermine public and private sector investments in the nation's health IT infrastructure and frustrate efforts to use modern technologies to improve health care quality and efficiency, accelerate research and innovation, and provide greater value and choice to health care consumers.

The information blocking provision added to PHSA defines and creates possible penalties and disincentives for information blocking in broad terms, working to deter the entire spectrum of practices likely to interfere with, prevent, or materially discourage access, exchange, or use of electronic health information. The PHSA information blocking provision applies to health care providers, health IT developers, exchanges, and networks. The information blocking provision added to PHSA by the Cures Act also provides that the “Secretary, through rulemaking, shall identify reasonable and necessary activities that do not constitute information blocking for purposes of the definition at section 3022(a)(1) of the PHSA.” ONC has taken the lead on this rulemaking effort, and in addition to the attestation discussed in this section, all health care providers would also be subject to the separate information blocking regulations proposed by ONC for HHS adoption at 45 CFR part 171 (published elsewhere in this issue of the Federal Register).

We propose to publicly report certain information about eligible clinicians' attestations under the QPP on Physician Compare and eligible hospitals' and CAHs' attestations under the Medicare FFS Promoting Interoperability Program (previously known as the Medicare EHR Incentive Program) on a CMS website. As discussed below, although we have already implemented what is required by sections 106(b)(2)(A) and (B) of MACRA through the attestation requirements we have established in prior rulemaking (81 FR 77028 through 77035), we believe publishing information on which eligible clinicians, eligible hospitals, and CAHs have negatively attested that they have not knowingly and willfully taken action to limit or restrict the compatibility or interoperability of certified EHR technology would serve to discourage knowing and willful behavior that limits interoperability and prevents the sharing of information discussed in both MACRA and the Cures Act.

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

Physician Compare (http://www.medicare.gov/​physiciancompare) draws its operating authority from section 10331(a)(1) of the Affordable Care Act. Consistent with section 10331(a)(2) of the Affordable Care Act, Physician Compare initiated a phased approach to publicly reporting performance scores that provide comparable information on quality and patient experience measures. A complete history of public reporting on Physician Compare is detailed in the CY 2016 Physician Fee Schedule (PFS) final rule with comment period (80 FR 71117 through 71122). More information about Physician Compare, including the history of public reporting and regular updates about what information is currently available, can also be accessed on the Physician Compare Initiative website at https://www.cms.gov/​medicare/​quality-initiatives-patient-assessment-instruments/​physician-compare-initiative/​.

As discussed in the CY 2018 Quality Payment Program final rule (82 FR 53820), Physician Compare has continued to pursue a phased approach to public reporting under MACRA in accordance with section 1848(q)(9) of the Act. Specifically, subparagraphs (A) and (D) of section 1848(q)(9) of the Act facilitate the continuation of the phased approach to public reporting by requiring the Secretary to make available on the Physician Compare website, in an easily understandable format, individual MIPS eligible clinician and group performance information, including: The MIPS eligible clinician's final score; the MIPS eligible clinician's performance under each MIPS performance category (quality, cost, improvement activities, and Promoting Interoperability); names of eligible clinicians in Advanced APMs and, to the extent feasible, the names of such Advanced APMs and the performance of such models; and, aggregate information on the MIPS, posted periodically, including the range of final scores for all MIPS eligible clinicians and the range of the performance of all MIPS eligible clinicians for each performance category.

In the CY 2018 Quality Payment Program final rule (82 FR 53827), we finalized a policy to include an indicator on Physician Compare, as technically feasible, for any eligible clinician or group who successfully meets the Promoting Interoperability performance category. We also finalized a policy to include, as technically feasible, additional information on Physician Compare, either on the profile pages or in the downloadable database, including, but not limited to objectives, activities, or measures specified in the CY 2018 Quality Payment Program final rule (82 FR 53827; see 82 FR 53663 through 53688) with respect to the Promoting Interoperability performance category.

Generally, all data available for public reporting on Physician Compare must meet our established public reporting standards under 42 CFR 414.1395(b). In addition, for each program year, CMS provides a 30-day preview period for any clinician or group with QPP data being publicly reported on Physician Compare under 42 CFR 414.1395(d). All data available for public reporting—such as final scores—are available for review and correction during the targeted review process as finalized in the CY 2017 Quality Payment Program final rule (81 FR 77392).

Building upon the continuation of our phased approach to public reporting and understanding the importance of preventing information blocking, promoting interoperability and the sharing of information, we propose to make certain data about the attestation statements on the prevention of information blocking referenced earlier in section VIII.A. of this proposed rule available for public reporting on Physician Compare, drawing upon our authority under section 10331(a)(2) of Affordable Care Act, which requires us to make publicly available on Physician Compare information on physician performance that provides comparable information for the public on quality and patient experience measures. Section 10331(a)(2) of the Affordable Care Act provides that to the extent scientifically sound measures that are developed consistent with the requirements of section 10331 of the Affordable Care Act are available, such information shall include, to the extent practicable, an assessment of the coordination of care and other information as determined appropriate by the Secretary. We believe section 10331(a)(2) of the Affordable Care Act provides the statutory authority to publicly report certain data about the prevention of information blocking attestation statements as an assessment of care coordination and as other information determined appropriate by the Secretary. Furthermore, the prevention of information blocking attestation statements are required for a clinician to earn a Promoting Interoperability performance category score, which is then incorporated into the final score for MIPS, and we are required to publicly report both of these scores under section 1848(q)(9)(A) of the Act. Publicly posting this information as an indicator is consistent with our finalized policy to publicly report, either on the profile pages or in the downloadable database, other aspects of the Promoting Interoperability performance category, such as objectives, activities, or measures specified in the CY 2018 Quality Payment Program final rule.

There are three prevention of information blocking attestation statements under 42 CFR 414.1375(b)(3)(ii)(A) through (C) to which eligible clinicians reporting on the Promoting Interoperability performance category of MIPS must attest. To report successfully on the Promoting Interoperability performance category, in addition to satisfying other requirements, an eligible clinician must submit an attestation response of “yes” for each of these statements. For more information about these statements, we refer readers to the preamble discussion in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 81 FR 77035).

We believe it would benefit the public to know if eligible clinicians have attested negatively to the statements under 42 CFR 414.1375(b)(3)(ii) as this may assist the patient in selecting a clinician or group who collaborates with other clinicians, groups, or other types of health care providers by sharing information electronically, and does not withhold information that may result in better care. Therefore, we are proposing to include an indicator on Physician Compare for the eligible clinicians and groups that submit a “no” response to any of the three statements under 42 CFR 414.1375(b)(3)(ii)(A) through (C). In the event that these statements are left blank, that is, a “yes” or a “no” response is not submitted, the attestations would be considered incomplete, and we would not include an indicator on Physician Compare. We also propose to post this indicator on Physician Compare, either on the profile pages or the downloadable database, as feasible and appropriate, starting with the 2019 performance period data available for public reporting starting in late 2020.

Under 42 CFR 414.1395(b), these data must meet our established public reporting standards, including that to be included on the public facing profile pages, the data must resonate with website users, as determined by CMS. In previous testing with patients and caregivers, we have learned that effective use of CEHRT is important to them when making informed health care decisions. To determine how to best display and meaningfully communicate the indicator on the Physician Compare website, the exact wording and, if applicable, profile page indicator would be determined after user testing and shared with stakeholders through the Physician Compare Initiative page, listservs, webinars, and other available communication channels. We note this proposal is contingent upon the availability of and technical feasibility to use these data for public reporting. We request comment on this proposal.

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

Section 1886(n)(4)(B) of the Act requires the Secretary to post in an easily understandable format a list of the names and other relevant data, as determined appropriate by the Secretary, of eligible hospitals and CAHs who are meaningful EHR users under the Medicare FFS program, on a CMS website. In addition, that section requires the Secretary to ensure that an eligible hospital or CAH has the opportunity to review the other relevant data that are to be made public with respect to the eligible hospital or CAH prior to such data being made public. We believe certain information related to the prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) would constitute other relevant data under section 1886(n)(4)(B) of the Act. Specifically, we are referring to the three prevention of information blocking attestation statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) to which eligible hospitals and CAHs must attest for purposes of the Promoting Interoperability Program. As part of successfully demonstrating that an eligible hospital or CAH is a meaningful EHR user for purposes of the Promoting Interoperability Program, the eligible hospital or CAH must submit an attestation response of “yes” for each of these statements. For more information about these statements, we refer readers to the preamble discussion in the CY 2017 Quality Payment Program final rule (81 FR 77028 through 81 FR 77035).

We believe it would be relevant to the public to know if eligible hospitals and CAHs have attested negatively to the statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3) as it could indicate that they are knowingly and unreasonably interfering with the exchange or use of electronic health information in ways that limit its availability and use to improve health care. As we stated in the CY 2017 Quality Payment Program final rule, we believe that addressing issues related to information blocking would require additional and more comprehensive measures (81 FR 77029). In addition, publicly posting this information would reinforce our commitment to focus on increased interoperability and the appropriate exchange of health information. We propose to post information on a CMS website available to the public indicating that an eligible hospital or CAH attesting under the Medicare FFS Promoting Interoperability Program submitted a “no” response to any of the three statements under 42 CFR 495.40(b)(2)(i)(I)(1) through (3). In the event that these statements are left blank, that is, a “yes” or a “no” response is not submitted, the attestations would be considered incomplete, and we would not post any information related to these attestation statements for that hospital or CAH. We propose to post this information starting with the attestations for the EHR reporting period in 2019, and we expect the information would be posted in late 2020. In accordance with section 1886(n)(4)(B) of the Act, we propose to establish a process for each eligible hospital and CAH to review the information related to their specific prevention of information blocking attestation statements before it is publicly posted on a CMS website. Specifically, for each program year, we propose a 30-day preview period for an eligible hospital or CAH to review this information before it is publicly posted. During the 30-day preview period, we propose that all of the information that we would publicly post would be available for the eligible hospital or CAH to review, and we would consider making changes to the information on a case-by-case basis (for example, in the event the eligible hospital or CAH identifies an error, and we subsequently determine that the information is not accurate). Additional information on the review process will be provided outside of the rulemaking process through the usual communication channels for the program. We invite comments on this proposal.

IX. Provider Digital Contact Information

A. Background

Congress required the Secretary to create a provider digital contact information index in section 4003 of the Cures Act. This index must include all individual health care providers and health care facilities, or practices, in order to facilitate a comprehensive and open exchange of patient health information. Congress gave the Secretary the authority to use an existing index or to facilitate the creation of a new index. In comments received on the FY 2019 IPPS proposed rule RFI, there was strong support for a single, public directory of provider digital contact information. Commenters noted that digital communication could improve interoperability by facilitating efficient exchange of patient records, eliminating the burden of working with scanned paper documents, and ultimately enhancing care coordination.

To ensure the index is accessible to all clinicians and facilities, we have updated the NPPES ^[39] to be able to capture digital contact information for both individuals and facilities. NPPES currently supplies National Provider Identifier (NPI) numbers to health care providers (both individuals and facilities), maintains their NPI record, and publishes the records online.^[40] The Secretary adopted the NPI as the HIPAA administrative simplification standard identifier for health care providers (69 FR 3434). HIPAA covered entities, including health care providers, health plans, and health care clearinghouses, must use the NPI in HIPAA transactions. All health care providers that transmit health information in electronic form in connection with a HIPAA transaction must obtain an NPI.

Health care providers are required to communicate to the NPPES any information that has changed within 30 days of the change (45 CFR 162.410(a)(4)). CMS reviews NPPES to ensure a provider has a valid NPI as part of the Medicare enrollment process, as well as the revalidation process, which occurs every 3 to 5 years depending on the provider or supplier type.

Information in NPPES is publicly accessible via both an online search option and a downloadable database option. As a result, adding digital contact information to this existing index is an efficient and effective way to meet the Congressional requirement to establish a digital contact information index and to promote the sharing of information.

As of June 2018, NPPES has been updated to include the capability to capture one or more pieces of digital contact information that can be used to facilitate secure sharing of health information. For instance, providers can submit a Direct address, which functions similar to a regular email address, but includes additional security measures to ensure that messages are only accessible to the intended recipient in order to keep the information confidential and secure. “Direct” is a technical standard for exchanging health information. Direct addresses are available from a variety of sources, including EHR vendors, State Health Information Exchange entities, regional and local Health Information Exchange entities, as well as private service providers offering Direct exchange capabilities called Health Information Service Providers (HISPs) (https://www.healthit.gov/​sites/​default/​files/​directbasicsforprovidersqa_​05092014.pdf). NPPES can also capture information about a wide range of other types of endpoints that providers can use to facilitate secure exchange of health information, for instance a FHIR server URL or query endpoint associated with a health information exchange.

In addition, NPPES can now maintain information about the type of contact information providers and organizations are associated with, along with the preferred uses for each address. Each provider in NPPES can maintain their own unique information or associate themselves with information shared among a group of providers. Finally, NPPES has also added a public API which can be used to obtain contact information stored in the database. Although NPPES is now better equipped to maintain provider digital contact information, many providers have not submitted this information. In the 2015 final rule, “Medicare and Medicaid Programs; Electronic Health Record Incentive Program-Stage 3 and Modifications to Meaningful Use in 2015 Through 2017” (80 FR 62901), we finalized a policy to collect information in NPPES about the electronic addresses of participants in the EHR Incentive Program (specifically, a Direct address and/or other “electronic service information” as available). However, this policy was not fully implemented at the time, in part due to the limitations of the NPPES system which have since been addressed. As a result, many providers have not yet added their digital contact information to NPPES and digital contact information is frequently out of date.

In light of these updates to the NPPES system, all individual health care providers and facilities can take immediate action to update their NPPES record online to add digital contact information. This simple step will significantly improve interoperability by making valuable contact information easily accessible. For those providers who continue to rely on the use of cumbersome, fax-based modes of sharing information, we hope that greater availability of digital contact information will help to reduce barriers to electronic communication with a wider set of providers with whom they share patients. Ubiquitous, public availability of digital contact information for all providers is a crucial step towards eliminating the use of fax machines for the exchange of health information. We urge all providers to take advantage of this resource to implement Congress' requirement that the Secretary establish a digital contact information index.

B. Proposed Public Reporting of Missing Digital Contact Information

Entities seeking to engage in electronic health information exchange need accurate information about the electronic addresses (for example, Direct address, FHIR server URL, query endpoint, or other digital contact information) of potential exchange partners. A common directory of the electronic addresses of health care providers and organizations could enhance interoperability and information exchange by providing a resource where users can obtain information about how to securely transmit electronic health information to a provider.

We propose to increase the number of providers with valid and current digital contact information available through NPPES by publicly reporting the names and NPIs of those providers who do not have digital contact information included in the NPPES system. We propose to begin this public reporting in the second half of 2020, to allow individuals and facilities time to review their records in NPPES and update the system with appropriate digital contact information. We are also requesting comment from stakeholders on the most appropriate way to pursue this public reporting initiative, including where these names should be posted, with what frequency, and any other information stakeholders believe would be helpful.

We believe this information is extremely valuable to facilitate interoperability, and we appreciate Congress' leadership in requiring the establishment of this directory. We are interested in stakeholder comment on additional possible enforcement authorities to ensure that individuals and facilities make their digital contact information publicly available through NPPES. For example, should Medicare reporting programs, such as MIPS, require eligible clinicians to update their NPPES data with their digital contact information? Should CMS require this information to be included as part of the Medicare enrollment and revalidation process? How can CMS work with states to promote adding information to the directory through state Medicaid programs and CHIP? Should CMS require providers to submit digital contact information as part of program integrity processes related to prior authorization and submission of medical record documentation? We will review comments for possible consideration in future rulemaking on these questions.

X. Revisions to the Conditions of Participation for Hospitals and Critical Access Hospitals (CAHs)

A. Background

As noted earlier in this proposed rule, CMS appreciates the pathways Congress has created for action on interoperability and has been working diligently with ONC to implement them. In order to ensure broad stakeholder input to inform our proposals, we published a Request for Information (RFI) on interoperability in several recently published proposed rules, including the FY 2019 IPPS proposed rule (83 FR 20550). Specifically, we published the RFI entitled, “Promoting Interoperability and Electronic Healthcare Information Exchange Through Possible Revisions to the CMS Patient Health and Safety Requirements for Hospitals and Other Medicare- and Medicaid-Participating Providers and Suppliers.” We requested stakeholders' input on how we could use the CMS health and safety standards that are required for providers and suppliers participating in the Medicare and Medicaid programs (that is, the Conditions of Participation (CoPs), Conditions for Coverage (CfCs), and Requirements for Participation (RfPs) for long term care facilities) to further advance electronic exchange of information that supports safe, effective transitions of care between hospitals and community providers. Specifically, we asked for comment on revisions to the current CMS CoPs for hospitals such as: Requiring that hospitals transferring medically necessary information to another facility upon a patient transfer or discharge do so electronically; requiring that hospitals electronically send required discharge information to a community provider via electronic means if possible and if a community provider can be identified; and, requiring that hospitals make certain information available to patients or a specified third-party application (for example, required discharge instructions) via electronic means if requested.

The RFI discussed several steps we have taken in recent years to update and modernize the CoPs and other health and safety standards to reflect current best practices for clinical care, especially in the area of care coordination and discharge planning. On November 3, 2015, we published a proposed rule, “Medicare and Medicaid Programs; Revisions to Requirements for Discharge Planning for Hospitals, Critical Access Hospitals, and Home Health Agencies” (80 FR 68126), to implement the discharge planning requirements of the IMPACT Act and to revise the discharge planning CoP requirements that hospitals (including short-term acute care hospitals, LTCHs, rehabilitation hospitals, psychiatric hospitals, children's hospitals, and cancer hospitals), CAHs, and HHAs must meet in order to participate in the Medicare and Medicaid programs. The final rule in response to public comment on our proposed new requirements for discharge planning for hospitals, CAHs, and HHAs is under development while we review and respond to public comments (our deadline to finalize this rule is November 3, 2019). Several of the proposed requirements from the 2015 Discharge Planning proposed rule directly addressed the issue of communication between providers and between providers and patients, as well as the issue of interoperability:

• Hospitals and CAHs would be required to transfer certain necessary medical information and a copy of the discharge instructions and discharge summary to the patient's practitioner, if the practitioner is known and has been clearly identified;
• Hospitals and CAHs would be required to send certain necessary medical information to the receiving facility/PAC providers, at the time of discharge; and,
• Hospitals, CAHs, and HHAs would need to comply with the IMPACT Act requirements that would require hospitals, CAHs, and certain PAC providers to use data on quality measures and data on resource use measures to assist patients during the discharge planning process, while taking into account the patient's goals of care and treatment preferences.

We also published the “Medicare and Medicaid Programs; Hospital and Critical Access Hospital Changes to Promote Innovation, Flexibility and Improvement in Patient Care” proposed rule (81 FR 39448) on June 16, 2016, which is under development while we review and respond to public comments (our deadline to finalize this rule is June 15, 2019). In that rule, we proposed updating a number of CoP requirements that hospitals and CAHs would have to meet to participate in the Medicare and Medicaid programs. One of the proposed hospital CoP revisions directly addressed the issues of communication between providers and patients, patient access to their medical records, and interoperability. We proposed that patients have the right to access their medical records, including current medical records, upon an oral or written request, in the form and format requested by such patients, if the information is readily producible in such form and format (including in an electronic form or format when such medical records are maintained electronically); or, if not, in a readable hard copy form or such other form and format as agreed to by the facility and the individual, and within a reasonable timeframe. Under the proposal, a hospital could not frustrate the legitimate efforts of individuals to gain access to their own medical records and would be required to meet these patient requests as quickly as record keeping systems permit.

In response to the recent RFI in the FY 2019 IPPS proposed rule, many stakeholders supported our goals of increasing interoperability and acknowledged the important role that hospital settings play in supporting care coordination. Stakeholders agreed that use of electronic technology was an important factor in ensuring safe transitions. At the same time, many stakeholders expressed concerns about implementing policy changes within the CoPs, which may increase the compliance burden on hospitals.

Given responses to the recent RFI, as well as previous rulemaking activities, we are seeking to further expand CMS requirements for interoperability within the hospital and CAH CoPs as part of this proposed rulemaking by focusing on electronic patient event notifications. In addition, we are committed to taking further steps to ensure that facilities that are electronically capturing information are electronically exchanging that information with providers who have the capacity to accept it. We expect that this will be required through rulemaking at a future point in time, with one option being alignment with the TEFCA described in section 4003 of the Cures Act. We will also continue to consider the RFI responses as we pursue this goal in future rulemaking.

Infrastructure supporting the exchange of electronic health information across settings has matured substantially in recent years. Research studies have increasingly found that health information exchange interventions can effect positive outcomes in health care quality and public health, in addition to more longstanding findings around reductions in utilization and costs. A recent review of how health information exchange interventions can improve cost and quality outcomes identified a growing body of high-quality studies showing that these interventions are associated with beneficial results.^[41] The authors identified a number of studies demonstrating positive effects on outcomes associated with better care coordination, such as reductions in 30-day readmissions,^{[42 43 44]} and medication reconciliation.^[45]

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

Patient event notifications are automated, electronic communications from the discharging provider to another facility, or to another community provider as identified by the patient, which alerts the receiving provider that the patient has received care at a different setting. Depending on the implementation, information included with these notifications can range from conveying the patient's name, other basic demographic information, and the sending institution to a richer set of clinical data on the patient. Regardless of the information included, these notifications can help ensure that a receiving provider is aware that the patient has received care elsewhere. The notification triggers a receiving provider to reach out to the patient and deliver appropriate follow-up care in a timely manner. By notifying the physician, care manager, or care management team, the notification can help to improve post-discharge transitions and reduce the likelihood that a patient would face complications from inadequate follow-up care.

In addition to their effectiveness in supporting care coordination, virtually all EHR systems generate the basic messages commonly used to support electronic patient event notifications. These notifications are based on admission, discharge, and transfer (ADT) messages, a standard message used within an EHR as the vehicle for communicating information about key changes in a patient's status as they are tracked by the system (more information about the current standard supporting these messages is available at http://www.hl7.org/​implement/​standards/​product_​brief.cfm?​product_​id=​144). As noted in the ISA published by ONC, this messaging standard has been widely adopted across the health care system (see https://www.healthit.gov/​isa/​sending-a-notification-a-patients-admission-discharge-andor-transfer-status-other-providers).

ADT messages provide each patient's personal or demographic information (such as the patient's name, insurance, next of kin, and attending physician), when that information has been updated, and also indicate when an ADT status has changed. To create an electronic patient event notification, a system can use the change in ADT status to trigger a message to a receiving provider or to a health information exchange system that can then route the message to the appropriate provider. In addition to the basic demographic information contained in the ADT message, some patient event notification implementations attach more detailed information to the message regarding the patient's clinical status and care received from the sending provider.

B. Proposal for Hospitals (Proposed 42 CFR 482.24(d))

We propose to revise the CoPs for Medicare- and Medicaid-participating hospitals at 42 CFR 482.24 by adding a new standard at paragraph (d), “Electronic Notifications,” that would require hospitals to send electronic patient event notifications of a patient's admission, discharge, and/or transfer to another health care facility or to another community provider. As noted in the discussion above, we would require hospitals to convey, at a minimum, the patient's basic personal or demographic information, as well as the name of the sending institution (that is, the hospital), and, if not prohibited by other applicable law, diagnosis. We would also encourage hospitals, as their systems and those of the receiving providers allow, to work with patients and their practitioners to offer more robust patient information and clinical data upon request in accordance with applicable law.

For a hospital that currently possesses an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event (ADT) notifications, compliance with this proposed standard within the Medical records services CoP (42 CFR 482.24) would be determined by the hospital demonstrating that its system: (1) Is fully operational and that it operates in accordance with all State and Federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.299(f)(2); (3) sends notifications that must include the minimum patient health information (which must be patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the hospital and either immediately prior to or at the time of the patient's discharge and/or transfer from the hospital. We recognize that some existing ADT messages might not include diagnosis and therefore seek comment on the technical feasibility of including this information as well as the challenges in appropriately segmenting this information in instances where the diagnosis may not be permitted for disclosure under other applicable laws.

We propose to limit this requirement to only those hospitals which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications as discussed below, recognizing that not all Medicare- and Medicaid-participating hospitals have been eligible for past programs promoting adoption of EHR systems. Our goal with this proposed requirement is to ensure that hospital EHR systems have a basic capacity to generate messages that can be utilized for notifications by a wide range of receiving providers, enabled by common standards. We believe that a system that utilizes the ADT messaging standard, which is widely used as the basis for implementing these notifications and other similar use cases, would meet this goal by supporting the availability of information that can be used to generate information for patient event notifications. Specifically, we propose that the system utilize the ADT Messaging standard incorporated by reference at 45 CFR 170.299(f)(2).^[47]

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

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

We further propose that the hospital would need to demonstrate that the system's notification capacity is fully operational, that it operates in accordance with all state and federal statutes and regulations regarding the exchange of patient health information. We intend for these notifications to be required, at minimum, for inpatients admitted to, and discharged and/or transferred from the hospital. However, we also note that patient event notifications are an effective tool for coordinating care across a wider set of patients that may be cared for by a hospital. For instance, a patient event notification could ensure a primary care physician is aware that their patient has received care at the emergency room, and initiate outreach to the patient to ensure that appropriate follow-up for the emergency visit is pursued. While we encourage hospitals to extend the coverage of their notification systems to serve additional patients, outside of those admitted and seen as inpatients, we also seek comment on whether we should identify a broader set of patients to whom this requirement would apply, and if so, how we should implement such a requirement in a way that minimizes administrative burden on hospitals.

Additionally, we are proposing that the hospital must demonstrate that its system sends notifications that must include the minimum patient health information (which must be patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis). The hospital would also need to demonstrate that the system sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the hospital, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) for whom the hospital has a reasonable certainty of receipt of notifications. Similarly, we are also proposing that the hospital would need to demonstrate the transmission of these notifications either directly, or through an intermediary that facilitates the exchange of health information, and either immediately prior to or at the time of the patient's discharge or transfer from the hospital, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) for whom the hospital has a reasonable certainty of receipt of notifications. We believe this proposal will allow for a diverse set of strategies that hospitals might use when implementing patient event notifications.

Through these provisions, we are seeking to allow for different ways that a hospital might identify those practitioners, other patient care team members, and PAC services providers and suppliers that are most relevant to both the pre-admission and post-discharge care of a patient. We are proposing that hospitals should send notifications to those practitioners or providers that have an established care relationship with the patient relevant to his or her care. We recognize that hospitals and their partners may identify appropriate recipients through various methods. For instance, hospitals might identify appropriate practitioners by requesting this information from patients or caregivers upon arrival, or by obtaining information about care team members from the patient's record. We expect hospitals might develop or optimize processes to capture information about established care relationships directly, or work with an intermediary that maintains information about care relationships. In other cases, hospitals may, directly or through an intermediary, identify appropriate notification recipients through the analysis of care patterns or other attribution methods that seek to determine the provider most likely to be able to effectively coordinate care post-discharge for a specific patient. The hospital or intermediary might also develop processes to allow a provider to specifically request notifications for a given patient for whom they are responsible for care coordination as confirmed through conversations with the patient.

Additionally, we would expect hospitals, psychiatric hospitals, and CAHs to comply with the Health Insurance Portability and Accountability Act (HIPAA) privacy rules set out at 45 CFR parts 160 and 164 when these proposed CoP requirements for patient event notifications are finalized. As required at 42 CFR 482.11 for hospitals and psychiatric hospitals and at 42 CFR 485.608 for CAHs, these providers must comply with all pertinent currently existing federal laws, including the HIPAA Privacy Rule. The patient event notifications and other exchanges of patient information would be permitted as disclosures for treatment purposes under 45 CFR part 164.

We also recognize that factors outside of the hospital's control may determine whether or not a notification is successfully received and utilized by a practitioner. Accordingly, we have proposed that a hospital would only need to send notifications to those practitioners for whom the hospital has reasonable certainty of receipt. While we expect hospitals will, to the best of their ability, seek to ensure that notification recipients are able to receive notifications (for instance, by obtaining a recipient's Direct address), we understand that technical issues beyond the hospital's control may prevent successful receipt and use of a notification.

Finally, we note that hospitals have an existing responsibility under the CoPs at 42 CFR 482.43(d) to “transfer or refer patients, along with necessary medical information, to appropriate facilities, agencies, or outpatient services, as needed, for follow-up or ancillary care.” We wish to emphasize that our proposal regarding patient event notifications would be separate from the requirement regarding necessary medical information at 42 CFR 482.43(d). We recognize that processes to implement this proposal, if finalized, may intersect with the hospital's discharge planning process. We note that nothing in this proposal would affect the hospital's responsibilities under 42 CFR 482.43(d). However, if this proposal is finalized, hospitals may wish to consider ways to fulfill these requirements in ways that reduce redundancy while still remaining compliant with existing requirements. For instance, where appropriate and allowed by law, hospitals may seek to include required necessary medical information within the same message as a patient event notification.

As previously stated, we are committed to continuing to identify further steps we can take to ensure that facilities that are electronically capturing information are exchanging that information electronically with providers that have the capacity to accept it. We expect that this will be required through rulemaking at a future point in time with one option being alignment with the TEFCA described in the Cures Act.

C. Proposal for Psychiatric Hospitals (Proposed 42 CFR 482.61(f))

Medicare- and Medicaid-participating psychiatric hospitals must comply with all of the hospital CoPs at 42 CFR 482.1 through 482.23 and at 42 CFR 482.25 through 482.57. They also must adhere to special provisions regarding medical records at 42 CFR 482.61 and staffing requirements at 42 CFR 482.62. Since the medical records requirements are different for psychiatric hospitals, and since these hospitals do not have to comply with our regulations at 42 CFR 482.24, we are proposing a new electronic notification standard at 42 CFR 482.61(f) within the special provisions for psychiatric hospitals in this section.

Similar to our proposal for hospitals at 42 CFR 482.24(d), we are proposing a new standard at 42 CFR 482.61(f), “Electronic Notifications,” that would require psychiatric hospitals to send electronic patient event notifications of a patient's admission, discharge, and/or transfer to another health care facility or to another community provider.

As we have proposed for hospitals, we propose to limit this requirement to only those psychiatric hospitals which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications, defined as systems that utilize the content exchange standard incorporated by reference at 45 CFR 170.299(f)(2). We propose that for a psychiatric hospital that currently possesses an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event (ADT) notifications, compliance with this proposed standard within the Special medical records requirements for psychiatric hospitals CoP (42 CFR 482.61) would be determined by the hospital demonstrating that its system: (1) Is fully operational and that it operates in accordance with all State and Federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.299(f)(2); (3) sends notifications that must include the minimum patient health information (which must be patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the hospital and either immediately prior to or at the time of the patient's discharge and/or transfer from the hospital. Please note that we are requesting comment on this policy as part of this hospital proposal in section X.B. of this proposed rule above. Please see additional discussion in the proposal for hospitals above.

Additionally, we are proposing that the hospital would need to demonstrate that the system sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the hospital, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) for whom the hospital has a reasonable certainty of receipt of notifications. Similarly, we are also proposing that the hospital would need to demonstrate the transmission of these notifications either directly, or through an intermediary that facilitates the exchange of health information, and either immediately prior to or at the time of the patient's discharge or transfer from the hospital, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) for whom the hospital has a reasonable certainty of receipt of notifications.

We refer readers to the extended discussion of these proposals in sections X.A. and B. of this proposed rule. We seek comment on these proposals.

D. Proposal for CAHs

We believe implementation of patient event notifications are also important for CAHs to support improved care coordination from these facilities to other providers in their communities. Therefore, similar to our proposals for the hospital and psychiatric hospital medical records requirements as discussed in the preceding sections, we would revise 42 CFR 485.638, by adding a new standard to the CAH Clinical records CoP at paragraph (d), “Electronic Notifications.” This proposed standard would require CAHs to send electronic patient event notifications of a patient's admission, discharge, and/or transfer to another health care facility or to another community provider.

We propose to limit this requirement to only those CAHs which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications, defined as systems that utilize the content exchange standard incorporated by reference at 45 CFR 170.299(f)(2). We propose that for a CAH that currently possesses an EHR system with the capacity to generate the basic patient personal or demographic information for electronic patient event (ADT) notifications, compliance with this proposed standard within the Clinical records services CoP (42 CFR 485.638) would be determined by the CAH demonstrating that its system: (1) Is fully operational and that it operates in accordance with all State and Federal statutes and regulations regarding the exchange of patient health information; (2) utilizes the content exchange standard incorporated by reference at 45 CFR 170.299(f)(2); (3) sends notifications that must include the minimum patient health information (which must be patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis); and (4) sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the CAH and either immediately prior to or at the time of the patient's discharge and/or transfer from the CAH. Please note that we are requesting comment on this policy as part of the hospital proposal above in section X.B. of this proposed rule. Please see additional discussion in the proposal for hospitals above.

Additionally, we are proposing that the CAH would need to demonstrate that the system sends notifications directly, or through an intermediary that facilitates exchange of health information, and at the time of the patient's admission to the CAH, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) for whom the CAH has a reasonable certainty of receipt of notifications. Similarly, we are also proposing that the CAH would need to demonstrate the transmission of these notifications either directly, or through an intermediary that facilitates the exchange of health information, and either immediately prior to or at the time of the patient's discharge or transfer from the CAH, to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) for whom the CAH has a reasonable certainty of receipt of notifications.

We request comments on all of these proposals. We are especially interested in stakeholder feedback about how these proposals should be operationalized. Additionally, we seek comment on how CMS should implement these proposals as part of survey and certification guidance in a manner that minimizes compliance burden on hospitals, psychiatric hospitals, and CAHs while ensuring adherence with the standards. We are also interested in stakeholder input about a reasonable timeframe for implementation of these proposals for hospitals, psychiatric hospitals, and CAHs, respectively.

XI. Request for Information on Advancing Interoperability Across the Care Continuum

A. Background

Transitions across care settings have been characterized as common, complicated, costly, and potentially hazardous for individuals with complex health needs. Yet despite the need for functionality to support better care coordination, discharge planning, and timely transfer of essential health information, interoperability by certain health care providers such as long term and PAC, behavioral health, and home and community-based services continues to lag behind acute care providers. Research from the Assistant Secretary for Planning and Evaluation (ASPE) and CMS, showed that in 2014, 44 percent of patients discharged from an acute care hospitalization received post-acute services, such as an admission to a SNFs, an IRF or a LTCH, or received HHA services. Specifically, of the 1,260,958 patients that received post-acute services following an acute care hospitalization, “. . . 47.8 percent were discharged to a HHA, 42.1 percent to a SNF, 8.4 percent to an IRF, 1.0 percent to a LTCH and .7 percent to LTCH-Site Neutral.” ^[49] In addition to the frequency of patients discharged from acute care to PAC, a remarkable number of patients discharged from PAC services receive subsequent care by another PAC provider. For instance, while more current analysis is being finalized, we note that 2012 data from the Post-Acute Care Reform Demonstration (PAC PRD) found, “67 percent of those discharged to SNFs continued on to additional services. Almost a quarter of them were readmitted to the acute hospital (23.1 percent). Another third (32.7 percent) were discharged from the SNF to a HHA.

In patients with the Acute-SNF-HHA pattern, almost 20 percent (19.9 percent) returned to the acute care hospital within 30 days of discharge from the HHA. Hospital patients discharged to LTCHs and IRFs were also likely to use multiple types of PAC services and a substantial share of these cases were readmitted within 30 days of discharge, ranging from 15.9 percent (LTCH-to-IRF cases) to 42.8 percent (LTCH to SNF cases).” ^[50] In examining the home health patterns, it is important to keep in mind that a significant number of the home health population does not come through an acute admission or as part of a post-acute trajectory of care but instead are directly admitted to the HHA from the community. The percentages of PAC use and patterns of multiple transitions reinforce the need for safeguards around transitions of care. These findings also speak to the importance of the interoperable exchange of information necessary to ensure continuity of care, and mitigate the risks of unintended events, such as those associated with medication errors, that can result from inadequate and untimely exchange of information.

Poor patient outcomes, resulting from poor communication and lack of information, have been found to contribute to hospital readmissions, emergency department (ED) visits, and adverse outcomes. A well-documented contributor to this problem is incomplete and missing information for patients with frequent transitions across care settings. While interoperable, bidirectional exchange of essential health information can improve these transitions, many long-term and PAC, behavioral health, and home and community-based service providers have not adopted health IT at the same rate as acute care hospitals. One major contributing factor to this difference in adoption rates can be attributed to the fact that PAC providers were not eligible for the Medicare and Medicaid EHR Incentive Programs (now known as the Promoting Interoperability Programs), which slowed adoption of EHRs and other forms of interoperable health IT for these providers.

National data on EHR adoption and interoperability by these providers is limited. For PAC facilities that do possess EHRs, vendor adoption of interoperable functionality has been slow and uneven. A national survey of SNFs found that 64 percent of facilities used an EHR in 2016, 29 percent of SNFs could send or receive health information, but only 7 percent could send, find, receive, and integrate such information.^[51] According to the 2015 National Electronic Health Records Survey (NEHRS), 61.3 percent of psychiatrists were using an EHR, of which 40.8 percent were certified systems.^[52] A CDC survey found that 26 percent of residential care communities used EHRs in 2016.^[53]

B. Solicitation of Comments

We are soliciting comment on several potential strategies for advancing interoperability across care settings to inform future rulemaking activity in this area.

As discussed above, health IT adoption has lagged in care settings that were not part of the EHR Incentive Programs. We are seeking input on how HHS can more broadly incentivize the adoption of interoperable health IT systems and use of interoperable data across settings such as long-term and PAC, behavioral health, and those settings serving individuals who are dually eligible for Medicare and Medicaid and/or receiving home and community-based services. We invite comment on specific policy strategies HHS could adopt to deliver financial support for technology adoption and use in these settings.

We also recognize that an ongoing challenge to advancing and incentivizing interoperability is the lack of agreed-upon measure concepts with which to gauge how well providers are routinely and effectively engaging in exchange of information across settings. To date, the measurement of interoperability has largely focused on the use of certified technology and the percentage of information exchanged. Expanding the scope of interoperability measurement beyond settings that were eligible for the EHR Incentive Programs is critical as efforts are being made to enable health IT and exchange capabilities across a broader range of care settings. In light of the interest by the stakeholder community to enable interoperability across all providers, HHS is seeking public comment on measure concepts that assess interoperability, including measure concepts that address PAC, behavioral health, home and community-based services, and other provider settings.

A National Quality Forum report on Quality in Home and Community-Based Services to Support Community Living: Addressing Gaps in Performance Measurement suggested that new types of measure concepts that assess quality across the continuum of care are needed. Specifically, NQF cited the domain of “service delivery and effectiveness,” which encompasses the level to which individuals who use Home and Community Based Services (HCBS) receive services and supports sufficient to meet their needs, as well as the domain of “person-centered planning and coordination,” which includes a focus on the level to which services and supports across the health and social service systems are coordinated for individuals who receive HCBS. We seek comment on needed measure development work and quality improvement efforts focused on assuring individuals receive sufficient needed services across the care continuum and that their services are coordinated.^[54] We are also interested in comments on the applicability and feasibility of measure concepts for PAC, behavioral health, home and community-based services as identified in previous ASPE reports ^{[55]  [56]} and the report, A Measurement Framework to Assess Nationwide Progress Related to Interoperable Health Information Exchange to Support the National Quality Strategy, published by the National Quality Forum.^[57]

As part of its work under the IMPACT Act, which requires, in part, that certain patient assessment data be standardized and interoperable to allow for exchange of the data among PAC providers and other providers, CMS has defined certain standardized patient assessment data elements ^[58] and their associated health IT vocabularies across PAC settings. Implementation of these standardized data elements is designed to support more seamless and effective assessment of quality across PAC settings, while also presenting a significant improvement in the ability of these settings to potentially share structured electronic data with other providers across the care continuum.

To enable the bidirectional exchange of this health information, we are seeking public comment on whether hospitals and physicians should adopt the capability to collect and electronically exchange a subset of the same PAC standardized patient assessment data elements (for example, functional status, pressure ulcers/injuries) in their EHRs. As these health care providers have generally been eligible for the EHR Incentive Programs (now known as Promoting Interoperability Programs), many of them would have adopted certified EHR technology and health IT systems, which are required to capture and exchange certain data elements under the ONC Health IT certification program. The set of data which systems must include under the certification program is set to expand in coming years under the USCDI Version 1 ONC has proposed for HHS adoption at 45 CFR 170.213, which would establish a minimum set of data classes that would be required to be interoperable nationwide (see the ONC proposed rule published elsewhere in this issue of the Federal Register). The USCDI is designed to be expanded in an iterative and predictable way over time.

We are seeking comment on whether to move toward the adoption of PAC standardized data elements through the expansion of the USCDI process. We are interested in whether the standardized patient assessment data elements that are implemented in CMS PAC assessment instruments in satisfaction of the IMPACT Act would be appropriate. If the full set of such standardized patient assessment data elements is not appropriate, we are seeking comment on whether a subset of these standardized items would be appropriate, and input on which data elements should be prioritized as part of a subset. We are also seeking information on what implementation timeline would be most appropriate for requiring adoption of these data elements in provider and hospital systems under the ONC Health IT Certification Program. We are also seeking comment on the administrative, development, and implementation burden that may be associated with adopting these data elements.

XII. Advancing Interoperability in Innovative Models

A. Promoting Interoperability

CMS plans to utilize Center for Medicare and Medicaid Innovation (“Innovation Center”) authority under section 1115A of the Act to test ways to promote interoperability across the health care spectrum. Section 1115A of the Act authorizes the Innovation Center to test innovative payment and service delivery models expected to reduce program expenditures, while preserving or enhancing the quality of care furnished to Medicare and Medicaid beneficiaries and CHIP enrollees. Interoperability and health data sharing are critical to the success of new payment and service delivery models that incentivize high quality, efficient care.

Innovation Center models can include multiple types of health care providers and other entities such as physician group practices, hospitals, PAC facilities, community-based organizations providing community-based long-term care services and supports or non-medical services, and dialysis centers. These types of health care providers furnish care to patients in different care settings, have different health IT systems, and have varied levels of experience with, and access to, EHR technology. The historically disparate and inadequate use of health IT among these providers and other entities has posed challenges to interoperability. Additionally, many of these types of health care providers are not eligible for the Promoting Interoperability Programs (previously known as the Medicare and Medicaid EHR Incentive Programs) and the associated financial incentives for EHR adoption and meaningful use.

We believe Innovation Center models (https://innovation.cms.gov/​) provide an important lever to advance progress toward interoperability. These models offer unique opportunities to engage with health care providers and other entities in innovative ways and to test concepts that have the ability to accelerate change in the U.S. health care system, including to promote interoperability. One example of CMS's use of Innovation Center Models to promote interoperability is found in the Innovation Center's State Innovation Models (SIM) initiative (https://innovation.cms.gov/​initiatives/​state-innovations/​), under which several awards to states are focused on health information exchanges and health IT investment. Another example of this work is found in the Comprehensive Primary Care Plus (CPC+) model (https://innovation.cms.gov/​initiatives/​comprehensive-primary-care-plus), in which primary care practices use health IT to strengthen their ability to deliver care, with some practices partnering with health IT vendors to implement advanced health IT functionality in their practices, including functionality that promotes interoperability and sharing of electronic health information.

B. Examples of Interoperability-Related Areas of Focus for New Model Development

Examples of how we may focus on interoperability related-issues in future model development may include: Models that incorporate piloting emerging standards; models leveraging non-traditional data in model design (for example, data from schools, data regarding housing and data on food insecurity); and models leveraging technology-enabled patient engagement platforms. The Innovation Center has incorporated non-clinical data in prior models, but anticipates addressing additional uses and types of non-clinical data in future models.

We are now requesting public comment on the following general principles around interoperability within Innovation Center models for integration into new models, through provisions in model participation agreements or other governing documents. In applying these general principles, we intend to be sensitive to the details of individual model design, and the characteristics and capacities of the participants in each specific model.

C. Establishing Principles for Promoting Interoperability in Innovative Model Tests

1. Provide Patients Access to Their Own Electronic Health Information

The MyHealthEData and Medicare Blue Button 2.0 initiatives aim to empower patients by ensuring that they have access to their health care data and can decide how their data is going to be used, all while keeping their data safe and secure. Certain Innovation Center models already require that participants with direct patient interactions provide their patients with electronic access to their health information within 24 hours of any encounter. New Innovation Center models may also require that providers and other health care entities with direct patient interactions provide patients access to their own electronic health information and, upon the patient's authorization, to third party developers via APIs.

2. Promote Trusted Health Information Exchange

Innovation Center model participants may, where appropriate, be required to participate in a trusted exchange network that meets the following criteria:

• The trusted exchange network must be able to exchange PHI in compliance with all applicable state and federal laws across jurisdictions.
• The trusted exchange network must connect both inpatient EHRs and ambulatory EHRs.
• The trusted exchange network must support secure messaging or electronic querying by and between patients, providers and payers.

Additionally, model participants may be required to participate in electronic alerting via one of the standards described in the ISA, II-A: Admission, Discharge, and Transfer published and updated by ONC.

3. Adopt Leading Health IT Standards and Pilot Emerging Standards

Emerging health data standards present new opportunities to exchange more types of health care data between health care providers. Innovation Center model participants, along with their health IT vendors, may pilot new FHIR standards and advance adoption of new data classes in USCDI (for example, psychosocial data) to improve interoperability for care management, quality reporting or other priority use cases. As part of the design and testing of innovative payment and service delivery models, the Innovation Center anticipates taking on a leadership role in developing new or less mature FHIR and supporting more innovative interventions undertaken by states, whenever possible.

D. Request for Stakeholder Input

The Innovation Center seeks public comment on the principles for promoting interoperability in innovative payment and service delivery models described above. Additionally, the Innovation Center is requesting public comment on other ways in which the Innovation Center may further promote interoperability among model participants and other health care providers as part of the design and testing of innovative payment and service delivery models.

XIII. Request for Information on Policies To Improve Patient Matching

A. Background

Through stakeholder feedback such as roundtables, stakeholder meetings, and rulemaking, we have received considerable feedback that the lack of a UPI inhibits interoperability efforts because, without a unique identifier for each patient, the safe and secure electronic exchange of health information is constrained as it is difficult to ensure that the relevant records are all for the same patient. HIPAA required the adoption of a “unique individual identifier for healthcare purposes,” commonly referred to as a UPI. At the time HIPAA was enacted, HHS began to consider what information would be needed to develop a rule to adopt a UPI standard. An initial Notice of Intent to issue a proposed rule on requirements for a unique health identifier for individuals was published in the November 2, 1998 Federal Register (63 FR 61773 through 61774).

Appreciating the significant privacy and security concerns raised by stakeholders regarding implementing a UPI, Congress included language in the Omnibus Consolidated and Emergency Supplemental Appropriations Act of 1999 (Pub. L. 105-277, enacted October 21, 1998) and in each subsequent Appropriations bill, stating none of the funds made available in this Act may be used to promulgate or adopt any final standard under section 1173(b) of the Act (42 U.S.C. 1320d-2(b)) providing for, or providing for the assignment of, a unique health identifier for an individual (except in an individual's capacity as an employer or a health care provider), until legislation is enacted specifically approving the standard. This language has effectively prohibited HHS from engaging in rulemaking to adopt a UPI standard. Consequently, the Secretary withdrew the Notice of Intent to pursue rulemaking on this issue on August 9, 2000 (https://www.reginfo.gov/​public/​do/​eAgendaViewRule?​pubId=​200010&​RIN=​0938-AI91).

Although the appropriations language regarding the UPI standard has remained unchanged, in the report accompanying the 2017 appropriations bill, Congress additionally stated, although the Committee continues to carry a prohibition against HHS using funds to promulgate or adopt any final standard providing for the assignment of a unique health identifier for an individual until such activity is authorized, the Committee notes that this limitation does not prohibit HHS from examining the issues around patient matching. Accordingly, the Committee encouraged the Secretary, acting through ONC and CMS, to provide technical assistance to private-sector led initiatives to develop a coordinated national strategy that will promote patient safety by accurately identifying patients to their health information. (H.R. Rep. No. 114-699, p. 110, https://www.gpo.gov/​fdsys/​pkg/​CRPT-114hrpt699/​pdf/​CRPT-114hrpt699.pdf). Congress has repeated this guidance for 2018 and 2019. This guidance directed HHS to focus on examining issues around patient matching and to provide technical assistance to private sector-led initiatives focusing on a patient matching solution.

In conjunction with ONC, we are posing a request for information regarding how CMS could leverage our program authority to improve patient identification to facilitate improved patient safety, enable better care coordination, and advance interoperability. Inaccurate patient matching can lead to adverse events, compromised safety and privacy, inappropriate and unnecessary care, increased health care costs, and poor oversight of fraud and abuse. We consider this a quality of care and patient safety issue and seek stakeholder input on ways we can incent improvements.

In section 4007 of the 21st Century Cures Act, the Government Accountability Office (GAO) was directed to conduct a study to determine whether ONC and other stakeholders could improve patient matching through various mechanisms, to survey ongoing efforts related to the policies and activities and the effectiveness of such efforts occurring in the private sector, and to evaluate current methods used in certified EHRs for patient matching. The GAO was also tasked with submitting to Congress a report concerning the findings of the study. This report was released in January 2019.^[59]

In section I of this proposed rule, we discuss further how patient identification and matching pose challenges to interoperability. We look forward to working with ONC as we review the responses to this RFI in concert with the GAO report to help inform potential appropriate methods to scale best practices and leverage program authority to improve patient matching.

B. Solicitation of Comments

We are soliciting comment on potential strategies to address patient matching. Many stakeholders commenting on the interoperability RFIs included in the various 2019 proposed payment rules, including the FY 2019 IPPS proposed rule (83 FR 20550), indicated that patient matching is a “core functionality” of patient identification and necessary to ensure care coordination and the best patient outcomes. Commenters also noted that a consistently used matching strategy could accomplish the original goals of a UPI with a diminished risk to individual privacy and health information security. We solicit comment on how and in what way patient matching does or does not present the same security and privacy risks as a UPI.

We understand the significant health information privacy and security concerns raised around the development of a UPI standard and the current prohibition against using HHS funds to adopt a UPI standard. Recognizing Congress' statement regarding patient matching and stakeholder comments stating that a patient matching solution would accomplish the goals of a UPI, we seek comment on ways for us to continue to facilitate private sector work on a workable and scalable patient matching strategy so that the lack of a specific UPI does not impede the free flow of information for future consideration.

We are also seeking comment on how we may leverage our program authority to provide support to those working to improve patient matching. We specifically seek input on the following questions and the potential authority for the requirement:

1. Should CMS require Medicare FFS, MA Plans, Medicaid FFS, Medicaid managed care plans (MCOs, PIHPs, and PAHPs), CHIP FFS, CHIP managed care entities, and QHP issuers in FFEs (not including SADP issuers), use a patient matching algorithm with a proven success rate of a certain percentage where the algorithm and real world processes associated with the algorithm used are validated by HHS or a 3rd party?

2. Should CMS require Medicare FFS, the MA Plans, Medicaid FFS, Medicaid managed care plans, CHIP FFS, CHIP managed care entities, and QHP issuers in FFEs to use a particular patient matching software solution with a proven success rate of a certain percentage validated by HHS or a 3rd party?

3. Should CMS expand the recent Medicare ID card efforts by requiring a CMS-wide identifier which is used for all beneficiaries and enrollees in health care programs under CMS administration and authority, specifically by requiring any or all of the following:

• That MA organizations, Part D prescription drug plan sponsors, entities offering cost plans under section 1876 of the Act, and other Medicare health plans use the Medicare ID in their plan administration.
• That State Medicaid and CHIP agencies in their FFS or managed care programs use the Medicare ID for dual eligible individuals when feasible.
• That QHP issuers in FFEs use the Medicare ID for their enrollees in the administration of their plans.

4. Should CMS advance more standardized data elements across all appropriate programs for matching purposes, perhaps leveraging the USCDI proposed by ONC for HHS adoption at 45 CFR 170.213.

5. Should CMS complement CMS data and plan data in Medicaid managed care plans (MCOs, PIHPs, and PAHPs), CHIP managed care entities, MA Plans, and QHP issuers in an FFE (not including SADP issuers) with one or more verifying data sources for identity proofing? What potential data source should be considered? What are possible restrictions or limitations to accessing such information?

6. Should CMS support connecting EHRs to other complementary verifying data sources for identity proofing? What potential data source should be considered? What are possible restrictions or limitations to accessing such information?

7. To what extent should patient-generated data complement the patient-matching efforts?

XIV. Collection of Information Requirements

Under the Paperwork Reduction Act of 1995, we are required to provide 60-day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. In order to fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act of 1995 requires that we solicit comment on the following issues:

• The need for the information collection and its usefulness in carrying out the proper functions of our agency.
• The accuracy of our estimate of the information collection burden.
• The quality, utility, and clarity of the information to be collected.
• Recommendations to minimize the information collection burden on the affected public, including automated collection techniques.

We are soliciting public comment on each of these issues for the following sections of this document that contain information collection requirements (ICRs):

A. Background

Health plans should have the ability to exchange data instantly with other payers for care and payment coordination or transitions, and with providers to facilitate more efficient care. Health plans are in a unique position to provide enrollees a complete picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. To advance our commitment to interoperability, we are proposing new requirements to implement APIs for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, CHIP FFS at 42 CFR 457.730, Medicaid managed care at 42 CFR 438.242, CHIP managed care at 42 CFR 457.1233(d), and QHP issuers in FFEs, excluding SADPs at 45 CFR 156.221. These openly published APIs will permit third-party applications to retrieve standardized data for adjudicated claims, encounters with capitated and subcapitated providers, provider remittances, beneficiary cost-sharing, reports of lab test results (depending on whether the plan manages such data), provider directories, and, as applicable, preferred drug lists. We believe that these proposals are designed to empower patients by making sure that they can access their healthcare data, through the use of common technologies, without special effort and in an easily usable digital format. We also expect our API proposals to enable the enrollees in the plans that are subject to our proposal to share their healthcare data. By making claims data readily available and portable to the patient, these initiatives support moving our healthcare system away from a FFS payment system that pays for volume and toward a payment system that pays for value and quality by reducing duplication of services; adding efficiency to provider visits; and, facilitating identification of fraud, waste, and abuse.

B. Wage Estimates

To derive average costs, we used data from the U.S. Bureau of Labor Statistics' May 2017 National Occupational Employment and Wage Estimates for Direct Health and Medical Insurance Carriers (NAICS 524114) (https://www.bls.gov/​oes/​current/​naics5_​524114.htm). Table 1 presents the mean hourly wage, the cost of fringe benefits (calculated at 100 percent of salary), and the adjusted hourly wage.

Table 1—Occupation Titles and Wage Rates

Occupation title	Occupation code	Mean hourly wage (/hr)	Fringe benefit (/hr)	Adjusted hourly wage (/hr)
Administrators and Network Architects	15-1140	$46.35	$46.35	$92.70
Security Engineer	17-2199	50.66	50.66	101.32
Computer and Information Analysts	15-1120	41.98	41.98	83.96
General Operations Mgr	11-1021	72.51	72.51	145.02
Operations Research Analysts	15-2031	37.33	37.33	74.66
Software Developers, Applications	15-1132	45.57	45.57	91.14
Computer and Information Systems Managers	11-3021	71.10	71.10	142.20
General and Operations Mgr	11-1021	72.51	72.51	145.02
Designers	27-1020	29.32	29.32	58.64
Technical Writer	27-3042	32.68	32.68	65.36
Computer Systems Analysts	15-1121	41.59	41.59	83.18
Network and Computer Systems Administrators	15-1142	43.64	43.64	87.28

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

C. Information Collection Requirements (ICRs)

1. ICRs Regarding MMA File Requirements (42 CFR 423.910)

States submit data on files at least monthly to CMS to identify all dually eligible individuals, including full-benefit and partial-benefit dually eligible beneficiaries (that is, those who get Medicaid help with Medicare premiums, and often for cost-sharing). The file is called the MMA file, but is occasionally referred to as the “State Phasedown file.” Section 423.910(d) requires states to submit at least one MMA file each month. However, states have the option to submit multiple MMA files throughout the month (up to one per day). Most states submit at least weekly. This information collection activity is currently approved under OMB control number 0938-0958.

Ensuring information on dual eligibility status is accurate and up-to-date by increasing the frequency of federal-state data exchange is an important step toward interoperability. As a result, we are proposing to update the frequency requirements in 42 CFR 423.910(d) to require that starting April 1, 2022, all states submit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily would mean every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. We estimate it would take a computer systems analyst about 6 months (approximately 960 hours) to complete the systems updates necessary to process and submit the MMA data daily. As only 13 states currently submit MMA data daily, we estimate a one-time burden for 37 states and the District of Columbia complying with submission of daily MMA data at 3,034,406 (38 states (and DC) × 960 hours × 83.18 per hour for a computer system analyst). We will be revising the information collection request currently approved under 0938-0958 to include the requirements discussed in this section.

2. ICRs Regarding API Proposals (42 CFR 422.119, 431.60, and 438.242, and 45 CFR 156.221)

To promote our commitment to interoperability, we are proposing new requirements for APIs for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, CHIP FFS at 42 CFR 457.730, Medicaid managed care at 42 CFR 438.242, CHIP managed care at 42 CFR 457.1233(d), and QHP issuers in FFEs at 45 CFR 156.221. These openly published APIs will permit third-party applications to retrieve standardized data for adjudicated claims, encounters with capitated and subcapitated providers, provider remittances, beneficiary cost-sharing, reports of lab test results, provider directories, and preferred drug lists. To implement the new requirements for APIs, we estimate that plans and states will conduct three major work phases: Initial design; development and testing; and long-term support and maintenance.

In the initial design phase, we believe tasks would include: Determining available resources (personnel, hardware, cloud space, etc.); assessing whether to use in-house resources to facilitate an API connection or contract the work to a third party; convening a team to scope, build, test, and maintain the API; performing a data availability scan to determine any gaps between internal data models and the data required for the necessary FHIR resources; and, mitigating any gaps discovered in the available data.

During the development and testing phase, we believe plans and states would need to conduct the following: Map existing data to FHIR, which would constitute the bulk of the work required for implementation; allocate hardware for the necessary environments (development, testing, production); build a new FHIR server or leverage existing FHIR servers; determine the frequency and method by which internal data is populated on the FHIR server; build connections between the databases and FHIR server; perform capability and security testing; and vetting third-party applications.

After the completion of the API development, we believe that plans and states would need to conduct the following on an annual basis: Allocate resources to maintain the FHIR server, and perform capability and security testing.

The burden estimate related to the new requirements for APIs reflects the time and effort needed to collect the information described above and disclose this information. We estimate an initial set one-time costs associated with the implementing the API requirements. We presume that it will take administrators and network architects 1440 hours (at 92.70 an hour), security engineers 960 hours (at 101.32 an hour), computer and information analysts 480 hours (at 83.96 an hour), operations research analysts 960 hours (at 74.66 an hour), software developers 960 hours (at 91.14 an hour), computer and information systems managers 720 hours (at 142.20 an hour), general and operations managers 720 hours (at 145.02 an hour), designers 960 hours (at 58.64 an hour), technical writers 240 hours (at 65.36 an hour), and computer systems analysts 960 hours (at 83.18 an hour). We estimate a one-time burden assessment of 8,400 (1440hrs + 960hrs + 480hrs + 960hrs + 960hrs + 720hrs + 720hrs + 960hrs + 240hrs + 960hrs) hours per organization or state and a total of 3,898,000 (8,400hrs × 345 organizations) hours across all organizations or states. The one-time cost to implement API requirements is 789,356.00 per organization or state per implementation and 275,432,820 across all organizations or states to complete the task described above.

Once the API is established, we believe that there would be an annual cost for performing necessary capability and security testing, performing necessary upgrades and vetting of third-party applications. We presume that it would take administrators and network architects 180 hours (at 92.70 an hour), network and computer systems administrators 420 hours (at 87.28 an hour), security engineers 240 hours (at 101.32 an hour), computer and information analysts 60 hours (at 83.96 an hour), operations research analysts 120 hours (at 74.66 an hour), software developers 240 hours (at 91.14 an hour), computer and information systems managers 90 hours (at 142.20 an hour), general and operations managers 90 hours (at 145.02 an hour), designers 120 hours (at 58.64 an hour), technical writers 30 hours (at 65.36 an hour), and computer systems analysts 120 hours (at 83.96 an hour). We estimate the total annual burden to be 1,710 hours (180hrs + 420hrs + 60hrs + 120hrs + 240hrs + 90hrs + 120hrs + 30hrs + 120hrs) per organization or state, and 589,950 hours (1,710hrs × 345 organizations) across all organizations and states. Thus, the total annual cost to maintain the API requirements is 158,359.80 per organization or state and 54,634,131 across all organizations and states.

3. Summary of Information Collection Burdens

Table 2—Summary of Information Collection Burdens

Regulation Section(s)	OMB Control Number	Number of respondents	Number of responses	Burden per response (hours)	Total annual burden (hours)	Hourly labor cost of reporting ($)	Total labor cost of reporting ($)	Total capital/ maintenance costs ($)	Total cost ($)
§ 423.910	0938-0958 *	38	38	20	960	83.18	3,034,406	0	3,034,406
§ 422.119, § 431.60, § 457.730, § 438.242, § 457.1233 and § 156.221	0938-New	345	345	840	2,889,600		275,432,820	0	275,432,820
§ 422.119, § 431.60, § 457.730, § 438.242, § 457.1233, and § 156.221	0938-New	345	345	1,710	588,240		54,634,131	0	54,634,131
Total		344	344	2,570	3,478,800		333,101,357		333,101,357
* This currently approved ICR will be revised to include the burden discussed in this rule.

If you comment on these information collections, that is, reporting, recordkeeping or third-party disclosure requirements, please submit your comments electronically as specified in the ADDRESSES section of this proposed rule.

Comments must be received on/by May 3, 2019.

D. Exempt ICRs

1. Usual and Customary Business Practices

While the requirements under 42 CFR 482.24(d), 482.61(f) and 485.638 are subject to the PRA, we believe the burden associated with those requirements is exempt from the PRA in accordance with 5 CFR 1320.3(b)(2). We believe that the time, effort, and financial resources necessary to comply with these requirements would be incurred by persons during the normal course of their activities, and therefore, should be considered usual and customary business practices.

We are proposing to further expand CMS requirements for interoperability within the hospital, psychiatric hospital, and CAH CoPs by focusing on electronic patient event notifications. For hospitals, psychiatric hospitals, and CAHs, we are proposing similar requirements to revise the CoPs for Medicare- and Medicaid-participating hospitals, psychiatric hospitals, and CAHs by adding a new standard, “Electronic Notifications,” that would require hospitals, psychiatric hospitals, and CAHs to send electronic patient event notifications of a patient's admission, discharge, and/or transfer to another health care facility or to another community provider. We propose to limit this requirement to only those hospitals, psychiatric hospitals, and CAHs which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications, recognizing that not all Medicare- and Medicaid-participating hospitals and psychiatric hospitals have been eligible for past programs promoting adoption of EHR systems. We intend for these notifications to be required, at minimum, for inpatients admitted to, and discharged and/or transferred from the hospital, psychiatric hospital, or CAH. These requirements would help support coordination of a patient's care between settings or with services received through different care settings. These sections would require updates to discharge planning processes, which has been a long-standing industry practice. Electronic patient event notifications from these care settings, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings. These notifications are typically automated, electronic communications from the admitting or discharging provider to a receiving facility or to another community provider that alert the receiving provider that a patient is receiving, or has received, care at a different setting.

These notifications are based on “admission, discharge, and transfer” (ADT) messages, a standard message used within an EHR as the vehicle for communicating information about key changes in a patient's status as they are tracked by the system (more information about the current standard supporting these messages is available at http://www.hl7.org/​implement/​standards/​product_​brief.cfm?​product_​id=​144). As noted in the ISA published by ONC, this messaging standard has been widely adopted across the health care system (see https://www.healthit.gov/​isa/​sending-a-notification-a-patients-admission-discharge-andor-transfer-status-other-providers).

We note that hospitals have an existing responsibility under the CoPs at 42 CFR 482.43(d) to transfer or refer patients, along with necessary medical information, to appropriate facilities, agencies, or outpatient services, as needed, for follow-up or ancillary care. We wish to emphasize that the proposal in this proposed rule around patient event notifications is independent of the requirement regarding necessary medical information at 42 CFR 482.43(d). As these processes are already required, and as many EHR systems already have an electronic notification system in place, we do not anticipate a significant increase in burden on hospitals, psychiatric hospitals, and CAHs with the adoption of this proposal. However, we recognize that processes to implement this proposal, if finalized, might intersect with the hospital's discharge planning process. We note that nothing in this proposal would affect the hospital's responsibilities under 42 CFR 482.43(d). However, if this proposal is finalized, hospitals might wish to consider ways to fulfill these requirements in ways that reduce redundancy while still fully meeting the provisions of each. For instance, where appropriate, hospitals might seek to include required necessary medical information within the same message as a patient event notification.

XV. Response to Comments

Because of the large number of public comments we normally receive on Federal Register documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and, when we proceed with a subsequent document, we will respond to the comments in the preamble to that document.

XVI. Regulatory Impact Analysis

A. Statement of Need

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

States and CMS routinely exchange data on who is enrolled in Medicare, and which parties are liable for paying that beneficiary's Parts A and B premiums. These “buy-in” data exchanges support state, CMS, and SSA premium accounting, collections, and enrollment functions. We have become increasingly concerned about the limitations of monthly buy-in data exchanges with states. The relatively long lag in updating buy-in data means that the state is not able to terminate or activate buy-in coverage sooner, so the state or beneficiary may be paying premiums for longer than appropriate. We note that once the data catch up, states and CMS reconcile the premiums by recouping and re-billing, so premiums collected are ultimately accurate, but only with—an administratively burdensome process involving debits and payments between the beneficiary, state, CMS, SSA, and potentially providers. Daily buy-in data exchange would reduce this administrative burden. As described in detail in section VII. of this proposed rule, the changes to 42 CFR parts 406, 407, and 423 establish frequency requirements that necessitate all states to participate in daily exchange of buy-in data, and updates frequency requirements to require all states to participate in daily exchange of MMA file data, with CMS by April 1, 2022.

States submit data on files at least monthly to CMS to identify all dually eligible individuals, including full-benefit and partial-benefit dually eligible beneficiaries (that is, those who get Medicaid help with Medicare premiums, and often for cost-sharing). The MMA file was originally developed to meet the need to timely identify dually eligible beneficiaries for the then-new Medicare Part D prescription drug benefit. Over time, we used these files' data on dual eligibility status to support Part C capitation risk-adjustment, and most recently, feeding dual eligibility status to Part A and B eligibility and claims processing systems so providers, suppliers, and beneficiaries have accurate information on beneficiary cost-sharing obligations. As CMS now utilizes MMA data on dual eligibility status in systems supporting all four parts of the Medicare program, it is becoming even more essential that dual eligibility status is accurate and up-to-date. Dual eligibility status can change at any time in a month. Waiting up to a month for status updates can negatively impact access to the correct level of benefit at the correct level of payment.

B. Overall Impact

We have examined the impacts of this proposed rule as required by Executive Order 12866 on Regulatory Planning and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96-354), section 1102(b) of the Social Security Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995; Pub. L. 104-4), Executive Order 13132 on Federalism (August 4, 1999), the Congressional Review Act (5 U.S.C. 804(2)), and Executive Order 13771 on Reducing Regulation and Controlling Regulatory Costs (January 30, 2017).

Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Section 3(f) of Executive Order 12866 defines a “significant regulatory action” as an action that is likely to result in a rule: (1) Having an annual effect on the economy of $100 million or more in any 1 year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local or tribal governments or communities (also referred to as “economically significant”); (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raising novel legal or policy issues arising out of legal mandates, the President's priorities, or the principles set forth in the Executive Order.

A regulatory impact analysis (RIA) must be prepared for major rules with economically significant effects ($100 million or more in any 1 year). We estimate that this rulemaking is “economically significant” as measured by the $100 million threshold, and hence also a major rule under the Congressional Review Act. Accordingly, we have prepared an RIA that to the best of our ability presents the costs and benefits of the rulemaking. Table 3 summarizes the estimated costs presented in the Collection of Information section of this proposed rule. We note that estimates below do not account for enrollment growth or higher costs associated with medical care. This is because the cost of requirements to implement patient access through APIs and for states to comply with data exchange requirements are not impacted by enrollment growth or higher costs associated with medical care. Per OMB guidelines, the projected estimates for future years do not take into account ordinary inflation.

Table 3—Estimated Aggregate Costs to the Health Care Sector by Provision

[CYs 2020 through 2024]

Provision	Regulation section(s)	Calendar year ($ in millions)					Total CY 2020-2024 ($ in millions) *
		2020	2021	2022	2023	2024
Requirements to Patient Access Through APIs	§ 422.119, § 431.60, § 438.242, § 457.730, § 457.1233, § 156.221	275.4	54.7	54.7	54.7	54.7	494.0
Dual Eligible Care Coordination	§ 406.26, § 407.40, § 423.910	0.7	2.2	2.2	1.2	0	6.3
Total Cost		276.1	56.9	56.9	55.9	54.7	500.3
* Total may not equal sum of parts due to rounding.

Allocation of Cost Impact by Program: As stated in the Collection of Information Section of this proposed rule, cost estimates have been aggregated at the parent organization level because we believe that an organization that offers commercial, Medicare, Medicaid, and CHIP products would create one system that would be used by all “plans” it offers. We note that due to the implementation of APIs across multiple business lines, there is no straightforward method to immediately estimate Parent Organization expenditures on how much of the cost is born by each program.

Preliminary Estimates: Later in this RIA section, we provide several detailed estimates of cost by program where we account for Federal matching for Medicaid and payments by the Trust Fund for Medicare Advantage Organizations. However, these estimates are approximate as explained in detail below. Therefore, the purpose of this preliminary estimate section, is to observe that the costs of this proposed rule are negligible relative to the costs of the various programs it impacts.

For purposes of clarification we use the metric of “costs per enrollee.” The “costs per enrollee” whether for Medicaid or Medicare, does not refer to actual costs paid by the enrollee but rather is a metric, it is the quotient of total program expenditures divided by total enrollees. The cost per enrollee metric facilitates comparison of costs. Since program expenditures for both Medicaid and MA are typically hundreds of millions (or billions) of dollars, concepts like negligibility do not have intuitive meaning. Contrastively, the costs per enrollee are more manageable and understandable. The 2018 Medicare Trust Fund ^[60] states that costs per enrollee are projected to be roughly $12,000-$14,000 for contract years 2020-2023 (Table IV.C3). The costs per enrollee for the Medicaid program are similarly several thousand dollars. We estimate 169 million enrollees will be affected by these provisions since. Currently there are 76, 66,^[61] 20,^[62] and 7² million enrollees in the commercial, Medicaid, MA and separate CHIP programs respectively.

The total first year (implementation) cost per enrollee is $1.63 ($276.1 million cost (Table 3) divided by 169 million enrollees); maintenance cost per enrollee in the following years are 34 cents ($56.9 million total cost (Table 3) divided by 169 million enrollees). The assertion that $1.63 and $0.34 is negligible compared to the $12,000-$14,000 cost per enrollee for the MA program or the several thousand-dollar cost per enrollee for the Medicaid program has intuitive appeal. However, these are very rough preliminary estimates. In the remainder of this RIA, we provide, subject to the limitations noted, more detailed impact by program.

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

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

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

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

Medicaid: For the year for which these MLR files provide data, 2016, about 70 percent of Medicaid enrollees were enrolled in Medicaid Managed Care.^[66] Thus although the MLR files omit State Agencies, we believe that the 70 percent Medicaid enrollees enrolled in Medicaid Managed Care provides a good approximation.

Finally, as noted in the section “Preliminary Estimates”, independent of these omissions, the average cost per enrollee is capped at $1.63 and $0.34 in first and follow up years.

Best Estimates of Impact per Program: We present two methods to obtain an estimate of cost by program both for purposes of assessing impact on small entities, as well as for purposes of assessing impacts of the provision on the Federal government, programs, and enrollees: We could assume costs proportional to current enrollment, or alternatively, we could assume costs proportional to total premium. For purposes of analyzing impact on small entities and impacts of the provision on the Federal Government, programs, and enrollees we are using the method of assuming costs proportional to total premium (the method of assuming costs proportional to current enrollment will be used below to assess impact on transfers to enrollees).

Among issuers with products in both Commercial and MA or Commercial and Medicaid, the 2016 CMS MLR files show $370 billion reported in premium for commercial plans, $157 billion reported for MA, and $113 billion reported for Medicaid. Consequently, the proportion of interoperability cost for each of the programs is 57.81 percent (370/(370+157+113)), 24.53 percent (157/(370+157+113)), and 17.66 percent (113/(370+157+113)) for Commercial, MA, and Medicaid respectively.

Using these proportions, Table 4 breaks out the top row in Table 3, the total cost by year of implementing and maintaining the API, by program.

Table 4—API Costs (in Millions) by Year and Program

Year	2020	2021	2022	2023	2024	Total
Full Implementation and Maintenance costs (Table 3, Row 1)	275.4	54.7	54.7	54.7	54.7	494.0
Commercial Programs (57.81%)	159.2	31.6	31.6	31.6	31.6	285.6
Medicaid and CHIP programs (17.66%)	48.6	9.7	9.7	9.7	9.7	87.2
Medicare Advantage Programs (24.53%)	67.6	13.4	13.4	13.4	13.4	121.2

Methods of Bearing Cost by Program: Commercial plans have the options to deal with increased costs by either temporarily absorbing them (for purposes of market competitiveness), increasing premiums to enrollees, or reducing benefits.

To the extent that issuers increase premiums for plans in the FFE, there would be Federal premium tax credit (PTC) impacts. However, the PTC formula is highly individual-specific, that is, it is the result of the relationship between the premium of the second lowest-cost silver plan applicable to a specific consumer in a specific month, the cost of the actual plan purchased by that consumer for that month, and that consumer's income. Consequently, it would not be possible to estimate the magnitude of the PTC impact with a reliable degree of accuracy, since we cannot predict: (1) What proportion of costs would be passed on to enrollees as increased premiums; (2) to what extent commercial issuers may recoup investment costs through raising premiums on the second-lowest cost silver plans or on other plans; and (3) whether or in what ways such premium increases may impact the PTC calculation or eligibility with respect to various consumers,

To deal with this uncertainty, we list the possible Federal PTC impacts as a qualitative impact. Most importantly, we assume the unlikely worst case scenario that all cost is passed on as premium to the enrollee without subsidization; we then show that the net impact per enrollee per month is extremely small (see Table 7).

Medicare Advantage: Medicare Advantage Organizations (MAOs) pass increased costs back to the Trust Fund. For those (most) MAOs whose bid amount is below the benchmark, the Trust Fund provides total expenditures to the MAOs consisting of: (1) Full payment of the bid amount; and (2) the rebate, a portion of the difference between the benchmark and the bid amount. Since MAOs are increasing their bid amounts to reflect the costs of this proposed rule, it follows that the rebate, equaling the difference between the benchmark and bid, is decreased, resulting in less rebates paid to the MAOs. Based on our historical and projected experience, the rebate is estimated as 34 percent of the difference between benchmark and bid. Thus, although the Trust Fund pays the bid in full, nevertheless, 66 percent of the increased bid costs arising from this proposed rule, are reduced from the rebates. The MAO in its submitted bid, can address this reduction of rebates by either: (1) Temporarily, for marketing purposes, absorbing the loss, and reducing its profit margin; (2) reduce the additional benefits it provides the enrollee paid for by the rebate; or (3) raise enrollee premiums.

Medicaid: State Medicaid agencies may be allowed to allocate the costs of state information retrieval systems between the costs attributable to design, development, installation, or enhancement of the system—at a 90 percent federal match—and for ongoing operations of the system—at a 75 percent federal match.

For Medicaid Managed Care entities, we assume an MCO, PIHP, and PAHP cost for implementing the open API provisions would be built into the capitation rates and matched at the State's medical assistance match rate. For purposes of these estimates we use the weighted FMAP, 58.44.

CHIP: Most states operate Medicaid and CHIP from the same state agency. One state is a notable exception in that it has a separate Medicaid and CHIP agency. The federal government pays an enhanced federal medical assistance percentage (EFMAP) to states for all costs associated with CHIP, including systems costs (this is unlike Medicaid where there are different FMAPs for different types of costs). For federal FY 2019 the EFMAPs will range from 88 to 100 percent. For federal FY 2020 the EFMAPs will range from approximately 76.5 to 93 percent. After federal FY 2020, the EFMAPs will range from approximately 65 to 81.5 percent. Since the CHIP program Federal rebate ranges include the 90 percent and 75 percent federal matching proportions of the Medicaid program, we are applying the 90 percent and 75 percent from Medicaid to the CHIP programs. Since the CHIP program is small relative to the Medicaid program, we believe this approach reasonable.

Table 5 uses these proportions to estimate the impact of the API on the Federal Government. For example, the $28.4 million cost to the Federal government for Medicaid/CHIP for 2020, the implementation year of the API, is obtained by multiplying the State Agency Medical Assistance average match rate to Medicaid Managed Care Plans, 58.44%, by the $48.6 million total cost to Medicaid for 2020 listed in Table 4.

Table 5—Costs (in Millions) Incurred by Federal Government by Program and Year

Year	2020	2021	2022	2023	2024	Total
For Commercial Programs	0.0	0.0	0.0	0.0	0.0	0.0
For Medicaid/CHIP programs (58.44%, average State Agency medical assistance match rate)	28.4	5.6	5.6	5.6	5.6	51.0
For Medicare/Advantage Programs (The bid increase in spending due to this proposed rule reduces the difference between the benchmark and the bid. The Trust Fund incurs 34% of this reduction while plans incur 66% of this reduction in the form of smaller rebates than would have been received had the cost of this provision not been included in the bid)	23.0	4.6	4.6	4.6	4.6	41.2

By taking the difference between the respective cells in Tables 4 and 5 we obtain the remaining costs for the API. To this amount must be added the coordination cost for the dual eligibles (row 2 of Table 3). For example, Medicaid/CHIP has a remaining cost of $20.3 million ($48.6 million total cost for 2020 (Table 4)−$28.4 million matched by Medicaid State Agencies (Table 5) + $0.7 million total cost for coordination of dual eligibles (Table 3) * 17.66 percent (proportion of total costs incurred by Medicaid/CHIP (Table 4)). (There are minor differences due to rounding). The results are summarized in Table 6.

Table 6—Remaining Costs (in Millions) for API by Year and Program

	2020	2021	2022	2023	2024	Total
Commercial	159.6	32.9	32.9	32.3	31.6	289.2
Medicaid/Chip	20.3	4.4	4.4	4.2	4.0	37.4
Medicare Advantage	44.8	9.4	9.4	9.1	8.8	81.5

The further discussion of bearing these costs, is clarified, if we reformulate the costs in terms of costs per enrollee. To do this we use enrollments by program. For commercial enrollment we use the 2016 MLR data, for MA enrollment we use the August 2018 data, and for Medicaid and CHIP we use September 2018 data. These enrollment numbers are 76, 66,^[67] 20,^[68] and 7^[4] million enrollees in the commercial, Medicaid, MA and separate CHIP programs respectively. Thus, for purposes of this analysis, we use a total of 169 million (76+67+20+6) enrollees in all programs. Table 7 presents cost per enrollee by program and year. For example, there is a 28-cent cost to Medicaid/CHIP state agencies in 2020 (20.3 million remaining cost (Table 6) divided by 73 million (66 million Medicaid + 7 million CHIP)).^[69]

Table 7—Cost per Enrollee per Year (Dollars and Cents) by Program

	Current enrollment (millions) by program	2020	2021	2022	2023	2024	Total
Commercial	76	2.10	0.43	0.43	0.42	0.42	3.81
Medicaid/Chip	73	0.28	0.06	0.06	0.06	0.05	0.51
Medicare Advantage	20	2.24	0.47	0.47	0.46	0.44	4.08

Using Table 7 we can assess the approximate impact of the remaining cost.

Commercial: As pointed out above, the Commercial program has the options of absorbing costs or passing costs to enrollees either in the form of premiums or reduced benefits. The cost per enrollee in 2021 through 2024 is under a half dollar and could comfortably be passed on to enrollees. For purposes of market competitiveness, it is very likely that some of the 2020 cost of $2.10 per enrollee will be absorbed by each QHP in an FFE.

Medicaid: Medicaid state agencies are adding a cost under 30 cents per enrollee for 2020-2024. Since total costs per enrollee for the Medicaid program are several thousand dollars we do not believe this additional 30 cents per enrollee cost to be a significant burden.

Medicare Advantage: Medicare Advantage plans in their June-submitted bids would address the reduced rebates (arising from increased bid costs due to the increased costs of this proposed 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 choose 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 7).

Table 8 summarizes these methods of bearing the remaining costs.

Table 8—How Programs Would Defray Remaining Costs

Commercial	Commercial plans have the options of absorbing costs (for example, in 2020 for reasons of market competitiveness), increasing premiums to enrollees, or reducing benefits.
Medicaid/CHIP	Medicaid Managed Care plan would bear the cost (under a dime per enrollee) which is negligible compared to current costs per enrollee.
Medicare Advantage (MA)	MA plans in their June-submitted bids would address the reduced rebates (arising from increased bid costs due to the increased costs of this proposed 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 8).

C. Anticipated Effects

The RFA, as amended, requires agencies to analyze options for regulatory relief of small businesses, if a rule has a significant impact on a substantial number of small entities. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small governmental jurisdictions.

This proposed rule affects (1) Commercial Issuers (2) MA plans, including those that are also Part D sponsors of MA-PD plans, as well as (3) Medicaid MCOs with a minimum threshold for small business size of $38.5 million (https://www.sba.gov/​federal-contracting/​contracting-guide/​size-standards).

Assessment of impact is complicated by the fact that costs have been aggregated at the Parent Organization level. A typical Parent Organization might have products with the commercial, MA, or Medicaid/CHIP programs. We have no way of directly assessing the size of Parent Organizations. Therefore, as a proxy, we analyze each program separately.

Medicare Advantage: We first assess the impact on MA plans. To clarify the flow of payments between these entities and the federal government, we note that MAOs submit proposed plan designs and estimates of the amount of revenue necessary to cover the cost of those plan designs (called bids) by the first Monday in June of the year preceding the coverage year. Regulations governing this process are in 42 CFR part 422, subpart F. These bids must be broken down in the following:

(1) The revenue requirements for providing Medicare Part A and Part B benefits with actuarially equivalent cost sharing (this is the “basic benefit bid”);

(2) The revenue requirements for providing supplemental benefits; and

(3) A Part D bid consistent with Part D regulations in 42 CFR part 423.

These bids project payments to hospitals, providers and staff, as well as the cost of administration and profits. Because the API requirements proposed in this rule will apply to every MA plan and each MA plan must furnish at least the Medicare Part A and Part B benefits, the cost of the API will be built into the administrative component of the basic benefit bid. These bids in turn determine one component of the payments of the Medicare Trust Fund to the MAOs who reimburse providers and other stakeholders for their services. A second component of the Trust Fund payment to MAOs are the rebates, which are a portion of the difference between the basic benefit bid compared to an administratively-set benchmark for the MA plan's service area (currently, based on our past and projected experience, rebates are approximately 66 percent). Benchmarks are based on a formula using an estimate of the Medicare FFE per capita cost for the geographic area, which are adjusted to reflect the per capita cost of each county in the United States and its territories. Payments from the Medicare Trust Funds for monthly capitation are capped at the benchmark; for basic benefit bids under the benchmark, a portion, currently 66 percent, of the difference between the bid and benchmark is made available to the MA organization to either: (1) Pay the premium for supplemental benefits; (2) include reductions in cost sharing; (3) provide additional non-Medicare covered benefits; or (4) provide buy-downs of Part B or Part D premiums. Basic benefit bids that are at or above the benchmark receive payment from the Trust Funds of the benchmark amount, with any excess charged to the enrollee as a premium.

MAOs are made aware of the benchmark through the annual CMS publication, “Medicare Advantage Capitation Rates and Medicare Advantage and Part D Payment Policies and Final Call Letter,” which, consistent with section 1853 of the Act, is released prior to MAO submission of bids. Therefore, the bids of most MAOs are below the benchmark and consequently most MAOs receive from the Trust Fund a total expenditure equaling payment for the bid plus the rebate.

Because of these proposed API provisions, MAOs would be raising the June-submitted bid amount to reflect additional costs. While the Trust Fund pays these bid amounts in full, the rebate goes down: That is, since the bid amount goes up, the rebate, equaling the difference between the benchmark and bid, decreases and results in less rebate payment to the MAO. The MAO has several options of dealing with these increased bid costs and reduced rebates: The MAO might decide to: (1) Temporarily absorb the loss by reducing its profit margin (so as to reduce the bid amount and thereby increase the rebates); (2) reduce additional benefits paid to the enrollee from the rebates; or (3) raise enrollee premiums so as to compensate for the reduction of enrollee premium that would have happened if the bid had not been increased (note: For marketing purposes, many plans operate at zero premium, and we do not consider this a likely possibility). In this RIA we have referred to options (2) and (3) reduction of additional benefits and raising of enrollee premiums as “passing the costs to the enrollee” the intent being that the “effect” of reduced rebates is less additional benefits or higher enrollee premiums than would have happened had the cost of the provisions of this proposed rule not been included in the bid.

There are various types of Medicare health plans, including MA HMOs, POS plans, and PPOs; Demonstration plans; Cost Plans; Prescription Drug Plans (PDP); and Programs of All-Inclusive Care for the Elderly (PACE) organizations. This proposed rule affects MA HMOs, MA POS plans, and MA PPOs but does not affect Cost Plans, Prescription Drug Plans nor PACE organizations.

There are a variety of ways to assess whether MAOs meet the $38.5 million threshold for small businesses. The assessment can be done by examining net worth, net income, cash flow from operations and projected claims as indicated in their bids. Using projected monetary requirements and projected enrollment for 2018 from submitted bids, 32 percent of the MAOs fell below the $38.5 million threshold for small businesses. Additionally, an analysis of 2016 data, the most recent year for which we have actual data on MAO net worth, shows that 33 percent of all MAOs fall below the minimum threshold for small businesses.

Medicaid: We next assess the impact on Medicaid MCOs. The Society of Actuaries (SOA) published “Medicaid Managed Care Organizations: Considerations in Calculating Margin in Rate Setting” in 2017.^[70] The report provided an MS Excel spreadsheet of Medicaid MCOs using data from 2013-2015. That report noted that “[n]ot every state requires Medicaid MCOs to submit Annual Statements, so not every MCO is represented. MCOs in California and Arizona are shown with a limited set of metrics, based on what was available and provided by HMA [Health Management Associates].” Of the 231 MCOs listed in the 2015 worksheet, 196 provided data that are adequate to identify MCOs with annual “revenue” less than $38.5 million. (NOTE: Since total revenue is reported at the company level, which includes revenue from non-Medicaid sources, we used “direct premium written” in the Medicaid portion of the worksheet as a proxy for annual revenue on the individual plan level.) Of the 196 Medicaid MCOs, only 15 MCOs or 7.7 percent had “revenue” less than $38.5 million in 2015.

Commercial: Based on the 2016 CMS MLR data, approximately 85 out of 494, or 17 percent of companies (that either had only commercial business, or had commercial plus Medicare and/or Medicaid business) had total premium revenue of less than $38,500,000. In other words, for MA, Medicaid, and Commercial, a significant number of small plans are affected. The RFA requires us to assess whether the rule has a significant impact on the plans which we do next.

If a proposed rule has a substantial impact on a substantial number of small entities, the proposed rule must discuss steps taken, including alternatives, to minimize burden on small entities. While a significant number (more than 5 percent) of not-for-profit organizations and small businesses are affected by this final rule, the impact is not significant. To assess impact, we use the data in Table 3 of this section which shows that the total raw (not discounted) net effect of this final rule over 5 years is 500 million dollars.

Medicare Advantage: We first assess impact on MA plans. Comparing the 500 million dollar number to the total monetary amounts projected to be needed just for 2018, the most recent year on which we have finalized plan submitted bid data (and which is expected to be less than the need in future years including 2019), we find that that the impact of this proposed rule is significantly below the 3 percent-5 percent threshold for significant impact for MA plans.

Medicaid: We next assess impact on Medicaid Managed Care plans. The total projected capitation payment and premiums for 2019 is projected to be $337.6 billion.^[71] Hence, the total cost of this proposed rule over 5 years, $500 million, is significantly below the 3 percent-5 percent threshold for significant impact to Medicaid Managed Care plans.

Commercial: As discussed prior to Table 4, based on data in the public, CMS MLR files, commercial plans had a revenue of at least $370 billion in 2016. We say at least, because this only includes organizations with either: (1) Only commercial; (2) both commercial and MA; or (3) both commercial and Medicaid. Had all organizations been included in the CMS MLR files (including those that only offer MA and/or Medicaid) the amount would be greater than $370 billion. Therefore, the aggregate raw cost of this proposed rule over 5 years, $500 million, is significantly below the 3 percent-5 percent threshold for significant impact to Commercial plans.

We conclude, that although a significant number of small plans in all programs are affected by this rule, this impact is not significant.

Besides the fact that the impact is not significant, we are not concerned that small plans will have a burden in implementing these requirements since as indicated above, without considering any rebates or Federal matching funds, the cost of this provision is $1.63 per enrollee per year in the first implementation year, and $0.34 in the following years for maintenance, these per enrollee costs are negligible when compared to the typical costs per enrollee (several thousand dollars).

Consequently, the Secretary has determined that this proposed rule will not have a significant economic impact on a substantial number of small entities and the requirements of the RFA have been met. Please see our detailed analysis of apportionment of costs per program and plan in Tables 4 through 8 and section XVI.H. of this proposed rule for further details.

In addition, section 1102(b) of the Act requires CMS to prepare an RIA if a rule may have a significant impact on the operations of a substantial number of small rural hospitals. This analysis must conform to the provisions of section 603 of the RFA. For purposes of section 1102(b) of the Act, we define a small rural hospital as a hospital that is located outside a Metropolitan Statistical Area and has fewer than 100 beds. We are not preparing an analysis for section 1102(b) of the Act because we have determined, and the Secretary certifies, that this proposed rule would not have a significant impact on the operations of a substantial number of small rural hospitals.

Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) (Pub. L. 104-04, enacted March 22, 1995) also requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any 1 year of $100 million in 1995 dollars, updated annually for inflation. In 2018, that is approximately $150 million. The apportionment of total cost between the MA, Medicaid, Commercial and Chip programs is detailed in both section XVI.B. (Tables 4 through 8) and section XVI.H of this RIA showing that costs for both enrollees and the states are small. Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on state and local governments, preempts state law, or otherwise has Federalism implications. This rule will not have a substantial direct effect on state or local governments, preempt state law, or otherwise have a Federalism implication. Therefore, the requirements of Executive Order 13132 are not applicable.

If regulations impose administrative costs, such as the time needed to read and interpret this proposed rule, we should estimate the cost associated with regulatory review. There are currently 288 organizations and 56 states and territories. We assume each organization will have one designated staff member who will read the entire rule.

Using the wage information from the BLS for medical and health service managers (Code 11-9111), we estimate that the cost of reviewing this rule is $139.14 per hour, including overhead and fringe benefits (https://www.bls.gov/​oes/​current/​naics5_​524114.htm). Assuming an average reading speed, we estimate that it would take approximately 6 hours for each person to review this proposed rule. For each plan and state that reviews the rule, the estimated cost is $834.84 (6 hours × $139.14). Therefore, we estimate that the total cost of reviewing this regulation is $288,020 ($834.84 × 345 reviewers).

1. Requirements for Patient Access Through APIs

To promote our commitment to interoperability, we are proposing new requirements in section III. of this proposed rule for MA organizations at 42 CFR 422.119, Medicaid FFS at 42 CFR 431.60, Medicaid managed care at 42 CFR 438.242, CHIP FFS at 42 CFR 457.730, CHIP managed care at 42 CFR 457.1233, and QHP issuers, excluding SADP issuers, that offer plans through the FFE at 45 CFR 156.221 to implement open APIs for making certain data available to enrollees and the public. These openly published APIs will permit third-party applications to retrieve standardized data for adjudicated claims, encounters with capitated and subcapitated providers, provider remittances, beneficiary cost-sharing, reports of lab test results, provider directories, and preferred drug lists. We believe that these proposals are designed to empower patients by mandating that entities subject to our API proposal take steps—by implementing the API—to enable enrollees to have access to their data in a usable digital format and have (potentially) easier means to share that data. By making these data readily available and portable to the patient, these initiatives support moving our healthcare system away from a FFS payment system that pays for volume and toward a payment system that pays for value and quality by reducing duplication of services, adding efficiency to provider visits, and facilitating identification of fraud, waste, and abuse.

To estimate the number of impacted issuers, we reviewed parent organizations of health plans across MA, Medicaid MCOs, and QHPs in FFEs to remove organizations that would not be subject to our proposal, such as SADPs; transportation plans and brokers such as non-emergency medical transportation (NEMTs) brokers; PACE; visiting nurse and home health care organizations; senior organizations such as Area Agencies on Aging; and other organizations such as community action programs. After removing these organizations, we then reviewed the remaining names of parent organizations and health plans in the National Association of Insurance Commissioners (NAIC) Consumer Information Support (CIS) system to determine the legal name of the entity and whether the entity was registered with the NAIC. We also used the 2018 NAIC Listing of Companies to determine whether various health plans had associated parent organizations using the NAIC's Group coding and numbering system. If the health plan or parent organization did not appear in the NAIC CIS or in the 2018 NAIC Listing of Companies, we then reviewed the name of the entity in the Securities and Exchange online Edgar system to locate the entity's Form 10-K filing, which includes an Exhibit (Exhibit 21) that requires the entity to list its subsidiaries. If the health plan or organization did not appear in these online systems or listings, an online internet search using Google search engine was conducted. After review, we have determined that 288 issuers and 56 states, territories, and U.S. commonwealths, which operate FFS programs, will be subject to the API provisions for Medicare, Medicaid, and the Commercial market. To this we add the one state that operates its CHIP and Medicaid separately. Thus, we have a total of 345 parent entities (288+56+1). We note that although 42 states have some lower-income children in an expansion of Medicaid, and some higher-income children or pregnant women in a separate CHIP, all but one of these programs are operated out of the same agency. Although the CHIP programs may be distinct, we believe they will use the same infrastructure built for Medicaid. Thus, the addition of 1 parent entity for CHIP is reasonable and plausible.

As noted in section XIII.C.3. of this proposed rule, to implement the new requirements for APIs, we estimate that organizations and states would conduct three major work phases: Initial design; development and testing; and long-term support and maintenance. (For a detailed description of these phases, see section XIII.C.3. of this proposed rule.)

As part of our research into the regulatory impact, we reviewed a sample of health plan organizations offering MA plans to determine whether any currently offer patient portal functionality with the MA plan. If yes, we reviewed whether they offered the opportunity to connect to Medicare's Blue Button 2.0. Health plan organizations offering MA plans were identified from June 2018 data and statistics compiled at https://www.cms.gov/​Research-Statistics-Data-and-Systems/​Statistics-Trends-and-Reports/​MCRAdvPartDEnrolData/​index.html. We initially reviewed the functionality offered by three organizations which together enroll over half of MA members through review of publicly-available information such as press releases and website informational materials. We found from this review that these organizations not only offered patient portals primarily focused on claims and user-entered data on their website, but that all three also offered enrollees the opportunity to connect to Blue Button. We then identified a selection of other health plan organizations at random and conducted the same evaluation. Results indicate that the majority of the health plan organizations we reviewed offer patients a way to access claims data and other information via their websites and sometimes via applications. Regarding Blue Button access, results were either negative or unclear.

We also cross-referenced health plan organizations offering MA plans with health plan organizations that offer plans in the Federal Employee Health Benefit (FEHB) program because a percentage of those organizations offer plans with patient portal access and Blue Button functionality. The FEHB, administered by the Office of Personnel Management (OPM), reported in 2014 that 90 percent of its participating plans offered enrollees access to a personal health record on the organization's website. In addition, OPM reported that over half of the FEHB participating plans expected to offer Blue Button functionality by January 1, 2016. We sought to learn whether there was any overlap between these two lists of organizations to gauge whether additional organizations may already have the capability to offer either patient portals or Blue Button, albeit in a different business arm, as having internal capability may assuage some of the cost of building out a new API to support patient access to claims data. While we found significant overlap between UnitedHealthcare and the Blue Cross Blue Shield Affiliates, we also were able to identify other organizations that offer both MA plans and plans included in the FEHB. While not definitive, this data allows us to draw the conclusion that a number of health plan organizations have the technology in place to offer patient portals to MA enrollees and, further, also have the ability to offer MA enrollees Blue Button functionality.

As detailed in the Collection of Information section of this proposed rule and summarized in Table 3, given the current state of interoperability, we estimate the burden related to the new requirements for APIs to have an initial set one-time costs of $798,356 per implementation or an aggregate cost of $275,432,820 ($798,356 × 345 parent entities). For a detailed discussion of the one-time costs associated with implementing the API requirements we refer readers to section XIII.C.3. of this proposed rule. Once the API is established we believe that there will be an annual cost for performing necessary capability and security testing, performing necessary upgrades and vetting of third party applications. We estimate the burden related to the requirements for APIs to have an annual cost of $158,406 per implementation or an aggregate cost of $54,650,070 (345 parent entities × $158,406). For a detailed discussion of the annual costs associated with implementing the API requirements, we refer readers to section XIII.C.3. of this proposed rule.

We are committed to fulfilling our role in promoting interoperability, putting patients first and ensuring they have access to their health care data. We recognize that there are significant opportunities to modernize access to patient data and its ability to share across the health ecosystem. We realize the importance of interoperability and the capability for health information systems and software applications to communicate, exchange, and interpret data in a usable and readable format. Although allowing access to healthcare data through pdf and text format is vital, it limits the utility of the data, and its ability to be easily accessed and shared. Additionally, we realize that moving to a system in which patients have access to their healthcare data will ultimately empower them to make informed decisions about their healthcare. Our proposals here do not go as far as our goals for how patients will be ultimately empowered but take steps in that direction.

We note that the federal government has spent over $35 billion under the EHR Incentive Programs ^[72] to incentivize the adoption of EHR systems; however, despite the fact that 78 percent of physicians and 96 percent of hospitals now use an EHR system,^[73] progress on system-wide data sharing has been limited. Previous attempts to advance interoperability have made incremental progress but have failed to align the necessary stakeholders to drive momentum in a single direction. Recently, the Administration launched the MyHealthEData initiative.^[74] This government-wide initiative aims to empower patients by ensuring that they have full access to their own healthcare data and the ability to decide how their data will be used, while keeping that information safe and secure. MyHealthEData aims to break down the barriers that prevent patients from gaining electronic access to their healthcare data and allow them to access that data from the device or application of their choice that will connect to a plan's API, empowering patients and taking a critical step toward interoperability and patient data exchange.

Health plans should have the ability to exchange data instantly with other payers for care coordination or transitions, and with providers to facilitate more efficient care. Health plans are in a unique position to provide enrollees a complete picture of their claims and encounter data, allowing patients to piece together their own information that might otherwise be lost in disparate systems. We are committed to solving the issue of interoperability and achieving complete patient access in the U.S. health care system and are taking an active approach using all available policy levers and authorities available to move all participants in the health care market toward interoperability and the secure exchange of health care data. The modern internet app economy thrives on an open API software environment. Part of the health care API evolution is incorporating many of the current protocols from leading standards development organizations with the newer Fast Healthcare Interoperability Resources (FHIR) web developer-friendly way of representing clinical data.

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

We routinely exchange data with states on who is enrolled in Medicare, and which parties are liable for paying that beneficiary's Part A and B premiums. These buy-in data exchanges support state, CMS, and SSA premium accounting, collections, and enrollment functions. CMS subregulatory guidance, specifically Chapter 3 of the State Buy-in Manual, specifies that states should exchange buy-in data with CMS at least monthly, but provides the option for states to exchange buy-in data with CMS daily or weekly. Likewise, states can choose to receive the CMS response data on a file daily or monthly. Currently, 31 states and the District of Columbia now submit buy-in data to CMS, daily and 28 states and the District of Columbia receive buy-in response files from CMS daily.

We are proposing to establish the frequency requirements in the regulation itself to require all states to participate in daily exchange of buy-in data to CMS, with “daily” meaning every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. We propose that states would be required to begin participating in daily exchange of buy-in data with CMS by April 1, 2022.

We estimate the cost for states to comply with these new requirements to be one-time costs associated with state systems updates, totaling $3,273,965 across impacted states and over the 3-year implementation period. We first identified those states already exchanging data daily, and then determined there are 19 states that we anticipate will need to make a systems change to send buy-in data to CMS daily, and 22 states that we anticipate will need to make a systems change to receive buy-in data from CMS daily. We then estimated that each change would involve 960 hours of computer analyst time at $83.18 per hour, for a one-time cost to be a little less than $80,000 per state, per change. So, a state that needs to make systems updates to both send buy-in data daily, and receive buy-in data daily would have a one-time cost of just under $160,000. We did not estimate any savings related to exchanging buy-in data with greater frequency, as data lags only delay when states are billed for premium costs; delays do not impact the effective date and total costs. While we did not estimate premium savings (since premium collection is ultimately correct), we anticipate that states may experience longer term reduction in administrative burden of making those corrections.

States submit data on MMA files at least monthly to CMS to identify all dually eligible individuals, including full-benefit and partial-benefit dually eligible beneficiaries (that is, those who get Medicaid help with Medicare premiums, and often cost-sharing). While 42 CFR 423.910(d) requires states to submit at least one MMA file each month, states have the option to submit multiple MMA files throughout the month (up to one per day). As CMS now utilizes MMA data on dual eligibility status in systems supporting all four parts of the Medicare program, it is becoming even more essential that dual eligibility status is accurate and up-to-date.

We are proposing to update the frequency requirements in 42 CFR 423.910(d) to require that starting April 1, 2022, all states submit the required MMA file data to CMS daily, and to make conforming edits to 42 CFR 423.910(b)(1). Daily would mean every business day, but that if no new transactions are available to transmit, data would not need to be submitted on a given business day. We estimate the cost for states to comply with these new requirements to be a one-time cost associated with state systems updates, totaling $3,034,406 across impacted states, and across the 3 years which states have to implement the requirement. There are 37 states and the District of Columbia that we anticipate will need to make a systems change to send MMA data to CMS daily. We estimate the one-time cost for a state to be a little less than $80,000 for this MMA data systems change. For a detailed discussion of the costs associated with these requirements we refer readers to section XIII.C. of this proposed rule. We did not estimate any savings related to submitting MMA files daily, as data lags only delay when data are sent; delays do not impact the effective date and total costs. While we did not estimate savings, we anticipate that states may experience longer term reduction in administrative burden.

If these proposals are finalized as proposed, we anticipate that states would have approximately 3 years to implement daily exchange of buy-in and MMA data. For each state there would be a one-time cost to make needed systems changes, and thereafter, no new on-going costs. States will have the ability to choose, in consultation with CMS, when in the 3-year implementation period they want to make this change, with numerous factors impacting in which year they would do so. For the purposes of this impact analysis, we estimated an even distribution beginning in May 2019 and ending in April 2022. The total cost impact over the 3-year implementation period for this provision is $6,308,371 ($3,273,965 + $3,034,406), comprising $0.7 million in FY 2019, $2.2 million in FY 2020, $2.2 million in FY 2021, and $1.2 million in FY 2022. Since the proposed effective date is April 1, 2022, we estimate no costs for FY 2023.

3. Revisions to the Conditions of Participation for Hospitals and Critical Access Hospitals (CAHs)

We are seeking to further expand CMS requirements for interoperability within the hospital and CAH CoPs by focusing on electronic patient event notifications. We are proposing new requirements in section X. of this proposed rule for hospitals at 42 CFR 482.24(d)), for psychiatric hospitals at 42 CFR 482.61(f), and for CAHs at 42 CFR 485.638. Specifically, for hospitals, psychiatric hospitals and CAHs, we are proposing similar requirements to revise the CoPs for Medicare- and Medicaid-participating hospitals, psychiatric hospitals, and CAHs by adding a new standard, “Electronic Notifications,” that would require hospitals, psychiatric hospitals, and CAHs to make electronic patient event notifications available to another healthcare facility or to another community provider. We propose to limit this requirement to only those hospitals, psychiatric hospitals, and CAHs which currently possess EHR systems with the technical capacity to generate information for electronic patient event notifications, recognizing that not all Medicare- and Medicaid-participating hospitals have been eligible for past programs promoting adoption of EHR systems. We propose that these notifications would need to be sent at admission and either immediately prior to or at the time of the patient's discharge or transfer to licensed and qualified practitioners, other patient care team members, and PAC services providers and suppliers that: (1) Receive the notification for treatment, care coordination, or quality improvement purposes; (2) have an established care relationship with the patient relevant to his or her care; and (3) for whom the hospital, psychiatric hospital, or CAH has a reasonable certainty of receipt of notifications. As we noted, infrastructure supporting the exchange of electronic health information across settings has matured substantially in recent years. Research studies have increasingly found that health information exchange interventions can effectuate positive outcomes in health care quality and public health outcomes, in addition to more longstanding findings around reductions in utilization and costs. Electronic patient event notifications from hospitals, or clinical event notifications, are one type of health information exchange intervention that has been increasingly recognized as an effective and scalable tool for improving care coordination across settings, especially for patients at discharge. This approach has been identified with a reduction in readmissions following implementation.^[75]

These notifications are automated, electronic communications from the provider to another facility or another community provider identified by the patient. These automated communications alert the receiving provider that the patient has received care at a different setting. Information included with these notifications can range from simply conveying the patient's name, basic demographic information, and the sending institution, to a richer set of clinical data depending upon the level of technical implementation. However, regardless of the information included these alerts can help ensure that a receiving provider is aware that the patient has received care elsewhere. The notification triggers a receiving provider to reach out to the patient to deliver appropriate follow-up care in a timely manner. By providing timely notifications, the alert may improve post-discharge transitions and reduce the likelihood of complications resulting from inadequate follow-up care.

Virtually all EHR systems generate the basic messages commonly used to support electronic patient event notifications. We believe that care coordination can have a significant positive impact on the quality of life, consumer experience, and health outcomes for patients. However, we acknowledge that though such activities can have positive impact, they will likely generate some costs. We believe it is difficult to quantify the impact of this proposed change because EHR implementation across care settings varies in maturity rates, leading to potential variance in cost and impact across such settings. We believe that this proposal would impose minimal additional costs on hospitals. The cost of implementing these proposed changes would largely be limited to the one-time cost related initial implementation of the notification system, and to the revision of a policies and procedures as they relate to discharge planning. There also may be some minimal cost associated with communicating these changes to affected staff. However, we believe that these costs would be offset by the benefits derived from positive outcomes in health care quality and public health outcomes. Therefore, while this proposal would impose a minimal burden on hospitals, we believe that, in sum, the changes proposed would greatly benefit patients overall.

4. Effects of Other Proposed Policy Changes

In addition to those proposed policy changes discussed previously that we are able to model, we are proposing to make various other changes in this proposed rule. Generally, we have limited or no specific data available with which to estimate the impacts of these proposed changes. Our estimates of the likely impacts associated with these other proposed changes are discussed in this section.

a. Care Coordination Across Payers

In section V. of this proposed rule, we are proposing a new requirement for MA plans, Medicaid managed care plans, CHIP managed care entities, and QHP issuers in FFEs to require these plans to maintain a process to exchange, at a minimum, the USCDI data set upon an enrollee's request. Under our proposal, each of these plans subject to the requirement would, upon an enrollee's request: (1) Accept the data set from another plan that had covered the enrollee within the previous 5 years; (2) send the data set at any time during an enrollee's enrollment and up to 5 years later, to another plan that currently covers the enrollee; and (3) send the data set at any time during enrollment or up to 5 years after enrollment has ended to a recipient identified by the enrollee.

Such transactions would be made in compliance with applicable laws.

We believe that sending and receiving this minimum data would help both plan enrollees and health care providers in coordinating care and reducing administrative burden. We believe that this entails utilizing all tools available to us to ensure that plans provide coordinated high-quality care in an efficient and cost-effective way that protects program integrity.

We believe that this proposal would impose minimal additional costs on plans. We note that we do not specify a transport standard in the proposal and anticipate that plans may opt to use APIs, such as the API that this proposed rule would also require. We also anticipate that plans may choose to utilize a regional health information exchange. We believe it is difficult to quantify the impact of this proposed change because plans will likely implement different transport methods, and we cannot predict the selected method plans will choose.

b. Care Coordination Through Trusted Exchange Networks

In section VI. of this proposed rule, we are proposing to require MA plans, Medicaid managed care plans, CHIP managed care entities and QHP issuers in FFEs to participate in trust networks in order to improve interoperability in these programs. We believe that payers and patients' ability to communicate between themselves and with health care providers could considerably improve patient access to data, reduce provider burden, and reduce redundant and unnecessary procedures. A trusted exchange framework allows for the secure exchange of electronic health information with, and use of electronic health information from, other health IT without special effort on the part of the user. Widespread payer participation in such a framework might also allow for more complete access, exchange, and use of all electronically accessible health information for authorized use under applicable state or federal law. Under our proposal, participation would be required in a trusted exchange framework that meets the following criteria:

• The trusted exchange network must be able to exchange PHI, defined in 45 CFR 160.103, in compliance with all applicable state and federal laws across jurisdictions.
• The trusted exchange network must connect both inpatient EHRs and ambulatory EHRs.
• The trusted exchange network must support secure messaging or electronic querying by and between patients, providers and payers.

We believe that this proposal would impose minimal additional costs on plans.

D. Alternatives Considered

This proposed rule contains a range of proposed and potential future policies. It provides descriptions of the statutory provisions that are addressed, identifies the proposed policies, and presents rationales for our decisions and, where relevant, alternatives that were considered. We carefully considered the alternatives to this proposed rule but concluded that none would adequately and immediately begin to address the critical issue of the lack of patient access and interoperability, or exchange of health care data within the health care system.

The critical policy decision was how broadly or narrowly to classify the standards required to implement interoperability. Overly prescriptive standards may stifle innovation and, in turn, increase costs. On the other side, broad language surrounding standards risked leaving too much open to interpretation and continuing the uncertainty about which standards would be the most practical and cost-effective to implement. We determined it was most appropriate to propose a technical and standards framework that strikes a balance between these two ends of the spectrum, and to establish that we expect the standards framework to expand and mature as interoperability increases.

A second decision was how broadly or narrowly to apply the proposed policies and requirements. For example, alternatives to requiring health plans to provide claims data to patients via an open API could have been altered in a number of ways, such as requiring more or less information to be provided to patients or, simultaneously, to require additional information beyond that already accessible through existing APIs be provided to patients by providers. Ultimately, we opted to continue to consider most matters pertaining to providers in separate RFIs, such as that in the FY 2019 IPPS proposed rule seeking information about program participation conditions and requirements, and to maintain the policies proposed in this rule as policies that will further enhance and secure the foundation of future interoperability, including through inclusion of payers, through care coordination, and through matters of security and identity confirmation.

As we recognize that advancing interoperability is no small or simple matter, we continue to explore alternatives and potential other policies. We have requested comment for consideration in future rulemaking or subregulatory guidance on a number of alternatives related to whether additional policies or requirements, beyond those proposed herein, should be imposed to promote interoperability. For example, the Innovation Center is seeking comment on general principles around promoting interoperability within Innovation Center models for integration into new models as part of the design and testing of innovative payment and service delivery models. Additionally, we are seeking comment on how we may leverage our program authority to provide support to those working on improving patient matching. For example, we are requesting comment on whether CMS should require, in Medicare FFS, the MA program, Medicaid FFS, CHIP FFS, Medicaid managed care programs, CHIP managed care entities, and the FFEs, use of a particular patient matching software solution with a proven success rate of a certain percentage validated by HHS or a 3rd party. We also continue to consider feedback received from RFIs issued in various rules over the course of the past year and to incorporate those suggestions into our strategy.

E. Accounting Statement and Table

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

Table 9—Accounting Statement

Category	Primary estimate	Units
		Year dollars	Discount rate (%)	Period covered
Benefits:
Qualitative	• API requirements will alleviative the burden for beneficiaries and enrollees 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.
	• API requirement allows for the administration of a more efficient and effective Medicaid program by taking advantage of commonly used methods of information sharing and data standardization.
	• API requirements would help to create a healthcare information ecosystem that allows and encourages the healthcare market to tailor products and services to compete for patients, thereby increasing quality, decreasing costs, and helping them live better, healthier lives.
Costs:
Annualized Monetized $ millions/year	106.26	2020	7	2020-2024
	102.73	2020	3	2020-2024

The preceding discussion was an actual cost impact (not a transfer) since goods and computer services are being paid for. Plans have the option of transferring their expenses to enrollees. In practice, because of market competitive forces a plan may decide to operate at a (partial) loss and not transfer the entire cost. It is important to estimate the maximum the transfer could be. Some costs are transferred to the States (for Medicaid and CHIP) and ultimately to the federal government (for Medicare, Medicaid, and CHIP), mitigating the amount transferred to enrollees. One approach to estimate impact on enrollees was made in section XVI.B. of this RIA. However, this analysis did not take into account transfers.

We now re-estimate the potential full transfer. As noted in section Tables 4 through 8 of XVI.B. of this RIA, we have in 2021 through 2024 under a dollar increase in premium as the worst case scenario, and we used actual costs per year. In this alternate analysis we use actual amounts for each of 2021 through 2024 with the initial 1-year cost amortized over 5 years. In other words, we assume a cost of $110 (275.4/5 + 54.7)

We point out that this premium increase should be counterbalanced by projected savings arising from the provisions in this proposed rule. More specifically, we expect the availability of portable electronic transfer of medical data proposed by this rule to increase prevention of future medical illnesses due to better data accessibility. The savings from avoiding one illness or one cheaper procedure would offset the under one-dollar impact. However, we have no way, at this point, of estimating this aspect of the future savings of the rule.

We present two estimates. First, we estimate using the enrollment figures used in Table 7 of this RIA. Table 7 shows that we have 169 million (76+73+20) in programs that will be spending about $110 million per year. Ignoring Federal subsidies, and assuming that all costs will be passed on to enrollees (which is contrary to our experience), the 169 million enrollees would each incur an extra 65 cents (110/169) a year to achieve the $110 million goal. We next estimate using premium versus enrollment as was done in section XVI.B. of this RIA.

Prior to discussing potential transfers to enrollees, we discuss how this proposed rule may affect commercial enrollees not in the MA, Medicaid, CHIP, or FFE programs. Technically, plans are only required to provide interoperability for enrollees in the MA, Medicaid, CHIP, and FFE programs. However, it is both possible and likely, that a Parent Organization providing interoperability for its FFE and other program enrollees as required, may choose to offer this to commercial enrollees. Consequently, it is possible that to cover the cost of offering interoperability to commercial enrollees outside the MA, Medicaid, CHIP and FFE programs, the Parent Organizations, raise premiums to both their commercial enrollees as well as the MA, Medicaid, CHIP or FFE enrollees. Thus it is possible (and we argue likely) that this proposed rule will affect commercial enrollees even though there is no requirement to provide them interoperability. Therefore, we believe we are obligated in this RIA to calculate the cost impact per enrollee should the Parent Organizations offer interoperability (and should they pass on the cost of interoperability in terms of commercial premium). The rest of the discussion below explores this possibility.^[76]

Commercial: Rebates are required under section 2718(b)(1)(A) of the PHSA and the implementing regulations at 45 CFR part 158 when an issuer does not meet the applicable threshold. The commercial market MLR is generally calculated as the percent of each dollar of after-tax premium revenue spent by the issuer on medical products and services, and activities that improve the quality of health care. If the issuer MLR for a state market is below the applicable threshold, then the issuer must return the difference to policyholders. It follows, that if interoperability costs raise plan costs, and if additionally, the issuers pass on the full cost in the form of premium and/or are able to treat these costs as QIAs, then premiums and rebates will change. The following two highly simplified examples are illustrative.

Suppose the MLR threshold is 85 percent (in practice it can vary by state market), but the issuer's MLR is below the threshold at 75 percent. Then the issuer would have to return the 10 percent as a rebate. If the interoperability costs for an issuer are on average 6 percent of premium and the issuer treats these expenses as QIA, the issuer will now have to rebate only 4 percent instead of 10 percent (that is, the issuer's MLR would be 81 percent rather than 75 percent). Similarly, if both the applicable threshold and issuer MLR are 85 percent, then the issuer would not owe a rebate.

There are two effects of recognizing these costs as QIA: (1) For issuers below the applicable MLR threshold, the rebate from issuers to policyholders would go down by some amount between $0 and the interoperability cost; and (2) for issuers at or above the MLR standards, the premium transfers from enrollees to issuers will go up by some amount between $0 and the interoperability cost.

To estimate these amounts, we used the public use 2016 MLR files on the CMS website that were used for Tables 4 through 7 of this RIA. The total 2016 premium revenue on the commercial side was approximately $370 billion. Of the $370 billion, the total 2016 premium revenue of issuers that were below the commercial MLR standard (80 or 85 percent, depending on the market) was approximately $19.4 billion and that subset of issuers paid a total of $455 million in rebates.

As mentioned earlier, to proceed further we use the estimates of the interoperability costs which are $110 million per year. This cost is for all parent organizations with each parent organization possibly dealing with up to four lines of business subject to MLR requirements: MA (including Part D sponsors); Medicaid; CHIP; and Commercial. Thus, of the $110 million level annual cost of interoperability, we estimate $64 million (57.81 percent commercial proportion x $110 million level annual interoperability cost) to be the cost for the commercial market.

In estimating the transfers to policyholders in the commercial market, we must distinguish between the $19.4 billion of premium revenues of issuers whose MLR was below the applicable threshold and the $350.6 billion of premium revenues ($370 billion total revenue−$19.4 billion) of issuers whose MLR was at or above the applicable threshold. We can now calculate the estimated aggregate transfer in the commercial market from the policyholders to the issuers whether through premium or rebates as follows:

• Interoperability cost = 0.017 percent of revenue premium ($64 million cost/$370 billion total revenue).
• Reduced MLR rebates = $3.3 million (0.017 percent × $19.4 billion premium from issuers below the applicable MLR threshold).
• Increased premiums = Up to $60.0 million (0.017 percent × ($370 billion total revenue−$19.4 billion premium from issuers below the applicable MLR threshold)).
• Total transfer from enrollees = Up to $63.3 million ($60.0 million increased premium + $3.3 million reduced rebate).
• Transfer per enrollee = 83 cents ($63.3 million/76 million commercial enrollee).

We note that the 83 cents (under a dollar per enrollee) is consistent with the results obtained in Tables 4 through 8 (with exact raw amounts by year without amortization of a large first year expense). These calculations are summarized in Table 10.

These calculations are summarized in Table 10.

Table 10—Transfers to Enrollee Resulting From the Proposed Rule

Level Annual Cost of Interoperability
(A)	First year cost of interoperability	275.4	Estimated in this proposed rule	In millions.
(B)	First year cost amortized over 5 years	55.08	(A)/5	In millions.
(C)	Continuation year cost of interoperability	54.7	Estimated in this proposed rule	In millions.
(D)	Level interoperability cost per year	109.78	(B) + (C)	In millions.
Commercial Percent of Premium Revenues
(E)	Total premium revenues in commercial, Medicaid and Medicare	640	Sum of (F) (G) and (H) Below	In billions.
(F)	Commercial Premium revenues (dollar amount and percent)	370	58%	2016 CMS MLR files (in billions); Percentage obtained by dividing by column E.
(G)	Medicare Advantage Premium revenues (Dollar amount and percent)	157	25%	2016 CMS MLR files (in billions); Percentage obtained by dividing by column E.
(H)	Medicaid Premium revenues (Dollar amount and percent)	113	18%	2016 CMS MLR files (in billions); Percentage obtained by dividing by column E.
Annual Interoperability Cost as a Percent of Commercial Premium Revenues
(I)	Annualized Level interoperability cost	109.78	(D)	In millions.
(J)	Percent of total revenues related to commercial market	58%	(F)
(K)	Interoperability cost for commercial issuers	63.67	(I) × (J)	In millions.
(L)	Commercial Premium revenues	370,000	(F)	In millions.
(M)	Interoperability cost as a percent of total commercial revenue	0.017%	(K)/(L)
Commercial Revenue Broken Out by Whether Above or Below MLR Threshold (Requiring Rebate)
(N)	Total Commercial Revenue	370,000	(F)	In millions.
(O)	Revenues of commercial market issuers whose MLR is below threshold	19,400	2016 CMS MLR files (in millions)
(P)	Revenues of commercial market issuers whose MLR is at or above the threshold	350,600	(N)−(O)	In millions.
Transfer To Enrollee per Enrollee From Decreased Rebates and Increased Premium
(Q)	Reduction in commercial market rebates from interoperability for those issuers paying rebates	3.3	(M) × (O)	In millions.
(R)	Premium increase from interoperability for those commercial market issuers not paying rebates	60.0	(M) × (P)	In millions.
(S)	Total increase to commercial enrollees from interoperability	63.3	(Q) + (R)	In millions.
(T)	Number Commercial Enrollees	76	2016 CMS MLR files (in millions)
(U)	Dollar increase in premium per enrollee	$0.83	(S)/(T)

F. Regulatory Reform Analysis under E.O. 13771

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

G. Conclusion

The analysis above, together with the preceding preamble, provides an RIA.

In accordance with the provisions of Executive Order 12866, this regulation was reviewed by the Office of Management and Budget.

List of Subjects

42 CFR Part 406

• Health facilities
• Diseases
• Medicare

42 CFR Part 407

• Medicare

42 CFR Part 422

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

42 CFR Part 423

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

42 CFR Part 431

• Grant programs—health
• Health facilities
• Medicaid
• Privacy
• Reporting and recordkeeping requirements

42 CFR Part 438

• Grant programs—health
• Medicaid
• Reporting and recordkeeping requirements

42 CFR Part 457

• Administrative practice and procedure
• Grant programs—health
• Health insurance
• Reporting and recordkeeping requirements

42 CFR Part 482

• Grant programs—health
• Hospitals
• Medicaid
• Medicare
• Reporting and recordkeeping requirements

42 CFR Part 485

• Grant programs—health
• Health facilities
• Medicaid
• Privacy
• Reporting and recordkeeping requirements

45 CFR Part 156

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

For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services (CMS) proposes to amend 42 CFR chapter IV and the Office of the Secretary (HHS) proposes to further amend 45 CFR subtitle A, subchapter B (as proposed to be amended in ONC's proposed rule “21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program” published elsewhere in this issue of this Federal Register), as set forth below:

Title 42—Public Health

Chapter IV—Centers For Medicare & Medicaid Services, Department of Health and Human Services

PART 406—HOSPITAL INSURANCE ELIGIBLIITY AND ENTITLEMENT

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

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

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

§ 406.26

Enrollment under State buy-in.

(a) * * *

(1) * * *

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

(ii) [Reserved]

* * * * *

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

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

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

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

§ 407.40

Enrollment under a State buy-in agreement.

* * * * *

(c) * * *

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

PART 422—MEDICARE ADVANTAGE PROGRAM

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

Authority: 42 U.S.C 1395w26 and 1395w-27.

6. Section 422.119 is added to read as follows:

§ 422.119

Access to and exchange of health data and plan information.

(a) Application Programming Interface to support MA enrollees. A Medicare Advantage (MA) organization must implement and maintain an open Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of an individual MA enrollee, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the enrollee.

(b) Accessible content. (1) An MA organization must make the following information accessible to its enrollees through the API described in paragraph (a) of this section:

(i) Standardized data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and enrollee cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;

(ii) Standardized encounter data, no later than one (1) business day after data concerning the encounter is received by the MA organization;

(iii) Provider directory data on the MA organization's network of contracted providers, including names, addresses, phone numbers, and specialties, updated no later than 30 business days after changes are made to the provider directory; and

(iv) Clinical data, including laboratory results, if the MA organization manages any such data, no later than one (1) business day after the data is received by the MA organization.

(2) In addition to the information specified in paragraph (b)(1) of this section, an MA organization that offers an MA-PD plan must make the following information accessible to its enrollees through the API described in paragraph (a) of this section:

(i) Standardized data concerning adjudicated claims for covered Part D drugs, including remittances and enrollee cost-sharing, no later than 1 business day after a claim is adjudicated;

(ii) Pharmacy directory data, including the number, mix, and addresses of network pharmacies; and

(iii) Formulary data that includes covered Part D drugs, and any tiered formulary structure or utilization management procedure which pertains to those drugs.

(c) Technical requirements. An MA organization:

(1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215;

(2) Must conduct routine testing and monitoring to ensure the API functions properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as, but not limited to, those minimally required to comply with HIPAA privacy and security requirements in 45 CFR part 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data;

(3) Must comply with the following regulations regarding content and vocabulary standards for data available through the API, where applicable to the data type or data element, unless alternate standards are required by other applicable law:

(i) Content and vocabulary standards at 45 CFR 170.213 where such standards are the only available standards for the data type or element;

(ii) Content and vocabulary standards at 45 CFR part 162 and 42 CFR 423.160 where required by law or where such standards are the only available standards for the data type or element; or

(iii) The content and vocabulary standards in either paragraph (c)(3) (i) or (ii) of this section as determined appropriate for the data type or element, where a specific data type or element may be encoded or formatted using content and vocabulary standards in either paragraph (c)(3)(i) or (ii) of this section.

(4) May use an updated version of any standard or all standards required under paragraph (c)(1) or (3) of this section, where:

(i) Use of the updated version of the standard is required by other applicable law, or

(ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that:

(A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170;

(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and

(C) Where use of the updated version of a standard does not disrupt an end user's ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section.

(d) Documentation requirements for APIs. For each API implemented in accordance with paragraph (a) of this section, an MA organization must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns;

(2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and

(3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.

(e) Denial or discontinuation of access to the API. An MA organization may deny or discontinue any third party application's connection to the API required under paragraph (a) of this section if the MA organization:

(1) Reasonably determines that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the MA organization's systems; and

(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which enrollees seek to access their electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.

(f) Coordination among payers. (1) MA organizations must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the regulations regarding the content standard adopted at 45 CFR 170.213. Such information received by an MA organization must be incorporated into the MA organization's records about the enrollee. At the request of an enrollee, the MA organization must:

(i) Receive such data from any other health care plan that has provided coverage to the enrollee within the preceding 5 years;

(ii) At any time an enrollee is currently enrolled in the MA plan and up to 5 years after disenrollment, send such data to any other health care plan that currently covers the enrollee; and

(iii) At any time the enrollee is currently enrolled in the MA plan and up to 5 years after disenrollment, send such data to a recipient designated by the enrollee.

(2) MA organizations must participate in a trusted exchange network which:

(i) Is capable of exchanging protected health information, defined at 45 CFR 160.103, in compliance with all applicable State and Federal laws across jurisdictions;

(ii) Is capable of connecting to inpatient electronic health records and ambulatory electronic health records; and

(iii) Supports secure messaging or electronic querying by and between providers, payers and patients.

(g) Enrollee resources regarding privacy and security. An MA organization must provide on its website and through other appropriate mechanisms through which it ordinarily communicates with current and former enrollees seeking to access their health information held by the MA organization, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum:

(1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application, and understanding the security and privacy practices of any application to which they will entrust their health information; and

(2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of OCR and FTC, and how to submit a complaint to:

(i) The HHS Office for Civil Rights; and

(ii) The Federal Trade Commission (FTC).

(h) Applicability. This section is applicable beginning on and after January 1, 2020.

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

§ 422.504

Contract provisions.

* * * * *

(a) * * *

(18) To comply with the requirements for access to health data and plan information under § 422.119.

* * * * *

PART 423—VOLUNTARY MEDICARE PRESCRIPTION DRUG BENEFIT

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

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

9. Section 423.910 is amended—

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

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

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

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

The addition reads as follows:

§ 423.910

Requirements.

* * * * *

(d) State enrollment reporting. * * *

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

(ii) For the period beginning April 1, 2022, States must submit the file at least monthly and must submit updates to that file on a daily basis.

* * * * *

PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION

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

Authority: 42 U.S.C. 1302.

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

§ 431.60

Beneficiary access to and exchange of data.

(a) Application Programming Interface to support Medicaid beneficiaries. A State must implement and maintain an open Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of a beneficiary, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the beneficiary.

(b) Accessible content. A State must make the following information accessible to its beneficiaries through the API described in paragraph (a) of this section:

(1) Standardized data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and beneficiary cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;

(2) Standardized encounter data through the API within one (1) business day of receiving the data from providers, other than MCOs, PIHPs, and PAHPs, compensated on the basis of capitation payments;

(3) Provider directory information specified in section 1902(a)(83) of the Act, no later than 30 calendar days after the State receives provider directory information or updates to provider directory information;

(4) Clinical data, including laboratory results, if the State manages any such data, no later than one (1) business day after the data is received by the State; and

(5) Information about covered outpatient drugs and updates to such information, including, where applicable, preferred drug list information, no later than one (1) business day after the effective date of any such information or updates to such information.

(c) Technical requirements. A State:

(1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215;

(2) Must conduct routine testing and monitoring to ensure the API functions properly, including assessments to verify that the API is fully and successfully implementing privacy and security features such as, but not limited to, those minimally required to comply with HIPAA privacy and security requirements in 45 CFR part 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data;

(3) Must comply with the following regulations regarding content and vocabulary standards for data available through the API, where applicable to the data type or data element, unless alternate standards are required by other applicable law:

(i) Content and vocabulary standards at 45 CFR 170.213 where such standards are the only available standards for the data type or element;

(ii) Content and vocabulary standards at 45 CFR part 162 and 42 CFR 423.160 where required by law, or where such standards are the only available standards for the data type or element; or

(iii) The content and vocabulary standards in either paragraphs (c)(3)(i) or (ii) of this section, as determined appropriate for the data type or element, where a specific data type or element may be encoded or formatted using content and vocabulary standards in either paragraph (c)(3)(i) or (ii) of this section.

(4) May use an updated version of any standard or all standards required under paragraph (c)(1) or (3) of this section, where:

(i) Use of the updated version of the standard is required by other applicable law, or

(ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that:

(A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170;

(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and

(C) Where use of the updated version of a standard does not disrupt an end user's ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section.

(d) Documentation requirements for APIs. For each API implemented in accordance with paragraph (a) of this section, a State must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns;

(2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and

(3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.

(e) Denial or discontinuation of access to the API. A State may deny or discontinue any third-party application's connection to the API required under paragraph (a) of this section if the State:

(1) Reasonably determines that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the State's systems; and

(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which beneficiaries seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.

(f) Beneficiary resources regarding privacy and security. The State must provide on its website and through other appropriate mechanisms through which it ordinarily communicates with current and former beneficiaries seeking to access their health information held by the State Medicaid agency, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum:

(1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application, and understanding the security and privacy practices of any application to which they will entrust their health information; and

(2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of OCR and FTC, and how to submit a complaint to:

(i) The HHS Office for Civil Rights; and

(ii) The Federal Trade Commission (FTC).

(g) Applicability. This section is applicable beginning on or after July 1, 2020.

PART 438—MANAGED CARE

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

Authority: 42 U.S.C. 1302.

13. Section 438.62 is amended by adding paragraph (b)(1)(vi) to read as follows:

§ 438.62

Continued services to enrollees.

* * * * *

(b) * * *

(1) * * *

(vi) A process for the electronic exchange of, at a minimum, the data classes and elements included in the regulations regarding the content standard at 45 CFR 170.213. Information received by the MCO, PIHP, or PAHP must be incorporated into the MCO's, PIHP's, or PAHP's records about the enrollee. At the request of an enrollee, the MCO, PIHP, or PAHP must:

(A) Accept such data from any other health care plan that has provided coverage to the enrollee within the preceding 5 years;

(B) At any time the enrollee is currently enrolled in the MCO, PIHP, or PAHP and up to 5 years after disenrollment, send such data to any other health care plan that currently covers the enrollee; and

(C) At any time the enrollee is currently enrolled in the MCO, PIHP, or PAHP and up to 5 years after disenrollment, send such data to any other recipient designated by the enrollee.

* * * * *

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

§ 438.242

Health information systems.

* * * * *

(b) * * *

(5) Participate in a trusted exchange network which:

(i) Is capable of exchanging protected health information as defined in 45 CFR 160.103, in compliance with all applicable State and Federal laws from all relevant jurisdictions;

(ii) Is capable of connecting to inpatient electronic health records and ambulatory electronic health records, and;

(iii) Supports secure messaging or electronic querying by and between providers, payers and patients.

(6) Implement an Application Programming Interface (API) as specified in § 431.60 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP and

(i) Include all standardized encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating on the basis of capitation payments and adjudicated claims and encounter data from any subcontractors; and

(ii) Provider directory information required in § 431.60(b)(3) of this chapter, which must include all information required in § 438.10(h)(1).

* * * * *

PART 457—ALLOTMENTS AND GRANTS TO STATES

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

Authority: 42 U.S.C. 1302.

16. Section 457.700 is amended by—

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

b. Adding paragraph (a)(1);

c. Revising paragraph (c).

The addition and revision reads as follows:

§ 457.700

Basis, scope, and applicability.

(a) * * *

(1) Section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to States to provide child health assistance to uninsured, low-income children in an effective and efficient manner that is coordinated with other sources of health benefits coverage;

* * * * *

(c) Applicability. The requirements of this subpart apply to separate child health programs and Medicaid expansion programs, except that § 457.730 does not apply to Medicaid expansion programs. Separate child health programs that provide benefits exclusively through managed care organizations may meet the requirements of § 457.730 by requiring the managed care organizations to meet the requirements of § 457.1233(d)(2).

17. Section 457.730 is added to read as follows:

§ 457.730

Beneficiary access to and exchange of data.

(a) Application Programming Interface to support CHIP beneficiaries. A State must implement and maintain an open application programming interface (API) that permits third-party applications to retrieve, with the approval and at the direction of the individual beneficiary, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the beneficiary.

(b) Accessible content. A State must make the following information accessible to its beneficiaries through the API described in paragraph (a) of this section:

(1) Standardized data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and beneficiary cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;

(2) Standardized encounter data through the API within one (1) business day of receiving the data from providers, other than MCOs, PIHPs, or PAHPs, compensated on the basis of capitation payments;

(3) Provider directory information, including updated provider information no later than 30 calendar days after the State receives updated provider information;

(4) Clinical data, including laboratory results, if a State manages any such data, no later than one (1) business day after the data is received by the State; and

(5) Information, about covered outpatient drugs and updates to such information, including, where applicable, preferred drug list information, no later than one (1) business day after the effective date of the information or updates to such information.

(c) Technical requirements. A State:

(1) Must implement, maintain, and use API technology conformant with 45 CFR 170.215;

(2) Must conduct routine testing and monitoring to ensure the API functions properly, including assessments to verify that the API technology is fully and successfully implementing privacy and security features such as, but not limited to, those minimally required to comply with HIPAA privacy and security requirements in 45 CFR part 164, 42 CFR parts 2 and 3, and other applicable law protecting the privacy and security of individually identifiable data;

(3) Must comply with the following regulations regarding content and vocabulary standards for data available through the API, where applicable to the data type or data element, unless alternate standards are required by other applicable law:

(i) Content and vocabulary standards at 45 CFR 170.213 where such standards are the only available standards for the data type or element;

(ii) Content and vocabulary standards at 45 CFR part 162 and 42 CFR 423.160 where required by law, or where such standards are the only available standards for the data type or element; or

(iii) The content and vocabulary standards in either paragraphs (c)(3)(i) or (ii) of this section, as determined appropriate for the data type or element, where a specific data type or element may be encoded or formatted using content and vocabulary standards in either paragraphs (c)(3)(i) or (ii) of this section.

(4) May use an updated version of any standard or all standards required under paragraphs (c)(1) or (3) of this section, where:

(i) Use of the updated version of the standard is required by other applicable law, or

(ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that:

(A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170;

(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and

(C) Where use of the updated version of a standard does not disrupt an end user's ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section.

(d) Documentation requirements for APIs. For each API implemented in accordance with paragraph (a) of this section, a State must make publicly accessible, by posting directly on its website or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns;

(2) The software components and configurations that an application must use in order to successfully interact with the API and process its response(s); and

(3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.

(e) Denial or discontinuation of access to the API. A State may deny or discontinue any third-party application's connection to the API required under paragraph (a) of this section if the State:

(1) Reasonably determines that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of protected health information on the State's systems; and

(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which beneficiaries seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.

(f) Beneficiary resources regarding privacy and security. A State must provide on its website and through other appropriate mechanisms through which it ordinarily communicates with current and former beneficiaries seeking to access their health information held by the State CHIP agency, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum:

(1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application, and understanding the security and privacy practices of any application to which they will entrust their health information; and

(2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of OCR and FTC, and how to submit a complaint to:

(i) The HHS Office for Civil Rights; and

(ii) The Federal Trade Commission (FTC).

(g) Applicability. This section is applicable beginning on or after July 1, 2020.

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

§ 457.1233

Structure and operations standards.

* * * * *

(d) Health information systems. (1) The State must ensure, through its contracts, that each MCO, PIHP, and PAHP complies with the health information systems requirements as provided in § 438.242(a), (b)(1) through (5), (c), (d), and (e) of this chapter.

(2) Each MCO, PIHP, and PAHP must implement an Application Programming Interface (API) as specified in § 457.730 as if such requirements applied directly to the MCO, PIHP, or PAHP, and

(i) Include all standardized encounter data, including encounter data from any network providers the MCO, PIHP, or PAHP is compensating on the basis of capitation payments and adjudicated claims and encounter data from any subcontractors; and

(ii) Provider directory information required in § 457.730(b)(3), which must include all information required in § 438.10(h)(1) of this chapter.

* * * * *

PART 482—CONDITIONS OF PARTICIPATION: HOSPITALS

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

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

20. Sections 482.24 is amended by adding paragraph (d) to read as follows:

§ 482.24

Conditions of participation: Medical record services.

* * * * *

(d) Standard: Electronic notifications. If the hospital utilizes an electronic medical records system with the capacity to generate information for patient event notifications in accordance with paragraph (d)(2) of this section, then the hospital must demonstrate that—

(1) The system's notification capacity is fully operational and that it operates in accordance with all State and Federal statutes and regulations regarding the exchange of patient health information;

(2) The system complies with the regulations regarding the content exchange standard at 45 CFR 170.205(a)(4)(i);

(3) The system sends notifications that must include the minimum patient health information (which must be patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis);

(4) At the time of the patient's admission to the hospital, the system sends notifications directly or through an intermediary that facilitates exchange of health information, to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers:

(i) That receive the notification for treatment, care coordination, or quality improvement purposes;

(ii) That have an established care relationship with the patient relevant to his or her care; and

(iii) For whom the hospital has a reasonable certainty of receipt of notifications; and

(4) Either immediately prior to or at the time of the patient's discharge or transfer from the hospital, the system sends notifications directly or through an intermediary that facilitates exchange of health information, to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers:

(i) That receive the notification for treatment, care coordination, or quality improvement purposes;

(ii) That have an established care relationship with the patient relevant to his or her care; and

(iii) For whom the hospital has a reasonable certainty of receipt of notifications.

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

§ 482.61

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

* * * * *

(f) Standard: Electronic notifications. If the hospital utilizes an electronic medical records system with the capacity to generate information for patient event notifications in accordance with paragraph (f)(2) of this section, then the hospital must demonstrate that—

(1) The system's notification capacity is fully operational and that it operates in accordance with all State and Federal statutes and regulations regarding the exchange of patient health information;

(2) The system complies with the regulations regarding the content exchange standard at 45 CFR 170.205(a)(4)(i);

(3) The system sends notifications that must include the minimum patient health information (which must be patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis);

(4) At the time of the patient's admission to the hospital, the system sends notifications directly, or through an intermediary that facilitates exchange of health information, to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers:

(i) That receive the notification for treatment, care coordination, or quality improvement purposes;

(ii) That have an established care relationship with the patient relevant to his or her care; and

(iii) For whom the hospital has a reasonable certainty of receipt of notifications; and

(5) Either immediately prior to or at the time of the patient's discharge or transfer from the hospital, the system sends notifications directly or through an intermediary that facilitates exchange of health information, to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers:

(i) That receive the notification for treatment, care coordination, or quality improvement purposes;

(ii) That have an established care relationship with the patient relevant to his or her care; and

(iii) For whom the hospital has a reasonable certainty of receipt of notifications.

PART 485—CONDITIONS OF PARTICIPATION: SPECIALIZED PROVIDERS

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

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

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

§ 485.638

Conditions of participation: Clinical records.

* * * * *

(d) Standard: Electronic notifications. If the CAH utilizes an electronic medical records system with the capacity to generate information for patient event notifications in accordance with paragraph (d)(2) of this section, then the CAH must demonstrate that—

(1) The system's notification capacity is fully operational and that it operates in accordance with all State and Federal statutes and regulations regarding the exchange of patient health information;

(2) The system complies with the regulations regarding the content exchange standard at 45 CFR 170.205(a)(4)(i);

(3) The system sends notifications that must include the minimum patient health information (which must be patient name, treating practitioner name, sending institution name, and, if not prohibited by other applicable law, patient diagnosis);

(4) At the time of the patient's admission to the CAH, the system sends notifications directly or through an intermediary that facilitates exchange of health information, to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers:

(i) That receive the notification for treatment, care coordination, or quality improvement purposes;

(ii) That have an established care relationship with the patient relevant to his or her care; and

(iii) For whom the CAH has a reasonable certainty of receipt of notifications; and

(5) Either immediately prior to or at the time of the patient's discharge or transfer from the CAH, the system sends notifications directly or through an intermediary that facilitates exchange of health information, to licensed and qualified practitioners, other patient care team members, and post-acute care services providers and suppliers:

(i) That receive the notification for treatment, care coordination, or quality improvement purposes;

(ii) That have an established care relationship with the patient relevant to his or her care; and

(iii) For whom the CAH has a reasonable certainty of receipt of notifications.

TITLE 45—PUBLIC WELFARE

Subtitle A—Department of Health and Human Services

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

24. The authority citation for part 156 is revised to read as follows:

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

25. Section 156.221 is added to read as follows:

§ 156.221

Access to and exchange of health data and plan information.

(a) Application Programming Interface to support enrollees. Subject to paragraph (h) of this section, QHP issuers in a Federally-facilitated Exchange, not including stand-alone dental plans (SADP) issuers, must implement and maintain an open Application Programming Interface (API) that permits third-party applications to retrieve, with the approval and at the direction of an individual enrollee, data specified in paragraph (b) of this section through the use of common technologies and without special effort from the enrollee.

(b) Accessible content. (1) A QHP issuer in a Federally-facilitated Exchange must make the following information accessible to its enrollees through the API described in paragraph (a) of this section:

(i) Standardized data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal, and provider remittances and enrollee cost-sharing pertaining to such claims, no later than one (1) business day after a claim is processed;

(ii) Standardized encounter data, no later than one (1) business day after data concerning the encounter is received by the QHP issuer; and

(iii) Clinical data, including laboratory results, if the QHP issuer maintains such data, no later than one (1) business day after data is received by the issuer.

(c) Technical requirements. A QHP issuer in a Federally-facilitated Exchange:

(1) Must implement, maintain, and use API technology conformant 45 CFR 170.215;

(2) Must conduct routine testing and monitoring to ensure the API functions properly, including assessments to verify the API is fully and successfully implementing privacy and security features such as, but not limited to, those minimally required to comply with HIPAA privacy and security requirements in 45 CFR part 164, 42 CFR parts 2 and 3, and other applicable law protecting privacy and security of individually identifiable data;

(3) Must comply with the following regulations regarding the content and vocabulary standards for data available through the API where applicable to the data type or data element, unless alternate standards are required by other applicable law:

(i) Content and vocabulary standards at 45 CFR 170.213 where such are the only available standards for the data type or element;

(ii) Content and vocabulary standards at 45 CFR part 162 and 42 CFR 423.160 where required by law, or where such standards are the only available standards for the data type or element; or

(iii) The content and vocabulary standards in either paragraph (c)(3)(i) or (ii) of this section as determined appropriate for the data type or element, where a specific data type or element may be encoded or formatted using content and vocabulary standards in either paragraph (c)(3)(i) or (ii) of this section.

(4) May use an updated version of any standard or all standards required under paragraphs (c)(1) or (3) of this section, where:

(i) Use of the updated version of the standard is required by other applicable law, or

(ii) Use of the updated version of the standard is not prohibited under other applicable law, provided that:

(A) For content and vocabulary standards other than those at 45 CFR 170.213, the Secretary has not prohibited use of the updated version of a standard for purposes of this section or 45 CFR part 170;

(B) For standards at 45 CFR 170.213 and 45 CFR 170.215, the National Coordinator has approved the updated version for use in the ONC Health IT Certification Program; and

(iii) Where use of the updated version of a standard does not disrupt an end user's ability to access the data described in paragraph (b) of this section through the API described in paragraph (a) of this section.

(d) Documentation requirements for APIs. For each API implemented in accordance with paragraph (a) of this section, a QHP issuer must make publicly accessible, by posting directly on its website and/or via publicly accessible hyperlink(s), complete accompanying documentation that contains, at a minimum:

(1) API syntax, function names, required and optional parameters supported and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns;

(2) The software components and configurations an application must use in order to successfully interact with the API and process its response(s); and

(3) All applicable technical requirements and attributes necessary for an application to be registered with any authorization server(s) deployed in conjunction with the API.

(e) Denial or discontinuation of access to the API. A QHP issuer in a Federally-facilitated Exchange may deny or discontinue any third party application's connection to the API required under paragraph (a) of this section if the issuer:

(1) Reasonably determines that allowing an application to connect or remain connected to the API would present an unacceptable level of risk to the security of personally identifiable information, including protected health information, on the QHP issuer's systems; and

(2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which enrollees seek to access their electronic health information as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools.

(f) Exchange of data between plans. (1) Subject to paragraph (d) of this section, QHP issuers in a Federally-facilitated Exchange, not including SADP issuers, must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the regulations regarding the content standard at 45 CFR 170.213 of this subchapter. Information received by a QHP issuer must be incorporated into the QHP issuer's records about the enrollee. At the request. A QHP issuer must:

(i) Accept such data from any other health care plan that has provided coverage to the enrollee within the preceding 5 years;

(ii) At any time the enrollee is currently enrolled in the plan and up to 5 years after disenrollment, send such data to any other health care plan that currently covers the enrollee; and

(iii) At any time the enrollee is currently enrolled in the plan and up to 5 years after disenrollment, send such data to a recipient designated by the enrollee.

(2) QHP issuers must participate in a trusted exchange network which:

(i) Is capable of exchanging protected health information, defined at 45 CFR 160.103 of this subchapter, in compliance with all applicable State and Federal laws of relevant jurisdictions;

(ii) Is capable of connecting to inpatient electronic health records and ambulatory electronic health records; and

(iii) Supports secure messaging or electronic querying by and between providers, payers and patients.

(g) Enrollee resources regarding privacy and security. A QHP issuer in a Federally-facilitated Exchange must provide on its website and through other appropriate mechanisms through which it ordinarily communicates with current and former enrollees seeking to access their health information held by the QHP issuer, educational resources in non-technical, simple and easy-to-understand language explaining at a minimum:

(1) General information on steps the individual may consider taking to help protect the privacy and security of their health information, including factors to consider in selecting an application, and understanding the security and privacy practices of any application to which they will entrust their health information; and

(2) An overview of which types of organizations or individuals are and are not likely to be HIPAA covered entities, the oversight responsibilities of OCR and FTC, and how to submit a complaint to:

(i) The HHS Office for Civil Rights; and

(ii) The Federal Trade Commission (FTC).

(h) Exception. (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraphs (a), (b), or (c) of this section, the issuer must include as part of its QHP application a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section.

(2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraphs (a), (b), or (c) if the Exchange determines that making such health plan available through such Exchange is in the interests of qualified individuals and qualified employers in the State or States in which such Exchange operates.

(i) Applicability. This section is applicable for plan years beginning on or after January 1, 2020.

(ii) [Reserved]

Dated: December 14, 2018.

Seema Verma,

Administrator, Centers for Medicare & Medicaid Services.

Dated: January 10, 2019.

Alex M. Azar II,

Secretary, Department of Health and Human Services.

Footnotes

1.  ONC, Health IT Dashboard, “Office-based Physician Health IT Adoption: State rates of physician EHR adoption, health information exchange & interoperability, and patient engagement (2015),” https://dashboard.healthit.gov/​apps/​physician-health-it-adoption.php (last accessed July 9, 2018).

2.  ONC, Health IT Dashboard, “Non-federal Acute Care Hospital Health IT Adoption and Use: State rates of non-federal acute care hospital EHR adoption, health information exchange and interoperability, and patient engagement (2015),” https://dashboard.healthit.gov/​apps/​hospital-health-it-adoption.php (last accessed July 9, 2018).

3.  We refer readers to https://bluebutton.cms.gov for more information related to the CMS Blue Button initiative.

4.  https://www.healthit.gov/​sites/​default/​files/​electronic-health-record-adoption-and-interoperability-among-u.s.-skilled-nursing-facilities-in-2016.pdf.

5.  https://aspe.hhs.gov/​report/​opportunities-engaging-long-term-and-post-acute-care-providers-health-information-exchange-activities-exchanging-interoperable-patient-assessment-information/​hit-and-ehr-certification-ltpac.

6.  https://www.healthit.gov/​sites/​default/​files/​pdf/​HIT_​LTPAC_​IssueBrief031513.pdf.

7.  https://www.cms.gov/​Medicare/​Provider-Enrollment-and-Certification/​CertificationandComplianc/​Downloads/​nursinghomedatacompendium_​508-2015.pdf.

8.  For more information on the USCDI, see https://www.healthit.gov/​USCDI.

9.  See, for example, ONC “Connecting Health and Care for the Nation: A Shared Nationwide Interoperability Roadmap” Final Version 1.0 (2015): https://www.healthit.gov/​sites/​default/​files/​hie-interoperability/​nationwide-interoperability-roadmap-final-version-1Nor.0.pdf.

10.  ONC has made available a succinct, non-technical overview of APIs in context of consumers' access to their own medical information across multiple providers' EHR systems, which is available at the HealthIT.gov website at https://www.healthit.gov/​api-education-module/​story_​html5.html.

11.  “RESTful interfaces” are those that are consistent with Representational State Transfer (REST) architectural style and communications approaches to web services development.

12.  OCR enforces federal civil rights laws, conscience and religious freedom laws, the Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy, Security, and Breach Notification Rules, and provisions of the Patient Safety and Quality Improvement Act of 2005 (PSQIA) and the Patient Safety Rule (codified at 42 CFR part 3 (73 FR 70732)) protecting the confidentiality and privilege of patient safety work product as defined in PSQIA and 42 CFR part 3. Thus, within HHS, OCR has lead responsibility for interpreting, administering, and enforcing HIPAA regulations and developing guidance.

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

14.  More information on the Privacy Rule, including related rulemaking actions and additional interpretive guidance, is available at https://www.hhs.gov/​hipaa/​for-professionals/​privacy/​index.html.

15.  See § 164.524(c)(2) and (3), and 164.308(a)(1), OCR HIPAA Guidance/FAQ-2036: https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2036/​can-an-individual-through-the-hipaa-right/​index.html,, and OCR HIPAA Guidance/FAQ-2037: https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2037/​are-there-any-limits-or-exceptions-to-the-individuals-right/​index.html.

16.  See, generally, the “unreasonable measures” heading of OCR HIPAA for professionals information web page at https://www.hhs.gov/​hipaa/​for-professionals/​privacy/​guidance/​access/​index.html. See also FAQ 2039—https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2039/​what-is-the-liability-of-a-covered-entity-in-responding/​index.html;​; FAQ 2060: https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2060/​do-individuals-have-the-right-under-hipaa-to-have/​index.html;​; FAQ 2040: https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2040/​what-is-a-covered-entitys-obligation-under/​index.html.

17.  https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2039/​what-is-the-liability-of-a-covered-entity-in-responding/​index.html.

18.  https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2060/​do-individuals-have-the-right-under-hipaa-to-have/​index.html.

19.  https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2040/​what-is-a-covered-entitys-obligation-under/​index.html.

20.  https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2060/​do-individuals-have-the-right-under-hipaa-to-have/​index.html.

21.  https://www.healthit.gov/​sites/​default/​files/​non-covered_​entities_​report_​june_​17_​2016.pdf.

22.  For more information on the USCDI, see https://www.healthit.gov/​USCDI.

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

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

25.  For more information on the USCDI, see https://www.healthit.gov/​USCDI.

26.  For more information on FHIR, see https://www.hl7.org/​fhir/​overview.html.

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

28.  See 45 CFR 164.524(c)(2) and (3), and 164.308(a)(1), OCR HIPAA Guidance/FAQ-2036: https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2036/​can-an-individual-through-the-hipaa-right/​index.html,, and OCR HIPAA Guidance/FAQ-2037: https://www.hhs.gov/​hipaa/​for-professionals/​faq/​2037/​are-there-any-limits-or-exceptions-to-the-individuals-right/​index.html (FAQs last accessed at these URLs July 30, 2018).

29.  Available at https://github.com/​CMSgov/​QHP-provider-formulary-APIs/​blob/​master/​README.md.

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

31.  https://www.healthit.gov/​topic/​health-it-basics/​improved-diagnostics-patient-outcomes.

32.  While this rulemaking is specific to QHP issuers participating in FFEs, we note that to the extent other commercial market issuers incur similar costs for coverage sold in the individual or group markets, those expenses may similarly qualify as QIA.

33.  As noted above, to the extent other commercial market issuers incur similar costs for coverage sold in the individual or group markets outside of an FFE, those expenses may similarly qualify as QIA.

34.  CMS, “State Buy-In Manual Chapter 3—Data Exchange,” https://www.cms.gov/​Regulations-and-Guidance/​Guidance/​Manuals/​downloads/​buyin_​c03.pdf. (last accessed September 26, 2018).

35.  CMS, “Medicare Prescription Drug Benefit Manual: Chapter 3—Eligibility, Enrollment and Disenrollment (2017),” https://www.cms.gov/​Medicare/​Eligibility-and-Enrollment/​MedicarePresDrugEligEnrol/​Downloads/​CY_​2018_​PDP_​Enrollment_​and_​Disenrollment_​Guidance_​6-15-17.pdf (last accessed September 26, 2018).

36.  ONC, Report to Congress on Health Information Blocking (Apr. 2015), https://www.healthit.gov/​sites/​default/​files/​reports/​info_​blocking_​040915.pdf.

37.  See, for example, Julia Adler-Milstein and Eric Pfeifer, Information Blocking: Is It Occurring And What Policy Strategies Can Address It?, 95 Milbank Quarterly 117, 124-25 (Mar. 2017), available at http://onlinelibrary.wiley.com/​doi/​10.1111/​1468-0009.12247/​full.

38.  See, for example, Martin Gaynor, Farzad Mostashari, and Paul B. Ginsberg, Making Health Care Markets Work: Competition Policy for Health Care, 16-17 (Apr. 2017), available at http://heinz.cmu.edu/​news/​news-detail/​index.aspx?​nid=​3930;​ see also Diego A. Martinez et al., A Strategic Gaming Model For Health Information Exchange Markets, Health Care Mgmt. Science (Sept. 2016). Niam Yaraghi, A Sustainable Business Model for Health Information Exchange Platforms: The Solution to Interoperability in Healthcare IT (2015), available at http://www.brookings.edu/​research/​papers/​2015/​01/​30-sustainable-business-model-health-information-exchange-yaraghi;​; Thomas C. Tsai & Ashish K. Jha, Hospital Consolidation, Competition, and Quality: Is Bigger Necessarily Better?, 312 J. AM. MED. ASSOC. 29, 29 (2014).

39.  The NPPES website is available at https://nppes.cms.hhs.gov/​.

40.  See https://nppes.cms.hhs.gov/​.

41.  Menachemi N, Rahurkar S, Harle CA, Vest JR, The benefits of health information exchange: An updated systematic review, J Am Med Inform Assoc. 2018 Apr 28, accessed at https://www.ncbi.nlm.nih.gov/​pubmed/​29718258.

42.  Yeaman B, Ko KJ, Alvarez del Castillo R. Care ransitions in long-term care and acute care: Health information exchange and readmission rates. Online J Issues Nurs 2015;20(3):5. Accessed at https://www.ncbi.nlm.nih.gov/​pubmed/​26882514.

43.  Vest JR, Kern LM, Silver MD, Kaushal R, investigators H. The potential for community-based health information exchange systems to reduce hospital readmissions. J Am Med Inform Assoc, 2015 March, accessed at https://www.ncbi.nlm.nih.gov/​pubmed/​25100447.

44.  Unruh MA, Jung HY, Kaushal R, Vest JR, Hospitalization event notifications and reductions in readmissions of Medicare FFS beneficiaries in the Bronx, New York. J AM Med Inform Assoc, 2017 Apr 1, accessed at https://www.ncbi.nlm.nih.gov/​pubmed/​28395059.

45.  Boockvar KS, Ho W, Pruskowski J, et al. Effect of health information exchange on recognition of medication discrepancies is interrupted when data charges are introduced: Results of a cluster-randomized controlled trial. J Am Med Inform Assoc 2017, accessed at https://www.ncbi.nlm.nih.gov/​pubmed/​28505367.

46.  Unruh MA, Jung HY, Kaushal R, Vest JR, Hospitalization event notifications and reductions in readmissions of Medicare FFS beneficiaries in the Bronx, New York. J AM Med Inform Assoc, 2017 Apr 1, accessed at https://www.ncbi.nlm.nih.gov/​pubmed/​28395059.

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

48.  https://www.healthit.gov/​isa/​admission-discharge-and-transfer.

49.  Ongoing work under contract: HHSP23320095651WC with RTI International.

50.  Gage BJ, Morley MA, Smith LM, Ingber MJ, Deutsch A, Kline TL, Dever JA, Abbate JH, Miller RD, Lyda-McDonald B, Kelleher CA, Garfinkel DB, Manning JR, Murtaugh CM, Stineman MG, Mallinson T. (March, 2012). Post-Acute Care Payment Reform Demonstration: Final Report Volume 2. Prepared for the Centers for Medicare and Medicaid Services. Available at https://www.cms.gov/​Research-Statistics-Data-and-Systems/​Statistics-Trends-and-Reports/​Reports/​Downloads/​PAC-PRD_​FinalRpt_​Vol2of4.pdf.

51.  Alvarado C, Zook K, Henry J. Electronic Health Record Adoption and Interoperability among U.S. Skilled Nursing Facilities in 2016, Washington, DC, Office of the National Coordinator for Health Information Technology, U.S. Department of Health and Human Services, September 2017. Accessed at https://www.healthit.gov/​sites/​default/​files/​electronic-health-record-adoption-and-interoperability-among-u.s.-skilled-nursing-facilities-in-2016.pdf.

52.  Yang N, Hing E. Table of Electronic Health Record Adoption and Use among Office-based Physicians in the U.S., by Specialty: 2015 National Electronic Health Records Survey. 2017. Accessed at https://www.cdc.gov/​nchs/​data/​ahcd/​nehrs/​2015_​nehrs_​ehr_​by_​specialty.pdf.

53.  QuickStats: Percentage of Residential Care Communities That Use Electronic Health Records, by Community Bed Size—United States, 2016. MMWR Morb Mortal Wkly Rep 2018;67:138. DOI: https://www.cdc.gov/​mmwr/​volumes/​67/​wr/​mm6704a8.htm?​s_​cid=​mm6704a8_​w.

54.  Quality in Home and Community-Based Services to Support Community Living: https://www.qualityforum.org/​Publications/​2016/​09/​Quality_​in_​Home_​and_​Community-Based_​Services_​to_​Support_​Community_​Living_​_​Addressing_​Gaps_​in_​Performance_​Measurement.aspx.

55.  Measurement of Interoperable Electronic Health Care Records Utilization Final Report: https://aspe.hhs.gov/​system/​files/​pdf/​255526/​EHRUtilizationReport.pdf.

56.  Analyzing the Public Benefit Attributable to Interoperable Health Information Exchange: https://aspe.hhs.gov/​system/​files/​pdf/​258851/​AnalyzingthePublicBenefitAttributabletoInteroperableHealth.pdf.

57.  A Measurement Framework to Assess Nationwide Progress Related to Interoperable Health Information Exchange to Support the National Quality Strategy: https://www.qualityforum.org/​Projects/​i-m/​Interoperability_​2016-2017/​Final_​Report.aspx.

58.  For more information on the Data Element Library see https://del.cms.gov/​DELWeb/​pubHome,, as well as the Data Element Library Training and FAQ at https://del.cms.gov/​DELWeb/​pubTrainFAQ. CMS also provides information and training on the various assessment instruments through which post-acute care providers must submit data. Training on the OASIS instrument can be found on the HH QRP website at https://www.cms.gov/​Medicare/​Quality-Initiatives-Patient-Assessment-Instruments/​HomeHealthQualityInits/​Home-Health-Quality-Reporting-Training.html; information related to the training on the IRF PAI is available on the IRF QRP website at https://www.cms.gov/​Medicare/​Quality-Initiatives-Patient-Assessment-Instruments/​IRF-Quality-Reporting/​IRF-Quality-Reporting-Training.html; information related to the training on the LTCH CARE Data Set is available on the LTCH QRP website at https://www.cms.gov/​Medicare/​Quality-Initiatives-Patient-Assessment-Instruments/​LTCH-Quality-Reporting/​LTCH-Quality-Reporting-Training.html; and information related to the training on the MDS is available on the SNF QRP website at https://www.cms.gov/​Medicare/​Quality-Initiatives-Patient-Assessment-Instruments/​NursingHomeQualityInits/​Skilled-Nursing-Facility-Quality-Reporting-Program/​SNF-Quality-Reporting-Program-Training.html.

59.  https://www.gao.gov/​assets/​700/​696426.pdf.

60.  https://www.cms.gov/​Research-Statistics-Data-and-Systems/​Statistics-Trends-and-Reports/​ReportsTrustFunds/​Downloads/​TR2018.pdf.

61.  https://www.medicaid.gov/​medicaid/​program-information/​medicaid-and-chip-enrollment-data/​report-highlights/​index.html.

62.  https://www.cms.gov/​Research-Statistics-Data-and-Systems/​Statistics-Trends-and-Reports/​MCRAdvPartDEnrolData/​Monthly-Contract-and-Enrollment-Summary-Report-Items/​Contract-Summary-2018-08.html?​DLPage=​1&​DLEntries=​10&​DLSort=​1&​DLSortDir=​descending.

63.  https://www.cms.gov/​CCIIO/​Resources/​Data-Resources/​mlr.html.

64.  Although the 2017 MLR data recently became available, using them would not change the bottom line of the analysis. The 2016 data gives $113 billion, $157 billion and $370 billion enrollees for commercial, MA, and Medicaid plans respectively resulting in revenue proportions of 57.81 percent, 24.53 percent, 17.68 percent. The 2017 data gives $119.5, $170.3 and $381.5 billion for commercial MA, and Medicaid plans resulting in proportions of 56.8 percent, 25.36 percent, and 17.79 percent. The 76 million commercial enrollees from the 2016 data decreased to 73.5 million in 2017. Using these alternate proportions and numbers would not change significantly our dollar-per-enrollee estimates of impacts.

65.  https://www.cms.gov/​Research-Statistics-Data-and-Systems/​Statistics-Trends-and-Reports/​ReportsTrustFunds/​Downloads/​TR2018.pdf Table IV.C2.

66.  https://www.cms.gov/​newsroom/​press-releases/​cms-proposes-changes-streamline-and-strengthen-medicaid-and-chip-managed-care-regulations.

67.  https://www.medicaid.gov/​medicaid/​program-information/​medicaid-and-chip-enrollment-data/​report-highlights/​index.html.

68.  https://www.cms.gov/​Research-Statistics-Data-and-Systems/​Statistics-Trends-and-Reports/​MCRAdvPartDEnrolData/​Monthly-Contract-and-Enrollment-Summary-Report-Items/​Contract-Summary-2018-08.html?​DLPage=​1&​DLEntries=​10&​DLSort=​1&​DLSortDir=​descending.

69.  To give an idea of how the per enrollee per year numbers would change had we used updated enrollment, we note that the latest MA enrollment (as of January 2019) is for January 2019 and is 22 million, the latest Medicaid enrollment is for Oct 2018 and is still 73 million, and the latest commercial enrollment is for 2017 and is 73.5. The resulting per-enrollee-per-year cost impacts would be $2.17, 0.28, and $2.04 versus the numbers in Table 7 which are $2.10, 0.28, and $2.24. These changes per enrollee per year would not affect any of our conclusions about negligibility relative to the 4 and 5 digit per enrollee per year expenses for Medicare, Medicaid and the Federally Funded exchange.

70.  Society of Actuaries, Medicaid Managed Care Organizations: Considerations in Calculating Margin in Rate Setting. Accessed at https://www.soa.org/​research-reports/​2017/​medicaid-margins/​,, pg. 49.

71.  Table 17 of Appendix D, “Capitation Payments and Premiums”, in the CMS report, “2016 Actuarial Report on the Financial Outlook for Medicaid,” accessible at URL https://www.medicaid.gov/​medicaid/​finance/​downloads/​medicaid-actuarial-report-2016.pdf.

72.  May 2018, EHR Incentive Program, Payment Summary Report, accessed at https://www.cms.gov/​Regulations-and-Guidance/​Legislation/​EHRIncentivePrograms/​Downloads/​May2018_​SummaryReport.pdf.

73.  ONC, Health IT Dashboard, “Office-based Physician Health IT Adoption: State rates of physician EHR adoption, health information exchange & interoperability, and patient engagement (2015),” https://dashboard.healthit.gov/​apps/​physician-health-it-adoption.php (last accessed July 9, 2018).

74.  https://www.cms.gov/​Newsroom/​MediaReleaseDatabase/​Press-releases/​2018-Press-releases-items/​2018-03-06.html.

75.  Unruh MA, Jung HY, Kaushal R, Vest JR, Hospitalization event notifications and reductions in readmissions of Medicare FFS beneficiaries in the Bronx, New York. J AM Med Inform Assoc, 2017 Apr 1, accessed at https://www.ncbi.nlm.nih.gov/​pubmed/​28395059.

76.  Note that our analysis in Tables 5,6,7,8 also assume that costs are incurred by commercial enrollees even though there is no requirement to provide them with interoperability. We believe this the most likely scenario. However, if we are restrictive in our impact analysis and only assume MA, Medicaid, CHIP and FFE enrollees are bearing the cost the results of Tables 5-8 would not change the negligibility conclusion as the following justifications show: We have assumed 20 million, 73 million and 76 million enrollees in the MA, Medicaid and Commercial programs (Table 7). The 20 million and 73 million remain accurate. The 76 million (commercial enrollees) must be replaced by FFE enrollees. For this purpose we use QHP data. Based on internal data (some of which has not yet been published), for 2017 there were 9,757,747 enrollees with $55,109,210,072 total premium resulting in a $5600 per enrollee per year cost, and for 2018, there were 9,925,382 enrollees with $70,738,585,845 total premium resulting in a $7100 per enrollee per year cost. To illustrate how this changes the Table 7 impact, the $2.10 per enrollee per year cost for 2020 commercial must be replaced by $15.96 to account for a division by 10 million versus 76 million. Although this is a big increase, $15.96 is still only about one third a percent of the per-enrollee-per-year costs of the FFE. Thus the cost is still negligible. Furthermore, a Parent Organization actuary reviewing these numbers would probably seriously recommend that all enrollees including commercial be offered the interoperability since that significantly reduces the per enrollee per year cost.