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

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

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

Office of the Secretary

45 CFR Part 156

[CMS-9115-P]

RIN 0938-AT79

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

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, (410) 786-4457, for issues related to interoperability, CMS health IT strategy, technical standards and patient matching.

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

John Giles, (410) 786-1255, for issues related to Medicaid.

Emily Pedneau, (301) 492-4448, for issues related to Qualified Health Plans.

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

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

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

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

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

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

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

Lisa Bari, (410) 786-0087, for issues related to advancing interoperability in innovative models.

Russell Hendel, (410) 786-0329, 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.

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

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.

3

We refer readers to

https://bluebutton.cms.gov

for more information related to the CMS Blue Button initiative.

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

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.

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

7

https://www.cms.gov/Medicare/Provider-Enrollment-and-Certification/CertificationandComplianc/Downloads/nursinghomedatacompendium_508-2015.pdf.

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.

8

For more information on the USCDI, see

https://www.healthit.gov/USCDI.

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.

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.

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

10

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

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

While acknowledging the limits of our authority to require use of APIs to address our goals for interoperability and data access, we 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.

11

“RESTful interfaces” are those that are consistent with Representational State Transfer (REST) architectural style and communications approaches to web services development.

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.

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.

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.

13

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

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

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.

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

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.

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

21

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

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

).

22

For more information on the USCDI, see

https://www.healthit.gov/USCDI.

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

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.

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

).

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.

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 not

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