7610 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

reference information, clinical guidelines, DEPARTMENT OF HEALTH AND CMS–9115–P, P.O. Box 8016, Baltimore, condition-specific order sets, alerts, and HUMAN SERVICES MD 21244–8016. reminders, among other tools. Please allow sufficient time for mailed • Clinical Quality Measures criteria for Centers for Medicare & Medicaid comments to be received before the record and export, import and calculate, and Services close of the comment period. filter criteria: 3. By express or overnight mail. You Æ Record and export criterion ensures that 42 CFR Parts 406, 407, 422, 423, 431, may send written comments to the health IT systems can record and export 438, 457, 482, and 485 following address ONLY: Centers for CQM data electronically; the export Medicare & Medicaid Services, functionality gives clinicians the ability to Office of the Secretary Department of Health and Human export their results to multiple programs. Services, Attention: CMS–9115–P, Mail Æ import and calculate criterion supports 45 CFR Part 156 Stop C4–26–05, 7500 Security streamlined clinician processes through the Boulevard, Baltimore, MD 21244–1850. importing of CQM data in a standardized [CMS–9115–P] For information on viewing public format and ensures that health IT systems comments, see the beginning of the can correctly calculate eCQM results using a RIN 0938–AT79 SUPPLEMENTARY INFORMATION section. standardized format. FOR FURTHER INFORMATION CONTACT: Æ filter criterion supports the capability for Medicare and Medicaid Programs; Patient Protection and Affordable Care Alexandra Mugge, (410) 786–4457, for a clinician to make a query for eCQM results issues related to interoperability, CMS using or a combination of data captured by Act; Interoperability and Patient Access for Medicare Advantage health IT strategy, technical standards the certified health IT for quality and patient matching. improvement and quality reporting purposes. Organization and Medicaid Managed Care Plans, State Medicaid Agencies, Natalie Albright, (410) 786–1671, for Alignment With Proposed New or Updated CHIP Agencies and CHIP Managed issues related to Medicare Advantage. John Giles, (410) 786–1255, for issues Certification Criteria Care Entities, Issuers of Qualified related to Medicaid. ONC believes this recommendation is Health Plans in the Federally- Emily Pedneau, (301) 492–4448, for supported by the proposed new and updated Facilitated Exchanges and Health Care issues related to Qualified Health Plans. certification criteria in this proposed rule: Providers Meg Barry, (410) 786–1536, for issues • United States Core Data for related to CHIP. Interoperability (USCDI): The USCDI AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS. Thomas Novak, (202) 322–7235, for (§ 170.213) which enables the inclusion of issues related to trust exchange pediatric vital sign data elements, including ACTION: Proposed rule. networks and payer to payer the reference range/scale or growth curve for SUMMARY: This proposed rule is coordination. BMI percentile per age and sex, weight for Sharon Donovan, (410) 786–9187, for age per length and sex, and head occipital- intended to move the health care issues related to federal-state data frontal circumference. ecosystem in the direction of • interoperability, and to signal our exchange. Application Programming Interfaces Daniel Riner, (410) 786–0237, for (APIs): § 170.315(g)(10), would require the commitment to the vision set out in the ® 21st Century Cures Act and Executive issues related to Physician Compare. use of Health Level 7 (HL7 ) Fast Healthcare Ashley Hain, (410) 786–7603, for ® Order 13813 to improve access to, and Interoperability Resources (FHIR ) standards issues related to hospital public and several implementation specifications to the quality of, information that Americans need to make informed reporting. establish standardized application Melissa Singer, (410) 786–0365, for health care decisions, including data programming interfaces (APIs) for issues related to provider directories. interoperability purposes and to permit 3rd about health care prices and outcomes, CAPT Scott Cooper, USPHS, (410) party software developers to connect to the while minimizing reporting burdens on 786–9465, for issues related to hospital electronic health record (EHR) through the affected plans, health care providers, or and critical access hospital conditions certified API technology. payers. of participation. [FR Doc. 2019–02224 Filed 2–22–19; 4:15 pm] DATES: To be assured consideration, Lisa Bari, (410) 786–0087, for issues BILLING CODE 4150–45–P comments must be received at one of related to advancing interoperability in the addresses provided below, no later innovative models. than 5 p.m. on May 3, 2019. Russell Hendel, (410) 786–0329, for ADDRESSES: In commenting, please refer issues related to the Collection of to file code CMS–9115–P. Because of Information or the Regulation Impact staff and resource limitations, we cannot Analysis sections. accept comments by facsimile (FAX) SUPPLEMENTARY INFORMATION: transmission. Inspection of Public Comments: All Comments, including mass comment comments received before the close of submissions, must be submitted in one the comment period are available for of the following three ways (please viewing by the public, including any choose only one of the ways listed): personally identifiable or confidential 1. Electronically. You may submit business information that is included in electronic comments on this regulation a comment. We post all comments to http://www.regulations.gov. Follow received before the close of the the ‘‘Submit a comment’’ instructions. comment period on the following 2. By regular mail. You may mail website as soon as possible after they written comments to the following have been received: http:// address ONLY: Centers for Medicare & www.regulations.gov. Follow the search Medicaid Services, Department of instructions on that website to view Health and Human Services, Attention: public comments.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00188 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7611

I. Background and Summary of health information in interoperable providers and are taking an active Provisions forms. Patients and the health care approach using all available policy providers caring for them are often levers and authorities to move A. Purpose presented with an incomplete picture of participants in the health care market This proposed rule is the first phase their health and care as pieces of their toward interoperability and the secure of proposed policies centrally focused information are stored in various, and timely exchange of health care on advancing interoperability and unconnected systems and do not information. patient access to health information accompany the patient to every care using the authority available to the setting. C. Executive Order and MyHealthEData Centers for Medicare & Medicaid We believe patients should have the On October 12, 2017, President Services (CMS). We believe this is an ability to move from health plan to Trump issued Executive Order 13813 to important step in advancing health plan, provider to provider, and Promote Healthcare Choice and interoperability, putting patients at the have both their clinical and Competition Across the United States. center of their health care and ensuring administrative information travel with Section 1(c)(iii) of Executive Order they have access to their health them throughout their journey. When a 13813 states that the Administration information. We are committed to patient receives care from a new will improve access to, and the quality solving the issue of interoperability and provider, a complete record of their of, information that Americans need to achieving complete access to health health information should be readily make informed health care decisions, information for patients in the United available to that care provider, including information about health care States (U.S.) health care system, and are regardless of where or by who care was prices and outcomes, while minimizing taking an active approach to move previously provided. When a patient is reporting burdens on affected plans, participants in the health care market discharged from a hospital to a post- providers, and payers. toward interoperability and the secure acute care (PAC) setting there should be In support of Executive Order 13813, and timely exchange of health no question as to how, when, or where the Administration launched the information by proposing and adopting their data will be exchanged. Likewise, MyHealthEData initiative. This policies for the Medicare and Medicaid when an enrollee changes health plans government-wide initiative aims to programs, the Children’s Health or ages into Medicare, the enrollee empower patients by ensuring that they Insurance Program (CHIP), and issuers should be able to have their claims have full access to their own health of qualified health plans (QHPs). history and encounter data follow so Throughout this proposed rule, we information and the ability to decide that information is not lost. how their data will be used, while refer to terms such as patient, consumer, For providers in clinical settings, keeping that information safe and beneficiary, enrollee, and individual. health information technology (health secure. MyHealthEData aims to break We note that every reader of this IT) should be a resource, designed to down the barriers that prevent patients proposed rule is a patient and has or make it faster and easier for providers to from gaining electronic access to their will receive medical care at some point deliver high quality care, creating health information from the device or in their life. In this proposed rule, we efficiencies and allowing them to access use the term ‘‘patient’’ as an inclusive all available data for their patients. application of their choice, empowering term, but because we have historically Health IT should not detract from the patients and taking a critical step referred to patients using other terms in clinician-patient relationship, from the toward interoperability and patient data our regulations, we use specific terms as patient’s experience of care, or from the exchange. applicable in sections of this proposed quality of work life for physicians, In March 2018, the White House rule to refer to individuals covered nurses, and other health care Office of American Innovation and the under the health care programs that professionals. Through standards-based CMS Administrator announced the CMS administers and regulates. We also interoperability and exchange, health IT launch of MyHealthEData, and CMS’s use terms such as payer, plan, and has the potential to be a resource and direct, hands-on role in improving issuer in this proposed rule. Certain facilitator for efficient, safe, high-quality patient access and advancing portions of this proposed rule are care for individuals and populations. interoperability. As part of the applicable to the Medicare Fee-for- All payers, including health plans, MyHealthEData initiative, we are taking Service (FFS) Program, the Medicaid should have the ability to exchange data a patient-centered approach to health FFS Program, the CHIP FFS program, seamlessly with other payers for timely information access and moving to a Medicare Advantage (MA) benefits coordination or transitions, and system in which patients have Organizations, Medicaid Managed Care with providers to facilitate more immediate access to their computable plans (managed care organizations coordinated and efficient care. Health health information and can be assured (MCOs), prepaid inpatient health plans plans are in a unique position to that their health information will follow (PIHPs) and prepaid ambulatory health provide enrollees a complete picture of them as they move throughout the plans (PAHPs)), CHIP Managed Care their claims and encounter data, health care system from provider to entities (MCOs, PIHPs, and PAHPs), and allowing patients to piece together their provider, payer to payer. To accomplish QHP issuers in Federally-facilitated own information that might otherwise this, we have launched several Exchanges (FFEs). We use the term be lost in disparate systems. This initiatives related to data sharing and ‘‘payer’’ as an inclusive term, but we use information can contribute to better interoperability to empower patients specific terms as applicable in sections informed decision making, helping to and encourage plan and provider of this proposed rule. inform the patient’s choice of coverage competition. In this proposed rule, we options and care providers to more continue to advance the policies and B. Overview effectively manage their own health, goals of the MyHealthEData initiative We are dedicated to enhancing and care, and costs. through various proposals as outlined in protecting the health and well-being of We are committed to solving the issue the following sections. all Americans. One critical issue in the of interoperability and patient access in Our proposals are wide-reaching and U.S. health care system is that people the U.S. health care system while would have an impact on all facets of cannot easily access their complete reducing administrative burdens on the health care system. Several key

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00189 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7612 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

touch points of the proposals in this alleviate provider burden, and reduce clinical data, including providing patients rule include: overall health care costs. with electronic copies of health information. • • Patients: Enabling patients to access Stage 2 expanded upon the Stage 1 D. Past Efforts criteria with a focus on advancing clinical their health information electronically processes and ensuring that the meaningful without special effort by requiring the The Department of Health and Human Services (HHS) has been working to use of EHRs supported the aims and payers subject to this proposed rule to priorities of the National Quality Strategy. make the data available through an advance the interoperability of Stage 2 criteria encouraged the use of CEHRT application programming interface (API) electronic health information since for continuous quality improvement at the to which third party software 2004, when the ONC was initially point of care and the exchange of information applications connect to make the data created via Executive Order 13335. in the most structured format possible. • available to patients. This encourages From 2004 to 2009, ONC worked with Stage 3 focuses on using CEHRT to them to take charge of and better a variety of federal and private sector improve health outcomes. manage their health care, and thus these stakeholders to coordinate private and The federal government has spent initiatives are imperative to improving a public actions, began harmonizing data over $35 billion under the EHR patient’s long-term health outcomes. standards, and worked to advance Incentive Programs to incentivize the • Clinicians and Hospitals: Ensuring nationwide health information adoption and meaningful use of EHR that health care providers have ready exchange. In 2009, the National systems by eligible professionals, access to health information about their Coordinator position, office, and eligible hospitals, and CAHs; however, statutory duties were codified by the patients, regardless of where the patient despite the fact that 78 percent of Health Information Technology for 1 may have previously received care. We physicians and 96 percent of Economic and Clinical Health Act 2 are also proposing policies to prevent hospitals now use a certified EHR (HITECH Act), enacted as part of the health care providers from system, progress on system-wide data American Recovery and Reinvestment inappropriately restricting the flow of sharing has been limited. Act of 2009 (Pub. L. 111–5, enacted information to other health care In 2010, under the HITECH Act, ONC February 17, 2009), at Title 42—Health providers and payers. Finally, we are adopted an initial set of standards, Information Technology and Quality (42 working to ensure that better implementation specifications, and U.S.C. 300jj et seq.) of the Public Health interoperability reduces the burden on certification criteria, and established the Service Act (PHSA). Under section health care providers. Temporary Certification Program for • 3001(c)(5) of the PHSA, ONC Health Information Technology, under Payers: Proposing requirements to established a voluntary certification ensure that payers (that is, entities and which health IT developers could begin program to certify that health IT met to obtain certification of the EHR organizations that pay for health care), standards, implementation such as MA plans and Medicaid and technology that eligible professionals, specifications, and certification criteria eligible hospitals, and CAHs would CHIP programs, make enrollee adopted by the Secretary. ONC is electronic health information held by need to adopt and use to satisfy CMS organizationally located within HHS’ Stage 1 requirements for demonstration the plan available through an API such Office of the Secretary and is the that, with use of software we expect of meaningful use of CEHRT. In January principal federal entity charged with 2011, ONC replaced the Temporary payers and third parties to develop, the coordination of nationwide efforts to information becomes easily accessible to Certification Program with the implement and use the most advanced Permanent Certification Program for the enrollee, and that the data flows health IT and the electronic exchange of seamlessly with the enrollee as they Health Information Technology (45 CFR health information. part 170). The Secretary has adopted change providers, plans, and issuers. The HITECH Act provided the iterative editions of the set of standards, Additionally, our proposals would opportunity to move interoperability implementation specifications, and ensure that payers make it easy for forward in many additional meaningful certification criteria included in the current and prospective enrollees to ways. A few are particularly worth Programs to keep pace with advances in identify which providers are within a noting in relation to this proposed rule. standards, health information exchange, given plan’s network in a way that is For instance, HITECH also amended the and the health IT market. In addition, simple and easy for enrollees to access Social Security Act (the Act), and understand, and thus find the authorizing CMS to make incentive this helps to maintain alignment with providers that are right for them. payments (and in later years, make the needs of health care providers Under our proposals to standardize downward adjustments to Medicare seeking to succeed within health IT- data and technical approaches to payments) to eligible professionals, linked federal programs. In April 2015, Congress passed the advance interoperability, we believe eligible hospitals and critical access Medicare Access and CHIP health care providers and their patients, hospitals (CAHs), and MA organizations Reauthorization Act of 2015 (MACRA) as well as other key participants within to promote the adoption and meaningful (Pub. L. 114–10, enacted April 16, the health care ecosystem such as plans use of certified electronic health record and payers, will have appropriate access technology (CEHRT). In 2010, through 2015), which declared it a national to the information necessary to rulemaking, we established criteria for 1 ONC, Health IT Dashboard, ‘‘Office-based coordinate individual care, analyze the Medicare and Medicaid Electronic Physician Health IT Adoption: State rates of population health trends, outcomes, and Health Record (EHR) Incentive Programs physician EHR adoption, health information costs, and manage benefits and the to encourage eligible professionals, exchange & interoperability, and patient health of populations, while tracking eligible hospitals, and CAHs to adopt, engagement (2015),’’ https:// dashboard.healthit.gov/apps/physician-health-it- progress through quality improvement implement, upgrade, and demonstrate adoption.php (last accessed July 9, 2018). initiatives. We are working with other the meaningful use of CEHRT. The 2 ONC, Health IT Dashboard, ‘‘Non-federal Acute federal partners including the Office of programs were implemented in three Care Hospital Health IT Adoption and Use: State the National Coordinator for Health stages: rates of non-federal acute care hospital EHR adoption, health information exchange and Information Technology (ONC) on this • Stage 1 set the foundation for the EHR interoperability, and patient engagement (2015),’’ effort with the clear objective to Incentive Programs by establishing https://dashboard.healthit.gov/apps/hospital- improve patient access and care, requirements for the electronic capture of health-it-adoption.php (last accessed July 9, 2018).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00190 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7613

objective to achieve widespread to Hospital Conditions of Participation align with the Da Vinci Project to: (1) exchange of health information through and other like program requirements Develop a similar lookup service; (2) interoperable CEHRT nationwide. could impact or contribute to advancing populate it with their list of items/ Section 106(b)(1)(B)(ii) of MACRA interoperability, stakeholders provided services for which prior authorization is defines ‘‘interoperability’’ as the ability additional input that we are taking required; and (3) populate it with the of two or more health information under advisement for the purposes of documentation rules for at least oxygen systems or components to exchange advancing interoperability generally in and CPAP. By taking this step, health clinical and other information and to this proposed rule. For example, some plans can join CMS in helping to build use the information that has been commenters recommended aligning an ecosystem that will allow providers exchanged using common standards as existing standards and adopting to connect their EHRs or practice to provide access to longitudinal common standards and/or data elements management systems and efficient work information for health care providers in across the health care industry as a flows with up-to-date information on order to facilitate coordinated care and whole (not just focusing on providers), which items and services require prior improved patient outcomes. The incentivizing the use of standards, and authorization and what the MACRA charges the Secretary to removing barriers as possible ways to documentation requirements are for establish metrics to be used to address gaps in interoperability. various items and services under that determine if widespread interoperability Commenters also expressed support for patient’s current plan enrollment. had been achieved, and the heading of the use of open APIs but cautioned CMS In the 8 years since the first HHS section 106(b)(2) of the MACRA refers to to consider the need to ensure health rulemakings to implement HITECH, ‘‘preventing blocking the sharing of information security. Support was also significant progress has been made in information.’’ Specifically, section expressed for enhancing applications the adoption of EHRs by hospitals and 106(b)(2) of the MACRA amended that are designed for patient, or clinicians; however, progress on section 1848(o)(2)(A)(ii) of the Act for consumer use, such as Blue Button 2.0 interoperability needs to be accelerated. eligible professionals and section (CMS’ Medicare FFS open API for In section 106(b) of MACRA, Congress 1886(n)(3)(A)(ii) of the Act for eligible patient access to health information), declared it a national objective to hospitals and CAHs to require that the and the development of patient-facing achieve widespread exchange of health professional or hospital demonstrate consumer applications that aggregate information through interoperable that they have not knowingly and various longitudinal health information certified EHR technology nationwide by willfully taken action to limit or restrict for the patient into one location. We December 31, 2018. Not later than July the compatibility or interoperability of plan to continue to review the public 1, 2016, the Secretary was to establish CEHRT. For a discussion of the comments we receive to help identify metrics to be used to determine if and attestation requirements that we opportunities for CMS to advance to the extent this objective was established and codified to support the interoperability in future rulemaking achieved. If the objective is not achieved prevention of information blocking, we and subregulatory guidance. by December 31, 2018, the Secretary refer readers to the CY 2017 Quality CMS is also working with partners in must submit a report not later than Payment Program final rule (81 FR the private sector to promote December 31, 2019, that identifies 77028 through 77035). interoperability. In 2018, CMS began barriers to the objective and In April 2018, we renamed the EHR participating in the Da Vinci project, a recommends actions that the federal Incentive Programs and the MIPS private-sector initiative led by Health government can take to achieve the Advancing Care Information Level 7 (HL7), a standards development objective. In April 2016, ONC published performance category to the Promoting organization. For one of the use cases the ‘‘Office of the National Coordinator Interoperability (PI) Programs and under this project—called ‘‘Coverage for Health Information Technology; Promoting Interoperability performance Requirements and Documentation Rules Medicare Access and CHIP category, respectively (83 FR 41635). Discovery’’—the Da Vinci project Reauthorization Act of 2015; Request for This refocusing and rebranding of the developed a draft Fast Healthcare Information Regarding Assessing initiatives is just one part of the CMS Interoperability Resources (FHIR) Interoperability for MACRA’’ RFI (81 FR strategic shift in focus to advancing standard during the summer and fall of 20651). Based on stakeholder input health IT and interoperability. 2018. In June 2018, in support of the Da received in response to the RFI, ONC CMS appreciates the pathways Vinci project, the CMS Medicare FFS subsequently identified the following Congress opened for action on program began: (1) Developing a two metrics for interoperability (see interoperability, as will be discussed in prototype Documentation Requirement https://www.healthit.gov/sites/default/ more detail throughout this proposed Lookup Service for the Medicare FFS files/fulfilling_section_106b1c_of_the_ rule and has been working diligently program; (2) populating it with the list medicare_access_and_chip_ with ONC to support implementation. of items/services for which prior reauthorization_act_of_2015_ In addition, in order to make sure we authorization is required by the 06.30.16.pdf): have as much stakeholder feedback on Medicare FFS program; and (3) • Measure #1: Proportion of health all the options CMS specifically has populating it with the documentation care providers who are electronically available to best take advantage of this rules for oxygen and Continuous engaging in the following core domains new opportunity to promote Positive Airway Pressure (CPAP) of interoperable exchange of health interoperability, over a span of several devices. More information about the information: sending, receiving, finding months in 2018, we released FFS Medicare program’s efforts to (querying), and integrating information interoperability Requests for support these Da Vinci use cases are received from outside sources. Information (RFIs) in several Medicare available at go.cms.gov/ • Measure #2: Proportion of health payment rules, including in the FY 2019 MedicareRequirementsLookup. care providers who report using the Inpatient Prospective Payment System We encourage all payers, including information they electronically receive (IPPS) proposed rule (83 FR 20164). but not limited to MA organizations, from outside providers and sources for While the Interoperability RFI in the FY Medicaid managed care plans and CHIP clinical decision-making. 2019 IPPS proposed rule was focused managed care entities, and QHP issuers ONC recently provided an update on primarily on how and whether changes in FFEs to follow CMS’s example and these metrics in its 2018 Report to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00191 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7614 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Congress—Annual Update on the E. Challenges and Barriers to regarding the impact of this UPI on Adoption of a Nationwide System for Interoperability health information security and privacy. the Electronic Use and Exchange of Through significant stakeholder Stakeholders were concerned that if Health Information (see https:// feedback, we understand that there are there was a single identifier used across www.healthit.gov/sites/default/files/ many barriers to interoperability which systems, it would be easier for that page/2018-12/2018-HITECH-report-to- have obstructed progress over the years. information to be compromised, congress.pdf). ONC will continue to We have conducted stakeholder exposing protected health information evaluate nationwide performance meetings and roundtables; solicited (PHI) more easily than in the current medical record environment that according to the identified metrics, and comments via RFIs; and received generally requires linking several pieces believes current developments, such as additional feedback through letters and of personally identifying information to policy changes being implemented rulemaking. All of this input together link health records. under the 21st Century Cures Act (Cures has contributed to our proposals in this Act) (Pub. L. 114–255, enacted The National Committee on Vital proposed rule. Some of the main Health Statistics (NCVHS), the statutory December 13, 2016) will contribute to barriers shared with us are addressed in increasingly improved performance public advisory body to the Secretary of the following sections. While we have Health and Human Services (the under these metrics. made efforts to address some of these In addition, the Cures Act included Secretary) for health data, statistics, barriers in this proposed rule and privacy, and national health information provisions to advance interoperability through prior rules and actions, we and health information exchange, policy and HIPAA, conducted extensive believe there is still considerable work hearings in the first year after HIPAA including, for example, enhancements to be done to overcome some of these to ONC’s Health IT certification program was enacted to evaluate this and other considerable challenges toward HIPAA-related implementation issues. and a definition of ‘‘information achieving interoperability. blocking’’ (as discussed further in The NCVHS First Annual Report to the section VIII. of this proposed rule). 1. Patient Identifier and Interoperability Congress on the Implementation of the Administrative Simplification These provisions have been addressed In the Interoperability RFI in the FY in depth in ONC’s proposed rule ‘‘21st Provisions of the Health Insurance 2019 IPPS proposed rule (83 FR 20550), Portability and Accountability Act, Century Cures Act: Interoperability, we solicited feedback on positive Information Blocking, and the ONC February 3, 1998, outlines the NCVHS’ solutions to better achieve efforts to obtain feedback on the UPI Health IT Certification Program’’ interoperability or the sharing of health (published elsewhere in this issue of the (https://ncvhs.hhs.gov/wp-content/ care information between providers. A uploads/2018/03/yr1-rpt-508.pdf). Federal Register). number of commenters noted that the Through this process, NCVHS found a Section 4003 of the Cures Act added lack of a unique patient identifier (UPI) lack of consensus on how best to define a definition of ‘‘interoperability’’ as inhibited interoperability efforts a UPI and controversy around the use of paragraph 10 of section 3000 of the because, without a unique identifier for a UPI due to privacy and data security PHSA (42 U.S.C. 300jj (9)) (as amended). each patient, the safe and secure concerns. Those in favor of adopting a Under section 3000 of the PHSA, electronic exchange of health UPI believe a UPI is the most efficient ‘interoperability’, with respect to health information is constrained because it is way to foster information sharing and IT, means technology that enables the difficult to ensure that the relevant accurate patient record linking, where secure exchange of electronic health records are all for the same patient. those against it are concerned about information with, and use of electronic As part of efforts to reduce the patient privacy and data security. health information from, other health IT administrative costs of providing and NCVHS found these privacy and data without special effort on the part of the paying for health care, the Health security concerns outweighed the user. It also allows for complete access, Insurance Portability and benefits of a UPI. exchange, and use of all electronically Accountability Act of 1996 (HIPAA) The NCVHS recommended that the accessible health information for (Pub. L. 104–191, enacted August 21, Secretary not move forward with a authorized use under applicable state or 1996) required the adoption of a proposed rule on a patient identifier federal law and does not constitute ‘‘unique individual identifier for until further discussions could be had to information blocking as defined in healthcare purposes,’’ commonly fully understand the privacy and data section 3022(a) of the PHSA. referred to as a UPI. At the time HIPAA security concerns, as well as the full This definition aligns with the was enacted, HHS began to consider breadth of options beyond a single definition under MACRA and the HHS what information would be needed to identifier. NCVHS suggested the vision and strategy for achieving a develop a rule to adopt a UPI standard. Secretary work to maximize public health information ecosystem within An initial Notice of Intent to issue a participation in soliciting a variety of which all individuals and their health proposed rule on requirements for a options for establishing an identifier or care providers are able to send, receive, unique health identifier for individuals an alternative approach for identifying find, and use electronic health was published in the November 2, 1998 individuals and linking health information in a manner that is Federal Register (63 FR 61773–61774). information of individuals for health appropriate, secure, timely, and reliable Such an identifier has the potential to purposes. to support the health and wellness of facilitate the accurate portability of Appreciating the significant concerns individuals through informed shared health information by allowing correct raised by stakeholders regarding decision-making, as well as through patient matching because the universal implementing a UPI, Congress included patient choice of health plans and identifier allows for accurate and timely language in the Omnibus Consolidated providers. Accordingly, except where patient record linking between and Emergency Supplemental we further or otherwise specify for a providers across the care continuum Appropriations Act of 1999 (Pub. L. specific policy or purpose, when we use and it allows a patient’s complete record 105–277, enacted October 21, 1998) and the term ‘‘interoperability’’ within this to easily move with them from provider in each subsequent Appropriations bill, proposed rule we are referring to the to provider. However, stakeholders stating ‘‘None of the funds made definition in section 3000 of the PHSA. immediately raised significant concerns available in this Act may be used to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00192 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7615

promulgate or adopt any final standard generally done by using multiple www.patientmatchingchallenge.com/ under section 1173(b) of the Act (42 demographic data fields such as name, challenge-information/challenge- U.S.C. 1320d–2(b)) providing for, or birth date, gender, and address. The goal details). The goal of the Patient providing for the assignment of, a of patient matching is to link one Matching Algorithm Challenge was to unique health identifier for an patient’s data across multiple databases bring about greater transparency and individual (except in an individual’s within and across health care providers data on the performance of existing capacity as an employer or a health care in order to obtain a comprehensive view patient matching algorithms, spur the provider), until legislation is enacted of that patient’s health care information. adoption of performance metrics for specifically approving the standard.’’ ONC has stated that patient matching patient data matching algorithm This language has effectively prohibited is critically important to interoperability vendors, and positively impact other HHS from engaging in rulemaking to and the nation’s health IT infrastructure aspects of patient matching such as adopt a UPI standard. Consequently, the as health care providers must be able to deduplication and linking to clinical Secretary withdrew the Notice of Intent share patient health information and data. to pursue rulemaking on this issue on accurately match a patient to his or her We continue to support ONC’s work August 9, 2000 (https:// data from a different provider in order promoting the development of patient www.reginfo.gov/public/do/eAgenda for many anticipated interoperability matching initiatives. Per Congress’ ViewRule?pubId=200010&RIN=0938- benefits to be realized. guidance, ONC is looking at innovative AI91). Patient matching can be less precise ways to provide technical assistance to In recent years, concerns regarding than a UPI due to the reliance on private sector-led initiatives to further the privacy and security of information demographic attributes (such as name develop accurate patient matching have only increased. For example, in the and date of birth) which are not unique solutions in order to promote first quarter through third quarter of FY traits to a particular patient; further, interoperability without requiring a UPI. 2018 (October 1, 2017 through June 30, patient matching is often dependent on We understand the significant health 2018), 276 breach incidents were manual data entry and data maintained information privacy and security reported to the HHS Office of Civil in varying formats. Matching mistakes concerns raised around the Rights (OCR) affecting 4,341,595 can contribute to adverse events, development of a UPI standard and the individuals (https://ocrportal.hhs.gov/ compromised safety and privacy, and current prohibition against using HHS ocr/breach/breach_report.jsf). increased health care costs (see https:// funds to adopt a UPI standard. Although the appropriations language www.healthit.gov/sites/default/files/hie- Recognizing Congress’ statement regarding the UPI standard has interoperability/nationwide- regarding patient matching and remained unchanged, in the report interoperability-roadmap-final-version- stakeholder comments stating that a accompanying the 2017 appropriations 1.0.pdf). However, a wide range of patient matching solution would bill, Congress additionally stated, strategies and best practices currently accomplish the goals of a UPI, we seek ‘‘Although the Committee continues to being deployed across the industry have comment for future consideration on carry a prohibition against HHS using been shown to improve patient ways for ONC and CMS to continue to funds to promulgate or adopt any final matching rates, suggesting that patient facilitate private sector efforts on a standard providing for the assignment of matching approaches can be an effective workable and scalable patient matching a unique health identifier for an solution when appropriately strategy so that the lack of a specific UPI individual until such activity is implemented (see https:// does not impede the free flow of authorized, the Committee notes that www.healthit.gov/sites/default/files/ information. We also seek comment on this limitation does not prohibit HHS patient_identification_matching_final_ how we may leverage our program from examining the issues around report.pdf). authority to provide support to those patient matching. Accordingly, the Many stakeholders commenting on working to improve patient matching. In Committee encouraged the Secretary, the interoperability RFIs included in the addition, we intend to use comments for acting through ONC and CMS, to 2019 proposed payment rules indicated the development of policy and future provide technical assistance to private- that patient matching is a ‘‘core rulemaking. sector led initiatives to develop a functionality’’ of patient identification 2. Lack of Standardization coordinated national strategy that will and necessary to ensure care promote patient safety by accurately coordination and the best patient Lack of standardization inhibits the identifying patients to their health outcomes. Commenters also noted that a successful exchange of health information.’’ (H.R. Rep. No. 114–699, consistently used matching strategy information without additional effort on p. 110, https://www.gpo.gov/fdsys/pkg/ could accomplish the original goals of a the part of the end user. To achieve CRPT-114hrpt699/pdf/CRPT-114hrpt UPI with a diminished risk to secure exchange of health information 699.pdf). Congress has repeated this individual privacy and health across health IT products and systems guidance for 2018 and 2019. This information security. that can be readily used without special guidance directed HHS to focus on Several commenters noted that the effort by the user, both the interface examining issues around patient lack of a UPI impacted interoperability, technology and the underlying data matching and to provide technical but finding a suitable and consistent must be standardized, so all systems are assistance to private sector-led matching strategy could address this ‘‘speaking the same language.’’ initiatives focusing on a patient issue. These commenters often Consistent use of modern computing matching solution. specifically supported Congress’ standards and applicable content Unlike a UPI, which assigns a unique guidance to have ONC and CMS provide standards (such as clinical vocabularies) identifier—either numerical or technical assistance to the private sector are fundamental to achieving full-scale otherwise—to each patient, patient to identify this strategy. To help jump technical interoperability (systems can matching is a process by which health start the process of finding a solution to connect and exchange data unaltered) information from multiple sources is patient matching, ONC launched the and semantic interoperability (systems compared to identify common elements, Patient Matching Algorithm Challenge can interpret and use the information with the goal of identifying records in 2017, awarding six winners $75,000 that has been exchanged). Lack of such representing a single patient. This is in grants in late 2017 (https:// standards creates a barrier to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00193 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7616 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

interoperability. Where specific CFR part 162 and 42 CFR 423.160, and progress for those patients.4 standards are not consistently used, proposed by ONC for HHS adoption at Interoperable health IT can improve the particularly to structure exchange 45 CFR 170.213 (published elsewhere in ability of these facilities to coordinate interfaces such as APIs, the exchange is this issue of the Federal Register). and provide care; however, long-term more difficult and expensive than it Furthermore, we note that we intend to care and PAC providers, such as nursing needs to be and the recipient of continue to work with stakeholders to homes, home health agencies (HHAs), exchanged data must often undertake develop standards that will advance long-term care providers, and others, substantial special effort to make sense interoperability. were not eligible for the EHR Incentive of the information. Programs under the HITECH Act. Based In this proposed rule, similar to CMS’ 3. Information Blocking on the information we have, we Blue Button 2.0 approach for Medicare As explained above, information understand that this was a contributing FFS,3 we propose to require that all MA blocking is defined in section 3022(a) of factor to these providers not adopting organizations, Medicaid managed care the PHSA. Understanding this CEHRT at the same rate as eligible plans, CHIP managed care entities, definition, information blocking could hospitals and physicians, who were able Medicaid state agencies, CHIP agencies be considered to include the practice of to adopt CEHRT using the financial that operate FFS systems, and issuers of withholding data, or intentionally incentives provided under the QHPs in the FFEs, deploy standardized, taking action to limit or restrict the programs.56 open APIs to make certain information compatibility or interoperability of While a majority of skilled nursing available to enrollees as discussed in health IT. Through stakeholder facilities (SNFs) used an EHR in 2016 section III. of this proposed rule. outreach, roundtables, and letters we (64 percent), there is considerable work The lack of a sufficiently mature API have received, we understand that to be done to increase adoption and the functionality technical standard has health care providers may limit or exchange of data in this provider posed a challenge and impediment to prevent data exchange in an effort to population. In that same year, only three advancing interoperability. In 2015, retain patients. By withholding a out of 10 SNFs electronically exchanged ONC finalized an API functionality patient’s health information from (that is, sent or received) key clinical certification criterion in the ‘‘2015 competing health care providers, a health information, and only 7 percent Edition Health Information Technology health care provider can effectively had the ability to electronically send, (Health IT) Certification Criteria, 2015 inhibit a patient from freely moving receive, find, and integrate patient Edition Base Electronic Health Record within the health care market because health information. In 2017, an ONC (EHR) Definition, and ONC Health IT that patient would not otherwise have survey found that more HHA) (78 Certification Program Modifications’’ access to their complete health percent) adopted EHRs than SNFs (66 Final Rule (2015 Edition final rule) (80 information. percent), but integration of received FR 62602). However, while a consensus We additionally understand from information continued to lag behind for technical standard specific to the API stakeholder feedback that in certain both HHAs (36 percent) and SNFs (18 technical functionality was in cases a health IT vendor has prohibited percent). While both ONC surveys development, it had not yet matured the movement of data from one health focused on SNFs, it is important to note enough for inclusion in the 2015 Edition IT system to another in an effort to the large provider overlap between final rule, which does not identify a maintain their customer base. SNFs and other nursing facilities. In specific standard for API functionality. Information blocking is a significant 2014, 14,409 out of 15,640 (92 percent) As discussed in greater detail in threat to interoperability and can limit of nursing homes were certified for both section II of this proposed rule, we the ability for providers to coordinate Medicare and Medicaid.7 believe that a specific foundational care and treat a patient based on the Long-term hospitals, inpatient standard for API functionality has most comprehensive information rehabilitation facilities (IRFs), SNFs, matured sufficiently enough for ONC to available. In sections VIII.B. and C. of and HHAs are required to submit to propose it for HHS adoption (published this proposed rule we propose to CMS standardized patient assessment elsewhere in this issue of the Federal publicly report the names of clinicians data described in section 1899B(b)(1) of Register). To take full advantage of this and hospitals who submit a ‘‘no’’ the Act (as added by section 2(a) of the proposed standard, as well as already response to certain attestation Improving Medicare Post-Acute Care adopted standards applicable to content statements related to the prevention of Transformation Act of 2014 (IMPACT exchanged via APIs, we propose in information blocking in order to deter Act) (Pub. L. 113–185, enacted October sections II. and III. of this proposed rule health care providers from engaging in 6, 2014)). We have defined the term to require that MA organizations, conduct that could be considered ‘‘standardized patient assessment data’’ Medicaid managed care plans, Medicaid information blocking. (or ‘‘standardized resident assessment state agencies, CHIP managed care Preventing and avoiding information data’’ for purposes of SNFs) as patient entities, CHIP agencies that operate FFS blocking is important to advancing or resident assessment questions and systems, and QHP issuers in FFEs interoperability. We believe this comply with the ONC-proposed proposal would help discourage health 4 https://www.healthit.gov/sites/default/files/ electronic-health-record-adoption-and- regulations for this standard. Those care providers from information proposed regulations would require interoperability-among-u.s.-skilled-nursing- blocking and clearly indicates CMS’s facilities-in-2016.pdf. deployment of API technologies commitment to preventing such 5 https://aspe.hhs.gov/report/opportunities- conformant with the API technical practices. engaging-long-term-and-post-acute-care-providers- standard proposed by ONC for HHS health-information-exchange-activities-exchanging- adoption at 45 CFR 170.215 and other 4. Lack of Adoption/Use of Certified interoperable-patient-assessment-information/hit- applicable standards such as content Health IT Among Post-Acute Care (PAC) and-ehr-certification-ltpac. 6 https://www.healthit.gov/sites/default/files/pdf/ and vocabulary standards adopted at 45 Providers HIT_LTPAC_IssueBrief031513.pdf. PAC facilities are critical in the care 7 https://www.cms.gov/Medicare/Provider- 3 We refer readers to https://bluebutton.cms.gov Enrollment-and-Certification/Certification for more information related to the CMS Blue of patients’ post-hospital discharge, and andComplianc/Downloads/nursinghome Button initiative. can be a determining step in the health datacompendium_508-2015.pdf.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00194 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7617

response options that are identical in all Coordinated Care (RS2CC). In support of ONC for adoption by HHS and to use four PAC assessment instruments, and this effort, the HHS Office of Inspector content and vocabulary standards to which identical standards and General (OIG) released an RFI on adopted by HHS at 45 CFR part 162 and definitions apply. Section barriers to coordinated care or value- 42 CFR 423.160, and proposed by ONC 1899B(b)(1)(B) of the Act states that the based care, which was out for public for adoption by HHS at 45 CFR 170.213 categories for which standardized comment through October 26, 2018 (83 (published elsewhere in this issue of the patient or resident assessment data must FR 43607). Together, CMS and ONC are Federal Register). be submitted include, at a minimum, working to address information blocking Effective coordination and functional status; cognitive function; via rulemaking. We are actively working appropriate sharing of enrollee medical conditions and co-morbidities; to improve data standardization, information between health plans can special services, treatments and particularly through the use of APIs. reduce the need for providers to write interventions; and impairments. Section And, we are using available policy duplicative letters of medical necessity, 1899B(b)(1)(A) of the Act requires that levers to encourage greater adoption of or it could reduce instances of such data must be submitted through EHR technology and interoperability subjecting beneficiaries to unnecessary the applicable reporting provision that among PAC providers. We provide repetition of step therapy, or repeated applies to each PAC provider type using resources to help providers see how utilization reviews, risk screenings and the PAC assessment instrument that HIPAA and interoperability work assessments. It could also help to applies to the PAC provider. Section together. And, we are leveraging private streamline prior authorization 1899B(a)(1)(B) of the Act additionally sector relationships to find patient procedures or reduce instances where requires that these data be standardized matching solutions in lieu of a patient the clinician might need to intervene and interoperable so as to allow for their identifier. personally with a payer to ensure his or exchange among health care providers, her patient received the treatment F. Summary of Major Provisions including PAC providers, to ensure necessary. We are proposing to require coordinated care and improved To empower beneficiaries of Medicaid payers to support beneficiaries in Medicare beneficiary outcomes as these and CHIP FFS programs and enrollees coordinating their own care via payer to patients transition throughout the care in MA organizations, Medicaid and payer care coordination. In addition to continuum. To enable the interoperable CHIP managed care entities, and QHP existing care coordination efforts exchange of such information, we have issuers in the FFEs (when mentioned between plans, we propose that a plan adopted certain patient assessment data throughout this proposed rule, this must, if asked by the beneficiary, elements as standardized patient or includes QHPs certified by FFEs forward his or her information to a new resident assessment data and mapped regardless of whether enrollees enroll plan or other entity designated by the them to appropriate health IT standards through the FFE or off the FFE), we are beneficiary for up to 5 years after the which can support the exchange of this proposing several initiatives to break beneficiary has disenrolled with the information. For more information, we down the barriers that impede patients’ plan. Such transactions would be made refer the reader to the CMS website at ease of access to their electronic health in compliance with applicable laws. We https://del.cms.gov/DELWeb/pubHome. care information; we propose to create are proposing a requirement for MA and implement new mechanisms for Plans, Medicaid and CHIP Managed 5. Privacy Concerns and HIPAA them to access to their own health care Care entities (MCOs, PIHPs, PAHPs), The Privacy, Security, and Breach information, as well as the ability to and QHP issuers in FFEs to coordinate Notification Rules under HIPAA (45 decide how, when, and with whom to care between plans by exchanging, at a CFR parts 160 and 164) support share their information. We are minimum, the data elements in the interoperability by providing assurance proposing to require that a variety of United States Core Data for to the public that PHI as defined in 45 information be made accessible to these Interoperability (USCDI) standard 8 at CFR 160.103 is maintained securely and impacted patients via ‘‘openly enrollee request at specified times. shared only for appropriate purposes or published’’ (or simply ‘‘open’’) APIs– We believe that payers’ ability to with express authorization of the that is, APIs for which the technical and share enrollee claims, encounter data, individual. For more than a decade, the other information required for a third- utilization history, and clinical health HIPAA Rules have provided a strong party application to connect to them is information they may have for their privacy and security foundation for the publicly available. This will provide enrollees with one another, as well as health care system. However, we have these patients with convenient access to their ability to share that information heard that lack of harmonization their health care information in with patients and health care providers, between federal and state privacy and accordance with the HIPAA Privacy when approved by the patient and security standards can create Rule access standard at 45 CFR 164.524, appropriate under applicable law, using uncertainty or confusion for HIPAA and an increase in their choice of interoperable electronic means will covered entities that want to exchange applications with which to access and considerably improve patient access to health information. Resources about use their own electronic health information, reduce provider burden, how the HIPAA Rule permits health information, as discussed above, and and reduce redundant and otherwise care providers and health plans to share other information relevant to managing unnecessary data-related policies and health information using health IT for their health, enabling open APIs to procedures. We are proposing to require purposes like treatment or care improve competition and choice as they that all MA organizations, Medicaid and coordination is available on the HHS have in other industries. We propose to CHIP Managed Care entities (MCOs, OCR website. See https://www.hhs.gov/ require MA organizations, Medicaid PIHPs, and PAHPs), and QHP issuers in hipaa/for-professionals/privacy/ state agencies, state CHIP agencies, FFEs (with the exception of stand-alone guidance/permitted-uses/index.html. Medicaid managed care plans, CHIP dental plans (SADPs)) must participate Although barriers to interoperability managed care entities, and QHP issuers in a trusted health information exchange do exist, HHS and private industry are in FFEs (by requiring them to comply network meeting criteria for actively working to address them. On with the proposed ONC standard) to June 6, 2018, the HHS Deputy Secretary implement open APIs consistent with 8 For more information on the USCDI, see https:// initiated the Regulatory Sprint to the API technical standards proposed by www.healthit.gov/USCDI.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00195 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7618 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

interoperability. Further, we discuss an (with the exception of issuers of SADPs) Program. We discussed creating a set of approach to payer-to-payer and payer- such that each payer/plan issuer would priority health IT activities with a focus to-provider interoperability which make provider directory information on interoperability and simplification to leverages such existing trusts networks. publicly available via an API. reduce health care provider burden States and CMS routinely exchange Electronic patient event notifications while allowing flexibility to pursue data to support the administration of from hospitals, or clinical event innovative applications of health IT to benefits to Medicare-Medicaid dually notifications, are widely recognized as improve care delivery. We offered three eligible beneficiaries. This includes an effective tool for improving care different examples of activities which ‘‘buy-in’’ data on who is enrolled in coordination across settings, especially might be included under such an Medicare, and who is liable for paying for patients at admission, discharge, and approach, including: the dual eligible beneficiary’s Part A transfer. We are proposing to revise the • Participation in, or serving as, a and B premiums. Buy-in data exchanges conditions of participation for hospitals health information network which is support state, CMS, and Social Security (including short-term acute care part of the Trusted Exchange Administration (SSA) premium hospitals, long-term care hospitals Framework and Common Agreement accounting, collections, and enrollment (LTCHs), rehabilitation hospitals, (TEFCA); functions. This also includes ‘‘MMA’’ psychiatric hospitals, children’s • Maintaining an open API which data on dual eligibility status (called the hospitals, and cancer hospitals) and allows persistent access to third parties ‘‘MMA file’’ after the Medicare CAHs to require that these entities send which enables patients to access their Prescription Drug, Improvement and patient event notifications to another health information; and Modernization Act of 2003 (MMA) (Pub. health care facility or to another • Participating in piloting and testing L. 108–173, enacted December 8, 2003)), community provider. We propose to of new standards that support emerging which are used in all four Parts of limit this requirement to only those interoperability use cases. Medicare. We are proposing to establish Medicare- and Medicaid-participating While we are not proposing this here, frequency requirements to require all hospitals and CAHs that possess EHRs we expect to introduce a proposal for states to participate in daily exchange of systems with the technical capacity to establishing ‘‘interoperability activities’’ buy-in data with CMS by April 1, 2022, generate information for electronic in the FY 2020 IPPS/LTCH PPS and to update frequency requirements to patient event notifications. rulemaking in conjunction with other require all states to submit MMA file We also plan to test ways to promote updates to the Promoting data to CMS daily by April 1, 2022. interoperability across the health care Interoperability Program. To help We are actively working with our spectrum through models tested by the inform future rulemaking, we invite partners throughout HHS to deter the Center for Medicare and Medicaid comments on the concepts discussed practice of information blocking. We Innovation (‘‘Innovation Center’’). above, as well as other ideas for believe it would benefit patients to Innovation Center models offer a unique ‘‘interoperability activities’’ for which know if their health care providers opportunity to engage with health care eligible hospitals and CAHs could attested negatively to any of the providers and other entities in receive credit in lieu of reporting on prevention of information blocking innovative ways and to test concepts program measures. attestation statements under the Quality that have the ability to accelerate change Finally, we include two RFIs. One Payment Program (QPP) or the Medicare in the U.S. health care system, including related to interoperability and health IT FFS Promoting Interoperability to promote interoperability. As such, we adoption in PAC settings, and one Program. In previous testing with are soliciting public comment on related to the role of patient matching in patients and caregivers, we have learned general principles around interoperability and improved patient that effective use of CEHRT is important interoperability within Innovation care. to them when making informed health Center models for integration into new II. Technical Standards Related to care decisions. To address this issue, we models, through provisions in model Interoperability are proposing to publicly post participation agreements or other information about negative attestations governing documents. In applying these A. Technical Approach and Standards on appropriate CMS websites. general principles, we intend to be 1. Use of FHIR for APIs Section 4003 of the Cures Act sensitive to the details of individual recognized the importance of making model design, and the characteristics The MACRA defines interoperability provider digital contact information and capacities of the participants in as the ability of two or more health available through a common directory. each specific model. information systems or components to To facilitate this, CMS has updated the One of the many proposals we exchange clinical and other information National Plan and Provider considered but did not include in this and to use the information that has been Enumeration System (NPPES) to be able proposed rule was a proposal to make exchanged using common standards to capture this digital contact updates to the Promoting such as to provide access to longitudinal information. Now that the systems are Interoperability Program (formerly the information for health care providers in in place, we seek to increase the number Medicare and Medicaid EHR Incentive order to facilitate coordinated care and of clinicians with valid and current Programs) to encourage eligible improved patient outcomes. digital contact information available hospitals and CAHs to engage in certain Interoperability is also defined in through NPPES. We are proposing to activities focused on interoperability. section 3000 of the Public Health publicly identify those clinicians who This concept was initially introduced in Service Act (PHSA) (42 U.S.C. 300jj), as have not submitted digital contact a request for public comment in the FY amended by section 4003 of the Cures information in NPPES. Further, we are 2019 IPPS/LTCH PPS proposed rule (83 Act. Under that definition, proposing to align program FR 20537 through 20538). We discussed ‘‘interoperability’’, with respect to requirements for MA organizations, a possible future strategy in which we health IT, means such health IT that Medicaid state agencies, Medicaid would create a set of priority health IT enables the secure exchange of managed care plans, CHIP agencies that or ‘‘interoperability’’ activities that electronic health information with, and operate FFS systems, CHIP managed would serve as alternatives to measures use of electronic health information care entities, and QHP issuers in FFEs in the Promoting Interoperability from, other health IT without special

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00196 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7619

effort on the part of the user; allows for current and past medical conditions and beneficiaries, CHIP enrollees, and complete access, exchange, and use of care received, as well as information enrollees in QHPs in FFEs, by requiring all electronically accessible health that is of general interest and should be that MA organizations, Medicaid state information for authorized use under widely available, such as plan provider agencies, Medicaid managed care plans, applicable state or federal law; and does networks, the plan’s formulary, and CHIP agencies, CHIP managed care not constitute information blocking as coverage policies. entities, and QHPs in FFEs, adopt and defined in section 3022(a) of the PHSA, While many consumers today can implement ‘‘openly published’’ (or which was added by section 4004 of the often access their own electronic health simply ‘‘open’’) APIs. Having certain Cures Act. We believe the PHSA information through patient/enrollee data available through open APIs would definition is consistent with the portals and proprietary applications allow these enrollees to use the MACRA definition of interoperability. made available by various providers and application of their choice to access and As noted at the outset of this proposed health plans, they must typically go use their own electronic health rule, for the purposes of this proposed through separate processes to obtain information and other information rule and this specific section, we will access to each system, and often need to relevant to managing their health. use the PHSA definition. manually aggregate information that is Much like our efforts under the We believe the PHSA definition of delivered in various, often non- Medicare Blue Button 2.0 and interoperability is useful as a standardized, formats. The complex MyHealthEData initiatives, which made foundational reference for our approach tasks of accessing and piecing together Parts A, B, and D claims data available to advancing interoperability and this information can be burdensome and to Medicare beneficiaries, our proposal exchange of electronic health frustrating to consumers. would result in claims and coverage information for individuals throughout In contrast, consider the ease with information being accessible for the vast the United States, and across the entire which consumers can choose and use a majority of Medicare beneficiaries by spectrum of provider types and care navigation application which integrates requiring MA organizations to take new settings with which health plan issuers information on their current location, steps—by implementing the API and administrators need to efficiently preferences, and real-time traffic described in this proposed rule—to exchange multiple types of relevant conditions to choose the best route to a make claims data available to their data. We note the PHSA definition of chosen destination. Consumers do not enrollees. We expect that our proposal interoperability is not applied only to a have to log into a different ‘‘location’’ would also benefit all Medicaid specific program or initiative but to all portal to learn their current geographic beneficiaries because our proposal activities under the title of the PHSA coordinates, write them down, and then applies to Medicaid state agencies that establishes ONC’s responsibilities log into a separate ‘‘map’’ portal to enter (which administer Medicaid FFS to support and shape the health their current coordinates to request programs), and all types of Medicaid information ecosystem, including directions to their destination. managed care plans (MCOs, PIHPs, and exchange infrastructure for the United An API can be thought of as a set of PAHPs), and CHIP agencies (which States health care system as a whole. commands, functions, protocols, or administer CHIP FFS) and CHIP The PHSA definition of interoperability tools published by one software managed care entities (MCOs, PIHPs, is also consistent with HHS’s vision and developer (‘‘A’’) that enable other and PAHPs). Finally, while our proposal strategies for achieving a health software developers to create programs is only applicable to QHPs in FFEs, we information ecosystem within which all (applications or ‘‘apps’’) that can hope that states operating Exchanges individuals, their families, and health interact with A’s software without might consider adopting similar care providers are able to send, receive, needing to know the internal workings requirements for QHPs in State-Based find, and use electronic health of A’s software, all while maintaining Exchanges (SBEs), and that other payers information in a manner that is consumer privacy data standards. This in the private sector might consider appropriate, secure, timely, and reliable is how API technology enables the voluntarily offering data accessibility of to support the health and wellness of seamless user experiences associated the type included in this proposal so individuals through informed, shared with applications familiar from other that even more patients across the decision-making,9 as well as to support aspects of many consumers’ daily lives, American health care system can easily consumer choice of health plans and such as travel and personal finance. have and use such information to providers. Standardized, transparent, and pro- advance their choice and participation A core policy principle we aim to competitive API technology can enable in their health care. We hope that the support across all proposals in this similar benefits to consumers of health example being set by CMS will raise proposed rule is that every American care services.10 consumers’ expectations and encourage should be able, without special effort or While acknowledging the limits of our other payers in the market to take advanced technical skills, to see, obtain, authority to require use of APIs to similar steps to advance patient access and use all electronically available address our goals for interoperability and empowerment outside the scope of information that is relevant to their and data access, we are proposing in our proposed requirements. health, care, and choices—of plans, this rule to use our programmatic An ‘‘open API,’’ for purposes of this providers, and specific treatment authority in Medicare, Medicaid, CHIP, proposed rule, is simply one for which options. This includes two types of and over QHPs in FFEs to advance these the technical and other information information: Information specifically goals. Therefore, we are proposing to required for a third-party application to about the individual that requires require that a variety of data be made connect to it is openly published. Open appropriate diligence to protect the accessible to MA enrollees, Medicaid API does not imply any and all individual’s privacy, such as their applications or application developers 10 ONC has made available a succinct, non- would have unfettered access to 9 See, for example, ONC ‘‘Connecting Health and technical overview of APIs in context of consumers’ people’s personal or sensitive Care for the Nation: A Shared Nationwide access to their own medical information across information. Rather, an open API’s Interoperability Roadmap’’ Final Version 1.0 (2015): multiple providers’ EHR systems, which is available https://www.healthit.gov/sites/default/files/hie- at the HealthIT.gov website at https:// published technical and other interoperability/nationwide-interoperability- www.healthit.gov/api-education-module/story_ information specifically includes what roadmap-final-version-1Nor.0.pdf. html5.html. an application developer would need to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00197 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7620 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

know to connect to and obtain data fundamental to scale API-enabled managed care entities, and QHPs in available through the API. interoperability and reduce the level FFEs), supported by the suppliers of We recommend reviewing the and costs of custom development their API technology, and for the API discussion of the standardized API otherwise necessary to access, exchange, technology they use to comply with the criterion and associated policy and use health information. From an requirements we propose in this principles and technical standards industry standpoint, a consistent and proposed rule, be required to make included in ONC’s proposed rule ‘‘21st predictable set of API functions, as well freely and publicly accessible the Century Cures Act: Interoperability, as content and formatting standards, specific business and technical Information Blocking, and the ONC provide the health IT ecosystem with documentation necessary to interact Health IT Certification Program’’ known technical requirements against with these APIs. Thus, we propose to (published elsewhere in this issue of the which application developers can build require that these entities comply with Federal Register) for those seeking more applications (including but not limited the requirements that ONC has detailed information on API to ‘‘mobile apps’’) and other innovative proposed that the Secretary adopt for functionality and interoperability services which users can select to access developers and users of health IT standards relevant to electronic health and manage the data they need. certified to the API criteria at 45 CFR information. While that discussion is Therefore, to achieve interoperability 170.315 (published elsewhere in this specific to health IT certified under consistent with the PHSA definition, the issue of the Federal Register). ONC’s Health IT Certification Program proposals in section III. of this proposed c. Pro-Competitive rather than the information systems rule would effectively require that API generally used by payers and plan technologies deployed by health plans Pro-competitive practices in selecting, issuers for claims, encounters, or other subject to this rule use modern configuring, and maintaining APIs are administrative or plan operational data, computing standards (such as RESTful those business practices that promote it includes information applicable to interfaces 11 and XML/JSON), and the efficient access to, exchange of, and interoperability standards, as well as present the requested information using use of electronic health information to considerations relevant to establishing widely recognized content standards support a competitive marketplace that reasonable and non-discriminatory (such as standardized vocabularies of enhances consumer value and choice of terms of service for applications seeking clinical terms), where applicable. direct-to-consumer technology, health to connect to the open API. However, it coverage, and care. We believe that an is important to reiterate that we are not b. Transparent ultimate goal of all participants in the proposing to require health plan issuers Transparency and openness around health care ecosystem is that to use Health IT Modules certified API documentation is commonplace in individuals should be able to use an under ONC’s program to make many other industries and has fueled application they choose to connect and administrative data such as claims innovation, growth, and competition. access, without special effort, their history or provider directory Documentation associated with APIs electronic health information held by information available to enrollees. deployed by health care providers, health care providers, health plans, or In developing this proposed rule, we health plans, and other entities engaged any health information networks, within considered how to advance the sort of in exchanging electronic health practical and prudent limits that do not interoperability and innovation in the information typically addresses the needlessly hinder their ability to health system supported by open APIs information that would be material to connect to the API in a persistent in other industries. We have also persons and entities that use or create manner. collaborated with ONC to align with and software applications that interact with Such acceptable limits include leverage relevant API policies ONC has the API (API users). Information technical compatibility and ensuring the proposed to implement Cures Act material to API users includes, but is application does not pose an requirements. In general, we believe not necessarily limited to, all terms and unacceptable level of risk to a system three attributes of open APIs are conditions for use of the API, including when connecting to an API offered by particularly important to achieve the terms of service, restrictions, that system, consistent with the HIPAA goal of offering individuals convenient limitations, obligations, registration Privacy and Security Rules and access, through applications they process requirements, or other similar guidance issued by the HHS OCR,12 to choose, to available and relevant requirements that would be needed to: which the Secretary delegated the electronic health information. The three • Develop software applications to authority to enforce HIPAA privacy and API attributes are: interact with the API; security requirements. Organizational • The API technologies themselves, • Connect software applications to policies and procedures needed to not just the data accessible through the API to access electronic health comply with any additional them, are standardized; requirements under state laws that • information through the API; The APIs are technically • Use any electronic health would apply in a given situation would transparent; and also be viewed as necessary and not • information obtained by means of the The APIs are implemented in a pro- API technology; and anti-competitive. Examples of practices competitive manner. • Register software applications to In this section, we discuss these 12 connect with the API. OCR enforces federal civil rights laws, concepts generally and how they are conscience and religious freedom laws, the Health As discussed in section III. of this applicable in the health care context for Insurance Portability and Accountability Act of proposed rule, we are proposing that all payers, as well as explain how these 1996 (HIPAA) Privacy, Security, and Breach certain entities (MA organizations, State Notification Rules, and provisions of the Patient are relevant to our specific proposals, Medicaid agencies, Medicaid managed Safety and Quality Improvement Act of 2005 which are discussed in detail in section (PSQIA) and the Patient Safety Rule (codified at 42 care plan, State CHIP agencies, CHIP III. of this proposed rule. CFR part 3 (73 FR 70732)) protecting the confidentiality and privilege of patient safety work a. Standardized 11 ‘‘RESTful interfaces’’ are those that are product as defined in PSQIA and 42 CFR part 3. consistent with Representational State Transfer Thus, within HHS, OCR has lead responsibility for Technical consistency and (REST) architectural style and communications interpreting, administering, and enforcing HIPAA implementation predictability are approaches to web services development. regulations and developing guidance.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00198 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7621

we would view as pro-competitive to enable individuals to access their covered entity may not impose might include proactively advising health information must take reasonable unreasonable measures on an individual enrollees they are not required to use steps to ensure an individual’s requesting access that serve as barriers only the organization’s own or preferred information is only disclosed as to or unreasonably delay the individual applications to access, use, and share permitted or required by applicable law. from obtaining access to their PHI.16 their health information. Such advice The entity must take greater care in We refer readers to further OCR would be publicly available and include configuring and maintaining the guidance on related issues, including: information relevant to the enrollee security functionalities of the API and The liability of a covered entity in about how they could request access to the covered entities’ electronic responding to an individual’s access their information through a third-party information systems to which it request to send the individual’s PHI to application of their choosing. connects than would be needed if it was a third party (FAQ 2039); 17 individuals’ We recognize that organizations implementing an API simply to allow rights under HIPAA to have copies of subject to the open API requirements easier access to widely available public their PHI transferred or transmitted to proposed in section III. of this proposed information. them in the manner they request, even rule need to take reasonable and HIPAA covered entities and their if the requested mode of transfer or necessary steps to fulfill the business associates continue to be transmission is unsecure (FAQ 2060); 18 organizations’ duties under all responsible for compliance with the and, a covered entity’s obligation under applicable laws and regulations to HIPAA Rules, the Federal Trade the HIPAA Breach Notification Rule if it protect the privacy and security of Commission Act (FTC Act), and all transmits an individual’s PHI to a third personally identifiable information (PII), other laws applicable to their business party designated by the individual in an including but not limited to PHI under activities including but not limited to access request, and the entity discovers HIPAA as defined at 45 CFR 160.103; their handling of enrollees’ PHI and the information was breached in transit those privacy and security protection other data. As we state repeatedly (FAQ 2040).19 Under the HIPAA Privacy obligations remain applicable even in throughout this proposed rule, nothing Rule, as explained in OCR’s interpretive the context of complying with our in this proposed rule is intended to alter guidance, ‘‘individuals have the right proposal. However, we do not believe it or should be construed as altering under HIPAA to have copies of their is appropriate to use security and existing responsibilities to protect PHI PHI transferred or transmitted to them privacy concerns as an opportunity to under the HIPAA Rules and in the manner they request . . . as long engage in anti-competitive practices. requirements. as the PHI is ‘readily producible’ in the Anti-competitive practices might However, we note that a number of manner requested, based on the include declining to assess the technical stakeholders may believe that they are capabilities of the covered entity and compatibility or security risk of an responsible for determining whether an transmission or transfer in such a application provided to prospective application to which an individual manner would not present an enrollees by a competing plan, despite directs their PHI be disclosed applies unacceptable level of security risk to the an enrollee request to disclose their PHI appropriate safeguards for the PHI on the covered entity’s systems, to that application through the API. information it receives. Based on the such as risks that may be presented by OCR guidance discussed below, covered connecting an outside system, 2. Privacy and Security Concerns in the entities are not responsible under the application, or device directly to a Context of APIs HIPAA Rules for the security of PHI covered entity’s systems (as opposed to We have received a wide range of once it has been received by a third- security risks to PHI once it has left the 20 stakeholder feedback on privacy and party application chosen by an systems)’’ (HIPAA FAQ 2060). security issues in response to prior individual. We have also noted stakeholder proposals 13 about policies related to Under the HIPAA Privacy Rule,14 concerns about protections which apply APIs that would allow consumers to use individuals have the right of access to to non-covered entities such as direct- any app of their choosing to access PHI inspect and receive a copy of a defined held by a HIPAA covered entity. This index.html, and OCR HIPAA Guidance/FAQ–2037: set of their PHI as detailed at 45 CFR https://www.hhs.gov/hipaa/for-professionals/faq/ feedback includes concerns about 164.501. Specifically, as OCR has 2037/are-there-any-limits-or-exceptions-to-the- potential security risks to PHI created by indicated in regulations and guidance, individuals-right/index.html. an API connecting to third-party an individual can exercise their right of 16 See, generally, the ‘‘unreasonable measures’’ applications. access to direct a covered entity to send heading of OCR HIPAA for professionals information web page at https://www.hhs.gov/ We appreciate these concerns. their information to a third party. When hipaa/for-professionals/privacy/guidance/access/ Deploying API technology that offers responding to an access request, ‘‘the index.html. See also FAQ 2039—https:// consumers the opportunity to access same requirements for providing the www.hhs.gov/hipaa/for-professionals/faq/2039/ their electronic health information that what-is-the-liability-of-a-covered-entity-in- PHI to the individual, such as the responding/index.html; FAQ 2060: https:// is held by a covered entity (which timeliness requirements, fee limitations, www.hhs.gov/hipaa/for-professionals/faq/2060/do- includes but is not limited to MA prohibition on imposing unreasonable individuals-have-the-right-under-hipaa-to-have/ organizations, the Medicare Part A and measures, and form and format index.html; FAQ 2040: https://www.hhs.gov/hipaa/ B programs, the Medicaid program, requirements, apply when an individual for-professionals/faq/2040/what-is-a-covered- CHIP, QHP issuers on the FFE, and entitys-obligation-under/index.html. directs that the PHI be sent to another 17 https://www.hhs.gov/hipaa/for-professionals/ other health plan issuers) does not person or entity.’’ 15 Moreover, a faq/2039/what-is-the-liability-of-a-covered-entity-in- lessen the covered entity’s duties under responding/index.html. HIPAA and other law to protect the 14 More information on the Privacy Rule, 18 https://www.hhs.gov/hipaa/for-professionals/ privacy and security of information it including related rulemaking actions and additional faq/2060/do-individuals-have-the-right-under- holds, including but not limited to PHI. interpretive guidance, is available at https:// hipaa-to-have/index.html. www.hhs.gov/hipaa/for-professionals/privacy/ 19 https://www.hhs.gov/hipaa/for-professionals/ A covered entity implementing an API index.html. faq/2040/what-is-a-covered-entitys-obligation- 15 See § 164.524(c)(2) and (3), and 164.308(a)(1), under/index.html. 13 For instance, see discussion of stakeholder OCR HIPAA Guidance/FAQ–2036: https:// 20 https://www.hhs.gov/hipaa/for-professionals/ comments in the 2015 Edition final rule at 80 FR www.hhs.gov/hipaa/for-professionals/faq/2036/ faq/2060/do-individuals-have-the-right-under- 62676. can-an-individual-through-the-hipaa-right/ hipaa-to-have/index.html.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00199 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7622 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

to-consumer applications. Stakeholders, (including though not limited to HIPAA requirements, we were guided by an as well as covered entities who may be Privacy, Security, and Breach intent to have available through the API required to send PHI to these Notification Rules) that apply to the all of the individual’s electronic health applications, have noted concerns that organizations that would be subject to information held by the plan in unscrupulous actors could deploy our proposed regulations. Even if the electronic format that is compatible direct-to-consumer applications open API access requirements proposed with the API or that can, through specifically in order to profit from in section III.C. of this proposed rule automated means, be accurately obtaining, using, or disclosing were to be finalized and implemented, rendered compatible with individuals’ PHI (and potentially other the organization may still be called representation through the API. We information) in ways the individual upon to respond to individuals’ request were also guided by an intent to make either did not authorize or to which the for information not available through available through standardized, individual would not knowingly the API, or for all of their information transparent API technology all of the consent. through means other than the API. We provider directory and plan coverage When a non-HIPAA-covered entity encourage HIPAA covered entities or information that is held in formats discloses an individual’s confidential business associates to review the OCR readily compatible with the API. information in a manner or for a website for resources on the individual Both the API technology itself and the purpose not consistent with the privacy access standard at https://www.hhs.gov/ data it makes available must be notice and terms of use to which the hipaa/for-professionals/privacy/ standardized to support true individual agreed, the FTC has authority guidance/access/index.html to ensure interoperability. Therefore, we propose under the FTC Act to investigate and they understand their responsibilities. in section III.C.2.b. of this proposed rule take action against unfair or deceptive to require compliance with both (1) trade practices. The FTC has applied 3. Specific Technical Approach and Standards ONC’s 21st Century Cures Act proposed this authority to a wide variety of regulations regarding content and Achieving interoperability throughout entities. The FTC also enforces the FTC vocabulary standards for representing the health system is essential to Health Breach Notification Rule, which electronic health information and (2) achieving an effective, value-conscious applies to certain types of entities that technical standards for an API by which health system within which consumers fall outside of the scope of HIPAA, and the electronic health information must are able to choose from an array of therefore, are not subject to the HIPAA be made available. For the proposals 21 health plans and providers. An Breach Notification Rule. described in section III.C.2.b. of this We recognize that this is a complex interoperable system should ensure that proposed rule (which include purposes landscape for patients, who we consumers can both easily access their other than a HIPAA transaction, which anticipate will want to exercise due electronic health information held by diligence on their own behalf in plans and routinely expect that their is required to comply with standards reviewing the terms of service and other claims, encounter, and other relevant adopted at 45 CFR part 162), we are information about the applications they health history information will follow proposing these requirements to comply consider selecting. Therefore, we them smoothly from plan to plan and with interoperability standards propose in section III. of this proposed provider to provider without proposed for HHS adoption in ONC’s rule specific requirements on the payers burdensome requirements for them or 21st Century Cures Act proposed rule subject to these proposed regulations to their providers to reassemble or re- (published elsewhere in this issue of the ensure enrollees have the opportunity to document the information. Ready Federal Register). become more informed about how to availability of health information can be In proposing to require that regulated protect their PHI, important things to especially helpful when an individual entities comply with ONC-proposed consider in selecting an application, and cannot access their usual source of care, regulations (published elsewhere in this where they can lodge a complaint if for instance if care is needed outside issue of the Federal Register), and they believe a HIPAA covered entity or their regular provider’s business hours, therefore, use specified standards, we business associate may have breached while traveling, or in the wake of a intend to preclude regulated entities their duties under HIPAA or if they natural disaster. from implementing API technology believe they have been subjected to The specific proposals within this using alternative technical standards to unfair or deceptive actions or practices rule as described in section III.C.2. those ONC proposes for HHS adoption related to a direct-to-consumer would impose new requirements on MA at 45 CFR 170.215, including but not application’s privacy practices or terms organizations, state Medicaid and CHIP limited to those not widely used to of use. FFS programs, Medicaid managed care exchange electronic health information In some circumstances, information plans, CHIP managed care entities, and in the U.S. health system. We further that would be required to be made QHP issuers in FFEs (excluding issuers intend to preclude entities from using available through an API per an of SADPs) to implement standardized, earlier versions of the technical enrollee’s information request under transparent APIs. Using the API, these standards adopted at 45 CFR 170.215 by this proposed rule—which we view as entities would be required to provide requiring compliance with only consistent with the enrollee’s right of current and former enrollees with specified provisions of 45 CFR part 170 access from a covered entity under the certain claims and encounter data and and deliberately excluding others. Privacy Rule—may not be readily certain specific clinical information. Likewise, by proposing to require use of transferable through the API. For These entities would also be required to the content and vocabulary standards by instance, the covered entity may not make available through the API requiring compliance with 42 CFR hold certain information electronically. information already required to be 423.160 and 45 CFR part 162, and However, such a scenario would in no widely available, such as provider proposed at 45 CFR 170.213, we intend way limit or alter responsibilities and directory and plan coverage to prohibit use of alternative technical requirements under other law information. In developing our proposal standards that could potentially be used delineating the information that must be for these same data classes and 21 https://www.healthit.gov/sites/default/files/ available through an API consistent elements, as well as earlier versions of non-covered_entities_report_june_17_2016.pdf. with the proposed technical the adopted standards named in 42 CFR

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00200 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7623

423.160, 45 CFR part 162 and proposed those proposed by ONC for HHS law. Specifically, we propose the at 45 CFR 170.213. adoption is the best approach, we seek applicable entity must use: While we intend to preclude public comment on an alternative by • Content and vocabulary standard regulated entities from using content which CMS would separately adopt the ONC proposes for HHS adoption at 45 and vocabulary standards other than proposed ONC standards identified CFR 170.213 (USCDI Version 1) where those described in 42 CFR 423.160, 45 throughout this proposed rule, as well such standards are the only available CFR part 162, or proposed 45 CFR as future interoperability, content and standards for the data type or element; 170.213 and 170.215, we recognize there vocabulary standards. We anticipate • HIPAA Administrative may be circumstances which render the that any such alternative would include Simplification transaction standards use of other content and vocabulary incorporating by reference the FHIR and under 45 CFR part 162 or the Part D e- alternatives necessary. As discussed OAuth technical standards and the prescribing transaction standards at 42 below, we propose to allow the use of USCDI content and vocabulary standard CFR 423.160 where required by other other alternatives in two circumstances. (described in sections II.A.3.b. and applicable law, or where such standards First, where other content or vocabulary II.A.3.a. of this proposed rule, are the only available standards for the standards are expressly mandated by data type or element; or respectively) in CMS regulation, and • applicable law, we would allow for use replacing references to ONC regulations Where a specific data type or of those other mandated standards. at 45 CFR 170.215, 170.213, and element might be encoded or formatted Second, where no appropriate content 170.205, respectively. However, we using either a 45 CFR part 162 or 42 or vocabulary standard exists within 45 specifically seek comment on whether CFR 423.160 standard or the USCDI CFR part 162, 42 CFR 423.160, or this alternative would present an Version 1 standard at 45 CFR 170.213, proposed 45 CFR 170.213 and 170.215, unacceptable risk of creating multiple the applicable entity may use any of we would allow for use of any suitable regulations requiring standards or these content and vocabulary standards gap-filling options, as may be applicable versions of standards across HHS’ as determined appropriate for the data to the specific situation. programs, and an assessment of the type or element. We describe these proposals in more detail below. We are using two separate benefits or burdens of separately First, we propose in section III.C.2.b. rulemakings because ONC’s 21st adopting new standards and Century Cures Act proposed rule, which of this proposed rule to require incorporating updated versions of compliance with the ONC-proposed includes API interoperability standards standards in CFR text on a program by proposed for HHS adoption, would have regulations regarding the content and program basis. Furthermore, we seek vocabulary standard at 45 CFR 170.213 broader reach than the scope of this comment on: How such an option might proposed rule. At the same time, we as applicable to the data type or data impact health IT development element. This is the USCDI Version 1 set wish to assure stakeholders that the API timelines; how potentially creating standards required of MA organizations, of data classes that can be supported by multiple regulations regarding standards state Medicaid agencies, state CHIP commonly used standards, and over time across HHS might impact agencies, Medicaid managed care plans, establishes a minimum set of data system implementation; and other CHIP managed care entities, and QHP classes that would be required to be factors related to the technical aspect of issuers in FFEs under this proposal interoperable nationwide.22 The USCDI implementing these requirements. would be consistent with the API is designed to be expanded in an standards proposed by ONC for HHS B. Content and Vocabulary Standards iterative and predictable way over time. adoption because we would require that On behalf of HHS, ONC has proposed to the regulated entities follow specified, The HHS-adopted content and adopt the USCDI as a standard in its applicable provisions of the ONC- vocabulary standards applicable to the 21st Century Cures Act proposed rule proposed requirements. data provided through the API will vary (published elsewhere in this issue of the Requiring that regulated entities by use case and within a use case. For Federal Register). The USCDI Version 1 comply with the regulations regarding instance, content and vocabulary data sets proposed by ONC for HHS standards in ONC’s 21st Century Cures standards supporting consumer access adoption at 45 CFR 170.213 also Act proposed rule will support greater vary according to what specific data includes the standards that are interoperability across the health care elements MA organizations, state referenced by certification criteria that system, as health IT products and Medicaid and CHIP FFS programs, are also adopted in 45 CFR part 170, to applications that will be developed for Medicaid managed care plans, CHIP which health IT, such as Health IT different settings and use cases would managed care entities, and QHP’s in Modules presented for certification be developed according to a consistent FFEs have available electronically. under ONC’s Health IT Certification base of standards that supports more Where another law does not require use Program, must conform. Developers of seamless exchange of information. We of a specific standard, we are proposing applications are already familiar with welcome public comment on the to require use of, in effect, a catalogue and commonly using these standards in proposed required compliance with of content and vocabulary standards products that interact with ONC- regulations regarding standards in this from which the regulated entities may certified health IT. The payer and proposed rule to those proposed for choose in order to satisfy the proposed purchaser communities are also aware adoption by HHS through ONC’ 21st requirements in 42 CFR 422.119, 431.60, of and commonly using the 45 CFR part Century Cures Act proposed rule, as 457.730, 438.252, and 457.1233, and 45 170 standards, and many members of well as on the best method to provide CFR 156.221. these communities actively participate support in identifying and We propose in section III.C.2.b. of this in health-data-focused standards implementing the applicable content proposed rule that the applicable entity development organizations responsible and vocabulary standards for a given must comply with regulations regarding for the creation of these standards. As a data element. certain content and vocabulary result, we believe that compliance with Finally, while we believe that the standards for data available through the regulations requiring these standards for proposed required compliance with API, where applicable to the data type regulations regarding standards or data element, unless an alternate 22 For more information on the USCDI, see requirements in this proposed rule to standard is required by other applicable https://www.healthit.gov/USCDI.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00201 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7624 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

CMS’ programs should not add new Specifically, we believe payers should this issue of the Federal Register). By burdens to the industry. All standards use standards that are most efficient and requiring compliance with 45 CFR adopted within 45 CFR part 170, effective based on their existing 170.215, we are proposing in section including the USCDI standard ONC systems, data mapping considerations, III.C.2.b. of this proposed rule to require proposes for HHS adoption at 45 CFR or those standards that best meets use of the foundational Health Level 7 170.213, are, or are proposed by ONC to enrollees’ needs, while remaining (HL7®) 23 Fast Healthcare be incorporated by reference by HHS, at technically practicable for use in Interoperability Resources (FHIR®) 45 CFR 170.299 (published elsewhere in conjunction with API technology standard,24 several implementation this issue of the Federal Register). conformant to the 45 CFR 170.215 specifications specific to FHIR, and Second, we propose to require that proposed standards (published complementary security and app entities use standards specified at 45 elsewhere in this issue of the Federal registration protocols (OAuth 2.0 and CFR part 162 for HIPAA transactions as Register), and so long as such action is OpenID Connect Core). required by applicable law, as well as in accordance with applicable laws. For The FHIR standard holds great the standards specified at 42 CFR example, for data types for which 45 potential for supporting interoperability 423.160 for Part D e-prescribing CFR part 162 standards are the only and enabling new entrants and transactions, as required by applicable ones widely used throughout the payer competition throughout the health care law. We reiterate that this proposed rule community, and for specific content industry. FHIR leverages modern would not alter these other regulations, that payers typically only receive computing techniques to enable users to and should not be construed as altering according to these HIPAA standards, we access health care ‘‘resources’’ over the any organization’s compliance believe use of the 45 CFR part 162 internet via a standardized RESTful API. requirements for these other regulations. content standards to represent the Developers can create tools that interact The standards proposed in this information is appropriate and efficient with FHIR APIs to provide actionable regulation are intended for instances at this juncture. We note that for data data to their stakeholders. In the short where other statutes and regulations do made available through the API, entities time since FHIR was first created, the not dictate the standard by which subject to this proposal would be health care industry has rapidly regulated parties are to convey or required to use the standards identified embraced the standard through otherwise make available electronic in this proposal even if the exact substantial investments in industry information. information to be exchanged through pilots, specification development, and Where there is no legally mandated the API is also required to be available the deployment of FHIR APIs standard applicable to a specific data through other mechanisms. supporting a variety of business needs. type or data element in a particular Finally, we encourage payers or plans With the exception of the API Resource exchange context, and the HIPAA to implement additional, widely used, Collection in Health (ARCH) (proposed Administrative Simplification consensus-based standards identified by by ONC for HHS adoption at 45 CFR transaction standards under 45 CFR part other means—such as by HHS for other 170.215(a)(2)), the API technology 162 or the Part D e-prescribing purposes or through a consensus standards and implementation transaction standards at 42 CFR 423.160 standards development organization— specifications proposed at 45 CFR are the only standards available for a for additional data in their information 170.215 (published elsewhere in this specific data element or type, we systems for which no standard is issue of the Federal Register) are propose to require entities subject to adopted at 45 CFR part 162, 42 CFR consensus technical standards that, these proposals to use these HIPAA 423.160, or 45 CFR 170.213 to the extent under the National Technology Transfer standards when making data available feasible, while maintaining & Advancement Act of 1995 (Pub. L. through the API. We further clarify that, compatibility with the required API 104–113, enacted March 7, 1996) and for purposes of formatting, making technical standards. We also encourage OMB Circular No. A–119, are, where available, and sending electronic data entities to pilot emerging standards available and their use not under this proposed rule, we would identified by HHS, or by a consensus impracticable, preferred for use in require compliance with: (1) The standards development organization government programs over both content and vocabulary standards through development or approval for government-unique standards and identified in 45 CFR part 162 regardless trial use, where such a pilot maintains standards developed using less rigorous of whether the entities are covered compatibility with the proposed API entities, and (2) the Part D e-prescribing technical standards. However, MA consensus processes. standards in 42 CFR 423.160 to organizations, state Medicaid and CHIP We note that while all APIs that exchange e-prescribing and related data agencies, Medicaid managed care plans, would be used by software applications (such as drug formulary and preferred CHIP managed care entities, and QHPs to provide consumers access to their drug list data) regardless of whether in FFEs that choose to make non- electronic health information would be they are conducting a Part D e- standardized data available through required to adhere to the foundational prescribing transaction. their APIs would be required to ensure FHIR standard, and other essential Third, in information exchanges that their API documentation provides standards such as security protocols where applicable law does not mandate sufficient information to an application applicable to the data exchanged, we do a certain standard and where a specific developer for their applications to not anticipate that all of the standards, data type or element might be encoded handle this information accurately and implementation specifications, and or formatted using the 45 CFR part 162 automatically. We welcome public ® or 42 CFR 423.160 standard, or the 23 Health Level Seven International (HL7 ) is a comment on these proposals. not-for-profit, ANSI-accredited standards USCDI Version 1 standard at 45 CFR C. API Standard development organization (SDO) focused on 170.213, we propose in section III.C.2.b. developing consensus standards for the exchange, of this proposed rule that the regulated In section III.C.2.b. of this proposed integration, sharing, and retrieval of electronic entities subject to our proposal would rule, we propose to require compliance health information that supports clinical practice and the management, delivery and evaluation of have the freedom to provide data with the API technical standard health services. Learn more at ‘‘About HL7’’ web through the API that complies with any proposed by ONC for HHS adoption at page, last accessed 06/27/2018.) of these format or encoding standards. 45 CFR 170.215 (published elsewhere in 24 https://www.hl7.org/fhir/overview.html.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00202 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7625

protocols proposed at 45 CFR 170.215 These publicly available materials will to reduce fragmentation and preserve will be directly relevant to every use inform readers understanding of the efficacy—only the latest of the updated case reflected within the policies requirements under this proposed rule versions should be used. We will proposed in this rule. For example, and, we expect, will also assist publish subregulatory guidance to that authenticating end users’ identities may stakeholders in drafting comments effect. not be needed where the information submitted within this rulemaking For content and vocabulary standards requested and released to an application proceeding. at 45 CFR part 162 or 42 CFR 423.160, through the API is limited to As noted in our proposal in section we propose to allow the use of an information otherwise published, such III.C.2.b. of this proposed rule, we have updated version of the content or as provider directory information determined to align our proposal to the vocabulary standard adopted under this otherwise required by the programs’ types of data, technology use, and rulemaking, unless the use of the regulations to be made widely available. available standards that are consistent updated version of the standard is We note that an API implemented by with an overall HHS approach to prohibited for entities regulated by that regulated entities described in section support interoperability while part or the program under that section, III.C. of this proposed rule is not mitigating provider and developer or prohibited by the Secretary for required to be certified by ONC under burden by requiring compliance with purposes of these policies or for use in the ONC Health IT Certification Program applicable HHS regulations. We hope to ONC’s Health IT Certification Program, for the related certification criteria. see continued innovation and or is precluded by other applicable law. Furthermore, because the data required advancement in standards development For the content and vocabulary to be made available by an API as for identified gaps in health information standards proposed by ONC for HHS proposed in section III.C. of this data classes and data elements, as well adoption at 45 CFR 170.213 (USCDI proposed rule includes information as improved bi-directional patient Version 1),25 as well as for API beyond the USCDI Version 1 data set engagement functionalities. For interoperability standards proposed by (proposed by ONC for HHS adoption at example, we are not proposing to ONC for HHS adoption at 45 CFR 45 CFR 170.213), certification to the require that organizations subject to the 170.215 (including HL7 FHIR and other ONC certification criteria at 45 CFR requirements proposed in section III.C. standards discussed above),26 we 170.215 would not alone be sufficient to of this proposed rule offer patients or propose to allow the use of an updated ensure the API’s capacity to support the providers the ability through the API to version of a standard adopted by HHS, full range of data elements required write information directly to patient provided such updated version has been under the proposal in section III.C. of records held by the organization. approved by the National Coordinator this proposed rule. However, we hope that organizations through the standards version Finally, we are aware that the and their health IT developers build on advancement process described in implementation specifications currently the API technology we do propose to ONC’s 21st Century Cures Act proposed proposed by ONC for HHS adoption at require and accelerate innovation rule (published elsewhere in this issue 45 CFR 170.215 (published elsewhere in responsive to providers’ and patients’ of the Federal Register). this issue of the Federal Register), in calls for API write functionality at the As described in the ONC 21st Century complement to the base FHIR fastest pace practicable given the Cures Act proposed rule, under the foundational standards, leave maturity of needed standards. We proposed ONC Standards Version substantial work to be done by health IT believe this innovation may be fostered Advancement Process, ONC would developers and their customers to build by the concrete steps forward in data allow health IT developers participating and deploy technology to support the exchange and API capabilities we are in the ONC Health IT certification proposals described in section III.C.2.b. proposing to require across the program to voluntarily use updated of this proposed rule. Supplemental significant segment of payers subject to versions of adopted standards in their technical resources to support efficient this proposed rule. certified Health IT Modules, so long as and successful implementation of the D. Updates to Standards certain conditions are met. The foundational FHIR standard can be proposed Standards Version developed by a variety of organizations. In addition to our efforts to align Advancement Process flexibility gives standards across HHS, we recognize that However, we recognize that there may health IT developers the option to avoid while we must codify in regulation a be fewer applicable resources to support unnecessary costs and is expected to specific version of each standard, the the development required under this help reduce market confusion by need for continually evolving standards rule. Thus, HHS expects to provide enabling certified Health IT Modules to development has historically outpaced organizations subject to the policies keep pace with standards advancement our ability to amend regulatory text. In proposed in this proposed rule with and market needs. Once a standard has order to address how standards technical assistance and subregulatory been adopted for use in ONC’s Health IT development can outpace our guidance that incorporates feedback Certification Program through notice rulemaking schedule, we propose in from industry. We recommend readers and comment rulemaking, ONC would section III.C.2.b. of this proposed rule review ONC’s 21st Century Cures Act undertake an annual, open and proposed rule to fully understand the that regulated entities may use updated transparent process, including scope and detail of the API standard and versions of required standards if use of opportunity for public comment, to content and vocabulary standards the updated version is required by other timely ascertain whether a more recent proposed by ONC for HHS adoption applicable law. version of that standard or which apply to the proposals included In addition, under certain implementation specification should be in this proposed rule. We further circumstances, we propose to allow use approved for developers’ voluntary use. recommend readers review the publicly of an updated version of a standard if ONC expects to use an expanded section available resources available on the HL7 the standard is not prohibited under FHIR standard (https://www.hl7.org/ other applicable law. Where a single 25 For more information on the USCDI, see fhir/overview.html) and the USCDI standard is updated more than once in https://www.healthit.gov/USCDI. Version 1 standard (https:// a brief period of time and upon review 26 For more information on FHIR, see https:// www.healthit.gov/USCDI), respectively. of the standard HHS determines that— www.hl7.org/fhir/overview.html.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00203 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7626 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

of the Interoperability Standards III. Patient Access Through APIs picture of their health records. API technology can be an effective way to Advisory (ISA) web platform to A. Background on Medicare Blue Button facilitate the public transparency and share data because health information engagement process, and to publish We are committed to advancing from various sources can be retrieved each year’s final list of National interoperability, putting patients at the through these secure interfaces and Coordinator-approved advanced center of their health care, and ensuring consolidated by a single tool, such as a they have simple and easy access, versions that health IT developers could third-party application chosen by, in the without special effort, to their health elect to use consistent with the case of Medicare, the beneficiary or information. With the establishment of their caregiver. Standards Version Advancement the initial Medicare Blue Button® Process. (For more detail, please see The Medicare Blue Button 2.0 API is service in 2010, Medicare beneficiaries also expected to improve the Medicare section VIII.B.5. of ONC’s 21st Century became able to download their Part A, beneficiary experience by providing Cures Act proposed rule (published Part B, and Part D health care claims beneficiaries secure access to their elsewhere in this issue of the Federal data through MyMedicare.gov in either claims data in a standardized, Register).) We believe that permitting PDF or text format. While the original computable format. We recognize that the use of updates to standards at 45 Blue Button effort was a first step data security is of the utmost CFR 170.213 and 170.215 consistent towards liberating patient health importance and are dedicated to with the ONC Standards Version information, we recognize that safeguarding patient health information Advancement Process will enhance significant opportunities remain to so that only the beneficiary and their alignment and foster improved modernize access to that health authorized personal representative interoperability across the health information and the ability to share would have the ability to authorize system. health information across the health release of their health information ecosystem. We believe that moving to a In providing flexibility to the plans through Medicare Blue Button 2.0 to a system in which patients have access to third-party software application. and payers that will be required to and use of their health information will implement APIs that use the content Medicare Blue Button 2.0 will provide empower them to make better informed beneficiaries with a longitudinal view of and vocabulary standards identified in decisions about their health care. this proposed rule, we also believe it is their Medicare claims data, which can Additionally, interoperability, and the then be combined with other health important to maintain compatibility and ability for health information systems information within third party avoid a disruption or reduction in data and software applications to applications. One benefit of making availability to the end user. Entities communicate, exchange, and interpret records available via an API is that it subject to the proposed regulations health information in a usable and enables a beneficiary to pull Medicare seeking to use an updated version of a readable format, is vital to improving health information along with other standard must consider factors such as health care. Allowing access to health heath information into a single the impact of differences between information only through PDF and text application not dictated by any specific standards versions and the potential format limits the utility and sharing of health plan, provider, or portal. APIs burden on developers and end users to the health information. allow health information to move Medicare Blue Button 2.0 is a new, support transitioning between versions. through the health ecosystem with the modernized version of the original Blue We expect that these practical patient and ensure comprehensive and Button service. It enables beneficiaries considerations to maintain timely information is accessible even if to access their Medicare Parts A, B, and compatibility and avoid disruption will the patient changes health plans, D claims data and share that electronic discourage premature use of new providers, or both over time, facilitating health information through an versions of a standard. continuity of care. Application Program Interface (API) Therefore, we propose in section with applications, services, and research B. Expanding the Availability of Health III.C.2.b. of this proposed rule that an programs they select. As discussed in Information entity may use an updated version of a more detail in section II.A. of this 1. Benefits of Information Access required standard so long as use of the proposed rule, API technology allows updated version does not disrupt an end software from different developers to We believe there are numerous user’s ability to access the data available connect with one another and exchange benefits associated with individuals through the API proposed in section III. electronic health information in having simple and easy access to their of this proposed rule. Entities that electronic formats that can be more health care data under a standard that would be required to implement an easily compiled and leveraged by is widely used. Claims and encounter open API under this rulemaking would patients and their caregivers. data, used in conjunction with EHR be free to upgrade to newer versions of Beneficiaries may also select third-party data, can offer a broader and more holistic understanding of an the required standards, subject only to applications to compile and leverage individual’s interactions with the health those limiting conditions noted here, at their electronic health information to care system than EHR data alone. For any pace they wish. However, they must help them manage their health and engage in a more fully informed way in example, inconsistent benefit utilization continue to support connectivity, and their health care. patterns in an individual’s claims data, make the same data available, for end Medicare Blue Button 2.0 is expected such as a failure to fill a prescription or users using applications that have been to foster increased competition among receive recommended therapies, can built to support only the HHS-adopted technology innovators who serve indicate that the individual has had version(s) of the API standards. Medicare patients and their caregivers, difficulty adhering to a treatment We welcome public comment on this such as through finding better ways to regimen and may require less expensive proposed approach to allow voluntary use claims data to address their health prescription drugs or therapies, use of updated versions of these needs. Patients should have the ability additional explanation about the standards. to access their health information, in a severity of their condition, or other format of their choosing, to receive a full types of assistance. Identifying and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00204 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7627

finding opportunities to address the predict their consumers’ needs, we 2. Alignment With the HIPAA Right of individual’s non-adherence to a care believe it is important to position MA Access plan are critical to keeping people with organizations, Medicaid and CHIP The HIPAA Privacy Rule, at 45 CFR chronic conditions healthy and engaged managed care entities, and QHP issuers 164.524, provides that individuals have so they can avoid hospitalizations. in FFEs to do the same to encourage a right of access to inspect and obtain While a health plan can use claims and competition, innovation, and value. a copy of PHI, defined at 45 CFR encounter data to help it identify which Further, we believe that beneficiaries in 160.103, about them that is maintained enrollees could benefit from an Medicaid FFS programs administered by a health plan or covered health care assessment of why they are not filling by state Medicaid agencies and CHIP provider in a designated record set, their prescriptions or who might be at enrollees in both FFS and managed care defined at 45 CFR 164.501. The right of risk for particular problems, putting this should benefit from similar advances access also provides individuals with information into the hands of the and the benefits of innovation and the right to initiate disclosures to third individual’s chosen care provider—such value. parties. as the doctor or nurse practitioner CMS has programmatic authority over Software applications using the API prescribing the medications or the MA organizations, Medicaid programs proposed in 42 CFR 422.119, 431.60, pharmacist who fills the prescriptions— (both FFS and managed care), CHIP 438.242(b)(6), 457.730, 457.1233(d)(2), helps them to engage the patient in (including FFS and managed care), and and 45 CFR 156.221 would provide an shared decision making that can help QHP issuers in FFEs. This proposed rule additional mechanism through which address some of the reasons the seeks to leverage that CMS authority to the individuals in that coverage who so individual might not be willing or able make claims and encounter data choose can exercise the HIPAA right of to take medications as prescribed. By available to patients in these programs access to their PHI, by giving them a authorizing their providers to access the along with other plan data (such as simple and easy electronic way to same information through the open API, provider directory data) as detailed in request, receive, and share data that individuals can further facilitate sections III.C. and IV. of this proposed they want and need, including with a communication with their care teams. rule. We propose that regulated entities designated third party. However, as Enabling the provider to integrate make this data available in a discussed in section II of this proposed claims and encounter information with standardized format and through a rule, due to limitations in current EHR data gives the provider the ability specific technological means so that availability of interoperability standards to use the combined information, with third parties can develop and make for some types of data and patient’s relevant clinical decision support tools, available applications that make the rights to be granted access in the form as part of normal care delivery in a less data available for patient use in a and manner of their own choosing, the burdensome way, leading to improved convenient and timely manner. Our API requirement may not be sufficient care. This may be particularly important proposal would require compliance to support access to all of the health during times of system surge, for with specific regulations regarding information subject to the HIPAA right example, in the event of an event that interoperability standards adopted by of access because it may not all be generates a large and sudden demand the Secretary in implementing and transferable through the API. for health services, when access to such complying with the proposed C. Open API Proposal for MA, Medicaid, information may help to inform patient requirement to use an API to make this CHIP, and QHP Issuers in FFEs triage, transfer, and care decisions. data available. We are proposing to Further, consumers who have require compliance with 45 CFR 1. Introduction immediate electronic access to their 170.215 to require the API technical We are proposing to add new health information are empowered to standards that ONC is proposing for provisions at 42 CFR 422.119, 431.60, make more informed decisions when HHS adoption in its 21st Century Cures 438.242(b)(6), 457.730, 457.1233(d) and discussing their health needs with Act proposed rule (published elsewhere 45 CFR 156.221, that would, providers, or when considering in this issue of the Federal Register). respectively, require MA organizations, changing to a different health plan. In We are also proposing to require that the state Medicaid FFS programs, Medicaid many cases, claims and encounter data data elements made available through managed care plans, CHIP FFS can provide a more holistic and the proposed API technology must be programs, CHIP managed care entities, comprehensive view of a patient’s care formatted and presented in accordance and QHP issuers in FFEs (excluding history than EHR data alone. Whereas with applicable content and vocabulary issuers of SADPs) to implement, test, EHR data is frequently locked in closed, standards as described in section II. of and monitor an openly-published API disparate health systems, care and this proposed rule. This means that the that is accessible to third-party treatment information in the form of software receiving and using the data applications and developers. We note claims and encounter data is can readily consume the data to support that states with CHIPs are not required comprehensively combined in a consumer-friendly display and other to operate FFS systems and that some patient’s claims and billing history. functionalities. states’ CHIPs are exclusively operated Currently, not all beneficiaries enrolled Ultimately, the goal of this proposal is by managed care entities. We do not in MA plans have immediate electronic to require that patient data be made intend to require CHIPs that do not access to their claims and encounter available in a standardized format operate a FFS program to establish an data and those who do have it, cannot through an API, so that third parties can API; rather, these states may rely on easily share it with providers or others. develop and offer applications that their contracted plans, referred to The same is true of Medicaid make the data available in a convenient throughout this proposed rule as CHIP beneficiaries and CHIP enrollees, and timely manner for enrollees and managed care entities, to set up such a whether enrolled in FFS or managed beneficiaries in MA plans, Medicaid system. care programs, and enrollees in QHPs in and CHIP FFS and managed care The API would allow enrollees and FFEs. As industries outside of health delivery systems, and FFEs that are beneficiaries of MA organizations, care continue to integrate multiple specified in our proposal as detailed Medicaid and CHIP FFS programs, sources of data to understand and below. Medicaid managed care plans, CHIP

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00205 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7628 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

managed care entities, and QHP issuers managed care plans by providing • Denial or Discontinuation of Access in FFEs to exercise electronically their important details and context, thus to the API; HIPAA right of access to certain health enabling enrollees to make more • Enrollee and Beneficiary Resources information specific to their plan, informed, proactive decisions. Regarding Privacy and Security; through the use of common technologies Additionally, we believe that since • Exceptions or Provisions Specific to and without special effort. Common most of the information required to be Certain Programs or Sub-Programs; technologies, for purposes of our provided by these statutory sections of • Applicability and Timing; and • proposal, are those that are widely used the Act, such as the provider directory, Request for Information on and readily available, such as is currently accessible to enrollees and Information Sharing Between Payers computers, smartphones or tablets. potential enrollees electronically online, and Providers Through APIs. We are proposing that the API would making such standardized health We are proposing nearly identical be required to meet certain information available through the language for the regulations requiring interoperability standards, consistent proposed API could allow easy open APIs at 42 CFR 422.119; 431.60, with the API technical standards integration for use by more enrollees. and 457.730 and 45 CFR 156.221 for MA proposed by ONC for HHS adoption in Further, the proposal would enable organizations, Medicaid state agencies, its proposed rule (published elsewhere these enrollees to more easily share state CHIP agencies, and QHPs in FFEs; in this issue of the Federal Register), as their information with providers, Medicaid managed care plans would be well as to require the use of content and family, caregivers, and others. As a required at 42 CFR 438.242(b)(6), to comply with the requirement at 42 CFR vocabulary standards adopted by HHS general matter, providing important 431.60, and CHIP managed care entities and that the use of these standards details and context to patients gives would be required by 42 CFR would be applicable across the specific them more visibility into their treatment 457.1233(d)(2) to comply with the entities subject to proposed 42 CFR record through adjudicated claims, requirement at 42 CFR 457.730. As 422.119, 431.60, 438.242(b)(6), 457.730, allowing them to be true partners in discussed in detail in this proposed and 457.1233(d), and 45 CFR 156.221. their health care. This goal is related to rule, we are proposing similar if not In this context, these standards are the disclosure requirements in sections identical requirements for these various critical to ensure that enrollees of those 1852, 1932 and 2103 of the Act and our entities to establish and maintain an plans and programs have electronic proposal furthers each. open API, make specified data available access to their health information in We also believe the proposed API through that API, disclose API interoperable form and that access to allows for the administration of more documentation, provide access to the their health information and efficient and effective Medicaid and API, and make resources available to information about their coverage are not CHIP programs by taking advantage of enrollees. We believe that such nearly obstructed by, or confined to, certain commonly used methods of information identical text is appropriate here as the propriety systems. sharing and data standardization. reasons and need for the proposal and Under our proposal, the scope and Consumers routinely perform many the associated requirements are the volume of the information to be daily tasks on their mobile phones— same across these programs. Except as provided or made accessible through the banking, shopping, paying bills, open API would include: Adjudicated noted below with regard to specific scheduling—using secure applications. proposals, we intend to interpret and claims (including cost); encounters with We believe that obtaining their health capitated providers; provider apply the regulations proposed in this information should be just as easy, section, III.C. of this proposed rule, remittances; enrollee cost-sharing; and convenient, and user-friendly. Our clinical data, including laboratory similarly and starting with similar text proposal is a step toward that vision for is an important step to communicate results (where available). We propose enrollees in MA plans, Medicaid FFS that these programs and organizations, that to the applicable entities that would and managed care programs, CHIP FFS be required to comply. with the exception of the QHP issuers programs and managed care entities, in FFEs, would also be required to make In paragraph (a) of each of the and QHPs in FFEs. Finally, our proposal proposed regulations, we propose that information regarding provider includes a number of parameters and directories and formularies available the regulated entity (that is, the MA standards for the API and for adopting, organization, the State Medicaid or through the open API. Sections 1852(c), implementing, testing, and monitoring 1932(a)(5), and 2103(f)(3) of the Act CHIP agency, the Medicaid managed the API; the specific pieces of our require that MA organizations and care plan, the CHIP managed care entity proposal are addressed in turn in Medicaid MCOs, and CHIP managed or the QHP in an FFE, as applicable) sections III.C.2 of this proposed rule. care entities provide basic information would be required to implement and to their enrollees on how to get covered 2. The Open API Proposal maintain an open API that permits third-party applications to retrieve, with benefits in the plan and to facilitate This section outlines the components the approval and at the direction of the decision making about plan choice, of the open API proposal. Specifically, individual beneficiary, data specified in providers, and benefits. These statutory this section will discuss: provisions indicate information • Authority to require paragraph (b) of each regulation through enrollees could use to make decisions implementation of an open API; the use of common technologies and about their health care. The API • The API technical standard and without special effort from the proposals at 42 CFR 422.119(a), content and vocabulary standards; beneficiary. By ‘‘common technologies 438.242(b)(6), and 457.1233(d) support • Data Required To Be Available and without special effort’’ by the and complement existing Through the Open API & Timeframes for enrollee, we mean use of common implementation of these provisions in a Data Availability; consumer technologies, like smart robust and modern way. We believe the • Documentation Requirements for phones, home computers, laptops or health information that would be APIs; tablets, to request, receive, use and available through the proposed API • Routine Testing and Monitoring of approve transfer of the data that would would greatly supplement the benefit, Open APIs; be available through the open API provider directory, and, if applicable, • Compliance with Existing Privacy technology. By ‘‘without special effort,’’ formulary information from states and and Security Requirements; we codify our expectation that third-

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00206 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7629

party software, as well as proprietary the specifics of this proposal and how to provide further explanation as to how applications and web portals operated we propose to codify it at 42 CFR an open API proposal is necessary and by the payer could be used to connect 422.119, 431.60, 457.730, and 45 CFR appropriate in the MA program. Further, to the API and provide access to the 156.221, we refer only generally to 42 having easy access to their claims, data to the enrollee. In our proposed CFR 438.242(b)(6) and 457.1233(d)(2) encounter, and other health information regulations, we address the data that for this reason. would also facilitate beneficiaries’ must be made available through the API ability to detect and report fraud, waste, (1) Medicare Advantage in paragraph (b); the regulation and abuse—a critical component of an regarding the technical standards for the Sections 1856(b) and 1857(e) of the effective program. API and the data it contains in Act provide CMS with the authority to To the extent necessary, we also rely paragraph (c); the documentation add standards and requirements for MA on section 1860D–12(b)(3) of the Act to requirements for the API in paragraph organizations that the Secretary finds add provisions specific to the Part D (d); explicit authority for the payer necessary and appropriate and not benefit offered by certain MA regulated under each regulation to deny inconsistent with Part C of the Medicare organizations. For MA organizations or discontinue access to the API in statute; section 1852(c) of the Act that offer MA Prescription Drug plans, paragraph (e); and requirements for requires disclosure by MA organizations we are proposing requirements in 42 posting information about resources on of specific information about the plan, CFR 422.119(b)(2) regarding electronic security and privacy for beneficiaries in covered benefits, and the network of health information for Part D coverage. paragraphs (f) or (g). Additional providers; section 1852(h) of the Act That aspect of our proposal is also requirements specific to each program, requires MA organizations to provide supported by the disclosure discussed in sections IV. and V. of this their enrollees with timely access to requirements imposed under section proposed rule, are also included in medical records and health information 1860D–4(a) of the Act, which requires some of the regulations that address the insofar as MA organizations maintain Part D claims information, pharmacy API. such information. As technology directory information, and formulary We solicit comment on our use of evolves to allow for faster, more information to be disclosed to enrollees. virtually identical language in these efficient methods of information (2) Medicaid and CHIP regulations and our overall proposal to transfer, so do expectations as to what require implementation and is generally considered ‘‘timely.’’ We are proposing new provisions at maintenance of an open API. Currently, consumers across public and 42 CFR 431.60(a), 457.730, private sectors have become 438.242(b)(6), and 457.1233(d)(2) that a. Authority To Require Implementation increasingly accustomed to accessing a would require states administering of an Open API broad range of personal records, such as Medicaid FFS or CHIP FFS, Medicaid Our proposal would apply to MA bank statements, credit scores, and voter managed care plans, and CHIP managed organizations, Medicaid state agencies registrations, immediately through care entities to implement an open API and managed care plans, state CHIP electronic means and with updates that permits third-party applications agencies and managed care entities, and received in near real time. Thus, we authorized by the beneficiary or enrollee QHP issuers in FFEs. We note that our believe that in order to align our to retrieve certain standardized data. proposal for Medicaid managed care standards with 21st century demands, This proposed requirement would plans, at 42 CFR 438.242(b)(6), would we must take steps for MA enrollees to provide Medicaid beneficiaries’ and require MCOs, PIHPs, and PAHPs to have immediate, electronic access to CHIP enrollees simple and easy access comply with the regulation that we are their health information and plan to their information through common proposing for Medicaid state agencies at information. The proposed requirements technologies, such as smartphones, 42 CFR 431.60 as if that regulation in this rule are intended to achieve this tablets, or laptop computers, and applied to the Medicaid managed care goal. without special effort on the part of the plan. Similarly, we intend for CHIP We believe that the scope of the user. managed care entities to comply with information that would be made For Medicaid, we are proposing these the requirements we propose at 42 CFR available through an API under this new requirements under the authority 457.730 via the regulations proposed at proposal (described in section III. of this in section 1902(a)(4) of the Act, which 42 CFR 457.1233(d)(2). We propose to proposed rule) is consistent with the requires that a state Medicaid plan for structure the regulations this way to access and disclosure requirements in medical assistance provide such avoid ambiguity and to ensure that this section 1852 of the Act, and we rely on methods of administration as are found API proposal would result in consistent our authority in sections 1856(b) and by the Secretary to be necessary for the access to information for Medicaid 1857(e) of the Act, which provide CMS proper and efficient operation of the beneficiaries and CHIP enrollees, with the authority to add standards and plan and section 1902(a)(19) of the Act, regardless of whether they are in a FFS requirements for MA organizations, to which requires that care and services be delivery system administered by the require MA organizations to make provided in a manner consistent with state or in a managed care delivery specific types of information, at simplicity of administration and the system. CHIP currently adopts the minimum, accessible through an open best interests of the recipients. For Medicaid requirements at 42 CFR API and require timeframes for update CHIP, we propose these requirements 438.242 in whole. We propose revisions cycles. Throughout this section III.C. of under the authority in section 2101(a) of to 42 CFR 457.1233(d)(1) to indicate this proposed rule, we explain how and the Act, which sets forth that the CHIP’s continued adoption of 42 CFR why the open API proposal is necessary purpose of title XXI is to provide funds 438.242(a), (b)(1) through (5), (c), (d), and appropriate for MA organizations to states to provide child health and (e), while proposing specific text for and the MA program; the goals and assistance to uninsured, low-income CHIP managed care entities to comply purposes of achieving interoperability children in an effective and efficient with the regulations proposed at 42 CFR for the health care system as a whole are manner that is coordinated with other 457.1233(d)(2) in lieu of the proposed equally applicable to MA organizations sources of health benefits coverage. Medicaid revision, which would add 42 and their enrollees; thus, the discussion Together these provide us with CFR 438.242(b)(6). In our discussion of in section II of this proposed rule serves authority (in conjunction with our

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00207 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7630 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

delegation of authority from the percent of a State’s total annual CHIP without special effort, to their health Secretary) to adopt requirements for expenditures. information, including cost and Medicaid and CHIP that are necessary to payment information, also facilitates (3) Qualified Health Plan Issuers in ensure the provision of quality care in enrollees’ ability to detect and report Federally-Facilitated Exchanges an efficient and cost-effective way, fraud, waste, and abuse—a critical consistent with simplicity of We propose a new QHP minimum component of an effective program. administration and the best interest of certification standard at 45 CFR Existing and emerging technologies the beneficiary. 156.221(a) that would require QHP provide a path to make information and We believe that requiring state issuers in FFEs, not including SADPs, to resources for health and health care Medicaid and CHIP agencies and implement an open API that permits management universal, integrated, managed care plans/entities to take third-party applications, with the equitable, accessible to all, and steps to make Medicaid beneficiaries’ approval and at the direction of the personally relevant. Therefore, we and CHIP enrollees’ claims, encounters, individual enrollee, to retrieve believe generally certifying only health and other health information available standardized data concerning plans that make enrollees’ health through interoperable technology will adjudicated claims (including cost), information available to them in a ultimately lead to these enrollees encounters with capitated providers, convenient, timely, and portable way is accessing that information in a and provider remittances, enrollee cost- in the interests of qualified individuals convenient, timely, and portable way, sharing, and clinical data, including and qualified employers in the state or laboratory results (where available). We which is essential for these programs to states in which an FFE operates. We are also proposing to require that the be effectively and efficiently encourage SBEs to consider whether a data be made available to QHP enrollees administered in the best interests of similar requirement should be through common technologies, such as beneficiaries. Further, as noted in this applicable to QHP issuers participating smartphones or tablets, and without proposed rule, there are independent in their Exchange. special effort from enrollees. statutory provisions that require the We are proposing these new b. API Technical Standard and Content disclosure and delivery of information requirements under our authority in and Vocabulary Standards to Medicaid beneficiaries and CHIP section 1311(e)(1)(B) of the Patient We propose to require compliance enrollees; this proposal assists in the Protection and Affordable Care Act, as with proposed 45 CFR 170.215 at 42 implementation of those requirements amended by the Health Care and CFR 422.119(a) and (c), 431.60(a) and (c) in a way that is appropriate and Education Reconciliation Act of 2010 and 457.730(a) and (c), 438.242(b)(6) necessary in the 21st century. We (Pub. L. 111–148, enacted March 23, and 457.1233(d)(2), and 45 CFR believe making this information 2010, and Pub. L. 111–152, enacted 156.221(a) and (c), so that MA available in this format would result in March 30, 2010, respectively) organizations, Medicaid and CHIP FFS better health outcomes and patient (collectively referred to as the programs, Medicaid managed care satisfaction and improve the cost Affordable Care Act), which affords the plans, CHIP managed care entities, and effectiveness of the entire health care Exchanges the discretion to certify QHP issuers in FFEs implement open system, including Medicaid and CHIP. QHPs that are in the best interests of API technology conformant with the Having easy access to their claims, qualified individuals and qualified proposed API technical standards encounter, and other health information employers. Specifically, section 1311(e) (published elsewhere in this issue of the would also facilitate beneficiaries’ of the Affordable Care Act authorizes Federal Register) (see also section ability to detect and report fraud, waste, Exchanges to certify QHPs that meet the II.A.3. of this proposed rule). We further and abuse—a critical component of an QHP certification standards established propose to require compliance with the effective program. by the Secretary, and if the Exchange regulations regarding the following As technology has advanced, we have determines that making available such content and vocabulary standards for encouraged states, health plans, and health plan through such Exchange is in data available through the API, where providers to adopt various forms of the interests of qualified individuals applicable to the data type or data technology to improve the accurate and and qualified employers in the state or element, unless an alternate standard is timely exchange of standardized health states in which such Exchange operates. required by other applicable law: care information. This proposal would We believe there are numerous standards adopted at 45 CFR part 162 move Medicaid and CHIP programs in benefits associated with individuals and 42 CFR 423.160; and standards the direction of enabling better having access to their health plan data proposed by ONC for adoption by HHS information access by Medicaid that is built upon widely used at 45 CFR 170.213 (USCDI Version 1). beneficiaries and CHIP enrollees, which standards. The ability to easily obtain, See section II.A.3. of this proposed rule would make them active partners in use, and share claims, encounter, and for further information about our their health care through the exchange other health data enables enrollees to proposals regarding how entities subject of electronic health information by more effectively and easily use the to this rule would be required to utilize easily monitoring and sharing their data. health care system. For example, by these standards. We are proposing that By requiring that certain information be being able to easily access a both the API technical standard and the available in and through standardized comprehensive list of their adjudicated content and vocabulary standards formats and technologies, our proposal claims, the plan enrollee can ensure would be required across the MA moves these programs toward their providers know what services have program, Medicaid program, and CHIP, interoperability, which is key for data already been received, avoid receiving and by QHP issuers in FFEs (not sharing and access, and ultimately, duplicate services; and verify when including issuers of SADPs). improved health outcomes. As an prescriptions were filled. We believe Further, with the new proposed additional note, states will be expected these types of activities would result in requirements to implement and to implement the CHIP provisions using better health outcomes and enrollee maintain an API at 42 CFR 422.119(a), CHIP administrative funding, which is satisfaction and improve the cost 431.60(a), and 457.730(a), we are limited under section 2105(a)(1)(D)(v) effectiveness of the entire health care proposing corresponding requirements and 2105(c)(2)(A) of the Act to 10 system. Having simple and easy access, at proposed 42 CFR 422.119(c) for MA

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00208 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7631

plans, 431.60(c) for Medicaid FFS visit would save time during ONC’s 21st Century Cures Act proposed programs, and 457.730(c) for CHIP FFS appointments and ultimately improve rule (published elsewhere in this issue programs implementing the proposed the quality of care delivered to patients. of the Federal Register). API technology. In proposed paragraphs Most clinicians and patients have access Finally, we propose that use of an 42 CFR 422.119(c), 431.60(c), to the internet, providing many access updated standard by a payer that is 457.730(c), MA plans and the state points for viewing health information subject to these proposed regulations Medicaid or CHIP (for CHIP agencies over secure connections. We believe must not disrupt an end user’s ability to that operate FFS systems) agency would that these proposed requirements would be required to implement API significantly improve patients’ access the data available through the technology conformant with the experiences by providing a mechanism API proposed in section III. of this standards proposed by ONC for HHS through which they can access their proposed rule using an application that adoption at 45 CFR 170.215; for data data in a standardized, computable, and was designed to work with an API that available through the API, to use digital format in alignment with other conforms to the API standard proposed content and vocabulary standards public and private health care entities. under ONC’s 21st Century Cures Act adopted at 45 CFR part 162 and 42 CFR We also believe that these proposals are proposed rule (published elsewhere in 423.160, and proposed for adoption at designed to empower patients to have this issue of the Federal Register). 45 CFR 170.213; and to maintain and simple and easy access to their data in Entities that would be required to use the technology in compliance with a usable digital format, and therefore, implement an open API under this applicable law, including but not can empower them to decide how their rulemaking would be free to upgrade to limited to 45 CFR parts 162, 42 CFR part health information is going to be used. newer versions of the required 2, and the HIPAA Privacy and Security However, we remind payers that this standards, subject only to those limiting Rules. proposed regulation regarding the API conditions noted here, and at any pace We similarly propose at 45 CFR would not lower or change their they wish. However, they must continue 156.221(c) that QHP issuers in FFEs obligations as HIPAA covered entities to to support connectivity and make the must implement API technology comply with regulations regarding same data available to applications that conformant with the API technical standard transactions in 45 CFR part have been built to support only the standards proposed by ONC for HHS 162. adopted version(s) of the API standards. adoption at 45 CFR 170.215; for data As discussed in section II.A.3. of this For further discussion of these available through the API, use content proposed rule, we recognize that while proposals, see section II.A.3.D. of this and vocabulary standards adopted at 45 we must codify in regulation a specific proposed rule. CFR part 162 and 42 CFR 423.160, and version of each standard, the need for proposed for adoption at 45 CFR continually evolving standards c. Data Required To Be Available 170.213; and maintain and use the development has historically outpaced Through the Open API & Timeframes for technology in compliance with our ability to amend regulations. To Data Availability applicable law, including but not address how standards development can limited to 45 CFR part 162, 42 CFR part outpace our rulemaking schedule, we We propose the content that must be 2, and the HIPAA Privacy and Security offer several proposals. We propose that accessible for each enrollee of an entity Rules. regulated entities may use an updated subject to our open API proposal as set We believe that these proposals version of a standard where required by out at paragraph (b) of 42 CFR 422.119, would serve to create a health care other applicable law. We also propose 431.60, and 457.730 and 45 CFR information ecosystem that allows and that regulated entities may use an 156.221; as noted previously, the encourages the health care market to updated version of the standard where regulations for Medicaid managed care tailor products and services to better not prohibited by other applicable law, plans and CHIP managed care entities serve and compete for patients, thereby under certain circumstances. First, we cross-reference and incorporate the increasing quality, decreasing costs, and propose to allow the use of an updated regulations we propose for Medicaid empowering patients with information version of content or vocabulary and CHIP programs. We note that the that helps them live better, healthier standards adopted at 45 CFR part 162 or types of content proposed here would lives. Additionally, under these 42 CFR 423.160, unless the use of the represent the minimum threshold for proposals, clinicians would be able to updated version of the standard is compliance; at their discretion, MA review information on their patient’s prohibited for entities regulated by that organizations, state Medicaid and CHIP current prescriptions and services part or the program under that section, FFS programs, Medicaid managed care received by the enrollee on the is prohibited by the Secretary for plans, CHIP managed care entities, and enrollee’s smartphone. Also, the purposes of these policies, is prohibited QHP issuers in FFEs would have the enrollee could allow clinicians to access for use in ONC’s Health IT Certification option to use the API required by this such information by sharing data Program, or is prohibited by other proposed rule to make additional types received through the API with the applicable law. of health information or plan clinician’s EHR system—by forwarding Second, for the content and information available, exceeding these the information once the enrollee vocabulary standards proposed by ONC minimum requirements. receives it or by authorizing release of for HHS adoption at 45 CFR 170.213 the data through the API directly to the (USCDI Version 1), as well as for API We request comment on the data clinician’s EHR system. interoperability standards proposed by proposed to be made available as We also encourage payers to consider ONC for HHS adoption at 45 CFR detailed in the subsections below, the using the proposed API infrastructure as 170.215 (including HL7 FHIR and other appropriateness of the proposed a means to exchange PHI for other standards discussed above), we propose timeframes, and suggestions for health care purposes, such as to health to allow the use of an updated version, alternative timeframes that consider the care providers for treatment purposes. provided such updated version has been utility to the beneficiary, as well as Sharing interoperable information approved by the National Coordinator challenges that the proposed timeframe directly with the enrollee’s health care through the Standards Version may create for the entities that would provider’s EHR in advance of a patient Advancement Process described in have to comply.

VerDate Sep<11>2014 20:39 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00209 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7632 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

(1) Patient Claims and Encounter Data have to include all claims data rely on capitated providers submitting We propose that MA organizations, concerning adjudicated claims and their encounter data in a timely manner Medicaid and CHIP FFS programs, standardized encounter data from to ensure that patients receive a timely Medicaid managed care plans, CHIP providers (other than MCOs, PIHPs or and complete set of data. To the extent managed care entities, and QHP issuers PAHPs) that are paid using capitated providers do not submit in a timely in FFEs, permit third-party applications payments. The requirement for manner, there would be a delay in to retrieve, with the approval of an Medicaid managed care plans to provide patients having access to their data. We enrollee, certain specific data: encounter data is specified at 42 CFR recommend that MA organizations, adjudicated claims data, including 438.242(b)(6)(i); encounter data would Medicaid managed care plans, CHIP provider remittances and beneficiary or include any data from subcontractors managed care entities, and QHP issuers enrollee cost-sharing data; encounters and providers compensated by the in FFEs that would need this from capitated providers; and clinical managed care plan on the basis of information in order to meet the data, including laboratory results (but capitation payments, such as behavioral proposed API requirements should only if managed by the payer). health organizations, dental consider whether their contracts with Adjudicated claims data would include management organizations, and network providers should include on approved and denied claims; under pharmacy benefit managers. The API of timing requirements for the submission this proposal, adjudicated claims data Medicaid managed care plans would of encounter data and claims so that the have to include all claims and payer can comply with the API includes that for which the plan has encounter data would be included requirements. For Medicaid and CHIP made an initial payment decision even regardless if it is adjudicated or FFS programs, we encourage states to when the period during which an generated by the managed care plan consider other means to ensure that enrollee can file an appeal is still in itself, subcontractor, or provider necessary encounter data from providers effect, or when the enrollee has filed an compensated on the basis of capitation is also provided on a timely basis. appeal and is awaiting a reconsideration payments. All data would need to be We note that the data for claims and decision. We specifically request obtained in a timely manner to comply remittances that would be available comments from plans regarding the with these proposed requirements. through the API is much of the same feasibility of including such claims data, For CHIP agencies and managed care data that is required for the ASC X12 including any possible timing issues. In entities, claims data, encounter data, 837, ASC X12 835, and ASC X12 863 addition, the open APIs required for and reports of lab test results (if standards which are required for certain these entities must make available available) would be required transactions between certain entities formulary information (for MA–PD (specifically at 42 CFR 457.730(b)(1),(2), under 45 CFR 162.1102, 162.1602 and plans) or information about covered and (4)) through the API as soon as 162.1603, as well as the Part D eRx outpatient drugs and preferred drug lists possible but no later than one business transaction standards that use for (for state Medicaid and CHIP agencies, day. The proposal for CHIP state conveying prescription and Medicaid managed care plans and CHIP agencies (regarding FFS programs) and prescription-related information managed care entities). CHIP managed care entities is identical between Part D plans, providers, and Our proposal includes timeframe to the proposal for Medicaid State pharmacies as specified in 42 CFR requirements for making these various agencies (regarding FFS programs) and 423.160. As most claims are submitted categories of data available through the Medicaid managed care plans. For QHP to payers electronically utilizing these open API. For MA organizations, issuers in FFEs, our proposed regulation industry standard transaction types, we proposed 42 CFR 422.119(b)(1)(i), (1)(ii), at 45 CFR 156.221(b) would require believe this maximizes efficiency and and (2)(i) would require open API claims, encounter, and lab data to be reduces programming burden. As noted access to all claims activity pertaining to available within one business day of previously, our proposed regulation for adjudicated claims (including cost) and adjudication and receipt, respectively. Medicaid managed care plans at 42 CFR encounter data for benefits covered by These proposed timeframes would 438.242(b)(6) and for CHIP managed the plan (that is, Medicare Part A and ensure that data provided through the care entities at 42 CFR 457.1233(d)(2) Part B items and services, Part D API would be the most current data would require MCOs, PIHPs, and prescription drugs if covered by the MA available, which may be critical if the PAHPs to comply with the same plan, and any supplemental benefits) no data is provided by an enrollee to his or standard transaction types. later than one (1) business day after a her health care provider to use in Specifically regarding QHP issuers in claim is adjudicated or the encounter making clinical decisions. Under our FFEs, in 45 CFR 156.221(b)(1)(i) and (ii), data is received by the MA organization. proposal, the claims and encounter data we propose to require that QHP issuers For clinical data, including laboratory to be disclosed should include participating in an FFE make available results, MA organizations that manage information such as enrollee identifiers, through the API standardized data such data would be required under 42 dates of service, payment information concerning adjudicated claims CFR 422.119(b)(1)(iv) to provide access (provider remittance if applicable and (including cost) and encounters with through the open API to that data no available), and enrollee cost-sharing. capitated providers. Under proposed later than one business day after it is The ability for enrollees—created and paragraph (b)(1)(i), QHP issuers in FFEs received by the MA plan. For Medicaid facilitated by the API required under would be required to make available state agencies and managed care plans, our proposal—to access this information standardized adjudicated claim, claims data, encounter data, and clinical electronically would make it easier for provider remittance, and enrollee cost- data, including laboratory results (if them to take it with them as they move sharing data through the API within one available) would be required from payer to payer or among providers (1) business day after the claim is (specifically at 42 CFR 431.60(b)(1),(2), across the care continuum. processed. Under proposed paragraph and (4)) through the API no later than Regarding the provision of (b)(1)(ii), QHP issuers in FFEs would be one business day after the claim is standardized encounter data through the required to provide standardized processed or the data is received. For API within one (1) business day of the encounter data through the API within State Medicaid agencies in connection receiving the data, we note that this one (1) business day of the issuer with the FFS program, the API would proposal would mean that a payer must receiving the data.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00210 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7633

We are also considering requiring the information available through the API, propose at 42 CFR 422.119(b)(1)(iv) that encounter data to be available through including updated provider information MA organizations make clinical data, the API within a certain period after the no later than 30 calendar days after the such as laboratory test results available encounter, within one (1) business day state receives updated provider through the API if the MA organization after the encounter data is received. We information. As noted previously, our manages such data. Because we propose seek comment on what a reasonable proposed regulation for Medicaid in paragraph (c) that the USCDI period from the encounter date would managed care plans at 42 CFR standard, proposed by ONC for HHS be for us to consider as part of future 438.242(b)(6) and for CHIP managed adoption at 45 CFR 170.213, be used as rulemaking. In addition, we solicit care entities at 42 CFR 457.1233(d)(2) the content and vocabulary standard for comment on our authority to require would require MCOs, PIHPs, and this clinical data as provided in the API, MA organizations, States (for FFS PAHPs to comply with the same we intend our proposal to mean that the Medicaid programs and CHIP), standard, with the addition of specific data required under paragraph (b)(1)(iv) Medicaid and CHIP managed care plans, provider directory information as noted be the same as the data that is specified and QHPs in the FFEs to require in 42 CFR 438.242(b)(6)(ii) and in that content and vocabulary standard. submission of such data on a particular 457.1233(d)(2)(ii). For Medicaid In effect, we are proposing any clinical timeframe. managed care plans and CHIP managed data included in the USCDI standard, care entities, the provider directory (2) Provider Directory Data proposed by ONC for HHS adoption at information available through the API 45 CFR 170.213, be available through We are also proposing at 42 CFR must include all information that is the API if such data is managed by the 422.119(b)(1)(iii), 431.60(b)(3), specified in 42 CFR 438.10(h)(1) for MA organization. We recognize that 438.242(b)(6)(ii), 457.730(b)(3), and disclosure to managed care enrollees. some MA organizations receive this 457.1233(d)(2)(ii) that the required API We note that we have proposed that the information regularly or as a part of make available provider directory data, API be updated with new provider their contracted arrangements for health including updates to such data. Our directory information within 30 services, but that not all MA proposal at 45 CFR 156.221 would not calendar days from when the updated organizations do. Therefore, this require QHP issuers to permit third- information is received by the State (or proposed requirement applies to MA party retrieval of provider directory and the managed care plan under 42 CFR organizations, regardless of the type of preferred drug list information because 438.242(b)(6) and 457.1233(d)(2)) to be MA plan offered by the MA such information is already required to consistent with existing Medicaid organization, but only under be provided by QHPs in FFEs. managed care rules at 42 CFR circumstances when the MA For MA organizations, at proposed 42 438.10(h)(3). We propose that the API organization receives and maintains this CFR 422.119(b)(1)(iii), we propose to implemented by the State Medicaid specify that MA organizations make data as a part of its normal operations. agency would include the data elements This proposed requirement aligns with specific provider directory information specified for disclosure by Medicaid for their network of contracted existing regulations at 42 CFR 422.118, state agencies in section 1902(a)(83) of which require MA organizations to providers accessible through their APIs: the Act; we propose in 42 CFR The names of providers; addresses; disclose to individual enrollees any 438.242(b)(6)(ii) that the API medical records or other health or phone numbers; and specialty. This implemented by Medicaid managed care information is the same information MA enrollment information the MA plans would have the data elements organizations maintain with respect to organizations are already required to specified for disclosure at 42 CFR disclose to their enrollees under 42 CFR their enrollees. We propose that this 438.10(h)(1). For CHIP agencies that data be available in the API no later 422.111(b)(3) and make available online operate FFS systems and CHIP managed under 42 CFR 422.111(h)(2)(ii). MA than 1 business day from its receipt by care entities at 42 CFR 457.730(b)(3) and the MA organization. organizations would be required to 457.1233(d)(2)(ii), respectively, we have ensure the availability of this also proposed 30 calendar days. Similarly, the proposed regulations information through their APIs for all We are not proposing a similar for Medicaid and CHIP FFS programs MA plans. Including this information in requirement for QHP issuers in FFEs. and managed care plans (proposed 42 an open API allows non- MA third-party These issuers are already required, CFR 431.60(b)(4) and 457.730(b)(4)), applications to consume, aggregate, and under 45 CFR 156.230(c) and require provision of standardized data display plan data in different contexts, implementing guidance, to make for clinical data, including laboratory allowing patients to understand and provider directory information results, through the API, if available, no compare plan information in a way that accessible in a machine-readable format. later than one (1) business day after a can best serve their individual needs. Because this information is already claim is adjudicated or the data is MA plans would be required to update highly accessible in this format, we do received (by the state or the managed provider directory information available not believe the benefits of making it also care plan/entity). This would ensure through the API no later than 30 available through an open API outweigh that data provided through the API calendar days after changes to the the burden for QHP issuers in FFEs. would be the most current data provider directory are made. In However, we seek comment as to available, which may be critical if the addition, we are adding a new MA whether this same requirement should data is being shared by an enrollee with contract requirement at 42 CFR apply to QHP issuers, or if such a a health care provider who is basing 422.504(a)(18) specifying that MA requirement would be overly clinical decisions on the data. Like organizations must comply with the burdensome for them. proposed 42 CFR 422.119(c), these requirement for access to health data We request comment on these Medicaid and CHIP regulations propose and plan information under 42 CFR proposals. compliance with the regulations 422.119. regarding the USCDI standard, proposed Under proposed 42 CFR 431.60(b)(3) (3) Clinical Data Including Laboratory by ONC for HHS adoption at 45 CFR and 457.730(b)(3), state Medicaid and Results 170.213, as the content and vocabulary CHIP agencies respectively would be Regarding the provision of clinical standard for the clinical data available required to make provider directory data, including laboratory results, we through the API; therefore, we are, in

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00211 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7634 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

effect, proposing any clinical data prescription drug claims would have to develop applications technically included in the USCDI standard, be made available through the API no compatible with the organization’s API. proposed by ONC for HHS adoption at later than 1 business day of the MA–PD Transparency is also needed so that 45 CFR 170.213, be available through plan’s receipt of that information, we third-parties can understand how to the API. For state agencies managing are not proposing a specific timeframe successfully interact with an Medicaid or CHIP FFS programs, such for pharmacy directory or formulary organization’s API, including by data must be included through the API information to be available (or updated) satisfying any requirements the under our proposal only if the state through the API. We intend that the organization may establish for manages clinical data. Our proposed requirements in 42 CFR part 423 verification of developers’ identity and regulation for Medicaid managed care requiring when and how information their applications’ authenticity, plans at 42 CFR 438.242(b)(6) and CHIP related to pharmacy directories be consistent with its security risk analysis managed care entities at 42 CFR updated will apply to the provision of and related organizational policies and 457.1233(d)(2) would require MCOs, this information through the API; we procedures to ensure it maintains an PIHPs, and PAHPs to comply with the solicit comment specifically whether we appropriate level of privacy and security same standard in terms of the scope of should address this in the regulation protection for data on its systems. information and the timing of its text or otherwise impose a time-frame Specifically, at 42 CFR 422.119(d), availability through the API; the for this information to be made available 431.60(d), 457.730(d), and 45 CFR limitation about the availability of through the API. 156.221(d), we propose virtually clinical data through the API would At proposed 42 CFR 431.60(b)(5), for identical text to require publication of carry through to managed care plans Medicaid FFS programs, and at 42 CFR complete accompanying documentation and entities under our proposal. 457.730(b)(5) for CHIP FFS programs, regarding the API by posting this Proposed 45 CFR 156.221(b)(3) states would be required to include and documentation directly on the requires QHP issuers in FFEs to also update covered outpatient drug lists applicable entity’s website or via a make available, with the approval of the (including, where applicable, preferred publicly accessible hyperlink. As enrollee, clinical data, including drug lists) through the API no later than previously discussed, Medicaid laboratory results, if the QHP maintains one (1) business day after the effective managed care plans would be required such data. date of the information or any changes. by 42 CFR 438.242(b)(6) to comply with We recognize not all of the entities We are proposing to set this timeframe the requirement at 42 CFR 431.60(d), subject to this requirement have at one (1) business day because we and CHIP managed care entities would uniform access to this type of data and believe that it is critical for beneficiaries be required by 42 CFR 457.1233(d)(2) to seek comment on what barriers exist and prescribers to have this information comply with the requirement at 42 CFR that would discourage them from as soon as the information is applicable 457.730(d). In requiring that this obtaining, maintaining, and sharing this to coverage or in near real time since documentation is ‘‘publicly accessible,’’ data. We request comment on these this information could improve care and we expect that any person using proposals. health outcomes. Having timely data is commonly available technology to (4) Drug Benefit Data, Including particularly important during urgent or browse the internet could access the Pharmacy Directory, and Formulary emergency situations. Medicaid information without any preconditions Data managed care plans and CHIP managed or additional steps beyond downloading care entities would be required to and using a third-party application to We are also proposing that drug comply with these requirements as well access data through the API. This is not benefit data, including pharmacy under proposed 42 CFR 438.242(b)(6) intended to preclude use of links the directory information and formulary or and 457.1233(d)(2). We also note that user would click to review the full text preferred drug list data, also be available adjudicated claims and encounter data of lengthy documents or access sources through the API at proposed 42 CFR referenced in 42 CFR 431.60(b)(1) and of additional information, such as if the 422.119(b)(2)(ii) and (iii), 431.60(b)(5), (2), 438.242(b)(6), and 457.730(b)(1) and technology’s supplier prefers to host and 457.730(b)(5). As previously (2) include claims and encounter data technical documentation at a discussed, Medicaid managed care for covered outpatient drugs. To the centralized location. Rather, we mean plans would be required by 42 CFR extent that a state or managed care plan ‘‘additional steps’’ to include actions 438.242(b)(6) to comply with the utilizes a pharmacy benefit manager such as: Collecting a fee for access to the requirement at 42 CFR 431.60(b)(5), and (PBM), we anticipate that, as a practical documentation; requiring the reader to CHIP managed care entities would be matter, the state or managed care plan receive a copy of the material via email; required by 42 CFR 457.1233(d)(2) to would need to obtain the data from the or requiring the user to read comply with the requirement at 42 CFR PBM in a timely manner to comply with promotional material or agree to receive 457.730(b)(5). these proposed requirements. future communications from the We propose at 42 CFR We request comment on these organization making the documentation 422.119(b)(2)(ii) and (iii) that MA proposals. available. We specifically solicit organizations offering MA–PD plans d. Documentation Requirements for comments on these points. make available pharmacy directory data, We propose that the publicly APIs including the number, mix, and accessible documentation would be addresses of pharmacies in the plan We are proposing that the specific required to include, at a minimum, the network, as well as formulary data business and technical documentation following information: including covered Part D drugs and any necessary to interact with the proposed • API syntax, function names, tiered formulary structure or utilization APIs be made freely and publicly required and optional parameters management procedure which pertains accessible. As discussed in section supported and their data types, return to those drugs. The pharmacy directory II.A.1 of this proposed rule, we believe variables and their types/structures, information is the same information that transparency about API technology is exceptions and exception handling MA–PD plans—like all Part D plans— needed to ensure that any interested methods and their returns. must provide on their websites under 42 third-party application developer can • The software components and CFR 423.128(b)(5) and (d)(2). While easily obtain the information needed to configurations an application must use

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00212 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7635

in order to successfully interact with the APIs to ensure they are functioning authorization and authentication API (for example, to connect and receive properly, especially with respect to their mechanisms provide sufficient data through the API) and process its privacy and security features. Under our protections to enrollee PHI and that they response(s). proposal, MA organizations, Medicaid function as intended. We specifically • All applicable technical and CHIP FFS programs, Medicaid request public comment on whether requirements and attributes necessary managed care plans, CHIP managed care existing privacy and security standards, for an application to be registered with entities, and QHP issuers in FFEs would including but not limited to those in 45 any authorization server(s) deployed in have to implement, properly maintain, CFR part 164, are sufficient with respect conjunction with the API. update (as appropriate), and routinely to these proposals, or whether We note that these information test authentication features that will be additional privacy and security requirements are similar to those ONC used to verify the identity of individual standards should be required by CMS as has proposed for adoption by HHS for enrollees who seek to access their part of this proposal. developers and users of health IT claims and encounter data and other g. Issues Related to Denial or certified to the API criteria proposed at PHI through the API. Similarly, Discontinuation of Access to the API 45 CFR 170.315 (published elsewhere in compliance with our proposed this issue of the Federal Register), but requirements would mean that these As discussed in section II.A of this are proposed here to apply specifically entities must implement, maintain, proposed rule, HIPAA covered entities to the API technology deployed by update (as appropriate), and routinely must comply with patients’ requests to organizations subject to the API test authorization features to ensure an receive their data under the HIPAA requirements proposed in section III. of individual enrollee or their personal Right of Access, including having to this proposed rule. We request representative can only access claims transmit patient data to a third party. As comments on this proposal. and encounter data or other PHI that noted in guidance from OCR, disagreement with the individual about e. Routine Testing and Monitoring of belongs to that enrollee. As is the case the worthiness of the third party as a Open APIs under existing HIPAA requirements, where an enrollee is also a properly recipient of PHI, or even concerns about At 42 CFR 422.119(c)(2), 431.60(c)(2), designated personal representative of what the third party might do with the 457.730(c)(2), and 45 CFR 156.221(c)(2) another enrollee, the HIPAA covered PHI, are not grounds for denying a for MA organizations, state Medicaid entity must provide for appropriate request.27 However, a covered entity is and CHIP FFS programs, and QHP access to the information of the enrollee not expected to tolerate unacceptable issuers in FFEs, respectively, we are that has designated the personal levels of risk to the PHI held by the proposing that the API be routinely representative, just as they would if the covered entity in its systems, as tested and monitored to ensure it is personal representative were an enrollee determined by its own risk analysis.28 functioning properly, including of the same plan. Accordingly, it may be appropriate for assessments to verify that the API is Similarly, at proposed 45 CFR an organization to deny or terminate fully and successfully implementing 156.221(c)(2), QHP issuers in FFEs specific applications’ connection to its privacy and security features such as would be required to routinely test and API under certain circumstances in but not limited to those minimally monitor their API to confirm that it is which the application poses an required to comply with the HIPAA functioning properly. unacceptable risk to the PHI on its privacy and security requirements in 45 We request comment on these systems or otherwise violates the terms CFR part 164, 42 CFR parts 2 and 3, and proposals. of use of the API technology. other applicable law protecting privacy At 42 CFR 422.119(e), 431.60(e), and security of individually identifiable f. Compliance With Existing Privacy and 438.242(b)(6), 457.730(e), 457.1233(d)(2) health information. Medicaid managed Security Requirements and 45 CFR 156.221(e) for MA care plans would be required by 42 CFR In the hands of a HIPAA covered organizations, state Medicaid and CHIP 438.242(b)(6) to comply with the entity or its business associate, FFS programs, Medicaid managed care requirement at 42 CFR 431.60(c), and individually identifiable patient claims, plans, CHIP managed care entities, and CHIP managed care entities would be encounter data, and other health QHP issuers in FFEs, we are proposing required by 42 CFR 457.1233(d)(2) to information are PHI as defined at 45 to specify the circumstances under comply with the requirement at 42 CFR CFR 160.103. Ensuring the privacy and which these regulated entities, which 457.730(c). security of the claims, encounter, and are all HIPAA-covered entities subject to Additionally, we note that while other health information when it is HIPAA privacy and security federal laws that regulate MA transmitted through the API is of critical requirements, may decline to establish organizations and MA plans supersede importance. Therefore, we remind MA or may terminate a third-party any state law except where noted under organizations, state Medicaid and CHIP application’s connection to the covered section 1856(b)(3) of the Act, some state, FFS programs, Medicaid managed care entity’s API while remaining in local, or tribal laws that pertain to plans, CHIP managed care entities, and compliance with our proposed privacy and security of individually QHP issuers in FFEs that mechanisms requirement to offer patients access identifiable information generally and and practices to release PHI, including through open APIs. We intend for this are not specific to health insurance may but not limited to authorization and also apply to MA organizations and MA authentication protocols and practices 27 https://www.hhs.gov/hipaa/for-professionals/ plans in the context of our proposal. For must provide protection sufficient to faq/2037/are-there-any-limits-or-exceptions-to-the- the other entities regulated under our comply with HIPAA privacy and individuals-right/index.html. 28 See 45 CFR 164.524(c)(2) and (3), and proposals in these various programs, we security regulations at 45 CFR part 164 164.308(a)(1), OCR HIPAA Guidance/FAQ–2036: also intend the phrase ‘‘other applicable and other law (whether federal, state, https://www.hhs.gov/hipaa/for-professionals/faq/ law’’ to include federal, state, tribal or tribal or local) that may apply based on 2036/can-an-individual-through-the-hipaa-right/ local laws that apply to the entity. the specific circumstances. Under this index.html, and OCR HIPAA Guidance/FAQ–2037: https://www.hhs.gov/hipaa/for-professionals/faq/ We propose this requirement to proposal, the entities subject to these 2037/are-there-any-limits-or-exceptions-to-the- establish and maintain processes to requirements would need to individuals-right/index.html (FAQs last accessed at routinely test and monitor the open continuously ensure that all these URLs July 30, 2018).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00213 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7636 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

proposal to be consistent with the h. Enrollee and Beneficiary Resources might request disclosure of their data to HIPAA rules, and we note that these Regarding Privacy and Security a third-party application through the circumstances apply to specific As discussed in section II.A. of this organization’s API. We are also applications, rather than the third party proposed rule, we are committed to proposing that the entity must make this itself. For instance, were the individual maximizing enrollees’ access to and information available in non-technical, to request that the HIPAA covered entity control over their health information. consumer-friendly language. We anticipate that organizations provide the individual’s information We believe this calls for providing could meet the requirement to provide through other means than through an enrollees that would access data under information to current and former API to the same third party that would our proposal with essential information enrollees in whole or in part using have received it on the individual’s about the privacy and security of their materials designed for consumer behalf through an application which has information, and what to do if they audiences that are available on the HHS been denied access, the covered entity believe they have been misled or website (for example, content and would be required to approach that deceived about an application’s terms of request as if the application’s API materials such as those available at use or privacy policy. https://www.hhs.gov/hipaa/for- request or connection had not occurred. At 42 CFR 422.119(g), 431.60(f), and individuals/right-to-access/index.html) Specifically, we propose that an MA 457.730(f), and 45 CFR 156.221(g), we and FTC website (for example, content propose to require MA organizations, organization, state Medicaid and CHIP and materials such as those available at FFS program, Medicaid managed care state Medicaid and CHIP FFS programs, https://www.consumer.ftc.gov/topics/ plan, CHIP managed care entity, or QHP Medicaid managed care plans, CHIP online-security). However, we note that issuer in an FFE, may, in accordance managed care entities, and QHP issuers whether the organization chooses to with HIPAA, deny access to the API if in FFEs, to make available to their draft its own resource materials to the entity reasonably determines that current and former enrollees certain provide the required information or to allowing that application to connect or information about: Factors to consider rely on governmental or other sources remain connected to the API would in selecting a health information for such materials, the organization will present an unacceptable level of risk to management application, practical be responsible for ensuring that the the security of PHI on the organization’s strategies to help them safeguard the content of the materials remains current systems. We further propose that this privacy and security of their data, and as relevant law and policy may evolve determination must be based on how to submit complaints to OCR or over time. We seek comment on this objective, verifiable criteria that are FTC. These proposed obligations are proposal, and we invite additional applied fairly and consistently across all proposed to apply to Medicaid managed comments on what specific information applications through which enrollees care plans and CHIP managed care resources in addition to those already seek to access their electronic health entities through cross-references available on the websites noted above information as defined at 45 CFR proposed in 42 CFR 438.242(b)(6) and would be most useful to entities in 171.102, including but not limited to 457.1233(d)(2). meeting this requirement. We anticipate criteria that may rely on automated The general information about the using this feedback to help inform HHS monitoring and risk mitigation tools. steps individuals can take to help planning and prioritization of Where we propose to require access protect the privacy and security of their informational resource development through open APIs to otherwise publicly health information should not be work in addition to making a decision available information, such as provider limited to, but should specifically on the final rule regarding this proposal. directories, the entities subject to our include and emphasize the importance of understanding the privacy and i. Exceptions or Provisions Specific to proposal may also deny or terminate an Certain Programs or Sub-Programs application’s connection to the API security practices of any application to when it makes a similar determination which they entrust their data. We are proposing certain exceptions about risk to its systems. However, Information about submitting or specific additional provisions as part depending on how the organization’s complaints should include both specific of this proposed rule for certain QHPs systems are designed and configured, contact information for the OCR and in FFEs and certain types of MA plans, we recognize that the criteria and FTC complaints processes and a brief respectively. Under sections 1856, 1857, tolerable risk levels appropriate to overview, in simple and easy-to- and 1860D–12(b)(3) of the Act, we assessing an application for connection understand language, of: What proposed at 42 CFR 422.119(b)(2) to to an API for access to publicly available organizations are HIPAA covered include additional requirements that information may differ from those entities, OCR’s responsibility to oversee would apply specifically to MA required for API access to non- compliance with HIPAA, and FTC’s organizations that offer Medicare published PII. complementary responsibility to oversee Advantage-Prescription Drug (MA–PD) unfair and deceptive practices, plans. The organizations offering these We also anticipate that, where an including by non-covered entities that MA–PD plans must comply with MA application’s connection has been may offer direct-to-consumer health requirements in 42 CFR part 422 for Part terminated under these circumstances, information management applications. A, Part B and non-drug supplemental it might be feasible in some instances We propose that this information benefits; they must comply with Part D for the organization to allow the must be made available on the website requirements in 42 CFR part 423 for the application to re-connect to the API if of the organization subject to this Part D prescription drug benefit. These and when the flaw or compromise of the proposed requirement, and through additional requirements would ensure application has been addressed other appropriate mechanisms through that enrollees of MA–PD plans can sufficiently that the organization can no which the organization ordinarily easily access the information they need longer fairly say the application’s API communicates with enrollees. This in order to adhere to their care plans. connection continues to pose an could include customer portals, online Including this information in an open unacceptable risk. customer service help desks, and other API allows non- MA third-party We request comment on these locations, such as any portals through applications to properly use, aggregate, proposals. which enrollees and former enrollees and display plan data in different

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00214 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7637

contexts, enabling another means of with respect to SADPs. Therefore, we specific regulation text for 42 CFR accessing information for patients and believe that the utility of access to 431.60 or 438.242 because we intend to more options for comparing and issuers’ data is less applicable to dental make the regulation text effective on the understanding plan information in a coverage, and do not believe it would be applicable date discussed below. We way that can best serve their individual in the interest of qualified individuals expect that state Medicaid and CHIP needs. and qualified employers in the state in agencies will be aware of upcoming new Specifically, at 42 CFR 422.119 which an FFE operates to not certify regulations and planning for compliance (b)(2)(i), we propose to require MA SADPs because they do not provide with them when they are effective and organizations make standardized data patient access to their data through an applicable, even if the new regulation is concerning adjudicated Part D claims, openly-published API. We seek not yet codified in the CFR; we similarly including remittances and enrollee cost- comment on whether we should apply expect that such agencies will ensure sharing, available through the API to this policy to SADP issuers in the that their managed care plans/entities enrollees covered under a MA–PD plan. future. will be prepared for compliance. Unlike We propose to require that this We also propose to provide an Medicaid state agencies and managed information be made available no later exceptions process through which an care plans and state CHIP agencies and than one (1) business day after a claim FFE may certify health plans that do not managed care entities, MA organizations is adjudicated. This would ensure that provide patient access through an and QHP issuers in FFEs generally are data provided through the API would be openly-published API, but otherwise subject to rules regarding bid and the most current data available, which meet the requirements for QHP application submissions to CMS in may be critical if the data is being used certification. We propose in 45 CFR advance of the coverage period; for by a provider who is basing clinical 156.221(h)(1) that if a plan applying for example, MA organizations must submit decisions on the data. To the extent that QHP certification to be offered through bids to CMS by the first Monday in June an MA organization offering MA–PD an FFE does not provide patient access of the year before coverage starts in plans utilizes a PBM, the MA to their data through an open API, the order to be awarded an MA contract. In organization would be required to issuer must include as part of its QHP order to ensure that these requirements obtain the data from the PBM in order application a narrative justification for MA organizations and QHP issuers to comply with these requirements. outlining the reasons why the plan in FFEs are enforceable and reflected in Related to QHP issuers, we propose cannot reasonably satisfy the the bids and applications these entities two exceptions to this proposed rule. requirements in proposed 45 CFR submit to us in advance of when the First, we propose that the requirements 156.221(a),(b), or (c), the impact of non- actual requirements must be met, we proposed in 45 CFR 156.221(a) not compliance upon enrollees, the current propose to codify the actual compliance apply to issuers of SADPs in the FFEs. or proposed means of providing health and applicability dates of these In contrast to QHP issuers of medical information to enrollees, and proposed requirements. We solicit comment on plans, issuers of SADPs offer enrollees solutions and timeline to achieve API this approach. access to a unique and specialized form compliance. In 45 CFR 156.221(h)(2), For MA organizations, under 42 CFR of medical care. We believe the we propose that an FFE may grant an 422.119(h), we are proposing that the proposed standards and health IT exception to the requirement to provide requirements would be effective investment would be overly enrollees access to data through open beginning January 1, 2020. Under this burdensome for SADP issuers as related API technology if the FFE determines proposal, the requirements we propose to their current enrollment and that making available such health plan for 42 CFR 422.119 would be applicable premium intake and could result in is in the interest of qualified individuals for all MA organizations with contracts SADP issuers no longer participating in and qualified employers in the state in to offer any MA plan on that date and FFEs, which would not be in the best which the FFE operates. We anticipate thereafter. We request feedback about interest of enrollees. Additionally, we that this exception would be provided this proposed timing from the industry. believe much of the benefit to enrollees in limited situations. For example, we In particular, we are interested in from requiring issuers of QHPs to make would consider providing an exception information and request comment from patient data more easily available for small issuers, issuers who are only MA organizations about their current through a standard format depends in the individual or small group market, capability to implement an API upon deployment of open API financially vulnerable issuers, or new consistent with this proposal and the technology that conforms to standards entrants to the market who demonstrate costs associated with compliance by proposed by ONC for HHS adoption at that deploying open API technology January 1, 2020, versus compliance by 45 CFR 170.215 (published elsewhere in consistent with the required a future date. this issue of the Federal Register) and interoperability standards would pose a For Medicaid FFS at 42 CFR 431.60, a corresponding energetic response by significant barrier to the issuer’s ability CHIP agencies that operate FFS systems the developer community in developing to provide coverage to consumers, and at 42 CFR 457.730, Medicaid managed innovative, useful, usable, and not certifying the issuer’s QHP or QHPs care plans at 42 CFR 438.242(b)(6), and affordable consumer-facing applications would result in consumers having few CHIP managed care entities at 42 CFR through which plan enrollees can or no plan options in certain areas. We 457.1233(d)(2), we are proposing that conveniently access, use, and share seek comment on other circumstances the API requirements would be effective their information as they choose. in which the FFE should consider beginning July 1, 2020, regardless of Through our proposals in this section to providing an exception. when the managed care contract started. require implementation of open API Given the expected date of publication technology in the Medicare, Medicaid j. Applicability and Timing of this proposed rule and potential final and CHIP programs, as well as by QHP At 42 CFR 422.119(h) and 45 CFR rule, we believe July 1, 2020, would issuers in FFEs, we would anticipate 156.221(i), we are proposing specific provide state Medicaid agencies and significantly expanding the provisions regarding applicability and CHIP agencies that operate FFS systems, implementation of open APIs by timing for MA organizations and QHP Medicaid managed care plans, and CHIP medical plans. However, we do not issuers in FFEs that would be subject to managed care entities sufficient time to anticipate similar widespread usage our proposal. We are not proposing implement. We solicit comment on this

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00215 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7638 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

proposal and whether additional system that pays for value and quality PHI under the HIPAA Rules and other flexibility would be necessary to take by reducing duplication of services, legal standards, but instead specify a into account the contract terms that adding efficiency to patient visits to new and additional mechanism by states use for their Medicaid managed providers; and, facilitating identification which to share health information as care plans. of fraud, waste, and abuse. Data directed by the individual, through the For CHIP, we are aware that some interoperability is critical to the success use of API technology in compliance states do not provide any benefits on a of new payment models and approaches with all existing federal, state, local, and FFS basis, and we do not intend for that incentivize high quality, efficient tribal privacy and security laws. those states to implement an API care. All of the health care providers for In the future, we anticipate payers outside their managed care plans. a patient need to coordinate their care and providers may seek to coordinate Therefore, we also propose in 42 CFR for a value-based system to work, and care and share information in such a 457.700(c) that separate CHIP agencies that requires information to be securely way as to request data on providers’ or that provide benefits exclusively shareable in standardized, computable a plan’s patient/insured overlapping through managed care entities may meet formats. Moreover, patients need to population(s) in one transaction. the requirements of 42 CFR 457.730 by understand and be actively involved in Effective care coordination between requiring the managed care entities to their care under a value-based plans and providers can inform health meet the requirements of 42 CFR framework. We are committed to care providers about where their 457.1233(d)(2) beginning July 1, 2020. supporting requirements that focus on patients are receiving care to better For QHP issuers in FFEs, we propose these goals, and we believe that these understand the totality of their in 45 CFR 156.221(i) that these specific proposals in this proposed rule healthcare needs and manage their care. requirements would be applicable for support these efforts. We have heard that being aware of plan years beginning on or after January urgent care or emergency department 1, 2020. We seek comment on the timing k. Request for Information on visits allows clinicians to arrange of these requirements, and on how long Information Sharing Between Payers appropriate follow-up, modify issuers, particularly smaller issuers, and Providers Through APIs treatments, and update records if anticipate it would take to come into This proposed rule requires the services are provided (for example, compliance with these requirements. implementation of open APIs for tetanus boosters given with a laceration We believe that these proposals making accessible data that a third-party treated in urgent care). The would help to create a health care could use to create applications for accompanying proposals in Section X. information ecosystem that allows and patients to access data in order to of this proposed rule, to amend the encourages the health care market to coordinate and better participate in their conditions of participation regarding tailor products and services to compete medical treatment. While in some notification of patient discharge, further for patients, thereby increasing quality, instances, direct provider to health plan support the ability of clinicians to decreasing costs, and helping them live transmission of health information may arrange and affirm such appropriate better, healthier lives. Additionally, be more appropriate than sharing data follow-up care. Having a complete under these proposals, physicians through an open API, in other instances record of tests done at specialists’ would be able to access information on a patient may wish to send a provider offices can reduce duplicate testing. their patient’s current prescriptions and a copy of their health information via Having a complete list of clinicians services by reviewing the information another health care provider’s API. In caring for a patient facilitates with the patient on the patient’s such cases, patients could direct the appropriate notification if treatments are personal device or by the patient payer to transmit the health information changed or procedures are planned that sharing data with the provider’s EHR to a third party application (for may impact the other clinicians’ system, which would save time during example, an application offered by a treatment plan. We have heard from appointments and ultimately improve health care provider to obtain patient participants in our accountable care the quality of care delivered to claims and encounter data, as well as programs and models that organizations beneficiaries. Most health care lab test results (if applicable) on a one- taking risk for their patient populations professionals and consumers have off and as-needed basis. To the extent a need to have a complete picture of the widespread access to the internet, HIPAA covered entity uses a third party patients’ needs to better budget for providing many access points for application to offer patients access to appropriate resources. This may be viewing health care data over secure their records, another HIPAA covered particularly relevant during disasters or connections. We believe that these entity may be able to obtain an public health emergencies when proposed requirements would individual’s health information from the patients are not able to access their significantly improve beneficiaries’ app for treatment, payment, or certain normal sources of care and/or health experiences by providing a secure health care operations, if it could do so care facilities are overwhelmed due to mechanism through which they can in accordance with HIPAA without patient surge. access their data in a standardized, need of an individual’s authorization. We believe there are a variety of computable format. (See 45 CFR 164.506.) Under other laws, transmission solutions that may be These proposals are designed to providers may need to obtain specific employed to share data regarding a empower patients by making sure that individual consent to obtain health provider’s and plan’s overlapping they have access to health information information related to care provided by patient populations. For instance, some about themselves in a usable digital a behavioral health provider, treatment geographic areas might have regional format and can make decisions about received at a substance use disorder health information exchanges that could how, with whom, and for what uses treatment facility, certain 42 CFR part 2- coordinate such transmissions. they will share it. By making claims covered diagnoses or other claims- Elsewhere, direct provider-to-provider data readily available and portable to related information, or labs that suggest and plan-to-plan exchange might be the enrollee, these initiatives support a part 2 diagnosis. We do not intend to more appropriate. Plans could efforts to move our health care system expand any scope of authority to access participate in direct exchange through away from a FFS payment system that patient data nor to contravene existing existing trusted networks, or pays for volume and toward a payment requirements related to disclosure of beneficiary-facing third party

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00216 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7639

applications could meet this potential (42 CFR 438.10(e)(2)(vi) and (h) and networks available through API future requirement. 457.1207, respectively) require that technology, so that third party software We seek comment for possible provider directories be made available could access and publish that consideration in future rulemaking on to enrollees and potential enrollees in information. Such availability would be the feasibility of providers being able to hard copy and on the plan’s website. for current enrollees, prospective request a download on a shared patient Section 1902(a)(83) of the Act requires enrollees and possibly the general population, and whether such a process state Medicaid agencies to publish a public to the extent existing regulations could leverage the APIs described in directory of certain physicians on the require that information to be disclosed sections II.A.3. and III.C. of this public website of the State agency. A beyond current enrollees. We propose to proposed rule. We seek comment on regulation for QHPs in FFEs (45 CFR require that the API technology conform requirements for patient notice and 156.230(b)) requires public access to the to the API standards proposed by ONC consent, and applicable legal and QHP’s provider directory in addition to for HHS adoption at 45 CFR 170.215 regulatory requirements, and whether or distribution and access for enrollees. In (published elsewhere in this issue of the how this data transfer could be addition to directing that this Federal Register). At this time, because cumulative over time and between information be accessible, the current QHP issuers in FFEs are already various providers. We seek input on the regulations also address the content of required to make provider directory utility to providers of obtaining all of such directories and the format and information available in a specified, their patients’ utilization history in a manner in which MA plans, Medicaid machine-readable format,29 we do not timely and comprehensive fashion. We managed care plans, CHIP managed care propose these as requirements for QHP also seek input on potential unintended entities, and QHP issuers in FFEs make issuers. However, we seek comment as consequences that could result from the information available. to whether this same requirement allowing a provider to access or Making this required provider should apply to QHP issuers, or if such download information about a shared directory information available to a requirement would be overly patient population from payers through enrollees and prospective enrollees burdensome for them. an open API. Finally, we seek comment through an API could support We note that, since the provider on the associated burden on plans to development of applications (whether directory information we are proposing exchange this data, as well as the standalone or integrated with providers’ to require be available through the API identification other potential statutory EHR technology) that would pull in is already available and accessible to or regulatory barriers to exchanging this current information about available enrollees without cost to them, this data. providers to meet enrollees’ current information should be as accessible needs. For instance, as part of a referral through the API as it is required to be IV. API Access to Published Provider lookup use case, API access to a when posted on the organization’s Directory Data provider directory could allow for a websites. Therefore, the security A. Interoperability Background and Use referring provider’s health IT to enable protocols proposed at 45 CFR 170.215 Cases either the enrollee or the provider to that are specific to authenticating users easily identify up-to-date contact and confirming individuals’ The proposals described in section III information obtained from the directory authorization or request to disclose their of this proposed rule primarily focus on through an API, and securely send the personal information to a specific patient access to their data through a receiving health care provider the application would not apply to public standardized, transparent API; however, patient information needed to provide access to provider directory information we have also proposed that entities safe, high-quality care sensitive to the through APIs. While we are aware the subject to these proposals make patient’s preferences. Broad availability organization will nevertheless need to available certain plan-level data through of provider directory data through take appropriate steps to mitigate the the API. In this section, we provide interoperable API technology would potential security risks of allowing any additional context for the proposal also allow for innovation in applications application to connect to the API related to making provider directory or other services that help enrollees and through which it offers provider information available through the API, prospective enrollees to more easily directory access, we emphasize that including ways in which this proposal compare provider networks while they these steps should be appropriate to the may differ from our other proposals are considering their options for level of risk associated with the specific related to accessibility of patient data. changing health plans. Finally, a use case of accessing otherwise public Provider directories make key consistent, FHIR-based API-driven information through API technology. information about health care approach to making provider directory Those wishing to access this data professionals and organizations data accessible could reduce provider should not be unduly burdened by available to help consumers identify a burden by enabling payers/plans to security protocols that are not necessary provider when they enroll in an share more widely basic information to provide the appropriate degree of insurance plan or as new health needs about the providers in their networks, protection for the organization’s systems arise. For example, such information such as provider type, specialty, contact and data. might include hours of operation, information, and whether or not they As referenced in sections II. and III. of languages spoken, specialty/services, are accepting new patients. this proposed rule, we intend to develop availability for new patients. Provider additional guidance, incorporating directories also function as a resource B. Broad API Access to Provider Directory Data feedback from industry that provides used by the provider community to implementation best practices relevant discover contact information of other In sections II.A.3. and III.C. of this to FHIR-conformant open APIs to help providers to facilitate referrals, proposed rule, we propose to require organizations subject to the transitions of care, and care MA organizations, state Medicaid and requirements proposed in this coordination for enrollees. CHIP FFS programs, Medicaid managed rulemaking. To that end, we solicit The current applicable regulations for care plans, and CHIP managed care MA plans (42 CFR 422.111) and entities to make standardized 29 Available at https://github.com/CMSgov/QHP- Medicaid and CHIP managed care plans information about their provider provider-formulary-APIs/blob/master/README.md.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00217 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7640 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

comment on what specific resources patient access to their health reviews, risk screenings, and would be most helpful to organizations information through coordination of assessments. It can also streamline prior implementing APIs under requirements care between health plans. We also note authorization processes and reduce proposed in this proposed rule. that the CHIP regulations incorporate instances where an enrollee’s health and apply, through an existing cross- care provider needs to intervene V. Health Information Exchange and reference at 42 CFR 457.1216, the personally with the enrollee’s MA plan, Care Coordination Across Payers: Medicaid managed care plan Medicaid managed care plan, CHIP Establishing a Coordination of Care requirements codified at 42 CFR managed care entity, or QHP in the FFE Transaction To Communicate Between 438.62(b)(1)(vi). Therefore, the proposal to ensure his or her patient received the Plans for Medicaid managed care plans necessary treatment. This addresses We are proposing a new requirement described above will also apply to CHIP concerns stakeholders have previously for Medicare Advantage (MA) plans, managed care entities without new raised with CMS and ONC regarding Medicaid managed care plans, CHIP regulation text in part 457. We are such administrative burdens, as the managed care entities, and QHPs in the proposing that this new requirement USCDI standard contains many of the FFEs to require these plans to maintain would be effective starting January 1, data points required to more effectively a process to coordinate care between 2020 for MA plans, Medicaid managed coordinate care. plans by exchanging, at a minimum, the care plans, CHIP managed care entities, In addition to the benefits for care USCDI at enrollee request at the specific and QHP issuers in FFEs. Among other coordination at the plan level and times specified in the proposed topics related to this proposal, we solicit reduced provider burden, we note that regulation text. Understanding that this comments on this proposed effective once the combined health information, information could already be available date. specified by the USCDI standard, from for exchange between plans, this We propose to codify this new a prior plan is available to the patient’s proposal is specifically requiring this requirement at 42 CFR 422.119(f)(1) for current plan, the enrollee would also information sharing not only occur MA organizations; at 42 CFR have access to multiple years of their when initiated by an enrollee request, 438.62(b)(1)(vi) for Medicaid managed health information through the but that the information requested, in care plans (and by extension under proposed patient access API discussed the form of the USCDI data set, would existing rules in part 457, to CHIP in section III of this proposed rule. The then be incorporated into the recipient managed care entities); and at 45 CFR USCDI (Version 1) data set includes plan’s systems. The USCDI (Version 1) 156.221(c) for QHPs in FFEs. This laboratory results and tests, data set would have to be sent to proposed new requirement is virtually medications, health concerns, another plan that covers the enrollee or identical for MA plans, Medicaid assessment and plan of treatment, care a recipient identified by the enrollee at managed care plans, CHIP managed care teams, clinical notes, and other data any time during coverage or up to 5 entities, and QHP issuers in FFEs, with points essential for care coordination. years after coverage ends, and the plan modifications in the proposal necessary This would provide the patient with a would have to receive the USCDI for specific plans types to account for more comprehensive history of their (version 1) data set from any health plan the program needs of the MA program, medical care, helping them to make that covered the enrollee within the Medicaid and CHIP managed care better informed health care decisions. preceding 5 years. Under our proposal programs, and QHP program. Our We seek comments on how plans might we are supporting patient directed proposed regulation text references the combine records and address error coordination of care and each of the content standard adopted at 45 CFR reconciliation or other factors in plans subject to the requirement would, 170.213, which ONC is proposing as the establishing a more longitudinal record upon an enrollee’s request: (1) Accept USCDI Version 1 data set (published for each patient. the data set from another plan that had elsewhere in this issue of the Federal We propose to allow multiple covered the enrollee within the previous Register). We believe that exchanging methods for electronic exchange of the 5 years; (2) send the data set at any time this minimum data would help both information, including use of the APIs during an enrollee’s enrollment and up plan enrollees and health care providers proposed in section III. of this proposed to 5 years later, to another plan that coordinate care and reduce rule, to allow for patient-mediated currently covers the enrollee; and (3) administrative burden to ensure that exchange of payer information or direct send the data set at any time during plans provide coordinated high-quality payer-to-payer communication, subject enrollment or up to 5 years after care in an efficient and cost-effective to HIPAA requirements, 42 CFR part 2, enrollment has ended to a recipient way that protects program integrity. and other applicable laws. We identified by the enrollee. Leveraging interoperability to considered requiring the use of the As we discussed in section III.C.2. of facilitate care coordination among plans FHIR-based API discussed in section III. this proposed rule, this proposal is can, with thoughtful execution, of this proposed rule for the information based on our authority under sections significantly reduce unnecessary care, exchange; however, we understand that 1856(b) and 1857(e) of the Act to adopt as well as ensure that health care some geographic areas might have a standards and contract terms for MA providers are able to spend their time regional health information exchange plans; section 1902(a)(4) of the Act to providing care rather than performing that could coordinate such transitions adopt methods of administration for unnecessary administrative tasks. We for the MA plans, Medicaid managed state Medicaid plans, including believe that use of the USCDI to care plans, CHIP managed care entities, requirements for Medicaid managed exchange information furthers care and QHPs in the FFEs that are subject care plans (MCOs, PIHPs, and PAHPs); coordination. For instance, effective to this proposal. We seek comment on section 2101(a) of the Act for CHIP information exchange between plans whether it would be beneficial to managed care entities (MCOs, PIHPs, could improve care coordination by interoperability and patient care and PAHPs); and section 1311(e)(1)(B) reducing the need for health care coordination for us to require the use of of the ACA for QHP issuers in an FFE providers to write unneeded letters of the FHIR-based API discussed in section (not including SADP issuers). We medical necessity; by reducing III. of this proposed rule, and whether believe that our proposal will help to instances of inappropriate step therapy; this should be the only mechanism reduce provider burden and improve and by reducing repeated utilization allowed for this exchange, or whether

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00218 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7641

multiple methods for electronic any time during coverage or up to 5 perform timely outreach to enrollees exchange of the information should be years after coverage ends and the plan based on past and current utilization, allowed under this proposed policy. would have to receive the USCDI these plans could take steps to prevent We also propose that a patient should (version 1) data set from any health plan unnecessary emergency room visits and be able to request his or her information that covered the enrollee within the lapses in medication and ongoing care; from their prior plan up to 5 years after preceding 5 years. further, they could proactively address dis-enrollment, which is considerably We propose that the plans subject to any network deficiencies that may less than existing data retention policies this new requirement would be required impact the enrollee. We believe that for some of the plans.30 Further, if a to exchange, at a minimum, the USCDI having an enrollee’s utilization history plan has access to multiple years of Version 1 data set. On behalf of HHS, in a timely and comprehensive fashion health information for a patient, either ONC has proposed to adopt the USCDI would facilitate outreach and due to the fact that the patient has been as a standard (published elsewhere in coordination efforts in ways heretofore enrolled with the plan for multiple this issue of the Federal Register), to be unavailable on a broad basis. In all, this years, or because the enrollee has codified at 45 CFR 170.213, and our ability would mean that these plans requested transfer of the health proposed regulation text cross- could help new enrollees transition to information from prior plans which references this regulation. These data new coverage rules and a new network previously covered the enrollee, we exchanges would provide the enrollee’s with minimal disruptions to care. propose that the health information new plan with a core set of data that can While our proposal is to require, at a would be incorporated into the IT and be used to support better care minimum, exchange of the USCDI data systems of each plan that receives coordination and improved outcomes Version 1 data set, we reiterate that we the USCDI data set under this proposed for the enrollee. We considered do not propose to specify the means of requirement, such that the enrollee’s requiring plans to exchange all the data exchanging this data at this time. While data would be cumulative and move that we proposed be available through we anticipate that plans may opt to use with the enrollee as he or she changes an API (see section III. of this proposed APIs (such as those described in section enrollment. For example, if a patient is rule) but we understand that ingesting III of this proposed rule) as the means enrolled in Plan 1 in 2020 and Plan 2 data and reconciling errors has to exchange this data, we intend to not in 2021, then requests the data from challenges and proposed this more be overly prescriptive as to how USCDI Plan 1 to be sent to Plan 2, Plan 2 would limited data set to address those data set information for applicable have at least 2 years (2020 and 2021) of concerns. We are seeking comment on health information for that patient. If the whether the USCDI data set is enrollees is exchanged as we expect patient moves to Plan 3 in 2022, Plan 3 comprehensive enough to facilitate the there are a variety of transmission should receive both 2020 and 2021 data type of care coordination and patient solutions that may be employed. For from Plan 2 at the patient’s request. access described in this proposal, or instance, some geographic areas might While our proposal is to require whether additional data fields and data have a regional health information compliance (and thus exchange of these elements that would be available under exchange that could coordinate such data sets) only by MA plans, Medicaid our API proposal in section III of this transitions for the MA plans, Medicaid managed care plans, CHIP managed care proposed rule, should also be required. managed care plans, CHIP managed care entities, and QHPs in the FFEs, we hope Many key attributes of the USCDI entities, and QHPs in the FFEs that are that compliance by these plans could be make it suitable for the purpose subject to this proposal. Elsewhere, the first step toward adoption and outlined in our proposal. The USCDI direct plan-to-plan exchange might be implementation of these standards on a includes data classes that can be more appropriate, or beneficiary-facing voluntary basis by other health plans supported by commonly used standards, third party applications could be used and health issuers throughout the health including the Health Level Seven by MA plans, Medicaid managed care ® care system. (HL7 ) Consolidated Clinical Data plans, CHIP managed care entities, and Research indicates that the Architecture (C–CDA) Version 2.1 and QHPs in the FFEs to meet this proposed completeness of a patient record and the the Fast Healthcare Interoperability requirement. We also expect there may availability of up-to-date and relevant Resources (FHIR®) standards for be instances where these plans may health information at the point of care essential patient health information like leverage their connections to Health can have a significant impact on patient vital signs, lab results, medications and Information Exchanges to engage in the outcomes.31 Our proposal here for MA medication allergies. The USCDI information exchanges necessary to plans, Medicaid managed care plans, establishes a minimum set of data comply with this proposed rule. We CHIP managed care entities, and QHPs elements that would be required to be expect enrolled beneficiaries to have in the FFEs to exchange a minimum interoperable nationwide and is constant access to requesting an data set in particular scenarios would designed to be expanded in an iterative exchange of data as our proposal would support improvement in care and predictable way over time. The require exchange of the USCDI data set coordination by allowing for sharing of USCDI, at a minimum, transferred for whenever an enrollee makes such a key patient health information when an each enrollee moving among the plans request, which may occur at times other enrollee requests it. The USCDI (Version subject to our proposal would greatly than enrollment or disenrollment. We 1) data set would have to be sent to improve each plan’s coordination of request comments on other means that another plan that covers the enrollee or care efforts and spotlight areas of urgent the applicable plans may prefer to use a recipient identified by the enrollee at need. Having this information would for meeting this requirement and allow the new MA plan, Medicaid whether CMS might be able to leverage 30 Under 42 CFR 422.504(d) and 438.3(u), MA managed care plan, CHIP managed care its program authority to facilitate the organizations and Medicaid managed care plans entity or a QHP in the FFE to evaluate data exchanges contemplated by this and CHIP plans must retain records for at least 10 and review an enrollee’s utilization proposal. We acknowledge that in some years. Under 45 CFR 156.705; 45 CFR history in a timely and comprehensive cases plans subject to this proposed 155.1210(b)(2), (3) and (5) QHPs in the FFEs must also retain records for 10 years. fashion and thus assist each enrollee to requirement may be exchanging patient 31 https://www.healthit.gov/topic/health-it-basics/ transition to the new plan with minimal health information with other plans that improved-diagnostics-patient-outcomes. disruption to care. By being able to are not similarly required to exchange

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00219 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7642 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

USCDI data sets for enrollees, and we managed care entities under 42 CFR We are proposing to require, effective request comment on how to support 457.1203(f), and MA plans under 42 beginning January 1, 2020, that MA patients and providers in those CFR 422.2400 through 422.2490. We plans, Medicaid managed care plans, situations. request comments related to this CHIP managed care entities and QHPs We believe that this proposed assumption and its implications. in the FFEs (excluding not stand alone requirement would also support dual SADPs) participate in a trusted VI. Care Coordination Through Trusted eligible individuals who are exchange network. This proposal is Exchange Networks: Trust Exchange concurrently enrolled in MA plans and based on our authority under: Sections Network Requirements for MA Plans, Medicaid managed care plans. Under 1856(b) and 1857(e) of the Act to adopt Medicaid Managed Care Plans, CHIP our proposal, both of the dual eligible standards and contract terms for MA Managed Care Entities, and QHPs in the individual’s plans would be subject to plans; section 1902(a)(4) of the Act to FFEs the requirement to exchange that adopt methods of administration for the individual’s data in the USCDI Version We are proposing to require MA administration state Medicaid plans, 1, which should improve the ability of plans, Medicaid managed care plans, including requirements for Medicaid both plans to coordinate care based on CHIP managed care entities, and QHPs Managed Care Plans (MCOs, PIHPs, and that data. For example, when an in the FFEs (excluding SADP issuers) to PAHPs); section 2101(a) for CHIP enrollee is initially eligible for only one participate in trust networks in order to managed care entities (MCOs, PIHPs, program (that is, only for Medicare and improve interoperability in these and PAHPS); and section enrolled in a MA plan, or only for programs. We would codify this 3001(c)(9)(F)(iii) of the Public Health Medicaid and enrolled in a Medicaid requirement in, respectively, 42 CFR Service Act and section 1311(e)(1)(B) of MCO) and then becomes dually eligible 422.119(f)(2), 438.242(b)(5), and the Affordable Care Act for QHP issuers for a second program, the sharing of 457.1233(d) (which cross-references the in an FFE. Under our proposal, data between the existing plan and the requirements in 42 CFR 438.242(b)(5)) participation would be required in a new plan reduces the burden on the and 45 CFR 156.221. In general, payers trusted exchange framework that meets new plan, on the enrollee, and on health and patients’ ability to communicate the following criteria: care providers in the new plan regarding between themselves and with health (1) The trusted exchange network collecting information about prior care providers could considerably must be able to exchange PHI, defined utilization or health information. Rather improve patient access to data, reduce in 45 CFR 160.103, in compliance with than completing a lengthy health provider burden, and reduce redundant all applicable state and federal laws assessment, the enrollee in this example and unnecessary procedures. Trusted across jurisdictions. would benefit from having similar (or exchange networks allow for broader (2) The trusted exchange network possibly the same) information interoperability beyond one health must be capable of connecting both transferred directly between the MA system or point to point connections inpatient EHRs and ambulatory EHRs. plan and the Medicaid managed care among payers, patients, and providers. (3) The trusted exchange network plan under our proposal. We seek Such networks establish rules of the must support secure messaging or comment on how plans should road for interoperability, and with electronic querying by and between coordinate care and exchange maturing technology, such networks are patients, providers and payers. information in those situations. We also scaling interoperability and gathering We propose to codify these seek comment on the associated burden momentum with participants, including requirements for these plans at 42 CFR on plans to exchange the USCDI data set several federal agencies, EHR vendors, 422.119(f)(2) for MA organizations, under our proposal. In addition, we are retail pharmacy chains, large provider 438.242(b)(5) for Medicaid managed interested in comments about potential associations, and others. care plans, 457.1233(d)(2) for CHIP legal barriers to exchanging the USCDI The importance of a trusted exchange managed care entities, and 45 CFR data set as would be required under our framework to such interoperability is 156.221(d) for QHPs in the FFEs. proposal; for example, are there federal, reflected in section 4003(b) of the Cures On January 5, 2018, ONC released the state, local and tribal laws governing Act, as discussed in more detail in draft Trusted Exchange Framework for privacy for specific use cases (such as in section I.D. of this proposed rule. A public comment. Commenters to the the care of minors or for certain trusted exchange framework allows for draft framework, particularly payers behavioral health treatments) that raise the secure exchange of electronic health providing comments, requested that additional considerations we should information with, and use of electronic existing trust networks operating address in this regulation or guidance. health information from, other health IT successfully be leveraged in further We believe that activities related to without special effort on the part of the advancing interoperability; thus, we are this proposal may qualify as a quality user. Widespread payer participation in considering proposing in the future an improvement activity (QIA) meeting the such a framework might allow for more approach to payer to payer and payer to criteria described in section 2718(a)(2) complete access and exchange of all provider interoperability that leverages of the PHSA for purposes of the Medical electronically accessible health existing trust networks to support care Loss Ratio (MLR) requirements for QHP information for authorized use under coordination and improve patient access issuers in an FFE (excluding SADP applicable state or federal law, which to their data. We request comments on issuers),32 and similar standards for we believe would lead to better use of this approach and how it might be treatment of quality improvement such data. While we cannot require aligned in the future with section standards applicable to Medicaid widespread payer participation in trust 4003(b) of the Cures Act. We also managed care plans (MCOs, PIHPs, and networks, we are proposing here to use request comments on the effective date PAHPs) under 42 CFR 438.8, CHIP our program authority in the MA we have proposed for this requirement program, Medicaid managed care and what benefits and challenges the 32 While this rulemaking is specific to QHP program, CHIP managed care program, plans (MA organization, Medicare issuers participating in FFEs, we note that to the and QHP certification program for the managed care plans, CHIP managed care extent other commercial market issuers incur similar costs for coverage sold in the individual or FFEs to increase participation in trust entities and QHPs in the FFE) may face group markets, those expenses may similarly networks and to bring the benefits of meeting this requirement for additional qualify as QIA. such participation to those programs. consideration in future rulemaking.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00220 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7643

We believe that activities related to with the Secretary to facilitate state the limitations of monthly buy-in data this proposal may qualify as a QIA ‘‘buy-in,’’ that is, payment of Medicare exchanges with states. The relatively meeting the criteria described in section premiums, in this case Part B premiums, long lag in updating buy-in data means 2718(a)(2) of the PHSA for purposes of on behalf of certain individuals. For that the state is not able to terminate or the MLR requirements for QHP issuers those beneficiaries covered under the activate buy-in coverage sooner, so the in an FFE (excluding SADP issuers),33 agreement, the state pays the state or beneficiary may be paying and similar standards for treatment of beneficiary’s monthly Part B premium. premiums for longer than appropriate. quality improvement standards Section 1818(g) of the Act establishes In most cases, funds must be recouped applicable to Medicaid managed care the option for states to amend their buy- and redistributed—a burdensome plans (MCOs, PIHPs, and PAHPs) under in agreement to include enrollment and administrative process involving debits 42 CFR 438.8, CHIP managed care payment of the Part A premium for and payments between the beneficiary, entities under 42 CFR 457.1203(f), and certain specified individuals. All states state, CMS, and SSA. Additionally, MA plans under 42 CFR 422.2400 and the District of Columbia have a Part transaction errors do occur in the through 422.2490. We request B buy-in agreement; 36 states and the current data exchange processes. In a comments related to this assumption District of Columbia have a Part A buy- monthly exchange, it can take multiple and its implications. in agreement. months to correct and resubmit an improperly processed transaction, VII. Improving the Medicare-Medicaid To effectuate the state payment of exacerbating the delays in appropriately Dually Eligible Experience by Medicare Part A or Part B premiums, a assigning premium liability, leading to Increasing the Frequency of Federal- state submits data on a buy-in file to larger mispayment, recoupment, and State Data Exchanges CMS via an electronic file transfer (EFT) exchange setup. The state’s input file redistribution of premiums. A. Increasing the Frequency of Federal- includes a record for each Medicare Exchanging the buy-in data with State Data Exchanges for Dually Eligible beneficiary for whom the state is adding greater frequency supports more timely Individuals or deleting coverage, or changing buy-in access to coverage. All states’ systems already have the capacity to exchange 1. Background status. In response, CMS returns an updated transaction record that buy-in data. We acknowledge that states The Medicare and Medicaid programs provides data identifying, for each who do not already exchange data daily were originally created as distinct transaction on the state file, whether will need an initial, one-time systems programs with different purposes. The CMS accepted, modified, or rejected it, change to do so. However, moving to a programs have different rules for as well a Part A or Part B billing record daily data exchange would result in a eligibility, covered benefits, and showing the state’s premium net reduction of burden for states, and payment, and the programs have responsibility. In addition, the CMS file further, reduce administrative operated as separate and distinct may ‘‘push’’ new updates obtained from complexity for beneficiaries and systems despite a growing number of SSA to the state, for example, changes providers. More frequent submission of people who depend on both programs to the Medicare Beneficiary Identifier updates to individuals’ buy-in status for their health care. There is an number or a change of address. positively impacts all involved. Based increasing need to align these We have issued regulations for certain on our experience with the states programs—and the data and systems details of the state buy-in processes. For currently exchanging buy-in data daily, that support them—to improve care Medicare Part A, 42 CFR 407.40 we have found: delivery and the beneficiary experience • describes the option for states to amend States can terminate buy-in for dually eligible beneficiaries, while the buy-in agreement to cover Part A coverage sooner and lower the risk of reducing administrative burden for premiums for Qualified Medicare paying Part A or Part B premiums for providers, health plans, and states. The Beneficiaries (QMBs). For Medicare Part individuals once they no longer qualify. interoperability of state and CMS B, 42 CFR 406.26 codifies the process Enrollees for whom the buy-in is ending eligibility systems is a critical part of for modifying the buy-in agreement to have less risk of a retroactive deduction modernizing the programs and identify the eligibility groups covered. from their Social Security check due to improving beneficiary and provider CMS subregulatory guidance, delayed Part B buy-in terminations experiences. Improving the accuracy of (while 42 CFR 407.48(c) limits data on dual eligibility status by specifically Chapter 3 of the State Buy- in Manual,34 specifies that states should retroactive recoupments to a maximum increasing the frequency of federal-state of 2 months, an unexpected deduction data exchanges is a strong first step in exchange buy-in data with CMS at least monthly, but describes the option for of up to $268 [2 months of Part B improving how these systems work premiums in 2018] is significant for together. states to exchange buy-in data with CMS daily or weekly. Likewise, states can those with incomes low enough to be 2. Data Exchanges To Support State choose to receive the CMS response data dually eligible); • States can detect and fix errors Buy-in for Medicare Parts A and B file daily or monthly. We note that 31 sooner, limiting the impact of such states and the District of Columbia are States and CMS routinely exchange errors; now submitting buy-in data to CMS data on who is enrolled in Medicare, • State staff can spread the workload daily; 28 states and the District of and which parties are liable for paying of resolving rejected records across the Columbia are now receiving buy-in that beneficiary’s Parts A and B whole month rather than a spike when response files from CMS daily. premiums. These data exchanges they receive the monthly CMS response While many states submit and receive support state, CMS, and SSA premium file; accounting, collections, and enrollment buy-in files daily, some continue to only • States can effectuate an earlier shift functions. Section 1843 of the Act do so on a monthly basis. We have to Medicare as primary payer for many permits states to enter into an agreement become increasingly concerned about health care services, for those already

34 covered by Medicaid; 33 As noted above, to the extent other commercial CMS, ‘‘State Buy-In Manual Chapter 3—Data • Beneficiaries newly eligible for buy- market issuers incur similar costs for coverage sold Exchange,’’ https://www.cms.gov/Regulations-and- in the individual or group markets outside of an Guidance/Guidance/Manuals/downloads/buyin_ in who had been paying premiums FFE, those expenses may similarly qualify as QIA. c03.pdf. (last accessed September 26, 2018). themselves can stop having the Part B

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00221 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7644 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

premium deducted from their Social get Medicaid help with Medicare states, beneficiaries, and providers, in a Security check sooner; and, premiums, and often for cost-sharing). number of ways including: • Beneficiaries newly eligible for buy- The file is called the ‘‘MMA file,’’ but • Enabling an earlier transition to in who could not afford Medicare is occasionally referred to as the ‘‘State Medicare coverage for prescription premiums can access Medicare Parts A Phasedown file.’’ The MMA file was drugs, which reduces the number of and B services and providers can be originally developed to meet the need to claims the state pays erroneously and assured of coverage sooner. timely identify dually eligible has to recoup from pharmacists (that While there exist opportunities to beneficiaries for the then-new Medicare then have the burden of reaching out to modernize the platform for buy-in data Part D prescription drug benefit. The reconcile with the new Part D plan); exchange, we believe that an important Medicare Modernization Act (MMA) • Effectuating an earlier shift to first step is to promote the exchange of established that beginning January 1, Medicare as primary payer for many the most current available data. Section 2006, Medicare would be primarily health care services; 1843(f) of the Act specifies that Part B responsible for prescription drug • Aiding timely error identification buy-in agreements shall contain such coverage for full-benefit dually eligible and resolution, mitigating the payment provisions as will facilitate the financial and other implications of the error; transactions of the State and the carrier individuals; established auto-enrollment • Supporting states that promote with respect to deductions, coinsurance, of full-benefit dually eligible enrollment in integrated care by and otherwise, and as will lead to beneficiaries into Medicare prescription expediting the enrollment into economy and efficiency of operation. drug plans (with regulations further Medicare, since beneficiaries must have Further, section 1818(g)(2)(A) of the Act establishing facilitated enrollment into Medicare Parts A and B, as well as on Part A buy-in identifies this section prescription drug plans for partial- Medicaid to be eligible for integrated 1843(f) requirement as applicable to Part benefit dually eligible beneficiaries), products such as Dual-eligible Special A buy-in. While the regulations provided that dually eligible Needs Plans, Medicare-Medicaid Plans, governing buy-in agreements (see 42 beneficiaries are treated as eligible for and the Programs for All-inclusive Care CFR 406.26 and 407.40) are silent on the the Medicare Part D Low Income Subsidy (LIS), sometimes called Extra for the Elderly (PACE); frequency of buy-in data exchanges, • current guidance articulates that the Help; defined phased down state Supporting beneficiaries to obtain required buy-in data may be submitted contributions to partly finance Part D access to Medicare Part D benefits and daily, weekly, or monthly. We are costs for dually eligible beneficiaries; related subsidies sooner, as dual proposing to establish frequency and required risk-adjusting capitation eligibility status on the MMA file requirements in the regulations at 42 payments for low-income subsidy prompts CMS to deem individuals CFR 406.26(a)(1) and 407.40(c) to (which include dually eligible) enrollees automatically eligible for the Medicare require all states to participate in daily of Part D plans. To support these new Part D LIS and make changes to LIS exchange of buy-in data to CMS, with requirements, we issued 42 CFR status (for example, reducing ‘‘daily’’ meaning every business day, but 423.910, establishing monthly reporting copayments to $0 when data indicate a that if no new transactions are available by states, in which states would submit, move to a nursing facility or use of to transmit, data would not need to be at least monthly, a data file identifying home and community based long term submitted on a given business day. We dually eligible individuals in their state. care services) and auto-enroll them into believe these requirements will improve Over time, we used these files’ data on Medicare prescription drug coverage the economy and efficiency of operation dual eligibility status to support Part C back to the start of dual eligibility of the ‘‘buy-in’’ process. We propose status; and, capitation risk-adjustment, and most • that states would be required to begin recently, to feed dual eligibility status to Promoting protections for QMBs by participating in daily exchange of buy- Part A and B eligibility and claims improving the accuracy of data for in data with CMS by April 1, 2022. We processing systems so providers, providers and QMBs on zero cost- believe this effective date will allow suppliers, and beneficiaries have sharing liability for services under states to phase in any necessary accurate information on beneficiary Medicare Parts A and B. operational changes or bundle this cost-sharing obligations. As noted, current regulation requires required change with any new systems that the MMA files be submitted at least implementation. There are 19 states that It is required at 42 CFR 423.910 that monthly. We have implemented ‘‘work- we anticipate will need to make a states to submit at least one MMA file arounds’’ for lags in dual eligibility system change to send buy-in data to each month. However, states have the status for Part D, including the ‘‘Best CMS daily, and 22 states that we option to submit multiple MMA files Available Evidence’’ policy (see 42 CFR anticipate will need to make a system throughout the month (up to one per 423.800(d)), as well as the Limited change to receive buy-in data from CMS day). Most states submit MMA data files Income Newly Eligible Transition daily. We estimate the one-time cost to at least weekly; however, only 13 states demonstration, which provides short be a little less than $80,000 per state, submit MMA data files daily. As CMS term drug coverage for dually eligible per change. So a state that needs to now leverages MMA data on dual beneficiaries with no Part D plan make systems updates to both send buy- eligibility status into systems supporting enrollment in a given month (see in data daily, and receive buy-in data all four parts of the Medicare program, Medicare Prescription Drug Benefit daily would have a one-time cost of just it is becoming even more essential that Manual, Chapter 3, Section 40.1.4).35 under $160,000. We seek comment on dual eligibility status is accurate and While these work-arounds provide these proposals. up-to-date. Dual eligibility status can needed protections, more frequent data change at any time in a month. Waiting 3. Exchange of State MMA Data Files up to a month for status updates can 35 CMS, ‘‘Medicare Prescription Drug Benefit States submit data on files at least negatively impact access to the correct Manual: Chapter 3—Eligibility, Enrollment and monthly to CMS to identify all dually level of benefit at the correct level of Disenrollment (2017),’’ https://www.cms.gov/ payment. Based on our experience with Medicare/Eligibility-and-Enrollment/MedicarePres eligible individuals, including full- DrugEligEnrol/Downloads/CY_2018_PDP_ benefit and partial-benefit dually states that exchange data daily, more Enrollment_and_Disenrollment_Guidance_6-15- eligible beneficiaries (that is, those who frequent MMA file submissions benefit 17.pdf (last accessed September 26, 2018).

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00222 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7645

exchanges would mitigate the need for and enrollment status across Medicare, data liquidity, engagement with them. Medicaid, and related agencies (for stakeholders confirms that adverse Ensuring information on dual example, SSA), and reduce the need for incentives remain and continue to eligibility status is accurate and up-to- persons to provide, and states to collect/ undermine progress toward a more date by increasing the frequency of process, the same demographic connected health system. federal-state data exchange is an information (for example, address, Based on these economic realities and important step in the path to income). first-hand experience working with the interoperability. As a result, we are • For provider enrollment in both health IT industry and stakeholders, proposing to update the frequency Medicaid and Medicare, how ONC concluded in the Information requirements in 42 CFR 423.910(d) to interoperability can streamline provider Blocking Congressional Report that require that starting April 1, 2022, all enrollment and reduce provider and information blocking is a serious states submit the required MMA file state burden to increase systems problem and recommended that the data to CMS daily, and to make accuracy and beneficiary utilization of Congress prohibit information blocking conforming edits to 42 CFR provider enrollment data (for example, and provide penalties and enforcement 423.910(b)(1). Daily would mean every disability competence, hours of service, mechanisms to deter these harmful business day, but that if no new types of insurance accepted, etc.). practices. transactions are available to transmit, • For coordination of benefits, MACRA became law in the same data would not need to be submitted on including crossover claims, the month that the Information Blocking a given business day. We propose that underlying changes that would need to Congressional Report was published. states will be required to begin be made to support interoperability (for Section 106(b)(2)(A) of MACRA submitting these data daily to CMS by example, coding, file formats, provider/ amended section 1848(o)(2)(A)(ii) of the April 1, 2022, because we believe this beneficiary identifier, and encounter Act to require that an eligible effective date will allow states to phase versus FFS data). professional must demonstrate that he in any necessary operational changes or Please include specific examples or she has not knowingly and willfully bundle this required change with any when possible while avoiding the taken action (such as to disable new systems implementation. There are transmission of protected information. functionality) to limit or restrict the 37 states and the District of Columbia Please also include a point of contact compatibility or interoperability of that we anticipate will need to make a who can provide additional information certified EHR technology, as part of system change to send MMA data to upon request. being a meaningful EHR user. Section CMS daily. We estimate the one-time 106(b)(2)(B) of MACRA made cost for a state to be a little less than VIII. Information Blocking Background and Public Reporting corresponding amendments to section $80,000 for this MMA data systems 1886(n)(3)(A)(ii) of the Act for eligible change. For a detailed discussion of the A. Information Blocking Background hospitals and, by extension, under costs associated with these requirements section 1814(l)(3) of the Act for CAHs. we refer readers to section XVI. of this 1. Legislative Background and Policy Considerations Sections 106(b)(2)(A) and (B) of MACRA proposed rule. We seek comment on provide that the manner of this these proposals. The nature and extent of information demonstration is to be through a process B. Request for Stakeholder Input blocking has come into focus in recent specified by the Secretary, such as the years. In 2015, at the request of the use of an attestation. To implement In addition to the proposals Congress, ONC submitted a Report on these provisions, as discussed further recommended above, we seek public Health Information Blocking 36 below, we established and codified comment for consideration in future (hereinafter referred to as the attestation requirements to support the rulemaking on how we can achieve ‘‘Information Blocking Congressional prevention of information blocking, greater interoperability of federal-state Report’’), in which ONC commented on which consist of three statements data for dually eligible beneficiaries, the then current state of technology, containing specific representations including in the areas of program health IT, and health care markets. about a health care provider’s integrity and care coordination, Notably, ONC observed that prevailing implementation and use of CEHRT. To coordination of benefits and crossover market conditions create incentives for review our discussion of these claims, beneficiary eligibility and some individuals and entities to requirements, we refer readers to the CY enrollment, and their underlying data exercise their control over electronic 2017 Quality Payment Program final infrastructure. Specifically, we seek health information in ways that limit its rule (81 FR 77028 through 77035). comment on: availability and use. Since that time, • Whether existing regulations, as Recent empirical and economic ONC and other divisions of HHS have well as those proposed here, sufficiently research further underscores the continued to receive feedback regarding support interoperability among those complexity of the information blocking practices which may constitute serving dually eligible beneficiaries, and problem and its harmful effects. In a information blocking from patients, if not, what additional steps would national survey of health information clinicians, health care executives, advance interoperability. organizations, half of respondents payers, app developers and other • How to enhance the interoperability reported that EHR developers routinely technology companies, registries and of existing CMS processes to share engage in information blocking, and a health information exchanges, Medicare data with states for care quarter of respondents reported that professional and trade associations, and coordination and program integrity. hospitals and health systems routinely • How to improve the CMS and state many other stakeholders. Despite do so.37 Perceived motivations for data infrastructure to support significant public and private sector interoperability (for example, more efforts to improve interoperability and 37 See, for example, Julia Adler-Milstein and Eric Pfeifer, Information Blocking: Is It Occurring And frequent data exchanges, common data 36 environment, etc.). ONC, Report to Congress on Health Information What Policy Strategies Can Address It?, 95 Milbank • Blocking (Apr. 2015), https://www.healthit.gov/ Quarterly 117, 124–25 (Mar. 2017), available at For eligibility, how interoperability sites/default/files/reports/info_blocking_ http://onlinelibrary.wiley.com/doi/10.1111/1468- can provide timely, integrated eligibility 040915.pdf. 0009.12247/full.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00223 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7646 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

information blocking described by exchange, or use of electronic health history of public reporting and regular respondents included, for EHR vendors, information. The PHSA information updates about what information is maximizing short term revenue and blocking provision applies to health currently available, can also be accessed competing for new clients, and for care providers, health IT developers, on the Physician Compare Initiative hospitals and health systems, exchanges, and networks. The website at https://www.cms.gov/ strengthening their competitive position information blocking provision added to medicare/quality-initiatives-patient- relative to other hospitals and health PHSA by the Cures Act also provides assessment-instruments/physician- systems. Other research suggests that that the ‘‘Secretary, through rulemaking, compare-initiative/. these practices weaken competition shall identify reasonable and necessary As discussed in the CY 2018 Quality among health care providers by limiting activities that do not constitute Payment Program final rule (82 FR patient mobility, encouraging information blocking for purposes of the 53820), Physician Compare has consolidation, and creating barriers to definition at section 3022(a)(1) of the continued to pursue a phased approach entry for developers of new and PHSA.’’ ONC has taken the lead on this to public reporting under MACRA in innovative applications and rulemaking effort, and in addition to the accordance with section 1848(q)(9) of technologies that enable more effective attestation discussed in this section, all the Act. Specifically, subparagraphs (A) uses of clinical data to improve health care providers would also be and (D) of section 1848(q)(9) of the Act population health and the patient subject to the separate information facilitate the continuation of the phased experience.38 blocking regulations proposed by ONC approach to public reporting by In December 2016, section 4004 of the for HHS adoption at 45 CFR part 171 requiring the Secretary to make Cures Act added section 3022 of the (published elsewhere in this issue of the available on the Physician Compare PHSA (the ‘‘PHSA information blocking Federal Register). website, in an easily understandable provision’’), which defines conduct by We propose to publicly report certain format, individual MIPS eligible health care providers, health IT information about eligible clinicians’ clinician and group performance developers, and health information attestations under the QPP on Physician information, including: The MIPS exchanges and networks, that Compare and eligible hospitals’ and eligible clinician’s final score; the MIPS constitutes information blocking. The CAHs’ attestations under the Medicare eligible clinician’s performance under PHSA information blocking provision FFS Promoting Interoperability Program each MIPS performance category was enacted in response to ongoing (previously known as the Medicare EHR (quality, cost, improvement activities, concerns that some individuals and Incentive Program) on a CMS website. and Promoting Interoperability); names entities are engaging in practices that As discussed below, although we have of eligible clinicians in Advanced APMs unreasonably limit the availability and already implemented what is required and, to the extent feasible, the names of use of electronic health information for by sections 106(b)(2)(A) and (B) of such Advanced APMs and the authorized and permitted purposes (see MACRA through the attestation performance of such models; and, the definition of electronic health requirements we have established in aggregate information on the MIPS, information proposed by ONC for HHS prior rulemaking (81 FR 77028 through posted periodically, including the range adoption at 45 CFR 171.102 (published 77035), we believe publishing of final scores for all MIPS eligible elsewhere in this issue of the Federal information on which eligible clinicians and the range of the Register)). These practices undermine clinicians, eligible hospitals, and CAHs performance of all MIPS eligible public and private sector investments in have negatively attested that they have clinicians for each performance the nation’s health IT infrastructure and not knowingly and willfully taken category. frustrate efforts to use modern action to limit or restrict the In the CY 2018 Quality Payment technologies to improve health care compatibility or interoperability of Program final rule (82 FR 53827), we quality and efficiency, accelerate certified EHR technology would serve to finalized a policy to include an research and innovation, and provide discourage knowing and willful indicator on Physician Compare, as greater value and choice to health care behavior that limits interoperability and technically feasible, for any eligible consumers. prevents the sharing of information clinician or group who successfully The information blocking provision discussed in both MACRA and the meets the Promoting Interoperability added to PHSA defines and creates Cures Act. performance category. We also finalized a policy to include, as technically possible penalties and disincentives for B. Public Reporting and Prevention of information blocking in broad terms, feasible, additional information on Information Blocking on Physician Physician Compare, either on the profile working to deter the entire spectrum of Compare practices likely to interfere with, pages or in the downloadable database, prevent, or materially discourage access, Physician Compare (http:// including, but not limited to objectives, www.medicare.gov/physiciancompare) activities, or measures specified in the 38 See, for example, Martin Gaynor, Farzad draws its operating authority from CY 2018 Quality Payment Program final Mostashari, and Paul B. Ginsberg, Making Health section 10331(a)(1) of the Affordable rule (82 FR 53827; see 82 FR 53663 Care Markets Work: Competition Policy for Health Care Act. Consistent with section through 53688) with respect to the Care, 16–17 (Apr. 2017), available at http:// 10331(a)(2) of the Affordable Care Act, Promoting Interoperability performance heinz.cmu.edu/news/news-detail/ index.aspx?nid=3930; see also Diego A. Martinez et Physician Compare initiated a phased category. al., A Strategic Gaming Model For Health approach to publicly reporting Generally, all data available for public Information Exchange Markets, Health Care Mgmt. performance scores that provide reporting on Physician Compare must Science (Sept. 2016). Niam Yaraghi, A Sustainable comparable information on quality and meet our established public reporting Business Model for Health Information Exchange Platforms: The Solution to Interoperability in patient experience measures. A standards under 42 CFR 414.1395(b). In Healthcare IT (2015), available at http:// complete history of public reporting on addition, for each program year, CMS www.brookings.edu/research/papers/2015/01/30- Physician Compare is detailed in the CY provides a 30-day preview period for sustainable-business-model-health-information- 2016 Physician Fee Schedule (PFS) final any clinician or group with QPP data exchange-yaraghi; Thomas C. Tsai & Ashish K. Jha, Hospital Consolidation, Competition, and Quality: rule with comment period (80 FR 71117 being publicly reported on Physician Is Bigger Necessarily Better?, 312 J. AM. MED. through 71122). More information about Compare under 42 CFR 414.1395(d). All ASSOC. 29, 29 (2014). Physician Compare, including the data available for public reporting—

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00224 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7647

such as final scores—are available for Promoting Interoperability performance C. Public Reporting and Prevention of review and correction during the category, in addition to satisfying other Information Blocking for Eligible targeted review process as finalized in requirements, an eligible clinician must Hospitals and Critical Access Hospitals the CY 2017 Quality Payment Program submit an attestation response of ‘‘yes’’ (CAHs) final rule (81 FR 77392). for each of these statements. For more Section 1886(n)(4)(B) of the Act Building upon the continuation of our information about these statements, we requires the Secretary to post in an phased approach to public reporting refer readers to the preamble discussion easily understandable format a list of and understanding the importance of in the CY 2017 Quality Payment the names and other relevant data, as preventing information blocking, Program final rule (81 FR 77028 through determined appropriate by the promoting interoperability and the 81 FR 77035). Secretary, of eligible hospitals and sharing of information, we propose to CAHs who are meaningful EHR users make certain data about the attestation We believe it would benefit the public under the Medicare FFS program, on a statements on the prevention of to know if eligible clinicians have CMS website. In addition, that section information blocking referenced earlier attested negatively to the statements requires the Secretary to ensure that an in section VIII.A. of this proposed rule under 42 CFR 414.1375(b)(3)(ii) as this eligible hospital or CAH has the available for public reporting on may assist the patient in selecting a opportunity to review the other relevant Physician Compare, drawing upon our clinician or group who collaborates with data that are to be made public with authority under section 10331(a)(2) of other clinicians, groups, or other types respect to the eligible hospital or CAH Affordable Care Act, which requires us of health care providers by sharing to make publicly available on Physician prior to such data being made public. information electronically, and does not We believe certain information related Compare information on physician withhold information that may result in performance that provides comparable to the prevention of information better care. Therefore, we are proposing blocking attestation statements under 42 information for the public on quality to include an indicator on Physician and patient experience measures. CFR 495.40(b)(2)(i)(I)(1) through (3) Compare for the eligible clinicians and Section 10331(a)(2) of the Affordable would constitute other relevant data groups that submit a ‘‘no’’ response to Care Act provides that to the extent under section 1886(n)(4)(B) of the Act. scientifically sound measures that are any of the three statements under 42 Specifically, we are referring to the developed consistent with the CFR 414.1375(b)(3)(ii)(A) through (C). In three prevention of information requirements of section 10331 of the the event that these statements are left blocking attestation statements under 42 Affordable Care Act are available, such blank, that is, a ‘‘yes’’ or a ‘‘no’’ CFR 495.40(b)(2)(i)(I)(1) through (3) to information shall include, to the extent response is not submitted, the which eligible hospitals and CAHs must practicable, an assessment of the attestations would be considered attest for purposes of the Promoting coordination of care and other incomplete, and we would not include Interoperability Program. As part of information as determined appropriate an indicator on Physician Compare. We successfully demonstrating that an by the Secretary. We believe section also propose to post this indicator on eligible hospital or CAH is a meaningful 10331(a)(2) of the Affordable Care Act Physician Compare, either on the profile EHR user for purposes of the Promoting provides the statutory authority to pages or the downloadable database, as Interoperability Program, the eligible publicly report certain data about the feasible and appropriate, starting with hospital or CAH must submit an prevention of information blocking the 2019 performance period data attestation response of ‘‘yes’’ for each of these statements. For more information attestation statements as an assessment available for public reporting starting in about these statements, we refer readers of care coordination and as other late 2020. information determined appropriate by to the preamble discussion in the CY the Secretary. Furthermore, the Under 42 CFR 414.1395(b), these data 2017 Quality Payment Program final prevention of information blocking must meet our established public rule (81 FR 77028 through 81 FR 77035). attestation statements are required for a reporting standards, including that to be We believe it would be relevant to the clinician to earn a Promoting included on the public facing profile public to know if eligible hospitals and Interoperability performance category pages, the data must resonate with CAHs have attested negatively to the score, which is then incorporated into website users, as determined by CMS. In statements under 42 CFR the final score for MIPS, and we are previous testing with patients and 495.40(b)(2)(i)(I)(1) through (3) as it required to publicly report both of these caregivers, we have learned that could indicate that they are knowingly scores under section 1848(q)(9)(A) of the effective use of CEHRT is important to and unreasonably interfering with the Act. Publicly posting this information as them when making informed health care exchange or use of electronic health an indicator is consistent with our decisions. To determine how to best information in ways that limit its finalized policy to publicly report, display and meaningfully communicate availability and use to improve health either on the profile pages or in the the indicator on the Physician Compare care. As we stated in the CY 2017 downloadable database, other aspects of website, the exact wording and, if Quality Payment Program final rule, we believe that addressing issues related to the Promoting Interoperability applicable, profile page indicator would information blocking would require performance category, such as be determined after user testing and additional and more comprehensive objectives, activities, or measures shared with stakeholders through the specified in the CY 2018 Quality measures (81 FR 77029). In addition, Physician Compare Initiative page, Payment Program final rule. publicly posting this information would There are three prevention of listservs, webinars, and other available reinforce our commitment to focus on information blocking attestation communication channels. We note this increased interoperability and the statements under 42 CFR proposal is contingent upon the appropriate exchange of health 414.1375(b)(3)(ii)(A) through (C) to availability of and technical feasibility information. We propose to post which eligible clinicians reporting on to use these data for public reporting. information on a CMS website available the Promoting Interoperability We request comment on this proposal. to the public indicating that an eligible performance category of MIPS must hospital or CAH attesting under the attest. To report successfully on the Medicare FFS Promoting

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00225 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7648 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Interoperability Program submitted a scanned paper documents, and Information Service Providers (HISPs) ‘‘no’’ response to any of the three ultimately enhancing care coordination. (https://www.healthit.gov/sites/default/ statements under 42 CFR To ensure the index is accessible to files/directbasicsforprovidersqa_ 495.40(b)(2)(i)(I)(1) through (3). In the all clinicians and facilities, we have 05092014.pdf). NPPES can also capture event that these statements are left updated the NPPES 39 to be able to information about a wide range of other blank, that is, a ‘‘yes’’ or a ‘‘no’’ capture digital contact information for types of endpoints that providers can response is not submitted, the both individuals and facilities. NPPES use to facilitate secure exchange of attestations would be considered currently supplies National Provider health information, for instance a FHIR incomplete, and we would not post any Identifier (NPI) numbers to health care server URL or query endpoint associated information related to these attestation providers (both individuals and with a health information exchange. statements for that hospital or CAH. We facilities), maintains their NPI record, In addition, NPPES can now maintain propose to post this information starting and publishes the records online.40 The information about the type of contact with the attestations for the EHR Secretary adopted the NPI as the HIPAA information providers and organizations reporting period in 2019, and we expect administrative simplification standard are associated with, along with the the information would be posted in late identifier for health care providers (69 preferred uses for each address. Each 2020. In accordance with section FR 3434). HIPAA covered entities, provider in NPPES can maintain their 1886(n)(4)(B) of the Act, we propose to including health care providers, health own unique information or associate establish a process for each eligible plans, and health care clearinghouses, themselves with information shared hospital and CAH to review the must use the NPI in HIPAA among a group of providers. Finally, NPPES has also added a public API information related to their specific transactions. All health care providers which can be used to obtain contact prevention of information blocking that transmit health information in information stored in the database. attestation statements before it is electronic form in connection with a Although NPPES is now better equipped publicly posted on a CMS website. HIPAA transaction must obtain an NPI. Health care providers are required to to maintain provider digital contact Specifically, for each program year, we communicate to the NPPES any information, many providers have not propose a 30-day preview period for an information that has changed within 30 submitted this information. In the 2015 eligible hospital or CAH to review this days of the change (45 CFR final rule, ‘‘Medicare and Medicaid information before it is publicly posted. 162.410(a)(4)). CMS reviews NPPES to Programs; Electronic Health Record During the 30-day preview period, we ensure a provider has a valid NPI as part Incentive Program-Stage 3 and propose that all of the information that of the Medicare enrollment process, as Modifications to Meaningful Use in we would publicly post would be well as the revalidation process, which 2015 Through 2017’’ (80 FR 62901), we available for the eligible hospital or occurs every 3 to 5 years depending on finalized a policy to collect information CAH to review, and we would consider the provider or supplier type. in NPPES about the electronic addresses making changes to the information on a Information in NPPES is publicly of participants in the EHR Incentive case-by-case basis (for example, in the accessible via both an online search Program (specifically, a Direct address event the eligible hospital or CAH option and a downloadable database and/or other ‘‘electronic service identifies an error, and we subsequently option. As a result, adding digital information’’ as available). However, determine that the information is not contact information to this existing this policy was not fully implemented at accurate). Additional information on the index is an efficient and effective way the time, in part due to the limitations review process will be provided outside to meet the Congressional requirement of the NPPES system which have since of the rulemaking process through the to establish a digital contact information been addressed. As a result, many usual communication channels for the index and to promote the sharing of providers have not yet added their program. We invite comments on this information. digital contact information to NPPES proposal. As of June 2018, NPPES has been and digital contact information is IX. Provider Digital Contact updated to include the capability to frequently out of date. In light of these updates to the NPPES Information capture one or more pieces of digital contact information that can be used to system, all individual health care A. Background facilitate secure sharing of health providers and facilities can take information. For instance, providers can immediate action to update their NPPES Congress required the Secretary to submit a Direct address, which record online to add digital contact create a provider digital contact functions similar to a regular email information. This simple step will information index in section 4003 of the address, but includes additional significantly improve interoperability by Cures Act. This index must include all security measures to ensure that making valuable contact information individual health care providers and messages are only accessible to the easily accessible. For those providers health care facilities, or practices, in intended recipient in order to keep the who continue to rely on the use of order to facilitate a comprehensive and information confidential and secure. cumbersome, fax-based modes of open exchange of patient health ‘‘Direct’’ is a technical standard for sharing information, we hope that information. Congress gave the exchanging health information. Direct greater availability of digital contact Secretary the authority to use an addresses are available from a variety of information will help to reduce barriers existing index or to facilitate the sources, including EHR vendors, State to electronic communication with a creation of a new index. In comments Health Information Exchange entities, wider set of providers with whom they received on the FY 2019 IPPS proposed regional and local Health Information share patients. Ubiquitous, public rule RFI, there was strong support for a Exchange entities, as well as private availability of digital contact single, public directory of provider service providers offering Direct information for all providers is a crucial digital contact information. Commenters exchange capabilities called Health step towards eliminating the use of fax noted that digital communication could machines for the exchange of health improve interoperability by facilitating 39 The NPPES website is available at https:// information. We urge all providers to efficient exchange of patient records, nppes.cms.hhs.gov/. take advantage of this resource to eliminating the burden of working with 40 See https://nppes.cms.hhs.gov/. implement Congress’ requirement that

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00226 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7649

the Secretary establish a digital contact consideration in future rulemaking on Critical Access Hospitals, and Home information index. these questions. Health Agencies’’ (80 FR 68126), to implement the discharge planning B. Proposed Public Reporting of Missing X. Revisions to the Conditions of requirements of the IMPACT Act and to Participation for Hospitals and Critical Digital Contact Information revise the discharge planning CoP Access Hospitals (CAHs) Entities seeking to engage in requirements that hospitals (including electronic health information exchange A. Background short-term acute care hospitals, LTCHs, need accurate information about the As noted earlier in this proposed rule, rehabilitation hospitals, psychiatric electronic addresses (for example, Direct CMS appreciates the pathways Congress hospitals, children’s hospitals, and address, FHIR server URL, query has created for action on cancer hospitals), CAHs, and HHAs endpoint, or other digital contact interoperability and has been working must meet in order to participate in the information) of potential exchange diligently with ONC to implement them. Medicare and Medicaid programs. The partners. A common directory of the In order to ensure broad stakeholder final rule in response to public electronic addresses of health care input to inform our proposals, we comment on our proposed new providers and organizations could published a Request for Information requirements for discharge planning for enhance interoperability and (RFI) on interoperability in several hospitals, CAHs, and HHAs is under information exchange by providing a recently published proposed rules, development while we review and respond to public comments (our resource where users can obtain including the FY 2019 IPPS proposed deadline to finalize this rule is information about how to securely rule (83 FR 20550). Specifically, we November 3, 2019). Several of the transmit electronic health information published the RFI entitled, ‘‘Promoting proposed requirements from the 2015 to a provider. Interoperability and Electronic Discharge Planning proposed rule We propose to increase the number of Healthcare Information Exchange directly addressed the issue of providers with valid and current digital Through Possible Revisions to the CMS communication between providers and contact information available through Patient Health and Safety Requirements between providers and patients, as well NPPES by publicly reporting the names for Hospitals and Other Medicare- and as the issue of interoperability: and NPIs of those providers who do not Medicaid-Participating Providers and have digital contact information Suppliers.’’ We requested stakeholders’ • Hospitals and CAHs would be required included in the NPPES system. We input on how we could use the CMS to transfer certain necessary medical propose to begin this public reporting in health and safety standards that are information and a copy of the discharge the second half of 2020, to allow instructions and discharge summary to the required for providers and suppliers patient’s practitioner, if the practitioner is individuals and facilities time to review participating in the Medicare and known and has been clearly identified; their records in NPPES and update the Medicaid programs (that is, the • Hospitals and CAHs would be required system with appropriate digital contact Conditions of Participation (CoPs), to send certain necessary medical information. We are also requesting Conditions for Coverage (CfCs), and information to the receiving facility/PAC comment from stakeholders on the most providers, at the time of discharge; and, Requirements for Participation (RfPs) for • appropriate way to pursue this public long term care facilities) to further Hospitals, CAHs, and HHAs would need reporting initiative, including where to comply with the IMPACT Act advance electronic exchange of requirements that would require hospitals, these names should be posted, with information that supports safe, effective CAHs, and certain PAC providers to use data what frequency, and any other transitions of care between hospitals on quality measures and data on resource use information stakeholders believe would and community providers. Specifically, measures to assist patients during the be helpful. we asked for comment on revisions to discharge planning process, while taking into We believe this information is the current CMS CoPs for hospitals such account the patient’s goals of care and extremely valuable to facilitate as: Requiring that hospitals transferring treatment preferences. interoperability, and we appreciate medically necessary information to We also published the ‘‘Medicare and Congress’ leadership in requiring the another facility upon a patient transfer Medicaid Programs; Hospital and establishment of this directory. We are or discharge do so electronically; Critical Access Hospital Changes to interested in stakeholder comment on requiring that hospitals electronically Promote Innovation, Flexibility and additional possible enforcement send required discharge information to Improvement in Patient Care’’ proposed authorities to ensure that individuals a community provider via electronic rule (81 FR 39448) on June 16, 2016, and facilities make their digital contact means if possible and if a community which is under development while we information publicly available through provider can be identified; and, review and respond to public comments NPPES. For example, should Medicare requiring that hospitals make certain (our deadline to finalize this rule is June reporting programs, such as MIPS, information available to patients or a 15, 2019). In that rule, we proposed require eligible clinicians to update specified third-party application (for updating a number of CoP requirements their NPPES data with their digital example, required discharge that hospitals and CAHs would have to contact information? Should CMS instructions) via electronic means if meet to participate in the Medicare and require this information to be included requested. Medicaid programs. One of the as part of the Medicare enrollment and The RFI discussed several steps we proposed hospital CoP revisions directly revalidation process? How can CMS have taken in recent years to update and addressed the issues of communication work with states to promote adding modernize the CoPs and other health between providers and patients, patient information to the directory through and safety standards to reflect current access to their medical records, and state Medicaid programs and CHIP? best practices for clinical care, interoperability. We proposed that Should CMS require providers to submit especially in the area of care patients have the right to access their digital contact information as part of coordination and discharge planning. medical records, including current program integrity processes related to On November 3, 2015, we published a medical records, upon an oral or written prior authorization and submission of proposed rule, ‘‘Medicare and Medicaid request, in the form and format medical record documentation? We will Programs; Revisions to Requirements for requested by such patients, if the review comments for possible Discharge Planning for Hospitals, information is readily producible in

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00227 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7650 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

such form and format (including in an authors identified a number of studies notifications can help ensure that a electronic form or format when such demonstrating positive effects on receiving provider is aware that the medical records are maintained outcomes associated with better care patient has received care elsewhere. The electronically); or, if not, in a readable coordination, such as reductions in 30- notification triggers a receiving provider hard copy form or such other form and day readmissions,42 43 44 and medication to reach out to the patient and deliver format as agreed to by the facility and reconciliation.45 appropriate follow-up care in a timely the individual, and within a reasonable Electronic patient event notifications manner. By notifying the physician, care timeframe. Under the proposal, a from hospitals, or clinical event manager, or care management team, the hospital could not frustrate the notifications, are one type of health notification can help to improve post- legitimate efforts of individuals to gain information exchange intervention that discharge transitions and reduce the access to their own medical records and has been increasingly recognized as an likelihood that a patient would face would be required to meet these patient effective and scalable tool for improving complications from inadequate follow- requests as quickly as record keeping care coordination across settings, up care. systems permit. especially for patients at discharge. This In addition to their effectiveness in In response to the recent RFI in the approach has been identified with a supporting care coordination, virtually FY 2019 IPPS proposed rule, many reduction in readmissions following all EHR systems generate the basic stakeholders supported our goals of implementation.46 We note that the messages commonly used to support increasing interoperability and evidence cited in this section to support electronic patient event notifications. acknowledged the important role that the use of innovative health information These notifications are based on hospital settings play in supporting care exchange interventions and approaches, admission, discharge, and transfer coordination. Stakeholders agreed that such as the patient event notifications (ADT) messages, a standard message use of electronic technology was an that we are proposing to require in this used within an EHR as the vehicle for important factor in ensuring safe rule, can be applied to various types of communicating information about key transitions. At the same time, many hospitals, including psychiatric changes in a patient’s status as they are stakeholders expressed concerns about hospitals, as well as to CAHs, as tracked by the system (more information implementing policy changes within the discussed below. about the current standard supporting CoPs, which may increase the Patient event notifications are these messages is available at http:// compliance burden on hospitals. www.hl7.org/implement/standards/ automated, electronic communications _ _ Given responses to the recent RFI, as from the discharging provider to another product brief.cfm?product id=144). As well as previous rulemaking activities, facility, or to another community noted in the ISA published by ONC, this we are seeking to further expand CMS provider as identified by the patient, messaging standard has been widely requirements for interoperability within which alerts the receiving provider that adopted across the health care system the hospital and CAH CoPs as part of the patient has received care at a (see https://www.healthit.gov/isa/ this proposed rulemaking by focusing different setting. Depending on the sending-a-notification-a-patients- on electronic patient event notifications. implementation, information included admission-discharge-andor-transfer- In addition, we are committed to taking with these notifications can range from status-other-providers). ADT messages provide each patient’s further steps to ensure that facilities that conveying the patient’s name, other personal or demographic information are electronically capturing information basic demographic information, and the (such as the patient’s name, insurance, are electronically exchanging that sending institution to a richer set of next of kin, and attending physician), information with providers who have clinical data on the patient. Regardless when that information has been the capacity to accept it. We expect that of the information included, these this will be required through updated, and also indicate when an ADT status has changed. To create an rulemaking at a future point in time, Assoc. 2018 Apr 28, accessed at https:// with one option being alignment with www.ncbi.nlm.nih.gov/pubmed/29718258. electronic patient event notification, a the TEFCA described in section 4003 of 42 Yeaman B, Ko KJ, Alvarez del Castillo R. Care system can use the change in ADT the Cures Act. We will also continue to ransitions in long-term care and acute care: Health status to trigger a message to a receiving information exchange and readmission rates. consider the RFI responses as we pursue provider or to a health information Online J Issues Nurs 2015;20(3):5. Accessed at exchange system that can then route the this goal in future rulemaking. https://www.ncbi.nlm.nih.gov/pubmed/26882514. Infrastructure supporting the 43 Vest JR, Kern LM, Silver MD, Kaushal R, message to the appropriate provider. In exchange of electronic health investigators H. The potential for community-based addition to the basic demographic information across settings has matured health information exchange systems to reduce information contained in the ADT hospital readmissions. J Am Med Inform Assoc, message, some patient event notification substantially in recent years. Research 2015 March, accessed at https:// studies have increasingly found that www.ncbi.nlm.nih.gov/pubmed/25100447. implementations attach more detailed health information exchange 44 Unruh MA, Jung HY, Kaushal R, Vest JR, information to the message regarding interventions can effect positive Hospitalization event notifications and reductions the patient’s clinical status and care in readmissions of Medicare FFS beneficiaries in received from the sending provider. outcomes in health care quality and the Bronx, New York. J AM Med Inform Assoc, public health, in addition to more 2017 Apr 1, accessed at https:// B. Proposal for Hospitals (Proposed 42 longstanding findings around www.ncbi.nlm.nih.gov/pubmed/28395059. CFR 482.24(d)) reductions in utilization and costs. A 45 Boockvar KS, Ho W, Pruskowski J, et al. Effect We propose to revise the CoPs for recent review of how health information of health information exchange on recognition of medication discrepancies is interrupted when data Medicare- and Medicaid-participating exchange interventions can improve charges are introduced: Results of a cluster- hospitals at 42 CFR 482.24 by adding a cost and quality outcomes identified a randomized controlled trial. J Am Med Inform new standard at paragraph (d), growing body of high-quality studies Assoc 2017, accessed at https:// ‘‘Electronic Notifications,’’ that would showing that these interventions are www.ncbi.nlm.nih.gov/pubmed/28505367. 46 Unruh MA, Jung HY, Kaushal R, Vest JR, require hospitals to send electronic associated with beneficial results.41 The Hospitalization event notifications and reductions patient event notifications of a patient’s in readmissions of Medicare FFS beneficiaries in 41 Menachemi N, Rahurkar S, Harle CA, Vest JR, the Bronx, New York. J AM Med Inform Assoc, admission, discharge, and/or transfer to The benefits of health information exchange: An 2017 Apr 1, accessed at https:// another health care facility or to another updated systematic review, J Am Med Inform www.ncbi.nlm.nih.gov/pubmed/28395059. community provider. As noted in the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00228 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7651

discussion above, we would require standard, which is widely used as the pursuing more advanced content as part hospitals to convey, at a minimum, the basis for implementing these of patient notifications, nor to create patient’s basic personal or demographic notifications and other similar use redundant requirements where hospitals information, as well as the name of the cases, would meet this goal by already have a suitable notification sending institution (that is, the supporting the availability of system in place. Accordingly, while we hospital), and, if not prohibited by other information that can be used to generate are requiring that hospitals subject to applicable law, diagnosis. We would information for patient event this proposal possess a system utilizing also encourage hospitals, as their notifications. Specifically, we propose this standard, hospitals may utilize systems and those of the receiving that the system utilize the ADT other standards or features to support providers allow, to work with patients Messaging standard incorporated by their notification systems. We request and their practitioners to offer more reference at 45 CFR 170.299(f)(2).47 comment on this proposal, and whether robust patient information and clinical While there is no criterion under the this requirement would achieve the goal data upon request in accordance with ONC Health IT Certification Program of setting a baseline for hospitals’ applicable law. which certifies health IT to create and capacity to generate information for For a hospital that currently possesses send electronic patient event electronic notifications, while still an EHR system with the capacity to notifications, this standard is referenced allowing for innovative approaches that generate the basic patient personal or by other certification criteria under the would potentially increase the demographic information for electronic program. Specifically, this standard effectiveness of these notifications patient event (ADT) notifications, supports certification criteria related to toward improving patient outcomes and compliance with this proposed standard transferring information to safety during transitions in care. within the Medical records services CoP immunization registries, as well as We further propose that the hospital (42 CFR 482.24) would be determined transmission of laboratory results to would need to demonstrate that the by the hospital demonstrating that its public health agencies as described at system’s notification capacity is fully system: (1) Is fully operational and that 45 CFR 170.315(f) under the 2015 operational, that it operates in it operates in accordance with all State Edition certification criteria, and at 45 accordance with all state and federal and Federal statutes and regulations CFR 170.314(f) under the 2014 Edition. statutes and regulations regarding the regarding the exchange of patient health Thus, we expect systems that include exchange of patient health information. information; (2) utilizes the content Health IT Modules certified to meet We intend for these notifications to be exchange standard incorporated by criteria which reference this standard required, at minimum, for inpatients reference at 45 CFR 170.299(f)(2); (3) will possess the basic capacity to admitted to, and discharged and/or sends notifications that must include generate information for notification transferred from the hospital. However, the minimum patient health information messages. We further note that adopting we also note that patient event (which must be patient name, treating certified health IT that meets these notifications are an effective tool for practitioner name, sending institution criteria has been required for any coordinating care across a wider set of name, and, if not prohibited by other hospital seeking to qualify for the patients that may be cared for by a applicable law, patient diagnosis); and Promoting Interoperability Programs hospital. For instance, a patient event (4) sends notifications directly, or (formerly the EHR Incentive Programs). notification could ensure a primary care through an intermediary that facilitates We recognize that there is currently physician is aware that their patient has exchange of health information, and at significant variation in how hospitals received care at the emergency room, the time of the patient’s admission to have utilized the ADT messages to and initiate outreach to the patient to the hospital and either immediately support implementation of patient event ensure that appropriate follow-up for prior to or at the time of the patient’s notifications. We also recognize that the emergency visit is pursued. While discharge and/or transfer from the many hospitals, which have already we encourage hospitals to extend the hospital. We recognize that some implemented notifications, may be coverage of their notification systems to existing ADT messages might not delivering additional information serve additional patients, outside of include diagnosis and therefore seek beyond the basic information included those admitted and seen as inpatients, comment on the technical feasibility of in the ADT message (both automatically we also seek comment on whether we including this information as well as the when a patient’s status changes and should identify a broader set of patients challenges in appropriately segmenting then upon request from receiving to whom this requirement would apply, this information in instances where the providers) to receiving practitioners, and if so, how we should implement diagnosis may not be permitted for patient care team members, and post- such a requirement in a way that disclosure under other applicable laws. acute care services providers and minimizes administrative burden on We propose to limit this requirement suppliers with whom they have hospitals. to only those hospitals which currently established patient care relationships Additionally, we are proposing that possess EHR systems with the technical and agreements for patient health the hospital must demonstrate that its capacity to generate information for information exchange as allowed by system sends notifications that must electronic patient event notifications as law. We believe consensus standards for include the minimum patient health discussed below, recognizing that not ADT-based notifications may become information (which must be patient all Medicare- and Medicaid- more widely adopted in the future (we name, treating practitioner name, participating hospitals have been refer readers to ONC’s ISA 48 for more sending institution name, and, if not eligible for past programs promoting information about standards under prohibited by other applicable law, adoption of EHR systems. Our goal with consideration). However, at this time, patient diagnosis). The hospital would this proposed requirement is to ensure we do not wish to restrict hospitals from also need to demonstrate that the system that hospital EHR systems have a basic sends notifications directly, or through capacity to generate messages that can 47 Health Level Seven Messaging Standard an intermediary that facilitates exchange be utilized for notifications by a wide Version 2.5.1 (HL7 2.5.1), an Application Protocol of health information, and at the time of for Electronic Data Exchange in Healthcare range of receiving providers, enabled by Environments, February 21, 2007. the patient’s admission to the hospital, common standards. We believe that a 48 https://www.healthit.gov/isa/admission- to licensed and qualified practitioners, system that utilizes the ADT messaging discharge-and-transfer. other patient care team members, and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00229 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7652 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

PAC services providers and suppliers specifically request notifications for a necessary medical information within that: (1) Receive the notification for given patient for whom they are the same message as a patient event treatment, care coordination, or quality responsible for care coordination as notification. improvement purposes; (2) have an confirmed through conversations with As previously stated, we are established care relationship with the the patient. committed to continuing to identify patient relevant to his or her care; and Additionally, we would expect further steps we can take to ensure that (3) for whom the hospital has a hospitals, psychiatric hospitals, and facilities that are electronically reasonable certainty of receipt of CAHs to comply with the Health capturing information are exchanging notifications. Similarly, we are also Insurance Portability and that information electronically with proposing that the hospital would need Accountability Act (HIPAA) privacy providers that have the capacity to to demonstrate the transmission of these rules set out at 45 CFR parts 160 and accept it. We expect that this will be notifications either directly, or through 164 when these proposed CoP required through rulemaking at a future an intermediary that facilitates the requirements for patient event point in time with one option being exchange of health information, and notifications are finalized. As required alignment with the TEFCA described in either immediately prior to or at the at 42 CFR 482.11 for hospitals and the Cures Act. psychiatric hospitals and at 42 CFR time of the patient’s discharge or C. Proposal for Psychiatric Hospitals 485.608 for CAHs, these providers must transfer from the hospital, to licensed (Proposed 42 CFR 482.61(f)) and qualified practitioners, other patient comply with all pertinent currently care team members, and PAC services existing federal laws, including the Medicare- and Medicaid-participating providers and suppliers that: (1) Receive HIPAA Privacy Rule. The patient event psychiatric hospitals must comply with the notification for treatment, care notifications and other exchanges of all of the hospital CoPs at 42 CFR 482.1 through 482.23 and at 42 CFR 482.25 coordination, or quality improvement patient information would be permitted through 482.57. They also must adhere purposes; (2) have an established care as disclosures for treatment purposes to special provisions regarding medical relationship with the patient relevant to under 45 CFR part 164. records at 42 CFR 482.61 and staffing his or her care; and (3) for whom the We also recognize that factors outside requirements at 42 CFR 482.62. Since hospital has a reasonable certainty of of the hospital’s control may determine the medical records requirements are receipt of notifications. We believe this whether or not a notification is different for psychiatric hospitals, and proposal will allow for a diverse set of successfully received and utilized by a since these hospitals do not have to strategies that hospitals might use when practitioner. Accordingly, we have comply with our regulations at 42 CFR implementing patient event proposed that a hospital would only 482.24, we are proposing a new notifications. need to send notifications to those practitioners for whom the hospital has electronic notification standard at 42 Through these provisions, we are reasonable certainty of receipt. While CFR 482.61(f) within the special seeking to allow for different ways that we expect hospitals will, to the best of provisions for psychiatric hospitals in a hospital might identify those their ability, seek to ensure that this section. practitioners, other patient care team notification recipients are able to Similar to our proposal for hospitals members, and PAC services providers receive notifications (for instance, by at 42 CFR 482.24(d), we are proposing and suppliers that are most relevant to obtaining a recipient’s Direct address), a new standard at 42 CFR 482.61(f), both the pre-admission and post- we understand that technical issues ‘‘Electronic Notifications,’’ that would discharge care of a patient. We are beyond the hospital’s control may require psychiatric hospitals to send proposing that hospitals should send prevent successful receipt and use of a electronic patient event notifications of notifications to those practitioners or notification. a patient’s admission, discharge, and/or providers that have an established care Finally, we note that hospitals have transfer to another health care facility or relationship with the patient relevant to an existing responsibility under the to another community provider. his or her care. We recognize that CoPs at 42 CFR 482.43(d) to ‘‘transfer or As we have proposed for hospitals, hospitals and their partners may refer patients, along with necessary we propose to limit this requirement to identify appropriate recipients through medical information, to appropriate only those psychiatric hospitals which various methods. For instance, hospitals facilities, agencies, or outpatient currently possess EHR systems with the might identify appropriate practitioners services, as needed, for follow-up or technical capacity to generate by requesting this information from ancillary care.’’ We wish to emphasize information for electronic patient event patients or caregivers upon arrival, or by that our proposal regarding patient notifications, defined as systems that obtaining information about care team event notifications would be separate utilize the content exchange standard members from the patient’s record. We from the requirement regarding incorporated by reference at 45 CFR expect hospitals might develop or necessary medical information at 42 170.299(f)(2). We propose that for a optimize processes to capture CFR 482.43(d). We recognize that psychiatric hospital that currently information about established care processes to implement this proposal, if possesses an EHR system with the relationships directly, or work with an finalized, may intersect with the capacity to generate the basic patient intermediary that maintains information hospital’s discharge planning process. personal or demographic information about care relationships. In other cases, We note that nothing in this proposal for electronic patient event (ADT) hospitals may, directly or through an would affect the hospital’s notifications, compliance with this intermediary, identify appropriate responsibilities under 42 CFR 482.43(d). proposed standard within the Special notification recipients through the However, if this proposal is finalized, medical records requirements for analysis of care patterns or other hospitals may wish to consider ways to psychiatric hospitals CoP (42 CFR attribution methods that seek to fulfill these requirements in ways that 482.61) would be determined by the determine the provider most likely to be reduce redundancy while still hospital demonstrating that its system: able to effectively coordinate care post- remaining compliant with existing (1) Is fully operational and that it discharge for a specific patient. The requirements. For instance, where operates in accordance with all State hospital or intermediary might also appropriate and allowed by law, and Federal statutes and regulations develop processes to allow a provider to hospitals may seek to include required regarding the exchange of patient health

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00230 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7653

information; (2) utilizes the content Therefore, similar to our proposals for treatment, care coordination, or quality exchange standard incorporated by the hospital and psychiatric hospital improvement purposes; (2) have an reference at 45 CFR 170.299(f)(2); (3) medical records requirements as established care relationship with the sends notifications that must include discussed in the preceding sections, we patient relevant to his or her care; and the minimum patient health information would revise 42 CFR 485.638, by adding (3) for whom the CAH has a reasonable (which must be patient name, treating a new standard to the CAH Clinical certainty of receipt of notifications. practitioner name, sending institution records CoP at paragraph (d), Similarly, we are also proposing that the name, and, if not prohibited by other ‘‘Electronic Notifications.’’ This CAH would need to demonstrate the applicable law, patient diagnosis); and proposed standard would require CAHs transmission of these notifications (4) sends notifications directly, or to send electronic patient event either directly, or through an through an intermediary that facilitates notifications of a patient’s admission, intermediary that facilitates the exchange of health information, and at discharge, and/or transfer to another exchange of health information, and the time of the patient’s admission to health care facility or to another either immediately prior to or at the the hospital and either immediately community provider. time of the patient’s discharge or prior to or at the time of the patient’s We propose to limit this requirement transfer from the CAH, to licensed and discharge and/or transfer from the to only those CAHs which currently qualified practitioners, other patient hospital. Please note that we are possess EHR systems with the technical care team members, and PAC services requesting comment on this policy as capacity to generate information for providers and suppliers that: (1) Receive part of this hospital proposal in section electronic patient event notifications, the notification for treatment, care X.B. of this proposed rule above. Please defined as systems that utilize the coordination, or quality improvement see additional discussion in the content exchange standard incorporated purposes; (2) have an established care proposal for hospitals above. by reference at 45 CFR 170.299(f)(2). We relationship with the patient relevant to Additionally, we are proposing that propose that for a CAH that currently his or her care; and (3) for whom the the hospital would need to demonstrate possesses an EHR system with the CAH has a reasonable certainty of that the system sends notifications capacity to generate the basic patient receipt of notifications. directly, or through an intermediary that personal or demographic information We request comments on all of these facilitates exchange of health for electronic patient event (ADT) proposals. We are especially interested information, and at the time of the notifications, compliance with this in stakeholder feedback about how these patient’s admission to the hospital, to proposed standard within the Clinical proposals should be operationalized. licensed and qualified practitioners, records services CoP (42 CFR 485.638) Additionally, we seek comment on how other patient care team members, and would be determined by the CAH CMS should implement these proposals PAC services providers and suppliers demonstrating that its system: (1) Is as part of survey and certification that: (1) Receive the notification for fully operational and that it operates in guidance in a manner that minimizes treatment, care coordination, or quality accordance with all State and Federal compliance burden on hospitals, improvement purposes; (2) have an statutes and regulations regarding the psychiatric hospitals, and CAHs while established care relationship with the exchange of patient health information; ensuring adherence with the standards. patient relevant to his or her care; and (2) utilizes the content exchange We are also interested in stakeholder (3) for whom the hospital has a standard incorporated by reference at 45 input about a reasonable timeframe for reasonable certainty of receipt of CFR 170.299(f)(2); (3) sends implementation of these proposals for notifications. Similarly, we are also notifications that must include the hospitals, psychiatric hospitals, and proposing that the hospital would need minimum patient health information CAHs, respectively. to demonstrate the transmission of these (which must be patient name, treating notifications either directly, or through practitioner name, sending institution XI. Request for Information on an intermediary that facilitates the name, and, if not prohibited by other Advancing Interoperability Across the exchange of health information, and applicable law, patient diagnosis); and Care Continuum either immediately prior to or at the (4) sends notifications directly, or A. Background time of the patient’s discharge or through an intermediary that facilitates transfer from the hospital, to licensed exchange of health information, and at Transitions across care settings have and qualified practitioners, other patient the time of the patient’s admission to been characterized as common, care team members, and PAC services the CAH and either immediately prior to complicated, costly, and potentially providers and suppliers that: (1) Receive or at the time of the patient’s discharge hazardous for individuals with complex the notification for treatment, care and/or transfer from the CAH. Please health needs. Yet despite the need for coordination, or quality improvement note that we are requesting comment on functionality to support better care purposes; (2) have an established care this policy as part of the hospital coordination, discharge planning, and relationship with the patient relevant to proposal above in section X.B. of this timely transfer of essential health his or her care; and (3) for whom the proposed rule. Please see additional information, interoperability by certain hospital has a reasonable certainty of discussion in the proposal for hospitals health care providers such as long term receipt of notifications. above. and PAC, behavioral health, and home We refer readers to the extended Additionally, we are proposing that and community-based services discussion of these proposals in sections the CAH would need to demonstrate continues to lag behind acute care X.A. and B. of this proposed rule. We that the system sends notifications providers. Research from the Assistant seek comment on these proposals. directly, or through an intermediary that Secretary for Planning and Evaluation facilitates exchange of health (ASPE) and CMS, showed that in 2014, D. Proposal for CAHs information, and at the time of the 44 percent of patients discharged from We believe implementation of patient patient’s admission to the CAH, to an acute care hospitalization received event notifications are also important licensed and qualified practitioners, post-acute services, such as an for CAHs to support improved care other patient care team members, and admission to a SNFs, an IRF or a LTCH, coordination from these facilities to PAC services providers and suppliers or received HHA services. Specifically, other providers in their communities. that: (1) Receive the notification for of the 1,260,958 patients that received

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00231 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7654 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

post-acute services following an acute adverse outcomes. A well-documented Programs. We are seeking input on how care hospitalization, ‘‘. . . 47.8 percent contributor to this problem is HHS can more broadly incentivize the were discharged to a HHA, 42.1 percent incomplete and missing information for adoption of interoperable health IT to a SNF, 8.4 percent to an IRF, 1.0 patients with frequent transitions across systems and use of interoperable data percent to a LTCH and .7 percent to care settings. While interoperable, across settings such as long-term and LTCH-Site Neutral.’’ 49 In addition to the bidirectional exchange of essential PAC, behavioral health, and those frequency of patients discharged from health information can improve these settings serving individuals who are acute care to PAC, a remarkable number transitions, many long-term and PAC, dually eligible for Medicare and of patients discharged from PAC behavioral health, and home and Medicaid and/or receiving home and services receive subsequent care by community-based service providers community-based services. We invite another PAC provider. For instance, have not adopted health IT at the same comment on specific policy strategies while more current analysis is being rate as acute care hospitals. One major HHS could adopt to deliver financial finalized, we note that 2012 data from contributing factor to this difference in support for technology adoption and use the Post-Acute Care Reform adoption rates can be attributed to the in these settings. Demonstration (PAC PRD) found, ‘‘67 fact that PAC providers were not eligible percent of those discharged to SNFs for the Medicare and Medicaid EHR We also recognize that an ongoing continued on to additional services. Incentive Programs (now known as the challenge to advancing and Almost a quarter of them were Promoting Interoperability Programs), incentivizing interoperability is the lack readmitted to the acute hospital (23.1 which slowed adoption of EHRs and of agreed-upon measure concepts with percent). Another third (32.7 percent) other forms of interoperable health IT which to gauge how well providers are were discharged from the SNF to a for these providers. routinely and effectively engaging in HHA. National data on EHR adoption and exchange of information across settings. In patients with the Acute-SNF-HHA interoperability by these providers is To date, the measurement of pattern, almost 20 percent (19.9 percent) limited. For PAC facilities that do interoperability has largely focused on returned to the acute care hospital possess EHRs, vendor adoption of the use of certified technology and the within 30 days of discharge from the interoperable functionality has been percentage of information exchanged. HHA. Hospital patients discharged to slow and uneven. A national survey of Expanding the scope of interoperability LTCHs and IRFs were also likely to use SNFs found that 64 percent of facilities measurement beyond settings that were multiple types of PAC services and a used an EHR in 2016, 29 percent of eligible for the EHR Incentive Programs substantial share of these cases were SNFs could send or receive health is critical as efforts are being made to readmitted within 30 days of discharge, information, but only 7 percent could enable health IT and exchange ranging from 15.9 percent (LTCH-to-IRF send, find, receive, and integrate such capabilities across a broader range of cases) to 42.8 percent (LTCH to SNF information.51 According to the 2015 cases).’’ 50 In examining the home health National Electronic Health Records care settings. In light of the interest by patterns, it is important to keep in mind Survey (NEHRS), 61.3 percent of the stakeholder community to enable that a significant number of the home psychiatrists were using an EHR, of interoperability across all providers, health population does not come which 40.8 percent were certified HHS is seeking public comment on through an acute admission or as part of systems.52 A CDC survey found that 26 measure concepts that assess a post-acute trajectory of care but percent of residential care communities interoperability, including measure instead are directly admitted to the used EHRs in 2016.53 concepts that address PAC, behavioral health, home and community-based HHA from the community. The B. Solicitation of Comments percentages of PAC use and patterns of services, and other provider settings. multiple transitions reinforce the need We are soliciting comment on several A National Quality Forum report on for safeguards around transitions of potential strategies for advancing Quality in Home and Community-Based care. These findings also speak to the interoperability across care settings to Services to Support Community Living: importance of the interoperable inform future rulemaking activity in this Addressing Gaps in Performance exchange of information necessary to area. Measurement suggested that new types As discussed above, health IT ensure continuity of care, and mitigate of measure concepts that assess quality the risks of unintended events, such as adoption has lagged in care settings that were not part of the EHR Incentive across the continuum of care are those associated with medication errors, needed. Specifically, NQF cited the that can result from inadequate and 51 Alvarado C, Zook K, Henry J. Electronic Health domain of ‘‘service delivery and untimely exchange of information. Record Adoption and Interoperability among U.S. effectiveness,’’ which encompasses the Poor patient outcomes, resulting from Skilled Nursing Facilities in 2016, Washington, DC, level to which individuals who use poor communication and lack of Office of the National Coordinator for Health Home and Community Based Services Information Technology, U.S. Department of Health information, have been found to (HCBS) receive services and supports contribute to hospital readmissions, and Human Services, September 2017. Accessed at https://www.healthit.gov/sites/default/files/ sufficient to meet their needs, as well as emergency department (ED) visits, and electronic-health-record-adoption-and- the domain of ‘‘person-centered interoperability-among-u.s.-skilled-nursing- planning and coordination,’’ which 49 Ongoing work under contract: facilities-in-2016.pdf. HHSP23320095651WC with RTI International. 52 Yang N, Hing E. Table of Electronic Health includes a focus on the level to which 50 Gage BJ, Morley MA, Smith LM, Ingber MJ, Record Adoption and Use among Office-based services and supports across the health Deutsch A, Kline TL, Dever JA, Abbate JH, Miller Physicians in the U.S., by Specialty: 2015 National and social service systems are RD, Lyda-McDonald B, Kelleher CA, Garfinkel DB, Electronic Health Records Survey. 2017. Accessed coordinated for individuals who receive Manning JR, Murtaugh CM, Stineman MG, at https://www.cdc.gov/nchs/data/ahcd/nehrs/ Mallinson T. (March, 2012). Post-Acute Care 2015_nehrs_ehr_by_specialty.pdf. HCBS. We seek comment on needed Payment Reform Demonstration: Final Report 53 QuickStats: Percentage of Residential Care measure development work and quality Volume 2. Prepared for the Centers for Medicare Communities That Use Electronic Health Records, improvement efforts focused on and Medicaid Services. Available at https:// by Community Bed Size—United States, 2016. assuring individuals receive sufficient www.cms.gov/Research-Statistics-Data-and- MMWR Morb Mortal Wkly Rep 2018;67:138. DOI: Systems/Statistics-Trends-and-Reports/Reports/ https://www.cdc.gov/mmwr/volumes/67/wr/ needed services across the care Downloads/PAC-PRD_FinalRpt_Vol2of4.pdf. mm6704a8.htm?s_cid=mm6704a8_w. continuum and that their services are

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00232 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7655

coordinated.54 We are also interested in significant improvement in the ability of XII. Advancing Interoperability in comments on the applicability and these settings to potentially share Innovative Models feasibility of measure concepts for PAC, structured electronic data with other A. Promoting Interoperability behavioral health, home and providers across the care continuum. community-based services as identified CMS plans to utilize Center for To enable the bidirectional exchange in previous ASPE reports 55 56 and the Medicare and Medicaid Innovation of this health information, we are report, A Measurement Framework to (‘‘Innovation Center’’) authority under Assess Nationwide Progress Related to seeking public comment on whether section 1115A of the Act to test ways to Interoperable Health Information hospitals and physicians should adopt promote interoperability across the Exchange to Support the National the capability to collect and health care spectrum. Section 1115A of Quality Strategy, published by the electronically exchange a subset of the the Act authorizes the Innovation Center National Quality Forum.57 same PAC standardized patient to test innovative payment and service As part of its work under the IMPACT assessment data elements (for example, delivery models expected to reduce Act, which requires, in part, that certain functional status, pressure ulcers/ program expenditures, while preserving patient assessment data be standardized injuries) in their EHRs. As these health or enhancing the quality of care and interoperable to allow for exchange care providers have generally been furnished to Medicare and Medicaid of the data among PAC providers and eligible for the EHR Incentive Programs beneficiaries and CHIP enrollees. other providers, CMS has defined (now known as Promoting Interoperability and health data sharing certain standardized patient assessment Interoperability Programs), many of are critical to the success of new data elements 58 and their associated them would have adopted certified EHR payment and service delivery models health IT vocabularies across PAC technology and health IT systems, that incentivize high quality, efficient care. settings. Implementation of these which are required to capture and Innovation Center models can include standardized data elements is designed exchange certain data elements under to support more seamless and effective multiple types of health care providers the ONC Health IT certification and other entities such as physician assessment of quality across PAC program. The set of data which systems settings, while also presenting a group practices, hospitals, PAC must include under the certification facilities, community-based program is set to expand in coming 54 Quality in Home and Community-Based organizations providing community- Services to Support Community Living: https:// years under the USCDI Version 1 ONC based long-term care services and www.qualityforum.org/Publications/2016/09/ has proposed for HHS adoption at 45 supports or non-medical services, and Quality_in_Home_and_Community-Based_ CFR 170.213, which would establish a dialysis centers. These types of health Services_to_Support_Community_Living__ Addressing_Gaps_in_Performance_ minimum set of data classes that would care providers furnish care to patients in Measurement.aspx. be required to be interoperable different care settings, have different 55 Measurement of Interoperable Electronic nationwide (see the ONC proposed rule health IT systems, and have varied Health Care Records Utilization Final Report: published elsewhere in this issue of the levels of experience with, and access to, https://aspe.hhs.gov/system/files/pdf/255526/EHR EHR technology. The historically UtilizationReport.pdf. Federal Register). The USCDI is 56 Analyzing the Public Benefit Attributable to designed to be expanded in an iterative disparate and inadequate use of health Interoperable Health Information Exchange: https:// and predictable way over time. IT among these providers and other aspe.hhs.gov/system/files/pdf/258851/Analyzing entities has posed challenges to thePublicBenefitAttributabletoInteroperable We are seeking comment on whether interoperability. Additionally, many of Health.pdf. to move toward the adoption of PAC these types of health care providers are 57 A Measurement Framework to Assess standardized data elements through the Nationwide Progress Related to Interoperable not eligible for the Promoting Health Information Exchange to Support the expansion of the USCDI process. We are Interoperability Programs (previously National Quality Strategy: https:// interested in whether the standardized known as the Medicare and Medicaid www.qualityforum.org/Projects/i-m/ patient assessment data elements that _ _ EHR Incentive Programs) and the Interoperability 2016-2017/Final Report.aspx. are implemented in CMS PAC associated financial incentives for EHR 58 For more information on the Data Element Library see https://del.cms.gov/DELWeb/pubHome, assessment instruments in satisfaction adoption and meaningful use. as well as the Data Element Library Training and of the IMPACT Act would be We believe Innovation Center models FAQ at https://del.cms.gov/DELWeb/pubTrainFAQ. appropriate. If the full set of such (https://innovation.cms.gov/) provide an CMS also provides information and training on the important lever to advance progress various assessment instruments through which standardized patient assessment data post-acute care providers must submit data. elements is not appropriate, we are toward interoperability. These models Training on the OASIS instrument can be found on seeking comment on whether a subset of offer unique opportunities to engage the HH QRP website at https://www.cms.gov/ these standardized items would be with health care providers and other Medicare/Quality-Initiatives-Patient-Assessment- appropriate, and input on which data entities in innovative ways and to test Instruments/HomeHealthQualityInits/Home- concepts that have the ability to Health-Quality-Reporting-Training.html; elements should be prioritized as part of information related to the training on the IRF PAI a subset. We are also seeking accelerate change in the U.S. health care is available on the IRF QRP website at https:// system, including to promote information on what implementation www.cms.gov/Medicare/Quality-Initiatives-Patient- interoperability. One example of CMS’s Assessment-Instruments/IRF-Quality-Reporting/ timeline would be most appropriate for IRF-Quality-Reporting-Training.html; information use of Innovation Center Models to requiring adoption of these data promote interoperability is found in the related to the training on the LTCH CARE Data Set elements in provider and hospital is available on the LTCH QRP website at https:// Innovation Center’s State Innovation www.cms.gov/Medicare/Quality-Initiatives-Patient- systems under the ONC Health IT Models (SIM) initiative (https:// Assessment-Instruments/LTCH-Quality-Reporting/ Certification Program. We are also innovation.cms.gov/initiatives/state- LTCH-Quality-Reporting-Training.html; and seeking comment on the administrative, information related to the training on the MDS is innovations/), under which several available on the SNF QRP website at https:// development, and implementation awards to states are focused on health www.cms.gov/Medicare/Quality-Initiatives-Patient- burden that may be associated with information exchanges and health IT Assessment-Instruments/NursingHomeQualityInits/ adopting these data elements. Skilled-Nursing-Facility-Quality-Reporting- investment. Another example of this Program/SNF-Quality-Reporting-Program- work is found in the Comprehensive Training.html. Primary Care Plus (CPC+) model

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00233 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7656 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

(https://innovation.cms.gov/initiatives/ 2. Promote Trusted Health Information considerable feedback that the lack of a comprehensive-primary-care-plus), in Exchange UPI inhibits interoperability efforts which primary care practices use health Innovation Center model participants because, without a unique identifier for IT to strengthen their ability to deliver may, where appropriate, be required to each patient, the safe and secure care, with some practices partnering participate in a trusted exchange electronic exchange of health with health IT vendors to implement network that meets the following information is constrained as it is advanced health IT functionality in criteria: difficult to ensure that the relevant their practices, including functionality • The trusted exchange network must records are all for the same patient. that promotes interoperability and be able to exchange PHI in compliance HIPAA required the adoption of a sharing of electronic health information. with all applicable state and federal ‘‘unique individual identifier for laws across jurisdictions. healthcare purposes,’’ commonly B. Examples of Interoperability-Related • The trusted exchange network must referred to as a UPI. At the time HIPAA Areas of Focus for New Model connect both inpatient EHRs and was enacted, HHS began to consider Development ambulatory EHRs. what information would be needed to • The trusted exchange network must develop a rule to adopt a UPI standard. Examples of how we may focus on An initial Notice of Intent to issue a interoperability related-issues in future support secure messaging or electronic querying by and between patients, proposed rule on requirements for a model development may include: unique health identifier for individuals Models that incorporate piloting providers and payers. Additionally, model participants may was published in the November 2, 1998 emerging standards; models leveraging Federal Register (63 FR 61773 through non-traditional data in model design be required to participate in electronic alerting via one of the standards 61774). (for example, data from schools, data described in the ISA, II–A: Admission, Appreciating the significant privacy regarding housing and data on food Discharge, and Transfer published and and security concerns raised by insecurity); and models leveraging stakeholders regarding implementing a updated by ONC. technology-enabled patient engagement UPI, Congress included language in the platforms. The Innovation Center has 3. Adopt Leading Health IT Standards Omnibus Consolidated and Emergency incorporated non-clinical data in prior and Pilot Emerging Standards Supplemental Appropriations Act of models, but anticipates addressing Emerging health data standards 1999 (Pub. L. 105–277, enacted October additional uses and types of non- present new opportunities to exchange 21, 1998) and in each subsequent clinical data in future models. more types of health care data between Appropriations bill, stating none of the We are now requesting public health care providers. Innovation Center funds made available in this Act may be comment on the following general model participants, along with their used to promulgate or adopt any final principles around interoperability health IT vendors, may pilot new FHIR standard under section 1173(b) of the within Innovation Center models for standards and advance adoption of new Act (42 U.S.C. 1320d–2(b)) providing for, or providing for the assignment of, integration into new models, through data classes in USCDI (for example, a unique health identifier for an provisions in model participation psychosocial data) to improve individual (except in an individual’s agreements or other governing interoperability for care management, capacity as an employer or a health care documents. In applying these general quality reporting or other priority use provider), until legislation is enacted principles, we intend to be sensitive to cases. As part of the design and testing specifically approving the standard. of innovative payment and service the details of individual model design, This language has effectively prohibited delivery models, the Innovation Center and the characteristics and capacities of HHS from engaging in rulemaking to anticipates taking on a leadership role the participants in each specific model. adopt a UPI standard. Consequently, the in developing new or less mature FHIR Secretary withdrew the Notice of Intent C. Establishing Principles for Promoting and supporting more innovative to pursue rulemaking on this issue on Interoperability in Innovative Model interventions undertaken by states, August 9, 2000 (https:// Tests whenever possible. www.reginfo.gov/public/do/eAgenda 1. Provide Patients Access to Their Own D. Request for Stakeholder Input ViewRule?pubId=200010&RIN=0938- Electronic Health Information The Innovation Center seeks public AI91). Although the appropriations language comment on the principles for The MyHealthEData and Medicare regarding the UPI standard has promoting interoperability in innovative Blue Button 2.0 initiatives aim to remained unchanged, in the report payment and service delivery models empower patients by ensuring that they accompanying the 2017 appropriations described above. Additionally, the have access to their health care data and bill, Congress additionally stated, Innovation Center is requesting public can decide how their data is going to be although the Committee continues to comment on other ways in which the used, all while keeping their data safe carry a prohibition against HHS using and secure. Certain Innovation Center Innovation Center may further promote funds to promulgate or adopt any final models already require that participants interoperability among model standard providing for the assignment of with direct patient interactions provide participants and other health care a unique health identifier for an their patients with electronic access to providers as part of the design and individual until such activity is their health information within 24 hours testing of innovative payment and authorized, the Committee notes that of any encounter. New Innovation service delivery models. this limitation does not prohibit HHS Center models may also require that XIII. Request for Information on from examining the issues around providers and other health care entities Policies To Improve Patient Matching patient matching. Accordingly, the with direct patient interactions provide Committee encouraged the Secretary, patients access to their own electronic A. Background acting through ONC and CMS, to health information and, upon the Through stakeholder feedback such as provide technical assistance to private- patient’s authorization, to third party roundtables, stakeholder meetings, and sector led initiatives to develop a developers via APIs. rulemaking, we have received coordinated national strategy that will

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00234 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7657

promote patient safety by accurately ‘‘core functionality’’ of patient the Act, and other Medicare health identifying patients to their health identification and necessary to ensure plans use the Medicare ID in their plan information. (H.R. Rep. No. 114–699, p. care coordination and the best patient administration. 110, https://www.gpo.gov/fdsys/pkg/ outcomes. Commenters also noted that a • That State Medicaid and CHIP CRPT-114hrpt699/pdf/CRPT- consistently used matching strategy agencies in their FFS or managed care 114hrpt699.pdf). Congress has repeated could accomplish the original goals of a programs use the Medicare ID for dual this guidance for 2018 and 2019. This UPI with a diminished risk to eligible individuals when feasible. guidance directed HHS to focus on individual privacy and health • That QHP issuers in FFEs use the examining issues around patient information security. We solicit Medicare ID for their enrollees in the matching and to provide technical comment on how and in what way administration of their plans. assistance to private sector-led patient matching does or does not 4. Should CMS advance more initiatives focusing on a patient present the same security and privacy standardized data elements across all matching solution. risks as a UPI. appropriate programs for matching In conjunction with ONC, we are We understand the significant health purposes, perhaps leveraging the USCDI posing a request for information information privacy and security proposed by ONC for HHS adoption at regarding how CMS could leverage our concerns raised around the 45 CFR 170.213. program authority to improve patient development of a UPI standard and the 5. Should CMS complement CMS data identification to facilitate improved current prohibition against using HHS and plan data in Medicaid managed care patient safety, enable better care funds to adopt a UPI standard. plans (MCOs, PIHPs, and PAHPs), CHIP coordination, and advance Recognizing Congress’ statement managed care entities, MA Plans, and interoperability. Inaccurate patient regarding patient matching and QHP issuers in an FFE (not including matching can lead to adverse events, stakeholder comments stating that a SADP issuers) with one or more compromised safety and privacy, patient matching solution would verifying data sources for identity inappropriate and unnecessary care, accomplish the goals of a UPI, we seek proofing? What potential data source increased health care costs, and poor comment on ways for us to continue to should be considered? What are oversight of fraud and abuse. We facilitate private sector work on a possible restrictions or limitations to consider this a quality of care and workable and scalable patient matching accessing such information? patient safety issue and seek stakeholder strategy so that the lack of a specific UPI 6. Should CMS support connecting input on ways we can incent does not impede the free flow of EHRs to other complementary verifying improvements. information for future consideration. data sources for identity proofing? What In section 4007 of the 21st Century We are also seeking comment on how potential data source should be Cures Act, the Government we may leverage our program authority considered? What are possible Accountability Office (GAO) was to provide support to those working to restrictions or limitations to accessing directed to conduct a study to determine improve patient matching. We such information? whether ONC and other stakeholders specifically seek input on the following 7. To what extent should patient- could improve patient matching through questions and the potential authority for generated data complement the patient- various mechanisms, to survey ongoing the requirement: matching efforts? efforts related to the policies and 1. Should CMS require Medicare FFS, activities and the effectiveness of such MA Plans, Medicaid FFS, Medicaid XIV. Collection of Information efforts occurring in the private sector, managed care plans (MCOs, PIHPs, and Requirements and to evaluate current methods used in PAHPs), CHIP FFS, CHIP managed care Under the Paperwork Reduction Act certified EHRs for patient matching. The entities, and QHP issuers in FFEs (not of 1995, we are required to provide 60- GAO was also tasked with submitting to including SADP issuers), use a patient day notice in the Federal Register and Congress a report concerning the matching algorithm with a proven solicit public comment before a findings of the study. This report was success rate of a certain percentage collection of information requirement is released in January 2019.59 where the algorithm and real world submitted to the Office of Management In section I of this proposed rule, we processes associated with the algorithm and Budget (OMB) for review and discuss further how patient used are validated by HHS or a 3rd approval. In order to fairly evaluate identification and matching pose party? whether an information collection challenges to interoperability. We look 2. Should CMS require Medicare FFS, should be approved by OMB, section forward to working with ONC as we the MA Plans, Medicaid FFS, Medicaid 3506(c)(2)(A) of the Paperwork review the responses to this RFI in managed care plans, CHIP FFS, CHIP Reduction Act of 1995 requires that we concert with the GAO report to help managed care entities, and QHP issuers solicit comment on the following issues: inform potential appropriate methods to in FFEs to use a particular patient • The need for the information scale best practices and leverage matching software solution with a collection and its usefulness in carrying program authority to improve patient proven success rate of a certain out the proper functions of our agency. matching. percentage validated by HHS or a 3rd • The accuracy of our estimate of the party? information collection burden. B. Solicitation of Comments 3. Should CMS expand the recent • The quality, utility, and clarity of We are soliciting comment on Medicare ID card efforts by requiring a the information to be collected. potential strategies to address patient CMS-wide identifier which is used for • Recommendations to minimize the matching. Many stakeholders all beneficiaries and enrollees in health information collection burden on the commenting on the interoperability RFIs care programs under CMS affected public, including automated included in the various 2019 proposed administration and authority, collection techniques. payment rules, including the FY 2019 specifically by requiring any or all of the We are soliciting public comment on IPPS proposed rule (83 FR 20550), following: each of these issues for the following indicated that patient matching is a • That MA organizations, Part D sections of this document that contain prescription drug plan sponsors, entities information collection requirements 59 https://www.gao.gov/assets/700/696426.pdf. offering cost plans under section 1876 of (ICRs):

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00235 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7658 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

A. Background SADPs at 45 CFR 156.221. These openly support moving our healthcare system published APIs will permit third-party away from a FFS payment system that Health plans should have the ability applications to retrieve standardized pays for volume and toward a payment to exchange data instantly with other data for adjudicated claims, encounters system that pays for value and quality payers for care and payment with capitated and subcapitated by reducing duplication of services; coordination or transitions, and with providers, provider remittances, adding efficiency to provider visits; and, providers to facilitate more efficient beneficiary cost-sharing, reports of lab facilitating identification of fraud, care. Health plans are in a unique test results (depending on whether the waste, and abuse. position to provide enrollees a complete plan manages such data), provider picture of their claims and encounter directories, and, as applicable, preferred B. Wage Estimates data, allowing patients to piece together drug lists. We believe that these their own information that might proposals are designed to empower To derive average costs, we used data otherwise be lost in disparate systems. patients by making sure that they can from the U.S. Bureau of Labor Statistics’ To advance our commitment to access their healthcare data, through the May 2017 National Occupational interoperability, we are proposing new use of common technologies, without Employment and Wage Estimates for requirements to implement APIs for MA special effort and in an easily usable Direct Health and Medical Insurance organizations at 42 CFR 422.119, digital format. We also expect our API Carriers (NAICS 524114) (https:// Medicaid FFS at 42 CFR 431.60, CHIP proposals to enable the enrollees in the www.bls.gov/oes/current/naics5_ FFS at 42 CFR 457.730, Medicaid plans that are subject to our proposal to 524114.htm). Table 1 presents the mean managed care at 42 CFR 438.242, CHIP share their healthcare data. By making hourly wage, the cost of fringe benefits managed care at 42 CFR 457.1233(d), claims data readily available and (calculated at 100 percent of salary), and and QHP issuers in FFEs, excluding portable to the patient, these initiatives the adjusted hourly wage.

TABLE 1—OCCUPATION TITLES AND WAGE RATES

Mean hourly Fringe Adjusted Occupation title Occupation wage benefit hourly wage code (/hr) (/hr) (/hr)

Administrators and Network Architects ...... 15–1140 $46.35 $46.35 $92.70 Security Engineer ...... 17–2199 50.66 50.66 101.32 Computer and Information Analysts ...... 15–1120 41.98 41.98 83.96 General Operations Mgr ...... 11–1021 72.51 72.51 145.02 Operations Research Analysts ...... 15–2031 37.33 37.33 74.66 Software Developers, Applications ...... 15–1132 45.57 45.57 91.14 Computer and Information Systems Managers ...... 11–3021 71.10 71.10 142.20 General and Operations Mgr ...... 11–1021 72.51 72.51 145.02 Designers ...... 27–1020 29.32 29.32 58.64 Technical Writer ...... 27–3042 32.68 32.68 65.36 Computer Systems Analysts ...... 15–1121 41.59 41.59 83.18 Network and Computer Systems Administrators ...... 15–1142 43.64 43.64 87.28

As indicated, we are adjusting our Phasedown file.’’ Section 423.910(d) hours) to complete the systems updates employee hourly wage estimates by a requires states to submit at least one necessary to process and submit the factor of 100 percent. This is necessarily MMA file each month. However, states MMA data daily. As only 13 states a rough adjustment, both because fringe have the option to submit multiple currently submit MMA data daily, we benefits and overhead costs vary MMA files throughout the month (up to estimate a one-time burden for 37 states significantly from employer to one per day). Most states submit at least and the District of Columbia complying employer, and because methods of weekly. This information collection with submission of daily MMA data at estimating these costs vary widely from activity is currently approved under 3,034,406 (38 states (and DC) × 960 study to study. Nonetheless, there is no OMB control number 0938–0958. hours × 83.18 per hour for a computer practical alternative and we believe that Ensuring information on dual system analyst). We will be revising the doubling the hourly wage to estimate eligibility status is accurate and up-to- information collection request currently total cost is a reasonable accurate date by increasing the frequency of approved under 0938–0958 to include estimation method. federal-state data exchange is an the requirements discussed in this C. Information Collection Requirements important step toward interoperability. section. (ICRs) As a result, we are proposing to update 2. ICRs Regarding API Proposals (42 the frequency requirements in 42 CFR 1. ICRs Regarding MMA File CFR 422.119, 431.60, and 438.242, and 423.910(d) to require that starting April 45 CFR 156.221) Requirements (42 CFR 423.910) 1, 2022, all states submit the required States submit data on files at least MMA file data to CMS daily, and to To promote our commitment to monthly to CMS to identify all dually make conforming edits to 42 CFR interoperability, we are proposing new eligible individuals, including full- 423.910(b)(1). Daily would mean every requirements for APIs for MA benefit and partial-benefit dually business day, but that if no new organizations at 42 CFR 422.119, eligible beneficiaries (that is, those who transactions are available to transmit, Medicaid FFS at 42 CFR 431.60, CHIP get Medicaid help with Medicare data would not need to be submitted on FFS at 42 CFR 457.730, Medicaid premiums, and often for cost-sharing). a given business day. We estimate it managed care at 42 CFR 438.242, CHIP The file is called the MMA file, but is would take a computer systems analyst managed care at 42 CFR 457.1233(d), occasionally referred to as the ‘‘State about 6 months (approximately 960 and QHP issuers in FFEs at 45 CFR

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00236 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7659

156.221. These openly published APIs capability and security testing; and implementation and 275,432,820 across will permit third-party applications to vetting third-party applications. all organizations or states to complete retrieve standardized data for After the completion of the API the task described above. development, we believe that plans and adjudicated claims, encounters with Once the API is established, we capitated and subcapitated providers, states would need to conduct the believe that there would be an annual provider remittances, beneficiary cost- following on an annual basis: Allocate cost for performing necessary capability sharing, reports of lab test results, resources to maintain the FHIR server, provider directories, and preferred drug and perform capability and security and security testing, performing lists. To implement the new testing. necessary upgrades and vetting of third- requirements for APIs, we estimate that The burden estimate related to the party applications. We presume that it plans and states will conduct three new requirements for APIs reflects the would take administrators and network major work phases: Initial design; time and effort needed to collect the architects 180 hours (at 92.70 an hour), development and testing; and long-term information described above and network and computer systems support and maintenance. disclose this information. We estimate administrators 420 hours (at 87.28 an In the initial design phase, we believe an initial set one-time costs associated hour), security engineers 240 hours (at tasks would include: Determining with the implementing the API 101.32 an hour), computer and available resources (personnel, requirements. We presume that it will information analysts 60 hours (at 83.96 hardware, cloud space, etc.); assessing take administrators and network an hour), operations research analysts whether to use in-house resources to architects 1440 hours (at 92.70 an hour), 120 hours (at 74.66 an hour), software facilitate an API connection or contract security engineers 960 hours (at 101.32 developers 240 hours (at 91.14 an hour), the work to a third party; convening a an hour), computer and information computer and information systems team to scope, build, test, and maintain analysts 480 hours (at 83.96 an hour), managers 90 hours (at 142.20 an hour), operations research analysts 960 hours the API; performing a data availability general and operations managers 90 scan to determine any gaps between (at 74.66 an hour), software developers hours (at 145.02 an hour), designers 120 internal data models and the data 960 hours (at 91.14 an hour), computer hours (at 58.64 an hour), technical required for the necessary FHIR and information systems managers 720 resources; and, mitigating any gaps hours (at 142.20 an hour), general and writers 30 hours (at 65.36 an hour), and discovered in the available data. operations managers 720 hours (at computer systems analysts 120 hours (at During the development and testing 145.02 an hour), designers 960 hours (at 83.96 an hour). We estimate the total phase, we believe plans and states 58.64 an hour), technical writers 240 annual burden to be 1,710 hours (180hrs would need to conduct the following: hours (at 65.36 an hour), and computer + 420hrs + 60hrs + 120hrs + 240hrs + Map existing data to FHIR, which would systems analysts 960 hours (at 83.18 an 90hrs + 120hrs + 30hrs + 120hrs) per constitute the bulk of the work required hour). We estimate a one-time burden organization or state, and 589,950 hours for implementation; allocate hardware assessment of 8,400 (1440hrs + 960hrs (1,710hrs × 345 organizations) across all for the necessary environments + 480hrs + 960hrs + 960hrs + 720hrs + organizations and states. Thus, the total (development, testing, production); 720hrs + 960hrs + 240hrs + 960hrs) annual cost to maintain the API build a new FHIR server or leverage hours per organization or state and a requirements is 158,359.80 per existing FHIR servers; determine the total of 3,898,000 (8,400hrs × 345 organization or state and 54,634,131 frequency and method by which organizations) hours across all across all organizations and states. internal data is populated on the FHIR organizations or states. The one-time server; build connections between the cost to implement API requirements is 3. Summary of Information Collection databases and FHIR server; perform 789,356.00 per organization or state per Burdens TABLE 2—SUMMARY OF INFORMATION COLLECTION BURDENS

Hourly Total Number Number Burden Total an- labor Total labor capital/ Regulation Section(s) OMB Control of of per nual cost of cost of mainte- Total cost Number respond- re- response burden reporting reporting nance ($) ents sponses (hours) (hours) ($) ($) costs ($)

§ 423.910 ...... 0938–0958 * .. 38 38 20 960 83.18 3,034,406 0 3,034,406 § 422.119, § 431.60, § 457.730, § 438.242, 0938–New .... 345 345 840 2,889,600 ...... 275,432,820 0 275,432,820 § 457.1233 and § 156.221. § 422.119, § 431.60, § 457.730, § 438.242, 0938–New .... 345 345 1,710 588,240 ...... 54,634,131 0 54,634,131 § 457.1233, and § 156.221.

Total ...... 344 344 2,570 3,478,800 ...... 333,101,357 ...... 333,101,357 * This currently approved ICR will be revised to include the burden discussed in this rule.

If you comment on these information D. Exempt ICRs financial resources necessary to comply collections, that is, reporting, with these requirements would be 1. Usual and Customary Business incurred by persons during the normal recordkeeping or third-party disclosure Practices requirements, please submit your course of their activities, and therefore, comments electronically as specified in While the requirements under 42 CFR should be considered usual and the ADDRESSES section of this proposed 482.24(d), 482.61(f) and 485.638 are customary business practices. rule. subject to the PRA, we believe the We are proposing to further expand Comments must be received on/by burden associated with those CMS requirements for interoperability May 3, 2019. requirements is exempt from the PRA in within the hospital, psychiatric accordance with 5 CFR 1320.3(b)(2). We hospital, and CAH CoPs by focusing on believe that the time, effort, and electronic patient event notifications.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00237 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7660 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

For hospitals, psychiatric hospitals, and We note that hospitals have an data through pdf and text format also CAHs, we are proposing similar existing responsibility under the CoPs at limits the utility and sharing of the data. requirements to revise the CoPs for 42 CFR 482.43(d) to transfer or refer Moving to a system in which patients Medicare- and Medicaid-participating patients, along with necessary medical have access of their health care data will hospitals, psychiatric hospitals, and information, to appropriate facilities, help empower them to make informed CAHs by adding a new standard, agencies, or outpatient services, as decisions about their health care, as ‘‘Electronic Notifications,’’ that would needed, for follow-up or ancillary care. well as share their data with providers require hospitals, psychiatric hospitals, We wish to emphasize that the proposal who can assist these patients with their and CAHs to send electronic patient in this proposed rule around patient health care. Our proposals here are event notifications of a patient’s event notifications is independent of the designed to move the Medicare, MA, admission, discharge, and/or transfer to requirement regarding necessary Medicaid, CHIP and QHP programs another health care facility or to another medical information at 42 CFR further to that ultimate goal of community provider. We propose to 482.43(d). As these processes are empowering their enrollees. As limit this requirement to only those already required, and as many EHR technology has advanced, we have hospitals, psychiatric hospitals, and systems already have an electronic encouraged states, health plans, and CAHs which currently possess EHR notification system in place, we do not providers to adopt various forms of systems with the technical capacity to anticipate a significant increase in technology to improve the accurate and generate information for electronic burden on hospitals, psychiatric timely exchange of standardized health patient event notifications, recognizing hospitals, and CAHs with the adoption care information; these proposals would that not all Medicare- and Medicaid- of this proposal. However, we recognize enable beneficiaries and enrollees to be participating hospitals and psychiatric that processes to implement this active partners in the exchange of hospitals have been eligible for past proposal, if finalized, might intersect electronic health care data by easily programs promoting adoption of EHR with the hospital’s discharge planning monitoring or sharing their data. systems. We intend for these process. We note that nothing in this States and CMS routinely exchange notifications to be required, at proposal would affect the hospital’s data on who is enrolled in Medicare, minimum, for inpatients admitted to, responsibilities under 42 CFR 482.43(d). and which parties are liable for paying and discharged and/or transferred from However, if this proposal is finalized, that beneficiary’s Parts A and B the hospital, psychiatric hospital, or hospitals might wish to consider ways premiums. These ‘‘buy-in’’ data CAH. These requirements would help to fulfill these requirements in ways that exchanges support state, CMS, and SSA support coordination of a patient’s care reduce redundancy while still fully premium accounting, collections, and between settings or with services meeting the provisions of each. For enrollment functions. We have become received through different care settings. instance, where appropriate, hospitals increasingly concerned about the These sections would require updates to might seek to include required limitations of monthly buy-in data discharge planning processes, which necessary medical information within exchanges with states. The relatively has been a long-standing industry the same message as a patient event long lag in updating buy-in data means practice. Electronic patient event notification. that the state is not able to terminate or notifications from these care settings, or activate buy-in coverage sooner, so the XV. Response to Comments clinical event notifications, are one type state or beneficiary may be paying of health information exchange Because of the large number of public premiums for longer than appropriate. We note that once the data catch up, intervention that has been increasingly comments we normally receive on states and CMS reconcile the premiums recognized as an effective and scalable Federal Register documents, we are not by recouping and re-billing, so tool for improving care coordination able to acknowledge or respond to them premiums collected are ultimately across settings. These notifications are individually. We will consider all accurate, but only with—an typically automated, electronic comments we receive by the date and administratively burdensome process communications from the admitting or time specified in the DATES section of involving debits and payments between discharging provider to a receiving this preamble, and, when we proceed the beneficiary, state, CMS, SSA, and facility or to another community with a subsequent document, we will potentially providers. Daily buy-in data provider that alert the receiving respond to the comments in the preamble to that document. exchange would reduce this provider that a patient is receiving, or administrative burden. As described in has received, care at a different setting. XVI. Regulatory Impact Analysis detail in section VII. of this proposed These notifications are based on A. Statement of Need rule, the changes to 42 CFR parts 406, ‘‘admission, discharge, and transfer’’ 407, and 423 establish frequency (ADT) messages, a standard message As described in detail in section III. requirements that necessitate all states used within an EHR as the vehicle for of this proposed rule, the changes to 42 to participate in daily exchange of buy- communicating information about key CFR parts 422, 431, 438, 457 and 45 in data, and updates frequency changes in a patient’s status as they are CFR part 156 are part of the agency’s requirements to require all states to tracked by the system (more information broader efforts to empower patients by participate in daily exchange of MMA about the current standard supporting ensuring that they have full access to file data, with CMS by April 1, 2022. these messages is available at http:// their own health care data, through States submit data on files at least www.hl7.org/implement/standards/ common technologies and without monthly to CMS to identify all dually product_brief.cfm?product_id=144). As special effort, while keeping that eligible individuals, including full- noted in the ISA published by ONC, this information safe and secure. benefit and partial-benefit dually messaging standard has been widely Interoperability and the capability for eligible beneficiaries (that is, those who adopted across the health care system health information systems and software get Medicaid help with Medicare (see https://www.healthit.gov/isa/ applications to communicate, exchange, premiums, and often for cost-sharing). sending-a-notification-a-patients- and interpret data in a usable and The MMA file was originally developed admission-discharge-andor-transfer- readable format, such as pdf or text, is to meet the need to timely identify status-other-providers). vital, but allowing access to health care dually eligible beneficiaries for the then-

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00238 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7661

new Medicare Part D prescription drug 1995 (March 22, 1995; Pub. L. 104–4), rights and obligations of recipients benefit. Over time, we used these files’ Executive Order 13132 on Federalism thereof; or (4) raising novel legal or data on dual eligibility status to support (August 4, 1999), the Congressional policy issues arising out of legal Part C capitation risk-adjustment, and Review Act (5 U.S.C. 804(2)), and mandates, the President’s priorities, or most recently, feeding dual eligibility Executive Order 13771 on Reducing the principles set forth in the Executive status to Part A and B eligibility and Regulation and Controlling Regulatory Order. claims processing systems so providers, Costs (January 30, 2017). A regulatory impact analysis (RIA) suppliers, and beneficiaries have Executive Orders 12866 and 13563 must be prepared for major rules with accurate information on beneficiary direct agencies to assess all costs and economically significant effects ($100 cost-sharing obligations. As CMS now benefits of available regulatory million or more in any 1 year). We utilizes MMA data on dual eligibility alternatives and, if regulation is estimate that this rulemaking is status in systems supporting all four necessary, to select regulatory ‘‘economically significant’’ as measured parts of the Medicare program, it is approaches that maximize net benefits by the $100 million threshold, and becoming even more essential that dual (including potential economic, hence also a major rule under the eligibility status is accurate and up-to- environmental, public health and safety Congressional Review Act. Accordingly, date. Dual eligibility status can change effects, distributive impacts, and we have prepared an RIA that to the best at any time in a month. Waiting up to equity). Section 3(f) of Executive Order of our ability presents the costs and a month for status updates can 12866 defines a ‘‘significant regulatory benefits of the rulemaking. Table 3 negatively impact access to the correct action’’ as an action that is likely to summarizes the estimated costs level of benefit at the correct level of result in a rule: (1) Having an annual presented in the Collection of payment. effect on the economy of $100 million Information section of this proposed or more in any 1 year, or adversely and rule. We note that estimates below do B. Overall Impact materially affecting a sector of the not account for enrollment growth or We have examined the impacts of this economy, productivity, competition, higher costs associated with medical proposed rule as required by Executive jobs, the environment, public health or care. This is because the cost of Order 12866 on Regulatory Planning safety, or state, local or tribal requirements to implement patient and Review (September 30, 1993), governments or communities (also access through APIs and for states to Executive Order 13563 on Improving referred to as ‘‘economically comply with data exchange Regulation and Regulatory Review significant’’); (2) creating a serious requirements are not impacted by (January 18, 2011), the Regulatory inconsistency or otherwise interfering enrollment growth or higher costs Flexibility Act (RFA) (September 19, with an action taken or planned by associated with medical care. Per OMB 1980, Pub. L. 96–354), section 1102(b) of another agency; (3) materially altering guidelines, the projected estimates for the Social Security Act, section 202 of the budgetary impacts of entitlement future years do not take into account the Unfunded Mandates Reform Act of grants, user fees, or loan programs or the ordinary inflation.

TABLE 3—ESTIMATED AGGREGATE COSTS TO THE HEALTH CARE SECTOR BY PROVISION [CYs 2020 through 2024]

Calendar year ($ in millions) Total CY Provision Regulation sec- 2020–2024 tion(s) 2020 2021 2022 2023 2024 ($ in millions) *

Requirements to Pa- § 422.119, 275.4 54.7 54.7 54.7 54.7 494.0 tient Access § 431.60, Through APIs. § 438.242, § 457.730, § 457.1233, § 156.221. Dual Eligible Care § 406.26, 0.7 2.2 2.2 1.2 0 6.3 Coordination. § 407.40, § 423.910.

Total Cost ...... 276.1 56.9 56.9 55.9 54.7 500.3 * Total may not equal sum of parts due to rounding.

Allocation of Cost Impact by Program: immediately estimate Parent observe that the costs of this proposed As stated in the Collection of Organization expenditures on how rule are negligible relative to the costs Information Section of this proposed much of the cost is born by each of the various programs it impacts. rule, cost estimates have been program. For purposes of clarification we use aggregated at the parent organization Preliminary Estimates: Later in this the metric of ‘‘costs per enrollee.’’ The level because we believe that an RIA section, we provide several detailed ‘‘costs per enrollee’’ whether for organization that offers commercial, estimates of cost by program where we Medicaid or Medicare, does not refer to Medicare, Medicaid, and CHIP products account for Federal matching for actual costs paid by the enrollee but Medicaid and payments by the Trust rather is a metric, it is the quotient of would create one system that would be Fund for Medicare Advantage total program expenditures divided by used by all ‘‘plans’’ it offers. We note Organizations. However, these estimates total enrollees. The cost per enrollee that due to the implementation of APIs are approximate as explained in detail metric facilitates comparison of costs. across multiple business lines, there is below. Therefore, the purpose of this Since program expenditures for both no straightforward method to preliminary estimate section, is to Medicaid and MA are typically

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00239 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7662 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

hundreds of millions (or billions) of for these plans on the commercial MLR omit State Agencies, we believe that the dollars, concepts like negligibility do reporting form. 70 percent Medicaid enrollees enrolled not have intuitive meaning. Thus, these MLR data sets omit in Medicaid Managed Care provides a Contrastively, the costs per enrollee are organizations that only have Medicare good approximation. more manageable and understandable. or Medicaid. The data from the CMS Finally, as noted in the section The 2018 Medicare Trust Fund 60 states MLR files also omits: (1) The CHIP ‘‘Preliminary Estimates’’, independent that costs per enrollee are projected to program; and (2) Medicaid State of these omissions, the average cost per be roughly $12,000–$14,000 for contract Agencies. We now discuss these enrollee is capped at $1.63 and $0.34 in years 2020–2023 (Table IV.C3). The omissions to assess the accuracy of first and follow up years. costs per enrollee for the Medicaid using these MLR files. Best Estimates of Impact per Program: program are similarly several thousand CHIP: 85 percent of the 194 CHIP We present two methods to obtain an managed care plans also offer Medicaid dollars. We estimate 169 million estimate of cost by program both for and hence are covered by the parent enrollees will be affected by these purposes of assessing impact on small entity. We believe it reasonable that the provisions since. Currently there are 76, entities, as well as for purposes of remaining CHIP plans also have 61 62 2 assessing impacts of the provision on 66, 20, and 7 million enrollees in commercial offerings since it would be the Federal government, programs, and the commercial, Medicaid, MA and inefficient to operate a CHIP-only plan enrollees: We could assume costs separate CHIP programs respectively. as the total national CHIP enrollment is proportional to current enrollment, or The total first year (implementation) currently only about 7 million. alternatively, we could assume costs cost per enrollee is $1.63 ($276.1 Similarly, except for one state, CHIP proportional to total premium. For million cost (Table 3) divided by 169 programs are run through the state purposes of analyzing impact on small million enrollees); maintenance cost per Medicaid agency; again, there would be entities and impacts of the provision on one interoperability cost for the one enrollee in the following years are 34 the Federal Government, programs, and state agency since the resulting software cents ($56.9 million total cost (Table 3) enrollees we are using the method of would be used both by Medicaid and divided by 169 million enrollees). The assuming costs proportional to total assertion that $1.63 and $0.34 is CHIP. Thus, while we are leaving out CHIP programs in this analysis since premium (the method of assuming costs negligible compared to the $12,000– proportional to current enrollment will $14,000 cost per enrollee for the MA they are not in the CMS MLR files, we do not believe this materially alters the be used below to assess impact on program or the several thousand-dollar transfers to enrollees). cost per enrollee for the Medicaid overall picture. Medicare Advantage: We compared Among issuers with products in both program has intuitive appeal. However, Commercial and MA or Commercial and these are very rough preliminary the CMS MLR files with the CMS Trustee Report.65 According to the Medicaid, the 2016 CMS MLR files estimates. In the remainder of this RIA, show $370 billion reported in premium we provide, subject to the limitations Trustee Report (Table IV.C2), total MA revenue for 2016 was $189.1 billion. for commercial plans, $157 billion noted, more detailed impact by reported for MA, and $113 billion program. Thus, the reported amount in the CMS MLR files of $157 billion for MA reported for Medicaid. Consequently, Data Sources for Cost by Program: To represents 83 percent (157/189.1) of all the proportion of interoperability cost obtain allocation of cost by program we MA activity reflected in the Trustee for each of the programs is 57.81 percent used the CMS public use files for MLR Report. Therefore, we believe the (370/(370+157+113)), 24.53 percent data, for 2016.63 64 The MLR data sets proportions obtained from these MLR (157/(370+157+113)), and 17.66 percent are for private insurance plans but the files are accurate. (113/(370+157+113)) for Commercial, issuers of that private (commercial) Medicaid: For the year for which MA, and Medicaid respectively. insurance in many cases also have these MLR files provide data, 2016, Using these proportions, Table 4 contracts to provide MA, Medicaid and about 70 percent of Medicaid enrollees breaks out the top row in Table 3, the CHIP managed care plans and report were enrolled in Medicaid Managed total cost by year of implementing and revenue, expense, and enrollment data Care.66 Thus although the MLR files maintaining the API, by program.

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

Year 2020 2021 2022 2023 2024 Total

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

60 https://www.cms.gov/Research-Statistics-Data- 63 https://www.cms.gov/CCIIO/Resources/Data- 76 million commercial enrollees from the 2016 data and-Systems/Statistics-Trends-and-Reports/ Resources/mlr.html. decreased to 73.5 million in 2017. Using these ReportsTrustFunds/Downloads/TR2018.pdf. 64 Although the 2017 MLR data recently became alternate proportions and numbers would not 61 https://www.medicaid.gov/medicaid/program- available, using them would not change the bottom change significantly our dollar-per-enrollee information/medicaid-and-chip-enrollment-data/ line of the analysis. The 2016 data gives $113 estimates of impacts. report-highlights/index.html. billion, $157 billion and $370 billion enrollees for 65 https://www.cms.gov/Research-Statistics-Data- 62 https://www.cms.gov/Research-Statistics-Data- commercial, MA, and Medicaid plans respectively and-Systems/Statistics-Trends-and-Reports/Reports and-Systems/Statistics-Trends-and-Reports/ resulting in revenue proportions of 57.81 percent, MCRAdvPartDEnrolData/Monthly-Contract-and- 24.53 percent, 17.68 percent. The 2017 data gives TrustFunds/Downloads/TR2018.pdf Table IV.C2. Enrollment-Summary-Report-Items/Contract- $119.5, $170.3 and $381.5 billion for commercial 66 https://www.cms.gov/newsroom/press-releases/ Summary-2018-08.html?DLPage=1&DLEntries=10& MA, and Medicaid plans resulting in proportions of cms-proposes-changes-streamline-and-strengthen- DLSort=1&DLSortDir=descending. 56.8 percent, 25.36 percent, and 17.79 percent. The medicaid-and-chip-managed-care-regulations.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00240 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7663

Methods of Bearing Cost by Program: increased costs back to the Trust Fund. State’s medical assistance match rate. Commercial plans have the options to For those (most) MAOs whose bid For purposes of these estimates we use deal with increased costs by either amount is below the benchmark, the the weighted FMAP, 58.44. temporarily absorbing them (for Trust Fund provides total expenditures CHIP: Most states operate Medicaid purposes of market competitiveness), to the MAOs consisting of: (1) Full and CHIP from the same state agency. increasing premiums to enrollees, or payment of the bid amount; and (2) the One state is a notable exception in that reducing benefits. rebate, a portion of the difference To the extent that issuers increase between the benchmark and the bid it has a separate Medicaid and CHIP premiums for plans in the FFE, there amount. Since MAOs are increasing agency. The federal government pays an would be Federal premium tax credit their bid amounts to reflect the costs of enhanced federal medical assistance (PTC) impacts. However, the PTC this proposed rule, it follows that the percentage (EFMAP) to states for all formula is highly individual-specific, rebate, equaling the difference between costs associated with CHIP, including that is, it is the result of the relationship the benchmark and bid, is decreased, systems costs (this is unlike Medicaid between the premium of the second resulting in less rebates paid to the where there are different FMAPs for lowest-cost silver plan applicable to a MAOs. Based on our historical and different types of costs). For federal FY specific consumer in a specific month, projected experience, the rebate is 2019 the EFMAPs will range from 88 to the cost of the actual plan purchased by estimated as 34 percent of the difference 100 percent. For federal FY 2020 the that consumer for that month, and that between benchmark and bid. Thus, EFMAPs will range from approximately consumer’s income. Consequently, it although the Trust Fund pays the bid in 76.5 to 93 percent. After federal FY would not be possible to estimate the full, nevertheless, 66 percent of the 2020, the EFMAPs will range from magnitude of the PTC impact with a increased bid costs arising from this approximately 65 to 81.5 percent. Since reliable degree of accuracy, since we proposed rule, are reduced from the the CHIP program Federal rebate ranges cannot predict: (1) What proportion of rebates. The MAO in its submitted bid, include the 90 percent and 75 percent costs would be passed on to enrollees as can address this reduction of rebates by federal matching proportions of the increased premiums; (2) to what extent either: (1) Temporarily, for marketing Medicaid program, we are applying the commercial issuers may recoup purposes, absorbing the loss, and 90 percent and 75 percent from investment costs through raising reducing its profit margin; (2) reduce the premiums on the second-lowest cost additional benefits it provides the Medicaid to the CHIP programs. Since silver plans or on other plans; and (3) enrollee paid for by the rebate; or (3) the CHIP program is small relative to the whether or in what ways such premium raise enrollee premiums. Medicaid program, we believe this increases may impact the PTC Medicaid: State Medicaid agencies approach reasonable. calculation or eligibility with respect to may be allowed to allocate the costs of Table 5 uses these proportions to various consumers, state information retrieval systems estimate the impact of the API on the To deal with this uncertainty, we list between the costs attributable to design, Federal Government. For example, the the possible Federal PTC impacts as a development, installation, or $28.4 million cost to the Federal qualitative impact. Most importantly, enhancement of the system—at a 90 government for Medicaid/CHIP for we assume the unlikely worst case percent federal match—and for ongoing 2020, the implementation year of the scenario that all cost is passed on as operations of the system—at a 75 API, is obtained by multiplying the premium to the enrollee without percent federal match. State Agency Medical Assistance subsidization; we then show that the net For Medicaid Managed Care entities, average match rate to Medicaid impact per enrollee per month is we assume an MCO, PIHP, and PAHP extremely small (see Table 7). cost for implementing the open API Managed Care Plans, 58.44%, by the Medicare Advantage: Medicare provisions would be built into the $48.6 million total cost to Medicaid for Advantage Organizations (MAOs) pass capitation rates and matched at the 2020 listed in Table 4.

TABLE 5—COSTS (IN MILLIONS) INCURRED BY FEDERAL GOVERNMENT BY PROGRAM AND YEAR

Year 2020 2021 2022 2023 2024 Total

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

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

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00241 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7664 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

rounding). The results are summarized in Table 6.

TABLE 6—REMAINING COSTS (IN MILLIONS) FOR API BY YEAR AND PROGRAM

2020 2021 2022 2023 2024 Total

Commercial ...... 159.6 32.9 32.9 32.3 31.6 289.2 Medicaid/Chip ...... 20.3 4.4 4.4 4.2 4.0 37.4 Medicare Advantage ...... 44.8 9.4 9.4 9.1 8.8 81.5

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

TABLE 7—COST PER ENROLLEE PER YEAR (DOLLARS AND CENTS) BY PROGRAM

Current enroll- ment (millions) 2020 2021 2022 2023 2024 Total by program

Commercial ...... 76 2.10 0.43 0.43 0.42 0.42 3.81 Medicaid/Chip ...... 73 0.28 0.06 0.06 0.06 0.05 0.51 Medicare Advantage .... 20 2.24 0.47 0.47 0.46 0.44 4.08

Using Table 7 we can assess the enrollee will be absorbed by each QHP being included in the bid) by either: (1) approximate impact of the remaining in an FFE. Temporarily absorbing costs by cost. Medicaid: Medicaid state agencies are reducing profit margins; (2) reducing adding a cost under 30 cents per Commercial: As pointed out above, additional benefits paid for by the enrollee for 2020–2024. Since total costs the Commercial program has the options rebates; or (3) raising enrollee cost per enrollee for the Medicaid program sharing (however, many plans for of absorbing costs or passing costs to are several thousand dollars we do not enrollees either in the form of premiums competitive reasons would choose to believe this additional 30 cents per remain zero premium and either absorb or reduced benefits. The cost per enrollee cost to be a significant burden. enrollee in 2021 through 2024 is under Medicare Advantage: Medicare losses for one year or reduce additional, a half dollar and could comfortably be Advantage plans in their June-submitted rebate-funded benefits in the amount passed on to enrollees. For purposes of bids would address the reduced rebates per enrollee shown in Table 7). market competitiveness, it is very likely (arising from increased bid costs due to Table 8 summarizes these methods of that some of the 2020 cost of $2.10 per the increased costs of this proposed rule bearing the remaining costs.

TABLE 8—HOW PROGRAMS WOULD DEFRAY REMAINING COSTS

Commercial ...... Commercial plans have the options of absorbing costs (for example, in 2020 for reasons of market com- petitiveness), increasing premiums to enrollees, or reducing benefits. Medicaid/CHIP ...... Medicaid Managed Care plan would bear the cost (under a dime per enrollee) which is negligible com- pared to current costs per enrollee. Medicare Advantage (MA) ...... MA plans in their June-submitted bids would address the reduced rebates (arising from increased bid costs due to the increased costs of this proposed rule being included in the bid) by either: (1) Temporarily ab- sorbing costs by reducing profit margins; (2) reducing additional benefits paid for by the rebates; or (3) raising enrollee cost sharing (however, many plans for competitive reasons would chose to remain zero premium and either absorb losses for one year or reduce additional, rebate-funded benefits in the amount per enrollee shown in Table 8).

67 https://www.medicaid.gov/medicaid/program- 69 To give an idea of how the per enrollee per year Table 7 which are $2.10, 0.28, and $2.24. These information/medicaid-and-chip-enrollment-data/ numbers would change had we used updated changes per enrollee per year would not affect any report-highlights/index.html. enrollment, we note that the latest MA enrollment of our conclusions about negligibility relative to the 68 https://www.cms.gov/Research-Statistics-Data- (as of January 2019) is for January 2019 and is 22 4 and 5 digit per enrollee per year expenses for and-Systems/Statistics-Trends-and-Reports/MCR million, the latest Medicaid enrollment is for Oct Medicare, Medicaid and the Federally Funded AdvPartDEnrolData/Monthly-Contract-and- 2018 and is still 73 million, and the latest exchange. Enrollment-Summary-Report-Items/Contract- commercial enrollment is for 2017 and is 73.5. The Summary-2018-08.html?DLPage=1&DLEntries=10& resulting per-enrollee-per-year cost impacts would DLSort=1&DLSortDir=descending. be $2.17, 0.28, and $2.04 versus the numbers in

VerDate Sep<11>2014 20:39 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00242 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7665

C. Anticipated Effects between the basic benefit bid compared raising of enrollee premiums as The RFA, as amended, requires to an administratively-set benchmark for ‘‘passing the costs to the enrollee’’ the agencies to analyze options for the MA plan’s service area (currently, intent being that the ‘‘effect’’ of reduced regulatory relief of small businesses, if based on our past and projected rebates is less additional benefits or a rule has a significant impact on a experience, rebates are approximately higher enrollee premiums than would substantial number of small entities. For 66 percent). Benchmarks are based on a have happened had the cost of the purposes of the RFA, small entities formula using an estimate of the provisions of this proposed rule not include small businesses, nonprofit Medicare FFE per capita cost for the been included in the bid. organizations, and small governmental geographic area, which are adjusted to There are various types of Medicare jurisdictions. reflect the per capita cost of each county health plans, including MA HMOs, POS This proposed rule affects (1) in the United States and its territories. plans, and PPOs; Demonstration plans; Commercial Issuers (2) MA plans, Payments from the Medicare Trust Cost Plans; Prescription Drug Plans including those that are also Part D Funds for monthly capitation are (PDP); and Programs of All-Inclusive sponsors of MA–PD plans, as well as (3) capped at the benchmark; for basic Care for the Elderly (PACE) Medicaid MCOs with a minimum benefit bids under the benchmark, a organizations. This proposed rule affects portion, currently 66 percent, of the threshold for small business size of MA HMOs, MA POS plans, and MA difference between the bid and $38.5 million (https://www.sba.gov/ PPOs but does not affect Cost Plans, benchmark is made available to the MA federal-contracting/contracting-guide/ Prescription Drug Plans nor PACE organization to either: (1) Pay the size-standards). organizations. Assessment of impact is complicated premium for supplemental benefits; (2) There are a variety of ways to assess include reductions in cost sharing; (3) by the fact that costs have been whether MAOs meet the $38.5 million provide additional non-Medicare aggregated at the Parent Organization threshold for small businesses. The covered benefits; or (4) provide buy- level. A typical Parent Organization assessment can be done by examining downs of Part B or Part D premiums. might have products with the net worth, net income, cash flow from Basic benefit bids that are at or above commercial, MA, or Medicaid/CHIP operations and projected claims as the benchmark receive payment from programs. We have no way of directly indicated in their bids. Using projected the Trust Funds of the benchmark assessing the size of Parent monetary requirements and projected amount, with any excess charged to the Organizations. Therefore, as a proxy, we enrollment for 2018 from submitted enrollee as a premium. bids, 32 percent of the MAOs fell below analyze each program separately. MAOs are made aware of the Medicare Advantage: We first assess the $38.5 million threshold for small benchmark through the annual CMS businesses. Additionally, an analysis of the impact on MA plans. To clarify the publication, ‘‘Medicare Advantage flow of payments between these entities 2016 data, the most recent year for Capitation Rates and Medicare which we have actual data on MAO net and the federal government, we note Advantage and Part D Payment Policies that MAOs submit proposed plan worth, shows that 33 percent of all and Final Call Letter,’’ which, consistent MAOs fall below the minimum designs and estimates of the amount of with section 1853 of the Act, is released revenue necessary to cover the cost of threshold for small businesses. prior to MAO submission of bids. Medicaid: We next assess the impact those plan designs (called bids) by the Therefore, the bids of most MAOs are first Monday in June of the year on Medicaid MCOs. The Society of below the benchmark and consequently Actuaries (SOA) published ‘‘Medicaid preceding the coverage year. most MAOs receive from the Trust Fund Managed Care Organizations: Regulations governing this process are a total expenditure equaling payment in 42 CFR part 422, subpart F. These Considerations in Calculating Margin in for the bid plus the rebate. 70 bids must be broken down in the Because of these proposed API Rate Setting’’ in 2017. The report following: provisions, MAOs would be raising the provided an MS Excel spreadsheet of (1) The revenue requirements for June-submitted bid amount to reflect Medicaid MCOs using data from 2013– providing Medicare Part A and Part B additional costs. While the Trust Fund 2015. That report noted that ‘‘[n]ot every benefits with actuarially equivalent cost pays these bid amounts in full, the state requires Medicaid MCOs to submit sharing (this is the ‘‘basic benefit bid’’); rebate goes down: That is, since the bid Annual Statements, so not every MCO is (2) The revenue requirements for amount goes up, the rebate, equaling the represented. MCOs in California and providing supplemental benefits; and difference between the benchmark and Arizona are shown with a limited set of (3) A Part D bid consistent with Part bid, decreases and results in less rebate metrics, based on what was available D regulations in 42 CFR part 423. payment to the MAO. The MAO has and provided by HMA [Health These bids project payments to several options of dealing with these Management Associates].’’ Of the 231 hospitals, providers and staff, as well as increased bid costs and reduced rebates: MCOs listed in the 2015 worksheet, 196 the cost of administration and profits. The MAO might decide to: (1) provided data that are adequate to Because the API requirements proposed Temporarily absorb the loss by reducing identify MCOs with annual ‘‘revenue’’ in this rule will apply to every MA plan its profit margin (so as to reduce the bid less than $38.5 million. (NOTE: Since and each MA plan must furnish at least amount and thereby increase the total revenue is reported at the company the Medicare Part A and Part B benefits, rebates); (2) reduce additional benefits level, which includes revenue from non- the cost of the API will be built into the paid to the enrollee from the rebates; or Medicaid sources, we used ‘‘direct administrative component of the basic (3) raise enrollee premiums so as to premium written’’ in the Medicaid benefit bid. These bids in turn compensate for the reduction of enrollee portion of the worksheet as a proxy for determine one component of the premium that would have happened if annual revenue on the individual plan payments of the Medicare Trust Fund to the bid had not been increased (note: level.) Of the 196 Medicaid MCOs, only the MAOs who reimburse providers and For marketing purposes, many plans other stakeholders for their services. A operate at zero premium, and we do not 70 Society of Actuaries, Medicaid Managed Care Organizations: Considerations in Calculating second component of the Trust Fund consider this a likely possibility). In this Margin in Rate Setting. Accessed at https:// payment to MAOs are the rebates, RIA we have referred to options (2) and www.soa.org/research-reports/2017/medicaid- which are a portion of the difference (3) reduction of additional benefits and margins/, pg. 49.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00243 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7666 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

15 MCOs or 7.7 percent had ‘‘revenue’’ or Medicaid) the amount would be certain requirements that an agency less than $38.5 million in 2015. greater than $370 billion. Therefore, the must meet when it promulgates a Commercial: Based on the 2016 CMS aggregate raw cost of this proposed rule proposed rule (and subsequent final MLR data, approximately 85 out of 494, over 5 years, $500 million, is rule) that imposes substantial direct or 17 percent of companies (that either significantly below the 3 percent–5 requirement costs on state and local had only commercial business, or had percent threshold for significant impact governments, preempts state law, or commercial plus Medicare and/or to Commercial plans. otherwise has Federalism implications. Medicaid business) had total premium We conclude, that although a This rule will not have a substantial revenue of less than $38,500,000. In significant number of small plans in all direct effect on state or local other words, for MA, Medicaid, and programs are affected by this rule, this governments, preempt state law, or Commercial, a significant number of impact is not significant. otherwise have a Federalism small plans are affected. The RFA Besides the fact that the impact is not implication. Therefore, the requirements requires us to assess whether the rule significant, we are not concerned that of Executive Order 13132 are not has a significant impact on the plans small plans will have a burden in applicable. which we do next. implementing these requirements since If regulations impose administrative If a proposed rule has a substantial as indicated above, without considering costs, such as the time needed to read impact on a substantial number of small any rebates or Federal matching funds, and interpret this proposed rule, we entities, the proposed rule must discuss the cost of this provision is $1.63 per should estimate the cost associated with steps taken, including alternatives, to enrollee per year in the first regulatory review. There are currently minimize burden on small entities. implementation year, and $0.34 in the 288 organizations and 56 states and While a significant number (more than following years for maintenance, these territories. We assume each organization 5 percent) of not-for-profit organizations per enrollee costs are negligible when will have one designated staff member and small businesses are affected by this compared to the typical costs per who will read the entire rule. final rule, the impact is not significant. enrollee (several thousand dollars). Using the wage information from the To assess impact, we use the data in Consequently, the Secretary has BLS for medical and health service Table 3 of this section which shows that determined that this proposed rule will managers (Code 11–9111), we estimate the total raw (not discounted) net effect not have a significant economic impact that the cost of reviewing this rule is of this final rule over 5 years is 500 on a substantial number of small entities $139.14 per hour, including overhead million dollars. and the requirements of the RFA have and fringe benefits (https://www.bls.gov/ Medicare Advantage: We first assess been met. Please see our detailed oes/current/naics5_524114.htm). impact on MA plans. Comparing the 500 analysis of apportionment of costs per Assuming an average reading speed, we million dollar number to the total program and plan in Tables 4 through estimate that it would take monetary amounts projected to be 8 and section XVI.H. of this proposed approximately 6 hours for each person needed just for 2018, the most recent rule for further details. to review this proposed rule. For each year on which we have finalized plan In addition, section 1102(b) of the Act plan and state that reviews the rule, the submitted bid data (and which is requires CMS to prepare an RIA if a rule estimated cost is $834.84 (6 hours × expected to be less than the need in may have a significant impact on the $139.14). Therefore, we estimate that future years including 2019), we find operations of a substantial number of the total cost of reviewing this that that the impact of this proposed small rural hospitals. This analysis must regulation is $288,020 ($834.84 × 345 rule is significantly below the 3 conform to the provisions of section 603 reviewers). percent–5 percent threshold for of the RFA. For purposes of section 1. Requirements for Patient Access significant impact for MA plans. 1102(b) of the Act, we define a small Medicaid: We next assess impact on rural hospital as a hospital that is Through APIs Medicaid Managed Care plans. The total located outside a Metropolitan To promote our commitment to projected capitation payment and Statistical Area and has fewer than 100 interoperability, we are proposing new premiums for 2019 is projected to be beds. We are not preparing an analysis requirements in section III. of this $337.6 billion.71 Hence, the total cost of for section 1102(b) of the Act because proposed rule for MA organizations at this proposed rule over 5 years, $500 we have determined, and the Secretary 42 CFR 422.119, Medicaid FFS at 42 million, is significantly below the 3 certifies, that this proposed rule would CFR 431.60, Medicaid managed care at percent–5 percent threshold for not have a significant impact on the 42 CFR 438.242, CHIP FFS at 42 CFR significant impact to Medicaid Managed operations of a substantial number of 457.730, CHIP managed care at 42 CFR Care plans. small rural hospitals. 457.1233, and QHP issuers, excluding Commercial: As discussed prior to Section 202 of the Unfunded SADP issuers, that offer plans through Table 4, based on data in the public, Mandates Reform Act of 1995 (UMRA) the FFE at 45 CFR 156.221 to implement CMS MLR files, commercial plans had (Pub. L. 104–04, enacted March 22, open APIs for making certain data a revenue of at least $370 billion in 1995) also requires that agencies assess available to enrollees and the public. 2016. We say at least, because this only anticipated costs and benefits before These openly published APIs will includes organizations with either: (1) issuing any rule whose mandates permit third-party applications to Only commercial; (2) both commercial require spending in any 1 year of $100 retrieve standardized data for and MA; or (3) both commercial and million in 1995 dollars, updated adjudicated claims, encounters with Medicaid. Had all organizations been annually for inflation. In 2018, that is capitated and subcapitated providers, included in the CMS MLR files approximately $150 million. The provider remittances, beneficiary cost- (including those that only offer MA and/ apportionment of total cost between the sharing, reports of lab test results, MA, Medicaid, Commercial and Chip provider directories, and preferred drug 71 Table 17 of Appendix D, ‘‘Capitation Payments programs is detailed in both section lists. We believe that these proposals are and Premiums’’, in the CMS report, ‘‘2016 Actuarial XVI.B. (Tables 4 through 8) and section designed to empower patients by Report on the Financial Outlook for Medicaid,’’ accessible at URL https://www.medicaid.gov/ XVI.H of this RIA showing that costs for mandating that entities subject to our medicaid/finance/downloads/medicaid-actuarial- both enrollees and the states are small. API proposal take steps—by report-2016.pdf. Executive Order 13132 establishes implementing the API—to enable

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00244 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7667

enrollees to have access to their data in women in a separate CHIP, all but one over half of the FEHB participating a usable digital format and have of these programs are operated out of plans expected to offer Blue Button (potentially) easier means to share that the same agency. Although the CHIP functionality by January 1, 2016. We data. By making these data readily programs may be distinct, we believe sought to learn whether there was any available and portable to the patient, they will use the same infrastructure overlap between these two lists of these initiatives support moving our built for Medicaid. Thus, the addition of organizations to gauge whether healthcare system away from a FFS 1 parent entity for CHIP is reasonable additional organizations may already payment system that pays for volume and plausible. have the capability to offer either and toward a payment system that pays As noted in section XIII.C.3. of this patient portals or Blue Button, albeit in for value and quality by reducing proposed rule, to implement the new a different business arm, as having duplication of services, adding requirements for APIs, we estimate that internal capability may assuage some of efficiency to provider visits, and organizations and states would conduct the cost of building out a new API to facilitating identification of fraud, three major work phases: Initial design; support patient access to claims data. waste, and abuse. development and testing; and long-term While we found significant overlap To estimate the number of impacted support and maintenance. (For a between UnitedHealthcare and the Blue issuers, we reviewed parent detailed description of these phases, see Cross Blue Shield Affiliates, we also organizations of health plans across MA, section XIII.C.3. of this proposed rule.) were able to identify other organizations As part of our research into the Medicaid MCOs, and QHPs in FFEs to that offer both MA plans and plans regulatory impact, we reviewed a remove organizations that would not be included in the FEHB. While not sample of health plan organizations subject to our proposal, such as SADPs; definitive, this data allows us to draw offering MA plans to determine whether transportation plans and brokers such as the conclusion that a number of health any currently offer patient portal plan organizations have the technology non-emergency medical transportation functionality with the MA plan. If yes, (NEMTs) brokers; PACE; visiting nurse in place to offer patient portals to MA we reviewed whether they offered the enrollees and, further, also have the and home health care organizations; opportunity to connect to Medicare’s senior organizations such as Area ability to offer MA enrollees Blue Blue Button 2.0. Health plan Button functionality. Agencies on Aging; and other organizations offering MA plans were As detailed in the Collection of organizations such as community action identified from June 2018 data and Information section of this proposed programs. After removing these statistics compiled at https:// rule and summarized in Table 3, given organizations, we then reviewed the www.cms.gov/Research-Statistics-Data- the current state of interoperability, we remaining names of parent and-Systems/Statistics-Trends-and- estimate the burden related to the new organizations and health plans in the Reports/MCRAdvPartDEnrolData/ requirements for APIs to have an initial National Association of Insurance index.html. We initially reviewed the set one-time costs of $798,356 per Commissioners (NAIC) Consumer functionality offered by three implementation or an aggregate cost of Information Support (CIS) system to organizations which together enroll over $275,432,820 ($798,356 × 345 parent determine the legal name of the entity half of MA members through review of entities). For a detailed discussion of the and whether the entity was registered publicly-available information such as one-time costs associated with with the NAIC. We also used the 2018 press releases and website informational implementing the API requirements we NAIC Listing of Companies to determine materials. We found from this review refer readers to section XIII.C.3. of this whether various health plans had that these organizations not only offered proposed rule. Once the API is associated parent organizations using patient portals primarily focused on established we believe that there will be the NAIC’s Group coding and claims and user-entered data on their an annual cost for performing necessary numbering system. If the health plan or website, but that all three also offered capability and security testing, parent organization did not appear in enrollees the opportunity to connect to performing necessary upgrades and the NAIC CIS or in the 2018 NAIC Blue Button. We then identified a vetting of third party applications. We Listing of Companies, we then reviewed selection of other health plan estimate the burden related to the the name of the entity in the Securities organizations at random and conducted requirements for APIs to have an annual and Exchange online Edgar system to the same evaluation. Results indicate cost of $158,406 per implementation or locate the entity’s Form 10–K filing, that the majority of the health plan an aggregate cost of $54,650,070 (345 which includes an Exhibit (Exhibit 21) organizations we reviewed offer patients parent entities × $158,406). For a that requires the entity to list its a way to access claims data and other detailed discussion of the annual costs subsidiaries. If the health plan or information via their websites and associated with implementing the API organization did not appear in these sometimes via applications. Regarding requirements, we refer readers to section online systems or listings, an online Blue Button access, results were either XIII.C.3. of this proposed rule. internet search using Google search negative or unclear. We are committed to fulfilling our engine was conducted. After review, we We also cross-referenced health plan role in promoting interoperability, have determined that 288 issuers and 56 organizations offering MA plans with putting patients first and ensuring they states, territories, and U.S. health plan organizations that offer have access to their health care data. We commonwealths, which operate FFS plans in the Federal Employee Health recognize that there are significant programs, will be subject to the API Benefit (FEHB) program because a opportunities to modernize access to provisions for Medicare, Medicaid, and percentage of those organizations offer patient data and its ability to share the Commercial market. To this we add plans with patient portal access and across the health ecosystem. We realize the one state that operates its CHIP and Blue Button functionality. The FEHB, the importance of interoperability and Medicaid separately. Thus, we have a administered by the Office of Personnel the capability for health information total of 345 parent entities (288+56+1). Management (OPM), reported in 2014 systems and software applications to We note that although 42 states have that 90 percent of its participating plans communicate, exchange, and interpret some lower-income children in an offered enrollees access to a personal data in a usable and readable format. expansion of Medicaid, and some health record on the organization’s Although allowing access to healthcare higher-income children or pregnant website. In addition, OPM reported that data through pdf and text format is vital,

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00245 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7668 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

it limits the utility of the data, and its patient access in the U.S. health care involve 960 hours of computer analyst ability to be easily accessed and shared. system and are taking an active time at $83.18 per hour, for a one-time Additionally, we realize that moving to approach using all available policy cost to be a little less than $80,000 per a system in which patients have access levers and authorities available to move state, per change. So, a state that needs to their healthcare data will ultimately all participants in the health care market to make systems updates to both send empower them to make informed toward interoperability and the secure buy-in data daily, and receive buy-in decisions about their healthcare. Our exchange of health care data. The data daily would have a one-time cost proposals here do not go as far as our modern internet app economy thrives of just under $160,000. We did not goals for how patients will be ultimately on an open API software environment. estimate any savings related to empowered but take steps in that Part of the health care API evolution is exchanging buy-in data with greater direction. incorporating many of the current frequency, as data lags only delay when We note that the federal government protocols from leading standards states are billed for premium costs; has spent over $35 billion under the development organizations with the delays do not impact the effective date EHR Incentive Programs 72 to newer Fast Healthcare Interoperability and total costs. While we did not incentivize the adoption of EHR Resources (FHIR) web developer- estimate premium savings (since systems; however, despite the fact that friendly way of representing clinical premium collection is ultimately 78 percent of physicians and 96 percent data. correct), we anticipate that states may 73 experience longer term reduction in of hospitals now use an EHR system, 2. Increasing the Frequency of Federal- administrative burden of making those progress on system-wide data sharing State Data Exchanges for Dually Eligible corrections. has been limited. Previous attempts to Individuals advance interoperability have made States submit data on MMA files at incremental progress but have failed to We routinely exchange data with least monthly to CMS to identify all align the necessary stakeholders to drive states on who is enrolled in Medicare, dually eligible individuals, including momentum in a single direction. and which parties are liable for paying full-benefit and partial-benefit dually Recently, the Administration launched that beneficiary’s Part A and B eligible beneficiaries (that is, those who the MyHealthEData initiative.74 This premiums. These buy-in data exchanges get Medicaid help with Medicare government-wide initiative aims to support state, CMS, and SSA premium premiums, and often cost-sharing). empower patients by ensuring that they accounting, collections, and enrollment While 42 CFR 423.910(d) requires states have full access to their own healthcare functions. CMS subregulatory guidance, to submit at least one MMA file each data and the ability to decide how their specifically Chapter 3 of the State Buy- month, states have the option to submit data will be used, while keeping that in Manual, specifies that states should multiple MMA files throughout the information safe and secure. exchange buy-in data with CMS at least month (up to one per day). As CMS now MyHealthEData aims to break down the monthly, but provides the option for utilizes MMA data on dual eligibility barriers that prevent patients from states to exchange buy-in data with CMS status in systems supporting all four gaining electronic access to their daily or weekly. Likewise, states can parts of the Medicare program, it is healthcare data and allow them to choose to receive the CMS response data becoming even more essential that dual on a file daily or monthly. Currently, 31 access that data from the device or eligibility status is accurate and up-to- states and the District of Columbia now application of their choice that will date. submit buy-in data to CMS, daily and 28 connect to a plan’s API, empowering We are proposing to update the states and the District of Columbia frequency requirements in 42 CFR patients and taking a critical step receive buy-in response files from CMS 423.910(d) to require that starting April toward interoperability and patient data daily. 1, 2022, all states submit the required exchange. We are proposing to establish the Health plans should have the ability MMA file data to CMS daily, and to frequency requirements in the to exchange data instantly with other make conforming edits to 42 CFR regulation itself to require all states to payers for care coordination or 423.910(b)(1). Daily would mean every participate in daily exchange of buy-in transitions, and with providers to business day, but that if no new data to CMS, with ‘‘daily’’ meaning transactions are available to transmit, facilitate more efficient care. Health every business day, but that if no new data would not need to be submitted on plans are in a unique position to transactions are available to transmit, a given business day. We estimate the provide enrollees a complete picture of data would not need to be submitted on cost for states to comply with these new their claims and encounter data, a given business day. We propose that requirements to be a one-time cost allowing patients to piece together their states would be required to begin associated with state systems updates, own information that might otherwise participating in daily exchange of buy- totaling $3,034,406 across impacted be lost in disparate systems. We are in data with CMS by April 1, 2022. states, and across the 3 years which committed to solving the issue of We estimate the cost for states to states have to implement the interoperability and achieving complete comply with these new requirements to requirement. There are 37 states and the be one-time costs associated with state District of Columbia that we anticipate 72 May 2018, EHR Incentive Program, Payment Summary Report, accessed at https://www.cms.gov/ systems updates, totaling $3,273,965 will need to make a systems change to Regulations-and-Guidance/Legislation/ across impacted states and over the 3- send MMA data to CMS daily. We EHRIncentivePrograms/Downloads/May2018_ year implementation period. We first estimate the one-time cost for a state to SummaryReport.pdf. identified those states already be a little less than $80,000 for this 73 ONC, Health IT Dashboard, ‘‘Office-based exchanging data daily, and then MMA data systems change. For a Physician Health IT Adoption: State rates of physician EHR adoption, health information determined there are 19 states that we detailed discussion of the costs exchange & interoperability, and patient anticipate will need to make a systems associated with these requirements we engagement (2015),’’ https:// change to send buy-in data to CMS refer readers to section XIII.C. of this dashboard.healthit.gov/apps/physician-health-it- daily, and 22 states that we anticipate proposed rule. We did not estimate any adoption.php (last accessed July 9, 2018). 74 https://www.cms.gov/Newsroom/ will need to make a systems change to savings related to submitting MMA files MediaReleaseDatabase/Press-releases/2018-Press- receive buy-in data from CMS daily. We daily, as data lags only delay when data releases-items/2018-03-06.html. then estimated that each change would are sent; delays do not impact the

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00246 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7669

effective date and total costs. While we other patient care team members, and notifications. We believe that care did not estimate savings, we anticipate PAC services providers and suppliers coordination can have a significant that states may experience longer term that: (1) Receive the notification for positive impact on the quality of life, reduction in administrative burden. treatment, care coordination, or quality consumer experience, and health If these proposals are finalized as improvement purposes; (2) have an outcomes for patients. However, we proposed, we anticipate that states established care relationship with the acknowledge that though such activities would have approximately 3 years to patient relevant to his or her care; and can have positive impact, they will implement daily exchange of buy-in and (3) for whom the hospital, psychiatric likely generate some costs. We believe it MMA data. For each state there would hospital, or CAH has a reasonable is difficult to quantify the impact of this be a one-time cost to make needed certainty of receipt of notifications. As proposed change because EHR systems changes, and thereafter, no new we noted, infrastructure supporting the implementation across care settings on-going costs. States will have the exchange of electronic health varies in maturity rates, leading to ability to choose, in consultation with information across settings has matured potential variance in cost and impact CMS, when in the 3-year substantially in recent years. Research across such settings. We believe that implementation period they want to studies have increasingly found that this proposal would impose minimal make this change, with numerous health information exchange additional costs on hospitals. The cost factors impacting in which year they interventions can effectuate positive of implementing these proposed would do so. For the purposes of this outcomes in health care quality and changes would largely be limited to the impact analysis, we estimated an even public health outcomes, in addition to one-time cost related initial distribution beginning in May 2019 and more longstanding findings around implementation of the notification ending in April 2022. The total cost reductions in utilization and costs. system, and to the revision of a policies impact over the 3-year implementation Electronic patient event notifications and procedures as they relate to period for this provision is $6,308,371 from hospitals, or clinical event discharge planning. There also may be ($3,273,965 + $3,034,406), comprising notifications, are one type of health some minimal cost associated with $0.7 million in FY 2019, $2.2 million in information exchange intervention that communicating these changes to FY 2020, $2.2 million in FY 2021, and has been increasingly recognized as an affected staff. However, we believe that $1.2 million in FY 2022. Since the effective and scalable tool for improving these costs would be offset by the proposed effective date is April 1, 2022, care coordination across settings, benefits derived from positive outcomes we estimate no costs for FY 2023. especially for patients at discharge. This in health care quality and public health 3. Revisions to the Conditions of approach has been identified with a outcomes. Therefore, while this reduction in readmissions following proposal would impose a minimal Participation for Hospitals and Critical 75 Access Hospitals (CAHs) implementation. burden on hospitals, we believe that, in These notifications are automated, sum, the changes proposed would We are seeking to further expand CMS electronic communications from the greatly benefit patients overall. requirements for interoperability within provider to another facility or another the hospital and CAH CoPs by focusing community provider identified by the 4. Effects of Other Proposed Policy on electronic patient event notifications. patient. These automated Changes We are proposing new requirements in communications alert the receiving In addition to those proposed policy section X. of this proposed rule for provider that the patient has received changes discussed previously that we hospitals at 42 CFR 482.24(d)), for care at a different setting. Information are able to model, we are proposing to psychiatric hospitals at 42 CFR included with these notifications can make various other changes in this 482.61(f), and for CAHs at 42 CFR range from simply conveying the proposed rule. Generally, we have 485.638. Specifically, for hospitals, patient’s name, basic demographic limited or no specific data available psychiatric hospitals and CAHs, we are information, and the sending with which to estimate the impacts of proposing similar requirements to revise institution, to a richer set of clinical these proposed changes. Our estimates the CoPs for Medicare- and Medicaid- data depending upon the level of of the likely impacts associated with participating hospitals, psychiatric technical implementation. However, these other proposed changes are hospitals, and CAHs by adding a new regardless of the information included discussed in this section. standard, ‘‘Electronic Notifications,’’ these alerts can help ensure that a a. Care Coordination Across Payers that would require hospitals, psychiatric receiving provider is aware that the hospitals, and CAHs to make electronic patient has received care elsewhere. The In section V. of this proposed rule, we patient event notifications available to notification triggers a receiving provider are proposing a new requirement for another healthcare facility or to another to reach out to the patient to deliver MA plans, Medicaid managed care community provider. We propose to appropriate follow-up care in a timely plans, CHIP managed care entities, and limit this requirement to only those manner. By providing timely QHP issuers in FFEs to require these hospitals, psychiatric hospitals, and notifications, the alert may improve plans to maintain a process to exchange, CAHs which currently possess EHR post-discharge transitions and reduce at a minimum, the USCDI data set upon systems with the technical capacity to the likelihood of complications an enrollee’s request. Under our generate information for electronic resulting from inadequate follow-up proposal, each of these plans subject to patient event notifications, recognizing care. the requirement would, upon an that not all Medicare- and Medicaid- Virtually all EHR systems generate the enrollee’s request: (1) Accept the data participating hospitals have been basic messages commonly used to set from another plan that had covered eligible for past programs promoting support electronic patient event the enrollee within the previous 5 years; adoption of EHR systems. We propose (2) send the data set at any time during that these notifications would need to 75 Unruh MA, Jung HY, Kaushal R, Vest JR, an enrollee’s enrollment and up to 5 be sent at admission and either Hospitalization event notifications and reductions years later, to another plan that in readmissions of Medicare FFS beneficiaries in immediately prior to or at the time of the Bronx, New York. J AM Med Inform Assoc, currently covers the enrollee; and (3) the patient’s discharge or transfer to 2017 Apr 1, accessed at https:// send the data set at any time during licensed and qualified practitioners, www.ncbi.nlm.nih.gov/pubmed/28395059. enrollment or up to 5 years after

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00247 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7670 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

enrollment has ended to a recipient • The trusted exchange network must additional information beyond that identified by the enrollee. be able to exchange PHI, defined in 45 already accessible through existing APIs Such transactions would be made in CFR 160.103, in compliance with all be provided to patients by providers. compliance with applicable laws. applicable state and federal laws across Ultimately, we opted to continue to We believe that sending and receiving jurisdictions. consider most matters pertaining to this minimum data would help both • The trusted exchange network must providers in separate RFIs, such as that plan enrollees and health care providers connect both inpatient EHRs and in the FY 2019 IPPS proposed rule in coordinating care and reducing ambulatory EHRs. seeking information about program administrative burden. We believe that • The trusted exchange network must participation conditions and this entails utilizing all tools available support secure messaging or electronic requirements, and to maintain the to us to ensure that plans provide querying by and between patients, policies proposed in this rule as policies coordinated high-quality care in an providers and payers. that will further enhance and secure the efficient and cost-effective way that We believe that this proposal would foundation of future interoperability, protects program integrity. impose minimal additional costs on including through inclusion of payers, We believe that this proposal would plans. through care coordination, and through matters of security and identity impose minimal additional costs on D. Alternatives Considered plans. We note that we do not specify confirmation. a transport standard in the proposal and This proposed rule contains a range of As we recognize that advancing anticipate that plans may opt to use proposed and potential future policies. interoperability is no small or simple APIs, such as the API that this proposed It provides descriptions of the statutory matter, we continue to explore rule would also require. We also provisions that are addressed, identifies alternatives and potential other policies. anticipate that plans may choose to the proposed policies, and presents We have requested comment for utilize a regional health information rationales for our decisions and, where consideration in future rulemaking or exchange. We believe it is difficult to relevant, alternatives that were subregulatory guidance on a number of quantify the impact of this proposed considered. We carefully considered the alternatives related to whether change because plans will likely alternatives to this proposed rule but additional policies or requirements, implement different transport methods, concluded that none would adequately beyond those proposed herein, should and we cannot predict the selected and immediately begin to address the be imposed to promote interoperability. method plans will choose. critical issue of the lack of patient For example, the Innovation Center is access and interoperability, or exchange seeking comment on general principles b. Care Coordination Through Trusted of health care data within the health around promoting interoperability Exchange Networks care system. within Innovation Center models for In section VI. of this proposed rule, The critical policy decision was how integration into new models as part of we are proposing to require MA plans, broadly or narrowly to classify the the design and testing of innovative Medicaid managed care plans, CHIP standards required to implement payment and service delivery models. managed care entities and QHP issuers interoperability. Overly prescriptive Additionally, we are seeking comment in FFEs to participate in trust networks standards may stifle innovation and, in on how we may leverage our program in order to improve interoperability in turn, increase costs. On the other side, authority to provide support to those these programs. We believe that payers broad language surrounding standards working on improving patient matching. and patients’ ability to communicate risked leaving too much open to For example, we are requesting between themselves and with health interpretation and continuing the comment on whether CMS should care providers could considerably uncertainty about which standards require, in Medicare FFS, the MA improve patient access to data, reduce would be the most practical and cost- program, Medicaid FFS, CHIP FFS, provider burden, and reduce redundant effective to implement. We determined Medicaid managed care programs, CHIP and unnecessary procedures. A trusted it was most appropriate to propose a managed care entities, and the FFEs, use exchange framework allows for the technical and standards framework that of a particular patient matching software secure exchange of electronic health strikes a balance between these two solution with a proven success rate of a information with, and use of electronic ends of the spectrum, and to establish certain percentage validated by HHS or health information from, other health IT that we expect the standards framework a 3rd party. We also continue to without special effort on the part of the to expand and mature as consider feedback received from RFIs user. Widespread payer participation in interoperability increases. issued in various rules over the course such a framework might also allow for A second decision was how broadly of the past year and to incorporate those more complete access, exchange, and or narrowly to apply the proposed suggestions into our strategy. use of all electronically accessible policies and requirements. For example, E. Accounting Statement and Table health information for authorized use alternatives to requiring health plans to under applicable state or federal law. provide claims data to patients via an In accordance with OMB Circular A– Under our proposal, participation open API could have been altered in a 4, Table 9 depicts an accounting would be required in a trusted exchange number of ways, such as requiring more statement summarizing the assessment framework that meets the following or less information to be provided to of the benefits, costs, and transfers criteria: patients or, simultaneously, to require associated with this regulatory action.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00248 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7671

TABLE 9—ACCOUNTING STATEMENT

Units Primary Category estimate Discount rate Period Year dollars (%) covered

Benefits:

Qualitative ...... • API requirements will alleviative the burden for beneficiaries and enrollees to go through separate processes to obtain access to each system, and the need to manually aggregate information that is delivered in various, often non-standardized, formats. • API requirement allows for the administration of a more efficient and effective Medicaid program by taking advantage of commonly used methods of information sharing and data standardization. • API requirements would help to create a healthcare information ecosystem that allows and encourages the healthcare market to tailor products and services to compete for patients, thereby increasing quality, decreasing costs, and helping them live better, healthier lives.

Costs:

Annualized Monetized $ millions/year ...... 106.26 2020 7 2020–2024 102.73 2020 3 2020–2024

The preceding discussion was an under one-dollar impact. However, we is no requirement to provide them actual cost impact (not a transfer) since have no way, at this point, of estimating interoperability. Therefore, we believe goods and computer services are being this aspect of the future savings of the we are obligated in this RIA to calculate paid for. Plans have the option of rule. the cost impact per enrollee should the transferring their expenses to enrollees. We present two estimates. First, we Parent Organizations offer In practice, because of market estimate using the enrollment figures interoperability (and should they pass competitive forces a plan may decide to used in Table 7 of this RIA. Table 7 on the cost of interoperability in terms operate at a (partial) loss and not shows that we have 169 million of commercial premium). The rest of the transfer the entire cost. It is important (76+73+20) in programs that will be discussion below explores this to estimate the maximum the transfer spending about $110 million per year. possibility.76 could be. Some costs are transferred to Ignoring Federal subsidies, and Commercial: Rebates are required the States (for Medicaid and CHIP) and assuming that all costs will be passed on under section 2718(b)(1)(A) of the PHSA ultimately to the federal government (for to enrollees (which is contrary to our and the implementing regulations at 45 Medicare, Medicaid, and CHIP), experience), the 169 million enrollees CFR part 158 when an issuer does not mitigating the amount transferred to would each incur an extra 65 cents meet the applicable threshold. The enrollees. One approach to estimate (110/169) a year to achieve the $110 impact on enrollees was made in section million goal. We next estimate using 76 Note that our analysis in Tables 5,6,7,8 also premium versus enrollment as was done assume that costs are incurred by commercial XVI.B. of this RIA. However, this enrollees even though there is no requirement to analysis did not take into account in section XVI.B. of this RIA. provide them with interoperability. We believe this transfers. Prior to discussing potential transfers the most likely scenario. However, if we are We now re-estimate the potential full to enrollees, we discuss how this restrictive in our impact analysis and only assume proposed rule may affect commercial MA, Medicaid, CHIP and FFE enrollees are bearing transfer. As noted in section Tables 4 the cost the results of Tables 5–8 would not change through 8 of XVI.B. of this RIA, we have enrollees not in the MA, Medicaid, the negligibility conclusion as the following in 2021 through 2024 under a dollar CHIP, or FFE programs. Technically, justifications show: We have assumed 20 million, increase in premium as the worst case plans are only required to provide 73 million and 76 million enrollees in the MA, interoperability for enrollees in the MA, Medicaid and Commercial programs (Table 7). The scenario, and we used actual costs per 20 million and 73 million remain accurate. The 76 year. In this alternate analysis we use Medicaid, CHIP, and FFE programs. million (commercial enrollees) must be replaced by actual amounts for each of 2021 through However, it is both possible and likely, FFE enrollees. For this purpose we use QHP data. 2024 with the initial 1-year cost that a Parent Organization providing Based on internal data (some of which has not yet been published), for 2017 there were 9,757,747 amortized over 5 years. In other words, interoperability for its FFE and other enrollees with $55,109,210,072 total premium we assume a cost of $110 (275.4/5 + program enrollees as required, may resulting in a $5600 per enrollee per year cost, and 54.7) choose to offer this to commercial for 2018, there were 9,925,382 enrollees with We point out that this premium enrollees. Consequently, it is possible $70,738,585,845 total premium resulting in a $7100 per enrollee per year cost. To illustrate how this increase should be counterbalanced by that to cover the cost of offering changes the Table 7 impact, the $2.10 per enrollee projected savings arising from the interoperability to commercial enrollees per year cost for 2020 commercial must be replaced provisions in this proposed rule. More outside the MA, Medicaid, CHIP and by $15.96 to account for a division by 10 million specifically, we expect the availability FFE programs, the Parent Organizations, versus 76 million. Although this is a big increase, $15.96 is still only about one third a percent of the of portable electronic transfer of medical raise premiums to both their per-enrollee-per-year costs of the FFE. Thus the cost data proposed by this rule to increase commercial enrollees as well as the MA, is still negligible. Furthermore, a Parent prevention of future medical illnesses Medicaid, CHIP or FFE enrollees. Thus Organization actuary reviewing these numbers due to better data accessibility. The it is possible (and we argue likely) that would probably seriously recommend that all enrollees including commercial be offered the savings from avoiding one illness or one this proposed rule will affect interoperability since that significantly reduces the cheaper procedure would offset the commercial enrollees even though there per enrollee per year cost.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00249 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7672 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

commercial market MLR is generally between $0 and the interoperability whose MLR was below the applicable calculated as the percent of each dollar cost; and (2) for issuers at or above the threshold and the $350.6 billion of of after-tax premium revenue spent by MLR standards, the premium transfers premium revenues ($370 billion total the issuer on medical products and from enrollees to issuers will go up by revenue¥$19.4 billion) of issuers whose services, and activities that improve the some amount between $0 and the MLR was at or above the applicable quality of health care. If the issuer MLR interoperability cost. threshold. We can now calculate the for a state market is below the To estimate these amounts, we used estimated aggregate transfer in the applicable threshold, then the issuer the public use 2016 MLR files on the commercial market from the must return the difference to CMS website that were used for Tables policyholders to the issuers whether policyholders. It follows, that if 4 through 7 of this RIA. The total 2016 through premium or rebates as follows: interoperability costs raise plan costs, premium revenue on the commercial • Interoperability cost = 0.017 percent and if additionally, the issuers pass on side was approximately $370 billion. Of of revenue premium ($64 million cost/ the full cost in the form of premium the $370 billion, the total 2016 premium $370 billion total revenue). and/or are able to treat these costs as revenue of issuers that were below the • Reduced MLR rebates = $3.3 QIAs, then premiums and rebates will commercial MLR standard (80 or 85 million (0.017 percent × $19.4 billion change. The following two highly percent, depending on the market) was premium from issuers below the simplified examples are illustrative. approximately $19.4 billion and that applicable MLR threshold). Suppose the MLR threshold is 85 subset of issuers paid a total of $455 • Increased premiums = Up to $60.0 percent (in practice it can vary by state million in rebates. million (0.017 percent × ($370 billion market), but the issuer’s MLR is below As mentioned earlier, to proceed total revenue¥$19.4 billion premium the threshold at 75 percent. Then the further we use the estimates of the from issuers below the applicable MLR issuer would have to return the 10 interoperability costs which are $110 threshold)). percent as a rebate. If the million per year. This cost is for all • Total transfer from enrollees = Up interoperability costs for an issuer are parent organizations with each parent to $63.3 million ($60.0 million on average 6 percent of premium and organization possibly dealing with up to increased premium + $3.3 million the issuer treats these expenses as QIA, four lines of business subject to MLR reduced rebate). the issuer will now have to rebate only requirements: MA (including Part D • Transfer per enrollee = 83 cents 4 percent instead of 10 percent (that is, sponsors); Medicaid; CHIP; and ($63.3 million/76 million commercial the issuer’s MLR would be 81 percent Commercial. Thus, of the $110 million enrollee). rather than 75 percent). Similarly, if level annual cost of interoperability, we We note that the 83 cents (under a both the applicable threshold and issuer estimate $64 million (57.81 percent dollar per enrollee) is consistent with MLR are 85 percent, then the issuer commercial proportion x $110 million the results obtained in Tables 4 through would not owe a rebate. level annual interoperability cost) to be 8 (with exact raw amounts by year There are two effects of recognizing the cost for the commercial market. without amortization of a large first year these costs as QIA: (1) For issuers below In estimating the transfers to expense). These calculations are the applicable MLR threshold, the policyholders in the commercial market, summarized in Table 10. rebate from issuers to policyholders we must distinguish between the $19.4 These calculations are summarized in would go down by some amount billion of premium revenues of issuers Table 10.

TABLE 10—TRANSFERS TO ENROLLEE RESULTING FROM THE PROPOSED RULE

Level Annual Cost of Interoperability

(A) ...... First year cost of interoperability ...... 275.4 Estimated in this proposed In millions. rule. (B) ...... First year cost amortized over 5 years ...... 55.08 (A)/5 ...... In millions. (C) ...... Continuation year cost of interoperability ...... 54.7 Estimated in this proposed In millions. rule. (D) ...... Level interoperability cost per year ...... 109.78 (B) + (C) ...... In millions.

Commercial Percent of Premium Revenues

(E) ...... Total premium revenues in commercial, Med- 640 Sum of (F) (G) and (H) Below In billions. icaid and Medicare. (F) ...... Commercial Premium revenues (dollar 370 58% ...... 2016 CMS MLR files (in bil- amount and percent). lions); Percentage obtained by dividing by column E. (G) ...... Medicare Advantage Premium revenues (Dol- 157 25% ...... 2016 CMS MLR files (in bil- lar amount and percent). lions); Percentage obtained by dividing by column E. (H) ...... Medicaid Premium revenues (Dollar amount 113 18% ...... 2016 CMS MLR files (in bil- and percent). lions); Percentage obtained by dividing by column E.

Annual Interoperability Cost as a Percent of Commercial Premium Revenues

(I) ...... Annualized Level interoperability cost ...... 109.78 (D) ...... In millions. (J) ...... Percent of total revenues related to commer- 58% (F) ...... cial market. (K) ...... Interoperability cost for commercial issuers .... 63.67 (I) × (J) ...... In millions. (L) ...... Commercial Premium revenues ...... 370,000 (F) ...... In millions.

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00250 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7673

TABLE 10—TRANSFERS TO ENROLLEE RESULTING FROM THE PROPOSED RULE—Continued (M) ...... Interoperability cost as a percent of total com- 0.017% (K)/(L) ...... mercial revenue.

Commercial Revenue Broken Out by Whether Above or Below MLR Threshold (Requiring Rebate)

(N) ...... Total Commercial Revenue ...... 370,000 (F) ...... In millions. (O) ...... Revenues of commercial market issuers 19,400 2016 CMS MLR files (in mil- whose MLR is below threshold. lions). (P) ...... Revenues of commercial market issuers 350,600 (N)¥(O) ...... In millions. whose MLR is at or above the threshold.

Transfer To Enrollee per Enrollee From Decreased Rebates and Increased Premium

(Q) ...... Reduction in commercial market rebates from 3.3 (M) × (O) ...... In millions. interoperability for those issuers paying re- bates. (R) ...... Premium increase from interoperability for 60.0 (M) × (P) ...... In millions. those commercial market issuers not paying rebates. (S) ...... Total increase to commercial enrollees from 63.3 (Q) + (R) ...... In millions. interoperability. (T) ...... Number Commercial Enrollees ...... 76 2016 CMS MLR files (in mil- lions). (U) ...... Dollar increase in premium per enrollee ...... $0.83 (S)/(T) ......

F. Regulatory Reform Analysis under 42 CFR Part 423 Hospitals, Indians, Individuals with E.O. 13771 Administrative practice and disabilities, Loan programs—health, procedure, Emergency medical services, Medicaid, Organization and functions Executive Order 13771, titled (Government agencies), Public Reducing Regulation and Controlling Health facilities, Health maintenance organizations (HMO), Medicare, assistance programs, Reporting and Regulatory Costs, was issued on January recordkeeping requirements, State and 30, 2017 and requires that the costs Penalties, Privacy, Reporting and recordkeeping requirements. local governments, Sunshine Act, associated with significant new Technical assistance, Women, Youth. regulations ‘‘shall, to the extent 42 CFR Part 431 For the reasons set forth in the permitted by law, be offset by the preamble, the Centers for Medicare & elimination of existing costs associated Grant programs—health, Health Medicaid Services (CMS) proposes to with at least two prior regulations.’’ facilities, Medicaid, Privacy, Reporting amend 42 CFR chapter IV and the Office This proposed rule is considered an and recordkeeping requirements. of the Secretary (HHS) proposes to E.O. 13771 regulatory action. We 42 CFR Part 438 further amend 45 CFR subtitle A, estimate that this rule generates $56.7 subchapter B (as proposed to be million in annualized costs, discounted Grant programs—health, Medicaid, amended in ONC’s proposed rule ‘‘21st at 7 percent relative to year 2016, over Reporting and recordkeeping Century Cures Act: Interoperability, an infinite time horizon. Details on the requirements. Information Blocking, and the ONC estimated costs of this proposed rule 42 CFR Part 457 Health IT Certification Program’’ can be found in the preceding analysis. Administrative practice and published elsewhere in this issue of this G. Conclusion procedure, Grant programs—health, Federal Register), as set forth below: Health insurance, Reporting and The analysis above, together with the recordkeeping requirements. Title 42—Public Health preceding preamble, provides an RIA. Chapter IV—Centers For Medicare & In accordance with the provisions of 42 CFR Part 482 Medicaid Services, Department of Health Executive Order 12866, this regulation Grant programs—health, Hospitals, and Human Services was reviewed by the Office of Medicaid, Medicare, Reporting and Management and Budget. recordkeeping requirements. PART 406—HOSPITAL INSURANCE ELIGIBLIITY AND ENTITLEMENT List of Subjects 42 CFR Part 485 ■ 1. The authority citation for part 406 42 CFR Part 406 Grant programs—health, Health facilities, Medicaid, Privacy, Reporting is revised to read as follows: Health facilities, Diseases, Medicare. and recordkeeping requirements. Authority: 42 U.S.C 1302 and 1395hh. 42 CFR Part 407 45 CFR Part 156 ■ 2. Section 406.26 is amended by adding paragraph (a)(1)(i) and adding Medicare. Administrative practice and and reserving paragraph (a)(1)(ii) to read 42 CFR Part 422 procedure, Advertising, Advisory as follows: committees, Brokers, Conflict of Administrative practice and interests, Consumer protection, Grant § 406.26 Enrollment under State buy-in. procedure, Health facilities, Health programs—health, Grants (a) * * * maintenance organizations (HMO), administration, Health care, Health (1) * * * Medicare, Penalties, Privacy, Reporting insurance, Health maintenance (i) Any State that has a buy-in and recordkeeping requirements. organization (HMO), Health records, agreement in effect must participate in

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00251 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7674 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

daily exchanges of enrollment data with contracted providers, including names, where a specific data type or element CMS. addresses, phone numbers, and may be encoded or formatted using (ii) [Reserved] specialties, updated no later than 30 content and vocabulary standards in * * * * * business days after changes are made to either paragraph (c)(3)(i) or (ii) of this the provider directory; and section. PART 407—SUPPLEMENTARY (iv) Clinical data, including laboratory (4) May use an updated version of any MEDICAL INSURANCE (SMI) results, if the MA organization manages standard or all standards required under ENROLLMENT AND ENTITLEMENT any such data, no later than one (1) paragraph (c)(1) or (3) of this section, where: ■ business day after the data is received 3. The authority citation for part 407 by the MA organization. (i) Use of the updated version of the is revised to read as follows: (2) In addition to the information standard is required by other applicable Authority: 42 U.S.C 1302 and 1395hh. specified in paragraph (b)(1) of this law, or ■ 4. Section 407.40 is amended by section, an MA organization that offers (ii) Use of the updated version of the adding paragraph (c)(4) to read as an MA–PD plan must make the standard is not prohibited under other follows: following information accessible to its applicable law, provided that: enrollees through the API described in (A) For content and vocabulary § 407.40 Enrollment under a State buy-in paragraph (a) of this section: standards other than those at 45 CFR agreement. (i) Standardized data concerning 170.213, the Secretary has not * * * * * adjudicated claims for covered Part D prohibited use of the updated version of (c) * * * drugs, including remittances and a standard for purposes of this section (4) Any State that has a buy-in enrollee cost-sharing, no later than 1 or 45 CFR part 170; agreement in effect must participate in business day after a claim is (B) For standards at 45 CFR 170.213 daily exchanges of enrollment data with adjudicated; and 45 CFR 170.215, the National CMS. (ii) Pharmacy directory data, Coordinator has approved the updated including the number, mix, and version for use in the ONC Health IT PART 422—MEDICARE ADVANTAGE addresses of network pharmacies; and Certification Program; and PROGRAM (iii) Formulary data that includes (C) Where use of the updated version covered Part D drugs, and any tiered of a standard does not disrupt an end ■ 5. The authority citation for part 422 formulary structure or utilization user’s ability to access the data is revised to read as follows: management procedure which pertains described in paragraph (b) of this Authority: 42 U.S.C 1395w26 and 1395w– to those drugs. section through the API described in 27. (c) Technical requirements. An MA paragraph (a) of this section. ■ 6. Section 422.119 is added to read as organization: (d) Documentation requirements for follows: (1) Must implement, maintain, and APIs. For each API implemented in use API technology conformant with 45 accordance with paragraph (a) of this § 422.119 Access to and exchange of CFR 170.215; section, an MA organization must make health data and plan information. (2) Must conduct routine testing and publicly accessible, by posting directly (a) Application Programming monitoring to ensure the API functions on its website or via publicly accessible Interface to support MA enrollees. A properly, including assessments to hyperlink(s), complete accompanying Medicare Advantage (MA) organization verify that the API is fully and documentation that contains, at a must implement and maintain an open successfully implementing privacy and minimum: Application Programming Interface security features such as, but not limited (1) API syntax, function names, (API) that permits third-party to, those minimally required to comply required and optional parameters applications to retrieve, with the with HIPAA privacy and security supported and their data types, return approval and at the direction of an requirements in 45 CFR part 164, 42 variables and their types/structures, individual MA enrollee, data specified CFR parts 2 and 3, and other applicable exceptions and exception handling in paragraph (b) of this section through law protecting the privacy and security methods and their returns; the use of common technologies and of individually identifiable data; (2) The software components and without special effort from the enrollee. (3) Must comply with the following configurations an application must use (b) Accessible content. (1) An MA regulations regarding content and in order to successfully interact with the organization must make the following vocabulary standards for data available API and process its response(s); and information accessible to its enrollees through the API, where applicable to the (3) All applicable technical through the API described in paragraph data type or data element, unless requirements and attributes necessary (a) of this section: alternate standards are required by other for an application to be registered with (i) Standardized data concerning applicable law: any authorization server(s) deployed in adjudicated claims, including claims (i) Content and vocabulary standards conjunction with the API. data for payment decisions that may be at 45 CFR 170.213 where such standards (e) Denial or discontinuation of access appealed, were appealed, or are in the are the only available standards for the to the API. An MA organization may process of appeal, and provider data type or element; deny or discontinue any third party remittances and enrollee cost-sharing (ii) Content and vocabulary standards application’s connection to the API pertaining to such claims, no later than at 45 CFR part 162 and 42 CFR 423.160 required under paragraph (a) of this one (1) business day after a claim is where required by law or where such section if the MA organization: processed; standards are the only available (1) Reasonably determines that (ii) Standardized encounter data, no standards for the data type or element; allowing an application to connect or later than one (1) business day after data or remain connected to the API would concerning the encounter is received by (iii) The content and vocabulary present an unacceptable level of risk to the MA organization; standards in either paragraph (c)(3) (i) or the security of protected health (iii) Provider directory data on the (ii) of this section as determined information on the MA organization’s MA organization’s network of appropriate for the data type or element, systems; and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00252 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7675

(2) Makes this determination using they will entrust their health PART 431—STATE ORGANIZATION objective, verifiable criteria that are information; and AND GENERAL ADMINISTRATION applied fairly and consistently across all (2) An overview of which types of ■ applications and developers through organizations or individuals are and are 10. The authority citation for part 431 which enrollees seek to access their not likely to be HIPAA covered entities, is revised to read as follows: electronic health information, as the oversight responsibilities of OCR Authority: 42 U.S.C. 1302. defined at 45 CFR 171.102, including and FTC, and how to submit a ■ 11. Section 431.60 is added to subpart but not limited to criteria that may rely complaint to: B to read as follows: on automated monitoring and risk (i) The HHS Office for Civil Rights; mitigation tools. and § 431.60 Beneficiary access to and (f) Coordination among payers. (1) (ii) The Federal Trade Commission exchange of data. MA organizations must maintain a (FTC). (a) Application Programming process for the electronic exchange of, at (h) Applicability. This section is Interface to support Medicaid a minimum, the data classes and applicable beginning on and after beneficiaries. A State must implement elements included in the regulations January 1, 2020. and maintain an open Application regarding the content standard adopted ■ 7. Section 422.504 is amended by Programming Interface (API) that at 45 CFR 170.213. Such information adding paragraph (a)(18) to read as permits third-party applications to received by an MA organization must be follows: retrieve, with the approval and at the direction of a beneficiary, data specified incorporated into the MA organization’s § 422.504 Contract provisions. records about the enrollee. At the in paragraph (b) of this section through request of an enrollee, the MA * * * * * the use of common technologies and organization must: (a) * * * without special effort from the (i) Receive such data from any other (18) To comply with the requirements beneficiary. health care plan that has provided for access to health data and plan (b) Accessible content. A State must coverage to the enrollee within the information under § 422.119. make the following information preceding 5 years; * * * * * accessible to its beneficiaries through (ii) At any time an enrollee is the API described in paragraph (a) of currently enrolled in the MA plan and PART 423—VOLUNTARY MEDICARE this section: up to 5 years after disenrollment, send PRESCRIPTION DRUG BENEFIT (1) Standardized data concerning such data to any other health care plan ■ 8. The authority citation for part 423 adjudicated claims, including claims that currently covers the enrollee; and is revised to read as follows: data for payment decisions that may be (iii) At any time the enrollee is appealed, were appealed, or are in the currently enrolled in the MA plan and Authority: 42 U.S.C. 1302, 1306, 1395w– process of appeal, and provider 101 through 1395w–152, and 1395hh. up to 5 years after disenrollment, send remittances and beneficiary cost-sharing such data to a recipient designated by ■ 9. Section 423.910 is amended— pertaining to such claims, no later than the enrollee. ■ a. In paragraph (b)(1) introductory text one (1) business day after a claim is (2) MA organizations must participate by removing the phrase ‘‘monthly processed; in a trusted exchange network which: reporting requirement for the monthly (2) Standardized encounter data (i) Is capable of exchanging protected enrollment reporting’’ and adding in its through the API within one (1) business health information, defined at 45 CFR place the phrase ‘‘state enrollment day of receiving the data from providers, 160.103, in compliance with all reporting requirement described in other than MCOs, PIHPs, and PAHPs, applicable State and Federal laws across paragraph (d) of this section’’; compensated on the basis of capitation jurisdictions; ■ b. In paragraph (d) by revising the payments; (ii) Is capable of connecting to paragraph heading and by redesignating (3) Provider directory information inpatient electronic health records and the text of paragraph (d) introductory specified in section 1902(a)(83) of the ambulatory electronic health records; text as paragraph (d)(1). Act, no later than 30 calendar days after and ■ c. In newly redesignated paragraph the State receives provider directory (iii) Supports secure messaging or (d)(1), by removing the phrase ‘‘Effective information or updates to provider electronic querying by and between June 2005, and each subsequent directory information; providers, payers and patients. month,’’, and following the phrase ‘‘in (4) Clinical data, including laboratory (g) Enrollee resources regarding a manner specified by CMS’’ by adding results, if the State manages any such privacy and security. An MA the following phrase ‘‘and frequency data, no later than one (1) business day organization must provide on its specified in paragraph (d)(2) of this after the data is received by the State; website and through other appropriate section,’’; and and mechanisms through which it ordinarily ■ d. By adding paragraph (d)(2). (5) Information about covered communicates with current and former The addition reads as follows: outpatient drugs and updates to such enrollees seeking to access their health information, including, where § 423.910 Requirements. information held by the MA applicable, preferred drug list organization, educational resources in * * * * * information, no later than one (1) non-technical, simple and easy-to- (d) State enrollment reporting. *** business day after the effective date of understand language explaining at a (2)(i) For the period prior to April 1, any such information or updates to such minimum: 2022, States must submit the file at least information. (1) General information on steps the monthly and may submit updates to that (c) Technical requirements. A State: individual may consider taking to help file on a more frequent basis. (1) Must implement, maintain, and protect the privacy and security of their (ii) For the period beginning April 1, use API technology conformant with 45 health information, including factors to 2022, States must submit the file at least CFR 170.215; consider in selecting an application, and monthly and must submit updates to (2) Must conduct routine testing and understanding the security and privacy that file on a daily basis. monitoring to ensure the API functions practices of any application to which * * * * * properly, including assessments to

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00253 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7676 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

verify that the API is fully and documentation that contains, at a (g) Applicability. This section is successfully implementing privacy and minimum: applicable beginning on or after July 1, security features such as, but not limited (1) API syntax, function names, 2020. to, those minimally required to comply required and optional parameters with HIPAA privacy and security supported and their data types, return PART 438—MANAGED CARE requirements in 45 CFR part 164, 42 variables and their types/structures, ■ 12. The authority citation for part 438 CFR parts 2 and 3, and other applicable exceptions and exception handling is revised to read as follows: law protecting the privacy and security methods and their returns; of individually identifiable data; (2) The software components and Authority: 42 U.S.C. 1302. (3) Must comply with the following configurations an application must use ■ 13. Section 438.62 is amended by regulations regarding content and in order to successfully interact with the adding paragraph (b)(1)(vi) to read as vocabulary standards for data available API and process its response(s); and follows: through the API, where applicable to the (3) All applicable technical § 438.62 Continued services to enrollees. data type or data element, unless requirements and attributes necessary alternate standards are required by other for an application to be registered with * * * * * applicable law: any authorization server(s) deployed in (b) * * * (i) Content and vocabulary standards conjunction with the API. (1) * * * (vi) A process for the electronic at 45 CFR 170.213 where such standards (e) Denial or discontinuation of access exchange of, at a minimum, the data are the only available standards for the to the API. A State may deny or classes and elements included in the data type or element; discontinue any third-party (ii) Content and vocabulary standards application’s connection to the API regulations regarding the content at 45 CFR part 162 and 42 CFR 423.160 required under paragraph (a) of this standard at 45 CFR 170.213. Information where required by law, or where such section if the State: received by the MCO, PIHP, or PAHP standards are the only available (1) Reasonably determines that must be incorporated into the MCO’s, PIHP’s, or PAHP’s records about the standards for the data type or element; allowing an application to connect or enrollee. At the request of an enrollee, or remain connected to the API would (iii) The content and vocabulary present an unacceptable level of risk to the MCO, PIHP, or PAHP must: (A) Accept such data from any other standards in either paragraphs (c)(3)(i) the security of protected health health care plan that has provided or (ii) of this section, as determined information on the State’s systems; and coverage to the enrollee within the appropriate for the data type or element, (2) Makes this determination using preceding 5 years; where a specific data type or element objective, verifiable criteria that are applied fairly and consistently across all (B) At any time the enrollee is may be encoded or formatted using currently enrolled in the MCO, PIHP, or applications and developers through content and vocabulary standards in PAHP and up to 5 years after which beneficiaries seek to access their either paragraph (c)(3)(i) or (ii) of this disenrollment, send such data to any electronic health information as defined section. other health care plan that currently at 45 CFR 171.102, including but not (4) May use an updated version of any covers the enrollee; and standard or all standards required under limited to criteria that may rely on (C) At any time the enrollee is paragraph (c)(1) or (3) of this section, automated monitoring and risk currently enrolled in the MCO, PIHP, or where: mitigation tools. PAHP and up to 5 years after (f) Beneficiary resources regarding (i) Use of the updated version of the disenrollment, send such data to any privacy and security. The State must standard is required by other applicable other recipient designated by the law, or provide on its website and through enrollee. (ii) Use of the updated version of the other appropriate mechanisms through standard is not prohibited under other which it ordinarily communicates with * * * * * ■ 14. Section 438.242 is amended by applicable law, provided that: current and former beneficiaries seeking adding paragraphs (b)(5) and (6) to read (A) For content and vocabulary to access their health information held as follows: standards other than those at 45 CFR by the State Medicaid agency, 170.213, the Secretary has not educational resources in non-technical, § 438.242 Health information systems. prohibited use of the updated version of simple and easy-to-understand language * * * * * a standard for purposes of this section explaining at a minimum: (b) * * * or 45 CFR part 170; (1) General information on steps the (5) Participate in a trusted exchange (B) For standards at 45 CFR 170.213 individual may consider taking to help network which: and 45 CFR 170.215, the National protect the privacy and security of their (i) Is capable of exchanging protected Coordinator has approved the updated health information, including factors to health information as defined in 45 CFR version for use in the ONC Health IT consider in selecting an application, and 160.103, in compliance with all Certification Program; and understanding the security and privacy applicable State and Federal laws from (C) Where use of the updated version practices of any application to which all relevant jurisdictions; of a standard does not disrupt an end they will entrust their health (ii) Is capable of connecting to user’s ability to access the data information; and inpatient electronic health records and described in paragraph (b) of this (2) An overview of which types of ambulatory electronic health records, section through the API described in organizations or individuals are and are and; paragraph (a) of this section. not likely to be HIPAA covered entities, (iii) Supports secure messaging or (d) Documentation requirements for the oversight responsibilities of OCR electronic querying by and between APIs. For each API implemented in and FTC, and how to submit a providers, payers and patients. accordance with paragraph (a) of this complaint to: (6) Implement an Application section, a State must make publicly (i) The HHS Office for Civil Rights; Programming Interface (API) as accessible, by posting directly on its and specified in § 431.60 of this chapter as website or via publicly accessible (ii) The Federal Trade Commission if such requirements applied directly to hyperlink(s), complete accompanying (FTC). the MCO, PIHP, or PAHP and

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00254 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7677

(i) Include all standardized encounter accessible to its beneficiaries through standards for the data type or element; data, including encounter data from any the API described in paragraph (a) of or network providers the MCO, PIHP, or this section: (iii) The content and vocabulary PAHP is compensating on the basis of (1) Standardized data concerning standards in either paragraphs (c)(3)(i) capitation payments and adjudicated adjudicated claims, including claims or (ii) of this section, as determined claims and encounter data from any data for payment decisions that may be appropriate for the data type or element, subcontractors; and appealed, were appealed, or are in the where a specific data type or element (ii) Provider directory information process of appeal, and provider may be encoded or formatted using required in § 431.60(b)(3) of this remittances and beneficiary cost-sharing content and vocabulary standards in chapter, which must include all pertaining to such claims, no later than either paragraphs (c)(3)(i) or (ii) of this information required in § 438.10(h)(1). one (1) business day after a claim is section. * * * * * processed; (4) May use an updated version of any (2) Standardized encounter data standard or all standards required under PART 457—ALLOTMENTS AND through the API within one (1) business paragraphs (c)(1) or (3) of this section, GRANTS TO STATES day of receiving the data from providers, where: (i) Use of the updated version of the ■ 15. The authority citation for part 457 other than MCOs, PIHPs, or PAHPs, standard is required by other applicable is revised to read as follows: compensated on the basis of capitation payments; law, or Authority: 42 U.S.C. 1302. (3) Provider directory information, (ii) Use of the updated version of the ■ 16. Section 457.700 is amended by— standard is not prohibited under other ■ including updated provider information a. Redesignating paragraphs (a)(1) and no later than 30 calendar days after the applicable law, provided that: (2) as paragraphs (a)(2) and (3), State receives updated provider (A) For content and vocabulary respectively; information; standards other than those at 45 CFR ■ b. Adding paragraph (a)(1); 170.213, the Secretary has not ■ c. Revising paragraph (c). (4) Clinical data, including laboratory results, if a State manages any such prohibited use of the updated version of The addition and revision reads as a standard for purposes of this section follows: data, no later than one (1) business day after the data is received by the State; or 45 CFR part 170; (B) For standards at 45 CFR 170.213 § 457.700 Basis, scope, and applicability. and and 45 CFR 170.215, the National (a) * * * (5) Information, about covered Coordinator has approved the updated (1) Section 2101(a) of the Act, which outpatient drugs and updates to such version for use in the ONC Health IT sets forth that the purpose of title XXI information, including, where Certification Program; and is to provide funds to States to provide applicable, preferred drug list child health assistance to uninsured, (C) Where use of the updated version information, no later than one (1) of a standard does not disrupt an end low-income children in an effective and business day after the effective date of efficient manner that is coordinated user’s ability to access the data the information or updates to such described in paragraph (b) of this with other sources of health benefits information. coverage; section through the API described in (c) Technical requirements. A State: paragraph (a) of this section. * * * * * (1) Must implement, maintain, and (d) Documentation requirements for (c) Applicability. The requirements of use API technology conformant with 45 APIs. For each API implemented in this subpart apply to separate child CFR 170.215; accordance with paragraph (a) of this health programs and Medicaid (2) Must conduct routine testing and section, a State must make publicly expansion programs, except that monitoring to ensure the API functions accessible, by posting directly on its § 457.730 does not apply to Medicaid properly, including assessments to website or via publicly accessible expansion programs. Separate child verify that the API technology is fully hyperlink(s), complete accompanying health programs that provide benefits and successfully implementing privacy documentation that contains, at a exclusively through managed care and security features such as, but not minimum: organizations may meet the limited to, those minimally required to (1) API syntax, function names, requirements of § 457.730 by requiring comply with HIPAA privacy and required and optional parameters the managed care organizations to meet security requirements in 45 CFR part supported and their data types, return the requirements of § 457.1233(d)(2). 164, 42 CFR parts 2 and 3, and other ■ variables and their types/structures, 17. Section 457.730 is added to read applicable law protecting the privacy as follows: exceptions and exception handling and security of individually identifiable methods and their returns; § 457.730 Beneficiary access to and data; (2) The software components and exchange of data. (3) Must comply with the following configurations that an application must (a) Application Programming regulations regarding content and use in order to successfully interact Interface to support CHIP beneficiaries. vocabulary standards for data available with the API and process its response(s); A State must implement and maintain through the API, where applicable to the and an open application programming data type or data element, unless (3) All applicable technical interface (API) that permits third-party alternate standards are required by other requirements and attributes necessary applications to retrieve, with the applicable law: for an application to be registered with approval and at the direction of the (i) Content and vocabulary standards any authorization server(s) deployed in individual beneficiary, data specified in at 45 CFR 170.213 where such standards conjunction with the API. paragraph (b) of this section through the are the only available standards for the (e) Denial or discontinuation of access use of common technologies and data type or element; to the API. A State may deny or without special effort from the (ii) Content and vocabulary standards discontinue any third-party beneficiary. at 45 CFR part 162 and 42 CFR 423.160 application’s connection to the API (b) Accessible content. A State must where required by law, or where such required under paragraph (a) of this make the following information standards are the only available section if the State:

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00255 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7678 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

(1) Reasonably determines that (i) Include all standardized encounter transfer from the hospital, the system allowing an application to connect or data, including encounter data from any sends notifications directly or through remain connected to the API would network providers the MCO, PIHP, or an intermediary that facilitates exchange present an unacceptable level of risk to PAHP is compensating on the basis of of health information, to licensed and the security of protected health capitation payments and adjudicated qualified practitioners, other patient information on the State’s systems; and claims and encounter data from any care team members, and post-acute care (2) Makes this determination using subcontractors; and services providers and suppliers: objective, verifiable criteria that are (ii) Provider directory information (i) That receive the notification for applied fairly and consistently across all required in § 457.730(b)(3), which must treatment, care coordination, or quality applications and developers through include all information required in improvement purposes; which beneficiaries seek to access their § 438.10(h)(1) of this chapter. (ii) That have an established care electronic health information as defined * * * * * relationship with the patient relevant to at 45 CFR 171.102, including but not his or her care; and limited to criteria that may rely on PART 482—CONDITIONS OF (iii) For whom the hospital has a automated monitoring and risk PARTICIPATION: HOSPITALS reasonable certainty of receipt of notifications. mitigation tools. ■ 19. The authority citation for part 482 ■ 21. Section 482.61 is amended by (f) Beneficiary resources regarding is revised to read as follows: privacy and security. A State must adding paragraph (f) to read as follows: provide on its website and through Authority: 42 U.S.C. 1302, 1395hh, and 1395rr, unless otherwise noted. § 482.61 Condition of participation: other appropriate mechanisms through Special medical record requirements for which it ordinarily communicates with ■ 20. Sections 482.24 is amended by psychiatric hospitals. adding paragraph (d) to read as follows: current and former beneficiaries seeking * * * * * to access their health information held § 482.24 Conditions of participation: (f) Standard: Electronic notifications. by the State CHIP agency, educational Medical record services. If the hospital utilizes an electronic resources in non-technical, simple and * * * * * medical records system with the easy-to-understand language explaining capacity to generate information for at a minimum: (d) Standard: Electronic notifications. If the hospital utilizes an electronic patient event notifications in (1) General information on steps the medical records system with the accordance with paragraph (f)(2) of this individual may consider taking to help capacity to generate information for section, then the hospital must protect the privacy and security of their patient event notifications in demonstrate that— health information, including factors to accordance with paragraph (d)(2) of this (1) The system’s notification capacity consider in selecting an application, and section, then the hospital must is fully operational and that it operates understanding the security and privacy demonstrate that— in accordance with all State and Federal practices of any application to which (1) The system’s notification capacity statutes and regulations regarding the they will entrust their health is fully operational and that it operates exchange of patient health information; information; and in accordance with all State and Federal (2) The system complies with the (2) An overview of which types of statutes and regulations regarding the regulations regarding the content organizations or individuals are and are exchange of patient health information; exchange standard at 45 CFR not likely to be HIPAA covered entities, (2) The system complies with the 170.205(a)(4)(i); the oversight responsibilities of OCR regulations regarding the content (3) The system sends notifications and FTC, and how to submit a exchange standard at 45 CFR that must include the minimum patient complaint to: 170.205(a)(4)(i); health information (which must be (i) The HHS Office for Civil Rights; (3) The system sends notifications patient name, treating practitioner and that must include the minimum patient name, sending institution name, and, if (ii) The Federal Trade Commission health information (which must be not prohibited by other applicable law, (FTC). patient name, treating practitioner patient diagnosis); (g) Applicability. This section is name, sending institution name, and, if (4) At the time of the patient’s applicable beginning on or after July 1, not prohibited by other applicable law, admission to the hospital, the system 2020. patient diagnosis); sends notifications directly, or through ■ 18. Section 457.1233 is amended by (4) At the time of the patient’s an intermediary that facilitates exchange revising paragraph (d) to read as admission to the hospital, the system of health information, to licensed and follows: sends notifications directly or through qualified practitioners, other patient an intermediary that facilitates exchange care team members, and post-acute care § 457.1233 Structure and operations of health information, to licensed and services providers and suppliers: standards. qualified practitioners, other patient (i) That receive the notification for * * * * * care team members, and post-acute care treatment, care coordination, or quality (d) Health information systems. (1) services providers and suppliers: improvement purposes; The State must ensure, through its (i) That receive the notification for (ii) That have an established care contracts, that each MCO, PIHP, and treatment, care coordination, or quality relationship with the patient relevant to PAHP complies with the health improvement purposes; his or her care; and information systems requirements as (ii) That have an established care (iii) For whom the hospital has a provided in § 438.242(a), (b)(1) through relationship with the patient relevant to reasonable certainty of receipt of (5), (c), (d), and (e) of this chapter. his or her care; and notifications; and (2) Each MCO, PIHP, and PAHP must (iii) For whom the hospital has a (5) Either immediately prior to or at implement an Application Programming reasonable certainty of receipt of the time of the patient’s discharge or Interface (API) as specified in § 457.730 notifications; and transfer from the hospital, the system as if such requirements applied directly (4) Either immediately prior to or at sends notifications directly or through to the MCO, PIHP, or PAHP, and the time of the patient’s discharge or an intermediary that facilitates exchange

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00256 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules 7679

of health information, to licensed and transfer from the CAH, the system sends concerning the encounter is received by qualified practitioners, other patient notifications directly or through an the QHP issuer; and care team members, and post-acute care intermediary that facilitates exchange of (iii) Clinical data, including services providers and suppliers: health information, to licensed and laboratory results, if the QHP issuer (i) That receive the notification for qualified practitioners, other patient maintains such data, no later than one treatment, care coordination, or quality care team members, and post-acute care (1) business day after data is received by improvement purposes; services providers and suppliers: the issuer. (ii) That have an established care (i) That receive the notification for (c) Technical requirements. A QHP relationship with the patient relevant to treatment, care coordination, or quality issuer in a Federally-facilitated his or her care; and improvement purposes; Exchange: (iii) For whom the hospital has a (ii) That have an established care (1) Must implement, maintain, and reasonable certainty of receipt of relationship with the patient relevant to use API technology conformant 45 CFR notifications. his or her care; and 170.215; (iii) For whom the CAH has a (2) Must conduct routine testing and PART 485—CONDITIONS OF reasonable certainty of receipt of monitoring to ensure the API functions PARTICIPATION: SPECIALIZED notifications. properly, including assessments to PROVIDERS TITLE 45—PUBLIC WELFARE verify the API is fully and successfully ■ 22. The authority citation for part 485 implementing privacy and security is revised to read as follows: Subtitle A—Department of Health and features such as, but not limited to, Human Services those minimally required to comply Authority: 42 U.S.C. 1302 and 1395hh. with HIPAA privacy and security PART 156—HEALTH INSURANCE ■ 23. Section 485.638 is amended by requirements in 45 CFR part 164, 42 ISSUER STANDARDS UNDER THE adding paragraph (d) to read as follows: CFR parts 2 and 3, and other applicable AFFORDABLE CARE ACT, INCLUDING law protecting privacy and security of § 485.638 Conditions of participation: STANDARDS RELATED TO individually identifiable data; Clinical records. EXCHANGES (3) Must comply with the following * * * * * ■ (d) Standard: Electronic notifications. 24. The authority citation for part 156 regulations regarding the content and If the CAH utilizes an electronic is revised to read as follows: vocabulary standards for data available medical records system with the Authority: 42 U.S.C. 18021–18024, 18031– through the API where applicable to the capacity to generate information for 18032, 18041–18042, 18044, 18054, 18061, data type or data element, unless patient event notifications in 18063, 18071, 18082, 26 U.S.C. 36B, and 31 alternate standards are required by other accordance with paragraph (d)(2) of this U.S.C. 9701. applicable law: section, then the CAH must demonstrate ■ 25. Section 156.221 is added to read (i) Content and vocabulary standards that— as follows: at 45 CFR 170.213 where such are the (1) The system’s notification capacity only available standards for the data is fully operational and that it operates § 156.221 Access to and exchange of type or element; health data and plan information. in accordance with all State and Federal (ii) Content and vocabulary standards statutes and regulations regarding the (a) Application Programming at 45 CFR part 162 and 42 CFR 423.160 exchange of patient health information; Interface to support enrollees. Subject to where required by law, or where such (2) The system complies with the paragraph (h) of this section, QHP standards are the only available regulations regarding the content issuers in a Federally-facilitated standards for the data type or element; exchange standard at 45 CFR Exchange, not including stand-alone or 170.205(a)(4)(i); dental plans (SADP) issuers, must (iii) The content and vocabulary (3) The system sends notifications implement and maintain an open standards in either paragraph (c)(3)(i) or that must include the minimum patient Application Programming Interface (ii) of this section as determined health information (which must be (API) that permits third-party appropriate for the data type or element, patient name, treating practitioner applications to retrieve, with the where a specific data type or element name, sending institution name, and, if approval and at the direction of an may be encoded or formatted using not prohibited by other applicable law, individual enrollee, data specified in content and vocabulary standards in patient diagnosis); paragraph (b) of this section through the either paragraph (c)(3)(i) or (ii) of this (4) At the time of the patient’s use of common technologies and section. admission to the CAH, the system sends without special effort from the enrollee. (4) May use an updated version of any notifications directly or through an (b) Accessible content. (1) A QHP standard or all standards required under intermediary that facilitates exchange of issuer in a Federally-facilitated paragraphs (c)(1) or (3) of this section, health information, to licensed and Exchange must make the following where: qualified practitioners, other patient information accessible to its enrollees (i) Use of the updated version of the care team members, and post-acute care through the API described in paragraph standard is required by other applicable services providers and suppliers: (a) of this section: law, or (i) That receive the notification for (i) Standardized data concerning (ii) Use of the updated version of the treatment, care coordination, or quality adjudicated claims, including claims standard is not prohibited under other improvement purposes; data for payment decisions that may be applicable law, provided that: (ii) That have an established care appealed, were appealed, or are in the (A) For content and vocabulary relationship with the patient relevant to process of appeal, and provider standards other than those at 45 CFR his or her care; and remittances and enrollee cost-sharing 170.213, the Secretary has not (iii) For whom the CAH has a pertaining to such claims, no later than prohibited use of the updated version of reasonable certainty of receipt of one (1) business day after a claim is a standard for purposes of this section notifications; and processed; or 45 CFR part 170; (5) Either immediately prior to or at (ii) Standardized encounter data, no (B) For standards at 45 CFR 170.213 the time of the patient’s discharge or later than one (1) business day after data and 45 CFR 170.215, the National

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00257 Fmt 4701 Sfmt 4702 E:\FR\FM\04MRP2.SGM 04MRP2 7680 Federal Register / Vol. 84, No. 42 / Monday, March 4, 2019 / Proposed Rules

Coordinator has approved the updated (f) Exchange of data between plans. health information, including factors to version for use in the ONC Health IT (1) Subject to paragraph (d) of this consider in selecting an application, and Certification Program; and section, QHP issuers in a Federally- understanding the security and privacy (iii) Where use of the updated version facilitated Exchange, not including practices of any application to which of a standard does not disrupt an end SADP issuers, must maintain a process they will entrust their health user’s ability to access the data for the electronic exchange of, at a information; and described in paragraph (b) of this minimum, the data classes and elements (2) An overview of which types of section through the API described in included in the regulations regarding organizations or individuals are and are paragraph (a) of this section. the content standard at 45 CFR 170.213 not likely to be HIPAA covered entities, (d) Documentation requirements for of this subchapter. Information received the oversight responsibilities of OCR APIs. For each API implemented in by a QHP issuer must be incorporated and FTC, and how to submit a accordance with paragraph (a) of this into the QHP issuer’s records about the complaint to: section, a QHP issuer must make enrollee. At the request. A QHP issuer publicly accessible, by posting directly (i) The HHS Office for Civil Rights; must: and on its website and/or via publicly (i) Accept such data from any other accessible hyperlink(s), complete health care plan that has provided (ii) The Federal Trade Commission accompanying documentation that coverage to the enrollee within the (FTC). contains, at a minimum: preceding 5 years; (h) Exception. (1) If a plan applying (1) API syntax, function names, (ii) At any time the enrollee is for QHP certification to be offered required and optional parameters currently enrolled in the plan and up to through a Federally-facilitated Exchange supported and their data types, return 5 years after disenrollment, send such believes it cannot satisfy the variables and their types/structures, data to any other health care plan that requirements in paragraphs (a), (b), or exceptions and exception handling currently covers the enrollee; and (c) of this section, the issuer must methods and their returns; (iii) At any time the enrollee is include as part of its QHP application a (2) The software components and currently enrolled in the plan and up to narrative justification describing the configurations an application must use 5 years after disenrollment, send such reasons why the plan cannot reasonably in order to successfully interact with the data to a recipient designated by the satisfy the requirements for the API and process its response(s); and enrollee. applicable plan year, the impact of non- (3) All applicable technical (2) QHP issuers must participate in a compliance upon enrollees, the current requirements and attributes necessary trusted exchange network which: or proposed means of providing health for an application to be registered with (i) Is capable of exchanging protected information to enrollees, and solutions any authorization server(s) deployed in health information, defined at 45 CFR and a timeline to achieve compliance conjunction with the API. 160.103 of this subchapter, in with the requirements of this section. (e) Denial or discontinuation of access compliance with all applicable State (2) The Federally-facilitated Exchange to the API. A QHP issuer in a Federally- and Federal laws of relevant may grant an exception to the facilitated Exchange may deny or jurisdictions; requirements in paragraphs (a), (b), or discontinue any third party (ii) Is capable of connecting to (c) if the Exchange determines that application’s connection to the API inpatient electronic health records and making such health plan available required under paragraph (a) of this ambulatory electronic health records; through such Exchange is in the section if the issuer: and (1) Reasonably determines that (iii) Supports secure messaging or interests of qualified individuals and allowing an application to connect or electronic querying by and between qualified employers in the State or remain connected to the API would providers, payers and patients. States in which such Exchange operates. present an unacceptable level of risk to (g) Enrollee resources regarding (i) Applicability. This section is the security of personally identifiable privacy and security. A QHP issuer in a applicable for plan years beginning on information, including protected health Federally-facilitated Exchange must or after January 1, 2020. information, on the QHP issuer’s provide on its website and through (ii) [Reserved] other appropriate mechanisms through systems; and Dated: December 14, 2018. (2) Makes this determination using which it ordinarily communicates with objective, verifiable criteria that are current and former enrollees seeking to Seema Verma, applied fairly and consistently across all access their health information held by Administrator, Centers for Medicare & applications and developers through the QHP issuer, educational resources in Medicaid Services. which enrollees seek to access their non-technical, simple and easy-to- Dated: January 10, 2019. electronic health information as defined understand language explaining at a Alex M. Azar II, at 45 CFR 171.102, including but not minimum: Secretary, Department of Health and Human limited to criteria that may rely on (1) General information on steps the Services. automated monitoring and risk individual may consider taking to help [FR Doc. 2019–02200 Filed 2–22–19; 4:15 pm] mitigation tools. protect the privacy and security of their BILLING CODE 4120–01–P

VerDate Sep<11>2014 19:17 Mar 01, 2019 Jkt 247001 PO 00000 Frm 00258 Fmt 4701 Sfmt 9990 E:\FR\FM\04MRP2.SGM 04MRP2