Justia Department Of Health And Human Services Centers For Medicare & Medicaid Services Medicaid Program; Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients' Electronic Access to Health Information for Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges; Health Information Technology Standards and Implementation Specifications, 82586-82682 [2020-27593]

Medicaid Program; Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients' Electronic Access to Health Information for Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the Federally-Facilitated Exchanges; Health Information Technology Standards and Implementation Specifications, 82586-82682 [2020-27593]

Download as PDF 82586 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules Centers for Medicare & Medicaid Services 42 CFR Parts 431, 435, 438, 440, and 457 Office of the Secretary 45 CFR Parts 156 and 170 [CMS–9123–P] RIN 0938–AT99 Medicaid Program; Patient Protection and Affordable Care Act; Reducing Provider and Patient Burden by Improving Prior Authorization Processes, and Promoting Patients’ Electronic Access to Health Information for Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified Health Plans on the FederallyFacilitated Exchanges; Health Information Technology Standards and Implementation Specifications Centers for Medicare & Medicaid Services (CMS), HHS; Office of the National Coordinator for Health Information Technology (ONC), HHS. ACTION: Proposed rule. AGENCY: This proposed rule would place new requirements on state Medicaid and CHIP fee-for-service (FFS) programs, Medicaid managed care plans, CHIP managed care entities, and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFEs) to improve the electronic exchange of health care data, and streamline processes related to prior authorization, while continuing CMS’ drive toward interoperability, and reducing burden in the health care market. In addition, on behalf of the Department of Health and Human Service (HHS), the Office of the National Coordinator for Health Information Technology (ONC) is proposing the adoption of certain specified implementation guides (IGs) needed to support the proposed Application Programming Interface (API) policies included in this rule. Each of these elements plays a key role in reducing overall payer and provider burden and improving patient access to health information. khammond on DSKJM1Z7X2PROD with PROPOSALS2 SUMMARY: To be assured consideration, comments must be received at one of the addresses provided below, no later than 5 p.m. on January 4, 2021. DATES: VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 In commenting, please refer to file code CMS–9123–P. Comments, including mass comment submissions, must be submitted in one of the following three ways (please choose only one of the ways listed): 1. Electronically. You may submit electronic comments on this regulation to https://www.regulations.gov. Follow the ‘‘Submit a comment’’ instructions. 2. By regular mail. You may mail written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS–9123–P, P.O. Box 8016, Baltimore, MD 21244–8016. Please allow sufficient time for mailed comments to be received before the close of the comment period. 3. By express or overnight mail. You may send written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS–9123–P, Mail Stop C4–26–05, 7500 Security Boulevard, Baltimore, MD 21244–1850. For information on viewing public comments, see the beginning of the SUPPLEMENTARY INFORMATION section. FOR FURTHER INFORMATION CONTACT: Alexandra Mugge, (410) 786–4457, for general issues related to this rule and CMS interoperability initiatives. Denise St. Clair, (410) 786–4599, for the API policies, implementation guides (IGs), general issues related to this rule, and CMS interoperability initiatives. Lorraine Doo, (443) 615–1309, for prior authorization process policies and CMS interoperability initiatives. Amy Gentile, (410) 786–3499, for issues related to Medicaid managed care. Kirsten Jensen, (410) 786–8146, for issues related to Medicaid fee for service (FFS). Cassandra Lagorio, (410) 786–4554, for issues related to the Children’s Health Insurance Program (CHIP). Russell Hendel, (410) 786–0329, for issues related to the Collection of Information and Regulatory Impact Analysis. Rebecca Zimmermann, (301) 492– 4396, for issues related to Qualified Health Plans (QHPs). SUPPLEMENTARY INFORMATION: Inspection of Public Comments: All comments received before the close of the comment period are available for viewing by the public, including any personally identifiable or confidential business information that is included in a comment. We post all comments received before the close of the comment period on the following ADDRESSES: DEPARTMENT OF HEALTH AND HUMAN SERVICES PO 00000 Frm 00002 Fmt 4701 Sfmt 4702 website as soon as possible after they have been received: https:// www.regulations.gov. Follow the search instructions on that website to view public comments. CMS will not post on Regulations.gov public comments that make threats to individuals or institutions or suggest that the individual will take actions to harm the individual. CMS continues to encourage individuals not to submit duplicative comments. We will post acceptable comments from multiple unique commenters even if the content is identical or nearly identical to other comments. Table of Contents I. Background and Summary of Provisions A. Purpose B. Summary of Major Proposals II. Provisions of the Proposed Rule A. Patient Access API B. Provider Access APIs C. Documentation and Prior Authorization Burden Reduction Through APIs D. Payer-to Payer Data Exchange on FHIR E. Adoption of Health IT Standards and Implementation Specifications III. Requests for Information A. Request for Information: Methods for Enabling Patients and Providers to Control Sharing of Health Information B. Request for Information: Electronic Exchange of Behavioral Health Information C. Request for Information: Reducing Burden and Improving Electronic Information Exchange of Prior Authorization D. Request for Information: Reducing the Use of Fax Machines E. Request for Information: Accelerating the Adoption of Standards Related to Social Risk Data IV. Incorporation by Reference V. Collection of Information VI. Response to Comments VII. Regulatory Impact Analysis Regulations Text I. Background and Summary of Provisions A. Purpose In the May 1, 2020 Federal Register, we published the first phase of CMS interoperability rulemaking in the ‘‘Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, state Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federallyfacilitated Exchanges and Health Care Providers’’ final rule (85 FR 25510) (hereinafter referred to as the ‘‘CMS Interoperability and Patient Access final rule’’). This proposed rule emphasizes improving health information exchange E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules and achieving appropriate and necessary access to complete health records for patients, providers, and payers, while simultaneously reducing payer, provider, and patient burden by improving prior authorization processes, and helping to ensure that patients remain at the center of their own care. In this rule, we are proposing to enhance certain policies from the CMS Interoperability and Patient Access final rule, as described below, and add several new proposals to increase data sharing and reduce overall payer, provider, and patient burden through proposed changes to prior authorization practices. ‘‘Prior authorization’’ refers to the process through which a provider must obtain approval from a payer before providing care and prior to receiving payment for delivering items or services. In some programs, this may be referred to as ‘‘pre-authorization’’ or ‘‘pre-claim review.’’ Prior authorization requirements are established by payers to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and is consistent with standards of care before the item or service is provided rather than undertaking that review for the first time when a post-service request for payment is made. We are taking an active approach to move participants in the health care market toward interoperability and reduced burden by proposing policies for the Medicaid program; the Children’s Health Insurance Program (CHIP); and qualified health plan (QHP) issuers on the individual market Federally-facilitated Exchanges (FFEs). For purposes of this proposed rule, references to QHP issuers on the FFEs exclude issuers offering only standalone dental plans (SADPs). Likewise, we are also excluding QHP issuers only offering QHPs in the Federallyfacilitated Small Business Health Options Program Exchanges (FF– SHOPs) from the proposed provisions of this rule. We believe that the proposed standards would be overly burdensome to both SADP and SHOP issuers, as their current enrollment numbers and premium intake from QHP enrollment are unlikely to support the costs of the requirements that this proposed rule would impose, and could result in those issuers no longer participating in the FFEs, which would not be in the best interest of enrollees. We note that, in this proposed rule, FFEs include those Exchanges in states that perform plan management functions. State-based Exchanges on the Federal Platform (SBE–FPs) are not FFEs, even though consumers in these states enroll in VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 coverage through HealthCare.gov, and QHP issuers in SBE–FPs would not be subject to the requirements in this proposed rule. We encourage states operating Exchanges to consider adopting similar requirements for QHPs on the State-based Exchanges (SBEs). In the CMS Interoperability and Patient Access final rule (85 FR 25510), we finalized policies impacting Medicare Advantage organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. The policies finalized in that rule requiring those impacted payers to build and maintain application programing interfaces (APIs) were critical and foundational policies, increasing patient access and data exchange and improving interoperability in health care. In this proposed rule, we are proposing certain policies to expand upon those foundational policies for state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. As further addressed later in this section of the preamble, starting with this payer population is a critical first step for these new proposals. For instance, state Medicaid and CHIP FFS programs were excluded from the payer-to-payer data exchange policies finalized in the CMS Interoperability and Patient Access final rule (85 FR 25564 through 25569). In our first phase of interoperability policy, we chose to limit the burden on these programs so they could focus their attention and resources on implementing the Patient Access and Provider Directory APIs. This proposed rule is a critical step in proposing to require state Medicaid and CHIP FFS programs to similarly exchange patient health information in a more efficient and interoperable way, as discussed in section II.D. of this proposed rule, leveraging the technology and experience gained from implementing the initial set of API policies to these new proposed policies. ‘‘Churn’’ in health care refers to the movement of patients between payers and in and out of health care coverage. Churn occurs when a patient moves between payer types and plans or disenrolls from coverage (voluntarily or involuntarily) for a period of time. Patients enrolled in Medicaid, CHIP, and QHPs in particular may move between and among these payers due to a change in their eligibility status, or a change in the availability of subsidies in the case of QHP enrollees. Medicaid beneficiaries who churn in and out of Medicaid tend to have higher utilization of emergency services. Overall, these PO 00000 Frm 00003 Fmt 4701 Sfmt 4702 82587 patients face more coverage instability than those enrolled in Medicare. Several of the API proposals outlined in this proposed rule would particularly benefit patients enrolled in Medicaid, CHIP, and QHPs by allowing them to retain their health information in an electronic form, and have their health information move with them from payer to payer and provider to provider. Our authority to regulate Medicaid and CHIP FFS, Medicaid and CHIP managed care, and QHP issuers on the FFEs puts us in a unique position to be able to align policies across these programs to the benefit of patients across the nation. Patients enrolled in these programs may churn from payer to payer within a given program, as well as from program to program. For example, a Medicaid enrollee may change eligibility status for Medicaid and enroll with a QHP issuer and back in a given year. For this reason, our API proposals discussed in the following sections are particularly valuable because they allow patients to maintain an electronic copy of their health information (Patient Access API discussed in section II.A.), share data directly with their providers (Provider Access API discussed in section II.B. of this proposed rule), and to bring their health information with them as they move from one payer to another (Payer-to-Payer API discussed in section II.D.), which is especially valuable to patients covered by Medicaid and QHPs who experience churn both within and between programs, and may also experience churn in and out of coverage. While we are not making any proposals for MA organizations at this time, we acknowledge that payers with multiple lines of business may choose to implement these polices for their MA lines of business to support better internal alignment as well as to create more efficiencies and transparency for their patients. Neither the provisions in the CMS Interoperability and Patient Access final rule nor the proposed provisions here would preclude any payer from implementing these proposed policies regardless of whether the payer is directly impacted by the rule. We believe aligning these policies across all payers would benefit all payers alike. However, we do not believe our approach to start with state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs will have a negative impact on patients. We believe these policies would provide a net benefit to these patients, bringing these programs closer in alignment with one another. We are aware that these proposals, if finalized, E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82588 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules would create misalignments between Medicaid and Medicare that could affect dually eligible individuals enrolled in both a Medicaid managed care plan and an MA plan. While we currently do not believe it is necessary to apply these policies to Medicare Advantage organizations at this time, we intend to further evaluate the implementation of these policies to determine whether they would also be appropriate to apply to Medicare Advantage organizations for future rulemaking. In this proposed rule, when we refer to ‘‘impacted payers,’’ we are referring to state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. Throughout this proposed rule, we refer to terms such as ‘‘patient’’, ‘‘consumer’’, ‘‘beneficiary’’, ‘‘enrollee’’, and ‘‘individual.’’ We note that every reader of this proposed rule is a patient and has or will receive medical care at some point in their life. In this proposed rule, we use the term ‘‘patient’’ as an inclusive term, but because we have historically referred to patients using the other terms noted above in our regulations, we use specific terms as applicable in sections of this proposed rule to refer to individuals covered under the health care programs that we administer and regulate. We also note that when we discuss patients, the term includes a patient’s personal representative. Per the privacy regulations issued under the Health Insurance Portability and Accountability Act of 1996 (HIPAA) (Pub. L. 104–191, enacted on August 21, 1996), as modified, at 45 CFR 164.502(g), a personal representative, generally, is someone authorized under state or other applicable law to act on behalf of the individual in making health care-related decisions (such as a parent, guardian, or person with a medical power of attorney).1 A patient’s personal representative could address policies in this proposed rule that require a patient’s action. We also use terms such as ‘‘payer’’, ‘‘plan’’, and ‘‘issuer’’ in this proposed rule. Certain portions of this proposed rule are applicable to state Medicaid FFS programs, state CHIP FFS programs, Medicaid managed care plans (managed care organizations (MCOs)), prepaid inpatient health plans (PIHPs), and prepaid ambulatory health plans (PAHPs)), CHIP managed care entities 1 See OCR guidance regarding personal representatives at https://www.hhs.gov/hipaa/forprofessionals/faq/2069/under-hipaa-when-can-afamily-member/ and https:// www.hhs.gov/hipaa/for-professionals/faq/personalrepresentatives-and-minors/. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 (MCOs, PIHPs, and PAHPs), and QHP issuers on the FFEs. We use the term ‘‘payer’’ in the preamble of this proposed rule as an inclusive term for all these programs and (in the case of plans) plan types, but we also use specific terms as applicable in sections of this proposed rule. We reference ‘‘items and services’’ when discussing prior authorization. Throughout this proposed rule, when we discuss ‘‘items and services,’’ this does not include prescription drugs and/or covered outpatient drugs. We did not include information about prescription drugs and/or covered outpatient drugs in any of the proposals in this rule. Finally, we use the terms ‘‘provider’’ and ‘‘supplier’’ too, as inclusive terms comprising individuals, organizations, and institutions that provide health services, such as clinicians, hospitals, skilled nursing facilities, home health agencies, hospice settings, laboratories, suppliers of durable medical equipment (such as portable X-ray services), community based organizations, etc., as appropriate in the context used. B. Summary of Major Proposals To drive interoperability, improve care coordination, reduce burden on providers and payers, and empower patients, we are proposing several initiatives that would impact state Medicaid FFS programs, Medicaid managed care plans, state CHIP FFS programs, CHIP managed care entities, and QHP issuers on the FFEs. We are also including several Requests for Information (RFIs) to gather information that may support future rulemaking or other initiatives. As with the CMS Interoperability and Patient Access rulemaking, our proposals provide for program requirements to cross-reference technical specifications in HHS regulations codified at 45 CFR part 170; in this rule, ONC is proposing the adoption of certain specified implementation guides (IGs) needed to support the proposed new API policies we are proposing here for impacted payers. In the CMS Interoperability and Patient Access final rule, we required certain payers to implement and maintain standards-based Patient Access and Provider Directory application programming interfaces (APIs).2 The Patient Access API must 2 Impacted payers under that rule include MA organizations, state Medicaid FFS programs, Medicaid managed care plans, state CHIP FFS programs, CHIP managed care entities, and QHP issuers on the FFEs for the Patient Access API. The Provider Directory API requirement applies to all those impacted payers except the QHP issuers on PO 00000 Frm 00004 Fmt 4701 Sfmt 4702 allow patients to easily access their claims and encounter information and a specified sub-set of their clinical information as defined in the US Core for Data Interoperability (USCDI) version 1 data set through third-party applications of their choice (85 FR 25558 through 25559). The Provider Directory API must make provider directory information publicly available to third-party applications (85 FR 25563 through 25564). Additionally, in the same final rule we required certain payers, with the approval and at the direction of a patient, to exchange specified clinical data (specifically the USCDI version 1 data set) through a Payer-to-Payer Data Exchange (85 FR 25568 through 25569). In this proposed rule, we are proposing to enhance the Patient Access API for impacted payers by requiring the use of specific IGs, proposed for adoption by ONC on behalf of HHS, and by proposing payers include information about pending and active prior authorization decisions. In addition, we are proposing to require that impacted payers establish, implement, and maintain a process to facilitate requesting an attestation from a third-party app developer requesting to retrieve data via the Patient Access API that indicates the app adheres to certain privacy provisions. We are also proposing to require these impacted payers to report certain metrics about patient data requests via the Patient Access API quarterly to CMS. In addition, we are proposing to require use of a specific IG for the Provider Directory API. And, we are proposing to extend the patient-initiated Payer-toPayer Data Exchange requirements to state Medicaid and CHIP FFS programs. We also propose to enhance and expand the Payer-to-Payer Data Exchange, and to require this exchange be conducted via a specified Health Level Seven International® (HL7) Fast Healthcare Interoperability Resources® (FHIR)-based API. We are proposing that impacted payers must implement and maintain a Payer-to-Payer API to facilitate the exchange of patient information between impacted payers, both with the approval and at the direction of the patient and when a patient moves from one payer to another as permitted, and in accordance with applicable law. Specifically, we are proposing that impacted payers implement the Payer-to-Payer API in accordance with the specified HL7 FHIR version 4.0.1 IGs, as well as the HL7 the FFEs. The Payer-to-Payer Data Exchange applies to all those impacted payers except state Medicaid and CHIP FFS programs. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules FHIR Bulk Data Access (Flat FHIR) specification, to support exchanging patient data including but not limited to: Adjudicated claims and encounter data (not including cost information), clinical data as defined in the USCDI, and information related to pending and active prior authorization decisions. To better facilitate the coordination of care across the care continuum and in support of a move to value-based care, we are proposing to require that impacted payers implement and maintain a Provider Access API that, consistent with the APIs finalized in the Interoperability and Patient Access final rule (85 FR 25510), utilizes HL7 FHIR version 4.0.1 to facilitate the exchange of current patient data from payers to providers, including adjudicated claims and encounter data (not including cost information), clinical data as defined in the USCDI, and information related to pending and active prior authorization decisions. In an effort to improve patient experience and access to care, we are proposing several policies associated with the prior authorization process that may ultimately reduce burden on patients, providers, and payers. As described in the CMS Interoperability and Patient Access proposed rule published on March 4, 2019 (84 FR 7610, 7613), we partnered with industry stakeholders to build a FHIR-based web service that would enable providers to search documentation and prior authorization requirements for Medicare FFS directly from their electronic health records (EHRs). This has significant potential to decrease the burden associated with providers determining which items and services need a prior authorization and what documentation is needed to submit the prior authorization request. And, this could reduce burden on payers who would receive fewer incomplete prior authorization requests and fewer denied and appealed requests simply as the result of missing or incorrect documentation. In this second phase of interoperability proposals, we are proposing to require impacted payers to implement and maintain a similar prior authorization Documentation Requirement Lookup Service (DRLS) API. To further streamline the process of submitting a prior authorization request, and reduce processing burden on both providers and payers, we are also proposing to require impacted payers to implement and maintain a FHIR-based Prior Authorization Support (PAS) API that would have the capability to accept and send prior authorization requests and decisions, and could be integrated within a provider’s workflow, while VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 maintaining alignment with, and facilitating the use of, HIPAA transaction standards. Provider use of the PAS API would be voluntary and payers may maintain their existing methods for processing prior authorization requests. We are also proposing several policies that would require impacted payers, with the exception of QHP issuers on the FFEs, to respond to prior authorization requests within certain timeframes. And, we are proposing that impacted payers publicly report certain metrics about prior authorization processes for transparency. Finally, on behalf of HHS, the Office of the National Coordinator for Health IT (ONC) is proposing to adopt the implementation specifications described in this regulation at 45 CFR 170.215— Application Programming Interfaces— Standards and Implementation Specifications as standards and implementation specifications for health care operations. ONC is proposing these implementation specifications for adoption by HHS as part of a nationwide health information technology infrastructure that supports reducing burden and health care costs and improving patient care. By ONC proposing these implementation specifications in this way, CMS and ONC are together working to ensure a unified approach to advancing standards in HHS that adopts all interoperability standards in a consistent manner, in one location, for HHS use. Once adopted for HHS use, these specifications would facilitate implementation of the proposed API policies in this rule if finalized. Although Medicare FFS is not directly impacted by this rule, we do note that we are targeting to implement these proposed provisions, if finalized. In this way, the Medicare implementations would conform to the same requirements that apply to the impacted payers under this rulemaking, as applicable, so that Medicare FFS beneficiaries would also benefit. And, we encourage other payers not directly impacted by this rule to join us in moving toward reduced burden and greater interoperability. We are also including several RFIs to gather information that may support future rulemaking or other initiatives. Specifically, we are seeking input for potential future rulemaking on whether patients and providers should have the ability to selectively control the sharing of data in an interoperable landscape. We request comment on whether patients and/or providers should be able to dictate which data elements from a PO 00000 Frm 00005 Fmt 4701 Sfmt 4702 82589 medical record are shared when and with whom. We are additionally seeking comment on how CMS might leverage APIs (or other solutions) to facilitate electronic data exchange between and with behavioral health care providers, and also community based organizations, who have lagged behind other provider types in adoption of EHRs. We are also seeking comment on how to reduce barriers, and actively encourage and enable greater use of electronic prior authorization, particularly among providers who could benefit most by being able to engage in the prior authorization process directly from their workflows. And, we request comment specifically on including an Improvement Activity under the Meritbased Incentive Payment System (MIPS) to support the use of the Prior Authorization Support (PAS) API. We are continually looking for ways to facilitate efficient, effective, and secure electronic data exchange to help ensure timely, better quality, and highly coordinated care. We believe one way to do this is to generally reduce or eliminate the use of facsimile (fax) technology across CMS programs, as possible and appropriate. The use of fax technology limits the ability of the health care sector to reach true interoperability. To work toward this goal and enable electronic data exchange, we request information on how CMS can reduce or eliminate the use of fax technology across programs where fax technology is still in use. Finally, we request information on barriers to adopting standards, and opportunities to accelerate adoption of standards, related to social risk data. We recognize that social risk factors (for example, housing instability and food insecurity) influence patient health and health care utilization. In addition, we understand that providers in valuebased arrangements rely on comprehensive, high-quality social risk data. Given the importance of these data, we look to understand how to better standardize and liberate these data. II. Provisions of the Proposed Rule A. Patient Access API 1. Background Claims and encounter data, used in conjunction with clinical data, can offer a more complete picture of an individual’s health care experience. In the CMS Interoperability and Patient Access final rule (85 FR 25523), we noted examples of how claims data can be used to benefit patients, as well as providers. For example, inconsistent E:\FR\FM\18DEP2.SGM 18DEP2 82590 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 benefit utilization patterns in an individual’s claims data, such as a failure to fill a prescription or receive recommended therapies, can indicate to a provider or a payer that the individual has had difficulty financing a treatment regimen, may require less expensive prescription drugs or therapies, or may need additional explanation about the severity of their condition. Claims data can also include other information that could be used to understand care utilization and create opportunities for future services or care coordination or management. These are a few examples of how access to these data can improve patient care. Patients tend to access care from multiple providers throughout their lifetime, leading to fractured patient health records in which various pieces of an individual’s data are locked in disparate, siloed data systems. With patient data scattered among these segregated systems, it can be challenging for providers to get a clear picture of the patient’s care history, and patients may forget or be unable to provide critical information to their provider during an office visit. This lack of comprehensive patient data can impede care coordination efforts and access to appropriate care. Through the FHIR-based Patient Access API, finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559), we required certain impacted payers to share, among other things, patient claims and encounter data and a sub-set of clinical data with the third-party apps of a patient’s choice so that patients could get their health information in a way that was most meaningful and useful to them. We noted that this FHIR-based API could also allow the patient to facilitate their data moving from their payer to their provider, and discussed the benefits of sharing patient claims and encounter data with providers, which we discuss in more detail in section II.B. of this proposed rule. 2. Enhancing the Patient Access API In the CMS Interoperability and Patient Access final rule that certain payers, specifically MA organizations, state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, must permit third-party applications to retrieve, with the approval and at the direction of a current enrollee, data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221, respectively. We required that the Patient Access API must, at a minimum, make available adjudicated claims (including provider remittances VerDate Sep<11>2014 23:17 Dec 17, 2020 Jkt 253001 and enrollee cost-sharing); encounters with capitated providers; and clinical data, including laboratory results when maintained by the payer. We required that data must be made available no later than one (1) business day after a claim is adjudicated or encounter data are received. And, that these payers make available through the Patient Access API the specified data they maintain with a date of service on or after January 1, 2016. a. Patient Access API Implementation Guides (IGs) When we finalized the Patient Access API, we provided a link to a CMS website that identified IGs and related reference implementations demonstrating use of these IGs available to support implementation (85 FR 25529): https://www.cms.gov/ Regulations-and-Guidance/Guidance/ Interoperability/index. On this website, we provide links and information about certain IGs, including: • HL7 Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) IG: Version STU 1.0.0 to facilitate the exchange of the claims and encounter data; 3 • HL7 FHIR US Core IG: Version STU 3.1.0 or HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG: Version STU 1.0.0 to facilitate the exchange of the clinical information as defined in the USCDI; 4 5 and • HL7 FHIR Da Vinci Payer Data Exchange (PDex) US Drug Formulary IG: Version STU 1.0.1 to facilitate the exchange of current formulary information.6 On this website, we explain how these IGs can help payers meet the requirements of the final rule efficiently and effectively in a way that reduces burden on them and ensures patients are getting timely access to their health information in a way that they can best make use of these data so that they can make informed decisions about their health. Although these IGs were available for payers and third-party app vendors, we did not require payers to 3 HL7 International. (n.d.). Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide Publication (Version) History. Retrieved from https://hl7.org/fhir/us/carinbb/history.html. 4 HL7 International. (n.d.). US Core Implementation Guide (FHIR IG) Publication (Version) History. Retrieved from https://hl7.org/ fhir/us/core/history.html. 5 HL7 International. (n.d.). Da Vinci Payer Data Exchange (FHIR IG) Publication (Version) History. Retrieved from https://hl7.org/fhir/us/davinci-pdex/ history.html. 6 HL7 International. (n.d.). US Drug Formulary (FHIR IG) Publication (Version) History. Retrieved from https://hl7.org/fhir/us/Davinci-drug-formulary/ history.html. PO 00000 Frm 00006 Fmt 4701 Sfmt 4702 use these IGs in the CMS Interoperability and Patient Access final rule. We did not specifically propose these IGs for possible finalizing in the final rule as general practice had been to include such information in subregulatory guidance. However, the June 3, 2019 Azar v. Allina Health Services, 139 S. Ct. 1804 (2019) decision held that under section 1871 of the Act, CMS must undertake notice-and-comment rulemaking for any rule, requirement, or other statement of policy that establishes or changes a ‘‘substantive legal standard’’ for the Medicare Program. IGs are considered a ‘‘substantive legal standard’’ per this decision. As such, we are now officially proposing to finalize these IGs through notice-and-comment rulemaking to ensure that all impacted payers are using these IGs in order to support true interoperability. If these IGs remain optional, there is a chance that the required APIs could be built in such a way that creates misalignment between and among payer APIs and with thirdparty apps. For example, where there is optionality in the technical build of the API, if that optionality is interpreted differently by the payer and a thirdparty app, that app may be unable to access and use the data as needed. By removing this optionality in the technical implementation, we better ensure that the APIs can support true interoperability and facilitate the desired data exchange. Additionally, as these same IGs are proposed for use for other APIs proposed in this rule, it would mean that providers (see section II.B. of this proposed rule) and payers (see section II.D. of this proposed rule) would also not be able to access and use the data as needed if misalignment is introduced during implementation. Proposing these IGs be required removes the current optionality resulting from only suggested use of the IGs, which could be a barrier to interoperability. We are proposing to require these specific IGs for the Patient Access API, by amending 42 CFR 431.60(c)(3)(iii) for state Medicaid FFS programs, 42 CFR 457.730(c)(3)(iii) for state CHIP FFS programs, and 45 CFR 156.221(c)(3)(iii) for QHP issuers on the FFEs. These requirements would be equally applicable to Medicaid managed care plans and CHIP managed care entities based on cross-references to the state Medicaid and CHIP FFS requirements at 42 CFR 438.242(b)(5) for Medicaid managed care plans and 42 CFR 457.1233(d)(2) for CHIP managed care entities. If finalized, beginning January 1, 2023, impacted payers would be required to ensure their APIs are E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules conformant with these IGs (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). The CARIN IG for Blue Button, the PDex IG, and the PDex US Drug Formulary IG are proposed for HHS use at 45 CFR 170.215(c). The US Core IG was adopted by HHS at 45 CFR 170.215(a)(2) in the ONC 21st Century Cures Act final rule. We recognize that while we have proposed to require compliance with the specific IGs noted above, the need for continually evolving IGs typically outpaces our ability to amend regulatory text. Therefore, we propose to amend 431.60(c)(4), 438.242(b)(5), 457.730(c)(4), 457.1233(d)(2), and 45 CFR 156.221(c)(4) to provide that, if finalized, regulated entities would be permitted to use an updated version of any or all IGs proposed for adoption in this rule if use of the updated IG does not disrupt an end user’s ability to access the data through any of the specified APIs discussed in this rule. This would then amend the process to allow payers to use new standards as they are available, as we finalized in the CMS Interoperability and Patient Access final rule to these proposed IGs. In making these proposals, we note that these IGs are publicly available at no cost to a user (see section IV. of this proposed rule for more information). All HL7 FHIR IGs are developed through an industry-led, consensus-based public process. HL7 is an American National Standards Institute (ANSI)-accredited standards development organization. HL7 FHIR standards are unique in their ability to allow disparate systems that otherwise represent data differently and speak different languages to exchange such information in a standardized way that all systems can share and consume via standards-based APIs. HL7 FHIR IGs are also open source, so any interested party can go to the HL7 website and access the IG. Once accessed, all public comments made during the balloting process as well as the IG version history are available for review. In this way, all stakeholders can fully understand the lifecycle of a given IG. Use of IGs developed through such a public process would facilitate a transparent and cost-effective path to interoperability that ensures the IGs are informed by, and approved by, industry leaders looking to use technology to improve patient care. We request comment on these proposals. We finalized in the CMS Interoperability and Patient Access final rule that the Patient Access API at 42 CFR 422.119(b)(1)(iii), 431.60(b)(3), and 457.730(b)(3), and 45 CFR VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 156.221(b)(1)(iii) must make available clinical data, including laboratory results. We specified at 42 CFR 422.119(c)(3)(i), 431.60(c)(3)(i), and 457.730(c)(3)(i), and 45 CFR 156.221(c)(3)(i) that such clinical data must comply with the content and vocabulary standards at 45 CFR 170.213, which is the USCDI version 1. Through a cross-reference to 45 CFR 170.215(a)(2) and (c)(6), at 42 CFR 431.60(c)(3)(iii) for state Medicaid FFS programs, 42 CFR 457.730(c)(3)(iii) for state CHIP FFS programs, and 45 CFR 156.221(c)(3)(iii) for QHP issuers on the FFEs, we propose that payers would be allowed to conform with either the US Core IG or the PDex IG to facilitate making the required USCDI data available via the Patient Access API. In section II.E. of this proposed rule, ONC, on behalf of HHS, proposes to adopt the PDex IG at 45 CFR 170.215(c)(6); currently, the US Core IG is adopted at 45 CFR 170.215(a)(2). These proposed new requirements to conform with either IG would be equally applicable to Medicaid managed care plans and CHIP managed care entities based on crossreferences to the state Medicaid and CHIP FFS requirements at 42 CFR 438.242(b)(5) for Medicaid managed care plans and 42 CFR 457.1233(d)(2) for CHIP managed care entities. When we first finalized the CMS Interoperability and Patient Access final rule and suggested IGs payers could use to implement the APIs, we only suggested the US Core IG; however, some payers informed us that they preferred to leverage the PDex IG because it offered additional resources for payer-specific use cases and was compatible with the US Core IG ensuring interoperable data regardless of which IG was used (see https:// www.cms.gov/Regulations-andGuidance/Guidance/Interoperability/ index for additional information). We seek comment on the pros and cons of requiring the use of either one of these IGs or if only one of the two proposed IGs should ultimately be required and why. b. Additional Information In addition to enhancing the Patient Access API by proposing to require that the API be conformant with the specified IGs, we are also proposing to require that information about prior authorization decisions be made available to patients through the Patient Access API in addition to the accessible content finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559). The primary goal of the Patient Access API is to give patients access to and use of PO 00000 Frm 00007 Fmt 4701 Sfmt 4702 82591 their health information. By ensuring patient access to this additional information, we intend to help patients be more informed decision makers and true partners in their health care. In section II.C. of this proposed rule, we advance a number of proposals focused on making the prior authorization process less burdensome for payers and providers, and in turn, avoiding care delays for patients, which we anticipate would also improve patient outcomes. Patients can only truly be informed if they understand all aspects of their care. We believe that more transparency would help ensure that patients better understand the prior authorization process. By having access to their pending and active prior authorization decisions via the Patient Access API, a patient could see, for instance, that a prior authorization is needed and has been submitted for a particular item or service, and might better understand the timeline for the process and plan accordingly. If a patient can see the supporting documentation shared with their payer they might better understand what is being evaluated and even potentially help providers get the best and most accurate information to payers to facilitate a successful prior authorization request, thus potentially avoiding unnecessary delays in care and reducing burden on providers and payers. As a result, we are proposing to require impacted payers to provide patients access to information about the prior authorization requests made on their behalf through the Patient Access API. Specifically, we are proposing at 431.60(b)(5) for state Medicaid FFS programs, at 438.242(b)(5) for Medicaid managed care plans, at 457.730(b)(5) for state CHIP FFS programs, at 457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(b)(1)(iv) for QHP issuers on the FFEs to require these payers to make available to patients information about any pending and active prior authorization decisions (and related clinical documentation and forms) for items and services via the Patient Access API conformant with the HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG no later than one (1) business day after a provider initiates a prior authorization request or there is a change of status for the prior authorization. We believe one (1) business day is appropriate because in order for patients to have true transparency into the process, they need to see the information timely. As discussed more in section II.C. of this proposed rule, we are proposing expedited prior authorization E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82592 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules timeframes. If this information is provided any later, it would be of less value in supporting the process. We propose that this requirement begin January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023).7 By ‘‘active prior authorization decisions,’’ we mean prior authorizations that are currently open and being used to facilitate current care and are not expired or no longer valid. By ‘‘pending prior authorization decisions,’’ we mean prior authorizations that are under review, either pending submission of documentation from the provider, or being evaluated by the payer’s medical review staff, or for another reason have not yet had a determination made. As discussed in section I.B. of this proposed rule, for the purposes of this rule, when we say ‘‘items and services,’’ we are talking about items and services excluding prescription drugs and/or covered outpatient drugs. And, ‘‘status’’ of the prior authorization means information about whether the prior authorization is approved, denied, or if more information is needed to complete the request. We also note that the required information and documentation through the API would include the date the prior authorization was approved, the date the authorization ends, the units and services approved, and those used to date. Similarly, as further discussed in section II.B. of this proposed rule, we are proposing to require impacted payers to share the same information about prior authorization decisions with a patient’s provider via the Provider Access API upon a provider’s request, and, in section II.D. of this rule, we are proposing that the same information about prior authorization decisions be made available via the Payer-to-Payer API. In this way, if a patient authorizes their new payer to access data from their old payer, this data exchange would include information about pending and active prior authorizations, if such information is applicable. We did not include information about denied or expired prior authorization decisions in this proposed requirement because this could result in a significant amount of information being shared that may or may not be clinically relevant at the moment in time the data are exchanged. Pending and active prior 7 HL7 International. (n.d.). Da Vinci Payer Data Exchange (FHIR IG) Publication (Version) History. Retrieved from https://hl7.org/fhir/us/davinci-pdex/ history.html. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 authorizations are much more likely to be clinically relevant and important for patients, providers, and payers to know in order to support treatment and care coordination, as well as efficient and effective payer operation that can lead to the best possible outcomes for patients. We do note that if a prior authorizations is ‘‘pending,’’ and the status changes to ‘‘denied,’’ that information would be shared as a ‘‘change in status.’’ As a result, a patient would have access to that information via the API per this proposal. We anticipate that requiring payers to share prior authorization information through the Patient Access API, with their patient’s approval and at their direction, might help patients better understand the items and services that require prior authorization, the information being considered and specific clinical criteria being reviewed to determine the outcome of that prior authorization, and the lifecycle of a prior authorization request. This proposed requirement could provide patients with an opportunity to better follow the prior authorization process and help their provider and payer by producing missing documentation or information when needed. The proposed requirement might also help to reduce the need for patients to make repeated calls to the provider and payer to understand the status of a request, or to inquire why there is a delay in care. We therefore believe this proposal would help give patients more agency in their health care journey and reduce burden on both the providers and the payers working through prior authorization requests, allowing them to more simply and efficiently administer the prior authorization process. As with all information being made available via the Patient Access API, we believe industry is in the best position to develop applications, or apps, that patients can use to most effectively use this information, and we look to innovators in industry to produce apps that would help patients understand this information and access it in a way that is useful to them. In addition, we believe it would be highly valuable for payers to share pending and active prior authorization decisions with providers, as proposed in section II.B. of this proposed rule, and other payers, as proposed in section II.D. of this proposed rule. Currently, providers know which prior authorizations they have initiated for a patient, but they may not be able to see pending and active prior authorizations other providers have outstanding or in place for the patient. Having this information could support care PO 00000 Frm 00008 Fmt 4701 Sfmt 4702 coordination and more informed decision making. Additionally, if a new payer has information from a previous payer about pending and active prior authorization decisions, it could support improved care coordination and continuity of care, also potentially improving patient outcomes. We request comment on this proposal. We also request comment for possible future consideration on whether or not impacted payers should be required to include information about prescription drug and/or covered outpatient drug pending and active prior authorization decisions with the other items or services proposed via the Patient Access API, the Provider Access API, or the Payer-to-Payer API. We did not include information about prescription drugs and/or covered outpatient drugs in any of the proposals in this rule. However, we are interested in better understanding the benefits and challenges of potentially including drug information in future rulemaking. For example, what specific considerations should we take into account? Are there unique considerations related to the role Pharmacy Benefit Managers (PBMs) play in this process? Overall, we do think it would be very valuable to payers, providers, and patients to have information about a patient’s prescription drug and/or covered outpatient drug pending and active prior authorization decisions, and we would like to better understand how to most efficiently and effectively consider including this information in these API provisions in the future. c. Privacy Policy Attestation As we discussed in detail throughout the CMS Interoperability and Patient Access final rule, one of the most important aspects of unleashing patient data is protecting the privacy and security of patient health information, especially appreciating that once a patient’s data is received by a thirdparty app, it is no longer protected under HIPAA. Throughout the final rule, we noted the limitations to our authority to directly regulate third-party applications. We previously finalized a provision that payers could deny Patient Access API access to a third-party app that a patient wished to use only if the payer determined that such access would pose a risk to the PHI on their system. See 42 CFR 422.119(e) for Medicare Advantage organizations, 431.60(e) for state Medicaid FFS programs, 438.242(b)(5) for Medicaid managed care plans, 457.730(e) for state CHIP FFS programs, and 45 CFR 156.221(e) for QHP issuers on the FFEs. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules In the ONC 21st Century Cures Act final rule (85 FR 25814 through 25815), ONC noted that it is not information blocking to provide information that is factually accurate, objective, unbiased, fair, and non-discriminatory to inform a patient about the advantages and disadvantages and any associated risks of sharing their health information with a third party. We previously finalized provisions at 42 CFR 422.119(g) for Medicare Advantage organizations, at 431.60(f) for state Medicaid FFS programs, at 438.242(b)(5) for Medicaid managed care plans, at 457.730(f) for state CHIP FFS programs, at 457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(g) for QHP issuers on the FFEs, requiring that impacted payers share educational resources with patients to help them be informed stewards of their health information and understand the possible risk of sharing their data with third-party apps. In response to comments on the CMS Interoperability and Patient Access proposed rule, we noted in the final rule (85 FR 25549 through 25550) commenters’ beliefs that it is a risk when patients do not understand what happens after their data are transmitted to a third-party app and are no longer protected by the HIPAA Rules. Commenters were specifically concerned about secondary uses of data, such as whether or not their data would be sold to an unknown third-party for marketing purposes or other uses. In the final rule, we noted that a clear, plain language privacy policy is the primary way to inform patients about how their information will be protected and how it will be used once shared with a third-party app. Taking into consideration comments indicating strong public support for additional privacy and security measures, we encouraged, but did not require, impacted payers to request an attestation from third-party app developers indicating the apps have certain privacy provisions included in their privacy policy prior to the payer providing the app access to the payer’s Patient Access API (85 FR 25549 through 25550). We are now proposing to make it a requirement that impacted payers request a privacy policy attestation from third party app developers when their app requests to connect to the payer’s Patient Access API. We are proposing at 42 CFR 431.60(g) for state Medicaid FFS programs, at 42 CFR 438.242(b)(5) for Medicaid managed care plans, at 42 CFR 457.730(g) for state CHIP FFS programs, at 42 CFR 457.1233(d)(2) for CHIP managed care entities, and at 45 CFR VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 156.221(h) for QHP issuers on the FFEs that beginning January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023), that impacted payers must establish, implement, and maintain a process for requesting an attestation from a third-party app developer requesting to retrieve data via the Patient Access API that indicates the app adheres to certain privacy provisions. We recognize that there are many ways that an impacted payer could meet this proposed requirement and we do not wish to be overly prescriptive regarding how each payer could implement this process. For instance, a reliable private industry third party may offer a pathway for apps to attest that they have established a minimum set of privacy provisions to be in compliance with this proposed requirement. A payer could work with such an organization to meet this requirement. Or, an impacted payer could establish its own process and procedures to meet this proposed requirement. This process could be automated.8 We believe it is important to allow the market to develop and make available innovative solutions, and we do not look to preclude use of such options and services. Regardless of this proposed flexibility, impacted payers must not discriminate in implementation of this proposed requirement, including for the purposes of competitive advantage. Whatever method a payer might choose to employ to meet this proposed requirement, the method must be applied equitably across all apps requesting access to the payer’s Patient Access API. At a minimum, we propose that the requested attestation include whether: • The app has a privacy policy that is publicly available and accessible at all times, including updated versions, and that is written in plain language,9 and the third-party app developer has affirmatively shared this privacy policy with the patient prior to the patient authorizing the app to access their health information. To ‘‘affirmatively share’’ means that the patient had to take an action to indicate they saw the privacy policy, such as click or check a box or boxes. 8 See Example 1 in ONC’s 21st Century Cures at final rule (85 FR 25816). 9 Plain Language Action and Information Network. (2011, May). Federal Plain Language Guidelines. Retrieved from https:// www.plainlanguage.gov/media/ FederalPLGuidelines.pdf. PO 00000 Frm 00009 Fmt 4701 Sfmt 4702 82593 • The app’s privacy policy includes, at a minimum, the following important information: ++ How a patient’s health information may be accessed, exchanged, or used by any person or other entity, including whether the patient’s health information may be shared or sold at any time (including in the future); ++ A requirement for express consent from a patient before the patient’s health information is accessed, exchanged, or used, including receiving express consent before a patient’s health information is shared or sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction); ++ If an app will access any other information from a patient’s device; and ++ How a patient can discontinue app access to their data and what the app’s policy and process is for disposing of a patient’s data once the patient has withdrawn consent. As we discussed in the CMS Interoperability and Patient Access final rule (85 FR 25550), payers can look to industry best practices, including the CARIN Alliance’s Code of Conduct and the ONC Model Privacy Notice for other provisions to include in their attestation request that best meet the needs of their patient population.10 11 In particular, we believe that explaining certain practices around privacy and security in a patient-friendly, easy-to-read privacy policy would help inform patients about an app’s practices for handling their data. It helps patients understand if and how the app will protect their health information and how they can be an active participant in the protection of their information. Also, as explained in the CMS Interoperability and Patient Access final rule (85 FR 25517), if an app has a written privacy policy and does not follow the policies as written, the Federal Trade Commission (FTC) has authority to take action. We propose that impacted payers must request the third-party app developer’s attestation at the time the third-party app engages the API. Under our proposal, the payer must inform the patient within 24 hours of requesting the attestation from the app developer of the status of the attestation—positive, negative, or no response, with a clear explanation of what each means. The patient would then have 24 hours to respond to this information. For 10 See https://www.carinalliance.com/our-work/ trust-framework-and-code-of-conduct/. 11 See https://www.healthit.gov/topic/privacysecurity-and-hipaa/model-privacy-notice-mpn. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82594 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules instance, if the app developer cannot attest that the app meets these provisions, or if there is no response to the payer’s request for the attestation, the payer can inform the patient there may be risk associated with sharing their health information with the app. The patient may choose to change his or her mind and, at that point, the payer would no longer be obligated to release the patient’s data via the API. However, if the patient does not respond or the patient indicates they would like their information made available regardless, the payer would be obligated to make the data available via the API. The patient would have already authorized the app to access their data, as the request from the payer for an attestation could only happen after the patient has already authorized the app to access their information and provided information about their payer to the app. As a result, the patient’s original request must be honored. Because the patient has already consented to the app receiving their data, it is important that this process not overly delay the patient’s access to their health information via the app of their choice. However, we are interested in comments from the public that discuss this process, and the payer’s obligation to send the data regardless of whether or not the patient responds to the payer after notification of the app’s attestation results, specifically notification if the app does not attest to meeting the above privacy provisions. We believe it is important for patients to have a clear understanding of how their health information may be used by a third party, as well as how to stop sharing their health information with a third party, if they so choose. We believe the use of this required attestation, if finalized as proposed, in combination with patient education,12 would help patients be as informed as possible. Therefore, we propose that the payer must include information about the specific content of their privacy policy provisions included in the attestation in the required enrollee resources. The enrollee resources must also include, at a minimum, the timeline for the attestation process, the method for informing enrollees about the app developer’s attestation response or non-response. The enrollee resources would also have to include the 12 In the CMS Interoperability and Patient Access final rule, we required impacted payers to make available enrollee resources regarding privacy and security on its public website and through other appropriate mechanisms through which it ordinarily communicates with current and former patients at 42 CFR 422.119(g), 42 CFR 431.60(f), 42 CFR 457.30(f), and 45 CFR 156.221(g). VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 enrollee’s role and rights in this process, such as what actions the enrollee may take when a payer informs the enrollee about the status of the attestation, and information about an enrollee’s right to access their data via a third-party app of their choice no matter what the status of the attestation request is. Together, this privacy policy attestation framework and the requirement for payers to provide patients with educational resources would help ensure a more secure data exchange environment and more informed patients. And, this would help build patient trust in apps, therefore encouraging them to take advantage of this opportunity to access their health information through a thirdparty app. Privacy and security remain a critical focus for CMS, and we look forward to continuing to work with stakeholders to keep patient privacy and data security a top priority. Accordingly, we request comment on additional content requirements for the attestation that impacted payers must request and additional required enrollee resources that impacted payers must make available related to the attestation in this proposal. We are particularly interested in hearing feedback on how best to engage available industry-led initiatives, as well as the level of flexibility payers think is appropriate for defining the process for requesting, obtaining, and informing patients about the attestation. For instance, would payers prefer that CMS require the specific types of communication methods payers can use to inform patients about the attestation result, such as via email or text or other electronic communication only? How should CMS account for third-party solutions that present a list of apps that have already attested? In this situation a payer would not need to take action for these apps, but would need to have a process in place for apps not included on such a list. We also request comment on whether the request for the app developer to attest to certain privacy provisions should be an attestation that all provisions are in place, as it is currently proposed, or if the app developer should have to attest to each provision independently. We wish to understand the operational considerations of an ‘‘all or nothing’’ versus ‘‘line-item’’ approach to the attestation for both the app developers and the payers who would have to communicate this information to patients. And, we wish to understand the value to patients of the two possible approaches. We request comment on the proposal to require impacted payers to request a PO 00000 Frm 00010 Fmt 4701 Sfmt 4702 privacy policy attestation from thirdparty app developers. d. Patient Access API Metrics We are proposing to require impacted payers to report metrics about patient use of the Patient Access API to CMS.13 We believe this is necessary to better understand whether the Patient Access API requirement is efficiently and effectively ensuring that patients have the required information and are being provided that information in a transparent and timely way. We would be better able to evaluate whether policy requirements are achieving their stated goals by having access to aggregated, patient de-identified data on the use of the Patient Access API from each payer. With this information, we expect that we would be better able to support payers in making sure patients have access to their data and can use their data consistently across payer types. As a first step in evaluating the adoption of the Patient Access API, we propose to require states operating Medicaid and CHIP FFS programs at the state level, Medicaid managed care plans at the plan level, CHIP managed care entities at the entity level, and QHP issuers on the FFEs at the issuer level to report to CMS. We also seek comment on whether we should consider requiring these data be reported to CMS at the contract level for those payers that have multiple plans administered under a single contract or permit Medicaid managed care plans, CHIP managed care entities, or QHP issuers on the FFEs to aggregate data for the same plan type to higher levels (such as the payer level or all plans of the same type in a program). Specifically, we propose that these payers report quarterly: • The total number of unique patients whose data are transferred via the Patient Access API to a patient designated third-party app; and • The number of unique patients whose data are transferred via the Patient Access API to a patient designated third-party app more than once. Tracking multiple transfers of data would indicate repeat access showing patients are either using multiple apps or are allowing apps to update their information over the course of the quarter. We are proposing these new reporting requirements at 42 CFR 431.60(h) for state Medicaid FFS programs, at 42 CFR 438.242(b)(5) for Medicaid managed 13 We note that the regulation text for QHP issuers on the FFEs in part 156 refers to HHS. In the regulation text for QHPs on the FFEs, we propose the reporting to HHS for consistency, noting that CMS is a part of HHS. E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 care plans, at 42 CFR 457.730(h) for state CHIP FFS programs, at 42 CFR 457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(i) for QHP issuers on the FFEs. Under this proposal, we would redesignate existing paragraphs as necessary to codify the new proposed text. We do not intend to publicly report these data at the state, plan, or issuer level at this time, but may reference or publish them at an aggregate, de-identified level. We are proposing that by the end of each calendar quarter, payers would report the previous quarter’s data to CMS starting in 2023. In the first quarter the requirement would become applicable, payers would be required to report, by the end of the first calendar quarter of 2023, data for the fourth calendar quarter of 2022. Therefore, beginning March 31, 2023 all impacted payers would need to report to CMS the first set of data, which would be the data for October, November, and December 2022. We request comment on this proposal. We are proposing a quarterly data collection. We seek comment on the burden associated with quarterly reporting versus annual reporting, as well as stakeholder input on the benefits and drawbacks of quarterly versus annual reporting. In addition, we request comment on what other metrics CMS might require payers to share with CMS, and potentially the public, on Patient Access API use, so that CMS can consider this information for possible future rulemaking.14 In particular, we seek comment on the potential burden if payers were required to report the names of the unique apps that access the payer’s API each quarter or each year. We are considering collecting this information to help identify the number of apps being developed, potentially review for best practices, and evaluate consumer ease of use. e. Patient Access API Revisions We note that to accommodate the proposed requirements regarding the use of the Patient Access API, we are proposing two minor changes to the requirements finalized in the CMS Interoperability and Patient access final rule. First, we are proposing to revise language about the clinical data to be made available via the Patient Access API 42 CFR 431.60(b)(3) for state Medicaid FFS programs, 42 CFR 457.730(b)(3) for state CHIP FFS 14 We note that the regulation text for QHP issuers on the FFEs in Part 156 refers to HHS. In the regulation text for QHP issuers on the FFEs, we propose the reporting to HHS for consistency, noting that CMS is a part of HHS. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 programs, and 45 CFR 156.221(b)(1)(iii) for QHP issuers on the FFEs. In the CMS Interoperability and Patient Access final rule, these specific provisions require payers to make available ‘‘clinical data, including laboratory results.’’ We are proposing to revise these paragraphs to read, ‘‘clinical data, as defined in the USCDI version 1.’’ Lab results are part of the USCDI, and clinical data were operationalized as the USCDI version 1 under the ‘‘technical requirements’’ where the content standard at 45 CFR 170.213 is adopted. Specifically calling out the USCDI here would help avoid unnecessary confusion, as it would be explicitly noted that the clinical data that must be available through the Patient Access API is the USCDI version 1 data elements. Second, we are proposing to revise the language previously finalized for denial or discontinuation of access to the API to require that the payer make such a determination to deny or discontinue access to the Patient Access API using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which parties seek EHI. We are proposing to change the terms ‘‘enrollees’’ and ‘‘beneficiaries’’ to ‘‘parties’’ as we are proposing to apply this provision to the Provider Access API, Payer-to-Payer API, and the prior authorization APIs discussed further in sections II.B., II.C., and II.D. of this proposed rule. As other parties may be accessing these APIs, such as providers and payers, we believe it is more accurate to use the term ‘‘parties’’ rather than ‘‘enrollees’’ or ‘‘beneficiaries.’’ We are proposing these revisions 431.60(e)(2), 457.730(e)(2), and 45 CFR 156.221(e)(2). We request comment on these proposals. Although Medicare FFS is not directly impacted by this rule, we do note that we are targeting to implement the provisions, if finalized. In this way, the Medicare FFS implementation would conform to the same requirements that apply to the impacted payers under this rulemaking, so that Medicare FFS beneficiaries would also benefit from this data sharing. CMS started to liberate patients’ data with Blue Button 2.0, which made Parts A, B, and D claims data available via an API to Medicare beneficiaries. In an effort to align with the API provisions included in the CMS Interoperability and Patient Access final rule, we are updating the Blue Button 2.0 API to FHIR R4, and will begin use of the CARIN IG for Blue Button.15 If the 15 https://bluebutton.cms.gov/blog/FHIR-R4coming-to-the-blue-button-api.html. PO 00000 Frm 00011 Fmt 4701 Sfmt 4702 82595 provisions in this rule are finalized, we will work to align and enhance Blue Button accordingly, as possible. f. Provider Directory API Implementation Guide We are also proposing to require that the Provider Directory API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25563 through 25564) be conformant with a specified IG. The Provider Directory API provision requires impacted payers to ensure provider directory information availability to third-party applications. Specifically, payers need to make, at a minimum, provider names, addresses, phone numbers, and specialties available via the public-facing API. All directory information must be available through the API within 30 calendar days of a payer receiving the directory information or an update to the directory information. We are proposing a new requirement at 42 CFR 431.70(d) for Medicaid state agencies, and at 42 CFR 457.760(d) for CHIP state agencies that the Provider Directory API be conformant with the implementation specification at 45 CFR 170.215(c)(8) beginning January 1, 2023. Therefore, we are proposing that the Provider Directory API be conformant with the HL7 FHIR Da Vinci PDex Plan Net IG: Version 1.0.0.16 Currently, because QHP issuers on the FFEs are already required to make provider directory information available in a specified, machinereadable format, the Provider Directory API proposal does not include QHP issuers.17 Currently, because of the existing cross-references at 42 CFR 438.242(b)(6) (cross referencing the Medicaid FFS Provider Directory API requirement at 42 CFR 431.70) and 42 CFR 457.1233(d)(3) (cross referencing the CHIP FFS Provider Directory API requirement at 42 CFR 457.760), Medicaid managed care plans and CHP managed care entities must also implement and maintain Provider Directory APIs. We are proposing here that Medicaid managed care plans and CHIP managed care entities must comply with the implementation specification at 45 CFR 170.215(c)(8) (that is, the HL7 FHIR Da Vinci PDex Plan Net IG: Version 1.0.0) by the rating period that begins on or after January 1, 2023. Because of the different compliance deadline for the managed care programs, we are also proposing 16 HL7 International. (n.d.). Da Vinci Payer Data Exchange PlanNet (FHIR IG) Publication (Version) History. Retrieved from https://www.hl7.org/fhir/us/ davinci-pdex-plan-net/history.cfml. 17 Available at https://cmsgov.github.io/QHPprovider-formulary-APIs/developer/. E:\FR\FM\18DEP2.SGM 18DEP2 82596 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules additional revisions at 42 CFR 438.242(b)(6) and 42 CFR 457.1233(d)(3). We request comment on these proposals. khammond on DSKJM1Z7X2PROD with PROPOSALS2 3. Statutory Authorities for the Patient Access and Provider Directory API Proposals a. Medicaid and CHIP For the reasons discussed below, our proposed requirements in this section for Medicaid managed care plans and Medicaid state agencies fall generally under our authority in section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. The proposals in this section are also authorized under section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Additionally, they are authorized by section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. We are proposing to require that state Medicaid agencies and Medicaid managed care plans implement the Patient Access and Provider Directory APIs finalized in the CMS Interoperability and Patient Access final rule conformant with specific IGs, as discussed in section II.A.2. above in this proposed rule. In sections II.B.3., II.B.5., II.C.3., II.C.4., and II.D.2. of this proposed rule, we are also proposing that these payers be required to implement new APIs, specifically the Provider Access APIs, the DRLS API, the PAS API, and the Payer-to-Payer API, in a manner that is conformant with specific IGs. Use of these APIs would support more efficient administration of the state plan, because, as discussed in more detail below, CMS expects that the APIs would improve the flow of information relevant to the provision of Medicaid services among beneficiaries, providers, and the state Medicaid program and its contracted managed care plans. Improving the flow of that information could also help states to ensure that Medicaid services are provided with reasonable promptness and in a manner consistent with simplicity of administration and the best interests of the beneficiaries, as discussed in the CMS Interoperability and Patient Access final rule related to the Patient Access and Provider Directory APIs and the VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 Payer-to-Payer data exchange (for Medicaid managed care) (see 85 FR 25526). The state is also required to make provider directory data for the FFS program available per section 1902(a)(83) of the Act; Medicaid managed care plans are similarly required to make a provider directory available under 42 CFR 438.10(g). Making provider directory information available via a standards-based API, and updating this information through this API, again adds efficiencies to administration of this process and our proposal here is intended to further standardize implementation of the Provider Directory API. The DRLS API and the PAS API both have the potential to significantly improve the efficiency and response time for Medicaid prior authorization processes, making them more efficient in many ways, including limiting the number of denials and appeals or even eliminating requests for additional documentation. In all of these ways, the APIs are expected to make administration of the Medicaid program more efficient. Proposing to require these APIs be conformant with specific IGs is expected to simplify the process of implementing and maintaining each API, including preparing the information that must be shared via each specific API, and ensuring data are provided as quickly as possible to beneficiaries (in the case of the Patient Access API and the Provider Directory API), to providers (in the case of the Provider Access API), and to other payers (in the case of the Payer-to-Payer API). Implementing these APIs across payers using the same IGs, as would be the case via the Payer-to-Payer API, would ensure these APIs are functioning as intended, and are able to perform the data exchanges specified in a way that is interoperable and of value to both the sender and receiver of the information, and thus could help to ensure the APIs would improve the efficient operation of the state Medicaid program, consistent with section 1902(a)(4) of the Act. These IGs, by further ensuring that each API is built and implemented in a consistent and standardized way, transmitting data that are mapped and standardized as expected by both the sending and receiving parties, would further increase the efficiency of the APIs. It would help ensure that the data sent and received are usable and valuable to the end user, whether that is the patient looking to have timely access to their records or the provider or payer looking to ensure efficient care and increased care coordination to support the timely administration of services. As a result, PO 00000 Frm 00012 Fmt 4701 Sfmt 4702 proposing to adopt these IGs would further contribute to proper and efficient operation of the state plan, and is expected to facilitate data exchange in a way that is consistent with simplicity of administration of the program and the best interest of the participants. Requiring that the APIs be conformant with these IGs is therefore expected to make the APIs more effective in terms of improving the efficient operation of the Medicaid state plan and Medicaid managed care plans. If the APIs operate more efficiently, that, in turn, may help to ensure that beneficiaries and enrollees receive care with reasonable promptness and in a manner consistent with simplicity of administration and beneficiaries’ and enrollees’ best interests. The proposed requirement to make available information about pending and active prior authorization decisions and associated documentation through the Patient Access API is expected to allow beneficiaries to more easily obtain the status of prior authorization requests submitted on their behalf, so that they could ultimately use that information to make more informed decisions about their health care, improve the efficiency of accessing and scheduling services, and if needed, provide missing information needed by the state to reach a decision. Receiving missing information more quickly could allow states to respond more promptly to prior authorization requests, thus improving providers’ and beneficiaries’ experience with the process by facilitating more timely and successful prior authorizations, which would help states fulfill their obligations to provide care and services in a manner consistent with simplicity of administration and the best interests of the recipients, and to furnish services with reasonable promptness to all eligible individuals. Improving the prior authorization process could also help states improve the efficient operation of the state plan. In these ways, these proposals are consistent with our authorities under section 1902(a)(4), (8), and (19) of the Act. We also propose that payers would be required to ask app developers to attest to whether they have certain privacy policy provisions in place prior to making a beneficiary’s or enrollee’s data available via the Patient Access API. Proposing to require state Medicaid agencies and Medicaid managed care plans to implement a privacy policy attestation process is expected to help ensure beneficiaries be informed about how their information would be protected or not protected when it is provided by the state Medicaid agency E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules or Medicaid managed care plan to a third-party app at their request. This attestation process is expected to help a beneficiary or enrollee better understand how their data would be used, and what they can do to further control how and when their data is shared by other entities associated with the app. Taking additional steps to protect patient privacy and security would help to ensure that the Medicaid program, whether through FFS or managed care, is providing Medicaidcovered care and services in a manner consistent with the best interests of beneficiaries and enrollees. In this way, it is within our authority under section 1902(a)(19) of the Act to propose to require this privacy policy attestation. We are also proposing to require state Medicaid agencies and Medicaid managed care plans to report Patient Access API metrics to CMS quarterly. We believe that having these metrics would support CMS’ oversight, evaluation, and administration of the Medicaid program, as it would allow us to evaluate beneficiary and enrollee access to the Patient Access API. Use of the API could indicate that the policy is supporting program efficiencies and ensuring access to information in a timely and efficient way and in the best interest of beneficiaries, as intended. Section 1902(a)(6) of the Act authorizes CMS to request reports in such form and containing such information as the Secretary from time to time may require. These metrics would serve as a report to evaluate the implementation and execution of the Patient Access API. For CHIP, we propose these requirements under the authority in section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, lowincome children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision provides us with authority to adopt these requirements for CHIP because the proposed requirements increase access to patient data, which can improve the efficacy of CHIP programs, allow for more efficient communication and administration of services, and promote coordination across different sources of health benefits coverage. As discussed above for Medicaid programs, requiring that the APIs finalized in the CMS Interoperability and Patient Access final rule, as well as those APIs proposed in this rule, be conformant with specific IGs would support program efficiency. By ensuring that these APIs are implemented in a consistent, standardized way, use of the VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 IGs is expected to help support patient, provider, and payer access to data they can best use to make informed decisions, support care coordination, and for the state, support efficient operations. We believe that requiring CHIP agencies, as well CHIP managed care entities, to make CHIP enrollees’ prior authorization data and other standardized data available through standards-based APIs would ultimately lead to these enrollees accessing that information in a convenient, timely, and portable way. This improved access would help to ensure that services are effectively and efficiently administered in the best interests of beneficiaries, consistent with the requirements in section 2101(a). We believe making patient data available in this format would result in better health outcomes and patient satisfaction and improve the cost effectiveness of the entire health care system, including CHIP. Allowing beneficiaries or enrollees easy and simple access to certain standardized data can also facilitate their ability to detect and report fraud, waste, and abuse—a critical component of an effective program. These proposals align with section 2101(a) in that they also improve the efficiency of CHIP programs. For example, adding information about pending and active prior authorization decisions to the Patient Access API allows beneficiaries to easily obtain the status of prior authorization requests made on their behalf. This allows patients to make scheduling decisions, and provide any missing information needed by a payer to reach a decision, which makes the prior authorization process more efficient, ultimately streamlining the prior authorization process. Additionally, proposing to require the CHIP programs (FFS and managed care) to put a process in place to ask thirdparty app developers to attest to whether they have certain privacy provisions in place would allow CHIP to provide services in a way that is in the beneficiary’s best interest by providing additional information to them about how they can best protect the privacy and security of their health information. Finally, proposing to require state CHIP agencies and CHIP managed care plans report Patient Access API metrics to CMS quarterly would help states and CMS understand how this API can be used to continuously improve the effectiveness and efficiency of state CHIP operations by providing information about its use, which is an indication of the effectiveness of the API. The more we understand about the PO 00000 Frm 00013 Fmt 4701 Sfmt 4702 82597 use of the Patient Access API, the better we can assess that the API is leading to improved operational efficiencies and providing information to beneficiaries in a way that supports their best interests. Regarding the requiring the use of the PlanNet IG for the Provider Directory API under CHIP, we note that 42 CFR 457.1207 requires CHIP managed care entities to comply with the provider directory (and other information disclosure) requirements that apply to Medicaid managed care plans under 42 CFR 438.10. b. QHP Issuers on the FFEs For QHP issuers on the FFEs, we propose these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. Existing and emerging technologies provide a path to make information and resources for health care and health care management universal, integrated, equitable, more accessible, and personally relevant. Requiring the APIs discussed in this rule, including the Patient Access API, the Provider Access API, the DRLS API, the PAS API, and the Payer-to-Payer API be conformant with specific IGs would permit QHP issuers on the FFEs to meet the proposed requirements of this rulemaking efficiently by simplifying the process of implementing and maintaining each API, including preparing the needed information to be shared via each specific API, and ensuring data, and ultimately services, are provided to enrollees as quickly as possible. These IGs, by further ensuring that each API is built and implemented in a consistent and standardized way, transmitting data that are mapped and standardized as expected by both the sending and receiving parties, would further increase the efficiency of the APIs. It would help ensure that the data sent and received are usable and valuable to the end user, whether that is the patient looking to have timely access to their records or the provider or payer looking to ensure efficient care and increased care coordination to support the timely administration of services. This could add significant operational efficiencies for QHP issuers on the FFEs. This would help each proposed policy be most effective, the API solutions to be truly interoperable, and for QHP issuers on the FFEs to meet E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82598 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules these requirements in a way that ensures enrollees’ needs are best met. We believe generally that certifying only health plans that take steps to make enrollees’ pending and active prior authorization decisions and related clinical documentation available through interoperable technology would ultimately lead to these enrollees having access to that information in a convenient, timely, and portable way, which is in the best interests of enrollees. Having simple and easy access, without special effort, to their health information also facilitates enrollees’ ability to detect and report fraud, waste, and abuse—a critical component of an effective program. Adding information about pending and active prior authorization decisions to the Patient Access API would allow enrollees to easily obtain the status of prior authorization requests submitted on their behalf and use that information effectively to make more informed decisions about their health care, improve the efficiency of accessing and scheduling services, and if needed, provide missing information needed by the issuer to reach a decision. This could allow QHP issuers on the FFEs to more promptly address prior authorization requests, streamlining this process, and thus simplifying prior authorization processes, and enrollees’ experience with the process, by facilitating timelier and potentially more successful initial prior authorization requests. We encourage State-based Exchanges (SBEs) to consider whether a similar requirement should be applicable to QHP issuers. Proposing to require QHP issuers on the FFEs to implement a privacy policy attestation process would ensure enrollees are informed about how their information would be protected and how it would be used, and would add an additional opportunity for issuers to promote the privacy and security of their enrollees’ information. This again ensures enrollees’ needs are best met. Finally, proposing to require QHP issuers on the FFEs report Patient Access API metrics to CMS quarterly would help CMS understand the impact this API is having on enrollees and would inform how CMS could either enhance the policy or improve access or use through such things as additional consumer education. These data could help CMS understand how best to leverage this API, and consumer access to it, to ensure this requirement is being met efficiently and adding value to CMS operations, including leading to the efficiencies intended. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 B. Provider Access APIs 1. Background As mentioned in the CMS Interoperability and Patient Access final rule, the Patient Access API (85 FR 25558 through 25559) could allow the patient to facilitate their data being accessible to their provider. A patient could use their mobile phone during a visit with their provider to show the provider their data to help inform their discussion. In the CMS Interoperability and Patient Access final rule (85 FR 25555), we discussed the benefits of sharing patient health information with providers. We also encouraged payers to consider an API solution to allow providers to access patient health information through payer APIs, such as for treatment purposes, and received comments in support of this type of data exchange. We sought comment for possible consideration in future rulemaking on the feasibility of providers being able to request information on a shared patient population using a standards-based API. Among the comments we received, some comments stated that allowing providers to receive data directly from payers would allow the FHIR-based data exchange to be significantly more valuable for patients, providers, and payers, as the data would be available at the moment of care when providers need it most, affording patients the maximum benefit from the data exchange. We also received some comments that having providers receive information about prior authorization decisions would reduce burden on providers and their staff (85 FR 25541). While the use of the Patient Access API is a significant first step in facilitating sharing individual patient health information, we believe the benefits of making patient data available via a standards-based API would be greatly enhanced if providers had direct access to their patients’ data. As discussed later in this section we are now working to get providers direct access to data through certain CMS programs, and based on this experience to date, we believe it would benefit providers if they were allowed ongoing access to information about their patients, particularly if they could access that information directly from clinical workflows in their EHRs or other health IT systems. We further believe provider access to patient information would improve both the provider and patient experience. Ensuring that providers have access to comprehensive patient data at the point of care could potentially reduce the burden on patients to recall certain PO 00000 Frm 00014 Fmt 4701 Sfmt 4702 information during an appointment, and might provide an additional way for both the provider and patient to confirm that the patient’s recollection of a prior care episode is accurate. If providers could access information about the care their patient received outside of the provider’s care network prior to a patient’s visit, the information might improve clinical efficiency and provide a more comprehensive understanding of the patient’s health, thus potentially saving time during appointments and potentially improving the quality of care delivered. While we have no data, we anticipate that putting patient data in the hands of the provider at the point of care would reduce provider burden and improve patient care. Providers would be empowered to view their patient’s claims history and available clinical data, including the identity of other providers who are working, or have worked, with the patient. This proposal might also improve a patient’s care experience as it may lessen the burden on patients not only in relation to recall, as noted above, but it may spare patients from having to fill out the same medical history forms repeatedly. Used wisely, the data available to providers under these proposals might give patients and providers more time to focus on the patient’s needs. In addition, if a patient’s entire care team has access to the same information, this may help improve the efficiency and effectiveness of patient care. 2. HIPAA Disclosures and Transaction Standards As reflected in our proposals below, providers would be allowed to request the claims and encounter data for patients to whom they provide services for treatment purposes. The HIPAA Privacy Rule, at 45 CFR 164.502, generally permits a covered entity to use or disclose protected health information (PHI) for treatment, payment, or health care operations without individual authorization. Covered entities must reasonably limit their disclosures of, and requests for, PHI for payment and health care operations to the minimum necessary to accomplish the intended purpose of the use, disclosure, or request (45 CFR 164.502(b)). However, covered entities are not required to apply the minimum necessary standard to disclosures to or requests by a health care provider for treatment purposes (45 CFR 164.502(b)(2)(i)).18 18 See, Office for Civil Rights. (2013, July 26). Uses and Disclosures for Treatment, Payment, and Health Care Operations (45 CFR 164.506). Retrieved from https://www.hhs.gov/hipaa/for-professionals/ E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules HIPAA also identifies specific transactions for which the Secretary must adopt standards and specifies a process for updating those standards. A HIPAA transaction is an electronic exchange of information between two parties to carry out financial or administrative activities related to health care (for example, when a health care provider sends a claim to a health plan to request payment for medical services). Under HIPAA, HHS has adopted multiple standards for transactions involving the exchange of electronic health care data, including: • Health care claims or equivalent encounter information. • Health care electronic funds transfers (EFT) and remittance advice. • Health care claim status. • Eligibility for a health plan. • Enrollment and disenrollment in a health plan. • Referrals certification and authorization. • Coordination of benefits. • Health plan premium payments. • Medicaid pharmacy subrogation. We note that the HHS Secretary has not adopted an applicable HIPAA transaction standard for communications of claims or encounter data that are not sent for the purpose of requesting payment. Although our proposals detailed below would facilitate payers sharing claims data with providers, this would not be done for the purpose of obtaining (or making) payment (as described under 45 CFR 162.1101(a)). We are not proposing to report health care encounters in connection with a reimbursement contract that is based on a mechanism other than charges or reimbursement rates for specific services (as described under 45 CFR 162.1101(b)). Therefore, the use of a HIPAA transaction standard is not required for our proposals in this section, or for our proposals regarding data sharing in sections II.C. and II.D. of this proposed rule, because the Secretary has not adopted a HIPAA transaction applicable to communications of claims or encounter information for a purpose other than requesting payment.19 In this section, we propose to require that certain payers implement a standards-based Provider Access API that makes patient data available to providers both on an individual patient basis and for one or more patients at once using a bulk specification, as permitted by applicable law, so that providers could use data on their privacy/guidance/disclosures-treatment-paymenthealth-care-operations/. 19 See 45 CFR 162.923(a). VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 patients for such purposes as facilitating treatment and ensuring their patients receive better, more coordinated care. As noted, the HIPAA Privacy Rule generally permits HIPAA covered entities to use and disclose PHI for these purposes without need of an individual’s authorization.20 However, under other federal, state, local, or tribal laws (for example, the ‘‘part 2’’ regulations addressing substance use disorder data at 42 CFR part 2), payers and providers may need to obtain some specified form of patient consent to request or disclose behavioral health, certain substance use disorder treatment, or other sensitive healthrelated information, or they may have to use specified transactions to carry out certain defined data transfers between certain parties for specific purposes. We note these proposals do not in any way alter a payer’s or a provider’s obligations under all existing federal, state, local, or tribal laws. 3. Proposed Requirements for Payers: Provider Access API for Individual Patient Information Access In the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559), we required impacted payers to make certain health information available to third–party apps with the approval and at the direction of a patient though the Patient Access API for patient use. We believe there would be value to providers having access to the same patient data through a FHIR-based API that allows the provider to request data for a single patient as needed. And, we recognize that the impacted payers under this proposed rule will have largely prepared the necessary infrastructure and implemented the FHIR standards to support the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) by January 1, 2021 (for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2021). As a result, we are now proposing to require impacted payers to implement a Provider Access API. Both this proposed Provider Access API and the Patient Access API would facilitate the FHIR-based exchange of claims and encounter data, as well as the same set of clinical data as defined in the USCDI version 1, where such clinical data are maintained by the payer, and formulary data or preferred drug list data, where applicable. Both APIs also require the sharing of pending and active prior authorization decisions (and related clinical documentation and 20 See PO 00000 45 CFR 164.506. Frm 00015 Fmt 4701 Sfmt 4702 82599 forms) for items and services. One difference is that the Provider Access API would not include remittances and beneficiary cost-sharing information. Another key difference is that in the case of the Provider Access API proposals, the provider, not the patient, requests and ultimately receives the patient’s information, and would typically make such a request for treatment or care coordination purposes. Where a patient would receive this data via a third-party app for use on a mobile device, in the case of the Provider Access API, the provider would receive the data directly from the payer and incorporate it into their EHR or other practice management system. Through a proposed cross-reference to the Patient Access API requirements, the Provider Access API also requires adherence to the same technical standards, API documentation requirements, and discontinuation and denial of access requirements. For a complete discussion of these requirements, we refer readers to the CMS Interoperability and Patient Access final rule (85 FR 25526 through 25550) and to section II.A. of this proposed rule. We are proposing two approaches to the Provider Access API. First, we are proposing a Provider Access API that allows providers to have access to an individual patient’s information. Second, we are proposing that the Provider Access API allow access to multiple patients’ information at the same time; this is discussed in section II.B.5. of this proposed rule. The individual request approach may be better suited for situations such as, but not limited to, when the provider needs ‘‘real-time’’ access to a patient’s data prior to or even during a patient visit or for small practices with limited server bandwidth. In these situations, providers may wish to gain access to patient data through an API that yields the data through an individual patient request. To support this individual patient use case, we are proposing to require state Medicaid and CHIP FFS programs at 42 CFR 431.61(a)(1)(i) and 457.731(a)(1)(i) respectively; and QHP issuers on the FFEs at 45 CFR 156.222(a)(1)(i), to implement and maintain a Provider Access API conformant with the requirements at 45 CFR 170.215, as detailed in section II.A.2. of this proposed rule for the Patient Access API. This proposed Provider Access API would leverage the same IGs in the same way as proposed for the Patient Access API. These requirements would be equally applicable to Medicaid managed care plans and CHIP managed care E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82600 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules entities based on cross-references to the state Medicaid and CHIP FFS requirements at 42 CFR 438.242(b)(7) for Medicaid managed care plans other than Non-Emergency Medical Transportation (NEMT) PAHPs 21 and 42 CFR 457.1233(d)(4) for CHIP managed care entities. We propose that payers implement this Provider Access API individual patient data approach for data maintained by the payer with a date of service on or after January 1, 2016 by January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). We note that providers may or may not have a provider agreement with or be inor out-of-network with the payer that is providing the information, as we believe providers should have access to their patients’ data regardless of their relationship with the payer. Therefore, our proposal does not permit a payer to deny use of or access to the Provider Access API based on whether the provider using the API is under contract with the payer. A provider that is not in network would need to demonstrate to the patient’s payer that they do have a care relationship with the patient. In the context of Medicaid managed care, we are proposing that NEMT PAHPs, as defined at 42 CFR 438.9(a), would not be subject to the requirement to establish a Provider Access API. MCOs, PIHPs, and non-NEMT PAHPs are subject to this proposed rule. We believe that the unique nature and limited scope of the services provided by NEMT PAHPs is not consistent with the proposed purposes of the Provider Access API proposed at 42 CFR 431.61(a). Specifically, we do not believe that providers have any routine need for NEMT data nor that having NEMT PAHPs implement and maintain a Provider Access API would help achieve the goals of the proposal, namely to help avoid patients needing to recall prior services, ensure that providers are able to spend time with patients focusing on care versus collecting redundant information, or improve patient care through enhanced care coordination. However, we include NEMT PAHPs in the scope of some of our other requirements that apply to all other Medicaid managed care plans under proposed 42 CFR 438.242(b)(5) through (8). Currently, NEMT PAHPs are exempt from compliance with requirements in 42 CFR part 438 unless the provision is listed in § 438.9(b), which does currently apply 42 CFR 438.242 to NEMT PAHPs. We are therefore proposing to revise 42 CFR 21 See 42 CFR 438.9(b)(7). VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 438.9(b)(7) to require compliance with the requirements in 42 CFR 438.242(b)(5) through (8) other than the reference to 42 CFR 431.61(a) and (c) at 438.242(b)(7). We request public comment on this proposal for impacted payers to implement a Provider Access API for individual patient information access. 4. The MyHealthEData Initiative Experience With Sharing Patient Data With Providers Understanding the benefits of provider access to patient information discussed above, as part of the MyHealthEData initiative, we launched the Beneficiary Claims Data API (BCDA), which enables Accountable Care Organizations (ACOs) participating in the Shared Savings Program to retrieve Medicare Part A, Part B, and Part D claims data for their prospectively assigned or assignable beneficiaries.22 To better facilitate the coordination of care across the care continuum and in support of a move to value-based care, the BCDA utilizes the HL7 FHIR Bulk Data Access (Flat FHIR) specification to allow us to respond to requests for large amounts of patientlevel Medicare FFS claims data on behalf of ACO participating practices.23 Using a bulk data exchange reduces burden for ACOs and CMS, and adds a number of efficiencies for ACOs and their participating practices by facilitating the exchange of data for many patients at once. It also gets data to providers when and where they need it most. In addition, in July 2019, we announced a pilot program called ‘‘Data at the Point of Care’’ (DPC) 24 in support of our mission to transform the health care system. Also part of the MyHealthEData initiative, DPC— utilizing the HL7 FHIR Bulk Data Access (Flat FHIR) specification— allows health care providers to access synthetic Medicare FFS claims data, either by integrating with their EHR or with the health IT system they utilize to support care, without requiring access to other applications. Currently, approximately 1,000 organizations representing over 130,000 providers have engaged with the synthetic data in the pilot. Participants include a diversity of practice types including primary care practices, single or small 22 Centers for Medicare and Medicaid Services. (n.d.). Beneficiary Claims Data API. Retrieved from https://bcda.cms.gov/. 23 HL 7 International. (n.d.). FHIR Bulk Data Access (Flat FHIR). Retrieved from https://hl7.org/ fhir/uv/bulkdata/history.html. 24 Data at the Point of Care. (n.d.). Retrieved from https://dpc.cms.gov/. PO 00000 Frm 00016 Fmt 4701 Sfmt 4702 office specialist practices, academic medical centers, non- and for-profit health systems, and dialysis centers. The provider organization is the official demonstration participant, but each organization is taking part with its EHR vendor. Both BCDA and DPC have started to demonstrate the value of exchanging data on multiple patients at once via FHIR. The HL7 FHIR Bulk Data Access (Flat FHIR) specification can reduce the number of API requests and support a secure connection for third-party application access to specified data stored in EHRs and data warehouse environments.25 CMS has developed our projects leveraging the HL7 FHIR Bulk Data Access (Flat FHIR) specification using open source programming. The documentation, specifications, and reference implementations are available at https:// github.com/CMSgov/bcda-app and https://github.com/CMSgov/dpc-app. When leveraged, the HL7 FHIR Bulk Data Access (Flat FHIR) specification permits the efficient retrieval of data on entire patient populations or defined cohorts of patients via the bulk transfer of data using standard data exchanges. Providers who are responsible for managing the health of multiple patients may need to access large volumes of data. Exchanging patient data for large numbers of patients may require large exports, which would usually require multiple requests and a number of resources to manage the process that can overburden organizations and be time consuming and costly. Even using more efficient methods of data exchange like secure APIs can present challenges for a large number of patient records. For example, for a health system with thousands of Medicaid patients, accessing those patients’ claims data one by one would require thousands of API calls.26 We believe that providing a streamlined means of accessing this information via FHIR-based APIs utilizing the HL7 FHIR Bulk Data Access (Flat FHIR) specification greatly improves providers’ ability to deliver quality, value-based care, and ultimately better manage patient health. 25 Office of the National Coordinator, Computational Health Informatics Program, & Boston Children’s Hospital. (2017, December 15). The Intersection of Technology and Policy: EHR Population Level Data Exports to Support Population Health and Value. Retrieved from https://smarthealthit.org/an-app-platform-forhealthcare/meetings/bulk-data-export-meeting-andreport/. 26 A ‘call’ is an interaction with a server using an API to deliver a request and receive a response in return. E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 5. Proposed Requirements for Payers: Bulk Data Provider Access API We believe that the benefits of data sharing would be greatly enhanced if other payers were sharing health information about their patients with health care providers for multiple patients at once, as CMS is now beginning to do under BCDA and as we are also further testing through the DPC pilot, for instance. As a result, we are proposing a second approach to require impacted payers to implement payer-toprovider data sharing using the HL7 FHIR Bulk Data Access (Flat FHIR) specification—a Bulk Data Provider Access API. Given the many benefits of giving providers efficient access to their patients’ data, and the relative ease of doing so by leveraging the HL7 FHIR Bulk Data Access (Flat FHIR) specification, we are proposing to require that all Medicaid and CHIP FFS programs at 42 CFR 431.61(a)(1)(ii) and 457.731(a)(1)(ii), Medicaid managed care plans at 42 CFR 438.242(b)(7), CHIP managed care entities at 42 CFR 457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 156.222(a)(1)(ii) implement and maintain a standardsbased Provider Access API using the HL7 FHIR Bulk Data Access (Flat FHIR) specification at 45 CFR 170.215(a)(4) to allow providers to receive the same information as indicated above for the individual patient request Provider Access API—their patients’ claims and encounter data (not including cost information such as provider remittances and enrollee cost-sharing); clinical data as defined in the USCDI version 1, where such clinical data are maintained; and formulary data or preferred drug list data, where applicable; as well as information on pending and active prior authorization decisions. The regulations for Medicaid managed care plans and CHIP managed care entities are cross-referenced and incorporate the regulations we propose for state Medicaid and CHIP FFS programs. We are proposing that payers would be required to implement this Bulk Data Provider Access API approach for data maintained by the payer with a date of service on or after January 1, 2016, by January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). We request public comment on whether this timeline is feasible and whether the benefits would out weight the costs of this Bulk Data Provider Access API proposal. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 We understand and acknowledge that payers and developers may view these proposed requirements as burdensome, as they could involve building multiple APIs to share data between payers and providers. We invite public comment on the benefits of having the Provider Access API available with and without the use of the HL7 FHIR Bulk Data Access (Flat FHIR) specification. As we look to balance providing this flexibility with the burden of potentially implementing and maintaining multiple APIs, we invite input on whether we should require payers to implement just one API that leverages the HL7 FHIR Bulk Data Access (Flat FHIR) specification for when they are requesting data for just one patient, or for more than one patient, or should we finalize as we are proposing here to have payers implement one API solution that does not leverage the Bulk specification for a single patient request (as discussed in section II.B.3. above in this proposed rule), and a second solution that uses the Bulk specification for requests for more than one patient. We believe both proposed functionalities offer necessary benefits to providers depending on the specifics of the situations in which they would need patient data. For example, a large health system or large group practice may benefit from using the bulk specification if it is updating records annually. We also believe that requiring payers to have both API approaches available gives providers flexibility. For example, a provider practicing within a large health system, such as in the example above, may want quick access to a specific patient’s information right before that patient’s scheduled appointment. We request comment on this proposal. States operating Medicaid and CHIP programs may be able to access federal matching funds to support their implementation of this Provider Access API, because the API is expected to help the state administer its Medicaid and CHIP state plans properly and efficiently, consistent with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more detail in section II.B.7.a. of this proposed rule. We do not consider state expenditures for implementing this proposal to be attributable to any covered item or service within the definition of ‘‘medical assistance.’’ Thus, we would not match these expenditures at the state’s regular federal medical assistance percentage. However, federal Medicaid matching funds under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be PO 00000 Frm 00017 Fmt 4701 Sfmt 4702 82601 available for state expenditures related to implementing this proposal for their Medicaid programs, because use of the Provider Access API would help ensure that providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately, and in the best interest of the patient, and thus help the state more efficiently administer its Medicaid program. States’ expenditures to implement these proposed requirements might also be eligible for enhanced 90 percent federal Medicaid matching funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent federal matching funds under section 1903(a)(3)(B) of the Act may be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement. States request Medicaid matching funds under section 1903(a)(3)(A)(i) or (B) of the Act through the Advance Planning Document (APD) process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to ensure that any system for which they are receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act aligns with and incorporates the ONC Health Information Technology standards adopted in accordance with 45 CFR part 170, subpart B. The Provider Access API, and all APIs proposed in this rule, complement this requirement because these APIs further interoperability through the use of HL7 FHIR standards proposed for adoption by ONC for HHS use at 45 CFR 170.215.27 In addition, states are reminded that 42 CFR 433.112(b)(10) explicitly supports exposed APIs as a condition of receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act. Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of Medicaid technologies and systems as a condition of receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act. CMS would interpret that sharing and re-use requirement also to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state’s APIs. Making the needed 27 See SHO #20–003, https://www.medicaid.gov/ federal-policy-guidance/downloads/sho20003.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 82602 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules technical documentation publicly available so that systems that need to connect to the APIs proposed in this rule can do so would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Provider Access API. Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act, limiting administrative costs to no more than 10 percent of CHIP payments to the state, would apply in developing the APIs proposed in this rule. We note that the temporary federal medical assistance percentage (FMAP) increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116–127) does not apply to administrative expenditures. khammond on DSKJM1Z7X2PROD with PROPOSALS2 6. Additional Proposed Requirements for the Provider Access APIs In general, the proposals discussed in this section would align with the requirements for the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559) and as proposed in section II.A.2. of this rule with respect to the data that are available through the API and the technical specifications (other than the proposed use of the Bulk specification). We anticipate that this alignment would provide consistency and help ensure that payers could build on the foundation of work done to meet the final Patient Access API requirements to meet the proposed requirements related to the Provider Access API. The accessible content, technical standards, API documentation requirements, and discontinuation and denial of access requirements would generally be consistent between the Patient Access API and the Provider Access API proposals, and thus we will not repeat the details of these requirements here. There are additional proposed requirements specific to the Provider Access API proposals related to attribution, patient opt-in, and provider resources. These are discussed in this section. a. Attribution Data sharing between the payer and provider via the Provider Access API starts with a request from the provider for one or more patients’ health information. Data sharing via the Provider Access API would be possible only if the patients for whom the provider is requesting information can be identified, especially if the provider is requesting data for more than one patient at a time using the proposed Bulk specification. We do not believe there is only one approach to VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 identifying the patients whose information would be requested, and we look to provide impacted payers with the opportunity to establish a process that will work best for them in light of their existing provider relationships. As discussed in the CMS Interoperability and Patient Access final rule, use of a standards-based FHIR API consistent with the privacy and security technical standards required provides a base level of protections (see 85 FR 25515 through 25519 and 85 FR 25544 through 25547). For instance, use of the API would allow payers to determine if the provider who is requesting the data is who they say they are by leveraging the required authorization and authentication protocols at 45 CFR 170.215. And, as mentioned above, the existing HIPAA Privacy and Security Rules apply. As a covered entity under HIPAA, it is the provider’s responsibility to use and disclose data in accordance with these existing rules. As part of the DPC pilot, as one example, we are planning to test a process that allows for the provider to add their active patients to a roster through self-attestation, which is further checked against claims to verify the provider has furnished services to the patient. The provider must attest electronically that they have an active treatment need for the data, and the provider must agree to the DPC terms of use for each roster submitted or updated.28 This approach was identified given the specific goals of the DPC pilot and the provider and patient population involved. For new patients, payers could consider a process for confirming a patient has an upcoming appointment scheduled to facilitate data sharing when there is not a claims history to use to verify a care relationship. We recognize that the payers impacted by this proposed rule have a variety of provider relationships to consider. We are therefore proposing that each payer establish, implement, and maintain for itself, a process to facilitate generating each provider’s current patient roster to enable this proposed payer-to-provider data sharing via the Provider Access API. We are proposing this at 42 CFR 431.61(a)(2) for state Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.61(a)) for Medicaid managed care plans other than non-emergency transportation (NEMT) PAHPs, at 42 CFR 457.731(a) for state CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 28 Data at the Point of Care. (n.d.). Terms of Service. Retrieved from https://dpc.cms.gov/termsof-service. PO 00000 Frm 00018 Fmt 4701 Sfmt 4702 457.731(a)) for CHIP managed care, and at 45 CFR 156.222(a)(2) for QHP issuers on the FFEs. To facilitate this data sharing, it is necessary that providers give payers a list of the patients whose data they are requesting. We do not wish to be overly prescriptive about how to generate this list for all payers. But, we note that it would be necessary for payers to put a process in place that is compliant with existing HIPAA Privacy and Security Rules and provides the information they need to complete their payer-specific compliance processes. We request comments on this proposal. And, we also seek comment on whether payers would like to maintain the option to define their own process or if they would prefer us to require a process across payers, such as the one we plan to test as part of the DPC pilot. b. Opt-In We are proposing that impacted payers would be permitted to put a process in place for patients to opt-in to use of the Provider Access API for data sharing between their payer and their providers. As with the attribution process discussed above, we did not want to be overly prescriptive regarding how this opt-in process might be implemented. However, we are considering whether to suggest a specific process for all payers who choose to implement this opt-in. One possible approach might be for CMS to have all payers engaging in an opt-in approach to include information about the ability to opt-in to this data sharing as part of their annual notice or regular communication with patients—such as when they communicate with patients about claims, and to permit opt-in via a variety of options, including by phone, via a website, or using an app, for instance. Currently the HIPAA Privacy Rule does not require health plans to obtain patient consent to share data with health care providers for treatment purposes or care coordination, for instance. However, we believe it is important to honor patient privacy preferences, and thus see value in possibly providing patients with options regarding which providers have access to their information as it relates to this proposed policy. We do note, as discussed above, that all existing applicable laws and regulations apply. This opt-in option is only specific to using the Provider Access API as the means to share data that the payer otherwise has authority to share with the provider. Therefore, we are specifically proposing at 42 CFR E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 431.61(a)(3) for state Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.61(a)(3)) for Medicaid managed care, at 42 CFR 457.731(a)(3) for state CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 457.731(a)(3)) for CHIP managed care, and at 45 CFR 156.222(a)(3) for QHP issuers on the FFEs that payers may put a process in place to allow a patient to opt-in to the Provider Access API data exchange for each provider from whom they are currently receiving care or are planning to receive care. We request comment on this proposal. In addition, we seek comment on whether payers would like to maintain the option to define their own process or if they would prefer CMS to suggest a process, such as the examples provided above, for all payers who would be required to implement and maintain the Provider Access API. We do note that we also considered the following alternatives: (1) Permit an optout process, (2) default to data sharing without patient engagement in the process consistent with the HIPAA Privacy Rule, and require an opt-out process. We seek comment on whether stakeholders would prefer we finalize an opt-out versus an opt-in approach, and whether either opt-out, or as currently proposed—opt-in, be permitted but not required. We request comment on the associated benefits and burdens with these different approaches, and any other considerations we should take into consideration as we consider a final policy. c. Provider Resources We are proposing that payers make educational resources available to providers that describe how a provider can request patient data using the payer’s Provider Access APIs in nontechnical, simple, and easy-tounderstand language. This requirement would be codified at 42 CFR 431.61(a)(4) for Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.61(a)) for Medicaid managed care other than NEMT PAHPs as defined at 42 CFR 438.2, at 42 CFR 457.731(a)(4) for CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 457.731(a)) for CHIP managed care, and at 45 CFR 156.222(a)(4) for QHP issuers on the FFEs. As proposed, this would include information on using both the individual patient request function as well as the bulk data request function. We are proposing that these resources be made available on the payer’s website and through other appropriate VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 mechanisms through which the payer ordinarily communicates with providers. We believe these resources would help providers understand how they can leverage the available APIs to access patient data, thus helping to ensure that the full value of the proposed APIs is realized and that providers gain access to needed patient data for use at the moment of care. We request comment on this proposal. d. Extensions and Exemptions for Medicaid and CHIP FFS Programs If our proposals regarding the Provider Access API are finalized, we would strongly encourage state Medicaid and CHIP FFS programs to implement the Provider Access API as soon as possible understanding the many benefits of the API as discussed previously in this section. However, we also recognize that state Medicaid or CHIP FFS agencies could face certain unique circumstances that would not apply to other impacted payers, as discussed in more detail later in this section. As a result, a few states might need to seek an extension of the compliance deadline or an exemption from these requirements. To address this concern, we are proposing a process through which states may seek an extension of and, in specific circumstances, an exemption from, the Provider Access API requirements if they are unable to implement these API requirements. Providing for these flexibilities might allow these states to continue building technical capacity in support of overall interoperability goals consistent with their needs. We therefore propose the following. Extension. At 42 CFR 431.61(e)(1) and 42 CFR 457.731(e)(1), respectively, we propose to provide states—for Medicaid FFS and CHIP FFS—the opportunity to request a one-time extension of up to one (1) year for implementation of the Provider Access API specified at 42 CFR 431.61(a) and 42 CFR 457.731(a). Unique circumstances that might present a challenge to specific states to meet the proposed compliance date could include resource challenges, such as funding. Depending on when the final rule is published in relation to a state’s budget process and timeline, some states may not be able to secure the needed funds in time to both develop and execute implementation of the API requirements by the proposed compliance date. A one-year extension could help mitigate this issue. And, some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state’s implementation of these proposed API policies. The PO 00000 Frm 00019 Fmt 4701 Sfmt 4702 82603 timeline for an open, competed procurement process, together with the time needed to onboard the contractor and develop the API, could require additional time as well. Finally, a state might need to hire new staff with the necessary skillset to implement this policy. Again, the time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult, because, generally speaking, public employee hiring processes include stricter guidelines and longer time-to-hire periods than other sectors.29 In all such situations, a state might need more time than other impacted payers to implement the requirements. If a state believes it can demonstrate the need for an extension, its request must be submitted and approved as a part of its annual Advance Planning Document (APD) for Medicaid Management Information System (MMIS) operations costs and must include the following: (1) A narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to states operating Medicaid or CHIP FFS programs, (2) a report on completed and ongoing implementation activities to evidence a good faith effort toward compliance, and (3) a comprehensive plan to meet implementation requirements no later than one year after the initial compliance date. An extension would be granted if CMS determines based on the information provided in the APD that the request adequately establishes a need to delay implementation, a good faith effort to implement the proposed requirements as soon as possible, and a clear plan to implement no later than one year after the proposed compliance date. We would expect states to explain why the request for an extension results from circumstances that are unique to states operating Medicaid or CHIP FFS programs. We also solicit comment on whether our proposal would adequately address the unique circumstances that affect states, and that might make timely compliance with the proposed API requirement sufficiently difficult for states and thus justify an extension. In particular, we seek comment on 29 State hiring processes are comparable with federal hiring processes. According to OMB, the average time-to-hire for federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See: https:// www.opm.gov/news/releases/2020/02/opm-issuesupdated-time-to-hire-guidance/. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82604 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules whether we should require or use additional information on which to base the determination or whether we should establish different standards in the regulation text for evaluating and granting the request. Exemption. At 42 CFR 431.61(e)(2) and 42 CFR 457.731(e)(2), respectively, we propose two circumstances that would permit state requests for exemption; namely, (1) when at least 90 percent of all covered items and services are provided to Medicaid or CHIP beneficiaries through Medicaid or CHIP managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or (2) when at least 90 percent of the state’s Medicaid or CHIP beneficiaries are enrolled in Medicaid or CHIP managed care organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10 for CHIP. In both circumstances, the time and resources that the state would need to expend to implement the API requirements may outweigh the benefits of implementing and maintaining the API. Unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries as states, unlike other payers, do not maintain additional lines of business. We acknowledge that the proposed exemption could mean that a few Medicaid or CHIP FFS systems would not receive the benefits of having this API available to facilitate health information exchange. To address this, we propose that states meeting the above thresholds would be expected to employ an alternative plan to enable the electronic exchange and accessibility of health information for those beneficiaries who are served under the FFS program. A state meeting the above criteria would be permitted to submit a request for an exemption to the requirements for the Provider Access API once per calendar year for a one (1) year exemption. The state would be required to submit this annual request as part of a state’s annual APD for MMIS operations costs. The state would be required to include in its request documentation that it meets the criteria for the exemption using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. We note we propose that this request be made annually as from year-to-year the nature of the FFS population could VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 change and so it is important that the state provide the most current information for CMS’ consideration. Exemptions would be granted for a one-year period if a state establishes to CMS’ satisfaction that it meets the criteria for the exemption and has established a plan to ensure that providers will have efficient electronic access to the same information through alternative means. We request comment on the proposed extension and exemption. For Medicaid and CHIP managed care, we are not proposing an extension process at this time because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements in 42 CFR part 438 and part 457 and also benefit from efficiencies resulting from their multiple lines of business impacted by these interoperability policies. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or are unachievable by the compliance date. We are soliciting comment on whether our belief concerning the scope of resources and ability of managed care parent organizations to achieve economies of scale is well-founded. Further, we seek comment on whether an extension process is warranted for certain managed care plans to provide additional time for the plan to comply with the requirement at 42 CFR 438.61(a) (which cross references 42 CFR 438.242(b)(7)) for Medicaid managed care plans and at proposed 42 CFR 457.731(a) (which cross references 42 CFR 457.1223(d)(4)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary for the reasons outlined here, we are open to considering one if necessary. If we adopt an extension process for these managed care plans and entities, what criteria would a managed care plan or entity have to meet to qualify for an extension? Should the process consider, for example, enrollment size, plan type, or some unique characteristic of certain plans that could hinder their achievement of the proposed requirements by the proposed compliance date? Also, we seek comment on whether, if finalized such PO 00000 Frm 00020 Fmt 4701 Sfmt 4702 a process for Medicaid managed care plans or CHIP managed care entities, the state or CMS should manage the process and whether states could successfully adopt and implement the process on the timeline necessary to fulfill the goals and purposes of the process. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(d), we would expect any extension request to include, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, the impact of noncompliance upon enrollees, the current or proposed means of providing electronic health information to providers, and a corrective action plan with a timeline to achieve compliance. e. Exception for QHP issuers For QHP issuers on the FFEs, we propose an exception at 45 CFR 156.222(d) to these Provider Access API proposals. We propose that if an issuer applying for QHP certification to be offered through a FFE believes it cannot satisfy the proposed requirements in 45 CFR 156.222(a) for the Provider Access APIs, the issuer must include as part of its QHP application a narrative justification describing the reasons why the issuer cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon providers and enrollees, the current or proposed means of providing health information to providers, and solutions and a timeline to achieve compliance with the requirements of this section. We propose that the FFE may grant an exception to the requirements in 45 CFR 156.222(a) for the Provider Access APIs if it determines that making such health plan available through such FFE is in the interests of qualified individuals in the state or states in which such FFE operates. This proposal would be consistent with the exception for QHP issuers on the FFEs we finalized for the Patient Access API in the Interoperability and Patient Access final rule (85 FR 25552 through 25553). For instance, as noted in that final rule, that exception could apply to small issuers, issuers who are only in the individual or small group market, financially vulnerable issuers, or new entrants to the FFEs who demonstrate that deploying standards based API technology consistent with the required interoperability standards would pose a significant barrier to the issuer’s ability to provide coverage to consumers, and not certifying the issuer’s QHP or QHPs would result in consumers having few E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE is in the best interest of consumers and would not want consumers to have to go without access to QHP coverage because the issuer is unable to implement this API timely. As mentioned in section II.A. of this proposed rule, although Medicare FFS is not directly impacted by this rule, we do note that we are targeting to implement a Provider Access API, if finalized. In this way, the Medicare FFS implementation would conform to the same requirements that apply to the impacted payers under this rulemaking, as applicable, so that Medicare FFS beneficiaries would also benefit from this data sharing. 7. Statutory Authorities for Provider Access API Proposals khammond on DSKJM1Z7X2PROD with PROPOSALS2 a. Medicaid and CHIP As is discussed in more detail below, our proposed requirements in this section for Medicaid managed care plans and Medicaid state agencies fall generally under the authority in the following provisions of the statute. • Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. • Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. • Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. We note statutory authority for proposals to require specific IGs for this and all APIs proposed in this rule is discussed in section II.A.3. of this proposed rule. We believe these proposals are generally consistent with all these provisions of the Act, because they would help ensure that providers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately. The proposals are thus expected to help states fulfill their obligations to operate their state plans efficiently and to ensure that Medicaid services are furnished with reasonable promptness and in a manner consistent with the best interest of patients. Proposing to require states to implement a Provider Access API to share data about certain claims, VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 encounter, and clinical data, including data about pending and active prior authorization decisions, for a specific individual beneficiary or for more than one beneficiary at a time could improve the efficiency of and simplify how states ensure the delivery of Medicaid services. This API would enable providers to easily access accurate and complete beneficiary utilization and authorization information at the time of care, or prior to a patient encounter, and that, in turn, would enable the provider to spend more time on direct care. This would support efficient and prompt delivery of care as well as care in the best interest of patients. These proposals also are expected to allow for better access to other providers’ prior authorization decisions. This would give a provider a more holistic view of a patient’s care that could reduce the likelihood of ordering duplicate or misaligned services. This could also facilitate easier and more informed decision making by the provider and would therefore support efficient provision of care in the best interest of patients. Additionally, because the data could be incorporated into the provider’s EHR or other practice management system, the proposal is expected to support efficient access to and use of the information. The proposal is expected to make it more likely that a more complete picture of the patient could be available to the provider at the point of care, which could result in the provision of more informed and timely services. These process efficiencies may ultimately improve practice efficiency and make more of providers’ time available for appointments. These outcomes and process efficiencies would help states fulfill their obligations to ensure prompt access to services in a simpler manner and in a manner consistent with the best interest of beneficiaries, consistent with section 1902(a)(8) and (19) of the Act, and the efficiencies created for providers might help the state to administer its Medicaid program more efficiently, consistent with section 1902(a)(4) of the Act. The proposal related to the Bulk specification for the Provider Access API would help facilitate data sharing about one or more beneficiaries at once. This could further improve the efficiency and simplicity of operations because it would eliminate the need for a provider to make individual API calls when seeking information about a large number of beneficiaries, taxing both the payer’s and provider’s systems. The ability to receive beneficiary data in bulk would also permit practices to PO 00000 Frm 00021 Fmt 4701 Sfmt 4702 82605 analyze practice and care patterns across patient populations, thus helping them to improve processes and maximize efficiencies that could lead to better health outcomes. All of these expected positive outcomes could help states fulfill their obligations to ensure prompt access to services in a simpler manner and in a manner consistent with the best interest of beneficiaries, consistent with section 1902(a)(8) and (19) of the Act, and the efficiencies created for providers might help the state to administer its Medicaid program more efficiently, consistent with section 1902(a)(4) of the Act. For CHIP, we are proposing these requirements under the authority in section 2101(a) of the Act, which states that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, lowincome children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe this proposed rule could strengthen states’ ability to fulfill these title XXI statutory obligations in a way that recognizes and accommodates the use of electronic information exchange in the health care industry today and would facilitate a significant improvement in the delivery of quality health care to CHIP beneficiaries. When providers have access to patient utilization and authorization information directly from their EHRs or other health IT systems, they can provide higher quality care. Improving the quality of care aligns with section 2101(a), which requires states to provide CHIP services in an effective and efficient manner. The more information a provider has to make informed decisions about a patient’s care, the more likely it is that patients will receive care that best meets their needs. Additionally, providers can be more effective and efficient in their delivery of CHIP services by having direct access to patient utilization and authorization information. If a provider has information about a patient prior to or at the point of care, the provider will be able to spend more time focused on the patient versus on their need to collect information. And, the information they do collect will not be based solely on patient recall. As noted above for Medicaid, this could save time, improve the quality of care, and increase the total amount of direct care provided to CHIP beneficiaries. When data are standardized, and able to be incorporated directly into the provider’s EHR or practice management system, they can be leveraged as needed at the point of care by the provider, but also be used to support coordination across E:\FR\FM\18DEP2.SGM 18DEP2 82606 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules providers and payers. This is inherently more efficient, and ultimately, more cost effective, as the information does not have to be regularly repackaged and reformatted to be shared or used in a valuable way. As such, the Provider Access API proposals also align with section 2101(a) in that these proposals could improve coordination between CHIP and other health coverage. For these reasons, we believe this proposal is in the best interest of the beneficiaries and within our authorities. b. QHP Issuers on the FFEs khammond on DSKJM1Z7X2PROD with PROPOSALS2 For QHP issuers on the FFEs, we are proposing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We note statutory authority for proposals to require specific IGs for this and all APIs proposed in this rule are discussed in section II.A.3. of this proposed rule. We believe that certifying only health plans that make enrollees’ health information available to their providers via the Provider Access API is in the interests of enrollees. Giving providers access to their patients’ information supplied by QHP issuers on the FFEs would ensure that providers are better positioned to provide enrollees with seamless and coordinated care, and helps to ensure that QHP enrollees on the FFEs are not subject to duplicate testing and procedures, and delays in care and diagnosis. Access to the patients’ more complete medical information may also maximize the efficiency of an enrollee’s office visits. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges. We also believe that requiring QHP issuers on the FFEs to use the Bulk specification for the Provider Access API would improve the efficiency and simplicity of data transfers by allowing the provider to get all the info for a full panel of patients at once. C. Reducing the Burden of Prior Authorization Through APIs 1. Background Improving the prior authorization process is an opportunity to reduce burden for payers, providers, and patients. The proposals in this rule build on the foundation set out in the CMS Interoperability and Patient Access VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 final rule to improve health information exchange and increase interoperability in the health care system. Proposals in this section were developed based on industry input from CMS sponsored listening sessions, stakeholder meetings, and reports. We use the term ‘‘prior authorization’’ to refer to the process through which a provider must obtain approval from a payer before providing care and prior to receiving payment for delivering items or services. In some programs, this may be referred to as ‘‘pre-authorization’’ or ‘‘pre-claim review.’’ Prior authorization requirements are established by payers to help control costs and ensure payment accuracy by verifying that an item or service is medically necessary, meets coverage criteria, and is consistent with standards of care before the item or service is provided rather than undertaking that review for the first time when a post-service request for payment is made. However, stakeholders have stated that diverse payer policies, provider workflow challenges, and technical barriers have created an environment in which the prior authorization process is a primary source of burden for both providers and payers, a major source of burnout for providers, and a health risk for patients when it causes their care to be delayed. The policies in this proposed rule would apply to any formal decisionmaking process by which impacted payers render an approval or disapproval determination, or decision, regarding payment for clinical care based on the payer’s coverage guidelines and policies before services are rendered or items provided. We have been studying prior authorization and its associated burden to identify the primary issues that stakeholders believe need to be addressed to alleviate that burden. To advance the priorities of the 21st Century Cures Act,30 specifically the aim to reduce burden, ONC and CMS created a working group to investigate the prior authorization ecosystem and identify opportunities for potential solutions. Burdens associated with prior authorization include difficulty in determining payer-specific requirements related to items and services that require prior authorization; inefficient use of provider and staff time to submit and receive prior authorization requests through burdensome channels such as fax, telephone, and various web portals; 30 ONC Strategy to reduce provider burden. Report required under the 21st Century Cures Act: https://www.healthit.gov/topic/usability-andprovider-burden/strategy-reducing-burden-relatinguse-health-it-and-ehrs. PO 00000 Frm 00022 Fmt 4701 Sfmt 4702 and unpredictable and lengthy amounts of time to receive payer decisions. In 2018, the American Medical Association (AMA) conducted a physician survey that indicated a weekly per-physician average of 31 prior authorization requests, consuming an average of 14.9 hours of practice time per workweek for physicians and their staff. Additionally, 36 percent of physicians have staff that work exclusively on prior authorizations.31 In 2019, CMS conducted a number of listening sessions with payers, providers, patients, and other industry representatives to gain insight into issues with prior authorization processes and to identify potential areas for improvement. While both providers and payers agreed that prior authorization provides value to the health care system through cost control, utilization management, and program integrity measures, some stakeholders expressed concerns that certain steps in the prior authorization processes are burdensome. For example, the information required from payers to receive prior authorization can be inconsistent from payer to payer, and it can be difficult for providers to determine the rules for items or services that require prior authorization or what documentation is needed to obtain approval. Furthermore, the documentation requirements are not centralized because the rules vary for each payer, and access to those requirements may require the use of proprietary portals. These challenges were described in the ONC 2020 report on reducing electronic health record burdens, which stated, ‘‘Each payer has different requirements and different submission methods, and clinicians report finding it burdensome and timeconsuming trying to determine whether prior authorization requirements exist for a given patient, diagnosis, insurance plan, or state.’’ 32 In the CMS listening sessions, as well as the surveys and reports referenced throughout this section, stakeholders suggested that payers should disclose their prior authorization requirements in a standard format. Stakeholders raised concerns that once a provider has identified the appropriate prior authorization requirement for a given 31 American Medical Association. (2019, February). 2018 AMA Prior Authorization (PA) Physician Survey. Retrieved from https://www.amaassn.org/system/files/2019-02/prior-auth-2018.pdf. 32 Office of the National Coordinator for Health Information Technology. (n.d.) Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs [PDF file]. Retrieved from https://www.healthit.gov/sites/ default/files/page/2020-02/BurdenReport_0.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 patient, payer, and item or service, the process of submitting a prior authorization request relies on an array of cumbersome submission channels, including payer-specific web-based portals, telephone calls, and fax exchange technology. In addition, after a provider has completed the process of submitting a prior authorization request and received approval for an item or service from a particular payer, the provider may need to re-submit a new prior authorization request for the same, already approved, item or service should the patient experience a change in health coverage, which could include switching payers, or switching between private coverage and public coverage. Should this occur, the provider must start the prior authorization process anew with the patient’s new payer, which may have different documentation requirements and submission formats. In 2017, a coalition of 16 provider organizations collaborated with payer associations to develop a set of principles to identify ways to reduce administrative burdens related to prior authorizations and improve patient care. The coalition published a consensus paper identifying 21 specific opportunities for improvement in prior authorization programs and processes and specifically called out the need for industry-wide adoption of electronic prior authorization to improve transparency and efficiency.33 Nonetheless, industry is still at a point where payers and IT developers have addressed prior authorization in an ad hoc manner with the implementation of unique interfaces that reflect their own technology considerations, lines of business, and customer-specific constraints.34 The proposals in this proposed rule reflect several principles cited in the industry consensus statement, including transparency and communication regarding prior authorization to encourage effective communication between health plans, providers, and patients to minimize care delays and articulate prior authorization requirements, as well as automation to improve transparency, through the adoption and implementation of electronic prior authorization with the 33 American Medical Association. (2018). Consensus Statement on Improving the Prior Authorization Process. Retrieved from https:// www.ama-assn.org/sites/ama-assn.org/files/corp/ media-browser/public/arc-public/priorauthorization-consensus-statement.pdf. 34 Office of the National Coordinator for Health Information Technology. (2020, February). Strategy on Reducing Regulatory and Administrative Burden Relating to the Use of Health IT and EHRs. Retrieved from https://www.healthit.gov/sites/ default/files/page/2020-02/BurdenReport_0.pdf. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 potential to streamline and improve the process for all stakeholders. There is increasing demand from providers, with support from the payer and vendor community, as well as the Secretary’s advisory committees, to address the burdens associated with the prior authorization process. In March and November of 2019, the Health IT Advisory Committee (HITAC) and National Committee on Vital and Health Statistics (NCVHS) held joint hearings with stakeholders to discuss the ongoing challenges with prior authorization workflow, standards, and payer policies. During these hearings, payers and providers agreed that solutions to address prior authorization issues may not rest with one single action, but, rather, they believed that the opportunity to use new standards and/ or technology, coupled with the movement towards more patient focused policies, would provide substantial relief and progress. At the November 13, 2019 NCVHS Full Committee meeting,35 ONC joined NCVHS and invited six industry experts to discuss ongoing challenges with prior authorization standards, policies, and practices. The themes from panelists were consistent with information provided elsewhere in this proposed rule, that changes are still needed in technology, payer policies, and payer/ provider workflow. America’s Health Insurance Plans (AHIP) reported the results of its 2019 fall plan survey, which included both AHIP and nonAHIP members, and reported that plans were evaluating opportunities for prior authorization policy changes to address issues. AHIP launched a pilot of alternative prior authorization strategies with several plans in 2020.36 In early 2020, NCVHS and HITAC convened another task force, the Intersection of Clinical and Administrative Data (ICAD), which met weekly to address an overarching charge to convene industry experts and produce recommendations related to electronic prior authorizations.37 The task force report was presented to HITAC in November 35 National Committee on Vital and Health Statistics. (2019, November 13). Committee Proceedings [Transcript]. Retrieved from https:// ncvhs.hhs.gov/wp-content/uploads/2019/12/ Transcript-Full-Committee-Meeting-November-132019.pdf. 36 America’s Health Insurance Plans. (2020, January 6). New Fast PATH Initiative Aims to Improve Prior Authorization for Patients and Doctors. Retrieved from https://www.ahip.org/newfast-path-initiative-aims-to-improve-priorauthorization-for-patients-and-doctors/. 37 See https://www.healthit.gov/hitac/ committees/intersection-clinical-andadministrative-data-task-force. PO 00000 Frm 00023 Fmt 4701 Sfmt 4702 82607 2020.38 Several recommendations pertaining to the use of FHIR based APIs for prior authorization were included in the ICAD report, and are consistent with proposals in this proposed rule. Those recommendations and others are described in more detail in the section II.E. of this proposed rule. In a November 4, 2019 letter to the CMS Administrator, the American Hospital Association (AHA) described the ongoing impact of prior authorization on patient care, health system costs, and burdens.39 In the letter, the AHA shared results from the previously referenced 2018 AMA survey of more than 1,000 physicians, which indicated that 90 percent of respondents stated prior authorization had a significant or somewhat negative clinical impact on care.40 Furthermore, 27 percent of survey respondents stated that delays in the provision of care due to prior authorization processes had led to a serious adverse event such as a death, hospitalization, disability, or permanent bodily damage. The AHA’s letter affirmed what we have stated above—prior authorization is a burden that can lead to patient harm. According to the AHA, hospitals and provider offices have many full-time employees whose sole role is to manage payer prior authorization requests. One hospital system spends $11 million annually just to comply with payer prior authorization requirements. Operational costs such as these are often factored into negotiated fees or charges to patients to ensure financial viability for health care organizations including providers and facilities, and we believe this to be the case for small and large organizations. We believe our proposals in the following sections would make meaningful progress in alleviating the burdens described above and facilitating more efficient and prompt health care service delivery to patients. 2. Electronic Options for Prior Authorization To mitigate provider burden, and improve care delivery to patients, we are proposing requirements for payers to implement APIs that are conformant with certain implementation guides that 38 Final report from ICAD Task Force November 17, 2020: https://www.healthit.gov/sites/default/ files/page/2020-11/2020-11-17_ICAD_TF_FINAL_ Report_HITAC.pdf. 39 American Hospital Association. (2019, November 4). RE: Health Plan Prior Authorization [PDF file]. Retrieved from https://www.aha.org/ system/files/media/file/2019/11/aha-to-cms-healthplan-prior-authorization-11-4-19.pdf. 40 American Medical Association. (2019, February). 2018 AMA Prior Authorization (PA) Physician Survey. Retrieved from https://www.amaassn.org/system/files/2019-02/prior-auth-2018.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82608 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules would facilitate the exchange of information between payers and providers and allow providers to more effectively integrate the prior authorization process within their clinical workflow. We believe, and stakeholder input has confirmed, that payers and providers do not take advantage of standards that are currently available for the exchange of electronic prior authorization transactions and resort to proprietary interfaces and web portals supplemented by inefficient and time consuming manual processes such as phone calls or faxes. However, if payers made the requirements for prior authorization more accessible and understandable through APIs, and providers had access to the tools to initiate a prior authorization from within their workflow, providers would be more likely to submit the request and necessary documentation to the payer using electronic standards. In section II.B.2. of this proposed rule, we reference transactions for which the Secretary must adopt electronic standards for use by covered entities (health plans, health care clearinghouses, and certain health care providers), and list the transactions there. The two standards adopted for referrals certifications and authorizations (hereafter referred to as the prior authorization transaction standard) under HIPAA (45 CFR 162.1302) include: • NCPDP Version D.0 for retail pharmacy drugs; and • X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional request for review and response for items and services. Though payers are required to use the X12 278 standard for electronic prior authorization transactions, and providers have been encouraged to conduct the transaction electronically, the prior authorization standard transaction has not achieved a high adoption rate by covered entities. The Council for Affordable and Quality Health Care (CAQH) releases an annual report called the CAQH Index, which includes data on payer and provider adoption of HIPAA standard transactions. In the 2019 report, among the seven transactions benchmarked, prior authorization using the X12 278 standard was the least likely to be supported by payers, practice management systems, vendors, and clearinghouse services.41 According to 41 CAQH. (2019). 2019 CAQH Index: A Report of Healthcare Industry Adoption of Electronic Business Transactions and Cost Savings [PDF file]. Retrieved from https://www.caqh.org/sites/default/ VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 this report, 14 percent of the respondents indicated that they were using the adopted standard in a fully electronic way while 54 percent responded that they were conducting electronic prior authorization using web portals, Integrated Voice Response (IVR) and other options, and 33 percent were fully manual (phone, mail, fax, and email). Reported barriers to use of the HIPAA standard include lack of vendor support for provider systems, inconsistent use of data content from the transaction, and lack of an attachment standard to submit required medical documentation (CAQH Index). The proposed PAS API could support increased use of the HIPAA standard through its capability to integrate with a provider’s system directly, automation, and improved timeliness for obtaining a response to a prior authorization request, particularly when paired with the DRLS API. However, we are interested in hearing from commenters if there are other steps CMS could take to further implementation of the X12 278 standard and what challenges would remain if the standard was more widely utilized. HIPAA also requires that HHS adopt operating rules for the HIPAA standard transactions. Operating rules are defined at 45 CFR 162.103 as the ‘‘necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications as adopted for purposes of HIPAA Administrative Simplification.’’ The NCVHS reviews potential HIPAA operating rules and advises the Secretary as to whether HHS should adopt them (section 1173(g) of the Act). The Secretary adopts operating rules in regulations in accordance with section 1173(g)(4) of the Act. To date, HHS has adopted operating rules for three of the HIPAA standard transactions: Eligibility for a health plan and health care claim status (76 FR 40458), health care electronic funds transfers (EFT), and remittance advice (77 FR 48008). In February 2020, CAQH, which develops operating rules for HIPAA standards, submitted two operating rules for the HIPAA referral certification and authorization transaction for consideration to NCVHS, which held a hearing to discuss those operating rules in August 2020. Should HHS adopt operating rules for the HIPAA referral certification and authorization transaction, we would evaluate them to determine their effect, if any, on proposals in this proposed rule. files/explorations/index/report/2019-caqhindex.pdf?token=SP6YxT4u. PO 00000 Frm 00024 Fmt 4701 Sfmt 4702 3. Proposed Requirement for Payers: Documentation Requirement Lookup Service (DRLS) API Based on information from the listening sessions and nongovernmental surveys, we believe one of the most highly burdensome parts of the prior authorization process for payers and providers include identifying the payer rules and determining what documentation is required for an authorization. As described earlier, this issue is one of the key principles in the industry consensus paper 42 under transparency and communication, in which the parties agreed to ‘‘encourage transparency and easy accessibility of prior authorization requirements, criteria, rationale, and program changes to contracted health care providers and patients/enrollees.’’ In concert with this effort towards collaboration, the AMA launched an outreach campaign called #fixpriorauth 43 to drive awareness to the scope of the challenges of the prior authorization process. Industry input underscores the fact that while there is no single solution to improving the prior authorization process, some action on certain burdens could be transformative. Therefore, we propose to streamline access to information about prior authorization and related documentation requirements to potentially reduce this burden. To that end, at 42 CFR 431.80(a)(1), 438.242(b)(7), 457.732(a)(1), 457.1233(d)(4), and 45 CFR 156.223(a)(1), we propose to require that, beginning January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023), state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs, implement and maintain a FHIR-based DRLS API conformant with the HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG: Version STU 1.0.0 44 and the HL7 FHIR Da Vinci Documentation Templates and Rules (DTR): Version STU 1.0.0 45 IG, populated with their list of covered items and services, not 42 Consensus Statement for Improving Prior Authorization: https://www.ama-assn.org/sites/ ama-assn.org/files/corp/media-browser/public/arcpublic/prior-authorization-consensusstatement.pdf. 43 AMA website link with resources regarding the prior authorization challenges: https:// fixpriorauth.org/resources. 44 HL7 International. (n.d.). Da Vinci Coverage Requirements Discovery (CRD) FHIR Implementation Guide. Retrieved from https:// hl7.org/fhir/us/davinci-crd/history.html. 45 HL7 International. (n.d.). Da Vinci Documentation Templates and Rules. Retrieved from https://hl7.org/fhir/us/davinci-dtr/history.html. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules including prescription drugs and/or covered outpatient drugs, for which prior authorization is required, and with the organization’s documentation requirements for submitting a prior authorization request, including a description of the required documentation. Through a proposed cross-reference to the Patient Access API requirements at 42 CFR 431.80(a)(1) for Medicaid FFS; at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.80) for Medicaid managed care; at 42 CFR 457.732(a)(1) for CHIP FFS; at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 457.732) for CHIP managed care; and at 45 CFR 156.223(a)(1) for QHP issuers on the FFEs, we are proposing to require that the DRLS API comply with the same technical standards, API documentation requirements, and discontinuation and denial of access requirements as apply to the Patient Access API (and as proposed for the Provider Access API in section II.B. of this proposed rule). For a complete discussion of these requirements, we refer readers to the CMS Interoperability and Patient Access final rule (85 FR 25526 through 25550). We believe payer implementation of DRLS APIs conformant with the CRD and DTR IGs which are proposed at 45 CFR 170.215(c)(1) and (2) in section II.E. of this proposed rule, would make prior authorization requirements and other documentation requirements electronically accessible and more transparent to health care providers at the point of care. As explained, because each payer has different rules to determine when a prior authorization is required, and what information is necessary to obtain approval, providers must use different methods to keep track of the rules and requirements, which is often time consuming and cumbersome. The payer’s DRLS API would enable a query to their prior authorization requirements for each item and service and identify in real time the specific rules and documentation requirements. Based on the information, the provider could be prepared to submit any necessary documentation to the payer based on those requirements, and complete any available electronic forms or templates, which would be incorporated into the API. For example, once the payer has built a DRLS API and made it available, a provider could initiate a query to the payer’s DRLS API to determine if a prior authorization and documentation is required. If the response is affirmative, the DLRS API would indicate what is required, and might provide a link to submit the required documentation. In VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 some cases, certain patient data available in the provider’s system could be used to meet documentation requirements. Payers who implement and maintain a DRLS API could see improvements and efficiencies in the prior authorization process within their own organization, by reducing the number of unnecessary requests, minimizing follow up, and through fewer denials or appeals. For similar reasons, this could contribute to burden reduction for providers as well. We believe that requiring impacted payers to implement the API would increase provider demand for this functionality if offered by these payers. Providers would want access to the API if the payer does offer it. We are interested in comments on steps that HHS could take to encourage development of these functions within provider EHR systems. We are also interested in comments for consideration for future policies to require or incentivize providers to use the payer DRLS API in their workflows. By the time this proposed DRLS API would be required to be implemented beginning January 1, 2023 should this proposal be finalized as proposed, impacted payers would have the technology needed to support a FHIR API, because they would have implemented the Patient Access API as adopted in the CMS Interoperability and Patient Access final rule (85 FR 25558 through 25559). We intend to enforce the requirement for a Patient Access API, as adopted in that rule, starting July 1, 2021, taking into account the 6 months of enforcement discretion we are exercising due to the public health emergency.46 In order to implement the Patient Access API, payers will have installed the FHIR servers, mapped claims and clinical data for data exchange via FHIR, and implemented a FHIR API. We believe the experience of implementing the Patient Access API, including having made upgrades to their computer systems and trained or hired staff to support its use, would enable impacted payers under this proposed rule to implement the DRLS API by January 1, 2023 (or, for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). We considered whether it would be beneficial for payers to implement the proposed DRLS APIs in phases. For example, we considered whether payers should implement the DRLS API via an incremental approach, incorporating the 46 For more information, visit: https:// www.cms.gov/Regulations-and-Guidance/ Guidance/Interoperability/index. PO 00000 Frm 00025 Fmt 4701 Sfmt 4702 82609 top 10 percent or top 10 highest volume prior authorization rules in the first year, and continue adding to the DRLS API over a 2- or 3-year period before the DRLS is fully implemented. However, we believe that fully implementing the DRLS API in year one of such a phased timeline, by January 1, 2023, would be critical to streamlining the prior authorization process, and would be instrumental in moving towards increased use of electronic prior authorization. We request comments on this proposal for impacted payers to implement a DRLS API. We also request input on a potential short-term solution to address the challenge of accessing payer requirements for prior authorizations. We solicit feedback on how payers currently communicate prior authorization requirements, and on the potential for payers to post, on a public-facing website, their list of items and services for which prior authorization is required, populate the website with their associated documentation rules as in interim step while they implement the DRLS. This is not intended to harmonize prior authorization requests, but rather to quickly address the issue identified by stakeholders regarding access to prior authorization information. If payers could post their prior authorization requirements on a website, how could that information be presented and organized for providers to easily identify the services and items which require prior authorization? Finally, we request comments on how the posting of this information on payer websites would provide a satisfactory interim solution to the challenge of accessing payer requirements for prior authorizations in advance of implementing the DRLS API. 4. Proposed Requirement for Payers: Implementation of a Prior Authorization Support API Electronic prior authorizations are not used consistently between payers and providers, even with the availability of an adopted HIPAA standard. The burden of navigating the various submission mechanisms falls on the provider and can detract from providing care to patients. Additionally, many provider administrative practice management systems and vendors do not support the adopted HIPAA standard. To help address this issue, we are proposing that impacted payers implement a Prior Authorization Support (PAS) API that facilitates a HIPAA compliant prior authorization request and response, including any forms or medical record documentation E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82610 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules required by the payer for items or services for which the provider is seeking authorization. Specifically, we propose to require that Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs implement and maintain a PAS API conformant with the HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG beginning January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). We propose to codify this requirement at 42 CFR 431.80(a)(2) and 457.732(a)(2), and 45 CFR 156.223(a)(2) and, as with our proposal for the Provider Access API (discussed in section II.B. of this proposed rule), we propose to use cross-references in 42 CFR 438.242(b)(7) and 42 CFR 457.1233(d)(4) to impose this new PAS API requirement on Medicaid managed care plans and CHIP managed care entities. The API would be required to be conformant with the implementation specification at 45 CFR 170.215(c)(3). If this provision is finalized as proposed, the payer would be required to implement the API, and, when sending the response, include information regarding whether the organization approves (and for how long), denies, or requests more information for the prior authorization request, along with a reason for denial in the case of a denial. The PAS API would provide an opportunity to leverage the convenience of API technology, while maintaining compliance with the adopted HIPAA transaction standard. Furthermore, use of the PAS API would accelerate adoption and use of electronic prior authorization transactions by impacted payers and by providers, particularly when coupled with implementation of the DRLS API, increasing efficiencies for both parties. We are aware that the flow of the payer API may not be intuitive to all readers, therefore, please refer to the implementation guides for payer API flow details. We also provide a highlevel description here. The payer would make a PAS API available for providers. When a patient needs authorization for a service, the payer’s PAS API would enable the provider, at the point of service, to send a request for an authorization. The API would send the request through an intermediary (such as a clearinghouse) that would convert it to a HIPAA compliant X12 278 request transaction for submission to the payer. It is also possible that the payer converts the request to a HIPAA compliant X12 278 transaction, and thus the payer acts as the intermediary. The VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 payer would receive and process the request and include necessary information to send the response back to the provider through its intermediary, where the response would be transformed into a HIPAA compliant 278 response transaction. The response through the API would indicate whether the payer approves (and for how long), denies, or requests more information related to the prior authorization request, along with a reason for denial in the case of a denial. We believe it would be valuable for payers to implement the PAS API for prior authorizations, because doing so would enhance the overall process generally, and, specifically, would increase the uptake of electronic prior authorizations by providers. Implementation of the PAS API would also maintain compliance with the adopted HIPAA standards, so other legacy system changes may not be necessary. We also believe that existing business arrangements with intermediaries or clearinghouses would remain in place to support transmission of the X12 transaction. Payers who implement the PAS API would likely see an improvement in efficiencies, particularly when coupled with implementation of the DRLS API because when providers know clearly what documentation is required to support a prior authorization request, they do not need to call or fax for additional instructions. Fewer phone calls or errors would decrease administrative costs for a payer. Use of the PAS API could facilitate a real time exchange of the authorization request, so that payers could provide a real time response. In particular, we expect that our proposals to require payers to implement the DRLS and PAS APIs would improve the electronic data exchange landscape between the impacted payers and providers once providers’ practice management system or EHR make the connection to the payer’s API. That is why it is important for the payers to make the APIs available first. It is burdensome and time-consuming for providers to use multiple mechanisms—including numerous payer-specific web portals and fax numbers—to submit prior authorization requests and receive prior authorization decisions. Our outreach and industry research show that providers are eager for the opportunity to have access to this technology to reduce burden. We request comment on these proposals. We believe that requiring the impacted payers to implement the FHIR PO 00000 Frm 00026 Fmt 4701 Sfmt 4702 based APIs that would be available for providers might ultimately result in broader industry-wide changes to address the prior authorization issues identified by stakeholders and discussed above. Similarly, if the APIs are successfully implemented by the impacted payers as proposed, the demand for this functionality would motivate EHR vendors to invest in integrating a PAS API directly into a provider’s workflow, which might ultimately result in APIs becoming the preferred and primary method to facilitate prior authorization processes. As with the proposed DRLS API, we note that functionality to interact with the proposed PAS API is not standardized across provider systems today, but that industry interest in this initiative is extremely high. Industry participation is increasing in the HL7 work groups developing and testing the IGs for these APIs, including increased participation by providers, payers, and vendors. We believe that EHR developers would increasingly make this functionality available to their customers to support increased use of the payer APIs should this proposed rule be finalized. We request comment on steps that HHS could take to educate providers on the benefits of these APIs and incentive their use. We also request comment on opportunities to encourage health IT developers to implement these functions within EHRs, including the potential future addition of certification criteria in the ONC Health IT Certification Program. a. Requirement To Provide a Reason for Denial When a provider has submitted an electronic prior authorization request, there is an expectation for a response to indicate that an item or service is approved (and for how long), denied, or if there is a request for more information. Regardless of the mechanism through which a prior authorization request is received and processed, in the case of a denial, providers need to know why the request has been denied, so that they can either re-submit it with updated information, identify alternatives, appeal the decision, or communicate the decision to their patients. A payer might deny a prior authorization because the items or services are not covered, because the items or services are not medically necessary, or because documentation to support the request was missing or inadequate. However, payers do not always provide consistent communication about the reasons for denials or information about what is required for approval. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules To improve the timeliness, clarity, and consistency of information for providers regarding prior authorization status, specifically denials, we are proposing that impacted payers send certain response information regarding the reason for denying a prior authorization request. Based on the surveys referenced above, stakeholders agree that payers do not provide consistent information about the status of a prior authorization or the reasons for a denial, nor do they use the adopted X12 278 HIPAA standard transaction to communicate prior authorization status information. Therefore, we propose at 42 CFR 431.80(a)(2)(iii) for Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.80) for Medicaid managed care, at 42 CFR 457.732(a)(2)(iii) for CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 457.732) for CHIP managed care, and at 45 CFR 156.223(a)(2)(iii) for QHP issuers on the FFEs that impacted payers transmit, through the proposed PAS API, information regarding whether the payer approves (and for how long), denies, or requests more information related to the prior authorization request. In addition, we propose at 42 CFR 431.80(a)(2)(iv) for Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.80) for Medicaid managed care, at 42 CFR 457.732(a)(2)(iv) for CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR 457.732) for CHIP managed care, and at 45 CFR 156.223(a)(2)(iv) for QHP issuers on the FFEs that impacted payers include a specific reason for denial with all prior authorization decisions, regardless of the method used to send the prior authorization decision. Under our proposal, impacted payers would be required to provide a specific reason a prior authorization request is denied, such as indicating necessary documentation was not provided, the services are not determined to be medically necessary, or the patient has exceeded limits on allowable (that is, covered) care for a given type of item or service, so that a provider is notified why a request was denied and can determine what their best next steps may be to support getting the patient the care needed in a timely manner. A clear and specific reason for a denial would help ensure both providers and payers have the opportunity to benefit from consistent communication, and supports our drive to reduce payer, provider, and even patient burden. States operating Medicaid and CHIP programs may be able to access federal matching funds to support their VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 implementation of the DRLS and PAS APIs, because these APIs are expected to help the state administer its Medicaid and CHIP state plans properly and efficiently by supporting a more efficient prior authorization process, consistent with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more detail in section II.C.7.a. of this proposed rule. We do not consider state expenditures for implementing this proposal to be attributable to any covered item or service within the definition of ‘‘medical assistance.’’ Thus, we would not match these expenditures at the state’s regular federal medical assistance percentage. However, federal Medicaid matching funds under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs, because use of the DRLS and PAS APIs would help the state more efficiently administer its Medicaid program by increasing the efficiencies in the prior authorization process. For instance, use of these APIs would allow administrative efficiencies by making the process more timely, and by helping reduce the number of denied and appealed prior authorization decisions, making the process more clear and transparent via the APIs. States’ expenditures to implement these proposed requirements might also be eligible for enhanced 90 percent federal Medicaid matching funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent federal matching funds under section 1903(a)(3)(B) of the Act may be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement. States request Medicaid matching funds under section 1903(a)(3)(A)(i) or (B) of the Act through the APD process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to ensure that any system for which they are receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act aligns with and incorporates the ONC Health Information Technology standards adopted in accordance with 45 CFR part 170, subpart B. The DRLS and PAS APIs, and all APIs proposed in this rule, would complement this requirement because these APIs further PO 00000 Frm 00027 Fmt 4701 Sfmt 4702 82611 interoperability through the use of HL7 FHIR standards proposed for adoption by ONC for HHS use at 45 CFR 170.215.47 And, states are reminded that 42 CFR 433.112(b)(10) explicitly supports exposed APIs as a condition of receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act. Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of Medicaid technologies and systems as a condition of receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act. CMS would interpret that sharing and re-use requirement also to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state’s APIs. Making the needed technical documentation publicly available so that systems that need to connect to the APIs proposed in this rule can do so would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the DRLS and PAS APIs. Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act, limiting administrative costs to no more than 10 percent of CHIP payments to the state, would apply in developing the APIs proposed in this rule. We note that the temporary federal medical assistance percentage (FMAP) increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116–127) does not apply to administrative expenditures. b. Program Specific Notice Requirements To Accompany Prior Authorization Denial Information— Medicaid and CHIP Managed Care Some of the payers impacted by this proposed rule are required by existing regulations to notify providers and patients when they have made an adverse decision regarding a prior authorization. The proposal above to send a denial reason would not reduce or replace such existing notification requirements. Rather, the proposed requirement to use the PAS API to provide a notification whether the authorization has been approved (and for how long) or denied (along with a reason for the denial) would supplement current notice requirements for those payers, and offer an efficient method of providing such information for those payers who currently do not have a requirement to notify providers of the decision on a prior authorization request. We believe use of the proposed 47 See SHO # 20–003, https://www.medicaid.gov/ federal-policy-guidance/downloads/sho20003.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82612 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules denial reasons in addition to the notification requirements provides enhanced communication which increases transparency and would reduce burden and improve efficiencies for both payers and providers. For Medicaid managed care plans and CHIP managed care entities,48 existing regulations at 42 CFR 438.210(c) requires notice to the provider without specifying the format or method while 42 CFR 438.210(c) and 42 CFR 438.404(a) require written notice to the enrollee of an adverse benefit determination. As part of our proposal, we intend that an indication of whether the payer approves, denies, or requests more information for the prior authorization request, if transmitted to providers via the PAS API, and a denial reason in the case of denial, would be sufficient to satisfy the current requirement for notice to providers at 42 CFR 438.210(c) and (d). Therefore, the payer would not be required to send the response via the PAS API and a denial reason, as well as a separate notice in another manner to the provider with duplicate information. We remind managed care plans that their obligations to provide these required notices would not be reduced or eliminated regardless of the proposals included in this rule. We acknowledge that some providers may need more time to adapt to submitting prior authorization requests via an API and until such time, we encourage managed care plans to comply with other applicable regulations to ensure that their prior authorization practices and policies do not lead to impeding timely access to care or affect network adequacy. Lastly, we note that the proposal to electronically transmit information through the PAS API about whether the payer approves, denies, or requests more information for the prior authorization request is about notice to the provider and is limited to transmission to a provider’s EHR or practice management system. This proposal would have no effect on the requirements for notice to an enrollee at 42 CFR 438.210(c) and (d) and 438.404. We would like to hear from the provider community how current notifications are received and whether the proposed communication via the PAS API could be more useful than the current notification process. For instance, are the current notifications integrated into EHRs and could this proposal improve communications? 48 CHIP managed care entities are required to comply with these standards by 42 CFR 57.1230(d). VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 5. Seeking Comment on Prohibiting Post-Service Claim Denials for Items and Services Approved Under Prior Authorization During the listening sessions, stakeholders raised concerns about denials of claims for approved prior authorizations explaining that provider staff spend significant time on appeals to resolve these denials, and in some cases, patients receive unexpected bills for the services, after the fact. Generally, a prior authorization is currently only a determination by a payer that an item or service is medically necessary, and is not a promise of payment. However, when a valid claim for an approved service is denied, this creates inefficiencies in processes for both payers and providers and could affect patient care. We wish to learn how new policies could help improve this process, and therefore request input from payers and other industry stakeholders, on the issues that could inform a future proposal to prohibit impacted payers from denying claims for covered items and services for which a prior authorization has been approved. We are requesting input on the criteria that could be included in a new policy, and the potential costs of such a policy on payers. Specifically we are soliciting input on what requirements would be appropriate to include in a policy to ensure that claims that meet certain guidelines for approved authorizations are not denied. In addition, we seek comment on whether it would be important that the patient be enrolled with the payer at the time the items or services were provided, or that certain conditions exist for the provider’s contract status with the payer. And, we seek comment on what other requirements would be appropriate to include in a policy to ensure that the claims that meet certain guidelines for approved authorizations are not denied. We would also like input on the criteria payers could use to deny claims once they are submitted to the claims processing system. For example, do payers deny claims when there is reliable evidence of technical errors, a duplicate claim for the approved item or service, or evidence that an approved prior authorization was procured based on material inaccuracy or by fraud? We believe payers have program integrity practices through which they determine if a prior authorization was procured by fraud, and coordinate investigations under relevant programmatic authorities or state laws. Commenters are encouraged to provide examples of program integrity practices used by PO 00000 Frm 00028 Fmt 4701 Sfmt 4702 payers to identify and address fraudulent claims. We also seek comment on whether all payer types should be required to comply with a policy to prohibit payers from denying a claim for payment after approving a prior authorization for covered items and services, or if any payer types should be excluded, and for what reasons. Finally, we would like input on the unintended consequences, cost implications, and cost estimates related to prohibiting a prior authorized claim from being denied, to the extent data can be provided. We are interested in what legitimate reasons for denial could be restricted by the adoption of specific criteria. We also invite payers to comment on whether such a policy could increase improper payments or program costs, decrease state use of prior authorization, or impact enforcement of third-party liability. If we were to address these topics, we would do so in a future notice and proposed rulemaking. 6. Requirements for Prior Authorization Decision Timeframes and Communications a. Overview of Decision Timeframe Issue We also heard from providers that excessive wait times for prior authorization decisions often caused delays in the delivery of services to patients. One risk of the time burden associated with some of the prior authorization processes is the potential patient harm resulting from delays in responses to prior authorization requests—whether for the approval of the initial request, or delays in the resolution of the request—for example, waiting for a payer’s review and decision based on required documentation for the request. The AMA study reported that 28 percent of physicians stated that delays in care due to the prior authorization process, specifically the wait for approval, led to serious, life-threatening adverse events, including death, for their patients.49 In addition, 91 percent of physicians reported that delays related to prior authorization have had other negative impacts on their patients.50 As described earlier, in 2019 CMS conducted outreach with external 49 American Medical Association. (n.d.). 2017 AMA Prior Authorization Physician Survey. Retrieved from https://www.ama-assn.org/sites/ ama-assn.org/files/corp/media-browser/public/arc/ prior-auth-2017.pdf. 50 American Medical Association. (n.d.). 2017 AMA Prior Authorization Physician Survey. Retrieved from https://www.ama-assn.org/sites/ ama-assn.org/files/corp/media-browser/public/arc/ prior-auth-2017.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 stakeholders through listening sessions, interviews, observational visits, RFIs and a special email box, to obtain information about how to improve the transparency, efficiency, and standardization of the prior authorization process. From the high volume of comments we received on the subject of timeframes for processing prior authorizations, it is apparent that delays in securing approvals for prior authorization directly affect patient care by, for example, delaying access to services, transfers between hospitals and post-acute care facilities, treatment, medication, and supplies. These delays occur, in part, because of the variation in processes used by each payer to review prior authorization requests, inconsistent use of available technologies to process prior authorizations, and the ongoing reliance on manual systems such as phone, fax, and mail, which require more laborintensive human interactions. Some commenters noted that the large variations in payer prior authorization policies for the same items and services and the difficulty discovering each payer’s policies—which requires substantial staff research and time— contribute to delays in care. In this proposed rule, we use the term ‘‘standard’’ prior authorization to refer to non-expedited request for prior authorization and the term ‘‘expedited’’ prior authorization to indicate an urgent request. This is consistent with the provisions at 42 CFR 438.210(d) (for Medicaid managed care plans). A standard prior authorization is for nonurgent items and services. An expedited prior authorization is necessary when failure to decide could jeopardize the health or life of the patient. b. Current Regulations Establishing Timeframes for Certain Payers for Standard and Expedited Prior Authorization Requests We have regulated in this area previously and have established timeframes for certain payers to make decisions and provide notice regarding prior authorizations as well as time requirements for certain decisions on appeals. Specifically, in the Medicaid managed care program, and for CHIP managed care entities, payers must, for standard authorization decisions, make a decision, and send notice of that decision, as expeditiously as the enrollee’s condition requires and within state-established timeframes that may not exceed 14 calendar days following receipt of the request for items or services (42 CFR 438.210(d)(1), 457.495(d), and 457.1230(d)). For cases in which a provider indicates or the VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 payer determines that following the standard timeframe could seriously jeopardize the enrollee or beneficiary’s life, health or ability to attain, maintain, or regain maximum function, the Medicaid managed care plan, or CHIP managed care entity must make an expedited authorization decision and provide notice as expeditiously as the enrollee’s health condition requires, but no later than 72 hours after receiving the request (42 CFR 438.210(d)(2) and 457.1230(d)). In addition, under these existing regulations, the enrollee or the provider may request an extension of up to 14 additional calendar days from the standard timeframe to make a decision on a prior authorization request for an item or service, or the payer may also initiate the extension up to 14 additional calendar days if the payer can justify a need for additional information and how the extension is in the enrollee or beneficiary’s interest (42 CFR 438.210(d)(2) and 457.1230(d)). For example, a payer may need to gather additional information by consulting with additional providers with expertise in treating a particular condition to enable the payer to make a more informed decision. Under existing CHIP regulations, prior authorization of health services must be completed within 14 days after receipt of a request for services or in accordance with existing state law regarding prior authorization of health services (42 CFR 457.495(d)). This means the CHIP managed care entities must decide, and send notice of that decision within 14 calendar days following receipt of the request for a medical item or service by the provider. An extension of 14 days may be permitted if the enrollee requests the extension or if the physician or health plan determines that additional information is needed (42 CFR 457.495(d)(1)). For cases in which a provider indicates, or the payer determines, that the standard timeframe of 14 days could seriously jeopardize the enrollee’s life; health; or ability to attain, maintain, or regain maximum function, the CHIP managed care entity must make an expedited authorization decision and provide notice no later than 72 hours after receiving the request (42 CFR 457.1230(d)). c. Proposals To Address Timeframes for Standard Prior Authorization Requests Given our interest in patient health outcomes, we are proposing to require that state Medicaid and CHIP FFS programs, Medicaid managed care plans, and CHIP managed care entities provide notice of prior authorization decisions as expeditiously as a PO 00000 Frm 00029 Fmt 4701 Sfmt 4702 82613 beneficiary’s health condition requires and under any circumstances not later than 72 hours of receiving a request for expedited decisions. Notice should be provided no later than 7 calendar days after receiving a request for standard decisions. For Medicaid managed care plans, we are also proposing to maintain that an extension of 14 days is authorized if the enrollee requests it or a health plan determines additional information is needed. We are not proposing at this time to change timeframes for prior authorization (pre-service) claims processes for QHP issuers on the FFEs, as further discussed below. We are not proposing that a prior authorization would be automatically approved should the impacted payer fail to meet the required timeframe. If the deadline is missed, providers may need to contact the payer to determine the status of the request and whether additional information is needed. Further, under the Medicaid managed care rules (at 42 CFR 438.404(c)(5)), a payer’s failure to decide within the required timeframe is considered a denial and the right to appeal that denial is available to the enrollee or provider. We are not proposing to change this existing rule. In addition to these proposals, we request comments on the impact of proposing a policy whereby a payer would be required to respond to a prior authorization request within the regulated timeframes, and if the payer failed to meet the required timeframe, the prior authorization would be automatically approved. We are interested in stakeholder feedback on the potential volume of such occurrences, the costs to payers in increasing prior authorization staffing levels or inappropriate items and services and the benefits to providers and patients in terms of reduced burden and faster access to necessary items and services. We propose at 42 CFR 440.230(d)(1)(i) for Medicaid FFS, at 42 CFR 457.495(d) for CHIP FFS, at 42 CFR 438.210(d) for Medicaid managed care, at 42 CFR 457.1233 for CHIP managed care (through the existing requirement to comply with 42 CFR 438.210), that impacted payers must meet these timeframes beginning January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). We are not proposing to change the timeframes that apply to expedited authorization decisions made by Medicaid managed care plans and CHIP managed care entities under 42 CFR 438.210(d)(2) and 457.1230(d), which already apply a 72 hour E:\FR\FM\18DEP2.SGM 18DEP2 82614 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 timeframe, with an opportunity to extend the timeframe by up to 14 days under certain conditions. d. Requirements for Notifications Related to Prior Authorization Decision Timeframes This section addresses current requirements for certain impacted payers to maintain communications about prior authorization decisions with patients through notifications, in concert with our proposals to improve the timeliness of prior authorization decisions. For Medicaid, we are proposing a new paragraph (d)(1)(i) at 42 CFR 440.230 to specify regulatory timeframes for providing notice of both expedited and standard prior authorization requests. The new requirements would be applied to prior authorization decisions beginning January 1, 2023. Under this proposal for Medicaid, notice of the state Medicaid program’s decision regarding an expedited request for prior authorization would have to be communicated as expeditiously as a beneficiary’s health condition requires, and in any event not later than 72 hours after receiving a provider’s request for an expedited determination. Notice of a decision on a standard request for a prior authorization would have to be communicated to the requesting provider as expeditiously as a beneficiary’s health condition requires, and under any circumstance, within 7 calendar days. If the state determines that it needs additional information from a provider to make a decision, or if the beneficiary or provider requests an extension, this proposed decisionmaking and communication timeframe could be extended by up to 14 calendar days. State Medicaid FFS programs must also comply with the requirements in section 1927 of the Act regarding coverage and prior authorization of covered outpatient drugs. Nothing in this proposed rule would change these requirements. This proposal is consistent with section 1902(a)(19) of the Act, which requires that care and services be provided in a manner consistent with simplicity of administration and the best interests of recipients, because it is expected to help make the prior authorization process less burdensome for the state, providers, and beneficiaries. The proposed requirements and standards could result in more prompt prior authorization decisions, improve delivery of covered services, reduce burden on providers, and improve efficiency of operations for the program, thereby serving the best interest of Medicaid beneficiaries. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 Under current Medicaid notice and fair hearing regulations, notice and fair hearing rights already apply to state decisions about Medicaid fee-for-service prior authorization requests. Specifically, Medicaid notice and fair hearing regulations apply to all prior authorization decisions, including partial or total denials of prior authorization requests, failures to make prior authorization decisions in a timely fashion, and terminations, suspensions of, and reductions in benefits or services for which there is a current approved prior authorization. We propose the following changes in regulation text to make it explicit that existing Medicaid notice and fair hearing rights apply to Medicaid fee-for-service prior authorization decisions. First, we propose a new paragraph (1)(ii) in 42 CFR 440.230(d) to specify that states must provide beneficiaries with notice of the Medicaid agency’s prior authorization decisions and fair hearing rights in accordance with 42 CFR 435.917 and part 431, subpart E. Second, we propose to revise the definition of an ‘‘action’’ at 42 CFR 431.201 to include termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization. We also propose to revise the definition of the term ‘‘action’’ to improve readability. Third, to align with our proposal at 42 CFR 431.201 (definition of ‘‘action’’) and 42 CFR 440.230(d)(1)(ii), we propose to modify 42 CFR 431.220(a)(1) to add a new paragraph (vi) to add a prior authorization decision to the list of situations in which a state must provide the opportunity for a fair hearing. Fourth, we propose a modification to 42 CFR 435.917(b)(2) to add a notice of denial or of change in benefits or services to the types of notices that need to comply with the requirements of 42 CFR 431.210. Finally, we propose modifications to the headers at 42 CFR 435.917(a) and (b) to clarify that the information contained in 42 CFR 435.917 relates broadly to eligibility, benefits, and services notices. Specifically, we propose to remove the word ‘‘eligibility’’ from the headers of paragraphs (a) and (b) of 42 CFR 435.917 to more accurately reflect the content of these paragraphs. These proposed changes are intended to make it explicit in regulation text how existing Medicaid fair hearing regulations apply to states’ prior authorization decisions. As noted above, the partial or total denial of a prior authorization request is appealable through a state fair hearing under current regulations. Even though current PO 00000 Frm 00030 Fmt 4701 Sfmt 4702 regulations at 42 CFR 431.220(a)(1) do not expressly refer to denials of prior authorization requests, a denial of a prior authorization request is a denial of benefits or services as described in that section because a prior authorization denial results in denial of coverage of a benefit or service requested by the beneficiary. Therefore, the state must provide a beneficiary who receives a partial or total denial of a prior authorization request the opportunity to have a fair hearing.51 Similarly, under current regulations at 42 CFR 431.220(a)(1), the state must provide beneficiaries the opportunity to request a fair hearing if the state fails to act on a claim with reasonable promptness. Just as states must furnish medical assistance to eligible individuals with reasonable promptness under section 1902(a)(8) of the Act, states must also provide individuals with access to a fair hearing if the state fails to act on a claim for medical assistance with reasonable promptness under section 1902(a)(3) of the Act. Therefore, for example, after January 1, 2023, the failure to render a prior authorization decision within the timeframe at proposed 42 CFR 440.230(d)(1)(i) would be considered a failure to act with reasonable promptness and subject to fair hearing rights available to individuals under 42 CFR part 431, subpart E. Finally, existing regulations require that states grant Medicaid beneficiaries the opportunity for a fair hearing whenever a state takes an action as defined in 42 CFR 431.201. This definition includes ‘‘a termination, suspension of, or reduction in covered benefits or services.’’ Therefore, under the current definition of ‘‘action’’ at 42 CFR 431.201, any termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization is considered an action for which the state must afford a beneficiary the opportunity for a fair hearing in accordance with 42 CFR 431.220(a)(1). The proposed changes at 42 CFR 440.230(d)(1)(ii) are also intended to make it explicit in regulation text that existing Medicaid notice regulations apply to states’ prior authorization 51 See discussion in the ‘‘Medicaid and Children’s Health Insurance Programs: Eligibility Notices, Fair Hearing and Appeal Processes for Medicaid and Other Provisions Related to Eligibility and Enrollment for Medicaid and CHIP’’ final rule (hereinafter ‘‘Eligibility and Appeals Final Rule’’), published in the Federal Register on November 30, 2016 (81 FR 86382, 86395)(approvals of prior authorization requests for an amount, duration, or scope that is less than what the beneficiary requested are subject to fair hearing requirements in 42 CFR 431, subpart E). E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules decisions. Under 42 CFR 435.917(a), a state must provide timely and adequate written notice of its prior authorization decisions, consistent with 42 CFR 431.206 through 431.214. This notice must include information about the beneficiary’s fair hearing rights. Under our proposals, a state would be required to provide notice of a decision within the timeframes in 42 CFR 440.230(d)(1)(i) when the state approves or partially or totally denies a prior authorization request after January 1, 2023. However, whenever a state makes a prior authorization decision that is considered an action, including the termination, suspension of, or reduction in benefits or services for which there is a current approved prior authorization, the state must provide the individual at least 10 days advance notice consistent with 42 CFR 431.211 prior to taking the action and afford the beneficiary the right to the continuation of services pending the resolution of the state fair hearing, in accordance with 42 CFR 431.230. Under 42 CFR 431.206(c)(2), the state must inform the beneficiary in writing whenever a fair hearing is required per 42 CFR 431.220(a), which includes when a state has not acted upon a claim with reasonable promptness. For example, after January 1, 2023, this would mean that a state must also provide notice to the beneficiary when it fails to reach a decision on a prior authorization request within the timeframes in proposed 42 CFR 440.230(d)(1)(i). To enhance beneficiary notice, we are proposing to explicitly link the required notice content in 42 CFR 431.210 to denials of or changes in benefits or services for beneficiaries receiving medical assistance by proposing amendments to 42 CFR 435.917(b)(2) to include a reference to denials of or changes in benefits and services for beneficiaries receiving medical assistance. The notice content requirements at 42 CFR 431.210 include a requirement that notices include a clear statement of the specific reasons supporting the intended action, so this proposed amendment would ensure that individuals receiving medical assistance who are denied benefits or services receive a notice clearly explaining the reasons for a denial. As we explained above, because a denial of a prior authorization request is a denial of a benefit or service, this change would also apply to notices for denials of prior authorization decisions. We note that the current application of existing notice and fair hearing requirements to Medicaid fee-for-service prior authorization decisions, which we propose to make explicit in regulation VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 text, is consistent with current regulations for notice and appeal rights for managed care prior authorization decisions (sometimes referred to as service authorizations or adverse benefit determinations). See 42 CFR 438.400 (definition of adverse benefit determination), 42 CFR 438.404 (timely and adequate notice for adverse benefit determination), and 42 CFR 438.420 (continuation of benefits while managed care plan appeal and the state fair hearing process are pending). As noted above, these proposed modifications generally apply existing regulations to prior authorization decisions and do not generally change Medicaid notice or fair hearing policy. As such, we propose that the revisions to 42 CFR 431.201, 431.220, 431.917, and 440.230(d)(1)(ii) would be effective upon publication of the final rule, with the understanding that any notice or fair hearing rights based solely on new provisions proposed in this rulemaking would take effect in accordance with the proposed effective date for the proposed new provisions, including the proposed timeframes for notifications about prior authorization decisions. We seek comment both on how states apply these notice and fair hearing rights to prior authorization decisions currently and on our proposals. We also seek comment on whether we should change this policy through future rulemaking, and not require fair hearing rights for prior authorization denials. To implement the proposed authorization timeframes for Medicaid managed care, we also propose to revise 42 CFR 438.210(d)(1). Under our proposal, the new timeframes for Medicaid managed care plans to issue decisions on prior authorization requests would apply beginning with the rating period on or after January 1, 2023. Therefore, we propose to add at the end of the current regulation that, beginning with the rating period that starts on or after January 1, 2023, the state-established timeframe that a decision may not exceed 7 calendar days following the plan’s receipt of the request for service would go into effect. This effectively would limit the period of time that a Medicaid managed care plan must make and provide notice of an authorization decision to a maximum of 7 days (or fewer if the state establishes a shorter timeline) unless there is an extension. We propose that the authority to extend that timeframe by up to 14 additional calendar days would continue to apply. Our proposal would not change the current provisions for how failure to issue a decision within the required time frame constitutes an adverse benefit PO 00000 Frm 00031 Fmt 4701 Sfmt 4702 82615 determination that can be appealed under 42 CFR 438.404(c)(5). Section 438.404 and the other regulations governing appeal rights in 42 CFR part 438, subpart F, would continue to apply. This is also consistent with how the definition of ‘‘adverse benefit determination’’ in 42 CFR 438.400(b) includes a failure of a Medicaid managed care plan to make an authorization decision within the regulatory timeframes. We also note that under current regulations at 42 CFR 438.3(s)(1) and (s)(6) and 438.210(d)(3), Medicaid managed care plans must also comply with the requirements in section 1927 of the Act regarding coverage and prior authorization of covered outpatient drugs. Nothing in this proposed rule would change these requirements. We also note that Medicaid managed care plans that are applicable integrated plans as defined in 42 CFR 438.2 would continue to follow the decision timeframes defined in 42 CFR 422.631(d). We believe implementing these proposed prior authorization timeframes for Medicaid FFS and managed care programs would help states to ensure that they are furnishing medical assistance services with reasonable promptness as described in section 1902(a)(8) of the Act and with reasonable program safeguards to ensure that services would be provided in the best interests of the recipients, in accordance with section 1902(a)(19) of the Act. In addition, this proposal would implement section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization must establish an internal grievance procedure under which an enrollee who is eligible for medical assistance may challenge the denial of coverage of or payment for such assistance. Reducing plan response time for prior authorizations should enable enrollees to file appeals timelier, when needed, and receive faster resolution. The prior authorization proposals in this rule, particularly the proposal to reduce the maximum amount of time for a managed care plan to make a standard prior authorization decision from 14 days to 7 days, are consistent with how section 1932(c)(2)(A) of the Act indicates that timely access to care should be assured for enrollees. Currently, and under our proposal, 42 CFR 438.210 applies the same appeal and grievance requirements for PIHPs and PAHPs as for MCOs; for this proposal, we rely on our authority in section 1902(a)(4) to adopt these standards for PIHPs and PAHPs. This is consistent with our prior practice for adopting standards for Medicaid E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82616 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules managed care plans (81 FR 27507). We believe that the proposal to shorten the maximum amount of time for a plan to make a prior authorization decision from 14 days to 7 days would improve the efficient operation of the Medicaid program by facilitating faster receipt of services or filing of appeals. We are not proposing any changes to the required timeframes for expedited decisions at 42 CFR 438.210(d)(1) nor the authority for a 14-day extension provided at 42 CFR 438.210(d)(1) and (2)(ii). This proposed requirement would be applicable to CHIP managed care through the cross reference to 42 CFR 438.210 in current 42 CFR 457.1230(d). To implement the proposed prior authorization timeframes for CHIP, we propose to revise 42 CFR 457.495, such that beginning January 1, 2023, decisions related to prior authorization of health services would be required to be completed in accordance with the medical needs of the patient, but no later than 7 calendar days after the date of the receipt of the request for a standard determination and 72 hours following the receipt of the request for an expedited determination. We are retaining the authority for an extension of up to 14 days to be granted if the enrollee requests or the physician or health plan determines that additional information is needed. We propose to remove the option for states to follow existing state law regarding prior authorization of health services, requiring states to instead follow these updated timeframes. However, if state laws are more stringent, states are not prohibited from complying with enhanced decision timelines. We believe timely prior authorization decisions are an important beneficiary protection, and CHIP beneficiaries should be afforded the same decision timeframes as Medicaid beneficiaries. We seek comment on this proposal, and most specifically from states. Existing CHIP regulations at 42 CFR 457.1130(b) require a state to ensure that an enrollee has an opportunity for external review of health services matters, including a delay, denial, reduction, suspension, or termination of health services, in whole or in part, including a determination about the type or level of service. Under this regulation, CHIP enrollees must have an opportunity for external review of prior authorization decisions. We are not proposing any changes to this requirement, as it already applies to decisions related to the prior authorization of services. In the case of QHP issuers on the FFEs, regulations at 45 CFR 147.136 VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 establish internal claims and appeals processes, external review processes, and pre-service claims requirements for all non-grandfathered group and individual market plans or coverage. Specifically, at 45 CFR 147.136(b)(3), individual health insurance issuers are required to meet minimum internal claims and appeals standards. To avoid adding to the burden that this proposal might impose by applying multiple, potentially inconsistent regulatory standards for individual and group market plans, we are considering, and solicit comments on, whether to extend the timeframes for processing of prior authorizations applicable to other payers, as discussed in this section, to QHP issuers on the FFEs. Specifically, we seek comment on whether having different processing timelines for prior authorizations for QHP issuers on the FFEs would be operationally feasible for issuers, or if such a requirement would have the unintended effect of increasing burden for issuers that are already subject to different requirements.52 Finally, we note that the alternative of making changes to regulations applicable to all non-grandfathered group and individual market plans or coverage for consistency with our proposed approach here would be outside the scope of this regulation. Overall, we believe that the decision timeframes proposed for the impacted payers in this rule would help ensure that prior authorization processes do not inappropriately delay patient access to necessary services. The introduction of decision timeframes that are the same across all impacted payers for items and services that require prior authorization would also help providers better organize and manage administrative resources and allow more time for providers to render patient-centered care. We believe these proposals would make substantive progress in improving the care experience for patients and lead to better health outcomes. In turn, better health outcomes would contribute to more efficient use of program resources. We request comment on these proposals, specifically those that include feedback on any unintended consequences of these proposed policies to reduce payer decision timeframes. In addition to comments on the proposals regarding timelines and notifications, we seek comment on several related topics. For example, are 52 We are not proposing in this proposed rule to impose on individual and group market plans generally timelines for processing of prior authorizations consistent with those we propose for other payers, as such requirements would require rulemaking by the Departments of Labor, the Treasury, and Health and Human Services. PO 00000 Frm 00032 Fmt 4701 Sfmt 4702 alternative timeframes feasible or appropriate for prior authorization for items and services? • Under what circumstances could payers approve an expedited prior authorization in less than the proposed 72 hours? Are there circumstances in which a payer should be required to approve an expedited prior authorization in 24 hours for items and services other than prescription or outpatient drugs? What are the operational and system requirements for a more streamlined scenario for prior authorization approvals? • Under what circumstances could an approval be provided in less than 7 calendar days for a complex case? • We also seek comment on process challenges with prior authorization. For example, are there scenarios that could be appropriate to support temporary coverage of services, such as, temporary access to DME, while the patient waits for an authorization during the 14-day review timeframe? What policy conditions might be necessary to include in such authorization determinations? Commenters are encouraged to provide examples of bestcase and worst-case scenarios, and explain what changes in process, policy, or technology would be necessary. 7. Proposed Extensions, Exemptions and Exceptions for Medicaid and CHIP and QHP Issuers a. Extensions and Exemptions for Medicaid and CHIP FFS Programs If our proposals regarding the DRLS and PAS APIs are finalized, we would strongly encourage state Medicaid and CHIP FFS programs to implement these APIs as soon as possible, in light of the many benefits of these APIs as discussed previously in this section. However, we also recognize that state Medicaid or CHIP FFS agencies could face certain unique circumstances that would not apply to other impacted payers, as discussed in more detail later in this section. As a result, a few states might need to seek an extension of the compliance deadline or an exemption from these requirements. To address this concern, we are proposing a process through which states may seek an extension of and, in specific circumstances, an exemption from, the DRLS and PAS API requirements if they are unable to implement these API requirements, consistent with the extension and exemption proposals for the Provider Access API in section II.B., and the Payer-to-Payer API in section II.D. of this proposed rule. Providing these flexibilities might allow these states to continue building technical E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules capacity in support of overall interoperability goals consistent with their needs. We therefore propose the following. Extension. At 42 CFR 431.80(b)(1) and 42 CFR 457.732(b)(1) respectively, we propose to provide states—for Medicaid FFS and CHIP FFS—the opportunity to request a one-time extension of up to one (1) year for the implementation of the PAS API specified at 42 CFR 431.80(a)(1) and 42 CFR 457.732(a)(2) and DRLS API specified at 42 CFR 431.80(a)(1) and 42 CFR 457.732(a)(1). Unique circumstances that might present a challenge to specific states to meet the proposed compliance date could include resource challenges, such as funding. Depending on when the final rule is published in relation to a state’s budget process and timeline, some states may not be able to secure the needed funds in time to both develop and execute implementation of the API requirements by the proposed compliance data. A one-year extension could help mitigate this issue. And, some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state’s implementation of these proposed API policies. The timeline for an open, competed procurement process, together with the time needed to onboard the contractor and develop the API, could require additional time as well. Finally, a state might need to hire new staff with the necessary skillset to implement this policy. Again, the time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult, because, generally speaking, public employee hiring processes include stricter guidelines and longer time-to-hire periods than other sectors.53 In all such situations, a state might need more time than other impacted payers to implement the requirements. If a state believes it can demonstrate the need for an extension, its request must be submitted and approved as a part of its annual Advance Planning Document (APD) for MMIS operations costs and must include the following: (1) A narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from 53 State hiring processes are comparable with federal hiring processes. According to OMB, the average time-to-hire for federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See: https:// www.opm.gov/news/releases/2020/02/opm-issuesupdated-time-to-hire-guidance/. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 circumstances that are unique to states operating Medicaid or CHIP FFS programs; (2) a report on completed and ongoing implementation activities to evidence a good faith effort toward compliance; and (3) a comprehensive plan to meet implementation requirements no later than one year after the initial compliance date. An extension would be granted if CMS determines based on the information provided in the APD that the request adequately establishes a need to delay implementation, a good faith effort to implement the proposed requirements as soon as possible, and a clear plan to implement no later than one year after the proposed compliance date. We would expect states to explain why the request for an extension results from circumstances that are unique to states operating Medicaid or CHIP FFS programs. We solicit comment on whether our proposal would adequately address the unique circumstances that affect states, and that might make timely compliance with the proposed API requirement sufficiently difficult for states, and thus justify an extension. In particular, we seek comment on whether we should require or use additional information on which to base the determination or whether we should establish different standards in the regulation text for evaluating and granting the request. Exemption. At 42 CFR 431.80(b)(2) and 42 CFR 457.732(b)(2), respectively, we propose two circumstances that would permit state requests for exemption; namely, (1) when at least 90 percent of all covered items and services are provided to Medicaid or CHIP beneficiaries through Medicaid or CHIP managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or (2) when at least 90 percent of the state’s Medicaid or CHIP beneficiaries are enrolled in Medicaid or CHIP managed care organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10 for CHIP. In both circumstances, the time and resources that the state would need to expend to implement the API requirements may outweigh the benefits of implementing and maintaining the API. As discussed in section II.B. of this proposed rule, unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology in which they have invested to be leveraged for additional beneficiaries as states, unlike PO 00000 Frm 00033 Fmt 4701 Sfmt 4702 82617 other payers, do not maintain additional lines of business. We acknowledge that the proposed exemption could mean that a few Medicaid or CHIP FFS systems would not receive the benefits of having these APIs available to facilitate health information exchange. To address this, we propose that states meeting the above thresholds would be expected to employ an alternative plan to enable the electronic exchange and accessibility of health information for those beneficiaries who are served under the FFS program. A state meeting the above criteria would be permitted to submit a request for an exemption to the requirements for the DRLS and PAS APIs once per calendar year for a one (1) year exemption. The state would be required to submit this annual request as part of a state’s annual APD for MMIS operations costs. The state would be required to include in its request document that it meets the criteria for the exemption using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. We propose that this request be made annually as from year-to-year the nature of the FFS population could change and so it is important that the state provide the most current information for CMS’s consideration. Exemptions would be granted for a one-year period if a state establishes to CMS’s satisfaction that it meets the criteria for the exemption and has established a plan to ensure that providers would have efficient electronic access to the same information through alternative means. We request comment on the proposed extension and exemption. For Medicaid and CHIP managed care, we are not proposing an extension process at this time because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements in 42 CFR part 438 and part 457, and also benefit from efficiencies resulting from their multiple lines of business impacted by these interoperability policies. Many managed care plans are part of parent organizations that maintain multiple lines of business, including plans on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or are unachievable by the compliance date. We are soliciting comment on whether E:\FR\FM\18DEP2.SGM 18DEP2 82618 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 our belief concerning the scope of resources and ability of managed care parent organizations to achieve economies of scale is well-founded. Further, we seek comment on whether an extension process is warranted for certain managed care plans to provide additional time for the plan to comply with requirements at proposed 42 CFR 431.80(a)(1) and 431.80(a)(2), which cross references 42 CFR 438.242(b)(5) for Medicaid managed care plans and at proposed 42 CFR 457.732(a)(1) and 457.732(a)(2) which cross reference 42 CFR 457.1223(d)(2) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary for the reasons outlined here, we are open to considering one if necessary. If we adopt an extension process for these managed care plans and entities, what criteria would a managed care plan or entity have to meet to qualify for an extension? Should the process consider, for example, enrollment size, plan type, or some unique characteristic of certain plans that could hinder their implementation of the proposed requirements by the proposed compliance date? Also, we seek comment on whether, if we finalize such a process for Medicaid managed care plans or CHIP managed care entities, the state or CMS should manage the process and whether states could successfully adopt and implement the process on the timeline necessary to fulfill the goals and purpose of the process. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(d), we would expect any extension request to include, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, the impact of noncompliance upon enrollees, the current or proposed means of providing electronic health information to providers, and a corrective action plan with a timeline to achieve compliance. We request comment on this proposal. b. Exceptions for QHP Issuers For QHP issuers on the FFEs, we propose an exceptions process to the DRLS API requirements proposed at 45 CFR 156.223(a)(1) and the PAS API requirements at proposed at 45 CFR 156.223(a)(2). We propose that if an issuer applying for QHP certification to be offered through an FFE believes it cannot satisfy the requirements to establish one or both of these APIs, the QHP issuer would have to include, as part of its QHP application: (1) A VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year; (2) the impact of non-compliance upon enrollees; (3) the current or proposed means of providing health information to providers; and (4) solutions and a timeline to achieve compliance with the requirements of this section. Further, we propose that the FFE may grant an exception if it determines that making a health plan available through the FFE is in the interests of qualified individuals in the state or states in which such FFE operates. This exceptions process is proposed at 45 CFR 156.223(b). As we noted in the Interoperability and Patient Access Final Rule at 45 CFR 156.221(h), we anticipate that the exception would be provided in limited situations. For example, we would consider providing an exception to small issuers, issuers who are only in the individual market, financially vulnerable issuers, or new entrants to the program who demonstrate that deploying standards based API technology would pose a significant barrier to the issuer’s ability to provide coverage to consumers, however, not certifying the issuer’s QHP or QHPs would result in consumers having few or no plan options in certain areas. We believe that having a QHP issuer offer QHPs through an FFE is in the best interests of consumers. We seek comment on other circumstances in which the FFE should consider granting an exception. We request comment on these proposed extensions, exemptions and exceptions for Medicaid and CHIP FFS, Medicaid and CHIP managed care, and the QHP issuers on the FFEs. 8. Public Reporting of Prior Authorization Metrics We are proposing to require impacted payers to publicly report certain prior authorization metrics on their websites at the state-level for Medicaid and CHIP FFS, at the plan-level for Medicaid and CHIP managed care, and at the issuerlevel for QHP issuers on the FFEs. As discussed in section II.C.11. of this proposed rule, publicly reporting these metrics would support efficient operations, timely service, and ensure prior authorization processes are executed in such a way as to be in the best interest of patients. Specifically, public reporting of this information would provide patients and providers with important information about Medicaid managed care plans, CHIP managed care entities, and QHP issuers when the patient is making a decision about a plan. When looking for a new plan, patients may compare a variety of PO 00000 Frm 00034 Fmt 4701 Sfmt 4702 factors including, but not limited to, access to care (authorizations), premiums, benefits, and cost sharing or coinsurance. We believe access to care is a critical factor for patients to consider when choosing a plan, and transparency regarding prior authorization processes could be an important consideration. Similarly, providers may find metrics about prior authorization approvals or appeals useful when selecting payer networks to join, and when considering whether to contract with a payer. Providers should be armed with information about how they will be able to treat their patients, and whether that will be in a manner they believe will support value-based care and services that are appropriate and necessary for each patient’s health. Therefore, we are proposing to require state Medicaid and CHIP FFS programs at 42 CFR 440.230(d)(2) and 457.732(a)(3), respectively; Medicaid managed care plans at 42 CFR 438.210(f); CHIP managed care entities through operation of existing 42 CFR 457.1233(d)(2); and QHP issuers on the FFEs at 45 CFR 156.223(a)(3) to publicly report, at least annually, prior authorization metrics on their websites or via publicly accessible hyperlink(s). We propose that each metric would be reported separately for each item and service, not including prescription drugs and/or covered outpatient drugs, and that the data would be required to be publicly reported for each metric. We propose that these metrics would include, at a minimum, the following: • A list of all items and services that require prior authorization; • The percentage of standard prior authorization requests that were approved, reported separately for items and services; • The percentage of standard prior authorization requests that were denied, reported separately for items and services; • The percentage of standard prior authorization requests that were approved after appeal, reported separately for items and services; • The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, reported separately for items and services; • The percentage of expedited prior authorization requests that were approved, reported separately for items and services; • The average and median time that elapsed between the submission of a request and a decision by the payer, plan or issuer, for standard prior E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules authorizations, reported separately for items and services. In this proposal, when we state ‘‘reported separately for items and services,’’ we mean each payer would report a percentage for all prior authorization requests in a given year that meet the specified criteria for requests that were for items and a percentage for all prior authorization requests that year for the same criteria that were for services. In this way, a payer’s prior authorization requests would be separated into two distinct categories, and these metrics would, if this proposal is finalized, be reported for each of these categories. By sharing information about prior authorization requirements for items and services, and data about prior authorization decisions, patients and providers would have a better understanding of a payer’s prior authorization review and approval processes. Such information may be helpful for making decisions at the time of open enrollment, special enrollment, or plan selection throughout the year. We are proposing that, beginning March 31, 2023, these data be publicly reported annually, by the end of the first calendar quarter each year for the prior year’s data. For example, for all impacted payers, all available data for calendar year 2022 would be publicly reported by the end of the first calendar quarter of 2023, or by March 31, 2023. We acknowledge that the first set of publicly available data would reflect current practices, rather than payer behavior based on compliance with this proposed rule. However, should our proposals be finalized, we anticipate that, over time, data might show improvements. In addition, year-overyear comparisons could demonstrate positive (or negative) trends, which alone could be useful information for patients who are making enrollment decisions. Publicly available data would aid interested providers and patients in understanding payer performance with respect to prior authorization processes for decisions, approvals, denials, and appeals. We request comments on the proposed reporting of metrics on prior authorization requests, including comments on the proposal to report a separate percentage for all prior authorization requests in a given year that meet the criteria for items and a separate percentage for all prior authorization requests that year for the criteria that were for services, and comments on the proposed reporting dates. In order to more directly facilitate the incorporation of such data into a VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 consumer-friendly comparison tool, we may consider proposing in future rulemaking to use these data to help develop quality measures to incorporate into quality star ratings across certain payer programs over time, specifically for QHP issuers on the FFEs. For Medicaid managed care, we propose to remove the text currently at 42 CFR 438.210(f), which addresses the applicability date for the provisions in that section. That text was added in 2016 to clarify that the prior requirements in that section would remain in effect until the new provisions begin starting with rating periods beginning on or after July 1, 2017. As several rating periods have passed since July 1, 2017, we do not believe this clarifying text is needed. We propose to replace the current text at 42 CFR 438.210(f) with the proposed public reporting of prior authorization metrics, as explained above. 9. Request for Comments on ‘‘GoldCarding’’ Programs for Prior Authorization During the CMS listening sessions, we heard about the potential for additional efficiencies in the prior authorization process, through certain payer policies, including decisions about when to require prior authorization. For example, prior authorization is sometimes required for certain items and services that are almost always approved or for some providers who have demonstrated a history of complying with all payer requirements. Stakeholders stated that it could be more efficient and cost effective if prior authorization requirements were minimized or removed in these cases. Some payers have implemented what they term ‘‘gold-carding’’ or similar programs to relax or reduce prior authorization requirements for providers that have demonstrated a consistent pattern of compliance. For example, some payers have relieved certain providers from the requirement to request prior authorizations based on data indicating adherence to submission requirements, appropriate utilization of items or services, or other evidencedriven criteria that they deem relevant. CMS uses an approach similar to goldcarding in the Medicare FFS Review Choice Demonstration for Home Health Services, under which home health agencies in demonstration states that select certain review choice options and have a review affirmation rate or claim approval rate of 90 percent or greater over 6 months are given the option to continue in the pre-claim review program or choose a selective post- PO 00000 Frm 00035 Fmt 4701 Sfmt 4702 82619 payment review or spot check review process.54 We believe the use of gold-carding programs could help alleviate provider burden related to prior authorization and believe these programs could facilitate more efficient and prompt delivery of health care services to beneficiaries. We encourage payers to adopt gold-carding approaches that would allow prior authorization exemptions or more streamlined reviews for certain providers who have demonstrated compliance with requirements. Gold-carding policies could reduce burden on providers and payers, while improving the patient experience. By taking this step, payers can join CMS in helping to build an infrastructure that would allow clinicians to deliver care in a timely and value-based manner. While we are not including any proposals here, and are not intending to be overly prescriptive in defining requirements in future rulemaking for gold-carding programs, we emphasize the importance of reducing provider burden and seek comment for consideration for future rulemaking on how best to measure whether and how these types of approaches and programs actually reduce provider and payer burden. To further encourage the adoption and establishment of gold-carding programs, we have considered including gold-carding as a factor in quality star ratings, where applicable, as a way for payers to raise their score in the quality star ratings for QHP issuers. We seek comment for potential future rulemaking on the incorporation of gold-carding into star ratings for QHP issuers on the FFEs. We also considered proposing gold-carding as a requirement in payer’s prior authorization policies and seek comment on how such programs could be structured to meet such a potential requirement. 10. Additional Requests for Comment We seek comment on additional topics pertaining to prior authorization, as feedback may be useful for future rulemaking. We understand from our listening sessions that there may be opportunities to improve the prior authorization process for individuals with chronic medical conditions. For example, when a patient has a chronic condition that 54 Centers for Medicare and Medicaid Services. (2019, October 7). Review Choice Demonstration for Home Health Services. Retrieved from https:// www.cms.gov/Research-Statistics-Data-andSystems/Monitoring-Programs/Medicare-FFSCompliance-Programs/Review-ChoiceDemonstration/Review-Choice-Demonstration-forHome-Health-Services.html. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82620 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules requires ongoing treatment, the provider is often required to resubmit repeated prior authorization requests for the same service, each time treatment is needed. One such condition described in listening sessions was macular degeneration. Patients shared their experience of needing monthly prior authorizations for their monthly injection treatments, despite the fact that those injections are required to avoid loss of vision, and despite the fact that there is no cure for their condition. Repeatedly submitting a prior authorization request for the same item or service, which is always approved, creates a burden on both the patient and the provider and adds costs to the overall health care system. We seek comment on whether there should be certain restrictions regarding requirements for repeat prior authorizations for items and services for chronic conditions, or whether there can be approvals for long term authorizations. What alternative programs are in place or could be considered to provide long-term authorizations for terminal or chronic conditions? Another topic identified in listening sessions was patient concerns about losing access to approved services after changing health plans. Patients expressed concern about being able to continue a specific course of care where, for example, they might be in the middle of an approved course of care requiring physical therapy, but then change health plans (payer). We seek comments on whether a prior authorization decision should follow a patient when they change from one qualified health plan on the Exchange to another, or to another health plan impacted by this proposed rule, and under what circumstances that prior authorization could follow a patient from payer to payer. We also seek comment for potential future rulemaking on other prior authorization topics, such as whether prior authorizations should be valid and accepted for a specified amount of time. We are interested in comments on who should determine how long an existing approved prior authorization from a previous payer should last and whether prior authorization should be regulated by amount of time and/or by condition. An additional topic from our listening sessions was the issue of the number of different forms used by payers for prior authorization requests, each with different information requirements (data elements) and methods for submission. The lack of standard forms and requirements from payers is considered burdensome and time consuming for VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 both patients and providers. We request input on solutions to standardizing prior authorization forms, including the possibility of developing an HL7 FHIR based questionnaire for prior authorization requests. Input on requiring the use of a standardized questionnaire could inform future rulemaking. Finally, we request comments on how to potentially phase out the use of fax technology to request and send information for prior authorization decisions. As we described earlier in this section, we believe the standardsbased API process should be the preferred and primary form of exchanging prior authorization communications. However, we acknowledge that providers could vary in their ability to develop and implement API-based prior authorization submission and receipt technology and that there must be a channel for prior authorization for providers whose systems are not APIcapable. In particular, we anticipate that providers in rural areas, small providers, and certain types of service providers, such as home and community-based services providers in Medicaid, may be subject to prior authorization processes but may not have the technical expertise, access to high speed internet, infrastructure, or financial resources to implement connectivity with and use the DRLS and PAS APIs. Further, non-API mechanisms like fax, phone, and web portals may be needed in times when other technology is not available or other unexpected emergencies. We request comment on how payers and providers might begin to phase out the use of fax technology, and what barriers must still be overcome to accomplish this goal. As mentioned previously in this proposed rule, although Medicare FFS is not directly impacted by this rule, we do note that we are evaluating implementation of these provisions, if finalized. In this way, Medicare FFS implementations would conform to the same requirements that apply to the impacted payers under this rulemaking, as applicable, so that participating Medicare providers and beneficiaries would benefit from the APIs and process improvements. 11. Statutory Authorities To Require Prior Authorization Burden Reduction Proposals a. Medicaid and CHIP For the reasons discussed below, our proposed requirements in this section for Medicaid managed care plans and PO 00000 Frm 00036 Fmt 4701 Sfmt 4702 Medicaid state agencies fall generally under our authority in section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. The proposals in this section are also authorized under section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. Additionally, they are authorized by section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. The proposed requirement for the states and Medicaid managed care plans to implement the DRLS and PAS API (section II.C.3. and II.C.4. of this proposed rule; statutory authority for proposals to require specific IGs is discussed in section II.A.3. of this proposed rule) is expected to improve the efficiency and timeliness of the prior authorization process for Medicaid beneficiaries, providers, and state Medicaid agencies and Medicaid managed care plans by addressing inefficiencies that appear to exist in the process today. These proposals would ensure that all states and Medicaid managed care plans would provide easily accessible information about when a prior authorization is required, and what documentation requirements must be fulfilled to submit the request. The DRLS API would allow a provider to determine if a prior authorization is required, and what the documentation requirements are for that prior authorization request. When using the PAS API, the state or Medicaid managed care plan would send a real time response to a provider’s request with the status of the request included. Use of these APIs by states (for FFS programs) and managed care plans could ensure that Medicaid providers are able to submit a request for a prior authorization with the correct and complete documentation, and avoid an incorrect submission which might result in an unnecessary denial. The PAS API would: (i) Enable providers to submit a prior authorization request faster and easier, (ii) support more timely notice to provider and beneficiary of the disposition of the prior authorization request sooner, and (iii) permit faster scheduling of services or filing appeals, depending on the decision. The DRLS API and the PAS API both have the potential to improve the prior E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules authorization process by making it more efficient, including by limiting the number of denials and appeals, or even by eliminating requests for additional documentation, as noted elsewhere. For the state, these requirements would thus align with section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. For the Medicaid managed care program, these requirements align with section 1932(c)(1)(A)(i) of the Act, which requires that states using managed care organizations must develop and implement a quality assessment and improvement strategy that includes standards for evaluating access to care so that covered services are available within reasonable timeframes. The proposal would implement section 1932(b)(4) of the Act, which provides that each Medicaid managed care organization must establish an internal grievance procedure under which an enrollee who is eligible for medical assistance may challenge the denial of coverage of or payment for such assistance. This proposal would enable enrollees to file appeals, when needed, and support them in receiving resolution. Our proposal to clarify that current notice and fair hearing requirements apply to Medicaid fee-for-service prior authorization decisions is authorized under section 1902(a)(3) of the Act. Section 1902(a)(3) of the Act requires that a Medicaid state plan provide for granting an opportunity for a fair hearing to any individual whose claim for medical assistance under the plan is denied or is not acted upon with reasonable promptness. These proposed clarifications are also supported by the 14th Amendment to the United States Constitution and case law on due process, specifically, Goldberg v. Kelly, 397 U.S. 254 (1970). States must establish timely notice and fair hearing processes meeting due process standards under Golberg v. Kelly, as incorporated into existing Medicaid fair hearing regulations at 42 CFR part 431, subpart E; see 431.205(d). The proposed requirement that states and Medicaid managed care plans meet certain timeframes to provide notice of decisions for prior authorizations, including the requirements that expedited decisions be made and communicated in 72 hours and standard decisions be made and communicated in 7 calendar days, may provide an improvement from the current standards for decision timeframes for Medicaid VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 managed care (section II.C.6. of this proposed rule). The proposal is intended to establish more certainty in the prior authorization process for Medicaid providers and enhance beneficiary access to timely and appropriate care, consistent with states’ obligations to provide Medicaid services with reasonable promptness and in a manner consistent with beneficiaries’ best interests. Improved decision timeframes could improve communication to providers and beneficiaries, as well as increase access to care. The proposal is consistent with, and might help states comply with, section 1902(a)(8) of the Act, which requires the provision of medical assistance with reasonable promptness. A uniform and consistent timeline for Medicaid program prior authorization decisions might improve beneficiaries’ prompt access to Medicaid-covered services. Standardizing Medicaid prior authorization decision timeframes could also support process improvements for the state and Medicaid managed care plans, including the creation of standard operating procedures and internal metric reports for program operations. This is consistent with section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. The proposal is also authorized under section 1902(a)(17) of the Act, as implemented under the existing Medicaid regulations at 42 CFR 440.230. This section of the Act requires state Medicaid programs to establish reasonable standards that are consistent with the objectives of title XIX of the Act to determine the extent of covered medical assistance. As set forth at 42 CFR 440.230, these standards could include appropriate limits on a service based on such criteria as medical necessity or on utilization control procedures, so long as each service is sufficient in amount, duration, and scope to reasonably achieve its purpose. Items and services covered under Title XIX benefit authorities are subject to 42 CFR 440.230, unless statute or regulation expressly provides for an exception or waiver. This would include covered items and services described in sections 1905(a), 1915(c), 1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any other authorities as established by Congress. The proposal is also consistent with section 1902(a)(19) of the Act, which requires that care and services be provided in a manner consistent with PO 00000 Frm 00037 Fmt 4701 Sfmt 4702 82621 simplicity of administration and the best interests of recipients, because it is expected to help make the prior authorization process less burdensome for the state, providers, and beneficiaries. The proposed requirements and standards could result in more prompt prior authorization decisions, improve delivery of covered services, and improve efficiency of operations for the program, thereby serving the best interest of Medicaid beneficiaries. Our proposal to require states and Medicaid managed care plans to publicly report prior authorization metrics (section II.C.8. of this proposed rule) would support CMS and state Medicaid agency oversight, and evaluation and administration of the state plan, as it would allow for an evaluation of the implementation of the policies proposed in this rule. The data may indicate that payers have implemented the APIs (by showing improvements in prior authorization numbers) or made other improvements in policies and processes that result in improved metrics in the areas that we propose to be reported. Section 1902(a)(6) of the Act authorizes us to request reports from state Medicaid agencies in such form and containing such information as the Secretary may require from time to time. By reporting metrics, states and Medicaid managed care plans could review data to identify areas for improvement. Requiring Medicaid managed care plans to publicly report their prior authorization metrics would hold them accountable and enable them to more easily monitor their own performance and identify process improvement opportunities which could be an integral part of implementing a quality assessment and improvement strategy, consistent with the requirements for quality strategies for managed care programs at section 1932(c)(1)(A)(i) of the Act. For CHIP, we propose these requirements under the authority in section 2101(a) of the Act, which sets forth that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, lowincome children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. This provision authorizes us to adopt these requirements for CHIP because they would also provide access to program data, which can improve the efficacy of CHIP programs, and allow for more efficient administration of services. As discussed above, we propose to require implementation of the DRLS API and PAS API (section II.C.3. and II.C.4. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82622 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules of this proposed rule; statutory authority for proposals to require specific IGs is discussed in section II.A.3. of this proposed rule) to improve the prior authorization process for patients, providers and payers by addressing deficiencies and inefficiencies that exist in the current process. Today, a payer’s rules about when a prior authorization is required, and what documentation requirements must be fulfilled to submit the request are not easily accessible for providers, which requires phone calls, access to multiple websites, and use of hard copy manuals, etc. This takes time away from actual patient care. The DRLS API allows a provider to determine if a prior authorization is required, and what the documentation requirements are for that prior authorization request. While we expect providers to be the primary stakeholders that benefit from the DRLS API, making this information available in a standardized way and permitting access through an API also serves the requirements in section 2101(a) of the Act that CHIP ensure access to coverage and coordinate care. The proposed PAS API would be a mechanism for receiving and responding to requests for coverage determinations before the services are furnished; the PAS APIs would streamline the initial authorization process for the payer, by sharing this information in an easily accessible way; this also allows the provider to know what to do if a prior authorization is required for a certain service, which improves the providers ability to treat the patient timely. The proposed PAS API would enable the payer to send a real time response back to a provider, based on a request for authorization. This too would improve the efficiency of providing services to the patient, because the request and response would be automated, and in real time. Payer use of these APIs could ensure that a provider is able to submit a request for a prior authorization with the correct and complete documentation to avoid an incorrect submission which might result in an unnecessary denial. The PAS API would: (i) Enable providers to submit a prior authorization request faster and easier, (ii) support more timely notice to provider and enrollee of the disposition of the prior authorization request, and (iii) permit faster scheduling of services or filing appeals, depending on the decision. The DRLS API and the PAS API both have the potential to improve the prior authorization process by making it more efficient, including limiting the number of denials and appeals, or even VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 eliminating requests for additional documentation, as noted elsewhere. The proposed requirement that CHIP FFS and managed care entities meet certain timeframes to provide decisions for prior authorizations, including the requirement that expedited decisions be given in 72 hours and standard decisions be given in 7 calendar days, is an improvement from the current state, when there is uncertainty about expectations for when a prior authorization might be approved (section II.C.6. of this proposed rule). The proposal is intended to establish more certainty in the prior authorization process for providers and enhance patient access to timely and appropriate care. As payers provide notice under a shorter timeframe, patients would have more timely access to care. This is often not the case today, as providers and patients could wait longer for the payer to respond to a request for certain services. This could have an impact on health, particularly for individuals with chronic conditions or who have health risks. Improving certainty around decision timeframes could also reduce administrative time and expense, because providers would not need to make repeat inquiries to payers for a status on the authorization request. The proposal to improve timeliness in responding to providers and patients could support process improvements for the state and managed care programs and is consistent with our authorities under section 2101(a) of the Act in that they improve the efficiency of the CHIP programs. Our proposal to require CHIP FFS and CHIP managed care entities to report prior authorization metrics also supports the states oversight, evaluation and administration responsibilities, as it would allow us to evaluate the impact of the prior authorization policies in this proposed rule (section II.C.8. of this proposed rule). The data may indicate use of the APIs (improvements in prior authorization numbers) or changes in total numbers, denials and appeals. b. QHP Issuers on the FFEs For QHP issuers on the FFEs, we are proposing these new requirements pursuant to the authority of section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. We believe that the policies included here would improve the efficiency of the issuers who are certified to PO 00000 Frm 00038 Fmt 4701 Sfmt 4702 participate in the QHP program and improve the quality of services they provide to providers and their patients. Qualified individuals in FFEs may receive covered services more quickly, and the information may be more accurate with the use of the APIs. These proposals could improve the quality of the patient experience with their providers by increasing the efficiency in the prior authorization submission and review process. Therefore, we believe generally, that certifying only health plans that implement FHIR based APIs and adhere to the other proposals herein, would be in the interests of qualified individuals in the state or states in which an FFE operates. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchanges. In sections II.C.3. and II.C.4. of this rule, we propose that QHPs implement two APIs for the prior authorization process (statutory authority for proposals to require specific IGs are discussed in section II.A.3. of this proposed rule). The DRLS API would allow providers to quickly and efficiently know if a prior authorization is needed and locate the documentation requirements easily. This would enable faster, more accurate submission of prior authorization requests and potentially more prompt delivery of services. We also propose that QHPs implement a PAS API, to allow providers to efficiently, and with greater simplicity submit prior authorization requests directly from within their workflow and would allow QHP issuers to respond to the prior authorization request quickly and efficiently, thus enabling more prompt delivery of services. We also include in our proposal that QHPs provide a denial reason when sending a response to a prior authorization request, to facilitate better communication and understanding between the provider and issuer. This could enable efficient resubmission of the prior authorization request with additional information or an appeal, which could more promptly facilitate the needed patient care. Finally, proposing to require QHP issuers to publicly report prior authorization metrics would hold issuers accountable to their providers and patients, which could help them improve their program administration (section II.C.8. of this proposed rule.). These data could help QHPs evaluate their processes and determine if there are better ways to leverage the APIs, including the quality and sufficiency of E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules the coverage and documentation information included in the APIs. D. Payer-to-Payer Data Exchange on FHIR 1. Background khammond on DSKJM1Z7X2PROD with PROPOSALS2 Research shows that the more complete a patient’s record is, and the more data there are at the point of care, the better patient outcomes can be.55 More data lead to better-coordinated care and more informed decisionmaking. Data sharing among payers is one powerful way to facilitate this critically valuable flow of information through the health care ecosystem. As a result, in the CMS Interoperability and Patient Access final rule, we finalized a requirement for certain impacted payers to exchange, at a minimum, clinical information as defined in the USCDI version 1 (85 FR 25568 through 25569). We did not specify an API standard for data sharing in that final rule, however, understanding at the time that there may be a variety of transmission solutions that payers could employ to meet this requirement. We did encourage impacted payers to consider the use of a FHIR-based API in line with the larger goal of leveraging FHIR-based APIs to support a number of interoperability use cases for improving patient, provider, and payer access to health care data in order to reduce burden, increase efficiency, and ultimately facilitate better patient care. In addition, we also signaled our intent to consider a future requirement to use FHIR-based APIs for payer-to-payer data sharing, envisioning the increasing implementation of FHIR-based APIs within the industry. In the time since we proposed the initial payer-to-payer data exchange requirements in the CMS Interoperability and Patient Access rule, we have begun to leverage new tools, most notably the HL7 FHIR Bulk Data Access (Flat FHIR) specification, as discussed in more detail in section II.B. of this proposed rule. We believe the 55 Office of the National Coordinator. (2019, June 4). Improved Diagnostics & Patient Outcomes. Retrieved from https://www.healthit.gov/topic/ health-it-basics/improved-diagnostics-patientoutcomes. 55 See SHO # 20–003, https://www.medicaid.gov/ federal-policy-guidance/downloads/sho20003.pdf. 55 HL7 International. (n.d.). Da Vinci Payer Coverage Decision Exchange (PCDE) FHIR IG. Retrieved from https://www.hl7.org/fhir/us/davincipcde/history.cfml. 55 State hiring processes are comparable with federal hiring processes. According to OMB, the average time-to-hire for federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See https:// www.opm.gov/news/releases/2020/02/opm-issuesupdated-time-to-hire-guidance/. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 HL7 FHIR Bulk Data Access (Flat FHIR) specification, in particular, provides an opportunity to continue to build upon the requirement for payer-to-payer data sharing in a way that adds valuable efficiencies for payers, further simplifying administration and reducing burden. We believe that the suite of tools that the CMS Interoperability and Patient Access final rule (85 FR 25510) requires and that this proposed rule would require for payers would ultimately lead to payers having more complete information available to share with patients and providers. As a result, we are now proposing an enhanced set of payer-to-payer data-sharing requirements that would build on the policy finalized in the CMS Interoperability and Patient Access final rule (85 FR 25568 through 25569) by leveraging FHIR-based APIs to further support greater interoperability and information flow. 2. Payer-to-Payer Data Exchange on FHIR There are three primary proposals we are making regarding the payer-to-payer data exchange in this proposed rule. First, we propose to extend the payerto-payer data exchange to state Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 457.731(b). We previously finalized in the CMS Interoperability and Patient Access final rule (85 FR 25568 through 25569) that MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs were required, at the patient’s request, to share a specified subset of clinical data with another payer of the patient’s choice. Second, we propose to enhance this payer-to-payer data exchange triggered by a patient’s request beyond what was previously finalized (for MA organizations, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs) in the CMS Interoperability and Patient Access final rule. In the final rule, we required impacted payers to exchange, at the patient’s request, clinical data as defined in the USCDI, but we did not finalize in what electronic form or how these data would be transmitted. In this rule, we are proposing to require a FHIR-based API for this data exchange. In addition, we propose that this standards-based API must be conformant with specific IGs. We also propose that this Payer-to-Payer API, at the patient’s request, must make not just clinical data as defined in the USCDI available, but also claims and encounter data (not including cost information), and information about pending and PO 00000 Frm 00039 Fmt 4701 Sfmt 4702 82623 active prior authorization decisions. We propose these enhancements to the required payer-to-payer exchanges for Medicaid managed care plans (other than NEMT PAHPs) at 42 CFR 438.242(b)(7), CHIP managed care entities at 42 CFR 457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 156.221(f)(2). We are also proposing to include these enhancements as part of extending the payer-to-payer data exchange requirements to Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 42 CFR 457.731(b). We believe these proposed enhancements would facilitate more efficient data sharing between payers. In addition, the proposed additions to the data the API must be able to share would be consistent with the proposals discussed in sections II.A. and II.B. of this proposed rule, which would require these payers to share the same types of data with patients and providers via FHIR-based APIs. This would add efficiencies for payers and maximize the value of the work being done to implement APIs, overall reducing burden for all impacted payers. Third, we propose a second payer-topayer data exchange policy that would use this Payer-to-Payer API to facilitate data sharing between payers at enrollment. When a patient enrolls with a new payer or when a patient identifies concurrent coverage, we propose that the patient would have an opportunity to opt-in to this data sharing. Unlike the payer-to-payer exchange finalized previously, where the patient must make a request to initiate the data sharing, under this proposal the patient would be presented with data sharing as an option at enrollment. As more than one patient could be moving from one payer to another at enrollment, this new Payer-to-Payer API proposal to share data at enrollment would include a requirement for impacted payers to facilitate data sharing both for individual patients and for more than one patient using the HL7 FHIR Bulk Data Access (Flat FHIR) specification, discussed previously in section II.B. of this proposed rule. We are proposing to codify the requirement for this Payer-toPayer API, including use of the HL7 FHIR Bulk Data Access (Flat FHIR) specification, at 42 CFR 431.61(c) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b) for QHP issuers on the FFEs. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82624 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 3. Payer-to-Payer Data Sharing in Medicaid and CHIP In the CMS Interoperability and Patient Access final rule, we did not include Medicaid and CHIP FFS programs in the payer-to-payer data exchange policies. In that rule, we also did not specify how these data must be exchanged. As discussed in sections II.B.6.d. and II.C.7., and again later in this section of this proposed rule, Medicaid and CHIP FFS programs can face unique circumstances that might make it more challenging for them to meet new requirements within the same timeframe as other payers. As a result, in our first phase of interoperability policy, we chose to limit the burden on these programs so they could focus their attention and resources on implementing the Patient Access and Provider Directory APIs. Now that we are looking to transition the payer-topayer data exchange to an API, and understanding the fact that this new API will be leveraging the same data and technical standards, and nearly all the same implementation guides as the Patient Access API, we believe that asking these programs to now implement this payer-to-payer data exchange via a Payer-to-Payer API would not be as burdensome as it would have been had we required these FFS programs to implement a payer-to-payer data exchange that does not require an API in the CMS Interoperability and Patient Access final rule effective January 1, 2022. By the time these programs would need to start preparing to implement this new Payer-to-Payer API, they are expected to have implemented the Patient Access API, and they would thus be able to leverage the work done for that to make implementing this new API more manageable. As a result, we now propose to extend this requirement to Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 457.731(b), respectively. In the case of Medicaid and CHIP FFS programs, the state agency is the ‘‘payer’’ that can share patient data with other payers. As we discuss in more detail in section II.D.4. of this proposed rule, use of the Payer-to-Payer API could improve operational efficiencies for the state, thereby reducing burden for the state, and leading to better coordinated patient care and improved health outcomes. We thus expect the proposed Payer-to-Payer API requirement to lead to more effective administration of the state plan, and to better enable Medicaid and CHIP programs to ensure care and services are provided in a manner that is consistent with their beneficiaries’ VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 best interests. Ensuring that information can follow Medicaid and CHIP beneficiaries as they enter the programs could potentially lead to better care coordination for these patients, and better continuity of care. It could also reduce burden for patients and providers. Payers would have additional information to share via the Patient Access API and the Provider Access API. As a result, patients would have more readily available information to support informed decision making, and providers would have more information about the care their patients are receiving. This could potentially lead to fewer duplicate tests or less time taken collecting and recollecting information about the patient during a visit. Any opportunity a state takes to evaluate the data from a patient’s previous payer could allow the state to avoid wasteful or unnecessary action that the previous payer may have already completed, such as an involved process or series of tests to support receipt of certain services. In this way, extending this Payer-to-Payer API to state Medicaid and CHIP programs could benefit them by helping them to operate more efficiently. Also, as discussed in the CMS Interoperability and Patient Access final rule (85 FR 255664 through 25569), we believe there are numerous benefits for payers to be able to maintain a cumulative record of their current patients’ health information. If payers do so, they can make information available to patients and their providers and can help ensure that patient information follows patients as they move from provider to provider and payer to payer. We believe it is important to propose that Medicaid and CHIP FFS agencies facilitate this data access and sharing for their beneficiaries, so that the benefits of both the data sharing required in the final rule and the data sharing proposed in sections II.A. through the Patient Access API and II.B. through the Provider Access API of this proposed rule would extend to Medicaid and CHIP FFS beneficiaries in the same way across other impacted payers. In this way, as a patient moves in and out of Medicaid or CHIP FFS, they will not lose access to their health information—that information would continue to follow them to new payers and providers by virtue of payers being able to send and receive their data and make it available to the patient and providers through these APIs. States operating Medicaid and CHIP programs may be able to access federal matching funds to support their implementation of this Payer-to-Payer PO 00000 Frm 00040 Fmt 4701 Sfmt 4702 API, because this API is expected to lead to more efficient administration of the Medicaid and CHIP state plans and improved care coordination and health outcomes for Medicaid beneficiaries consistent with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more detail in section II.D.8.a. of this proposed rule. Consistent with the discussion regarding funding and the Provider Access API proposal discussed in section II.B. of this proposed rule and the DRLS and API APIs in section II.C., we do not consider state expenditures for implementing this Payer-to-Payer API proposal to be attributable to any covered item or service within the definition of ‘‘medical assistance.’’ Thus, we would not match these expenditures at the state’s regular federal medical assistance percentage. However, federal Medicaid matching funds under section 1903(a)(7) of the Act, at a rate of 50 percent, for the proper and efficient administration of the Medicaid state plan, might be available for state expenditures related to implementing this proposal for their Medicaid programs, because use of the Payer-to-Payer API would help ensure that payers can access data that could improve their ability to render Medicaid services effectively, efficiently, and appropriately, and in the best interest of the patient. States’ expenditures to implement these proposed requirements might also be eligible for enhanced 90 percent federal Medicaid matching funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can be attributed to the design, development, or installation of mechanized claims processing and information retrieval systems. Additionally, 75 percent federal matching funds under section 1903(a)(3)(B) of the Act may be available for state expenditures to operate Medicaid mechanized claims processing and information retrieval systems to comply with this proposed requirement. States request Medicaid matching funds under section 1903(a)(3)(A)(i) or (B) of the Act through the Advance Planning Document (APD) process described in 45 CFR part 95, subpart F. States are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to ensure that any system for which they are receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act aligns with and incorporates the ONC Health Information Technology standards adopted in accordance with 45 CFR part 170, subpart B. The Payerto-Payer API, and all APIs proposed in this rule, complement this requirement E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules because these APIs further interoperability through the use of HL7 FHIR standards proposed for adoption by ONC for HHS use at 45 CFR 170.215.56 And, states are reminded that 42 CFR 433.112(b)(10) explicitly supports exposed APIs as a condition of receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act. Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of Medicaid technologies and systems as a condition of receiving enhanced federal financial participation under section 1903(a)(3)(A)(i) or (B) of the Act. As noted in section II.B. of this proposed rule, CMS would interpret that sharing and re-use requirement also to apply to technical documentation associated with a technology or system, such as technical documentation for connecting to a state’s APIs. Making the needed technical documentation publicly available so that systems that need to connect to the APIs proposed in this rule can do so would be required as part of the technical requirements at 42 CFR 431.60(d) for all proposed APIs in this rule, including the Payer-to-Payer API. Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act, limiting administrative costs to no more than 10 percent of CHIP payments to the state, would apply in developing the APIs proposed in this rule. Again, we note that the temporary federal medical assistance percentage (FMAP) increase available under section 6008 of the Families First Coronavirus Response Act (Pub. L. 116–127) does not apply to administrative expenditures. In the CMS Interoperability and Patient Access final rule, the payer-topayer data exchange is required for Medicaid managed care plans with an applicability date of January 1, 2022 and codified at 42 CFR 438.62(b)(1)(vi) and (vii). Because this rule proposes to require implementation and use of a Payer-to-Payer API for Medicaid FFS programs, and to be consistent with the other provisions of this rule, we propose to codify the requirement for states in connection with Medicaid FFS programs at 42 CFR 431.61(b), amend the requirement specific to Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii) to sunset the requirements at 438.61(b)(1)(vi) when the new requirements take effect with the rating period beginning on or after January 1, 2023, and revise 42 CFR 438.242(b)(7) to add a requirement for Medicaid managed care plans to comply 56 See SHO # 20–003, https://www.medicaid.gov/ federal-policy-guidance/downloads/sho20003.pdf. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 with the requirement imposed on Medicaid FFS program using a cross reference to 42 CFR 431.61. Codifying the requirement for Medicaid managed care plans this way would ensure that the same standards for payer-to-payer data exchange apply across the Medicaid program, regardless of it is through the FFS or managed care delivery system. Similarly, we are proposing revisions to the CHIP managed care regulations to require CHIP managed care entities to comply with the requirement for an API for payer-to-payer data exchanges that applies to CHIP FFS programs; the CHIP managed care entities would also have to comply by the rating period beginning on or after January 1, 2023. We propose to codify this policy for CHIP managed care entities at 42 CFR 457.1233(d)(4). Because CHIP managed care entities are required by current 42 CFR 457.1216 to comply with 42 CFR 438.62, our proposed revisions to 42 CFR 438.62 (for Medicaid managed care plans) would also apply to CHIP managed care entities. We request comment on these proposals. 4. Enhancing the Payer-to-Payer Data Exchange—Payer-to-Payer API In the Interoperability and Patient Access final rule, we established a payer-to-payer data exchange that required certain impacted payers to share clinical data as defined in the USCDI version 1 data set with the approval and at the direction of a current or former enrollee. We did not require that this data exchange take place using an API, though we encouraged payers to look at an API solution. We are now proposing to enhance this payer-to-payer data exchange in two ways. First, we are proposing to require that this payer-topayer data exchange take place via an API. Second, we propose to require impacted payers to make available, at a minimum, not only the USCDI version 1 data, but also claims and encounter data (not including cost information) that the payer maintains with a date of service on or after January 1, 2016, conformant with the same IGs proposed for these data types in sections II.A. and II.B. of this rule, as well as information about pending and active prior authorization decisions, beginning January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023) via this standards-based Payer-to-Payer API. This Payer-to-Payer API is proposed to use the technical standards and the same base content and vocabulary PO 00000 Frm 00041 Fmt 4701 Sfmt 4702 82625 standards used for the Patient Access API. These proposed requirements would be codified for Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 42 CFR 457.731(b), Medicaid managed care plans other than NEMT PAHPs at 42 CFR 438.242(b)(7), CHIP managed care entities at 42 CFR 457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 156.221(f)(2). Ultimately, we believe sharing this information across payers can improve operational efficiencies, reduce unnecessary care, reduce care costs, and improve patient outcomes. Consistent with what was finalized in the CMS Interoperability and Patient Access final rule, impacted payers who receive these data would be required to incorporate the data into the payer’s records about the enrollee, making these data part of the data maintained by the receiving payer. We note that unless expressly stated as part of a specific proposal, CMS is not proposing to require the receiving payer to specifically review or act on the data received from other payers. As explained in the CMS Interoperability and Patient Access final rule for the Payer-to-Payer Data Exchange, payers could choose to indicate the part of a data exchange that was received from a previous payer so a future receiving payer, provider, or even patient, would know where to direct questions (such as how to address contradictory or inaccurate information); and we propose that the same principle would apply to this enhancement. As noted in the CMS Interoperability and Patient Access final rule (85 FR 25566), impacted payers would be under no obligation under this proposal to review, utilize, update, validate, or correct data received from another payer. However, if a payer should choose to review or otherwise use received data, the payer would not be prohibited from doing so under any of the policies in this proposed rule. We believe a patient’s current payer is in an optimal position to maintain a cumulative record for the patient and facilitate that record following the patient through their health care journey. Whereas patients may see many providers, patients’ payers have a more holistic view of a patient’s care across providers over time. It is important to note that, under these proposals, impacted payers would not be required to exchange any cost information, such as enrollee costsharing and provider remittances. While there could be some value to patients accessing this cost information via the Patient Access API, sharing this cost information between payers would have only limited beneficial impact on care E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82626 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules coordination. We believe that sharing claims and encounter information without the cost details, however, could complement the clinical data as defined in the USCDI by providing more information to support care coordination and efficient operation, including, for example, information about the patient’s care history. As we discussed in the CMS Interoperability and Patient Access final rule, and in section II.B. of this proposed rule, claims and encounter data, used in conjunction with clinical data, can offer a broader and more holistic understanding of an individual’s interactions with the health care system (85 FR 25523). In addition, we believe it would be highly valuable for payers to share pending and active prior authorization decisions generally, and particularly when a patient enrolls with a new payer. Currently, when a patient enrolls with a new payer, little to no information is sent from the previous payer to the new payer about the prior authorization decisions the previous payer made or was in the process of making relevant to the patient’s ongoing care. While some previous payers will make this information available to the new payer upon request, most new payers do not request such information. Instead, most payers with a newly enrolling patient require the treating provider to request a new prior authorization, even for items or services for which a patient has a valid and current prior authorization approval. The burden of repeating the prior authorization process with the new payer falls on the provider and patient, which often impedes continuity of care, impacting patient outcomes and complicating care coordination. In addition, it adds burden to payers who must expend time and effort to review a potentially unnecessary and duplicative prior authorization request. While we do not propose to require the new payer that would receive the prior authorization information and documentation under this proposal to specifically consult this information, at the very least this information would now form part of the patient’s cumulative record and thus be available to be shared by the payer with the patient and the patient’s care team. Should a payer choose to consult this information, it could reduce payer, provider, and patient burden, and possibly cost, over time. If a new payer consulted this information, it could mean fewer prior authorization requests the provider needs to send and the payer needs to process. Patients would VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 not have to wait for a new prior authorization for an item or service they have already demonstrated they need and would benefit from. This is especially true of patients with chronic conditions who are changing payers. As a result, sharing this information between payers could have a significant impact on payers, providers, and patients. Payers and providers could see reduced burden, and patients could experience better, continuous care. We discuss prior authorization and our proposals regarding prior authorization processes in more depth in section II.C. of this proposed rule. As part of this Payer-to-Payer API proposal, we propose at 42 CFR 431.61(b) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(b) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.221(f)(2) for QHP issuers on the FFEs to require all impacted payers make available pending and active prior authorization decisions (and related clinical documentation and forms) via the Payer-to-Payer API using the HL7 FHIR Da Vinci Payer Coverage Decision Exchange (PCDE) 57 IG proposed at 45 CFR 170.215(c)(4) and integrate this information into the patient’s record for review and consideration. For purposes of this proposal, ‘‘active prior authorization decisions’’ means prior authorizations that are currently open, and being used to facilitate current care, and are not expired or no longer valid. By ‘‘pending prior authorization decision,’’ we mean prior authorizations that are under review, either pending submission of documentation from the provider, or being evaluated by the payer’s medical review staff, or for another reason have not yet had a determination made. As discussed in section II.A.2. of this proposed rule, when we say ‘‘items and services,’’ for purposes of this rule, we are talking about items and services excluding prescription drugs and/or covered outpatient drugs. ‘‘Status’’ of the prior authorization means information about whether the prior authorization is approved, denied, or if more information is needed to complete the request. We are proposing that impacted payers, consistent with the proposals for the Patient Access API in section II.A. and the Provider Access API in section II.B. of this proposed rule, limit sharing to pending and active authorizations to reduce the volume of outdated or 57 HL7 International. (n.d.). Da Vinci Payer Coverage Decision Exchange (PCDE) FHIR IG. Retrieved from https://www.hl7.org/fhir/us/davincipcde/history.cfml. PO 00000 Frm 00042 Fmt 4701 Sfmt 4702 irrelevant information shared between payers. We propose that this documentation would include the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date. We request comment on this proposal. In addition to these proposals, we also seek comment for possible future rulemaking on the extent to which we should consider explicitly requiring payers to demonstrate that they have reviewed and considered these previous prior authorization decisions and associated clinical documentation from a patient’s previous payer before requiring patients to undergo a new prior authorization process. Such a requirement could minimize the possibility of duplicate testing for the purposes of reaffirming coverage or renewing a prior authorization for a covered benefit that is part of the patient’s current care plan. As discussed in section II.C., providers experience burden when navigating through each payer’s set of prior authorization policies or rules. It is a burden to payers to administer a prior authorization process. In addition, requiring a new prior authorization can also delay patient care. We also seek comment for possible future rulemaking on whether to, in the alternative, require payers to honor a previous payer’s active prior authorization decisions at the time the enrollee moves from one payer to a new payer for some length of time, such as 30, 45, or 60 days, or if there are situations where this may not be possible or appropriate and why. This Patient Access API requirement was finalized at 42 CFR 422.119(a) through (e) for MA organizations, 42 CFR 431.60(a) through (e) for Medicaid FFS, 42 CFR 438.242(b)(5) for Medicaid managed care, 42 CFR 457.730(a) through (e) for CHIP FFS, 42 CFR 457.1233(d) for CHIP managed care, and at 45 CFR 156.221(a) through (e) for QHP issuers on the FFEs (85 FR 25558 through 25559). Further, we are proposing the same content and compliance with the same technical standards, the same documentation requirements, and the same discontinuation and denial of access requirements for the Patient Access API (discussed in section II.A. of this proposed rule) and the Provider Access API (discussed in section II.B. of this proposed rule) as we are proposing for this proposed Payer-to-Payer API. This degree of overlap and use of the same requirements should ease the burden for payers in developing and implementing these various APIs. E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 In addition, all of these APIs would need to be conformant with the same IGs proposed for claims and encounter data as well as the USCDI version 1 data as discussed in section II.A. for the Patient Access API and section II.B. of this proposed rule for the Provider Access API. The Patient Access API, in particular, provides the foundation necessary to share claims, encounter, and clinical data. Because the same data elements would be exchanged through all three APIs, payers would have already formatted these data elements and prepared their systems to share these standardized data via a FHIRbased API, doing much of the work needed to implement this Payer-toPayer API. As a result, we believe payers would have devoted the development resources needed to stand up a FHIR-based API infrastructure that could be adapted for expanded interoperability use cases after 2021, when they have implemented the Patient Access API. However, we are proposing that the Payer-to-Payer API and the Patient Access and Provider Access APIs be conformant with different IGs for sharing prior authorization decisions. In sections II.A. and II.B. of this proposed rule, we propose that the Patient Access and Provider Access APIs would need to be conformant with the PDex IG when sharing prior authorization decisions with patients and providers, respectively. We propose to require the Payer-to-Payer API be conformant with the PCDE IG instead, when sharing this information, as this IG addresses data sharing between payers more specifically. PDex would be better suited for an exchange from a payer to patients and providers. Given the shared FHIR resources across the two IGs, we do not believe requiring the use of both IGs—one for each appropriate recipient of the data—adds significant burden to payers. 5. Payer-to-Payer API—Sharing Data at Enrollment As finalized in the CMS Interoperability and Patient Access final rule, the payer-to-payer data exchange is initiated at the direction of the patient. We discussed proposed enhancements to this patient-directed data sharing in the previous section where we noted this data exchange would now require the use of an API and include additional data to be shared. In addition to this case-by-case, patient-directed data sharing, however, we also propose a second, new Payer-to-Payer API data sharing opportunity that would be offered to all patients receiving coverage from a payer impacted by this proposed VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 rule as an option at the time of enrollment with a new payer, if both the current payer and new payer would be subject to the requirements in this proposal. We propose to codify this new Payer-to-Payer API requirement at 42 CFR 431.61(c) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b) for QHP issuers on the FFEs. We are proposing that this exchange be offered to patients receiving coverage from payers impacted by this proposed rule as an option when they enroll with a new payer. The new payer, if an impacted payer under this proposed rule, could then request the data from the previous payer for patients who optin to this data sharing via the Payer-toPayer API. We are proposing the following if a patient enrolls during a specified annual open enrollment period, or, for a payer that does not have such an enrollment period, during the first calendar quarter of each year. If such a patient opts-in to having their new payer obtain the applicable data from their previous payer at this specified time, we are proposing to require that impacted new payers request such data from the previous payers via the Payer-to-Payer API using the HL7 FHIR Bulk Data Access (Flat FHIR) specification within one week of the end of the enrollment period or the first calendar quarter of each year. The previous payer, if an impacted payer, would be required to respond to this request within one business day of receiving the request. We do recognize that not every impacted payer has a dedicated annual open enrollment period. For those payers, we are proposing that the opt-in Bulk data sharing occur at the end of the first calendar quarter of each year. We seek comment on whether this is the best time to require the data sharing for such payers. Based on our experience with Bulk data sharing discussed in section II.B.4. of this proposed rule, and based on discussions with payers and technology developers, we believe the efficiencies afforded by having at least one time per year where payers could facilitate this data sharing and employ the Bulk specification to leverage the opportunity to make data available for as many patients as possible at one time could be potentially significant because such an asynchronous data sharing option could limit drain on system resources and promote a dedicated and efficient opportunity each year to ensure patients have their health information follow them as they move from payer to payer, permitting better care PO 00000 Frm 00043 Fmt 4701 Sfmt 4702 82627 coordination and potentially better health outcomes. Therefore, we seek comment on how best to operationalize this across impacted payers. We also see comment on whether the timeframes for the new payer requesting these data— within one week of this enrollment or other defined period ending—and the old payer sending these data—within one business day of receiving the request—are the optimal timeframes and what other timeframes payers may want us to consider. Would payers be able to accommodate a shorter request timeframe—such as one to three business days after the end of the defined enrollment period? Or, do payers need more than one business day to respond to a request? If so, would payers want to have a one week turnaround for data requests? We do think it is important for patient data to move to the new payer as soon as possible to facilitate care coordination, and to ensure the patient’s data is available to their providers and to them, hence our current proposal. We also seek comment on whether we should consider any other factors regarding the process and timeline for this Payer-toPayer API data sharing at enrollment. Efficient data sharing between payers would ensure that information that could support payer operations and benefit patient care is available to a new payer at the very start of the patient’s care covered by a new payer. This could facilitate care coordination and continuity of care. This proposal would require the new payer to adopt a process to obtain the name of an enrollee’s previous payer, or concurrent payer if the enrollee has coverage through more than one payer, as part of the enrollment process. Subsequently, the new payer would be required to receive the enrollee’s clinical data as defined in the USCDI version 1 and adjudicated claims and encounter data, as well as pending and active prior authorization decisions, from the previous or concurrent payer, if that payer maintains such data for the relevant enrollee. Under this proposal, impacted payers would be required to maintain a process for capturing data about each patient’s previous payer and concurrent payer (if there is one) at enrollment to facilitate this payer-to-payer data sharing. While we wish to leave it to each impacted payer how they choose to implement capturing this information, we seek comment on potential solutions to support payers in obtaining this previous and concurrent payer information in an effort to provide all impacted payers with options to consider. As to concurrent payers, we anticipate that many payers already E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82628 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules have a process in place to request and update information of this sort for coordination of benefits or to implement Medicare Secondary Payer requirements (if applicable), and we wish to allow payers to maintain their current processes if that is beneficial and feasible when incorporating the use of the Payer-to-Payer API into this process. We are proposing at 42 CFR 431.61(c)(5) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c)(5) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b)(5) for QHP issuers on the FFEs, that payers put a process in place to allow enrollees to opt-in to this payer-to-payer data sharing at enrollment, similar to the opt-in proposal under the Provider Access APIs detailed in section II.B. of this proposed rule. If enrollees do not actively opt-in, impacted payers would not be required to share their data through the Payer-to-Payer API as described under this proposal. This means that only at the defined enrollment period, or at the end of the first calendar quarter for payers that do not have a defined enrollment period, are impacted payers required under this proposal to have a process in place to capture a patient’s preference to opt-in to this data sharing under this proposal. If a patient would like their data shared with another payer at another time throughout a given year, the patient could request that data exchange under the enhanced payer-to-payer data exchange proposal discussed in section II.D.4. of this proposed rule. We seek comment on these proposals. Some individuals may have concurrent coverage with two or more of the payers impacted by this proposal. We also propose at 42 CFR 431.61(c)(4) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c)(4) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b)(4) for QHP issuers on the FFEs that when an enrollee has concurrent coverage with two or more impacted payers, the impacted payers must make the patient’s data available to the concurrent payer quarterly, in addition to when the enrollee obtains new coverage from a payer subject to these proposed requirements. We propose to require payers to provide enrollees the opportunity to opt-in to initiate this quarterly data sharing. This data exchange among concurrent payers is expected to support better care coordination and more efficient operations. We also considered whether to propose more frequent exchange VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 (weekly or monthly), and less frequent exchange (semi-annually or annually); however, we believe a quarterly data exchange would strike the right balance in providing accurate, timely data with minimal payer burden. We request comment on this proposal, including the appropriate frequency for this payer-to-payer exchange for enrollees with concurrent coverage. We also seek comment on whether payers prefer the flexibility to define their own process for facilitating how patients optin to this quarterly data sharing and if there are additional considerations that we should take into account to facilitate data sharing using the Payer-to-Payer API between concurrent payers. We appreciate that a patient may be moving to or from a payer, or have concurrent coverage with a payer not subject to the requirements in this proposed rule, such as when a patient moves from a QHP on the FFE to an employer-based plan, as an employerbased plan is not impacted by this rulemaking. We encourage all payers to consider the value of implementing a Payer-to-Payer API so that all patients, providers, and payers in the U.S. health care system may ultimately experience the benefits of such data sharing. For instance, we are exploring best next steps for the Medicare FFS program to participate in a Payer-to-Payer API data exchange with all interested payers. That said, if an impacted payer learns that a previous or concurrent payer is not subject to this proposal, we encourage the new payer to evaluate if the other payer can accommodate an API data exchange and seek such exchange in accordance with applicable law. However, an impacted payer would not be required to try to send data to or receive data from a payer that is not required to exchange data through the Payer-to-Payer API under this proposal. As discussed in section II.B. of this proposed rule, and as further illustrated in the discussion in this section of this proposed rule, it may be valuable for a payer to share data with another payer for more than one patient at a time. It is likely that if payers are sharing data at enrollment, impacted payers would have many patients’ data to share at one time. In such a situation, it can be burdensome to make an API call for each patient. This could require significant technological resources and time. To introduce additional efficiencies, we are proposing that this required Payer-to-Payer API must be able to share the specified data conformant with the HL7 FHIR Bulk Data Access (Flat FHIR) specification at 45 CFR 170.215(a)(4) to facilitate sharing information relevant to one or PO 00000 Frm 00044 Fmt 4701 Sfmt 4702 more patients at one time. We are proposing to codify this specific requirement at 42 CFR 431.61(c)(1) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c)(1) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b)(1) for QHP issuers on the FFEs. We request comment on this proposal. As with the proposal for the Provider Access API, discussed in section II.B. of this proposed rule, we invite comment on the tradeoffs and benefits of having the Payer-to-Payer API available with and without the use of the HL7 FHIR Bulk Data Access (Flat FHIR) specification. We believe both approaches would offer benefits to payers depending on the specifics of the situation in which they would need to share patient data. As we look to balance providing this flexibility with the burden of implementing and maintaining APIs, we invite public comment on the benefits of having the Payer-to-Payer API available with and without the use of the HL7 FHIR Bulk Data Access (Flat FHIR) specification, which can be leveraged to request the data for a single patient or multiple patients. 6. Extensions and Exemptions for Medicaid and CHIP If our proposals regarding the Payerto-Payer API are finalized, we would encourage state Medicaid and CHIP FFS programs to implement the Payer-toPayer API as soon as possible understanding the many benefits of the API as discussed previously in this section. However, we also recognize that state Medicaid or CHIP FFS agencies could face certain unique circumstances that would not apply to other impacted payers, as discussed in more detail later in this section. As a result, a few states might need to seek an extension of the compliance deadline or an exemption from these requirements. To address this concern, we are proposing a process through which states may seek an extension of and, in specific circumstances, an exemption from, the Payer-to-Payer API requirements if they are unable to implement these API requirements, consistent with the extension and exemption proposals for the Provider Access API in section II.B., and the DRLS and PAS APIs in section II.C. of this proposed rule. Providing these flexibilities might allow these states to continue building technical capacity in support of overall interoperability goals consistent with their needs. Therefore, we propose the following. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules Extension. At 42 CFR 431.61(e)(1) and 42 CFR 457.731(e)(1), respectively, we propose to provide states—for Medicaid FFS and CHIP FFS—the opportunity to request a one-time extension of up to one (1) year for the implementation of the Payer-to-Payer API specified at 42 CFR 431.61(b) and (c) and 42 CFR 457.731(b) and (c). Unique circumstances that might present a challenge to specific states to meet the proposed compliance date could include resource challenges, such as funding. Depending on when the final rule is published in relation to a state’s budget process and timeline, some states may not be able to secure the needed funds in time to both develop and execute implementation of the API requirements by the proposed compliance date. A one-year extension could help mitigate this issue. And, some states may need to initiate a public procurement process to secure contractors with the necessary skills to support a state’s implementation of these proposed API policies. The timeline for an open, competed procurement process, together with the time needed to onboard the contractor and develop the API, could require additional time as well. Finally, a state might need to hire new staff with the necessary skillset to implement this policy. Again, the time needed to initiate the public employee hiring process, vet, hire, and onboard the new staff may make meeting the proposed compliance timeline difficult, because, generally speaking, public employee hiring processes include stricter guidelines and longer time-to-hire periods than other sectors.58 In all such situations, a state might need more time than other impacted payers to implement the requirements. If a state believes it can demonstrate the need for an extension, its request must be submitted and approved as a part of its annual Advance Planning Document (APD) for MMIS operations costs and must include the following: (1) A narrative justification describing the specific reasons why the state cannot reasonably satisfy the requirement(s) by the compliance date, and why those reasons result from circumstances that are unique to states operating Medicaid or CHIP FFS programs, (2) a report on completed and ongoing implementation activities to evidence a good faith effort toward 58 State hiring processes are comparable with federal hiring processes. According to OMB, the average time-to-hire for federal employees was 98.3 days in 2018, significantly higher than the private sector average of 23.8 days. See: https:// www.opm.gov/news/releases/2020/02/opm-issuesupdated-time-to-hire-guidance/. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 compliance, and (3) a comprehensive plan to meet implementation requirements no later than one year after the initial compliance date. An extension would be granted if CMS determines based on the information provided in the APD that the request adequately establishes a need to delay implementation, a good faith effort to implement the proposed requirements as soon as possible, and a clear plan to implement no later than one year after the proposed compliance date. We would expect states to explain why the request for an extension results from circumstances that are unique to states operating Medicaid or CHIP FFS programs. We also solicit comment on whether our proposal would adequately address the unique circumstances that affect states, and that might make timely compliance with the proposed API requirement sufficiently difficult for states and thus justify an extension. In particular, we seek comment on whether we should require or use additional information on which to base the determination or whether we should establish different standards in the regulation text for evaluating and granting the request. Exemption. At 42 CFR 431.61(e)(2) and 42 CFR 457. 731(e)(2), respectively, we propose two circumstances that would permit state requests for exemption; namely, (1) when at least 90 percent of all covered items and services are provided to Medicaid or CHIP beneficiaries through Medicaid or CHIP managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or (2) when at least 90 percent of the state’s Medicaid or CHIP beneficiaries are enrolled in Medicaid or CHIP managed care organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10 for CHIP. In both circumstances, the time and resources that the state would need to expend to implement the API requirements may outweigh the benefits of implementing and maintaining the API. As discussed in section II.B. of this proposed rule, unlike other impacted payers, state Medicaid and CHIP FFS programs do not have a diversity of plans to balance implementation costs for those plans with low enrollment. If there is low enrollment in a state Medicaid or CHIP FFS program, there is no potential for the technology to be leveraged for additional beneficiaries as states, unlike other payers, do not maintain additional lines of business. We acknowledge that the proposed exemption could mean that a few Medicaid or CHIP FFS systems would not receive the benefits of having this API available to facilitate health PO 00000 Frm 00045 Fmt 4701 Sfmt 4702 82629 information exchange. To address this, we propose that states meeting the above thresholds would be expected to employ an alternative plan to enable the electronic exchange and accessibility of health information for those beneficiaries who are served under the FFS program. A state meeting the above criteria would be permitted to submit a request for an exemption to the requirements for the Payer-to-Payer API once per calendar year for a one-year exemption. The state would be required to submit this annual request as part of a state’s annual APD for MMIS operations costs. The state would be required to include in its request documentation that it meets the criteria for the exemption using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. We note we propose that this request be made annually as from year-to-year the nature of the FFS population could change and so it is important that the state provide the most current information for CMS’s consideration. Exemptions would be granted for a one-year period if a state establishes to CMS’s satisfaction that it meets the criteria for the exemption and has established a plan to ensure that all impacted payers would have efficient electronic access to the same information through alternative means. We request comment on the proposed extension and exemption. For Medicaid and CHIP managed care, we are not proposing an extension process at this time because we believe that managed care plans are actively working to develop the necessary IT infrastructure to be able to comply with the existing requirements in 42 CFR part 438 and part 457 and also benefit from efficiencies resulting from their multiple lines of business impacted by these interoperability policies. Many managed care plans are part of parent organizations that maintain multiple lines of business, including Medicaid managed care plans and plans sold on the Exchanges. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25607, 25612, 25620), work done by these organizations can benefit all lines of business and, as such, we do not believe that the proposals in this rule impose undue burden or are unachievable by the compliance date. We are soliciting comment on whether our belief concerning the scope of resources and ability of managed care parent organizations to achieve economies of scale is well-founded. Further, we seek comment on whether an extension process is warranted for E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82630 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules certain managed care plans to provide additional time for the plan to comply with the requirement at proposed 42 CFR 438.242(b)(7) (which cross references 42 CFR 438.61(b) and (c)) for Medicaid managed care plans and at proposed 42 CFR 457.1233(d)(4) (which cross references 42 CFR 457.731(b) and (c)) for CHIP managed care entities. While we are not proposing such a process for managed care plans and entities and do not believe one is necessary for the reasons outlined here, we are open to considering one if necessary. If we adopt an extension process for these managed care plans and entities, what criteria would a managed care plan or entity have to meet to qualify for an extension? Should the process consider, for example, enrollment size, plan type, or some unique characteristic of certain plans that could hinder their achievement of the proposed requirements by the proposed compliance date? Also, we seek comment on whether, if we finalize such a process for Medicaid managed care plans or CHIP managed care entities, the state or CMS should manage the process and whether states could successfully adopt and implement the process on the timeline necessary to fulfill the goals and purposes of the process. Consistent with the exception process proposed for QHP issuers on the FFEs at 45 CFR 156.222(d), we would expect any extension request to include, at a minimum, a narrative justification describing the reasons why a plan or entity cannot reasonably satisfy the requirements by the proposed compliance date, the impact of noncompliance upon enrollees, the current or proposed means of providing electronic health information to providers, and a corrective action plan with a timeline to achieve compliance. We do propose, however, to exclude non-emergency transportation (NEMT) PAHPs from the Payer-to-Payer API proposals. In this rule, we propose to require MCOs, PIHPs, and PAHPs other than NEMT PAHPs (as defined at 42 CFR 438.9(a)) to implement and maintain the Payer-to-Payer API. We believe that the unique nature and limited scope of the services provided by NEMT PAHPs is not consistent with the proposed purposes of the Payer-toPayer API proposed at 42 CFR 431.61(b) and (c). Specifically, we do not believe that having all other Medicaid managed care plans, such as acute care or dental managed care plans, be required to request, receive, and incorporate into the plan’s records NEMT data from an enrollee’s prior or concurrent payer would help achieve the goals of the VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 Payer-to-Payer API, namely to help avoid unnecessary care, ensure that providers are able to spend time with patients focusing on care versus collecting redundant information, or improve patient care through enhanced care coordination. Conversely, we do not believe having NEMT PAHPs be required to request, receive, and incorporate into its records enrollee data from other managed care plans contributes to achieving the goals of the Payer-to-Payer API given the unique nature and limited scope of the services they provide. We note that the HIPAA Privacy Rule, at 45 CFR 164.502, permits a covered entity to use or disclose PHI for certain treatment, payment, or health care operations without individual authorization. As such, we believe a health plan that needs NEMT PAHP utilization for treatment, payment, or the applicable health care operations for a current enrollee, would generally be permitted to under the applicable HIPAA provisions. As mentioned previously in this proposed rule, although Medicare FFS is not directly impacted by this rule, we do note that we are targeting to implement a Payer-to-Payer API for the Medicare FFS program, if finalized. In this way, the Medicare FFS Payer-toPayer API would conform to the same requirements that apply to the impacted payers under this rulemaking, as applicable, so that Medicare FFS beneficiaries would also benefit from this data sharing. 7. Exception for QHP Issuers With regard to QHP issuers on the FFEs, similar to our exceptions process noted in the CMS Interoperability and Patient Access final rule for the Patient Access API (85 FR 25552 through 25553) and in section II.B.6.e. of this proposed rule for the Provider Access API, we are also proposing an exception for the Payer-to-Payer API at 45 CFR part 156.222(d). As such, if a plan applying for QHP certification to be offered through a FFE believes it cannot satisfy the Payer-to-Payer API requirements, the issuer must include as part of its QHP application a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon enrollees, the current or proposed means of providing health information to payers, and solutions and a timeline to achieve compliance with the requirements of this section. Further, we propose that the FFE may grant an exception to these requirements if the Exchange determines that making such PO 00000 Frm 00046 Fmt 4701 Sfmt 4702 health plan available through such Exchange is in the interests of qualified individuals and qualified employers in the state or states in which such Exchange operates. We request comment on this proposal. 8. Statutory Authorities for Payer Exchange Proposals a. Medicaid and CHIP For Medicaid managed care plans and Medicaid state agencies, we are proposing to require the implementation of a Payer-to-Payer API to exchange claims, encounter, clinical, and pending and active prior authorizations data between payers at a patient’s request or any time a patient changes payers using a FHIR-based API. Our proposals in this section fall generally under our authority in the following provisions of the statute: • Section 1902(a)(4) of the Act, which requires that a state Medicaid plan provide such methods of administration as are found by the Secretary to be necessary for the proper and efficient operation of the state Medicaid plan. • Section 1902(a)(8) of the Act, which requires states to ensure that Medicaid services are furnished with reasonable promptness to all eligible individuals. • Section 1902(a)(19) of the Act, which requires states to ensure that care and services are provided in a manner consistent with simplicity of administration and the best interests of the recipients. We note statutory authority for proposals to require specific IGs for this and all APIs proposed in this rule is discussed in section II.A.3. of this proposed rule. We believe these proposals related to the Payer-to-Payer API are authorized by these provisions of the Act for the following reasons. First, because the Payer-to-Payer API is designed to enable efficient exchange of data between payers, it is anticipated to help state Medicaid programs improve the efficiencies and simplicity of their own operations, consistent with sections 1902(a)(4) and (a)(19) of the Act. Use of the Payer-to-Payer API could introduce efficiencies in providing Medicaid services, by reducing duplicate prior authorization requests, referrals, or tests. In addition, as is discussed in section II.B. of this proposed rule, with respect to the Provider Access API and the Bulk specification, this Payer-to-Payer API, by allowing payers to share health information for one or more patients at once, could increase efficiency and simplicity of administration. It could give payers access to all of their enrollees’ information with limited E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules effort and enable the state to then make that information available to providers and to patients through the Provider Access and Patient Access APIs. And, it could reduce the amount of time needed to evaluate a patient’s current care plan and possible implications for care continuity, which could introduce efficiencies and improve care. Use of the proposed Bulk specification allows state Medicaid programs to receive information on a full panel of patients at once, thus expediting the data collection process. Sharing patient information for a full panel of patients at a specified time annually, such as at the end of the first calendar quarter, would help to ensure payers receive patient information in a timely manner when a beneficiary moves to a new payer, and therefore, could lead to more appropriate service utilization and higher beneficiary satisfaction by supporting efficient care coordination and continuity of care as beneficiaries move from payer to payer, which could lead to better health outcomes. Second, the proposals are expected to help states and managed care plans furnish Medicaid services with reasonable promptness and in a manner consistent with beneficiaries’ best interests, consistent with section 1902(a)(8) and (a)(19) of the Act, for the following reasons. If states were to share information about Medicaid beneficiaries or former beneficiaries with other payers with whom these beneficiaries are enrolled, they could support opportunities for improved care coordination for Medicaid beneficiaries and former beneficiaries. Exchanging information about Medicaid beneficiaries and former beneficiaries between payers might also reduce the amount of time needed to evaluate a Medicaid beneficiary’s current care plan, their health risks, and their health conditions at the time that beneficiary enrolls with the Medicaid program. Exchanging this information between payers could also better support care continuity for Medicaid beneficiaries. As discussed in section II.D.4. of this proposed rule, if a state Medicaid program has access to a previous payer’s pending and active prior authorization decisions, the Medicaid program could choose to accept the existing decision and support continued patient care without requiring a new prior authorization or duplicate tests. This information exchange might be of particular value in improving care continuity for beneficiaries who might churn into and out of Medicaid coverage, or have concurrent coverage in addition to Medicaid. The proposal VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 could also improve the provision of Medicaid services, by potentially helping to ensure that Medicaid beneficiaries who may require coordinated services with concurrent payers could be identified and provided case management services, as appropriate. For Medicaid managed care plans, the proposed exchange of claims, encounter, USCDI, and some prior authorization data would greatly enhance an MCO’s, PIHP’s, or PAHP’s ability to fulfill its obligations under 42 CFR 438.208(b) which require them to: Implement procedures to deliver care to and coordinate services including ensuring that each enrollee has an ongoing source of appropriate care; coordinate services between settings of care, among Medicaid programs, and with community and social support providers; make a best effort to conduct an initial screening of each enrollee’s needs; and share with the state or other MCOs, PIHPs, and PAHPs serving the enrollee the results of any identification and assessment of that enrollee’s needs to prevent duplication of those activities. The data provided via the Payer-to-Payer API proposed in this rule would give managed care plans the information needed to much more easily perform these required functions, thus enhancing the effectiveness of the care coordination and helping enrollees receive the most appropriate care in an effective and timely manner. For CHIP, we are proposing these requirements under our authority in section 2101(a) of the Act, which states that the purpose of title XXI is to provide funds to states to provide child health assistance to uninsured, lowincome children in an effective and efficient manner that is coordinated with other sources of health benefits coverage. We believe the provisions in this proposed rule could strengthen our ability to fulfill these statutory obligations in a way that recognizes and accommodates the use of electronic information exchange in the health care industry today and would facilitate a significant improvement in the delivery of quality health care to our beneficiaries. As with the Medicaid FFS and Medicaid managed care programs, the proposals in this section of the proposed rule for CHIP FFS and CHIP managed care require the use of a Payer-to-Payer API to exchange claims, encounter, clinical and pending and active prior authorization data at a beneficiary’s request, or any time a beneficiary changes payers, using a FHIR-based API. The current payer could use data from the prior payer to more effectively or PO 00000 Frm 00047 Fmt 4701 Sfmt 4702 82631 accurately respond to a request for a prior authorization, because under this proposal, a new payer would have historical claims or clinical data upon which they may review a request with more background data. Access to information about new patients could enable appropriate staff within the CHIP program to more effectively coordinate care and conduct the care management because they would have better data available to make decisions for planning. In many cases, patients do not remember what services they have had, what vaccines they have had, or other possibly relevant encounters that could help payers manage their care. This proposal is consistent with the goal of providing more informed and effective care coordination, which could help to ensure that CHIP services are provided in a way that supports quality care, which aligns with section 2101(a). b. QHP Issuers on the FFEs For QHP issuers on the FFEs, we are proposing these new requirements under our authority in section 1311(e)(1)(B) of the Affordable Care Act, which affords the Exchanges the discretion to certify QHPs if the Exchange determines that making available such health plans through the Exchange is in the interests of qualified individuals in the state in which the Exchange operates. Existing and emerging technologies provide a path to make information and resources for health and health care management universal, integrated, equitable, accessible to all, and personally relevant. Requiring QHP issuers on the FFEs to build and maintain a Payer-to-Payer API would allow the seamless flow of claims and encounter data, the clinical data the payer maintains for a patient as defined in the USCDI version 1, as well as their pending and active prior authorization decisions, from payer to payer. We believe that ensuring a means for an enrollee’s new issuer to electronically obtain the enrollee’s claims, encounter, and clinical data, as well as prior authorization information with corresponding medical records, from the previous issuer will reduce administrative burden and result in more timely and efficient care coordination and responses to prior authorization requests. We believe it is necessary that QHP issuers on FFEs have systems in place to send information important to care coordination with departing enrollees, and that QHP issuers also have systems in place to receive such information from payer to payer on behalf of new and concurrent enrollees, as appropriate E:\FR\FM\18DEP2.SGM 18DEP2 82632 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 and consistent with the proposals in this section. Therefore, we believe certifying only health plans that make enrollees’ health information available to them and their providers, and as discussed in this section, other payers, in a convenient, timely, and portable way is in the interests of qualified individuals and qualified employers in the state in which an FFE operates. We encourage SBEs to consider whether a similar requirement should be applicable to QHP issuers participating in their Exchange. We previously finalized the Payer-toPayer Data Exchange in the CMS Interoperability and Patient Access final rule, where, with the approval and at the direction of an enrollee, one payer would have to send clinical data as defined in the USCDI version 1 to another payer named by the enrollee. We are now requiring this to be done via an API and adding claims and encounter data, as well as pending and active prior authorization decisions. We also believe that requiring QHP issuers on the FFEs to use the Bulk Specification for the Payer-to-Payer API would improve the efficiency and simplicity of data transfers between issuers, by enabling the exchange of all data for all patients at once. We believe the opportunity to support an exchange of large volumes of patient data, rather than data for one patient at a time, may be cost effective for the issuers, and having patient care at the beginning of a new plan, could assist the new payer in identifying patients who need care management services, which could reduce the cost of care. Taking in volumes of data would also enable the QHPs to perform analysis on the types of new patients in their plan, if they choose to analyze data for existing patients as well. E. Adoption of Health IT Standards and Implementation Specifications As first mentioned in section II.A. of this proposed rule, at 45 CFR 170.215, ONC is proposing the specific IGs discussed in sections II.A., II.B., II.C., and II.D. of this proposed rule for HHS adoption in support of the API provisions included in this proposed rule. This section outlines ONC’s authority to do so, and how this will support HHS generally, and CMS specifically, in continuing to advance standards and the use of FHIR to reduce burden, improve the prior authorization process, and support patient electronic access to health information. 1. Statutory Authority The Health Information Technology for Economic and Clinical Health VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 (HITECH) Act, Title XIII of Division A and Title IV of Division B of the American Recovery and Reinvestment Act of 2009 (the Recovery Act) (Pub. L. 111–5), was enacted on February 17, 2009. The HITECH Act amended the Public Health Service Act (PHSA) and created ‘‘Title XXX—Health Information Technology and Quality’’ (Title XXX) to improve health care quality, safety, and efficiency through the promotion of health IT and exchange of electronic health information (EHI). Subsequently, Title IV of the 21st Century Cures Act (Pub. L. 114–255) (‘‘Cures Act’’) amended portions of the HITECH Act by modifying or adding certain provisions to the PHSA relating to health IT. a. Adoption of Standards and Implementation Specifications Section 3001 of the PHSA directs the National Coordinator for Health Information Technology (National Coordinator) to perform duties in a manner consistent with the development of a nationwide health information technology infrastructure that allows for the electronic use and exchange of information. Section 3001(b) of the PHSA establishes a series of core goals for development of a nationwide health information technology infrastructure that: • Ensures that each patient’s health information is secure and protected, in accordance with applicable law; • Improves health care quality, reduces medical errors, reduces health disparities, and advances the delivery of patient-centered medical care; • Reduces health care costs resulting from inefficiency, medical errors, inappropriate care, duplicative care, and incomplete information; • Provides appropriate information to help guide medical decisions at the time and place of care; • Ensures the inclusion of meaningful public input in such development of such infrastructure; • Improves the coordination of care and information among hospitals, laboratories, physician offices, and other entities through an effective infrastructure for the secure and authorized exchange of health care information; • Improves public health activities and facilitates the early identification and rapid response to public health threats and emergencies, including bioterror events and infectious disease outbreaks; • Facilitates health and clinical research and health care quality; • Promotes early detection, prevention, and management of chronic diseases; PO 00000 Frm 00048 Fmt 4701 Sfmt 4702 • Promotes a more effective marketplace, greater competition, greater systems analysis, increased consumer choice, and improved outcomes in health care services; and • Improves efforts to reduce health disparities. Section 3004 of the PHSA identifies a process for the adoption of health IT standards, implementation specifications, and certification criteria, and authorizes the Secretary to adopt such standards, implementation specifications, and certification criteria. As specified in section 3004(a)(1) of the PHSA, the Secretary is required, in consultation with representatives of other relevant federal agencies, to jointly review standards, implementation specifications, and certification criteria endorsed by the National Coordinator under section 3001(c) of the PHSA and subsequently determine whether to propose the adoption of any grouping of such standards, implementation specifications, or certification criteria. The Secretary is required to publish all determinations in the Federal Register. Section 3004(b)(3) of the PHSA, which is titled ‘‘Subsequent Standards Activity,’’ provides that the Secretary shall adopt additional standards, implementation specifications, and certification criteria as necessary and consistent with the schedule published by the Health IT Advisory Committee (HITAC). As noted in the final rule, ‘‘2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications’’ (‘‘ONC 2015 Edition Final Rule’’), published on October 16, 2015, we consider this provision in the broader context of the HITECH Act and the Cures Act to continue to grant the Secretary the authority and discretion to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria (80 FR 62606). Under the authority outlined in section 3004(b)(3) of the PHSA, the Secretary may adopt standards, implementation specifications, and certification criteria as necessary even if those standards have not been recommended and endorsed through the process established for the HITAC under section 3002(b)(2) and (3) of the PHSA. Moreover, while HHS has traditionally adopted standards and implementation E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules specifications at the same time as adopting certification criteria that reference those standards, the Secretary also has the authority to adopt standards or implementation specifications apart from the certification criteria adopted specifically for the voluntary certification of health IT under the ONC Health IT Certification Program. Finally, the Cures Act amended the PHSA to add section 3004(c) of the PHSA to specify that in adopting and implementing standards under this section, the Secretary shall give deference to standards published by standards development organizations and voluntary consensus-based standards bodies. khammond on DSKJM1Z7X2PROD with PROPOSALS2 b. Coordination of Federal Activities With Adopted Standards and Implementation Specifications, and Application to Private Entities Section 13111 of the HITECH Act requires that when a federal agency implements, acquires, or upgrades health information technology systems used for the direct exchange of individually identifiable health information between agencies and with non-federal entities, it shall utilize, where available, health information technology systems and products that meet standards and implementation specifications adopted under section 3004 of the PHSA, as added by section 13101 of the HITECH Act. Similarly, section 13112 of the HITECH Act states that federal agencies shall require in its contracts and agreements with providers, plans, or issuers that as each provider, plan, or issuer implements, acquires, or upgrades health information technology systems, it shall utilize, where available, health information technology systems and products that meet standards and implementation specifications adopted under section 3004 of the PHSA. 2. Background Consistent with section 3004(b)(3) of the PHSA, we believe the standards and implementation specifications proposed at 45 CFR 170.215 by ONC for HHS adoption are appropriate and necessary and would, if adopted, contribute to key health care priorities of a nationwide health IT infrastructure as described in section 3001(b) of the PHSA. The use of the identified implementation specifications across health IT systems would support more effective prior authorization transactions between providers and payers, and would help to reduce administrative burden and support medical decision-making. Use of the proposed payer data implementation specifications would VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 help to bring together administrative and clinical data, and make such data accessible, which is an essential step to connecting cost and quality data to promote a more effective marketplace, greater competition, greater systems analysis, increased consumer choice, and improved outcomes in health care services. Finally, use of the additional implementation specifications for a Provider Directory API would support more robust care coordination and increased patient choice through improved availability of health care provider contact and exchange information. In support of these likely outcomes, we note that the CMS proposals in sections II.A., II.B., II.C., and II.D. of this rule detail further benefits that would result from the use of these implementation specifications for each of the relevant CMS payer API requirement proposals. In the following section, consistent with section 3004(b)(3) of the PHSA and on behalf of the Secretary, ONC proposes to adopt at 45 CFR 170.215(c) implementation specifications for APIs based upon the HL7® FHIR® Release 4 base standard adopted by ONC on behalf of HHS at 45 CFR 170.215(a). The proposed implementation specifications were developed through a voluntary consensus-based standard organization, HL7®, a non-profit standard development organization. In concert with CMS, ONC has led or participated in a variety of activities related to monitoring and evaluating the standards and implementation specifications identified in this proposed rule, utilizing available mechanisms for gathering input on these standards from stakeholders and experts. Based on these activities and input, it is appropriate to propose these specifications for adoption. a. Standards Development Organization Activities Consistent with section 3004(c) of the PHSA, the implementation specifications proposed for adoption have been developed through an industry-led, consensus-based public process by a nationwide voluntary consensus-based standards body. HL7® is an American National Standards Institute (ANSI) accredited standards development organization. HL7® FHIR® standards are unique in their ability to allow disparate systems that otherwise represent data differently to exchange such data in a standardized way that all systems can share and consume via standards-based APIs. HL7® FHIR® IGs are also openly accessible, so any interested party can go to the HL7® website and access the IG. Once PO 00000 Frm 00049 Fmt 4701 Sfmt 4702 82633 accessed, all public comments made during the balloting process as well as the IG version history are available for review. A number of the FHIR® IGs proposed for adoption have been developed by the Da Vinci project, an initiative established in 2018 to help payers and providers positively impact clinical, quality, cost, and care management outcomes.59 The Da Vinci project is part of the HL7® FHIR® Accelerator Program.60 Under the Da Vinci project, industry stakeholders have facilitated the definition, design, and creation of use-case-specific reference implementations of solutions based upon the HL7® FHIR® platform to address value-based care initiatives. Because the Da Vinci project is aligned with HL7®, new and revised requirements can become open industry standards. b. Interoperability Standards Advisory ONC’s Interoperability Standards Advisory (ISA) supports the identification, assessment, and public awareness of interoperability standards and implementation specifications that can be used by the United States health care industry to address specific interoperability needs (see https:// www.healthit.gov/isa). The ISA is updated on an annual basis based on recommendations received from public comments and subject matter expert feedback. This public comment process reflects ongoing dialogue, debate, and consensus among industry stakeholders when more than one standard or implementation specification could be used to address a specific interoperability need. ONC currently identifies the IGs referenced throughout this proposed rule within the ISA as available standards for a variety of potential use cases. For instance, the HL7® FHIR® Da Vinci PDex IG proposed for adoption at 45 CFR 170.215(c)(6) is currently identified under the ‘‘Query for Documents Outside a Specific Health Information Exchange Domain’’ within the ISA.61 We encourage stakeholders to review the ISA to better understand key applications for the IGs proposed for adoption in this proposed rule. c. Alignment With Federal Advisory Committee Activities The HITECH Act established two federal advisory committees, the HIT 59 See https://www.hl7.org/about/davinci/. https://www.hl7.org/documentcenter/ public/pressreleases/HL7_PRESS_20190211.pdf. 61 See https://www.healthit.gov/isa/querydocuments-outside-a-specific-health-informationexchange-domain. 60 See E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82634 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules Policy Committee (HITPC) and the HIT Standards Committee (HITSC). Each was responsible for advising the National Coordinator on different aspects of health IT policy, standards, implementation specifications, and certification criteria. Section 3002 of the PHSA, as amended by section 4003(e) of the Cures Act, replaced the HITPC and HITSC with one committee, the Health Information Technology Advisory Committee (HIT Advisory Committee or HITAC). After that change, section 3002(a) of the PHSA established that the HITAC would advise and recommend to the National Coordinator on different aspects of standards, implementation specifications, and certification criteria, relating to the implementation of a health IT infrastructure, nationally and locally, that advances the electronic access, exchange, and use of health information. The Cures Act specifically directed the HITAC to advise on two areas: (1) A policy framework to advance an interoperable health information technology infrastructure (section 3002(b)(1) of the PHSA); and (2) priority target areas for standards, implementation specifications, and certification criteria (section 3002(b)(2) and (3) of the PHSA). For the policy framework, as described in section 3002(b)(1)(A) of the PHSA, the Cures Act tasks the HITAC with providing recommendations to the National Coordinator on a policy framework for adoption by the Secretary consistent with the Federal Health IT Strategic Plan under section 3001(c)(3) of the PHSA. In February of 2018, the HITAC made recommendations to the National Coordinator for the initial policy framework 62 and has subsequently published a schedule in the Federal Register, and an annual report on the work of the HITAC and ONC to implement and evolve that framework.63 For the priority target areas for standards, implementation specifications, and certification criteria, section 3002(b)(2)(A) of the PHSA identified that in general, the HITAC would recommend to the National Coordinator, for purposes of adoption under section 3004 of the PHSA, standards, implementation specifications, and certification criteria and an order of priority for the 62 HITAC Policy Framework Recommendations, February 21, 2018: https://www.healthit.gov/sites/ default/files/page/2019-07/2018-02-21_HITAC_ Policy-Framework_FINAL_508-signed.pdf. 63 HITAC Annual Report CY 2019 published March 2, 2020: https://www.healthit.gov/sites/ default/files/page/2020-03/ HITAC%20Annual%20Report%20for%20FY19_ 508.pdf. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 development, harmonization, and recognition of such standards, specifications, and certification criteria. In October of 2019, the HITAC finalized recommendations on priority target areas for standards, implementation specifications, and certification criteria.64 As described above and in the ONC 2015 Edition final rule (80 FR 62606), section 3004(b)(3) of the PHSA provides broad authority for the Secretary to adopt standards, implementation specifications, and certification criteria that have been recommended by the HITAC and endorsed by the National Coordinator, as well as other appropriate and necessary health IT standards, implementation specifications, and certification criteria. Under this authority, the Secretary may adopt standards, implementation specifications, and certification criteria as necessary even if those standards have not been recommended and endorsed through the process established for the HITAC under section 3002(b)(2) and (3) of the PHSA. While the implementation specifications we are proposing to adopt have not been specifically recommended and endorsed through the HITAC process, the HITAC has recommended the adoption of interoperability standards for specific data flows addressed by the standards we propose to adopt in this proposed rule. In other instances, the HITAC has addressed issues related to interoperability standards for health care operations relevant to these proposed standards. In addition, our proposal to adopt the identified implementation specifications for health care operations under section 3004(b)(3) of the PHSA is consistent with the HITAC policy framework schedule as well as with the priority target areas for standards and implementation specifications. In the October 16, 2019 recommendations from the HITAC establishing the Interoperability Standards Priority Target Areas, the HITAC recommendations identified a ‘‘need for standards to support the integration of prior authorization (PA).’’ The 2019 HITAC annual report (published March 2020) describes a hearing held by the HITAC related to prior authorization and administrative simplification. The report identifies continuing work in this area including highlighting the HL7 standards development organization efforts to 64 HITAC recommendations on priority target areas, October 16, 2019: https://www.healthit.gov/ sites/default/files/page/2019-12/2019-10-16_ISP_ TF_Final_Report_signed_508.pdf. PO 00000 Frm 00050 Fmt 4701 Sfmt 4702 improve automation and interoperability of administrative and clinical data, and the Da Vinci Project use case supporting payers sending administrative data to providers using the HL7 FHIR standard.65 In CY 2020, ONC charged the HITAC to establish the Intersection of Clinical and Administrative Data (ICAD) Task Force to produce information and considerations related to the merging of clinical and administrative data. The ICAD Task Force explored a wide range of considerations including transport and exchange structures, areas for clinical and operations data alignment, and privacy and security rules and protections. The ICAD Task Force, which included members of the HITAC, NCVHS, industry, and the public, received input from a variety of experts and stakeholders in the field. In November 2020, the ICAD Task Force presented final recommendations 66 to the HITAC, which were then approved by the full Committee. These included a recommendation to ‘‘Establish Standards for Prior Authorization Workflows.’’ Specifically, the final report recommends that ONC work with CMS, other federal actors, and standards development organizations to ‘‘develop programmatic (API) specifications to create an authorization (digital prior authorization or related determinations such as Medical Necessity) such that the authorization and related documentation can be triggered in workflow in the relevant workflow system where the triggering event for the authorization is created.’’ In addition, the final report identifies for consideration the potential use of HL7® FHIR® standards as part of this recommendation including discussion of: The HL7® FHIR® Da Vinci CRD and DTR IGs, and the HL7® FHIR® Da Vinci PAS IG. These implementation specifications, which ONC proposes to adopt on behalf of HHS in this proposed rule, are discussed extensively as part of the final report as examples of FHIR® specifications that can support prior authorization. ONC has considered these recommendations and considerations in our decision to propose to adopt these prior authorization implementation specifications for health care operations at 45 CFR 170.215(c)(1) through (3) as 65 HITAC Annual Report CY 2019 published March 2, 2020: https://www.healthit.gov/sites/ default/files/page/2020-03/ HITAC%20Annual%20Report%20for%20FY19_ 508.pdf. 66 Final Recommendations of the ICAD Task Force, November 2020: https://www.healthit.gov/ sites/default/files/facas/ICAD_TF_FINAL_Report_ HITAC_2020-11-06_0.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 described below in section II.E.3. of this proposed rule. In addition to the recommendation regarding standards, the final report includes several additional recommendations to support the convergence of clinical and administrative data to improve data interoperability to support clinical care, reduce burden, and improve efficiency. We believe our proposal to adopt implementation specifications for health care operations relating to payer data exchange and provider directories at 45 CFR 170.215(c)(4) through (8) will help to advance these aims (see section II.E.3. of this proposed rule for further detail). These include recommendations relating to prioritizing administrative efficiency in relevant federal programs, focusing on convergence of health care standards, and developing patientcentered workflows and standards. We agree with the findings in the final report which state that these recommendations will help to form a solid basis on which to develop the future policies, standards, and enabling technologies that will truly put the patient at the center of an efficient health care information ecosystem. d. Coordination of Federal Activities With Adopted Standards and Implementation Specifications Consistent with sections 13111 and 13112 of the HITECH Act, ONC has worked with CMS, HHS agencies, and other federal partners to ensure that federal activities involving the implementation, acquisition, and upgrade of systems that collect and process health information are consistent with the standards and implementation specifications adopted under section 3004 of the PHSA. Aligning the use of such standards and implementation specifications would ensure that the same health IT standards are utilized by federal government programs and federal partners in the health care industry and reduce the risk of competing or inconsistent regulatory requirements increasing stakeholder burden. In addition, alignment of standards and implementation guidance would be expected to reduce fragmentation between and among systems supporting interoperability across the health care continuum for a wide range of use cases. This includes specific efforts to align federal activities with the standards for APIs adopted in the ONC 21st Century Cures Act final rule as proposed in 2019 and finalized in 2020 (85 FR 25642). The ONC 21st Century Cures Act final rule implements provisions of the Cures Act, which prioritize the adoption of VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 APIs across the health care industry. In the API requirements for payers finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510), which serve as the basis for several additional proposals in this proposed rule, CMS specified alignment of their final policies with technical standards for APIs adopted in the ONC 21st Century Cures Act final rule at 45 CFR 170.215, as well as the USCDI version 1 standard vocabulary standard adopted at 45 CFR 170.213. In addition to the efforts described in this proposed rule, HHS agencies are exploring areas for alignment to these adopted standards to improve health information exchange for a wide range of use cases. Some examples include: • In fall 2019, NIH published a request for information on the use of FHIR-based APIs to support research use cases (https://grants.nih.gov/grants/ guide/notice-files/NOT-OD-19150.html). • In partnership with the CDC, ONC has worked with HL7 and other standards development process participants to develop an IG to provide developers and IT staff details on how to access prescription drug monitoring program (PDMP) data from clinical systems. This ongoing work includes aligning the IG with updates to existing standards and specifically FHIR Release 4 (https://hl7.org/fhir/us/meds/2018May/ pdmp.html). • CMS is leading the PACIO Project for the development of post-acute care FHIR implementation specifications and reference implementations that will facilitate health data exchange through standards-based APIs (https:// confluence.hl7.org/display/PC/ PACIO+Project). As these efforts continue, ONC will continue to work with federal partners and monitor and analyze interoperability standards and implementation specifications for potential adoption on behalf of the Secretary and HHS. This ongoing process aims to support coordination and alignment of federal activities involving the broad collection and submission of health information, as well as the applicability to private entities engaged in health information exchange with federal partners. The overarching goal is to continue to support the advancement of a nationwide health information technology infrastructure that reduces burden and health care costs, and, most importantly, improves patient care. PO 00000 Frm 00051 Fmt 4701 Sfmt 4702 82635 3. Proposal To Adopt the Standards for Use by HHS Consistent with section 3004(b)(3) of the PHSA and the efforts described above to evaluate and identify standards for adoption, on behalf of the Secretary, we propose to adopt the implementation specifications for health care operations at 45 CFR 170.215 to support the continued development of a nationwide health information technology infrastructure as described under section 3001(b) of the PHSA and to support federal alignment of standards for interoperability and health information exchange. Specifically, we propose to adopt the latest versions of the following standards at 45 CFR 170.215 under a new paragraph (c), ‘‘Standards and Implementation Specifications for Health Care Operations.’’ We note that each IG is discussed in detail in relation to the specific API it will support in sections II.A., II.B., II.C., and II.D. of this proposed rule, as well as in section IV. of this proposed rule. The latest version of each standard may be accessed at the links provided: • HL7 FHIR Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/ davinci-crd/history.html. • HL7 FHIR Da Vinci— Documentation Templates and Rules (DTR) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/ davinci-dtr/history.html. • HL7 FHIR Da Vinci—Prior Authorization Support (PAS) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/ davinci-pas/history.html. • HL7 FHIR Da Vinci—Payer Coverage Decision Exchange (PCDE) Implementation Guide: Version STU 1.0.0. URL: https://www.hl7.org/fhir/us/ davinci-pcde/history.cfml. • HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/ fhir/us/carin-bb/history.html. • HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/ fhir/us/davinci-pdex/history.html. • HL7 FHIR Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide: Version STU 1.0.1. URL: https://hl7.org/fhir/us/ Davinci-drug-formulary/history.html. • HL7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide: Version STU 1.0.0. URL: https://www.hl7.org/fhir/us/ davinci-pdex-plan-net/history.cfml. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82636 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules The implementation specifications proposed for adoption in this rule would be important additions to the group of interoperability specifications adopted by HHS. We believe that by adopting these standards, as proposed at 45 CFR 170.215(c), we would support future alignment across health care system stakeholders and the development of a robust nationwide health IT infrastructure. Unlike other rulemakings in which ONC has engaged, we are not proposing new or revised certification criteria based on the proposed adoption of these standards, nor are we proposing to require testing and certification to these implementation specifications for any existing certification criteria in the ONC Health IT Certification Program. These proposals focus on the adoption of standards and implementation specifications for health information technology to support interoperability and health information exchange across a wide range of potential use cases. We expect that, as new models of care delivery continue to connect clinical and payment data in innovative ways to reduce burden and increase efficiency, the implementation specifications we are proposing to adopt at 45 CFR 170.215(c) will contribute to advancing the interoperability of data across clinical and administrative systems. We further believe this approach will support federal alignment and coordination of federal activities with adopted standards and implementation specifications for a wide range of systems, use cases, and data types within the broad scope of health information exchange. As noted above under section II.E.1.b. of this proposed rule, historically, state, federal, and local partners have leveraged the standards adopted by ONC on behalf of HHS (as well as those identified in the ISA) to inform program requirements, technical requirements for grants and funding opportunities, and systems implementation for health information exchange. We believe the adoption of these standards will support these HHS partners in setting technical requirements and exploring the use of innovative health IT solutions for health information exchange for health care operations. We additionally propose to make minor revisions to the regulation text at 45 CFR 170.215 to support clarity in the short descriptions of the standards and implementation specifications previously adopted at 45 CFR 170.215(a) and (b). However, we are not proposing any changes to the standards and implementation specifications, or versions thereof, previously adopted in VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 45 CFR 170.215(a) or (b). For the implementation specifications proposed for adoption at 45 CFR 170.215(c) Standards and Implementation Specifications for Health Care Operations, we propose to incorporate by reference the specified version of each implementation specification at 45 CFR 170.299. III. Requests for Information A. Methods for Enabling Patients and Providers To Control Sharing of Health Information The CMS Interoperability and Patient Access final rule (85 FR 25510) and this proposed rule are focused on unleashing data in order to empower patients to make informed decisions and empowering providers with the data they need at the moment they are caring for their patients. Stakeholders have shared that they believe part of empowering patients and providers is being sure both have a say in what specific data are shared, when, and with whom. We have started to address this issue within these two regulations. However, we received several comments on the CMS Interoperability and Patient Access proposed rule (84 FR 7610) indicating that patients and providers want more options for controlled sharing of health information beyond what is currently in place under current federal and state laws and regulations. Commenters indicated a preference for a framework that honors an individual’s privacy rights, without constricting permissible uses of health information to improve the health and wellness of individuals and populations. Commenters indicated that some patients want the right to choose which data elements from their health record are shared with specified providers, payers, and third parties. Other patients want the ability to opt out of information exchanges between payers and other stakeholders, such as health care providers and health information exchanges. Some patients indicated that they want their preferences considered in the determination of what data should be shared, and they desire the ability to deem certain aspects of their health information as sensitive and not to be shared under pre-defined circumstances. These patient preferences could provide the opportunity to continue support for patient autonomy and encourage greater patient participation, as patients should have an understanding of how their health information is being shared and used, given this could have an impact on their care. PO 00000 Frm 00052 Fmt 4701 Sfmt 4702 We received comments indicating that providers want the right to choose if all or some of a patient’s data should be shared with other providers and/or the patient themselves, especially if they believe sharing specific information could lead to negative outcomes. One example mentioned is where a provider may want to edit or remove a section of a patient’s clinical notes before sharing the record with the patient and/or another provider if the notes indicate a possible diagnosis that may be misunderstood by the patient or lead to stigmatization by another provider who does not possess sufficient context prior to reading the notes. In regards to providers having the ability to choose which data are shared, we noted that the HIPAA Privacy Rule allows for certain limited circumstances for which a provider may deny a patient access to all or a portion of a patient’s data under 45 CFR 164.524(a)(2) and 45 CFR 164.524(a)(3). While there may also be relevant state laws, those that applied additional restrictions on individual access would be preempted by HIPAA, and we note that providing patients with easy access to their health information empowers them to be more in control of decisions regarding their health and well-being. We also note that in ONC’s 21st Century Cures Act final rule (85 FR 25642), ONC finalized certain exceptions to the practice of information blocking, which would allow health care providers, health IT developers, exchanges, and networks to withhold data from other health care providers, health IT developers, exchanges, and networks under certain circumstances. This allows organizations to respect an individual’s request not to share information, where not required or prohibited by law. Additionally, we received comments about the maturity of existing processes that impact access controls of heath IT systems, such as data segmentation, or processes that enable more granular consent capabilities. Commenters indicated concerns that the current standards available are not well adopted or appropriately conformant with the FHIR version 4 (85 FR 25546). Taking into consideration applicable federal, state, local, and tribal law, we are interested in stakeholder feedback on different methods that enable patients and providers to have more granular control over the sharing of patient health information. Specifically, we are seeking stakeholder feedback on the following questions: • Patient Engagement and Provider Discretion. What role should patients and providers play in data segmentation E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules decisions? Should patients assume this responsibility and are there mechanisms currently in place or available that could support the documenting of these preferences? Would providing opportunities to express these preferences negatively impact patients who are unable or choose not to state their preferences? For instance, would a patient who did not fully understand how, or, or the pros and cons of, sharing some data but not other data be at a disadvantage in some way? How can patients be engaged in these decisions and acquire adequate understanding of how their data are being shared without burdening them? Are there specific situations, use cases, or considerations that should limit how the impacted entity responds to a data segmentation request to either restrict uses and disclosures of some of the data, or to obtain access to some of the data from a patient or provider? Are there unintended consequences of such data segmentation requests or options? If so, how can they be addressed? • Methods and Readiness. What are examples of effective tools and methods for patients and providers to control access to portions of patients’ health data? What is the readiness and feasibility of implementing successful access control methods? • Resource Burden. Commenters raised concerns about the potential cost and burden of data segmentation at the data element level. Specifically, would requiring the ability to segment the data by, for instance, conducting data tagging, place additional burden on clinical providers? Please describe the nature of any additional burden. What are possible solutions to consider to address these concerns? • Current Patient Consent Practices. How do current consent practices inform patients of opportunities for patient engagement and provider discretion in responding to patient requests? What technology and policy gaps exist for achieving widespread successful segmentation practices? • FHIR Utility. What recommendations do stakeholders have to improve the data segmentation capabilities of existing FHIR standards? How would you describe the state of development projects or standards efforts planned or ongoing to address data segmentation (or segmentation of sensitive information) on FHIR or other standards? What are the key gaps or constraints that exist within ongoing and emerging efforts? • Technical Considerations. What general data segmentation strategies can we leverage for the programs described in this proposed rule from standards VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 like the Substance Abuse and Mental Health Services Administration’s (SAMSHA) Consent2Share 67 and HL7 Data Segmentation for Privacy (DS4P)? 68 What lessons can we learn from use of these existing standards? • How can existing tools, resources, and approaches with data segmentation be used to help inform any approaches or strategies that CMS might consider proposing for impacted entities? 69 • Patient Options. Should preferences be something that data senders should try to honor but retain flexibility to deny in certain situations, when consistent with applicable regulations? For example, the HIPAA Privacy Rule requires a covered entity to permit an individual to request restrictions on the entity’s uses and disclosures of PHI, but only requires the entity to agree to the request in limited circumstances (see 45 CFR 164.522(a)(1)(vi)). • Current Segmentation Efforts. Varied segmentation practices exist, and we are seeking stakeholder input from those who have implemented or piloted patient-controlled segmentation models, individual provider-controlled models, or other related models or tools. What prevents patients and/or providers from recording, maintaining, or using a patient’s privacy preferences when exchanging health information? How can data segmentation decisions be automated? Are there particular processes or workflows related to patient privacy preferences, consent, or data segmentation that could be improved by automation and/or standardization? B. Electronic Exchange of Behavioral Health Information Several factors have led to an EHR adoption rate that is significantly lower among behavioral health providers compared to other types of health care providers. One possible contributing factor was that the Health Information Technology for Economic and Clinical Health Act (Pub. L. 111–5, enacted 67 HL7 International Community-Based Care and Privacy. (n.d.). Consent2Share Implementation Guide. Retrieved from https://gforge.hl7.org/gf/ project/cbcc/frs/?action=FrsReleaseBrowse&frs_ package_id=303. 68 Office of the National Coordinator for Health Information Technology. (2020). Data Segmentation of Sensitive Information. Retrieved from https:// www.healthit.gov/isa/data-segmentation-sensitiveinformation. 69 For selected resources on practices for privacy and data segmentation, see p. 61 of the Health IT Advisory Committee Notice of Proposed Rulemaking Task Force. (2019, June 3). Information Blocking Task Force Recommendations. Retrieved from https://www.healthit.gov/sites/default/files/ page/2019-07/2019-06-03_ All%20FINAL%20HITAC%20NPRM%20Recs_508signed.pdf. PO 00000 Frm 00053 Fmt 4701 Sfmt 4702 82637 February 17, 2009) (HITECH Act) made Medicare fee-for-service and Medicaid incentive payments for the adoption and meaningful use of certified EHR technology available only to eligible professionals, eligible hospitals, and critical access hospitals (CAH). Behavioral health providers that did not meet the criteria to be considered an eligible professional, eligible hospital, or CAH were not eligible for these incentive payments. For example, behavioral health providers who were physicians (eligible professionals) could receive the incentive payments, but other types of non-physician behavioral health providers may not have been eligible. Today, behavioral health providers lag behind their peers in the ability to electronically share health information across providers and with patients. ONC noted that, in 2017, only 12 percent of office-based physicians reported sending data to behavioral health providers, while 14 percent of officebased physicians reported receiving data from behavioral health providers.70 Other technical and regulatory restrictions, such as 42 CFR part 2, which governs the confidentiality of substance use disorder patient records maintained by a covered substance use disorder treatment program can also inhibit the exchange of behavioral health information. Understanding the time and cost of implementing an EHR system, we are interested in evaluating whether using other applications that exchange data using FHIR-based APIs and do not require implementation of a full EHR system might be a way to help behavioral health providers leverage technology to exchange health data to improve care quality and coordination in a more agile fashion. Specifically, would small practices, communitybased providers, and other nontraditional providers be able to more quickly adopt applications using API technology to exchange health information when the technology is not tied to an EHR? Would these providers be able to achieve the same care coordination goals using such applications as with a more extensive EHR implementation, or would the value be lower but still sufficient to improve care quality and care coordination? 70 Office of the National Coordinator. ‘‘Interoperability among Office-Based Physicians in 2015 and 2017.’’ ONC Data Brief No. 47 (May 2019). Retrieved from https://www.healthit.gov/sites/ default/files/page/2019-05/ 2015to2017PhysicianInteroperabilityDataBrief_ 0.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82638 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules Over the past few years, HHS continued to highlight the importance of coordinated care and removing any unnecessary obstacles. In 2018, HHS launched the ‘‘Regulatory Sprint to Coordinated Care’’ prompting agencies within the Department to assess a variety of long-standing regulatory requirements to see whether they hinder innovative progress and how they can better incentivize coordination. We have also seen the Substance Abuse and Mental Health Services Administration (SAMHSA) publish regulations related to improved care coordination among providers that treat substance use disorders as well as protecting those patients’ records (42 CFR part 2), and the enactment of the Substance UseDisorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT for Patients and Communities Act) (Pub. L. 115–271, October 24, 2018), which encouraged us to consider ways to facilitate information sharing among behavioral health providers. In the spirit of the ‘‘Regulatory Sprint to Coordinated Care’’ and these policies, we are looking for innovative approaches to addressing the need to facilitate the electronic exchange of behavioral health information, as well as approaches to support the exchange of health information to behavioral health providers to inform care and provision of behavioral health services. Many behavioral health providers are in the community. As a result, when thinking about behavioral health specifically, it is valuable to think about community-based providers more broadly. We are interested in public comments on how we might best support electronic data exchange of behavioral health information between and among behavioral health providers, other health care providers, and patients, as well as how we might best inform and support the movement of health data (and its consistency) to behavioral health providers for their use to inform care and treatment of behavioral health services. Specifically, we are seeking public comments on the following questions: • Can applications using FHIR-based APIs facilitate electronic data exchange between behavioral health providers and with other health care providers, as well as their patients, without greater EHR adoption? Is EHR adoption needed first? What opportunities do FHIR-based APIs provide to bridge the gap? What needs might not be addressed by the use of applications with more limited functionality than traditional EHRs? VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 • What levers could CMS consider using to facilitate greater electronic health data exchange from and to behavioral health providers? What costs, resources, and/or burdens are associated with these options? • Are there particular considerations for electronic data exchange for behavioral health providers who practice independently, are communitybased, or are non-traditional providers? What about rural-based behavioral health providers? How could an APIbased solution help address these considerations? • Are there state or federal regulations or payment rules that are perceived as creating barriers to technical integration of systems within these practices? What additional policy issues, technical considerations, and operational realities should we consider when looking at ways to best facilitate the secure electronic exchange of health information that is maintained by behavioral health providers including sensitive health information? • What levers and approaches could CMS consider using and advancing to facilitate greater electronic health data exchange from and to community-based health providers including use of relevant health IT standards as feasible? What costs, resources, and/or burdens are associated with these options? We seek comments on these questions and issues for future consideration. B. Electronic Exchange of Behavioral Health Information Several factors have led to an EHR adoption rate that is significantly lower among behavioral health providers compared to other types of health care providers. One possible contributing factor was that the Health Information Technology for Economic and Clinical Health Act (Pub. L. 111–5, enacted February 17, 2009) (HITECH Act) made Medicare fee-for-service and Medicaid incentive payments for the adoption and meaningful use of certified EHR technology available only to eligible professionals, eligible hospitals, and critical access hospitals (CAH). Behavioral health providers that did not meet the criteria to be considered an eligible professional, eligible hospital, or CAH were not eligible for these incentive payments. For example, behavioral health providers who were physicians (eligible professionals) could receive the incentive payments, but other types of non-physician behavioral health providers may not have been eligible. Today, behavioral health providers lag behind their peers in the ability to electronically share health information PO 00000 Frm 00054 Fmt 4701 Sfmt 4702 across providers and with patients. ONC noted that, in 2017, only 12 percent of office-based physicians reported sending data to behavioral health providers, while 14 percent of officebased physicians reported receiving data from behavioral health providers.71 Other technical and regulatory restrictions, such as 42 CFR part 2, which governs the confidentiality of substance use disorder patient records maintained by a covered substance use disorder treatment program can also inhibit the exchange of behavioral health information. Understanding the time and cost of implementing an EHR system, we are interested in evaluating whether using other applications that exchange data using FHIR-based APIs and do not require implementation of a full EHR system might be a way to help behavioral health providers leverage technology to exchange health data to improve care quality and coordination in a more agile fashion. Specifically, would small practices, communitybased providers, and other nontraditional providers be able to more quickly adopt applications using API technology to exchange health information when the technology is not tied to an EHR? Would these providers be able to achieve the same care coordination goals using such applications as with a more extensive EHR implementation, or would the value be lower but still sufficient to improve care quality and care coordination? Over the past few years, HHS continued to highlight the importance of coordinated care and removing any unnecessary obstacles. In 2018, HHS launched the ‘‘Regulatory Sprint to Coordinated Care’’ prompting agencies within the Department to assess a variety of long-standing regulatory requirements to see whether they hinder innovative progress and how they can better incentivize coordination. We have also seen the Substance Abuse and Mental Health Services Administration (SAMHSA) publish regulations related to improved care coordination among providers that treat substance use disorders as well as protecting those patients’ records (42 CFR part 2), and the enactment of the Substance UseDisorder Prevention that Promotes Opioid Recovery and Treatment for Patients and Communities Act (SUPPORT for Patients and 71 Office of the National Coordinator. ‘‘Interoperability among Office-Based Physicians in 2015 and 2017.’’ ONC Data Brief No. 47 (May 2019). Retrieved from https://www.healthit.gov/sites/ default/files/page/2019-05/2015to2017Physician InteroperabilityDataBrief_0.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules Communities Act) (Pub. L. 115–271, October 24, 2018), which encouraged us to consider ways to facilitate information sharing among behavioral health providers. In the spirit of the ‘‘Regulatory Sprint to Coordinated Care’’ and these policies, we are looking for innovative approaches to addressing the need to facilitate the electronic exchange of behavioral health information, as well as approaches to support the exchange of health information to behavioral health providers to inform care and provision of behavioral health services. Many behavioral health providers are in the community. As a result, when thinking about behavioral health specifically, it is valuable to think about community-based providers more broadly. We are interested in public comments on how we might best support electronic data exchange of behavioral health information between and among behavioral health providers, other health care providers, and patients, as well as how we might best inform and support the movement of health data (and its consistency) to behavioral health providers for their use to inform care and treatment of behavioral health services. Specifically, we are seeking public comments on the following questions: • Can applications using FHIR-based APIs facilitate electronic data exchange between behavioral health providers and with other health care providers, as well as their patients, without greater EHR adoption? Is EHR adoption needed first? What opportunities do FHIR-based APIs provide to bridge the gap? What needs might not be addressed by the use of applications with more limited functionality than traditional EHRs? • What levers could CMS consider using to facilitate greater electronic health data exchange from and to behavioral health providers? What costs, resources, and/or burdens are associated with these options? • Are there particular considerations for electronic data exchange for behavioral health providers who practice independently, are communitybased, or are non-traditional providers? What about rural-based behavioral health providers? How could an APIbased solution help address these considerations? • Are there state or federal regulations or payment rules that are perceived as creating barriers to technical integration of systems within these practices? What additional policy issues, technical considerations, and operational realities should we consider when looking at ways to best facilitate VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 the secure electronic exchange of health information that is maintained by behavioral health providers including sensitive health information? • What levers and approaches could CMS consider using and advancing to facilitate greater electronic health data exchange from and to community-based health providers including use of relevant health IT standards as feasible? What costs, resources, and/or burdens are associated with these options? We seek comments on these questions and issues for future consideration. D. Reducing Burden and Improving Electronic Information Exchange of Prior Authorizations As discussed in section II.C. of this proposed rule, we believe there are many benefits to using electronic prior authorization solutions. Specifically, we propose to require impacted payers to implement, maintain, and use a Prior Authorization Support API. However, as we discuss in section VII. of this proposed rule, the health care system would gain maximum benefits if providers adopted use of the Prior Authorization Support API as well. As a result, we are requesting information for consideration in future rulemaking regarding how CMS can best incentivize providers to use electronic prior authorization solutions. 1. Electronic Prior Authorization for Medicare- and Medicaid-Participating Providers and Suppliers We have been working with the provider community to ensure that the Conditions of Participation, Conditions for Certification, and Conditions for Coverage (CoPs and CfCs) reflect the latest advances in health information technology and interoperability to the greatest extent possible. For instance, the CMS Interoperability and Patient Access final rule (85 FR 25510, finalized on May 1, 2020) revised the CoPs for hospitals, psychiatric hospitals, and critical access hospitals (CAHs) by adding new standards that require a hospital, including a psychiatric hospital, or a CAH, which utilizes an electronic medical records system or other electronic administrative system that meets certain technical specifications, to demonstrate that it sends electronic patient event notifications to the patient’s primary care practitioner, practice group, or other practitioner or practice group identified by the patient as being responsible for his or her primary care, when a patient is admitted to, and discharged (and/or transferred) from, the hospital or the CAH. PO 00000 Frm 00055 Fmt 4701 Sfmt 4702 82639 The notifications must include, at a minimum, the patient’s name, the name of the treating practitioner, and the name of the sending institution. These provisions were finalized at § 482.24(d), ‘‘Electronic notifications,’’ for hospitals; at § 482.61(f), ‘‘Electronic notifications,’’ for psychiatric hospitals; and at § 485.638(d), ‘‘Electronic notifications,’’ for CAHs. The CMS Interoperability and Patient Access final rule (85 FR 25510) requires hospitals, including psychiatric hospitals, and CAHs to implement the patient event notification provisions by April 30, 2021. As we explained in that final rule, there is growing evidence that health information exchange can lower cost and improve outcomes, particularly when the exchange of information, such as a patient event notification, is between providers. These exchanges are associated with better care coordination, a reduction in 30-day readmissions, and improved medication reconciliation, for instance (85 FR 25585). In reviewing other areas where the electronic exchange of patient information through interoperable systems offers significant opportunities for improvements for direct patient care, and also to overall health care system efficiency, we have identified electronic prior authorization as an area that might benefit from these technological advances. As we have discussed elsewhere in this proposed rule, we believe that the electronic prior authorization process is an opportunity to reduce burden and improve care. Prior authorization is the request and approval for payment of items and services (including prescription drugs) provided by Medicare- and Medicaidparticipating providers and suppliers (including, but not limited to, hospitals, psychiatric hospitals, and CAHs) to beneficiaries. We recognize that there are gaps in the current prior authorization process, including: • Prior authorization requirements not residing within a provider’s EHR or not being visible to the provider or staff members as part of the workflow; • Inability to rely on a consistent submission method for prior authorization requests. In many cases, only some of the process is automated, or electronic, making for a hybrid process that is partially computer-based through an EHR or practice management system, and partially manual, requiring phone calls, faxes, or emails, resulting in various workarounds that may or may not meld together; • Paper forms and portals require manual data reentry that may already reside electronically within an EHR; and • There are multiple routes to obtain a prior authorization depending on the E:\FR\FM\18DEP2.SGM 18DEP2 82640 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 payer, item or service, and provider (such as a hospital). We are interested in learning what barriers exist for hospitals (and other providers and suppliers) to electronically transmit prior authorization requests and receive prior authorization decisions for patients receiving care and services by the applicable provider. We believe answers to the following questions would be beneficial in obtaining additional information on the overall electronic prior authorization process, the impact of this process on patient health and safety issues, and whether the hospital (and other providers and suppliers)CoP requirements are a good vehicle to achieve nearly universal adoption and use of electronic prior authorization requests and receipts: • What are the current barriers to transmitting prior authorization requests and receipts electronically? What actions could CMS and/or industry take to remove barriers? • Do the current methods for electronic transmission of prior authorization requests and receipts, including the adopted standard, and any that have been established and maintained by third-party health care insurers (including Medicare) provide the efficient and timely request and receipt of prior authorization decisions? Please provide relevant detail in your response. • Would the CMS CoP/CfC requirements for hospitals and other providers and suppliers be the appropriate lever by which CMS should propose new or additional provisions that would require the electronic request and receipt of prior authorization decisions? If so, under which provisions would this best be accomplished? We intend to utilize this information as we evaluate opportunities to revise the hospital and CAH CoP requirements related to electronic prior authorization request and receipt. 2. Request for Information: Future Electronic Prior Authorization Use in the Merit-Based Incentive Payment System (MIPS) As discussed in section II.C. of this proposed rule, we believe the tools to support more efficient electronic prior authorization processes have the potential to greatly reduce the amount of time needed for submitting, reviewing, and making prior authorization decisions. We are considering ways to encourage clinicians to use electronic prior authorization solutions and are seeking input on the addition of an VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 improvement activity for the MeritBased Incentive Payment System (MIPS). The Medicare Access and CHIP Reauthorization Act of 2015 (Pub. L. 114–10) established MIPS for certain Medicare-participating eligible clinicians, a system that will make payment adjustments based upon scores from four performance categories. We first established policies for MIPS in the CY 2017 Quality Payment Program final rule (81 FR 77008 through 77831) and annually thereafter. Section 1848(q)(2)(C)(v)(III) of the Act defines an improvement activity as an activity that relevant eligible clinician organizations and other relevant stakeholders identify as improving clinical practice or care delivery, and that the Secretary determines, when effectively executed, is likely to result in improved outcomes. For previous discussions on the background of the improvement activities performance category, we refer readers to the CY 2017 Quality Payment Program final rule (81 FR 77177 through 77178), the CY 2018 Quality Payment Program final rule (82 FR 53648 through 53661), the CY 2019 Physician Fee Schedule (PFS) final rule (83 FR 59776 through 59777), and the CY 2020 PFS final rule (84 FR 62980 through 62990). We also refer readers to 42 CFR 414.1305 for the definition of improvement activities and attestation, § 414.1320 for the performance period, § 414.1325 for data submission requirements, § 414.1355 for the improvement activity performance category generally, § 414.1360 for data submission criteria, and § 414.1380(b)(3) for improvement activities performance category scoring. In section II.C of this proposed rule, we note that prior authorization is the process through which a provider must obtain approval from a payer before providing care, and prior to receiving payment for delivering items or services. In that section, we propose that state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs implement and maintain a Prior Authorization Support (PAS) Application Programing Interface (API) conformant with the HL7 Fast Healthcare Interoperability Resources (FHIR) (PAS) IG beginning January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). We believe the PAS API would provide an opportunity to leverage the convenience and efficiency of API technology, while maintaining compliance with the mandated HIPAA transaction standard, to accelerate electronic prior authorization adoption PO 00000 Frm 00056 Fmt 4701 Sfmt 4702 and use by enabling the prior authorization process to be integrated into a provider’s EHR or practice management system. Providers could leverage the PAS API to improve care coordination and patient and clinician shared decision making through improvements to the prior authorization process, particularly if the API is integrated into the provider workflow. We believe that MIPS eligible clinicians would also benefit from the PAS API, and we are seeking comment on whether we should add a MIPS improvement activity to our Inventory that would utilize this PAS API to facilitate submitting and receiving electronic prior authorization requests and decisions to reduce burden, improve efficiency, and ultimately ensure patients receive the items and services they need in a timely fashion. We believe this could fall under the care coordination subcategory (81 FR 77188) and section 1848(q)(2)(B)(iii) of the Act. We refer readers to Table H in the Appendix of the CY 2017 Quality Payment Program final rule (81 FR 77177 through 77199), Tables F and G in the Appendix of the CY 2018 Quality Payment Program final rule (82 FR 54175 through 54229), Tables X and G in the Appendix 2 of the CY 2019 PFS final rule (83 FR 60286 through 60303), and Tables A, B, and C in the Appendix 2 of the CY 2020 PFS final rule (84 FR 63514 through 63538) for our previously finalized improvement activities Inventory. We also refer readers to the Quality Payment Program website at https://qpp.cms.gov/ for a complete list of the most current improvement activities. We are interested in comments regarding the addition of a MIPS improvement activity, and if this area will be appropriate to encourage clinicians to make certain improvements. • Is this an activity that stakeholders identify as improving clinical practice or care delivery? • When effectively executed, is implementation of such technology and use of these standards likely to result in improved outcomes? • If yes, should this activity be assigned a medium-weight or highweight? We refer readers to section III.I.3.h.(4)(d)(i)(C) of CY 2019 PFS final rule (83 FR 59776 through 59777) where we discussed that high-weighting should be used for activities that directly address areas with the greatest impact on beneficiary care, safety, health, and well-being and/or is of high intensity, requiring significant investment of time and resources. If the E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 addition of a MIPS improvement activity incorporating the use of a FHIRbased Prior Authorization Support API is not an incentive to encourage clinicians to use electronic prior authorization solutions, are there other ways that we could do so? In addition to the above questions, we are also seeking comment on the following questions regarding how best to encourage the use of electronic prior authorization: • Should CMS consider adding a measure to the Medicare Promoting Interoperability Program for eligible hospitals and critical access hospitals and the MIPS Promoting Interoperability performance category for clinicians and groups to encourage the use of electronic prior authorization through a payer’s Prior Authorization Support API? • What are the primary considerations for developing such a measure? • How would the measure require the use of certified electronic health record technology? • Should the Prior Authorization Support IG be incorporated into potential future certification requirements for health IT under the ONC Health IT Certification Program? • Should CMS consider additional measures and activities under MIPS Quality, Cost, or Improvement Activities performance categories involving FHIRbased electronic prior authorization solutions? • If so, what are the primary considerations for developing such measures and activities? • What other approaches should CMS consider to help support clinician use of electronic prior authorization solutions such as the Prior Authorization Support API? E. Reducing the Use of Fax Machines CMS is continually looking for ways to facilitate efficient, effective, and secure electronic data exchange to help ensure more timely, better quality, and highly coordinated care. Historically, we have relied on fax technology as a primary method for sharing information across the health care system, which can allow for easy sending and receiving of documents. However, the data in those documents are not easily integrated electronically into a patient’s medical record or shared in an interoperable way with other payers and providers. Therefore, using fax technology limits our ability to reach true interoperability. Fax technology creates inefficiencies. It requires time spent manually pulling together clinical and administrative data from EHRs and practice management VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 systems, transmitting data back and forth between health care providers and payers using a mechanism slower than the internet, and making frequent follow-up phone calls between health care providers and other providers and payers to clarify unclear transaction statuses in real-time. We discuss examples of these inefficiencies further in sections II.C. and V.C. of this proposed rule, to which we refer readers. To work toward true interoperability, we believe we must reduce or completely eliminate the use of fax technology in health care. To this end, we seek comment on how CMS can reduce or completely eliminate the use of fax technology across programs, including both hospitals and post-acute care facilities, so that information can be shared electronically in real time without extensive follow-up to determine if the information was received. At CMS, we are working to identify all programs and processes that currently require and/or encourage the use of fax technology for data exchange to determine whether the use of fax can be removed or significantly reduced in those programs. We acknowledge that there are instances where the use of fax may be necessary to send data, for example, where rural providers do not have sufficient internet access to exchange certain data electronically and must rely on fax technology, and also the impact of reduced fax use on preparedness and response to disasters. We note section 202(c) of the EGovernment Act of 2002 (Pub. L. 107– 347, December 17, 2002), requires CMS to avoid diminished access for those lacking internet access or computer access. We seek a balance and want to ensure that elimination of fax technology in CMS programs does not eliminate options for those without internet access. In an effort to reduce burden and increase efficiency, we are requesting feedback from the public on how electronic data exchange could replace fax technology. Specifically, we are seeking stakeholder feedback on the following questions: • What specific programs, processes, workflows, or cases are you currently using a fax machine to accomplish? In what ways would replacing this with an electronic data exchange, such as via a FHIR-based API, add value, efficiencies, and/or improve patient care? Are there specific processes (such as prior authorization) that you would prioritize first to reduce the reliance on fax technology? Has your organization implemented an electronic data PO 00000 Frm 00057 Fmt 4701 Sfmt 4702 82641 exchange in an effort to reduce the reliance on the fax machine? • What challenges might payers and providers face if use of the fax technology for health care data exchange is completely eliminated? Are there particular types of providers or health care settings that would be more negatively impacted than others? What solutions might mitigate these challenges? • What recommendations are there for balancing the goal of improving efficiencies in health care data exchange through reducing the use of fax while ensuring that health care providers without ready access to internet can still share information? • To what extent can electronic and cloud-based fax technology bridge the gap between electronic transmission and traditional fax technology? • What impact will the reduction of use of fax technology have on preparedness and response to disasters? How might organizations begin to reduce reliance on this technology, and mitigate these impacts? F. Request for Information: Accelerating the Adoption of Standards Related to Social Risk Data CMS recognizes that social risk factors (for example, housing instability, food insecurity) impact beneficiary health and utilization outcomes. Providers in value-based payment arrangements rely on comprehensive, high-quality data to identify opportunities to improve patient care and drive value. When implemented effectively, value-based payment encourages clinicians to care for the whole person and address the social risk factors that are critical for beneficiaries’ quality of life. As value-based payment has grown, so has provider interest in data on social risk factors. For example, a recent study 72 found that 24 percent of hospitals and 16 percent of physician practices were screening patients for all five health-related social needs (housing, food, transportation, utilities, and safety needs) included in the Accountable Health Communities model. Providers use these data to inform care and connect patients with the right community resources and supports. Unfortunately, social risk data are often fragmented and duplicative due to a lack of clear standards for recording and exchanging these data. For example, multiple providers who cannot exchange these data with each other may ask the same beneficiary similar 72 See https://www.ncbi.nlm.nih.gov/pubmed/ 31532515. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82642 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules questions, or hospitals within a single system may all collect varying food insecurity data in different formats. Additionally, relevant data collected by community-based organizations outside the health sector can be difficult to integrate and utilize. Siloed data increase the burden on beneficiaries, create inefficiencies in managing referrals for social services, create duplicative workflows in an already strained system, and impede opportunities to provide higher quality care. As providers assume greater accountability for costs and outcomes through value-based payment, they need tools to successfully identify and address social risk factors to improve care and health outcomes. Over the last several years, a variety of community led efforts are developing industry-wide standards 73 to collect social risk data, electronically represent these data, and enable exchange of person-centered data between medical providers and community-based organizations through health information technology platforms. CMS seeks input on barriers the health care industry faces to using industry standards and opportunities to accelerate adoption of standards related to social risk data. Specifically: • What are the challenges in representing and exchanging social risk and social needs data from different commonly used screening tools? How do these challenges vary across screening tools or social needs (for example, housing, food)? • What are the barriers to the exchange of social risk and social needs data across providers? What are key challenges related to exchange of social risk and social needs data between providers and community-based organizations? • What mechanisms are currently used to exchange social risk and social needs data (EHRs, HIEs, software, cloudbased data platforms, etc.)? What challenges, if any, occur in translating social risk data collected in these platforms to Z-codes on claims? • How can health care payers promote exchange of social risk and social needs data? Are there promising practices used by public or private payers that can potentially be further leveraged in other settings? 73 See https://www.healthit.gov/buzz-blog/ interoperability/advancing-interoperable-socialdeterminants-of-health-data. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 IV. Incorporation by Reference A. Standards, Implementation Guides, and Specifications 1. National Technology Transfer and Advancement Act The National Technology Transfer and Advancement Act (NTTAA) of 1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget (OMB) Circular A–119 74 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. The NTTAA and OMB Circular A–119 provide exceptions to electing only standards developed or adopted by voluntary consensus standards bodies, namely when doing so would be inconsistent with applicable law or otherwise impractical. In these cases, agencies have the discretion to decline the use of existing voluntary consensus standards, and instead can use a governmentunique standard or other standard. In addition to the consideration of voluntary consensus standards, the OMB Circular A–119 recognizes the contributions of standardization activities that take place outside of the voluntary consensus standards process. Therefore, as stated in OMB Circular A– 119, in instances where use of voluntary consensus standards would be inconsistent with applicable law or otherwise impracticable, other standards should be considered that meet the agency’s regulatory, procurement, or program needs; deliver favorable technical and economic outcomes; and, are widely utilized in the marketplace. In this proposed rule, we propose use of voluntary consensus standards, including implementation guides (IGs) and specifications. 2. Compliance With Adopted Standards, Implementation Guides, and Specifications In accordance with the Office of the Federal Register (OFR) regulations related to ‘‘incorporation by reference,’’ 1 CFR part 51, which we follow when we adopt proposed standards, implementation guides, or specifications in any subsequent final rule, the entire standard, implementation guide, or specification document is deemed published in the Federal Register when incorporated by reference therein with the approval of the Director of the Federal Register. Once published, compliance with the 74 https://www.whitehouse.gov/sites/ whitehouse.gov/files/omb/circulars/A119/revised_ circular_a-119_as_of_1_22.pdf. PO 00000 Frm 00058 Fmt 4701 Sfmt 4702 standard, implementation guide, or specification includes the entire document unless specified otherwise in regulation. For example, if the Health Level 7® (HL7) Fast Healthcare Interoperability Resources® (FHIR) Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version STU 1.0.0 proposed in this rule is adopted (see section II.E. of this proposed rule), and API requirements for payers based on this IG are finalized (see section II.D. of this proposed rule, payers developing and implementing a Documentation Requirements Lookup Service (DRLS) application programming interface (API) would need to demonstrate compliance with all mandatory elements and requirements of the IG. If an element of the IG is optional or permissive in any way, it would remain that way for compliance unless we specified otherwise in regulation. In such cases, the regulatory text would preempt the permissiveness of the implementation guide. This also applies to standards and specifications. 3. ‘‘Reasonably Available’’ to Interested Parties The OFR has established requirements for materials (for example, standards, implementation guides, and specifications) that agencies propose to incorporate by reference in Federal Regulations (79 FR 66267; 1 CFR 51.5(a)). To comply with these requirements, in this section we provide summaries of, and uniform resource locators (URLs) to the standards, implementation guides, and specifications we propose to adopt and subsequently incorporate by reference in the Code of Federal Regulations (CFR). To note, we also provide relevant information about these standards, implementation guides, and specifications throughout the relevant sections of the proposed rule. B. Incorporation by Reference OFR has established requirements for materials (for example, standards, IGs, or specifications) that agencies propose to incorporate by reference in the CFR (79 FR 66267; 1 CFR 51.5(a)). Section 51.5(a) requires agencies to discuss, in the preamble of a proposed rule, the ways that the materials it proposes to incorporate by reference are reasonably available to interested parties or how it worked to make those materials reasonably available to interested parties, and summarize in the preamble of the proposed rule, the material it proposes to incorporate by reference. To make the materials we intend to incorporate by reference reasonably E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules available, we provide a URL for the IGs and specifications. In all cases, these IGs and specifications are accessible through the URLs provided by selecting the specific version number from the version history page the URL directly links to. In all instances, access to the IGs or specification can be gained at nocost (monetary). There is also no requirement for participation, subscription, or membership with the applicable standards developing organization (SDO) or custodial organization to obtain these materials. As noted above, the NTTAA and OMB Circular A–119 require the use of, wherever practical, technical standards that are developed or adopted by voluntary consensus standards bodies to carry out policy objectives or activities, with certain exceptions. As discussed, HHS has followed the NTTAA and OMB Circular A–119 in proposing standards, IGs, and specifications for adoption. HHS has worked with HL7 to make the IGs and specifications being proposed for adoption and subsequently incorporated by reference in the Federal Register, available to interested stakeholders. As discussed in section II.B. of this proposed rule, all HL7 FHIR IGs are developed through an industryled, consensus-based public process. HL7 is an American National Standards Institute (ANSI) accredited standards development organization. HL7 FHIR standards are unique in their ability to allow disparate systems that otherwise represent data differently to exchange such data in a standardized way that all systems can share and consume via standards-based APIs. HL7 FHIR IGs are also openly accessible, so any interested party can go to the HL7 website and access the IG. Once accessed, all public comments made during the balloting process as well as the version history of the IGs are available for review. In this way all stakeholders can fully understand the lifecycle of a given IG. Use of such guidance facilitates interoperability in a transparent and cost-effective way that ensures the IGs are informed by, and approved by, industry leaders looking to use technology to improve patient care. As such, all of the standards we propose for HHS adoption and subsequent incorporation by reference are developed and/or adopted by voluntary consensus standards bodies. As required by § 51.5(a), we provide summaries of the standards we propose to adopt and subsequently incorporate by reference in the Code of Federal Regulations. We also provide relevant information about these standards, implementation guides, and VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 specifications throughout the relevant sections of the proposed rule. Standards Including Implementation Guides and Specifications for Health Care Interoperability—45 CFR Part 170 • HL7 FHIR Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/davincicrd/history.html. This is a link to the version history. Select the specified version from the list on this page to access the IG and all related documentation. Summary: The purpose of this IG is to define a workflow whereby payers can share coverage requirements with clinical systems at the time treatment decisions are being made. This ensures that clinicians and administrative staff have the capability to make informed decisions and can meet the requirements of the patient’s insurance coverage. We are specifically proposing this IG to support the DRLS API discussed by CMS in section II.C. of this proposed rule. The various CMSregulated insurance and coverage products accepted by a given provider may have very different requirements for prior authorization documentation. Providers who fail to adhere to payer requirements may find that costs for a given service are not covered or not completely covered. The outcome of this failure to conform to payer requirements can be increased out of pocket costs for patients, additional visits and changes in the preferred care plan, and increased burden. The information that may be shared using this IG includes: —Updated coverage information. —Alternative preferred/first-line/lowercost services/products. —Documents and rules related to coverage. —Forms and templates. —Indications of whether prior authorization is required. • HL7 FHIR Da Vinci— Documentation Templates and Rules (DTR) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/davincidtr/history.html. This is a link to the version history. Select the specified version from the list on this page to access the IG and all related documentation. Summary: This IG specifies how payer rules can be executed in a provider context to ensure that documentation requirements are met. The DTR IG is a companion to the CRD IG, which uses Clinical Decision PO 00000 Frm 00059 Fmt 4701 Sfmt 4702 82643 Support (CDS) Hooks 75 to query payers to determine if there are documentation requirements for a proposed medication, procedure, or other service. When those requirements exist, CDS Hooks Cards will be returned with information about the requirements. This IG leverages the ability of CDS Hooks to link to a Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR 76 app to launch and execute payer rules. The IG describes the interactions between the SMART on FHIR app and the payer’s IT system to retrieve the payer’s documentation requirements, in the form of Clinical Quality Language (CQL) 77 and a FHIR Questionnaire resource, for use by the provider. The goal of DTR is to collect clinical documentation and/or to encourage the completion of documentation that demonstrates medical necessity for a proposed medication, procedure, or other service. To accomplish this, the IG details the use of a payer provided Questionnaire resource and results from CQL execution to generate a Questionnaire Response resource containing the necessary information. Essentially, the provider’s EHR communicates to the payer’s system, which informs the EHR of the documentation that needs to be completed—this is the Questionnaire resource. To populate the Questionnaire response, this IG supports the provider’s EHR in populating the response form with the relevant patient information from the patient’s electronic record. As much as can be auto-populated by the system is completed. The IG then instructs the system to alert a provider to any gaps in information that may need to be manually filled before the Questionnaire response resource is sent back to the payer through the EHR via the SMART on FHIR app. This IG will also support the DRLS API discussed by CMS in section II.C. of this proposed rule. • HL7 FHIR Da Vinci—Prior Authorization Support (PAS) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/davincipas/history.html. This is a link to the version history. Select the specified version from the list on this page to access the IG and all related documentation. Summary: The PAS IG uses the FHIR standard as the basis for assembling the information necessary to substantiate the need for a particular treatment and submitting that information and the 75 https://cds-hooks.org/. 76 https://docs.smarthealthit.org/. 77 https://cql.hl7.org/. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82644 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules request for prior authorization to an intermediary end point. That endpoint is responsible for ensuring that any HIPAA requirements are met. The response from the payer is intended to come back to that intermediary endpoint and be available to the provider’s EHR solution using the FHIR standard. The goal is to provide real time prior authorization, where possible, in the provider’s clinical workflow. This IG, in this way, strives to enable direct submission of prior authorization requests initiating from a provider’s EHR system or practice management system. To meet regulatory requirements, these FHIR interfaces will communicate with an intermediary that converts the FHIR requests to the corresponding X12 instances prior to passing the requests to the payer. Responses are handled by a reverse mechanism (payer to intermediary as X12, then converted to FHIR and passed to the provider’s EHR). Direct submission of prior authorization requests from the provider’s EHR will reduce costs for both providers and payers and result in faster prior authorization decisions resulting in improved patient care and experience. When combined with the Da Vinci CRD and DTR IGs, direct submission of prior authorization requests will further increase efficiency by ensuring that authorizations are always sent when (and only when) necessary, and that such requests will almost always contain all relevant information needed to make the authorization decision on initial submission. This IG also defines capabilities around the management of prior authorization requests, including checking the status of a previously submitted request, revising a previously submitted request, and cancelling a request. This IG will support the Prior Authorization Support API discussed by CMS in section II.C. of this proposed rule. • HL7 FHIR Da Vinci—Payer Coverage Decision Exchange (PCDE) Implementation Guide: Version STU 1.0.0. URL: https://www.hl7.org/fhir/us/ davinci-pcde/history.cfml. This is a link to the version history. Select the specified version from the list on this page to access the IG and all related documentation. Summary: The IG defines standardized mechanisms for a patient or payer to enable a transfer of ‘‘current active treatments’’ with other relevant metadata and coverage-related information from a prior payer to a new payer. It also defines a standardized VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 structure for organizing and encoding that information to ease its consumption by the new payer organization. This IG addresses the need for continuity of treatment when patients move from one payer’s health insurance or benefit plan to another. In the current situation, the patient and new payers often do not have the information needed to continue treatment in progress or to determine that the therapies are necessary or medically appropriate. As a result, patients can face a break in continuity of care, challenges to share additional information, and increased costs as tests are re-run or prior therapies need to be re-tested in order to comply with the rules of the new payer. By enabling an authorized transfer of information from the original payer to the new payer, the new payer can have access to information about what therapies are currently in place and the rationale for them, as well as what precursor steps have been taken to demonstrate the medical necessity and appropriateness of the current therapy. By automating this exchange and maximizing the computability of the information shared, a process that frequently takes weeks or months can be reduced to a few days or even minutes reducing costs and improving patient safety, quality, and experience. This IG will support the Payer-to-Payer API discussed by CMS in section II.D. of this proposed rule. • HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/carin-bb/ history.html. This is a link to the version history. Select the specified version from the list on this page to access the IG and all related documentation. Summary: This IG describes the CARIN for Blue Button Framework, providing a set of resources that payers can exchange with third-parties to display to consumers via a FHIR-based API. This IG will help impacted payers share adjudicated claims and encounter data via the Patient Access API discussed by CMS in section II.A. of this proposed rule. It includes data elements and coding instructions each impacted payer can use to prepare and share the specified data. • HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/davincipdex/history.html. This is a link to the version history. Select the specified version from the list on this page to access the IG and all related documentation. PO 00000 Frm 00060 Fmt 4701 Sfmt 4702 Summary: This IG enables payers to create a member’s health history from clinical Resources based on FHIR Release 4 that can be exchanged with other payers, providers, and thirty-party applications. It supports patientauthorized exchange to a third-party application, such as the patientrequested prior authorization information via the Patient Access API as discussed in section II.A. of this proposed rule. It will also support exchanging active prior authorization decisions between payers and providers via the Provider Access API discussed by CMS in section II.B. of this proposed rule. • HL7 FHIR Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide: Version STU 1.0.1. URL: https://hl7.org/fhir/us/Davincidrug-formulary/history.html. This is a link to the version history. Select the specified version from the list on this page to access the IG and all related documentation. Summary: This IG defines a FHIR interface to a health insurer’s current drug formulary information for patient access. A drug formulary is a list of brand-name and generic prescription drugs a payer agrees to pay for, at least partially, as part of health insurance or benefit coverage. Drug formularies are developed based on the efficacy, safety, and cost of drugs. The primary use cases for this FHIR interface is to enable patients’ ability to understand the costs and alternatives for drugs that have been or can be prescribed, and to enable the comparison of their drug costs across different insurance plans. This IG would support the inclusion of current formulary and preferred drug list information via the Patient Access API as discussed by CMS in section II.A. of this proposed rule. • HL7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide: Version STU 1.0.0. URL: https://www.hl7.org/fhir/us/ davinci-pdex-plan-net/history.cfml. This is a link to the version history. Select the specified version from the list on this page to access the IG and all related documentation. Summary: This IG is modeled off of the Validated Healthcare Directory Implementation Guide (VHDir), an international standard developed to support a conceptual, centralized, national source of health care data that would be accessible to local directories and used across multiple use cases. VHDir, as a basis for a centralized health care directory, is in development. This PlanNet IG leverages the lessons learned E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules A. Background Under the Paperwork Reduction Act of 1995, we are required to provide 30day notice in the Federal Register and solicit public comment before a collection of information requirement is submitted to the Office of Management and Budget (OMB) for review and approval. To fairly evaluate whether an information collection should be approved by OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act of 1995 Payers are in a unique position to offer patients and providers a holistic view of a patient’s health care data that might otherwise be distributed across disparate IT systems. Payers should have the capability to exchange data with patients and providers for care and payment coordination or transitions, and to facilitate more efficient care. To advance our commitment to interoperability, we are proposing new requirements for various impacted CMSregulated payers to implement a series of standards-based APIs. These standards-based APIs would permit patients and providers to have access to As indicated, we are adjusting the employee hourly wage estimates by a factor of 100 percent. This is necessarily a rough adjustment, both because fringe benefits and overhead costs vary significantly across employers, and because methods of estimating these costs vary widely across studies. V. Collection of Information Requirements khammond on DSKJM1Z7X2PROD with PROPOSALS2 requires that we solicit comment on the following issues: • The need for the information collection and its usefulness in carrying out the proper functions of our agency. • The accuracy of our estimate of the information collection burden. • The quality, utility, and clarity of the information to be collected. • Recommendations to minimize the information collection burden on the affected public, including automated collection techniques. We are soliciting public comment on each of these issues for the following sections of this document that contain information collection requirements (ICRs): VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 PO 00000 Frm 00061 Fmt 4701 Sfmt 4702 a defined set of standardized data. We believe that these proposals would help facilitate coordinated care by helping to ensure that patients can access their own health information, and that providers can access the health care data of their patients through the use of common technologies, without special effort and in an easily usable digital format. We additionally propose to reduce prior authorization burden on payers, providers, and patients, especially in terms of delays in patient care, through a number of proposals that would require impacted payers to implement standards-based APIs for prior authorization processes, reduce the amount of time to process prior authorization requests, and publicly report certain metrics about prior authorization processes for transparency, among other proposals. B. Wage Estimates To derive average costs, we use data from the U.S. Bureau of Labor (BLS) Statistics’ National Occupational Employment and Wage Estimates for Direct Health and Medical Insurance Carriers (NAICS Code 524114) (https:// www.bls.gov/oes/current/oes_nat.htm). Table 1 presents the mean hourly wage, the cost of fringe benefits (calculated at 100 percent of salary), and the adjusted hourly wage. Nonetheless, there is no practical alternative, and we believe that doubling the hourly wage to estimate E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.000</GPH> and input provided throughout the extended VHDir development process, which has been informed by a large cross-section of stakeholders, and to address a more narrow scope of health care directory needs. This IG specifically allows payers to share basic information about their own, local networks via a publicly-accessible API. At a minimum, this IG will support impacted payers sharing their providers’ names, addresses, phone numbers, and specialties, which is the information required to be shared via the Provider Directory API discussed by CMS in section II.A. of this proposed rule. Where the VHDir IG looks to create a central resource that a payer, for instance, could use to populate their local directory; the PlanNet IG allows the payer to make their local directory accessible to the public via an API. 82645 82646 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules total cost is a reasonably accurate estimation method. C. Information Collection Requirements (ICRs) Consistent with our approach in the CMS Interoperability and Patient Access final rule (85 FR 25622–25623), we determine ICRs by evaluating cost and burden at the parent organization level, as defined and discussed in detail in that rule. In that final rule, we provided a detailed rationale for how we determined the number of parent organizations (85 FR 25622). For this proposed rule, we used a similar approach to determine the number of parent organizations. We started by reviewing the parent organizations of health plans across Medicaid and CHIP managed care and QHP issuers on the FFEs to remove organizations that would not be subject to our proposed policies. We then de-duplicated the list to accurately represent those parent organizations that have multiple lines of business across programs only once. Ultimately, we determined that there are 209 parent organizations across Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. In addition, we again identified 56 states, territories, and U.S. commonwealths which operate FFS programs, as well as one state that operates its CHIP and Medicaid FFS programs separately, for a total of 266 parent organizations that together represent the possible plans, entities, issuers, and state programs impacted by these proposals. We are interested to hear from the public regarding this methodology and whether parent organizations can implement the following information collection requirements across their lines of business. khammond on DSKJM1Z7X2PROD with PROPOSALS2 1. ICRs Regarding Patient Access API Proposal (42 CFR 431.60, 438.242, 457.730, 457.1233, and 45 CFR 156.221) To improve patient access to their health information, as discussed in section II.A. of this proposed rule, we are proposing to expand the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510). Specifically, we are proposing that impacted payers implement the API conformant with a specific set of IGs at 45 CFR 170.215 to improve interoperability. We are also proposing to enhance the API by VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 proposing to require information about pending and active prior authorization decisions be made available by all impacted payers. The cost of upgrading the Patient Access API to be conformant with the specified IGs is accounted for in the maintenance costs estimated in the CMS Interoperability and Patient Access final rule (85 FR 25607). We note that those maintenance costs also include costs for MA organizations, which are still relevant to the CMS Interoperability and Patient Access final rule policies, and would not be directly regulated by these proposed policies. As discussed therein, the maintenance we estimated accounts for additional capability testing and long-term support of the APIs, increased data storage needs, such as additional servers, or cloud storage to store any additional patient health information, and allocation of resources to maintain the FHIR server. In the CMS Interoperability and Patient Access final rule (85 FR 25510), we provided a link to additional information about the set of IGs that we are now proposing to require, and we encouraged, but did not require, the use of the these IGs. We understand that most payers are currently using these IGs to implement the API. We seek comment on our assumptions that use of these IGs is adequately accounted for in the maintenance costs of the Patient Access API in the CMS Interoperability and Patient Access final rule. We are also proposing to require the Privacy Policy Attestation provision that we had presented as an option in the CMS Interoperability and Patient Access final rule (85 FR 25549 through 25550). Facilitating this attestation process is part of the regular work of keeping the API up to date and functioning. 2. ICRs Regarding Reporting Patient Access API Metrics to CMS Proposal (42 CFR 431.60, 438.242, 457.730, 457.1233, and 45 CFR 156.221) In order to assess whether our policy requirements concerning the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25558) are providing patients information in a transparent and timely way, we are proposing at 42 CFR 431.60(h), 438.242(b)(5), 457.730(h), 457.1233(d)(2), and 45 CFR 156.221(i) to require impacted payers to report quarterly to CMS certain metrics PO 00000 Frm 00062 Fmt 4701 Sfmt 4702 on use of the Patient Access API. We estimate that impacted payers would conduct two major work phases: 1) implementation, which includes defining requirements and system design (and updates) to generate and compile reports; and 2) maintenance, compiling and transmitting quarterly reporting to CMS. In the first phase (implementation), we believe impacted payers would need to define requirements concerning the types and sources of data that would need to be collected on the use of the Patient Access API and build the capability for a system to generate data that can be sent to CMS. In the second phase (maintenance), we believe impacted payers would need to prepare the quarterly data to be transmitted to CMS. The burden estimate related to the new proposed requirements reflects the time and effort needed to collect the information described above and to disclose the information. We estimate an initial set of one-time costs associated with implementing the reporting infrastructure, and an ongoing annual maintenance cost to report after the reporting infrastructure is set up. Table 2 presents our estimates for first year implementation and ongoing maintenance costs. For example, in the second row of Table 2, we estimate for first-year implementation that Business Operations Specialists would spend 60 hours at a wage of $72.62 an hour for a total cost of $4,357.20. As captured in the bottom two rows of Table 2: • First-year implementation would require, on average, a total of 160 hours per organization at an average cost of $14,645.20 per organization. • Therefore, the aggregate burden of the first-year implementation across 266 parent organizations would be 42,560 hours (160 hours * 266 parent organizations) at a cost of $3,895,623 ($14,645.20 * 266 parent organizations). • Similarly, ongoing maintenance after the first year would require a total of 40 hours per organization per year at an average cost of $2,904.80 per organization. • Therefore, the aggregate burden of ongoing maintenance across 266 parent organizations would be 10,640 hours (40 hours * 266 parent organizations) at a cost of $772,677 ($2,904.80 * 266 parent organizations). E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 3. ICRs Regarding Provider Directory API Proposal (42 CFR 431.70, 438.242, 457.760, and 457.1233) As discussed in section II.A. of this proposed rule, we are proposing to require impacted payers implement and maintain the Provider Directory API conformant with the HL7 FHIR Da Vinci Payer Data Exchange Plan Net IG. The Provider Directory API was finalized in the CMS Interoperability and Patient Access final rule (85 FR 25564). We note that those maintenance costs also include costs to MA organizations, which are still relevant to the CMS Interoperability and Patient Access final rule policies, and would not be directly regulated by these proposed policies. In the CMS Interoperability and Patient Access final rule (85 FR 25562), we encouraged, but did not require the use of this IG. We seek comment on this assumption that use of the IG is fully accounted for in the maintenance costs from the CMS Interoperability and Patient Access final rule. khammond on DSKJM1Z7X2PROD with PROPOSALS2 4. ICRs Regarding Provider Access API Proposal (42 CFR 431.61, 438.242, 457.731, 457.1233, and 45 CFR 156.222) To promote our commitment to interoperability, we propose new requirements for APIs at 42 CFR 431.61(a), 438.242(b)(5), 457.731(a), 457.1233(d)(2), and 45 CFR 156.222(a). This standards-based Provider Access API would permit providers to retrieve standardized patient data to facilitate coordinated care. To estimate costs to implement the new requirements for all new APIs proposed in this rule, we are using the same methodology that we used in the CMS Interoperability and Patient Access final rule (85 FR 25510). In the CMS Interoperability and Patient Access final rule (85 FR 25510), we estimated that impacted payers would conduct three major work phases: Initial design; development and testing; and long-term support and maintenance. In this proposed rule, we VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 assume the same major phases of work would be required, with a different level of effort during each work phase for each of the new proposed APIs. Consistent across all new proposed API provisions, we describe below the tasks associated with the first two phases. Where we believe additional effort associated with these tasks is necessary, we describe those as relevant in subsequent ICRs depending on how we believe they impact cost estimates. We discuss the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs below in this section. In the initial design phase, we believe tasks would include: Determining available resources (personnel, hardware, cloud storage space, etc.); assessing whether to use in-house resources to facilitate an API connection or contract the work to a third party; convening a team to scope, build, test, and maintain the API; performing a data availability scan to determine any gaps between internal data models and the data required for the necessary FHIR resources; and, mitigating any gaps discovered in the available data. During the development and testing phase, we believe impacted payers would need to conduct the following: Map existing data to the HL7 FHIR standards, which would constitute the bulk of the work required for implementation; allocate hardware for the necessary environments (development, testing, production); build a new FHIR-based server or leverage existing FHIR-based servers; determine the frequency and method by which internal data is populated on the FHIR-based server; build connections between the databases and the FHIRbased server; perform capability and security testing; and vet provider requests. The payers impacted by the proposed Provider Access API provision are required by the CMS Interoperability and Patient Access final rule by January PO 00000 Frm 00063 Fmt 4701 Sfmt 4702 1, 2021 (beginning with plan years beginning on or after January 1, 2021 for QHP issuers on the FFEs) 78 (85 FR 25510) to implement a FHIR-based Patient Access API using the same baseline standards. These include HL7 FHIR Release 4.0.1, and complementary security and app registration protocols, specifically the SMART Application Launch Implementation Guide (SMART IG) 1.0.0 (including mandatory support for the ‘‘SMART on FHIR Core Capabilities’’), which is a profile of the OAuth 2.0 specification. Therefore, we believe payers will be able to gain efficiencies and leverage efforts and knowledge of the staff required to build, implement, and maintain the Provider Access API (as well as the other APIs in this proposed rule) because part of the cost of training and staff necessary is built into the development of the APIs required in the CMS Interoperability and Patient Access final rule (85 FR 25510). One additional requirement new for both the Provider Access API and the Payer-to-Payer API is conformance with the HL7 FHIR Bulk Data Access (Flat FHIR) specification. We believe this is an additional package layer on top of the baseline standards that supports the exchange of health information for one or more patients at a time in a secure manner. We believe this would require additional development. We are also proposing that the Provider Access API include active and pending prior authorization decisions and related clinical documentation and forms, including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to-date. We factor in these proposed requirements in the estimated 78 In the CMS Interoperability and Patient Access final rule, we finalized that these provisions would be applicable to data with a date of service on or after January 1, 2016, beginning January 1, 2021, and enforced beginning July 1, 2021 taking into account the 6 months of enforcement discretion we are exercising as a result of the current public health emergency (PHE). E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.001</GPH> We solicit comment on our assumptions and approach. 82647 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules costs for the Provider Access API in Table 3. We assume this cost accounted for here will absorb costs to include the same data in other proposed APIs. As a result, we account for these new costs once appreciating the efficiencies of using the same mapped data across more than one API. We seek comment on this assumption that the underlying content and exchange standards can be shared across the multiple APIs discussed in this proposed rule. Our estimates as summarized in Table 3 are based on feedback from industry experts on the anticipated burden to implement the HL7 FHIR Bulk Data Access (Flat FHIR) specification— including input based on CMS’ experience with the DPC pilot discussed in section II.B. of this proposed rule. Therefore, we believe this to be a reasonable estimate of the implementation burden. The burden estimate related to the new requirements for APIs reflects the time and effort needed to collect the information described above and to disclose this information. We estimate an initial set of one-time costs associated with implementing the proposed Provider Access API requirements. Below we describe the burden estimates for the development and implementation phases for the Provider Access API. Table 3 presents the total activities, hours, and dollar burdens for the implementation of the Provider Access API (initial design phase and the development and testing phase). Based on the same assumptions as those included in the CMS Interoperability and Patient Access final rule (85 FR 25510), we have selected the medium estimate as the primary estimate. As can be seen from the bottom rows of Table 3: • One-time implementation efforts for the first two phases would (for the primary estimate) require on average a total of 2,800 hours per organization at an average cost of $275,743 per organization. • The aggregate burden of the firstyear implementation across 266 parent organizations would be 744,800 hours (2,800 hours * 266) at a cost of $73.3 million ($275,743 * 266). This corresponds to the primary estimate; the primary and high estimates are obtained by multiplying the low estimate by a factor of two and three, respectively. Although this provision would be first applicable January 1, 2023, we believe it is reasonable that the APIs will be under development prior to this date. Acknowledging that impacted payers will have varying technological and staffing capabilities, we estimate that development of the APIs will require six to 12 months of work. Expecting that this rule will be finalized in early 2021, we have distributed the cost estimates over approximately 2 calendar years of time to reflect payers being given flexibility regarding when they complete the work (see Table 10, summary table). We solicit comment on our approach and assumptions for the cost of the Provider Access API, including whether our estimates and ranges are reasonable or should be modified. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 PO 00000 Frm 00064 Fmt 4701 Sfmt 4702 E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.002</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 82648 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules a. API Maintenance Costs We discuss the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all four proposed APIs below. As relevant to the APIs discussed in sections V.C.4., 5., 6., and 10., we estimate ongoing maintenance costs for the Provider Access API, DRLS API, PAS API, and Payer-to-Payer API in aggregate. This approach aligns with the approach taken in the CMS Interoperability and Patient Access final rule (85 FR 25606–25607) whereby the costs of API development are split into three phases: Initial design, development and testing, and long-term support and maintenance. However, unlike the CMS Interoperability and Patient Access final rule, this rule assumes that maintenance costs only account for cost associated with the technical requirements as outlined in this rule. Any changes to requirements would require additional burden which would be discussed in future rulemaking. Throughout this Collection of Information section, we discuss initial design and development, and testing costs per API. We now discuss a total maintenance cost for all four APIs. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25606), once the API is established, we believe that there would be an annual cost to maintain the FHIR server, which includes the cost of maintaining the necessary patient data, supporting the privacy policy attestation, and performing capability and security testing. We do believe there are efficiencies gained in implementation and maintenance due to the fact that these proposed APIs rely on several of the same underlying foundational technical and content. For example, the same baseline standards including the HL7 FHIR Release 4.0.1, and complementary security and app registration protocols—specifically the SMART Application Launch Implementation Guide (SMART IG) 1.0.0 (including mandatory support for the ‘‘SMART on FHIR Core Capabilities’’), which is a profile of the OAuth 2.0 specification, as noted above. However, we do believe that maintenance costs will be higher than what we estimated for the CMS Interoperability and Patient Access final rule (85 FR 25510) for the new APIs proposed in this rule as our estimates also account for new data mapping needs, standards upgrades, additional data storage, system testing, initial bug VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 fixes, fixed-cost license renewals, contracting costs, and ongoing staff education and training. In order to account for these maintenance costs, we based our estimates on input from industry experience piloting and demoing APIs for provider access, prior authorization, and payer-to-payer data exchange. We estimate an annual cost averaging approximately 25 percent of the primary estimate for one-time API costs, or $575,285 per parent organization ($275,743 (Provider Access API) + $984,181 (DRLS API) + $936,400 (PAS API) + $104,816 (Payer-to-Payer API) * 25 percent) (see V.C.4., 5., 6., and 10. for calculation of these estimates). Therefore, the aggregate maintenance burden across 266 parent organizations would be approximately $153,025,810 ($575,284 * 266). In Table 10 (summary table) we account for this maintenance cost separately for each API (at 25 percent of the one-time API cost) but, as discussed previously, the overlap in IGs across the proposed APIs, for example, is a shared efficiency that we believe supports the assumption that maintenance should be accounted for in aggregate and is presented in this section as such. We solicit public comment on our approach and assumptions for the aggregate maintenance cost of the APIs, including whether our estimate is reasonable or should be modified. 5. ICRs Regarding Documentation Requirement Lookup Service (DRLS) API Proposal (42 CFR 431.80, 438.242, 457.732, 457.1233, and 45 CFR 156.223) To promote our commitment to interoperability, we propose requirements for DRLS API at 42 CFR 431.80(a)(1), 438.242(b)(5), 457.732(a)(1), 457.1233(d)(2), and 45 CFR 156.223(a)(1). This DRLS API, would permit providers to access data showing whether prior authorization is required by the payer for the requested item or service, and if so, the documentation requirements for submitting the prior authorization request. This API is proposed to be conformant with the CRD and DTR IGs, and would begin January 1, 2023 (for Medicaid and CHIP managed care plans, by the rating period beginning on or after January 1, 2023). As discussed above regarding the Provider Access API, to implement the new requirements for the DRLS API, we estimate that impacted payers would conduct three major work phases: Initial design, development and testing, and long-term support and maintenance. Additionally, for this proposed API, we believe additional tasks are necessary to PO 00000 Frm 00065 Fmt 4701 Sfmt 4702 82649 accomplish the proposed requirements, which we describe below as they impact the cost estimates. As discussed previously, the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs is presented in section V.C.4. of this proposed rule. We base our estimates on feedback from industry experts on the anticipated burden to implement the DRLS API, including input from our own experience working on the prototype as further discussed in section II.C. of this proposed rule. We base our estimates on our own experience because we believe many impacted payers will find the experience similar to that used to estimate the cost. Additionally, the necessary IGs are openly available as HL7 provides access to all IGs as open source materials. Thus, HL7 IGs and many reference implementations and test scripts are also available free of charge to the health care community. These shared resources help support our belief that other payers will incur similar costs. Lessons learned from this DRLS prototype experience to-date indicate the efforts may require clinical expertise and software and web developers. As such, we have accounted for the necessary engineers, subject matter experts, and health informaticists. These personnel resources would, for example, need to convert payer prior authorization documentation rules into computable formats, create provider questionnaires regarding whether a patient had a medical necessity for a medical item or service, create formats that could interface with the provider’s EHR or practice management system, and integrate the DRLS API with the payer’s system. Table 4 presents the total activities, hours, and dollar burdens for the implementation of the DRLS API (initial design phase and the development and testing phase). Based on the same assumptions as those included in the CMS Interoperability and Patient Access final rule (85 FR 25510), we have selected the mid-range estimate as the primary estimate. As can be seen from the bottom rows of Table 4: • One-time implementation efforts for the first two phases would (for the primary estimate) require on average a total of 9,630 hours per organization at an average cost of $984,181 per organization. • Aggregate burden of the one-time implementation costs across 266 parent organizations would be 2,561,580 hours (9,630 hours * 266) at a cost of $261.8 million ($984,181 * 266). This E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules corresponds to the primary estimate; the primary and high are obtained by multiplying the low estimate by a factor of two and three, respectively. As noted previously, although this provision would be first applicable January 1, 2023, we believe it is reasonable that the APIs will be under development prior to that date. Acknowledging that impacted payers will have varying technological and staffing capabilities, we estimate that development of the APIs will require six to 12 months of work. Expecting that this rule will be finalized in early 2021, we have distributed the cost over approximately two calendar years of time to give payers the flexibility to complete the work necessary (see Table 10, summary table). We solicit public comment on our approach and assumptions for the cost of the DRLS API, including whether our estimates and ranges are reasonable or should be modified. would be required to implement the PAS API, and, when sending the response, include information regarding whether the organization approves (and for how long), denies, or requests more information for the prior authorization request. This API must be conformant with the HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG beginning January 1, 2023 (for Medicaid and CHIP managed care plans, by the rating period beginning on or after January 1, 2023). As discussed previously, to implement the new requirements for the PAS API, we estimate that impacted payers would conduct three major work phases: Initial design, development and testing, and long-term support and maintenance. Additionally, for this proposed PAS API, we believe additional tasks are necessary to accomplish the proposed requirements, which we describe below as they impact the cost estimates. As discussed previously, the costs for the third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs is presented in section V.C.4. of this proposed rule. 6. ICRs Regarding Prior Authorization Support (PAS) API Proposal (42 CFR 431.80, 438.242, 457.732, 457.1233, and 45 CFR 156.223) We are also proposing new requirements for a PAS API at 42 CFR 431.80(a)(2), 438.242(b)(5), 457.732(a)(2), 457.1233(d)(2), and 45 CFR 156.223(a)(2). Impacted payers VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 PO 00000 Frm 00066 Fmt 4701 Sfmt 4702 Our estimates are based on feedback from industry experts on the anticipated burden to implement the PAS API. We believe this to be a reasonable estimate of the implementation burden. Payers would need to develop APIs that could receive providers’ prior authorization requests, and associated documentation and send the payer’s decision. In addition to implementing the PAS API, these payers would also be required to send a reason for denial for any prior authorization decisions that are denied. We note, as discussed in section II.C. of this proposed rule, while the PAS API will leverage the HL7 FHIR standard, the prior authorization transactions would remain conformant with the X12 278 standard and thus remain HIPAAcompliant. As such, given the added complexity of accounting for the HIPAA standards, we have accounted for the multiple skill sets required in developing the burden estimates. Table 5 presents the total activities, hours, and dollar burdens for the implementation of the PAS API (initial design phase and the development and testing phase). Based on the same assumptions as those included in the CMS Interoperability and Patient Access E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.003</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 82650 82651 final rule (85 FR 25510), we have selected the medium estimate as the primary estimate. As can be seen from the bottom rows of Table 5: • One-time implementation efforts for the first two phases would (for the primary estimate) require on average a total of 9,200 hours per organization at an average cost of $936,400 per organization. • The aggregate burden of the onetime implementation costs across 266 parent organizations would be 2,447,200 hours (9,200 hours * 266) at a cost of $249.1 million ($936,400 * 266). This corresponds to the primary estimate; the primary and high are obtained by multiplying the low estimate by a factor of two and three, respectively. As noted previously, although compliance with this provision is required to begin January 1, 2023, the APIs will be under development prior to this date in order to be implemented and operational on January 1, 2023 (or the rating period that begins on or after January 1, 2023 for Medicaid managed care plans and CHIP managed care entities). Acknowledging that impacted payers will have varying technological and staffing capabilities, we estimate that development of the APIs will require six to 12 months of work. Expecting that this rule will be finalized in early 2021, we have distributed the cost over approximately two calendar years of time to give payers the flexibility to complete the work necessary (see Table 10, summary table). We solicit public comment on our approach and assumptions for the onetime implementation cost of the PAS API, including whether our estimates and ranges are reasonable or should be modified. The burden of this provision will be included in OMB Control #0938–NEW. Since this provision is only applicable to Medicaid and CHIP, only 235 of the 266 Parent Organizations, those parent organizations that offer Medicaid or CHIP plans, would have to implement this provision. In order to implement this policy, there would be up-front costs for impacted payers to update their policies and procedures, the burden for which we now estimate. We anticipate this burden per payer is 8 hours to update policies and procedures reflecting two half-days of work. We estimate a per entity cost of $946.40 (8 hours to develop * $118.30/hour, the hourly wage for General and Operations Managers). The total burden for all 235 payers is 1,880 hours (8 hours * 235), at an aggregate first year cost of $222,404 ($946.40 * 235). These calculations are summarized in Table 6. EP18DE20.005</GPH> 7. ICRs Regarding Requirement To Send Prior Authorization Decisions Within Certain Timeframes Proposals (42 CFR 438.210, 440.230, 457.495, and 457.1230) To increase transparency and reduce burden, we are proposing to require that impacted payers, not including QHP issuers on the FFEs, send prior authorization decisions within 72 hours for urgent requests and 7 calendar days for non-urgent requests at 42 CFR 438.210(d)(1), 440.230(d)(1), and 457.495(d)(1). We are proposing that the payers would have to comply with these provisions beginning January 1, 2023 (for Medicaid and CHIP managed care plans, by the rating period beginning on or after January 1, 2023). VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 PO 00000 Frm 00067 Fmt 4701 Sfmt 4725 E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.004</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules We solicit public comments on our assumptions and approach. 8. ICRs Regarding Public Reporting of Prior Authorization Metrics Proposal (42 CFR 438.210, 440.230, 457.732, 457.1233, and 45 CFR 156.223) In order to support transparency for patients in choosing health coverage, and for providers when selecting payer networks to join, we are proposing to require at 42 CFR 438.210(g), 440.230(d)(2), 457.732(a)(3), 457.1233(d)(2), and 45 CFR 156.223(a)(3) the applicable payers to publicly report, annually, certain planlevel prior authorization metrics on their websites or via publicly accessible hyperlink(s). Impacted payers would be required to report once, annually, by the end of the first calendar quarter each We solicit comment on this approach and our assumptions. 9. ICRs for Implementing Third Party Application Attestation for Privacy Provisions (42 CFR 431.60(g), 438.242(b)(5), 457.70(g), 457.1233(d)(2), and 45 CFR 156.221(h)) khammond on DSKJM1Z7X2PROD with PROPOSALS2 We are proposing at 42 CFR 431.60(g) for state Medicaid FFS programs, at 42 CFR 438.242(b)(5) for Medicaid managed care plans, at 42 CFR 457.730(g) for state CHIP FFS programs, at 42 CFR 457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(h) for QHP issuers on the FFEs that beginning January 1, 2023 (for VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 year for the prior year’s data beginning March 31, 2023. We estimate that impacted payers would conduct two major work phases: (1) Implementation, which includes defining requirements and system design (and updates) to generate and compile reports; and (2) maintenance, including annual compilation of reports and public reporting of metrics on a website or through a publicly accessible hyperlink(s). In the first phase, we believe impacted payers would need to define requirements concerning the types and sources of data that would need to be compiled regarding prior authorization activities, build the capability for a system to generate reports, and update or create a public web page to post the data. In the second phase, we believe impacted payers would need to create the quarterly reports and post to a public web page on an annual basis. • First-year implementation would require on average a total of 320 hours per organization at an average cost of $28,685.20 per organization. • Therefore, the aggregate burden of the first-year implementation across 266 parent organizations would be 85,120 hours (320 hours * 266) at a cost of $7,630,263 ($28,685.20/organization * 266). • Similarly, ongoing maintenance after the first year will require a total of 120 hours per organization at an average cost of $8,714.40 per organization. • Therefore, the aggregate burden of ongoing maintenance across 266 parent organizations would be 31,920 hours (120 hours * 266 parent organizations) at a cost of $2,318,030 ($8,714.40 * 266). Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023), that impacted payers must establish, implement, and maintain a process for requesting an attestation from a third-party app developer requesting to retrieve data via the Patient Access API that indicates the app adheres to certain privacy provisions. Since the two tasks of establishing, implementing, and maintaining a process for requesting an attestation from a third-party app developer and the task of informing patients of the privacy policy evaluation of the third- party app developer are connected, we estimate the cost together. PO 00000 Frm 00068 Fmt 4701 Sfmt 4702 We estimate the system work required is similar to the system work required for the public reporting requirements (Table 7) which involves both data lookup and data display. We therefore assume that first year development costs would involve 180 hours by a software developer working in collaboration with a business operations specialist for 140 hours to develop these systems. After the first year, the business operations specialist would require 120 hours to maintain the system. E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.006</GPH> 82652 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 10. ICRs Regarding Payer-to-Payer API Proposal (42 CFR 431.61, 438.242, 457.731, 457.1233, and 45 CFR 156.222) To reduce payer, and ultimately, provider burden and improve patient access to their health information through care coordination between payers, as discussed in section II.D. of this proposed rule, we are proposing new requirements at 42 CFR 431.61(c), 438.242(b), 457.731(c), 457.1233(d), and 45 CFR 156.222(b). These proposals would improve care coordination between payers by requiring payers to exchange, at a minimum, adjudicated claims and encounter data (not including remittances and enrollee costsharing information), clinical information as defined in the USCDI (version 1), and pending and active prior authorization decisions, using a FHIR-based Payer-to-Payer API by January 1, 2023 (for Medicaid and CHIP managed care plans, by the rating period beginning on or after January 1, 2023). As discussed for the other APIs being proposed in this rule, we estimate that impacted payers would conduct three major work phases: Initial design, development and testing, and long-term support and maintenance. Additionally, for this proposed API, we believe additional tasks are necessary to accomplish the proposed requirements, which we describe below as they impact the cost estimates. The costs for the VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 third phase, long-term support and maintenance, and our methodology for the development of those costs in aggregate for all proposed APIs is presented in section V.C.4. of this proposed rule. Payers should be able to leverage the API infrastructure already accounted for in other requirements, including the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510) and the Provider Access API proposal in this rule. As discussed in the CMS Interoperability and Patient Access final rule (85 FR 25510) (as well as the companion ONC 21st Century Cures Act final rule (85 FR 25642)) and this proposed rule, payers would be using the same FHIR standards for content and transport; IGs to support interoperability of data sharing; as well as the same underlying standards for security, authentication, and authorization. In addition, impacted payers would be required to implement the HL7 FHIR Bulk Data Access (Flat FHIR) specification for the Provider Access API, the same specification proposed for this Payer-to-Payer API, to support the exchange of patient health information for one or more patients at a time. Taken together, these standards would also support the proposed Payerto-Payer API. Thus, we believe there will be some reduced development costs to implement the Payer-to-Payer API because of efficiencies gained in implementing many of the same underlying standards and IGs for the Patient Access API and the other APIs proposed in this rule. We do believe there will be some costs for impacted payers to implement the proposed Payer-to-Payer API that are unique to this proposal. Even though there will be some efficiencies gained in using the same standards and IGs as other APIs, we believe based on input from industry experience in implementing APIs that there will be PO 00000 Frm 00069 Fmt 4701 Sfmt 4702 costs to test and integrate the Payer-toPayer API with payer systems, albeit potentially lower costs than estimated for the Provider Access API. We estimate the one-time implementation costs at about one-third the cost of a full de novo Provider Access API implementation based on input from developers who have implemented and piloted prototype APIs using the proposed required standards and IGs. As such, we have accounted for the necessary staff required as we also believe there will be unique costs for implementing the HL7 FHIR Payer Coverage Decision Exchange IG so that payers can exchange active and pending prior authorization decisions and related clinical documentation and forms when an enrollee or beneficiary enrolls with a new impacted payer. Table 9 presents the total activities, hours, and dollar burdens for the implementation of the Payer-to-Payer API given our assumptions above (initial design phase and the development and testing phase). Based on the same assumptions as those published in the CMS Interoperability and Patient Access final rule (85 FR 25510), we have selected the medium estimate as the primary estimate. As can be seen from the bottom rows of Table 9: • One-time implementation efforts for the first two phases would (for the primary estimate) require on average a total of 1,012 hours per organization at an average cost of $104,816 per organization. • Therefore, the aggregate burden of the one-time implementation costs across 266 parent organizations would be 269,192 hours (1,012 hours * 266) at a cost of $27.9 million ($104,816 * 266). This corresponds to the primary estimate; the primary and high are obtained by multiplying the low estimate by a factor of two and three, respectively. E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.007</GPH> The aggregate first year burden is therefore 85,120 hours (266 parent organizations *(180 for development plus 140 for input from a business operations specialist)) at a cost of $7.6 million (266 organizations * (180 hr * $102.88/hr for a software and web developer plus 140 hr * $72.62/hr for a business operations specialist). Second and later year burden would be 31,920 hours (266 parent organizations * 120 hr) at a cost of $2.3 million (266 parent organizations * 120 hr * $72.62/hr). 82653 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 As noted previously, although this provision would first be applicable January 1, 2023, we believe it is reasonable that the APIs will be under development prior to that date. Acknowledging that impacted payers will have varying technological and staffing capabilities, we estimate that development of the APIs will require six to twelve months of work. Expecting that this rule will be finalized in early 2021, we have distributed the cost estimates over approximately two calendar years of time to reflect impacted payers being given flexibility regarding when they complete the work (see Table 10). VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 We solicit public comments on our approach and assumptions for the cost of the Payer-to-Payer API, including whether our estimates and ranges are reasonable or should be modified. c. Summary of Information Collection Burdens The previous sections have detailed costs of individual provisions. Table 10 summarizes costs for the first, second, and subsequent years of these provisions (as described in detail above). Table 10 reflects an assumption of an early 2021 publication date for the final rule; the API provisions would be effective January 1, 2023. Table 10 PO 00000 Frm 00070 Fmt 4701 Sfmt 4702 reflects the primary estimates. Calculations of the high and low estimates for the APIs may be found in the tables and narrative of the relevant sections for each of the provisions as discussed in this Collection of Information section. Labor costs are either BLS wages when a single staff member is involved, or a weighted average representing a team effort obtained by dividing the aggregate cost (calculated in the tables above) by the aggregate hours; for example, in the first row the $91.53 equals the aggregate $3.9 million cost divided by the aggregate 42,560 hours. BILLING CODE 4120–01–P E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.008</GPH> 82654 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 D. Conclusion The provisions of this proposed rule could greatly improve data sharing across stakeholders by facilitating access, receipt, and exchange of patient data. This could both increase access to patient data and decrease burden associated with gaining access to patient data. We are committed to providing patients, providers, and payers with timely access to patient health information. We welcome comments on our approaches for estimating cost burden and cost savings. The requirements of this proposed rule are extensions of the requirements of the CMS Interoperability and Patient Access final rule (85 FR 25510). Therefore, the information collection requirements will be submitted to OMB for review and approval. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 If you would like to provide feedback on these information collections, please submit your comments electronically as specified in the ADDRESSES section of this proposed rule. Comments must be received on/by January 4, 2021. VI. Response to Comments Because of the large number of public comments we normally receive on Federal Register documents, we are not able to acknowledge or respond to them individually. We will consider all comments we receive by the date and time specified in the DATES section of this preamble, and, when we proceed with a subsequent document, we will respond to the comments in the preamble to that document. PO 00000 Frm 00071 Fmt 4701 Sfmt 4702 VII. Regulatory Impact Analysis A. Statement of Need As described in prior sections of this proposed rule, the proposed changes to 42 CFR parts 431, 435, 438, 440, and 457, and 45 CFR parts 156 and 170 further support the agency’s efforts to reduce burden on patients, providers, and payers, and to empower patients and providers by increasing electronic access to health care data, while keeping that information safe and secure. The proposals in this rule would largely build on the foundation we laid in the CMS Interoperability and Patient Access final rule (85 FR 25510). This proposed rule continues the efforts started with that final rule to move the health care system toward greater interoperability and reduce burden by proposing to increase the data sharing capabilities of impacted payers, encourage health care providers’ use of new capabilities, and E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.009</GPH> BILLING CODE 4120–01–C 82655 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82656 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules make patient data more easily available to them through standards-based technology. The provisions in this proposed rule would allow providers and payers new means to receive their patient population’s data from impacted payers through the Provider Access and Payerto-Payer APIs. This would allow providers to improve their ability to deliver quality care and improve care coordination by ensuring that providers have access to patient data at the point of care. These proposals would also assist impacted payers by improving their ability to exchange claims and clinical data on enrollees who switch payers or have concurrent payers, which would reduce burden and improve continuity of care for patients, as well as ensure more efficient payer operations. Further, patients would have more timely access to their claims and other health care information from impacted payers, empowering them to more directly understand and manage their own care through enhancements to the Patient Access API. Additionally, we believe these proposals would reduce burden on patients, providers, and payers, as well as reduce interruptions or delays in patient care by improving some aspects of the prior authorization process. To accomplish this, we are proposing a number of requirements, including proposing to require impacted payers implement and maintain a FHIR-based API to support a documentation requirement lookup service (DRLS). The DRLS API would be able to integrate with a provider’s EHR or practice management system to allow providers to discover the items and services that require prior authorization, as well as the documentation required to submit a prior authorization. Impacted payers would also be required to implement and maintain a Prior Authorization Support (PAS) API that would have the capability to accept and send prior authorization requests and decisions, and could be integrated directly in a provider’s workflow, while maintaining alignment with, and facilitating the use of, the required HIPAA transaction standards. As noted below, we believe that the policies in this proposed rule, if finalized, would result in some financial burdens for impacted payers. We have weighed these potential burdens against the potential benefits, and believe the potential benefits justify potential costs. B. Overall Impact We have examined the impacts of this proposed rule as required by Executive Order 12866 on Regulatory Planning VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 and Review (September 30, 1993), Executive Order 13563 on Improving Regulation and Regulatory Review (January 18, 2011), the Regulatory Flexibility Act (RFA) (September 19, 1980, Pub. L. 96–354), section 1102(b) of the Social Security Act, section 202 of the Unfunded Mandates Reform Act of 1995 (March 22, 1995; Pub. L. 104–4), Executive Order 13132 on Federalism (August 4, 1999), and Executive Order 13771 on Reducing Regulation and Controlling Regulatory Costs (January 30, 2017). Executive Orders 12866 and 13563 direct agencies to assess all costs and benefits of available regulatory alternatives and, if regulation is necessary, to select regulatory approaches that maximize net benefits (including potential economic, environmental, public health and safety effects, distributive impacts, and equity). Section 3(f) of Executive Order 12866 defines a ‘‘significant regulatory action’’ as an action that is likely to result in a rule: (1) Having an annual effect on the economy of $100 million or more in any one year, or adversely and materially affecting a sector of the economy, productivity, competition, jobs, the environment, public health or safety, or state, local or tribal governments or communities (also referred to as ‘‘economically significant’’); (2) creating a serious inconsistency or otherwise interfering with an action taken or planned by another agency; (3) materially altering the budgetary impacts of entitlement grants, user fees, or loan programs or the rights and obligations of recipients thereof; or (4) raising novel legal or policy issues arising out of legal mandates, the President’s priorities, or the principles set forth in the Executive Order. A Regulatory Impact Analysis must be prepared for major rules with economically significant effects ($100 million or more in any one year). We estimate that this rulemaking is ‘‘economically significant’’ as measured by the $100 million threshold, and hence a major rule under the Congressional Review Act. Accordingly, we have prepared a Regulatory Impact Analysis that, to the best of our ability, presents the costs and benefits of this rulemaking. C. Regulatory Flexibility Act Executive Order 13272 requires that HHS thoroughly review rules to assess and take appropriate account of their potential impact on small business, small governmental jurisdictions, and small organizations (as mandated by the Regulatory Flexibility Act (RFA)). If a PO 00000 Frm 00072 Fmt 4701 Sfmt 4702 proposed rule may have a significant economic impact on a substantial number of small entities, then the proposed rule must discuss steps taken, including alternatives considered, to minimize burden on small entities. The RFA does not define the terms ‘‘significant economic impact’’ or ‘‘substantial number.’’ The Small Business Administration (SBA) advises that this absence of statutory specificity allows what is ‘‘significant’’ or ‘‘substantial’’ to vary, depending on the problem that is to be addressed in rulemaking, the rule’s requirements, and the preliminary assessment of the rule’s impact. Nevertheless, HHS typically considers a ‘‘significant’’ impact to be three to five percent or more of the affected entities’ costs or revenues. For purposes of the RFA, we estimate that many impacted payers are small entities as that term is used in the RFA, either by being nonprofit organizations or by meeting the SBA definition of a small business. For purposes of the RFA, small entities include small businesses, nonprofit organizations, and small governmental jurisdictions. The North American Industry Classification System (NAICS) is used in the U.S., Canada, and Mexico to classify businesses by industry. While there is no distinction between small and large businesses among the NAICS categories, the SBA develops size standards for each NAICS category.79 Note that the most recent update to the NAICS went into effect for the 2017 reference year. We first review the provisions of this rule at a high level, and then discuss each of the impacted payer types, and through this discussion evaluate the impact on small entities. 1. Overview of Overall Impact The annual information collection burden estimates for the proposed requirements in this rule are summarized in Table 10 of the Collection of Information (section V. of this proposed rule). The specific information collection requirement (ICR) proposals, which we have calculated burden estimates for, include: (1) Provider Access API (Table 3); (2) DRLS API (Table 4); (3) PAS API (Table 5); (4) Proposed requirement to send prior authorization decisions within certain timeframes (Table 6); (5) Payer-to-Payer API (Table 9); (6) two metrics reporting requirements (specifically, Patient Access API and prior authorization metrics) (Tables 2 79 Office of Management and Budget. (2017). North American Industry Classification System. Retrieved from: https://www.census.gov/eos/www/ naics/2017NAICS/2017_NAICS_Manual.pdf. E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 and 7) and (7) Requirements to comply with privacy policy attestations (Table 8). Additionally, this Regulatory Impact Analysis section provides an analysis about potential savings from voluntary provider compliance with the DRLS and PAS API proposed provisions (however, this savings is neither included in monetized tables nor in summary tables, as further discussed below). We have identified assumptions for these analyses, and we solicit public comment. In analyzing the impact of this proposed rule, we note that there would be a quantifiable impact for the proposed Provider Access, DRLS, and PAS APIs. The proposed requirements would apply to 266 parent organizations. Throughout this proposed rule we use the term ‘‘parent organizations’’ to refer to impacted payers. These parent organizations include the states that administer state Medicaid and CHIP FFS programs, Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs. The NAICS category relevant to these proposed provisions is Direct Health and Medical Insurance Carriers, NAICS 524114, who have a $41.5 million threshold for ‘‘small size.’’ Seventy-five percent of insurers in this category have under 500 employees, thereby meeting the definition of small business. We are certifying that, for impacted payers, this proposed rule does not have a significant economic impact on a substantial number of small entities with regard to the provisions noted above. 2. Health Coverage Groups If the proposals in this rule are finalized, the 266 parent organizations, including state Medicaid and CHIP agencies, would be responsible for implementing and maintaining four new APIs, updating policies and procedures regarding timeframes for making prior authorization decisions, and reporting certain metrics either to CMS or the public. Medicaid managed care plans, CHIP managed care entities, and QHP issuers on the FFEs are classified as NAICS code 524, direct health insurance carriers. We are assuming that a significant number of these entities are not small. And, we note that none of the state Medicaid and CHIP agencies are considered small. At a high level, state Medicaid managed care plans and CHIP managed care entities have many of their costs covered through capitation payments from the federal government or through state payments. Therefore, there is no VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 significant burden, as detailed below. If finalized as proposed, QHP issuers on the FFEs and certain states operating Medicaid and CHIP FFS programs would be able to apply for an extension, exception or exemption under which they would not be required to meet the new API provisions of the proposed rule on the proposed compliance dates, provided certain conditions are met as discussed in sections II.B., II.C., and II.D. of this proposed rule. We therefore believe there is no significant burden to a significant number of entities from this proposed rule for these provisions as discussed. a. Medicaid and CHIP Title XIX of the Act established the Medicaid program as a federal-state partnership for the purpose of providing and financing medical assistance to specified groups of eligible individuals. States claim federal matching funds on a quarterly basis based on their program expenditures. Since states are not small entities under the Small Business Act we need not further discuss in this section the burden imposed on them by this rule. With regard to Medicaid managed care plans and CHIP managed care entities, since managed care plans receive 100 percent capitation payments from the state, we generally expect that the costs associated with the provisions of this proposed rule would be included in their capitation rates and may be reasonable, appropriate, and attainable costs whether they are a small business or not. Consequently, we can assert that there is no significant impact on a significant number of entities. As discussed in sections II.B., II.C., and II.D. for the new proposed API provisions, states operating Medicaid FFS and CHIP FFS programs could submit an application for an extension of up to one year to comply with the requirements of this rule. Additionally, we propose that states operating Medicaid and CHIP FFS programs with very low enrollment and high managed care penetration rates (at least 90 percent), can apply for an exemption under which they would not be required to meet certain proposed requirements, provided certain conditions are met. b. QHP Issuers on the FFEs Few, if any, QHP issuers on the FFEs are small enough to fall below the size thresholds for a small business established by the SBA. Consistent with previous CMS analyses, we estimate that any issuers that would be considered a small business are likely to be subsidiaries of larger issuers that are not small businesses (78 FR 33238) and PO 00000 Frm 00073 Fmt 4701 Sfmt 4702 82657 thus do not share the same burdens as an independent small business. Therefore, even though QHP issuers do not receive federal reimbursement for the costs of providing care, we do not conclude that there would be a significant small entity burden for these issuers. In addition, we propose an exception process for QHP issuers on the FFEs from certain proposed requirements, which further helps to address burden that could otherwise prohibit a QHP issuer from participating in an FFE. Based on the above, we conclude that the requirements of the RFA have been met by this proposed rule. D. UMRA and E.O. 13132 Requirements Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA) requires that agencies assess anticipated costs and benefits before issuing any rule whose mandates require spending in any one year of $100 million in 1995 dollars, updated annually for inflation. In 2020, that threshold is approximately $156 million. This proposed rule would not impose an unfunded mandate that would result in the expenditure by state, local, and tribal governments, in the aggregate, or by the private sector, of more than $156 million in any one year. Executive Order 13132 establishes certain requirements that an agency must meet when it promulgates a proposed rule (and subsequent final rule) that imposes substantial direct requirement costs on state and local governments, preempts state law, or otherwise has federalism implications. As previously outlined, while the API provisions would be a requirement for state Medicaid and CHIP agencies under these proposals, the cost per enrollee for implementation is expected to be negligible when compared with the overall cost per enrollee. This analysis does not take into account federal matching funds provided to state Medicaid and CHIP agencies, but the conclusion is the same: There is not expected to be a significant cost impact on state entities. For Medicaid and CHIP, we do not believe that the proposals in this rule would conflict with state law, and therefore, do not anticipate any preemption of state law. However, we invite states to submit comments on this proposed rule if they believe any proposal in this rule would conflict with state law, so that we can fully evaluate any potential conflicts. If regulations impose administrative costs on private entities, such as the time needed to read and interpret this proposed or final rule, we should estimate the cost associated with E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules regulatory review. We model our estimates of review burden based on similar estimates presented in the CMS Interoperability and Patient Access final rule (85 FR 25510). The particular staff involved in such a review would vary from one parent organization to another. We believe that a good approximation for a range of staff would be a person such as a medical and health service manager or a lawyer. Using the wage information from the BLS for medical and health services managers (Code 11–9111) and lawyers (Code 23–1011) we estimate that the cost of reviewing this proposed rule is $125.23 per hour, including overhead and fringe.80 This number was obtained by taking the average wage of a medical manager and lawyer. In the CMS Interoperability and Patient Access final rule (85 FR 25510), we estimated six hours of reading time. Therefore, we believe 10 hours would be enough time for each parent organization to review relevant portions of this proposed rule. We believe the review would be done by parent organizations that would be required to implement the proposed provisions. There are 266 parent organizations accounted for in our estimates. Thus, we estimate a one-time aggregated total review cost of $333,112 million ($125.23 * 10 hours * 266 entities). We solicit comments on our estimate. F. Alternatives Considered to address the critical issues related to patient access and interoperability or help to address the processes that contribute to payer, provider, and patient burden. We now discuss the alternatives we considered to our proposed provisions and the reasons why we did not select them as proposed policies. In this proposed rule, we continue to build on the efforts initiated with the CMS Interoperability and Patient Access final rule (85 FR 25510) and the work we have done to reduce burden in the health care system, to advance interoperability, improve care coordination, reduce burden, and empower patients with access to their health care data. This proposed rule covers a range of policies aimed at achieving these goals. We carefully considered alternatives to the policies we are proposing in this rule. We concluded that none of the alternatives would adequately or immediately begin 80 U.S. Bureau of Labor Statistics. (2019, April 02). May 2018 National Occupational Employment VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 E. Impact of Individual Proposals The proposed provisions of this rule would have information collectionrelated burden. Consequently, the impact analysis may be found in Table 10 of the Collection of Information in 1. Alternatives Considered for the Proposed Patient Access API Enhancements We are proposing to require that payers make enhancements to the Patient Access API finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510) including requiring section V. of this proposed rule. To facilitate review of the provisions and estimates made in the Collection of Information, we include Table 11, which provides the related ICRs in section V. of this proposed rule, the tables in section V. where impact is presented, as well as a title used for cross-reference in the remainder of this Regulatory Impact Analysis section. Table 19 of this section, using Table 10 as a basis, provides a 10-year impact estimate. Table 19 includes impact by year, by type (parent organizations, including Medicaid and CHIP state agencies), as well as the cost burden to the federal government, allocations of cost by program, and payments by the federal government to Medicaid and CHIP, as well as the premium tax credits (PTC) paid to certain enrollees in the individual market. the Patient Access API be conformant with the IGs specified in section II.A.2. of this proposed rule, proposing additional information be made available to patients through the Patient Access API, proposing a privacy attestation policy, and proposing certain metrics about patient use of the Patient Access API be reported directly to CMS quarterly. Before proposing to require these provisions, we considered several policy alternatives. As we discussed in the CMS Interoperability and Patient Access final rule (85 FR 25627), one alternative to the proposed updates to the Patient Access API we considered is allowing payers and providers to upload patient and Wage Estimates. Retrieved from https:// www.bls.gov/oes/current/oes_nat.htm. PO 00000 Frm 00074 Fmt 4701 Sfmt 4702 E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.010</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 82658 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules data directly to a patient portal, operated by a provider. However, despite the availability of patient portals, ONC reported in 2017 that only 52 percent of individuals have been offered online access to their medical records by a health provider or payer. And of the 52 percent that were offered access, only half of those viewed their record.81 Therefore, we do not believe that patient portals are meeting patients’ needs and would not be a suitable policy option to propose. We also believe that there would be additional burden associated with using portals, because providers and patients would need to utilize multiple portals and websites, requiring various log-ins, to access all of a patient’s relevant data— one for each provider a patient is associated with—instead of a single app. Portals would require developers to link systems or ensure system-level compatibility to enable patients to see a more comprehensive picture of their care. Alternatively, FHIR-based APIs have the ability to make data available without the need to link multiple systems or portals and would provide a patient a single point of access to their data. APIs that make data available to third-party apps permit the patient to choose how they want to access their data and promote innovation in industry to find solutions to best help patients interact with their data in a way that is most meaningful and valuable to them. The nature of portals does not lend as well to such interoperability or innovation. Because business models and processes pertaining to patient portals are varied across the industry, and any one patient could be associated with a number of different portals, we believe it would be very difficult to evaluate the cost impacts of requiring individual portals versus the estimates for enhancing the Patient Access API. As explained in the CMS Interoperability and Patient Access final rule (85 FR 25627), another alternative considered was to allow Health Information Exchanges (HIEs) and Health Information Networks (HINs) to serve as a central source for patients to obtain aggregated data from across their providers and payers in a single location. HIEs and HINs could provide patients with information via an HIE portal that is managed by the patient. However, as described above, there are various reasons why patient portal access does not lend itself to 81 Patel, V. & Johnson, C. (2018, April). Individuals’ Use of Online Medical Records and Technology for Health Needs (ONC Data Brief N. 40). Retrieved from https://www.healthit.gov/sites/ default/files/page/2018-03/HINTS-2017-ConsumerData-Brief-3.21.18.pdf. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 interoperability or innovation, and not all patients might have access to an HIE or HIN. For these reasons, we ultimately decided to proceed with our proposed requirements versus this alternative. We had also considered alternative compliance dates for the proposed policies. For instance, we considered January 1, 2022, as a possible compliance date for the Patient Access API enhancements. However, due to the current public health emergency and the enforcement discretion we are exercising for the API policies finalized in the CMS Interoperability and Patient Access final rule, we believe it is more appropriate, and less burdensome to impacted payers to propose compliance dates for these policies beginning January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). 2. Alternatives Considered for the Proposed Provider Access API In this proposed rule, to better facilitate the coordination of care across the care continuum, we are proposing to require impacted payers to implement and maintain a Provider Access API conformant with the specified HL7 FHIR IGs, as well as the HL7 FHIR Bulk Data Access (Flat FHIR) specification to support exchanging data for one or more patients at a time. This proposed API would require payers to make available to providers the same types of data they would make available to patients via the enhanced Patient Access API. Alternatively, we considered other data types that could be exchanged via the Provider Access API. We considered only requiring the exchange of clinical data, as defined in the USCDI. While this would be less data to exchange and, thus, potentially less burdensome for payers to implement, we believe that claims and encounter information can complement the USCDI data and offer a broader and more holistic understanding of a patient’s interactions with the health care system. Furthermore, the data that we propose to be available through the proposed Provider Access API aligns with the data that we propose be available to individual patients through the Patient Access API. Therefore, we do not believe there is significant additional burden to include these data as once the data are mapped and prepared to share via one FHIR-based API, these data are available for all payer APIs to use. We did also consider only having payer claims and encounter data available to providers, understanding that providers are generally the source of clinical data. Again, this could PO 00000 Frm 00075 Fmt 4701 Sfmt 4702 82659 potentially reduce burden on payers by potentially requiring less data to be made available. However, even if a provider is the source for the clinical data relevant to their patients’ care, a provider may not have access to clinical data from other providers a patient is seeing. As a result, and understanding payers were already preparing these data for use in other APIs, we decided a more comprehensive approach would be most beneficial to both providers and patients and thus aligned the proposed Provider Access API data requirements with those proposed for the Patient Access API. We also considered including additional data elements in this proposal. We considered requiring the patient’s complete medical record. However, we believe this would require additional resources and be overly burdensome for impacted payers at this time. The USCDI is a standardized set of health data classes and constituent data elements for nationwide, interoperable health information exchange.82 Because this limited set of data has been standardized, and corresponding HL7 FHIR IGs have been developed, payers can map these data and make them more easily available via an API. Industry has not yet fully developed the needed IGs to facilitate sharing a patient’s full medical record. Before this alternative would be feasible, more FHIR development work needs to be done, and important questions about data segmentation, and a patient’s role in potentially specifying what parts of their medical record could or should be available to which providers, need to be considered. 3. Alternatives Considered for the Proposed DRLS API and PAS API and Other Prior Authorization Proposals In this rule, we are also proposing several policies that would reduce burden associated with the prior authorization process. First, we are proposing to require all impacted payers implement and maintain a DRLS API conformant with the HL7 FHIR CRD and DTR IGs. We believe this would reduce burden for payers, providers, and patients by streamlining access to information about which items and services require a prior authorization and the associated documentation requirements, potentially reducing the number of incomplete and denied prior authorization requests. This would add efficiencies for both payers and 82 Interoperability Standards Advisory. (n.d.). U.S. Core Data for Interoperability. Retrieved from https://www.healthit.gov/isa/united-states-coredata-interoperability-uscdi. E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82660 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules providers, and it would improve patient care by avoiding gaps and delays in care. As proposed, by January 1, 2023, (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023), impacted payers would be required to implement the DRLS API, populate the API with their list of items and services for which prior authorization is required, populate the API with their associated documentation rules, and ensure the DRLS API is functional. Alternatively, we considered proposing a phased approach to the DRLS API where payers would first upload a specified subset of documentation to the DRLS API, as opposed to all of the documentation for all applicable items and services at one time. For instance, we considered requiring that payers only prepare the DRLS for a specific set of services most commonly requiring prior authorization across payers. However, we believe this would be more burdensome in some ways. It would require payers to use different systems to find requirements for different services for a single payer, for instance. If the requirements for different services were in different places—such as some information in payer portals and some through the DRLS API—providers would have to spend additional time searching for the information in multiple locations for one payer. Therefore, we believe it is ultimately less burdensome overall to require impacted payers to populate the prior authorization and documentation requirements for all items and services at the same time. We also considered whether we should propose to require that payers post, on a public-facing website, their list of items and services for which prior authorization is required, populate the website with their associated documentation rules as in interim step while they implement the DRLS. However, we are aware that payers already have this information publicly available, and determined that this would not provide any reduced burden on payers or providers at this time. We seek comment on whether a payer website to provide additional transparency to prior authorization requirements and documentation would be beneficial in reducing overall burden in this process. We are also proposing to require impacted payers implement and maintain a FHIR-based PAS API conformant with the HL7 FHIR Da Vinci PAS IG that would have the capability to accept and send prior authorization requests and decisions. This API would VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 be accessible to providers to integrate directly into their workflow, while maintaining alignment with, and facilitating the use of, the required HIPAA transaction standards. This requirement is proposed to be effective at the same time as the DRLS API, January 1, 2023 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2023). We considered a phased timeline approach to implement both of these APIs. For instance, we considered first requiring implementation of the DRLS API in 2022 and then a year later requiring implementation of the PAS API. However, given the current situation with the public health emergency, and taking into account the enforcement discretion we are exercising as a result for the APIs finalized in the CMS Interoperability and Patient Access final rule (85 FR 25510), we believe it is more appropriate, and less burdensome to impacted payers, to propose compliance dates for both of these policies in 2023, providing payers with more time to potentially implement both policies. We further determined that because the DRLS API and the PAS API are steps in the same prior authorization workflow, the full benefits of both APIs are best realized when used concurrently. We are proposing other provisions to reduce prior authorization burden including requiring payers to ensure that prior authorization decisions are made within 72 hours of receiving an expedited request and no later than 7 days after receiving a standard requests, and proposing to require impacted payers to publicly report prior authorization metrics on their websites or via publicly accessible hyperlink(s) annually. We considered several alternative policies before deciding to propose these policies. We considered alternative timeframes such as whether payers could provide a decision in less than 72 hours (for expedited decisions) and 7 days (for standard decisions). For example, we considered requiring payers to provide a decision in 48 hours for expedited requests and 3 days for standard requests. Despite the importance of having providers and patients get decisions as quickly as possible, we believe that the timeframes we propose in this rule would help increase reliability in the prior authorization process and establish clear expectations without being overly burdensome for payers. These timeframes would allow payers to process the prior authorization decisions in a timely fashion and give providers and patients an expectation PO 00000 Frm 00076 Fmt 4701 Sfmt 4702 for when they can anticipate a decision, while at the same time encouraging a timelier decision-making process. We also considered whether more than 7 days would be necessary for complex cases. We did not propose this alternative, however, because we believe it is important for patients and providers to be able to receive a decision in a shorter timeframe. We believe 7 days is sufficient time for a payer to process prior authorization decisions. Regarding publicly reporting prior authorization metrics, we considered requiring impacted payers to publicly report these metrics more frequently than annually. For instance, we considered a quarterly requirement. While we considered this alternative, we believe that our proposal is sufficient to accomplish our goals without creating additional burden. Because patients typically shop for health coverage on an annual basis, we believe updating this information annually would be sufficient for supplying patients and providers with transparent and valuable information. We also considered reporting these metrics at the parent organization versus at the plan or issuer level for all impacted payers. After further consideration, we decided this may not be truly operational and may be too aggregated a level of reporting for some payer types to provide true transparency or useful information for patients and providers. As a result, we are proposing reporting at the state-level for Medicaid and CHIP FFS, plan-level for Medicaid and CHIP managed care, and at the issuer-level for QHP issuers on the FFEs. 4. Alternatives Considered for the Proposed Payer-to-Payer API We are proposing to require impacted payers to implement and maintain a Payer-to-Payer API that makes the same data available to other payers via a FHIR-based API as we propose payers make available to patients and providers, conformant with the same IGs as proposed for the Patient Access API discussed in section II.A. and the Provider Access API discussed in section II.B. of this proposed rule. Before proposing these policies, we considered several policy alternatives. We considered proposing to enhance the Payer-to-Payer Data Exchange finalized in the CMS Interoperability and Patient Access final rule without naming a specific standard. We considered maintaining a payer’s ability to share data with another payer without requiring the use of an API, and instead only requiring the additional E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 types of data be made available to share. But, ultimately, there are numerous benefits to requiring the FHIR-based API conformant with the specified IGs for this data sharing. We have heard from several stakeholders that sharing these data in a standardized way is the only way to introduce valuable efficiencies and achieve true interoperability. Furthermore, for the Payer-to-Payer API, once an organization implements the other proposed APIs, there would be less additional investment necessary to implement the Payer-to-Payer API as payers would be able to leverage the infrastructure already established for the Patient Access API and Provider Access API. Given this available infrastructure, and the efficiencies of sharing standardized data via the API, we determined it was most advantageous for payers to again leverage an API for this enhanced data exchange. We also considered which data elements would be the most appropriate. Similar to the Provider Access API alternatives, we considered only requiring the exchange of clinical data as defined in the USCDI via an API. As we described above, we believe that claims and encounter information can complement the USCDI data and potentially allow for better care coordination, as well as more efficient payer operations. And, we do not believe there would be significant additional burden once the data are mapped to FHIR for the other proposed APIs. We also considered requiring payers to exchange all prior authorization decisions, including expired decisions, via the Payer-to-Payer API. However, we recognize that much of this information may be outdated and may not have an effect on the new payer’s prior authorization process. Therefore, in an effort to reduce the volume of outdated or irrelevant information shared among payers, we have decided to limit the proposal to only active and pending prior authorization decisions. G. Analysis of Potential Impact for Savings by Voluntary Participation of Individual Providers in the Proposed Prior Authorization Provisions To support our commitment to promoting interoperability and reducing burden on payers, providers, and patients, as discussed in section II.C. of this proposed rule, we are proposing new requirements related to prior authorization for states operating Medicaid FFS programs at 42 CFR 431.80 and 440.230; states operating CHIP FFS programs at 42 CFR 457.495 and 457.732; Medicaid managed care plans at 42 CFR 438.210 and 438.242; VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 CHIP managed care entities at 42 CFR 457.495, 457.1230, and 457.1233; and QHP issuers on the FFEs at 45 CFR 156.223. While we discussed the ICRs regarding cost estimates of those proposals with anticipated impact in sections V.C.5. through V.C.8., here, we discuss the anticipated cost savings of these proposals to the health care industry. We have detailed in this section the cost impact of creating the proposal discussed in section II.C. of this rule, including the DRLS and PAS APIs, as well as a number of other policies focused on reducing burden associated with the prior authorization process. Potentially offsetting some of these costs are the savings that would result from reduced administrative work associated with existing prior authorization protocols. These savings would be true savings, not transfers, since they reflect savings in reducing the administrative costs required to process prior authorizations. However, these savings would be an indirect consequence of the proposed rule, not direct savings. To be clear, this proposed rule does not reduce the current paperwork required for prior authorization. Rather, a consequence of the efficiencies resulting from the prior authorization proposals would be significantly reduced time spent on the paperwork. In general, it is only appropriate to claim that a regulatory provision’s benefits are in excess of its costs after a substantive, and preferably quantitative, assessment of the preexisting market failure and the provision’s suitability for addressing it. As a result of data limitations and other analytic challenges preventing such an assessment in this, the case illustrative savings estimates are neither included in the monetized table, nor the summary table of the Regulatory Impact Analysis in section VII. of this proposed rule, nor in the 2016-dollar calculation. Nevertheless, the savings could be significant and we believe should be a factor in the evaluation of this proposed rule. In calculating these potential savings, uncertainties arise in five areas, described below. The result of this illustrative analysis is that we find a potential savings impact of a billion dollars over 10 years. In this section, we carefully explain each uncertainty, indicate how we approached estimation, and solicit public comment. The five areas of uncertainty we had to take into account include: (1) Assumptions on the number of providers voluntarily engaging with the provisions of this proposed rule: A major obstacle in estimating impact is PO 00000 Frm 00077 Fmt 4701 Sfmt 4702 82661 the fact that these provisions, if finalized, would be mandatory for impacted payers but engagement by providers is voluntary. Before proposing this rule, we conducted conversations with stakeholders who indicated that more efficient prior authorization processes would ultimately reduce burden for all affected parties and would therefore likely be utilized by providers. To address the voluntary nature of provider utilization of the electronic prior authorization tools, we assume no provider participation in the first year, gradually increasing to 25 percent participation in 10 years. We believe this is a usefully illustrative assumption.83 We also believe that it is reasonable to assume that additional providers would participate as prior authorization capabilities become more widely available in EHRs, which are not regulated by this rule, and the benefits of having more efficient prior authorization processes become clear through burden reduction and improved patient care. In going from no providers leveraging the technology in the first year of implementation to 25 percent of providers using the technology in 10 years, we did not believe it appropriate to use a strict linear approach of a 2.5 percent increase of providers per year. We are aware that many providers do not yet have the necessary technical capabilities to facilitate interoperable exchange of data for prior authorization. Specifically, their EHR systems are not yet prepared to leverage the DRLS or PAS APIs. Absent that technology in the EHR, the DRLS and PAS APIs would provide minimal benefit to providers. We assume that providers in hospitals and providers in large health systems who already have such software would use it as soon as technologically feasible. Therefore, we modeled the growth of providers participating with a gradually increasing exponential model, since the exponential model is typically used to indicate slow growth in the beginning but faster growth later on. Our numerical assumptions of the percent of providers using DRLS and PAS APIs are presented in Table 12. 83 This assumption may be supported by some states already adopting legislation around electronic prior authorization, and federal legislation such as provision 6062 in the SUPPORT Act (H.R. 6) where electronic prior authorization is stipulated for drugs covered under Medicare Part D by January 1, 2021. However, reasons for electronic prior authorization tools to be used are not necessarily reasons why their use is attributable to this proposed rule; they might instead be reasons why use would occur even in the rule’s absence. We request comment that would help with identifying impacts attributable to this proposal. E:\FR\FM\18DEP2.SGM 18DEP2 (Note, exponential models cannot start at 0; therefore, we started at 0.01 percent.) We solicit public comments on all assumptions: The assumption of no providers in the first year; the assumption of 25 percent participation in the tenth year; and the use of an exponential model. (2) Assumptions on the current workload hours for prior authorization: To estimate the savings impact, we first require estimates of the current amount of paperwork involved in prior authorization, the type and number of staff involved, the type of physician offices involved, and hours per week spent engaged in prior authorization processes. Our assumptions are based on a well-conducted survey presented in Casalino et al. (2009) 84, which gives a detailed analysis based on a validated survey instrument employed in 2006. This survey excluded certain physician practices, including health maintenance organizations (HMOs), but analyzed workload by staff type (doctor, nurse, clerical, administrator, lawyer, and accountant), office type (solo, three to 10 physicians, 10 or more physicians), and type of medical work involved (prior authorization, formulary, claims billing, quality, etc.). Consistent with our approach, we restricted ourselves to prior authorization activities, though formulary work could possibly add to burden related to prior authorization activities. Using the methods and data from Casalino et al. (2009), Table 13 presents an estimate of the current average annual paperwork burden per physician office for prior authorization activities. Table 13 estimates an annual burden per physician office of 1,060.8 hours at a cost of $73,750. Table 13 estimates are based on Casalino et al. (2009). Several other examples in the literature were reviewed 85 86 87 88 89 which, although reflecting more recent research, either did not show the basis for their calculations, showed a basis based on a very small number of people, or used a non-validated survey. For this reason, we used the Casalino et al. (2009) article for our calculations. The wages in Table 13 have been updated from those used in the Casalino et al. (2009) work to the latest BLS wages. The hours should also be adjusted for 2021, to account for increased prior authorization requirements. However, we do not have a more recent reliable survey on which to base this. Table 16 in this section presents an alternate estimate assuming a 4 percent growth rate in hours per week spent on prior authorization, the 4 percent coming from the articles cited above. We solicit public comment on these assumptions on the hours per week spent on prior authorization paperwork. (3) Assumptions on the total number of physician practices: Table 13 presents current hour and dollar burden per physician office. To obtain aggregate annual burden of prior authorization over all physician practices including those exclusively furnishing services to Fee For Service (FFS) enrollees, Casalino et al. (2009) multiplies the Table 13 burdens for physician office by the total number of physician practices. Thus, we need an estimate of total number of physician practices. Additionally, in this section, we need to 84 Casalino, L.P., Nicholson, S., Gans, D., Hammons, T., Morra, D., Karrison, T., & Levinson, W. (May 2009). What Does It Cost Physician Practices To Interact With Health Insurance Plans? Health Affairs, 28(4): w533–w543. doi: 10.1377/ hlthaff.28.4.w533. 85 Morley, C.P., Badolato, D.J., Hickner, J., Epling, J.W. (2013, January). The Impact of Prior Authorization Requirements on Primary Care Physicians’ Offices: Report of Two Parallel Network Studies. The Journal of the American Board of Family Medicine, 26(1), 93–95. doi: 10.3122/ jabfm.2013.01.120062. 86 Ward, V. (2018, April). The Shocking Truth About Prior Authorization in Healthcare. Retrieved from https://getreferralmd.com/2018/04/priorauthorization-problems-healthcare/. 87 Center for Health Innovation & Implementation Science. (2018, July 26) The Prior Authorization Burden in Healthcare. Retrieved from https:// www.hii.iu.edu/the-prior-authorization-burden-inhealthcare/. 88 Robeznieks, A. (2018, November 16). Inside Cleveland Clinic’s $10 million prior authorization price tag. Retrieved from https://www.amaassn.org/practice-management/sustainability/ inside-cleveland-clinic-s-10-million-priorauthorization-price. 89 American Medical Association. (2019, June). Prior Authorization and Utilization Management Reform Principles. Retrieved from https:// www.ama-assn.org/system/files/2019-06/principleswith-signatory-page-for-slsc.pdf. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 PO 00000 Frm 00078 Fmt 4701 Sfmt 4702 E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.012</GPH> Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules EP18DE20.011</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 82662 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules modify the total number of physician practices by a factor accounting for the fact that only a percentage of physician practices accept enrollees in the Medicaid, CHIP, and QHP programs. We first discuss the total number of physician practices. Casalino et al. (2009) cited that the AMA listed a figure of 560,000 physician offices in 2006. Casalino et al. (2009) criticized this 560,000 (rounded from 560,118 physician offices exactly) based on available sources in 2006 and reduced it to 450,000 physician offices (rounded from 453,696 physician offices exactly). The sources cited in the article have not been updated. Furthermore, the CY 2012 PFS final rule redefined physician group practice to require at least 25 physicians. As of 2016, there are 230,187 physician practices (76 FR 73026). We note that this number is lower than the value used in the 2016 survey, which makes sense given the high rates of consolidation in the medical field. In Table 16 later in this section, we present an alternative analysis of savings with 450,000 practices. We solicit public comment on our assumptions of the number of physician offices. (4) Percent of providers accepting Medicaid, CHIP, or QHP: The 230,187 physician practices just mentioned include providers who exclusively service Fee For Service enrollees. We must therefore adjust this number by the percent of providers furnishing services to Medicaid, CHIP, and QHP enrollees. According to the Medicaid and CHIP Payment and Access Commission (MACPAC),90 71 percent of providers accept Medicaid, but only 36 percent of psychiatrists accept new Medicaid patients, and 62 percent accept private insurance. Therefore we estimate that 50 percent of provider groups treat patients in the Medicaid and QHP. Although we don’t account for it, we note that these provisions, which reduce the amount of paperwork, might encourage a greater participation in the coming years of providers accepting Medicaid, CHIP, and QHPs in the FFEs. (5) Assumptions on the reduction in hours spent on prior authorization as a result of the provisions of this proposed rule: Table 13 provides current hours spent on prior authorization; to calculate potential savings we must make an assumption on how much these hours are being reduced as a result of the provisions of this rule. Therefore, 90 Kayla Holgash and Martha Heberlin, ‘‘Physician Acceptance of New Medicaid Patients,’’ January 24, 2019 https://www.macpac.gov/wpcontent/uploads/2019/01/Physician-Acceptance-ofNew-Medicaid-Patients.pdf VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 we review the specific provisions of this proposed rule. We believe two provisions in this proposed rule would reduce prior authorization burden: • Section II.C. of this proposed rule would require payers to implement a DRLS API. This service, if voluntarily used by providers, would allow them, at the point of care, to discover whether a requested item or service requires prior authorization and, if so, the relevant documentation requirements. All provider office staff types, including doctors, nurses, and clerical staff, would experience reductions in the time needed to locate prior authorization rules and documentation requirements, which are currently either not readily accessible or available in many different payer-specific locations and formats. We believe that our proposal would make it possible for provider staff to use one system (such as their EHR or practice management system) or software application to find the prior authorization rules and documentation requirements for all impacted payers. With these rules and requirements more consistently and easily accessible, we anticipate a reduction in the need for providers to make multiple attempts at submitting the full set of information necessary for the payer to approve or deny a prior authorization. As a consequence, a DRLS API could also reduce appeals and improper payments,91 but we are not addressing such savings here, as we have no realworld basis on which to make an estimate. (We also note that reduction in improper payments, though experienced as savings by certain entities, would be categorized as transfers from a societywide perspective.) Overall, once the APIs are in place and providers integrate with them, we assume providers and nurses could experience a 25 percent reduction in hours spent working to identify prior authorization rules and requirements. (Again, we are uncertain when providers may connect to the APIs.) The level annual 25 percent reduction reflects the belief that these provisions would accomplish savings through reduced administrative burden and therefore in the absence of additional data, the 25 percent reflects a midpoint between 0 percent and 50 percent indicating some savings (more than 0 percent but not more than 50 percent). 91 Centers for Medicare and Medicaid Services. (2019, November 15). Simplifying Documentation Requirements. Retrieved from https:// www.cms.gov/Research-Statistics-Data-andSystems/Monitoring-Programs/Medicare-FFSCompliance-Programs/ SimplifyingRequirements.html. PO 00000 Frm 00079 Fmt 4701 Sfmt 4702 82663 We solicit public comment on the estimated reduction in hours spent determining prior authorization rules and requirements due to the DRLS API proposal in this proposed rule. We are interested in understanding if there is burden reduction prior to the development of an EHR integration with the API. We also note that Table 16 in this section provides an alternative analysis using a 75 percent reduction for doctors and nurses. The intent in Table 16 is to provide a broad range inclusive of many possibilities (hence 25 percent to 75 percent for providers and nurses). • Section II.C. of this proposed rule would require that payers implement and maintain a PAS API that would, if voluntarily used by providers, allow them, through an existing EHR or practice management system that is capable of connecting to the API, to submit prior authorization requests along with any associated documentation needed, and receive an approval or denial decision from the payer, including any ongoing communications regarding additional information needed or other status updates. Currently, most prior authorization requests and decisions are conducted through one of several burdensome channels, including telephone, fax, or payer-specific web portals—each of which require taking actions and monitoring status across multiple and varying communication channels. Since submission support is predominantly done by clerical staff, not by doctors or nurses, we would estimate no savings to doctors and nurses, but a 50 percent reduction in hours spent by clerical staff. The 50 percent reduction represents a reasonable estimate of time spent in the absence of any experience or data. We solicit comments on this estimated 50 percent reduction in hours spent by clerical staff and whether our assumptions of the affected staff type are accurate. Having presented our assumptions on the number of providers voluntarily using the DRLS and PAS APIs for electronic prior authorization, the current hour and dollar burden per week spent on prior authorization, the number of physician practices, and the reduction in hours arising from the proposed provisions of this rule, Tables 14 and 15 present total hours and dollars saved. Table 14 presents the savings per physician practice. Table 15 multiplies these per physician practice savings by 50 percent of the 230,187 provider practices to obtain aggregate savings The following illustrative calculations help explain the entries in Table 14 and 15: E:\FR\FM\18DEP2.SGM 18DEP2 • In Table 14, the row on nurses cites Table 13, which shows that currently, annually, per physician practice, nurses spend 681.2 hours per year on prior authorization. Multiplying this number of hours by our assumed savings for nurses of 25 percent, we obtain 170.3 hours per year saved. Multiplying these reduced hours by the hourly wage for nurses of $74.48, we obtain a savings of $12,684 per physician practice for nurses. This calculation is repeated for all staff and then summed to obtain the total hours and dollars saved per physician practice. We save 347.1 hours per physician practice per year and $21,648 per physician practice per year. • Table 15 now multiplies the 347.1 hours and $21,648 saved per physician practice by 50 percent (percent of providers furnishing enrollees in Medicaid, CHIP, and QHP), times 230,187 (total number of physician practices) times the percent of providers using these technologies by year as outlined in Table 12. For example, for the 1st year, 2023, we multiply, $21,648 * 50 percent * 230,187 * 0.01% to obtain a reduced dollar spending of $0.2 million. The other rows in Table 15 are similarly calculated. As can be seen, the total savings over 10 years is 17.2 million hours and $1.1 billion. The savings for the first three years, obtained by summing the first three rows, is 36,254 hours and $2.26 million. The method of calculating the hours and dollars in these rows was just illustrated. Because we assume a 10year gradual increase in voluntary provider participation, we present a 10year horizon in Table 15 in this section. The analysis in Table 15 represents our illustrative analysis for this proposed rule, which we put forward for stakeholder review and comment. In Table 16, we present some alternative analysis of the savings. Despite the wide range of alternatives, the resulting range of savings is estimated at about $1.1 billion to about $5.2 billion. As indicated earlier, we solicit comments from stakeholders on our assumptions and methodology. We provide four VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 PO 00000 Frm 00080 Fmt 4701 Sfmt 4702 E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.014</GPH> Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules EP18DE20.013</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 82664 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules khammond on DSKJM1Z7X2PROD with PROPOSALS2 alternative assumptions as follows to the assumptions made in Tables 12 through 15: • We assumed in this section that the number of hours per week that providers spend on prior authorization has not changed since 2006. In Table 16, we allow for an alternative with 4 percent annual growth. This number came from several papers cited in section V. of this proposed rule. • We assumed in this section that the reduction of hours per week that provider teams spend on prior authorization is a result of a 25 percent reduction for doctors and nurses and a 50 percent reduction for clerical staff. In the Table 16, we provide an alternative analysis assuming a 75 percent VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 reduction for doctors and nurses and a 50 percent reduction for clerical staff. These alternative numbers are not based on published articles or experience but rather meant to span a range of alternatives. • In this section, we assumed 230,187 physician practices. In Table 16, we also use an alternate assumption of 450,000 physician practices, also discussed in this section.. We modified these numbers by a factor of 50 percent to account for the fact that only half of provider groups accept Medicaid, CHIP, and QHP. • For purposes of comparison we present the 10-year savings assuming all providers participate as well as the 10year savings from reduced paperwork PO 00000 Frm 00081 Fmt 4701 Sfmt 4702 82665 assuming a gradual increase in participation from 0 percent in the base year to 25 percent in the tenth year. In making these assumptions, the goal was to obtain a range of possible alternatives. We have no experience basis to justify any particular assumption and data vary widely in the literature. As can be seen from Table 16, the potential savings range from about $1 billion to about $5 billion. We believe the magnitude of such a number is important for stakeholders when evaluating and commenting on the provisions of this rule. We solicit public comment on the four assumptions and their impact in estimating these savings. BILLING CODE 4120–01–P E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules BILLING CODE 4120–01–P khammond on DSKJM1Z7X2PROD with PROPOSALS2 H. Summary of Costs In this section, we present a 10-year summary table of costs, an analysis for federal impacts, and the monetized table. To analyze the cost of this rule to the federal government, we utilize a method of allocating costs by program (Medicaid, CHIP, and QHP issuers on the FFEs). As the cost is shared by the 266 parent organizations, including Medicaid and CHIP state agencies, there VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 is no readily available way to allocate costs per parent organization across programs since the percentage of each parent organization’s expenditures on the different programs is not publicly available. To address this, we utilize the same method that was used in the CMS Interoperability and Patient Access final rule (85 FR 25612). In that final rule, we used the public CMS Medical Loss Ratio (MLR) files, which break out total premiums across the various programs. The advantages and disadvantages of PO 00000 Frm 00082 Fmt 4701 Sfmt 4702 such an approach are fully discussed in that rule, to which we refer readers. At the time this proposed rule is being written, 2019 is the latest available year with published data. Table 17 presents the 2019 MLR data of premiums by program and the resulting percentages by program. We use these percentages to allocate costs by programs. This allocation of cost by program forms a basis to calculate the federal government’s cost for the proposed provisions of this rule. E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.015</GPH> 82666 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules 82667 We can calculate the federal Medicaid payments using the percentages in Table 18. percent). By applying these percentages to the total Medicaid costs, we obtain federal costs for the program. These percentages are used to calculate the total dollars going from the federal government to states. We can now calculate all impacts of this proposed rule by program, government, and QHP issuers. The numerical impacts are presented in Table 19. EP18DE20.017</GPH> enhancement of such systems, and 75 percent of their expenditures on the ongoing operation of such systems. States receive an average of 58.44 percent (FMAP) for their managed care program costs. Therefore, the percent of costs paid in the first year by the federal government is 74.85 percent (90 percent * 52 percent + 58.44 percent * 48 percent). The percent of costs paid in later years is 67.05 percent (75 percent * 52 percent + 58.44 percent * 48 VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 PO 00000 Frm 00083 Fmt 4701 Sfmt 4702 E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.016</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 In Table 18, the first row shows that 52 percent of federal government payments go to the states for expenditures related to their FFS programs and 48 percent go to states for their Medicaid managed care programs. For state expenditures on Medicaid mechanized claims processing and information retrieval systems, the federal government pays states 90 percent of their expenditures on the design, development, installation, or Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules For Table 19: • Cost of Proposed Rule by Year column: The total cost for years 2021 to 2023 matches the costs in the Collection of Information (section V.) summary table (Table 10). The total 10-year cost (including payers but excluding PTC payments and savings from prior authorization) is, as shown in Table 19, $1.9 billion. This number uses the primary estimates for the API provisions. The low and high 10-year total costs are $1.0 billion and $2.8 billion, respectively. • Cost of Proposed Rule to Payers by Program columns: We apply the percentages from Table 17 to obtain the cost of the rule to Payers by program (Medicaid, CHIP, and QHP issuers on the FFEs). • Cost of Proposed Rule to Government by Program columns: We apply the percentages of payment by the federal government discussed in Table 18 to obtain the cost by program. • PTC Payments: The government does not reimburse QHPs, neither partially nor totally, neither prospectively nor retroactively, for their expenses in furnishing benefits. However, the government does offer eligible QHP enrollees PTCs to help cover the cost of the plan. QHP issuers on selling on the Exchanges have the option to deal with increased costs of complying with the requirements as proposed in this rule by either VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 temporarily absorbing them (for purposes of market competitiveness), increasing premiums to enrollees, or reducing non-essential health benefits. To the extent that issuers increase premiums for individual market plans on the FFEs, there would be federal PTC impacts. The purpose of the PTC is to assist enrollees in paying premiums. Since PTCs are only available if an individual purchases an individual market plan on an Exchange and the individual has an income between 100 and 400 percent of the Federal Poverty Level, the PTC estimates apply only to Exchange plans. In the PTC estimate, we have accounted for the fact that some issuers have both Exchange and nonExchange plans, and some issuers have only non-Exchange plans. We reflected these assumptions with global adjustments, so we believe the estimates are reasonable in aggregate. The methodology to estimate the PTC impact of the of the projected expense burdens is consistent with the method used to estimate the PTC impact in the CMS Interoperability and Patient Access final rule (85 FR 25612). Within the FFE states, the estimated expense burden would impact premium rates in the individual market and is spread across both Exchange and non-Exchange plans. PTCs are only paid in the Exchanges and are calculated as a function of the second lowest cost silver plan and the PO 00000 Frm 00084 Fmt 4701 Sfmt 4702 eligible individuals’ income. The estimate of these impacts uses the assumption that the industry would increase the second lowest cost silver plan premium rate in the same amount as the overall premium rate increase as a result of the expense estimate. This assumption allows application of the overall rate increase to the projected PTC payments in the FFE states to estimate the impact to PTC payments. There are no increases in PTC payments included for 2021 since by the time this proposed rule is projected to be published these rates will already have been determined. The total cost to the government is the sum of payments related to each program. This payment is a transfer from the government to payers for Medicaid, CHIP, and to QHP enrollees. • Remaining Cost to Payers columns: For Medicaid and CHIP, the remaining costs are the difference between total cost to payers and what the federal government pays. For the individual markets, the remaining costs to payers would be the total cost absorbed by the payers and not passed on through premium increases. Since the PTC is paid on behalf of individuals and not the payers, it therefore does not reduce expenses of the payers. • Note: The $1.1 billion savings from reduced paperwork burden for use of E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.018</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 82668 82669 electronic prior authorization (Table 16) is not included in Table 19. We next explain how the various plans (and states) would bear the costs remaining after federal payments. We follow the same methodology and discussion presented in the CMS Interoperability and Patient Access final rule (85 FR 25612). In Table 20, we explain possible ways payers may manage these extra costs. We emphasize that Table 20 lists possibilities. Payers will ultimately make decisions about how to defray these remaining costs based on market dynamics and internal business decisions, and we have no uniform way of predicting what these actual behaviors and responses will be. Individual Market Plans: Individual market plans have the option of absorbing costs or passing costs to enrollees either in the form of higher premiums or reduced benefits that are not essential health benefits (EHBs). The experience of the Office of the Actuary is that frequently, plans, for reasons of market competitiveness, will absorb costs rather than increase premiums or reduce benefits. Medicaid and CHIP: Assuming roughly 75 million enrollees nationally, including Medicaid and CHIP FFS programs, Medicaid managed care plans and CHIP managed care entities are adding a cost of under a dollar per beneficiary per year; this contrasts with a total cost per beneficiary per year for the Medicaid and CHIP programs of several thousand dollars. a-4.pdf), we have prepared an accounting statement in Table 21 showing the classification of annualized costs associated with the provisions of this proposed rule for the 10-year period 2021 through 2030. This accounting table is based on Table 19. It includes costs of this proposed rule to providers, Medicaid and CHIP state entities, and issuers offering QHPs on the FFEs. It does not include the potential savings (Tables 14 and 15) of at least $1.1 billion arising from reduced burden due to providers voluntarily complying with electronic prior authorization as discussed in the illustrative earlier in this section. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 I. Accounting Statement and Table As required by OMB Circular A–4 (available at https:// www.whitehouse.gov/sites/ whitehouse.gov/files/omb/circulars/A4/ PO 00000 Frm 00085 Fmt 4701 Sfmt 4702 E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.019</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules J. Regulatory Reform Analysis Under E.O. 13771 and recordkeeping requirements, State fair hearings. Executive Order 13771, titled Reducing Regulation and Controlling Regulatory Costs, was issued on January 30, 2017 and requires that the costs associated with significant new regulations ‘‘shall, to the extent permitted by law, be offset by the elimination of existing costs associated with at least two prior regulations.’’ This proposed rule, if finalized, is considered an E.O. 13771 regulatory action. We estimate that the medium (primary) estimates of this proposed rule would generate annual costs of $136.3 million in 2016 dollars when calculated at a 7 percent discount over a perpetual time horizon. (The low estimates would generate $70.6 million in annualized costs, while the high estimates would generate $202.1 million in annualized costs, discounted at 7 percent relative to 2016, over a perpetual time horizon.) Details on the estimated costs of this proposed rule can be found in the preceding analyses. In accordance with the provisions of Executive Order 12866, this regulation was reviewed by the Office of Management and Budget (OMB). 42 CFR Part 435 Aid to Families with Dependent Children, Grant programs-health, Medicaid, Notices, Reporting and recordkeeping requirements, Supplemental Security Income (SSI), Wages. List of Subjects 42 CFR Part 431 Grant programs-health, Health facilities, Medicaid, Privacy, Reporting VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 42 CFR Part 438 Grant programs-health, Medicaid, Reporting and recordkeeping requirements. 42 CFR Part 440 Grant programs-health, Medicaid. 42 CFR Part 457 Administrative practice and procedure, Grant programs-health, Health insurance, Reporting and recordkeeping requirements. 45 CFR Part 156 Administrative practice and procedure, Advertising, Brokers, Conflict of interests, Consumer protection, Grant programs-health, Grants administration, Health care, Health insurance, Health maintenance organizations (HMO), Health records, Hospitals, Indians, Individuals with disabilities, Intergovernmental relations, Loan programs-health, Medicaid, Organization and functions (Government agencies), Prescription PO 00000 Frm 00086 Fmt 4701 Sfmt 4702 drugs, Public assistance programs, Reporting and recordkeeping requirements, Technical assistance, Women, Youth. 45 CFR Part 170 Computer technology, Health, Health care, Health insurance, Health records, Hospitals, Indians, Incorporation by reference, Laboratories, Medicaid, Medicare, Privacy, Public health, Reporting and recordkeeping requirements, Security measures. For the reasons set forth in the preamble, the Centers for Medicare & Medicaid Services (CMS) proposes to amend 42 CFR chapter IV as set forth below: PART 431—STATE ORGANIZATION AND GENERAL ADMINISTRATION 1. The authority citation for part 431 continues to read as follows: ■ Authority: 42 U.S.C. 1302. 2. Section 431.60 is amended by— a. Revising paragraph (b)(3); b. Adding paragraph (b)(5); c. Revising paragraph (c)(3) introductory text; ■ d. Adding paragraph (c)(3)(iii); ■ e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and (e)(2); ■ f. Redesignating paragraph (g) as paragraph (i); and ■ g. Adding new paragraphs (g) and (h). ■ ■ ■ ■ E:\FR\FM\18DEP2.SGM 18DEP2 EP18DE20.020</GPH> khammond on DSKJM1Z7X2PROD with PROPOSALS2 82670 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules The revisions and addition read as follows: § 431.60 Beneficiary access to and exchange of data khammond on DSKJM1Z7X2PROD with PROPOSALS2 * * * * * (b) * * * (3) Clinical data, as defined in the USCDI version 1, if the State maintains any such data, no later than 1 business day after the data are received by the State; * * * * * (5) Beginning January 1, 2023, pending and active prior authorization decisions and related clinical documentation and forms for items and services, not including covered outpatient drugs, including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date, no later than 1 business day after a provider initiates a prior authorization request for the beneficiary or there is a change of status for the prior authorization. (c) * * * (3) Must comply with the content and vocabulary standards requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law, and be conformant with the requirements in paragraph (c)(3)(iii) of this section: * * * * * (iii) Beginning January 1, 2023, be conformant with the implementation specifications at 45 CFR 170.215(c)(5) for data specified in paragraphs (b)(1) and (2), 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified in paragraph (b)(3) of this section, 45 CFR 170.215(c)(7) for data specified in paragraph (b)(4) of this section, and 45 CFR 170.215(c)(6) for data specified in paragraph (b)(5) of this section. (4) May use an updated version of any standard or all standards and any or all implementation guides or specifications required under paragraphs (b) or (c) of this section, and §§ 431.61, 431.70, 431.80, where: * * * * * (ii) * * * (C) Use of the updated version of the standard, implementation guide, or specification does not disrupt an end user’s ability to access the data described in paragraph (b) of this section or the data described in §§ 431.61, 431.70, and 431.80 through the required API. * * * * * (e) * * * (2) Makes this determination using objective, verifiable criteria that are VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 applied fairly and consistently across all applications and developers through which parties seek to access electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. * * * * * (g) Privacy policy attestation. (1) Beginning January 1, 2023, the State must establish, implement, and maintain a process for requesting an attestation from a third-party app developer requesting to retrieve data via the Patient Access API that indicates the app adheres to certain privacy provisions. The State must: (i) Independently, or through the support of a third party, request a thirdparty app developer to attest whether: (A) The app has a privacy policy that is publicly available and accessible at all times, including updated versions, and that is written in plain language, and that the third-party app has affirmatively shared with the beneficiary prior to the beneficiary authorizing the app to access their health information. To ‘‘affirmatively share’’ means that the beneficiary had to take an action to indicate they saw the privacy policy, such as click or check a box or boxes. (B) The app’s privacy policy includes, at a minimum: (1) How a beneficiary’s health information may be accessed, exchanged, or used by any person or other entity, including whether the beneficiary’s health information may be shared or sold at any time (including in the future); (2) A requirement for express consent from a beneficiary before the beneficiary’s health information is accessed, exchanged, or used, including receiving express consent before a beneficiary’s health information is shared or sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction); (3) If an app will access any other information from a beneficiary’s device; and (4) How a beneficiary can discontinue app access to their data and what the app’s policy and process is for disposing of a beneficiary’s data once the beneficiary has withdrawn consent. (ii) Include information in the beneficiary resources required in paragraph (f) of this section about the specific content of the State’s privacy policy attestation required under this paragraph, and, at a minimum, the timeline for the attestation process, the method for informing the beneficiary PO 00000 Frm 00087 Fmt 4701 Sfmt 4702 82671 about the app developer’s response or non-response to the State’s request, and the beneficiary’s role and rights in this process; and (iii) Request the attestation at the time the third-party app engages the API and notify the beneficiary as follows: (A) The State must inform the beneficiary within 24 hours of requesting the attestation from the thirdparty app developer regarding the status of the attestation—positive, negative, or no response, with a clear explanation of what each means; (B) If a beneficiary does not respond within 24 hours of when the State sends notice of the attestation status to the beneficiary, the State must proceed with making the beneficiary’s data available to the third-party app consistent with the beneficiary’s original request. (2) The State must not discriminate when implementing this requirement, including for the purposes of competitive advantage; the method employed to meet this requirement must be applied equitably across all apps requesting access the Patient Access API. (h) Reporting on the use of the Patient Access API. (1) Beginning March 31, 2023, a State must report to CMS, at the State agency level, by the end of each calendar quarter, based on the previous quarter’s data as follows: (i) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a beneficiary-designated third-party application; and (ii) The number of unique beneficiaries whose data are transferred via the Patient Access API to a beneficiary designated third-party application more than once. (2) [Reserved]. * * * * * ■ 3. Section 431.61 is added to read as follows: § 431.61 Access to and exchange of health data to providers and payers. (a) Application Programming Interface to support data transfer from payers to providers—Provider Access API.—(1) Accessible content and API requirements. Beginning January 1, 2023, a state must implement and maintain a standards-based Application Programming Interface (API) compliant with § 431.60(c), (d), and (e): (i) Individual beneficiary data. The Provider Access API must make available to providers, if requested by the provider, as permitted by the beneficiary per paragraph (a)(3) of this section, and as permitted by applicable law, at a minimum, data maintained by the State with a date of service on or E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82672 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules after January 1, 2016, within one (1) business day of receipt, conformant with the implementation specifications at 45 CFR 170.215(c)(5) for data specified at § 431.60(b)(1) and (2) not including remittances and enrollee cost sharing information, 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified at § 431.60(b)(3), 45 CFR 170.215(c)(7) for data specified at § 431.60(b)(4), and 45 CFR 170.215(c)(6) for data specified at § 431.60(b)(5); and (ii) Bulk data access. The Provider Access API must be able to share the data specified in paragraph (a)(1)(i) of this section conformant with the implementation specification at 45 CFR 170.215(a)(4) to facilitate sharing the specified data relevant to one or more beneficiary at one time. (2) Attribution. A State must establish, implement, and maintain a process to facilitate generating each provider’s current beneficiary roster to enable this payer-to-provider data sharing via the Provider Access API. (3) Opt-in. A State may put a process in place to allow a beneficiary or the beneficiary’s personal representative to opt-in to permit the State’s use of the Provider Access API for sharing with each of the beneficiary’s provider(s) currently providing care, or planning to provide care, the data specified in paragraph (a)(1) of this section. (4) Provider resources regarding APIs. A State must provide on its website and through other appropriate mechanisms through which it ordinarily communicates with providers, educational resources in non-technical, simple, and easy-to-understand language explaining general information concerning how a provider may make a request to the State for beneficiary data using the standards-based Provider Access API required under paragraph (a)(1) of this section, both for individual access and bulk data requests. (5) Out-of-network provider access. A State cannot deny use of, or access to, the Provider Access API based on a provider’s contract status. (b) Coordination among payers— Payer-to-Payer Data Exchange. (1) Beginning January 1, 2023, a State must implement and maintain a standardsbased API compliant with § 431.60(c), (d), and (e) that makes available to another payer, at a minimum, the data maintained by the state with a date of service on or after January 1, 2016, within one (1) business day of receipt, conformant with the implementation specifications at 45 CFR 170.215(c)(5) for data specified at § 431.60(b)(1) and (2) not including remittances and enrollee cost sharing information, 45 CFR 170.215(a)(2) or 45 CFR VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 170.215(c)(6) for data specified at § 431.60(b)(3), 45 CFR 170.215(c)(7) for data specified at § 431.60(b)(4), and 45 CFR 170.215(c)(6) for data specified at § 431.60(b)(5). Such information received by a State must be incorporated into the State’s records about the current beneficiary. (2) With the approval and at the direction of a current or former beneficiary or the beneficiary’s personal representative, the State must: (i) Receive all such data for a current beneficiary from any other payer that has provided coverage to the beneficiary within the preceding 5 years; (ii) At any time a beneficiary is currently enrolled with the State and up to 5 years after disenrollment, send all such data to any other payer that currently covers the beneficiary or to a payer the beneficiary or the beneficiary’s personal representative specifically requests receive the data; and (iii) Send data received from another payer under this paragraph in the electronic form and format it was received. (c) Coordination among payers at enrollment—Payer-to-Payer API. (1) Accessible content and API requirements. Beginning January 1, 2023, a State must make the standardsbased API specified in paragraph (b)(1) of this section conformant with the implementation specification at 45 CFR 170.215(a)(4) to facilitate sharing the data specified in paragraph (b)(1) of this section relevant to one or more beneficiaries at one time. (2) Requesting data exchange. (i) When a beneficiary enrolls in coverage with the State, the State may request the data from a previous payer through the standards-based API described in paragraph (c)(1) of this section, as permitted by the beneficiary per paragraph (c)(5) of this section, and as permitted by applicable law; (ii) For any beneficiaries who enroll with the State during the first calendar quarter of each year, the State must request the specified data within one (1) week of the end of the first calendar quarter from any previous payers through the standards-based API described in paragraph (c)(1) of this section, as permitted by the beneficiary per paragraph (c)(5) of this section, and as permitted by applicable law; (iii) If a State receives a request from another payer to make data available for one or more former beneficiaries who have enrolled with the new payer, the State must respond by making the required data available via the standards-based API described in paragraph (c)(1) of this section within PO 00000 Frm 00088 Fmt 4701 Sfmt 4702 one (1) business day of receiving the request. (3) Previous or concurrent payer. A State must adopt a process to obtain from a new beneficiary the name of the new beneficiary’s previous payer as part of the enrollment process, and the name of the new beneficiary’s concurrent payer or payers if the beneficiary has coverage through more than one payer, to facilitate data sharing using the Payer-to-Payer API described in paragraph (c)(1) of this section. (4) Concurrent payer exchange. When a beneficiary has concurrent coverage with another payer also subject to CMS regulations on the Payer-to-Payer API, the State must make available to the other payer the data described in paragraph (b)(1) of this section through the standards-based API described in paragraph (c)(1) of this section quarterly. (5) Opt-in. A State must put a process in place to allow a beneficiary or the beneficiary’s personal representative to opt-in to permit the State’s use of the Payer-to-Payer API data sharing specified in paragraph (c)(1) of this section. (d) Obligations. The requirements under this section do not in any way alter or change a State’s obligation as a HIPAA covered entity to comply with regulations regarding standard transactions at 45 CFR part 162. (e) Extensions and Exemptions. (1) Extension. (i) A State may submit a written application to request to delay implementation of the requirements in paragraphs (a) through (c) of this section one-time for up to one (1) year with respect to its Medicaid fee-for-service program. The written application must be submitted and approved as part of the State’s annual Advance Planning Document for MMIS operations costs and must include: (A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and explaining why those reasons result from circumstances that are unique to States operating Medicaid fee-for service programs; (B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and (C) A comprehensive plan to meet implementation requirements no later than 1 year after the initial compliance date. (ii) CMS will grant the State’s request if it determines based on the information provided in the State’s annual Advance Planning Document for MMIS operations costs that the request E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules adequately establishes a need to delay implementation, that this need results from circumstances that are unique to States operating Medicaid fee-forservice programs, that the State has made a good faith effort to implement the proposed requirements as soon as possible, and that the State has a clear plan to implement the requirements no later than one (1) year after the proposed compliance date. (2) Exemption. (i) A State operating a Medicaid program under which at least 90 percent of all covered items and services are provided to Medicaid beneficiaries through Medicaid managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a fee-for-service delivery system, or under which at least 90 percent of the State’s Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined in § 438.2, may request that its fee-for-service program be exempted from the requirement(s) in paragraphs (a) through (c) of this section. (A) A state may submit an exemption request once per calendar year for a one (1) year exemption. (B) The annual request must be submitted as part of a state’s annual Advance Planning Document for MMIS operations costs. (C) The State’s request must include documentation that the State meets the criteria for the exemption, using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. (ii) CMS will grant the exemption for a one-year period if the State establishes to CMS’s satisfaction that the State meets the criteria for the exemption and has established a plan to ensure there will be efficient electronic access to the same information through alternative means. ■ 4. Section 431.70 is amended by adding paragraph (d) to read as follows: § 431.70 Access to published provider directory information. * * * * (d) Beginning January 1, 2023, the Provider Directory API must be conformant with the implementation specification at 45 CFR 170.215(c)(8). ■ 5. Section 431.80 is added to subpart B to read as follows: khammond on DSKJM1Z7X2PROD with PROPOSALS2 * § 431.80 Documentation and prior authorization. (a) Requirements to support provider documentation discovery and to support prior authorization. At a minimum: (1) Documentation Requirement Lookup Service (DRLS) Application Programming Interface (API). Beginning January 1, 2023, a State must implement VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 and maintain a standards-based API compliant with § 431.60(c), (d), and (e): (i) That is populated with the State’s list of covered items and services, not including covered outpatient drugs, for which prior authorization is required, and with the State’s documentation requirements for submitting a prior authorization request, including a description of the required documentation; and (ii) That is conformant with the implementation specifications at 45 CFR 170.215(c)(1) and (2). (2) Prior Authorization Support API. Beginning January 1, 2023, a State must implement and maintain a standardsbased API compliant with § 431.60(c), (d), and (e): (i) That facilitates a HIPAA-compliant prior authorization request and response, including any forms or medical record documentation required by the State for the items or services for which the provider is seeking prior authorization; (ii) That is conformant with the implementation specification at 45 CFR 170.215(c)(3); and (iii) That includes in the response whether the State approves (and for how long), denies, or requests more information related to the prior authorization request, along with a standard denial reason code in the case of denial; (iv) A State must include a specific reason for a denial in the case of a denial with all prior authorization decisions, regardless of the method used to send the prior authorization decision. (b) Extensions and Exemptions. (1) Extension. (i) A State may submit a written application to request to delay implementation of the requirements in paragraphs (a)(1) and (2) of this section one-time for up to one (1) year with respect to its Medicaid fee-for-service program. The written application must be submitted and approved as part of the State’s annual Advance Planning Document for MMIS operations costs and must include: (A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and explaining why those reasons result from circumstances that are unique to States operating Medicaid fee-for service programs; (B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and (C) A comprehensive plan to meet implementation requirements no later than 1 year after the initial compliance date. PO 00000 Frm 00089 Fmt 4701 Sfmt 4702 82673 (ii) CMS will grant the State’s request if it determines based on the information provided in the State’s annual Advance Planning Document for MMIS operations costs that the request adequately establishes a need to delay implementation, that this need results from circumstances that are unique to States operating Medicaid fee-forservice programs, that the State has made a good faith effort to implement the proposed requirements as soon as possible, and that the State has a clear plan to implement the requirements no later than one (1) year after the proposed compliance date. (2) Exemption. (i) A State operating a Medicaid program under which at least 90 percent of all covered items and services are provided to Medicaid beneficiaries through Medicaid managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a fee-for-service delivery system, or under which at least 90 percent of the State’s Medicaid beneficiaries are enrolled in Medicaid managed care organizations as defined in § 438.2, may request that its fee-for-service program be exempted from the requirement(s) in paragraphs (a)(1) and (2) of this section. (A) A state may submit an exemption request once per calendar year for a one (1) year exemption. (B) The annual request must be submitted as part of a state’s annual Advance Planning Document for MMIS operations costs. (C) The State’s request must include documentation that the State meets the criteria for the exemption, using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. (ii) CMS will grant the exemption for a one-year period if the State establishes to CMS’s satisfaction that the State meets the criteria for the exemption and has established a plan to ensure there will be efficient electronic access to the same information through alternative means. ■ 6. Section 431.201 is amended by revising the definition of ‘‘Action’’ to read as follows: § 431.201 Definitions. * * * * * Action means: (1) A termination, suspension of, or reduction in covered benefits or services, including benefits or services for which there is a current approved prior authorization; (2) A termination, suspension of, or reduction in Medicaid eligibility, or an increase in beneficiary liability, including a determination that a beneficiary must incur a greater amount E:\FR\FM\18DEP2.SGM 18DEP2 82674 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules of medical expenses in order to establish income eligibility in accordance with § 435.121(e)(4) or § 435.831 of this chapter; (3) A determination that a beneficiary is subject to an increase in premiums or cost-sharing charges under subpart A of part 447 of this chapter; or (4) A determination by a skilled nursing facility or nursing facility to transfer or discharge a resident and an adverse determination by a State with regard to the preadmission screening and resident review requirements of section 1919(e)(7) of the Act. * * * * * ■ 7. Section 431.220 is amended— ■ a. In paragraph (a)(1)(iv) by removing the term ‘‘or’’ from the end of the paragraph; ■ b. In paragraph (a)(1)(v) by removing ‘‘.’’ from the end of the paragraph and adding in its place ‘‘; or’’; and ■ c. By adding paragraph (a)(1)(vi). The addition reads as follows: § 431.220 When a hearing is required. (a) * * * (1) * * * (vi) A prior authorization decision. * * * * * PART 435—STATE ORGANIZATION AND GENERAL ADMINISTRATION Authority: 42 U.S.C. 1302. 9. Section 435.917 is amended by: a. Revising the paragraph headings of paragraphs (a) and (b); and ■ b. Revising paragraph (b)(2). The revisions read as follows: § 435.917 Notice of agency’s decision concerning eligibility, benefits, or services. (a) Notice of determinations. * * * * * * * (b) Content of notice. * * * * * * * * (2) Notice of adverse action including denial, termination or suspension of eligibility or change in benefits or services. Any notice of denial, termination or suspension of Medicaid eligibility or, in the case of beneficiaries receiving medical assistance, denial of or change in benefits or services must be consistent with § 431.210 of this chapter. * * * * * khammond on DSKJM1Z7X2PROD with PROPOSALS2 * PART 438—MANAGED CARE 10. The authority citation for part 438 continues to read as follows: Authority: 42 U.S.C. 1302. 11. Section 438.9 is amended by revising paragraph (b)(7) to read as follows: VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 * * * * (b) * * * (7) The PAHP standards in §§ 438.206(b)(1), 438.210, 438.214, 438.224, 438.230, and 438.242, excluding the requirement in § 438.242(b)(7) to comply with § 431.61(a) and (c) of this chapter. * * * * * ■ 12. Section 438.62 is amended by revising paragraph (b)(1)(vii)(A) introductory text to read as follows: § 438.62 Continued services to enrollees. * * * * * (b) * * * (1) * * * (vii) * * * (A) The MCO, PIHP, or PAHP must comply with the requirements in paragraph (b)(1)(vi) of this section beginning January 1, 2022 until the start of the rating period beginning on or after January 1, 2023 with regard to data: * * * * * ■ 13. Section 438.210 is amended by— ■ a. Revising paragraph (d)(1); and ■ b. Adding paragraph (g). The addition and revision read as follows: Coverage and authorization of * ■ ■ ■ * § 438.210 services. 8. The authority citation for part 435 is revised to read as follows: ■ ■ § 438.9 Provisions that apply to nonemergency medical transportation PAHPs. * * * * (d) * * * (1) Standard authorization decisions. For standard authorization decisions, provide notice as expeditiously as the enrollee’s condition requires and within State-established timeframes that may not exceed 14 calendar days following receipt of the request for service, with a possible extension of up to 14 additional calendar days, and for standard authorization decisions made beginning with the rating period on or after January 1, 2023, may not exceed 7 calendar days following receipt of the request for service, with a possible extension of up to 14 additional calendar days if— * * * * * (g) Public reporting of prior authorization metrics. Beginning March 31, 2023, the MCO, PIHP, or PAHP must make the following information about plan level prior authorization publicly accessible by posting directly on its website or via publicly accessible hyperlink(s), annually by the end of the first calendar quarter, data, for the prior rating period: (1) A list of all items and services, not including covered outpatient drugs, that require prior authorization; (2) The percentage of standard prior authorization requests that were PO 00000 Frm 00090 Fmt 4701 Sfmt 4702 approved, reported separately for items and services, not including covered outpatient drugs; (3) The percentage of standard prior authorization requests that were denied, reported separately for items and services, not including covered outpatient drugs; (4) The percentage of standard prior authorization requests that were approved after appeal, reported separately for items and services, not including covered outpatient drugs; (5) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, reported separately for items and services, not including covered outpatient drugs; (6) The percentage of expedited prior authorization requests that were approved, reported separately for items and services, not including covered outpatient drugs; and (7) The average and median time that elapsed between the submission of a request and a determination by the MA organization, for standard prior authorizations, reported separately for items and services, not including covered outpatient drugs. ■ 14. Section 438.242 is amended by— ■ a. Revising paragraphs (b)(5) introductory text; ■ b. Adding paragraph (b)(5)(ii); ■ c. Revising paragraph (b)(6); and ■ b. Adding paragraphs (b)(7) and (8). The revisions and additions read as follows: § 438.242 Health information systems. * * * * * (b) * * * (5) Subject to paragraph (b)(8) of this section, implement a Patient Access Application Programming Interface (API) as specified in § 431.60 of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP and include: * * * * * (ii) Reporting metrics specified at § 431.60(h) of this chapter at the plan level. (6) Except for § 431.70(d) of this chapter implement, by January 1, 2021, and maintain a publicly accessible standard-based Provider Directory API described at § 431.70 of this chapter, which must include all information specified at § 438.10(h)(1) and (2) of this chapter. The State must require, at a minimum, that each MCO, PIHP, and PAHP comply with § 431.70(d) by the rating period beginning on or after January 1, 2023. (7) By the rating period beginning on or after January 1, 2023, comply with § 431.61(a) through (d) and § 431.80(a) E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules of this chapter as if such requirements applied directly to the MCO, PIHP, or PAHP. (8) The following timeframes apply to paragraph (b)(5) of this section: (i) Except for the requirements at §§ 431.60(b)(5), 431.60(c)(3)(iii), 431.60(g), and 431.60(h) of this chapter, comply with the by the requirements of § 431.60 of this chapter by January 1, 2021. (ii) Comply with the requirements at §§ 431.60(b)(5), 431.60(c)(3)(iii), and 431.60(g) of this chapter by the rating period beginning on or after January 1, 2023. (iii) Comply with the reporting requirements at § 431.60(h) of this chapter beginning with the end of the first full quarter of the rating period beginning on or after January 1, 2023 based on the previous quarter’s data. * * * * * PART 440—SERVICES: GENERAL PROVISIONS 15. The authority citation for part 440 continues to read as follows: ■ Authority: 42 U.S.C. 1302. 16. Section 440.230 is amended by adding paragraphs (d)(1) and (2) to read as follows: ■ § 440.230 Sufficiency of amount, duration, and scope. khammond on DSKJM1Z7X2PROD with PROPOSALS2 * * * * * (d) * * * (1) Prior authorization decision timeframes. The State Medicaid agency must— (i) Beginning January 1, 2023, provide notice of prior authorization decisions for items and services, not including covered outpatient drugs, as expeditiously as a beneficiary’s health condition requires and under any circumstances not later than 72 hours of receiving a request for an expedited determination and not later than 7 calendar days for standard requests. The timeframe for authorization decisions could be extended by up to 14 calendar days for standard requests if the beneficiary or provider requests an extension, or if the state agency or its authorized representative determines that additional information from the provider is needed to make a decision. (ii) Provide the beneficiary with notice of the agency’s prior authorization decision and fair hearing rights in accordance with § 435.917 and part 431, subpart E of this chapter. (2) Public reporting of prior authorization metrics. Beginning March 31, 2023, the State Medicaid agency must make the following information about State agency level prior VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 authorization decisions publicly accessible by posting directly on its website or via publicly accessible hyperlink(s), annually by the end of the first calendar quarter, data for the prior calendar year: (i) A list of all items and services, not including covered outpatient drugs, that require prior authorization; (ii) The percentage of standard prior authorization requests that were approved, reported separately for items and services, not including covered outpatient drugs; (iii) The percentage of standard prior authorization requests that were denied, reported separately for items and services, not including covered outpatient drugs; (iv) The percentage of standard prior authorization requests that were approved after appeal, reported separately for items and services, not including covered outpatient drugs; (v) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, reported separately for items and services, not including covered outpatient drugs; (vi) The percentage of expedited prior authorization requests that were approved, reported separately for items and services, not including covered outpatient drugs; and (vii) The average and median time that elapsed between the submission of a request and a determination by the state Medicaid agency, for standard prior authorizations, reported separately for items and services, not including covered outpatient drugs. PART 457—ALLOTMENTS AND GRANTS TO STATES 17. The authority citation for part 457 continues to read as follows: ■ Authority: 42 U.S.C. 1302. 18. Section 457.495 is amended by revising paragraph (d) to read as follows: ■ § 457.495 State assurance of access to care and procedures to assure quality and appropriateness of care. * * * * * (d) Decisions related to the prior authorization of health services. (1) That decisions related to the prior authorization of health services are completed in accordance with the medical needs of the patient, but no later than 7 calendar days after the date of receipt of the request for a standard determination and by no later than 72 hours after the date of receipt of the request for an expedited determination. A possible extension of up to 14 days PO 00000 Frm 00091 Fmt 4701 Sfmt 4702 82675 may be permitted if the enrollee requests the extension or if the physician or health plan determines the additional information is needed. (2) Reserved. ■ 19. Section 457.700 is amended by revising paragraph (c) to read as follows: § 457.700 Basis, scope, and applicability. * * * * * (c) Applicability. The requirements of this subpart apply to separate child health programs and Medicaid expansion programs, except that §§ 457.730, 457.731, and 457.732 do not apply to Medicaid expansion programs. Separate child health programs that provide benefits exclusively through managed care organizations may meet the requirements of §§ 457.730, 457.731, and 457.732 by requiring the managed care organizations to meet the requirements of § 457.1233(d)(2). ■ 20. Section 457.730 is amended by— ■ a. Revising paragraphs (b)(3); ■ b. Adding paragraph (b)(5); ■ c. Revising paragraph (c)(3) introductory text; ■ d. Adding paragraph (c)(3)(iii); ■ e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and (e)(2); ■ f. Redesignating paragraph (g) as paragraph (i); and ■ g. Adding new paragraphs (g) and (h). The revisions and additions read as follows: § 457.730 Beneficiary access to and exchange of data. * * * * * (b) * * * (3) Clinical data, as defined in the USCDI version 1, if the State maintains any such data, no later than 1 business day after the data are received by the State; * * * * * (5) By January 1, 2023, pending and active prior authorization decisions and related clinical documentation and forms for items and services, not including covered outpatient drugs, including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date, no later than 1 business day after a provider initiates a prior authorization for the beneficiary or there is a change of status for the prior authorization. (c) * * * (3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law, and be conformant with the E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82676 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules requirements in paragraphs (c)(3)(iii) of this section: * * * * * (iii) Beginning January 1, 2023, be conformant with the implementation specifications at 45 CFR 170.215(c)(5) for data specified in paragraphs (b)(1) and (2) of this section, 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified in paragraph (b)(3), 45 CFR 170.215(c)(7) for data specified in (b)(4), and 45 CFR 170.215(c)(6) for data specified in paragraph (b)(5) of this section. (4) May use an updated version of any standard or all standards and any or all implementation guides or specifications required under paragraphs (b) or (c) of this section, §§ 457.731, 457.732, and 457.760, where: * * * * * (ii) * * * (C) Use of the updated version of the standard, implementation guide, or specification does not disrupt an end user’s ability to access the data described in paragraph (b) of this section, or the data described in §§ 457.731, 457.732, and 457.760 of this chapter through the required API. * * * * * (e) * * * (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which parties seek to access electronic health information, as defined at 45 CFR 171.102, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. * * * * * (g) Privacy policy attestation. (1) Beginning January 1, 2023, the State must establish, implement, and maintain a process for requesting an attestation from a third-party app developer requesting to retrieve data via the Patient Access API that indicates the app adheres to certain privacy provisions. The State must: (i) Independently, or through the support of a third party, request a thirdparty app developer to attest whether: (A) The app has a privacy policy that is publicly available and accessible at all times, including updated versions, and that is written in plain language, and that the third-party app has affirmatively shared with the beneficiary prior to the beneficiary authorizing app access to their health information. To ‘‘affirmatively share’’ means that the beneficiary had to take an action to indicate they saw the privacy policy, such as click or check a box or boxes. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 (B) The app’s privacy policy includes, at a minimum: (1) How a beneficiary’s health information may be accessed, exchanged, or used by any person or other entity, including whether the beneficiary’s health information may be shared or sold at any time (including in the future); (2) A requirement for express consent from a beneficiary before the beneficiary’s health information is accessed, exchanged, or used, including receiving express consent before a beneficiary’s health information is shared or sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction); (3) If an app will access any other information from a beneficiary’s device; and (4) How a beneficiary can discontinue app access to their data and what the app’s policy and process is for disposing of a beneficiary’s data once the beneficiary has withdrawn consent. (ii) Include information in the beneficiary resources required in paragraph (f) of this section about the specific content of the State’s privacy policy attestation required under this paragraph, and, at a minimum, the timeline for the attestation process, the method for informing beneficiary about the app developer’s response or nonresponse to the State’s request, and the beneficiary’s role and rights in this process; and (iii) Request the attestation at the time the third-party app engages the API and notify the beneficiary as follows: (A) The State must inform the beneficiary within 24 hours of requesting the attestation from the thirdparty app developer regarding the status of the attestation—positive, negative, or no response, with a clear explanation of what each means; (B) If a beneficiary does not respond within 24 hours of when the State sends notice of the attestation status to the beneficiary, the State must proceed with making the beneficiary’s data available to the third-party app consistent with the beneficiary’s original request. (2) The State must not discriminate when implementing this requirement, including for the purposes of competitive advantage; the method employed to meet this requirement must be applied equitably across all apps requesting access to the Patient Access API. (h) Reporting on the use of the Patient Access API. (1) Beginning March 31, 2023, a State must report to CMS, at the State agency level, by the end of each PO 00000 Frm 00092 Fmt 4701 Sfmt 4702 calendar quarter, based on the previous quarter’s data as follows: (i) The total number of unique beneficiaries whose data are transferred via the Patient Access API to a beneficiary-designated third-party application; and (ii) The number of unique beneficiaries whose data are transferred via the Patient Access API to a beneficiary-designated third-party application more than once. (2) [Reserved]. * * * * * ■ 21. Section 457.731 is added to subpart G to read as follows: § 457.731 Access to and exchange of health data to providers and payers. (a) Application Programming Interface to support data transfer from payers to providers—Provider Access API.—(1) Accessible content and API requirements. Beginning January 1, 2023, a State must implement and maintain a standards-based Application Programming Interface (API) compliant with § 457.730(c), (d), and (e): (i) Individual beneficiary data. The Provider Access API must make available to providers, if requested by the provider, as permitted by the beneficiary per paragraph (a)(3) of this section, and as permitted by applicable law, at a minimum, data maintained by the State with a date of service on or after January 1, 2016, within one (1) business day of receipt, conformant with the implementation specifications at 45 CFR 170.215(c)(5) for data specified at § 431.60(b)(1) and (2) of this chapter, not including remittances and enrollee cost sharing information, 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified at § 431.60(b)(3) of this chapter, 45 CFR 170.215(c)(7) for data specified at § 431.60(b)(4), and 45 CFR 170.215(c)(6) for data specified at § 431.60(b)(5) of this chapter; and (ii) Bulk data access. The Provider Access API must be able to share the data specified in (a)(1)(i) of this section conformant with the implementation specification at 45 CFR 170.215(a)(4) to facilitate sharing the specified data relevant to one or more beneficiaries at one time. (2) Attribution. A State must establish, implement, and maintain a process to facilitate generating each provider’s current beneficiary roster to enable this payer-to-provider data sharing via the Provider Access API; (3) Opt-in. A State may put a process in place to allow a beneficiary or the beneficiary’s personal representatives to opt-in to permit the State’s use of the Provider Access API for sharing with E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules the each of the beneficiary’s provider(s) currently providing care, or planning to provide care, the data specified in paragraph (a)(1) of this section. (4) Provider resources regarding APIs. A State must provide on its website and through other appropriate mechanisms through which it ordinarily communicates with providers, educational resources in non-technical, simple and easy-to-understand language explaining general information concerning how a provider may make a request to the State for beneficiary data using the standards-based Provider Access API required under paragraph (a)(1) of this section, both for individual access and bulk data requests. (5) Out-of-network provider access. A State cannot deny use of, or access to, the Provider Access API based on a provider’s contract status. (b) Coordination among payers— Payer-to-Payer Data Exchange. (1) Beginning January 1, 2023, a State must implement and maintain a standardsbased API compliant with § 457.730(c), (d), and (e) that makes available to another payer, at a minimum, the data maintained by the State with a date of service on or after January 1, 2016, within one (1) business day of receipt, conformant with the implementation specifications at 45 CFR 170.215(c)(5) for data specified at § 431.60(b)(1) and (2) of this chapter not including remittances and enrollee cost sharing information, 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified at § 431.60(b)(3) of this chapter, 45 CFR 170.215(c)(7) for data specified at § 431.60(b)(4) of this chapter, and 45 CFR 170.215(c)(6) for data specified at § 431.60(b)(5) of this chapter. Such information received by a State must be incorporated into the State’s records about the current beneficiary. (2) With the approval and at the direction of a current or former beneficiary or the beneficiary’s personal representative, the State must: (i) Receive all such data for a current beneficiary from any other payer that has provided coverage to the beneficiary within the preceding 5 years; (ii) At any time a beneficiary is currently enrolled with the State and up to 5 years after disenrollment, send all such data to any other payer that currently covers the beneficiary or a payer the beneficiary or the beneficiary’s personal representative specifically requests receive the data; and (iii) Send data received from another payer under this paragraph in the electronic form and format it was received. VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 (c) Coordination among payers at enrollment—Payer-to-Payer API.—(1) Accessible content and API requirements. Beginning January 1, 2023, a State must make the standardsbased API specified in paragraph (b)(1) of this section conformant with the implementation specification at 45 CFR 170.215(a)(4) to facilitate sharing the data specified in paragraph (b)(1) of this section relevant to one or more beneficiaries at one time. (2) Requesting data exchange. (i) When a beneficiary enrolls in coverage with the State, the State may request the data from a previous payer through the standards-based API described in paragraph (c)(1) of this section, as permitted by the enrollee per paragraph (c)(5) of this section, and as permitted by applicable law; (ii) For any beneficiaries who enroll with the State during the first calendar quarter of each year, the State must request the specified data within one (1) week of the end of the first calendar quarter from any previous payers through the standards-based API described in paragraph (c)(1) of this section, as permitted by the beneficiary per paragraph (c)(5) of this section, and as permitted by applicable law; (iii) If a State receives a request from another payer to make data available for one or more former beneficiaries who have enrolled with the new payer, the State must respond by making the required data available via the standards-based API described in paragraph (c)(1) of this section within one (1) business day of receiving the request. (3) Previous or concurrent payer. A State must maintain a process to obtain from a new beneficiary the name of the new beneficiary’s previous payer as part of the enrollment process, and concurrent payer if the beneficiary has coverage through more than one payer, to facilitate data sharing using the Payer-to-Payer API described in paragraph (c)(1) of this section. (4) Concurrent payer exchange. When a beneficiary has concurrent coverage with another payer also subject to CMS regulations on the Payer-to-Payer API, the State must make available to the other payer the data described in paragraph (b)(1) of this section through the standards-based API described in paragraph (c)(1) of this section quarterly. (5) Opt-in. A State must put a process in place to allow a beneficiary or the beneficiary’s personal representative to opt-in to permit the State’s use of the Payer-to-Payer API data sharing specified in paragraph (c)(1) of this section. PO 00000 Frm 00093 Fmt 4701 Sfmt 4702 82677 (d) Obligations. The requirements under this section do not in any way alter or change a State’s obligation as a HIPAA covered entity to comply with regulations regarding standard transactions at 45 CFR part 162. (e) Extensions and Exemptions—(1) Extension. (i) A State may submit a written application to request to delay implementation of the requirements in paragraphs (a) through (c) of this section one-time for up to one (1) year with respect to its Medicaid fee-for-service program. The written application must be submitted and approved as part of the State’s annual Advance Planning Document for MMIS operations costs and must include: (A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and explaining why those reasons result from circumstances that are unique to States operating CHIP fee-for service programs; (B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and (C) A comprehensive plan to meet implementation requirements no later than 1 year after the initial compliance date. (ii) CMS will grant the State’s request if it determines based on the information provided in the State’s annual Advance Planning Document for MMIS operations costs that the request adequately establishes a need to delay implementation, that this need results from circumstances that are unique to States operating CHIP fee-for-service programs, that the State has made a good faith effort to implement the proposed requirements as soon as possible, and that the State has a clear plan to implement the requirements no later than one (1) year after the proposed compliance date. (2) Exemption. (i) A State operating a CHIP program under which at least 90 percent of all covered items and services are provided to beneficiaries through managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a fee-for-service delivery system, or under which at least 90 percent of the State’s beneficiaries are enrolled in managed care organizations as defined in § 457.10, may request that its fee-forservice program be exempted from the requirement(s) in paragraphs (a) through (c) of this section. (A) A state may submit an exemption request once per calendar year for a one (1) year exemption. (B) The annual request must be submitted as part of a state’s annual E:\FR\FM\18DEP2.SGM 18DEP2 82678 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules Advance Planning Document for MMIS operations costs. (C) The State’s request must include documentation that the State meets the criteria for the exemption, using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. (ii) CMS will grant the exemption for a one-year period if the State establishes to CMS’s satisfaction that the State meets the criteria for the exemption and has established a plan to ensure there will be efficient electronic access to the same information through alternative means. (f) Applicability. This section is applicable beginning January 1, 2023. ■ 22. Section 457.732 is added to subpart G to read as follows: khammond on DSKJM1Z7X2PROD with PROPOSALS2 § 457.732 Documentation and prior authorization. (a) Requirements to support provider documentation discovery and to support prior authorization. At a minimum: (1) Documentation Requirement Lookup Service (DRLS) Application Programming Interface (API). Beginning January 1, 2023, a State must implement and maintain a standards-based API compliant with § 457.730(c), (d), and (e) — (i) That is populated with the State’s list of covered items and services, not including covered outpatient drugs, for which prior authorization is required, and with the State’s documentation requirements for submitting a prior authorization request, including a description of the required documentation; and (ii) That is conformant with the implementation specifications at 45 CFR 170.215(c)(1) and (2). (2) Prior Authorization Support API. Beginning January 1, 2023, a State must implement and maintain a standardsbased API compliant with § 457.730(c), (d), and (e) — (i) That facilitates a HIPAA-compliant prior authorization request and response, including any forms or medical record documentation required by the State for the items or services for which the provider is seeking prior authorization; (ii) That is conformant with the implementation specifications at 45 CFR 170.215(c)(1) and (2). (iii) That includes in the response whether the State approves (and for how long), denies, or requests more information related to the prior authorization request, along with a denial reason code in the case of denial; (iv) A State must include a specific reason for a denial in the case of a denial with all prior authorization VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 decisions, regardless of the method used to send the prior authorization decision. (b) Extensions and Exemptions.—(1) Extension. (i) A State may submit a written application to request to delay implementation of the requirements in paragraphs (a)(1) and (2) of this section one-time for up to one (1) year with respect to its Medicaid fee-for-service program. The written application must be submitted and approved as part of the State’s annual Advance Planning Document for MMIS operations costs and must include: (A) A narrative justification describing the specific reasons why the State cannot reasonably satisfy the requirement(s) by the compliance date and explaining why those reasons result from circumstances that are unique to States operating CHIP fee-for service programs; (B) A report on completed and ongoing State implementation activities that evidence a good faith effort towards compliance; and (C) A comprehensive plan to meet implementation requirements no later than 1 year after the initial compliance date. (ii) CMS will grant the State’s request if it determines based on the information provided in the State’s annual Advance Planning Document for MMIS operations costs that the request adequately establishes a need to delay implementation, that this need results from circumstances that are unique to States operating CHIP fee-for-service programs, that the State has made a good faith effort to implement the proposed requirements as soon as possible, and that the State has a clear plan to implement the requirements no later than one (1) year after the proposed compliance date. (2) Exemption. (i) A State operating a CHIP program under which at least 90 percent of all covered items and services are provided to beneficiaries through managed care contracts with MCOs, PIHPs, or PAHPs, rather than through a fee-for-service delivery system, or under which at least 90 percent of the State’s beneficiaries are enrolled in managed care organizations as defined in § 457.10, may request that its fee-forservice program be exempted from the requirement(s) in paragraphs (a)(1) and (2) of this section. (A) A state may submit an exemption request once per calendar year for a one (1) year exemption. (B) The annual request must be submitted as part of a state’s annual Advance Planning Document for MMIS operations costs. (C) The State’s request must include documentation that the State meets the PO 00000 Frm 00094 Fmt 4701 Sfmt 4702 criteria for the exemption, using data from any one of the three most recent and complete calendar years prior to the date the exemption request is made. (ii) CMS will grant the exemption for a one-year period if the State establishes to CMS’s satisfaction that the State meets the criteria for the exemption and has established a plan to ensure there will be efficient electronic access to the same information through alternative means. (3) Public reporting of prior authorization metrics. Beginning March 31, 2023, the State must make the following information about State agency level prior authorization decisions publicly accessible by posting directly on its website or via publicly accessible hyperlink(s), annually by the end of the first calendar quarter, data for the prior calendar year: (i) A list of all items and services, not including covered outpatient drugs, that require prior authorization; (ii) The percentage of standard prior authorization requests that were approved, reported separately for items and services, not including covered outpatient drugs; (iii) The percentage of standard prior authorization requests that were denied, reported separately for items and services, not including covered outpatient drugs; (iv) The percentage of standard prior authorization requests that were approved after appeal, reported separately for items and services, not including covered outpatient drugs; (v) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, reported separately for items and services, not including covered outpatient drugs; (vi) The percentage of expedited prior authorization requests that were approved, reported separately for items and services, not including covered outpatient drugs; and (vii) The average and median time that elapsed between the submission of a request and a determination by the State, for standard prior authorizations, reported separately for items and services, not including covered outpatient drugs. ■ 23. Section 457.760 is amended by adding paragraph (d) to read as follows: § 457.760 Access to published provider directory information * * * * * (d) Beginning January 1, 2023, the Provider Directory API must be conformant with the implementation specification at 45 CFR 170.215(c)(8). ■ 24. Section 457.1233 is amended by— E:\FR\FM\18DEP2.SGM 18DEP2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules a. Revising paragraph (d)(2) introductory text; ■ b. Adding paragraph (d)(2)(ii); ■ c. Revising paragraph (d)(3); and ■ d. Adding paragraph (d)(4) and (5). The revisions and additions read as follows: ■ PART 156—HEALTH INSURANCE ISSUER STANDARDS UNDER THE AFFORDABLE CARE ACT, INCLUDING STANDARDS RELATED TO EXCHANGES 25. The authority citation for part 156 continues to read as follows: ■ Authority: 42 U.S.C. 18021–18024, 18031– 18032, 18041–18042, 18044, 18054, 18061, 18063, 18071, 18082, and 26 U.S.C. 36B. § 457.1233 Structure and operations standards. khammond on DSKJM1Z7X2PROD with PROPOSALS2 * * * * * (d) * * * (2) Subject to paragraph (d)(5) of this section, each MCO, PIHP, and PAHP must implement a Patient Access Application Programming Interfaces (APIs) as specified in § 457.730 as if such requirements applied directly to the MCO, PIHP, or PAHP, and include: * * * * * (ii) Reporting metrics specified at § 457.730(h) at the plan level. (3) Except for § 457.760(d), implement, by January 1, 2021, and maintain a publicly accessible standards-based Provider Directory API described at § 457.760 of this chapter, which must include all information specified in § 438.10(h)(1) and (2) of this chapter. The state must require, at a minimum, that each MCO, PIHP, and PAHP comply with § 457.760(d) by the rating period beginning on or after January 1, 2023. (4) By the rating period beginning on or after January 1, 2023, comply with §§ 457.731(a) through (d) and 457.732(a) as if such requirements applied directly to the MCO, PIHP, or PAHP. (5) The following timeframes apply to paragraph (d)(2) of this section: (i) Except for the requirement at §§ 457.730(b)(5), 457.730(c)(3)(iii), 457.730(g), and 457.730(h), comply with the by the requirements of § 457.730 by January 1, 2021. (ii) Comply with the requirements at §§ 457.730(b)(5), 457.730(c)(3)(iii), and 457.730(g) by the rating period beginning on or after January 1, 2023. (iii) Comply with the reporting requirement at § 457.730(h) beginning with the end of the first full quarter of the rating period beginning on or after January 1, 2023 based on the previous quarter’s data. * * * * * For the reasons set forth in the preamble, the Department of Health and Human Services (HHS) proposes to amend 45 CFR subtitle A, subchapter B as set forth below: VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 26. Section 156.221 is amended by— a. Revising paragraph (b)(1)(iii); b. Adding paragraph (b)(1)(iv); c. Revising paragraph (c)(3) introductory text; ■ d. Adding paragraph (c)(3)(iii); ■ e. Revising paragraph (c)(4) introductory text, (c)(4)(ii)(C), (e)(2), and (f)(1) introductory text; ■ f. Adding paragraph (f)(2); ■ g. Redesignating paragraphs (h) and (i) as paragraphs (j) and (k); ■ h. Adding new paragraphs (h) and (i); and ■ i. Revising newly redesignated paragraph (j). The revisions and addition read as follows: ■ ■ ■ ■ § 156.221 Access to and exchange of health data and plan information. * * * * * (b) * * *. (1) * * * (iii) Clinical data, as defined in the USCDI version 1, if the QHP issuer maintains any such data, no later than 1 business day after data are received by the QHP issuer; and (iv) Beginning January 1, 2023, pending and active prior authorization decisions and related clinical documentation and forms for items and services, not including prescription drugs, including the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date, no later than 1 business day after a provider initiates a prior authorization for the enrollee or there is a change of status for the prior authorization. * * * * * (c) * * * (3) Must comply with the content and vocabulary standard requirements in paragraphs (c)(3)(i) and (ii) of this section, as applicable to the data type or data element, unless alternate standards are required by other applicable law, and be conformant with the requirements in paragraph (c)(3)(iii) of this section: * * * * * (iii) Beginning January 1, 2023, be conformant with the implementation PO 00000 Frm 00095 Fmt 4701 Sfmt 4702 82679 specifications at § 170.215(c)(5) for data specified at § 156.221(b)(1)(i) and (ii), § 170.215(a)(2) or § 170.215(c)(6) of this subchapter for data specified at §§ 156.221(b)(1)(iii), and 170.215(c)(6) of this subchapter for data specified in paragraph (b)(1)(iv) of this section. (4) May use an updated version of any standard or all standards and any or all implementation guides or specifications required under paragraphs (b), (c), or (f) of this section, §§ 156.222 or 156.223, where: * * * * * (ii) * * * (C) Use of the updated version of the standard, implementation guide, or specification does not disrupt an end user’s ability to access the data described in paragraph (b) or (f) of this section or the data described in §§ 156.222 or 156.223 of this chapter through the required API. * * * * * (e) * * * (2) Makes this determination using objective, verifiable criteria that are applied fairly and consistently across all applications and developers through which parties seek to access electronic health information, as defined at § 171.102 of this subchapter, including but not limited to criteria that may rely on automated monitoring and risk mitigation tools. (f) * * * (1) From January 1, 2022 until December 31, 2022, a QHP issuer on a Federally-facilitated Exchange must maintain a process for the electronic exchange of, at a minimum, the data classes and elements included in the content standard adopted at § 170.213 of this subchapter. Such information received by a QHP issuer on a Federallyfacilitated Exchange must be incorporated into the QHP issuer’s records about the current enrollee. With the approval and at the direction of a current or former enrollee or the enrollee’s personal representative, a QHP issuer on a Federally-facilitated Exchange must: * * * * * (2) Beginning January 1, 2023, a QHP issuer on a Federally-facilitated Exchange must implement and maintain an API compliant with § 156.221(c)(1), (c)(2), (c)(3)(i), and (c)(3)(ii), (d), and (e), and that is conformant with the implementation specifications at § 170.215(c)(5) of this chapter for data specified at § 156.221(b)(1)(i) and (ii) not including remittances and enrollee cost sharing information, § 170.215(a)(2) or 170.215(c)(6) of this subchapter for data specified at § 156.221(b)(1)(iii), and § 170.215(c)(6) of this subchapter for E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82680 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules data specified in paragraph (b)(1)(iv). Such information received by a QHP issuer on a Federally-facilitated Exchange must be incorporated into the QHP issuer’s records about the current enrollee. (i) With the approval and at the direction of a current or former enrollee or the enrollee’s personal representative, a QHP issuer on a Federally-facilitated Exchange must: (A) Receive all such data for a current enrollee from any other payer that has provided coverage to the enrollee within the preceding 5 years; (B) At any time an enrollee is currently enrolled in the plan and up to 5 years after disenrollment, send all such data to any other payer that currently covers the enrollee or a payer the enrollee or the enrollee’s personal representative specifically requests receive the data; and (C) Send data received from another payer under this paragraph (f)(2) of this section in the electronic form and format it was received. (ii) [Reserved]. * * * * * (h) Privacy policy attestation. (1) Beginning January 1, 2023, a QHP issuer on a Federally-facilitated Exchange must establish, implement, and maintain a process for requesting an attestation from a third-party app developer requesting to retrieve data via the Patient Access API that indicates the app adheres to certain privacy provisions. The QHP issuer on a Federally-facilitated Exchange must: (i) Independently, or through the support of a third party, request a thirdparty app developer to attest whether: (A) The app has a privacy policy that is publicly available and accessible at all times, including updated versions, and that is written in plain language, and that the third-party app has affirmatively shared with the enrollee prior to the enrollee authorizing app access to their health information. To ‘‘affirmatively share’’ means that the enrollee had to take an action to indicate they saw the privacy policy, such as click or check a box or boxes. (B) The app’s privacy policy includes, at a minimum: (1) How an enrollee’s health information may be accessed, exchanged, or used by any person or other entity, including whether the enrollee’s health information may be shared or sold at any time (including in the future); (2) A requirement for express consent from an enrollee before the enrollee’s health information is accessed, exchanged, or used, including receiving VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 express consent before an enrollee’s health information is shared or sold (other than disclosures required by law or disclosures necessary in connection with the sale of the application or a similar transaction); (3) If an app will access any other information from an enrollee’s device; and (4) How an enrollee can discontinue app access to their data and what the app’s policy and process is for disposing of an enrollee’s data once the enrollee has withdrawn consent. (ii) Include information in the enrollee resources required in paragraph (g) of this section about the specific content of the QHP issuer’s privacy policy attestation required under this paragraph, and, at a minimum, the timeline for the attestation process, the method for informing enrollees about the app developer’s response or nonresponse to the QHP issuer’s request, and the enrollee’s role and rights in this process; and (iii) Request the attestation at the time the third-party app engages the API and notify the enrollee as follows: (A) The QHP issuer on a Federallyfacilitated Exchange must inform the enrollee within 24 hours of requesting the attestation from the third-party app developer regarding the status of the attestation—positive, negative, or no response, with a clear explanation of what each means; (B) If an enrollee does not respond within 24 hours of when the QHP issuer send the notice of the attestation status to the enrollee, the QHP issuer must proceed with making the enrollee’s data available to the third-party app consistent with the enrollee’s original request. (2) A QHP issuer must not discriminate when implementing this requirement, including for the purposes of competitive advantage; the method employed to meet this requirement must be applied equitably across all apps requesting access the Patient Access API. (i) Reporting on the use of the Patient Access API. (1) Beginning March 31, 2023, a QHP issuer on a Federallyfacilitated Exchange must report to HHS, at the issuer level, by the end of each calendar quarter, based on the previous quarter’s data: (i) The total number of unique enrollees whose data are transferred via the Patient Access API to an enrollee designated third-party application; and (ii) The number of unique enrollees whose data are transferred via the Patient Access API to an enrollee designated third-party application more than once. PO 00000 Frm 00096 Fmt 4701 Sfmt 4702 (2) [Reserved]. (j) Exception. (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraphs (a) through (i) of this section, the issuer must include as part of its QHP application a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of noncompliance upon enrollees, the current or proposed means of providing health information to enrollees, and solutions and a timeline to achieve compliance with the requirements of this section. (2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraphs (a) through (i) of this section if the Exchange determines that making such health plan available through such Exchange is in the interests of qualified individuals and qualified employers in the State or States in which such Exchange operates. * * * * * ■ 27. Section 156.222 is added to read as follows: § 156.222 Access to and exchange of health data and plan information to providers and payers. (a) Application Programming Interface to support data transfer from payers to providers—Provider Access API. Subject to paragraph (d) of this section: (1) Accessible content and API requirements. Beginning January 1, 2023, a QHP issuer on a Federallyfacilitated Exchange must implement and maintain a standards-based Application Programming Interface (API) compliant with § 156.221(c), (d), and (e): (i) Individual enrollee data. The Provider Access API must make available to providers, if requested by the provider, as permitted by the enrollee per paragraph (a)(3) of this section, and as permitted by applicable law, at a minimum, data maintained by the QHP with a date of service on or after January 1, 2016, within one (1) business day of receipt, conformant with the implementation specifications at § 170.215(c)(5) of this subchapter for data specified at § 156.221(b)(1)(i) and (ii), not including remittances and enrollee cost sharing information, § 170.215(a)(2) or (c)(6) of this subchapter for data specified at § 156.221(b)(1)(iii), and § 170.215(c)(6) of this subchapter for data specified in paragraph (b)(1)(iv) of this section; and (ii) Bulk data access. The Provider Access API must be able to share the data described in paragraph (a)(1)(i) of E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules this section conformant with the implementation specification at § 170.215(a)(4) to facilitate sharing the specified data relevant to one or more QHP enrollees at one time; (2) Attribution. A QHP issuer on a Federally-facilitated Exchange must establish, implement, and maintain a process to facilitate generating each provider’s current enrollee rosters to enable payer-to-provider data sharing via the Provider Access API. (3) Opt-in. A QHP issuer on a Federally-facilitated Exchange may put a process in place to allow an enrollee or the enrollee’s personal representative to opt-in to permit the QHP’s use of the Provider Access API for sharing with each of the enrollee’s provider(s) currently providing care, or planning to provide care, the data specified in paragraph (a)(1) of this section. (4) Provider resources regarding APIs. A QHP issuer on a Federally-facilitated Exchange must provide on its website and through other appropriate mechanisms through which it ordinarily communicates with providers, educational resources in non-technical, simple, and easy-to-understand language explaining general information concerning how a provider may make a request to the QHP for QHP enrollee data using the standards-based Provider Access API, required under paragraph (a)(1) of this section, both for individual access and bulk data requests. (5) Out-of-network provider access. A QHP issuer on a Federally-facilitated Exchange cannot deny use of, or access to, the Provider Access API based on a provider’s contract status. (b) Coordination among payers at enrollment—Payer-to-Payer API. Subject to paragraph (d) of this section: (1) Accessible content and API requirements. Beginning January 1, 2023 a QHP issuer on a Federally-facilitated Exchange must make the standardsbased API specified at § 156.221(f)(2) conformant with the implementation specification at § 170.215(a)(4) of this subchapter to facilitate sharing the data specified at § 156.221(f)(2) relevant to one or more QHP enrollees at one time. (2) Requesting data exchange. (i) When an enrollee enrolls in a QHP on a Federally-facilitated Exchange, the QHP issuer may request the data from the previous payer through the standards-based API described in paragraph (b)(1) of this section, as permitted by the enrollee per paragraph (b)(5) of this section, and as permitted by applicable law. (ii) For any enrollees who enrolled in a QHP on a Federally-facilitated Exchange during the annual open enrollment period applicable to the VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 Federally-facilitated Exchange, the QHP issuer must request the specified data within one (1) week of the end of the enrollment period from any previous payers through the standards-based API described in paragraph (b)(1) of this section, as permitted by enrollees per paragraph (b)(5) of this section, and as permitted by applicable law; (iii) If a QHP issuer receives a request from another payer to make data available for one or more former enrollee who have enrolled with the new payer, the QHP issuer must respond by making the required data available via the standards-based API described in paragraph (b)(1) of this section within one (1) business day of receiving the request. (3) Previous or concurrent payer. A QHP issuer on a Federally-facilitated Exchange must maintain a process to obtain from a new QHP enrollee the name of the new QHP enrollee’s previous payer, and concurrent payer if the enrollee has coverage through more than one payer, to facilitate data sharing using the Payer-to-Payer API described in paragraph (b)(1) of this section. (4) Concurrent payer exchange. When a QHP enrollee has concurrent coverage with another payer also subject to HHS regulations on the Payer-to-Payer API, the QHP issuer on the Federallyfacilitated Exchange must make available to the other payer the data described at § 156.221(f)(2) through the standards-based API described in paragraph (b)(1) of this section quarterly. (5) Opt-in. A QHP issuer on a Federally-facilitated Exchange must put a process in place to allow an enrollee or the enrollee’s personal representative to opt-in to permit the QHP issuer to use the Payer-to-Payer API data sharing specified in paragraph (b)(1) of this section. (c) Obligations. The requirements under this section do not in any way alter or change a QHP issuer’s obligation as a HIPAA covered entity to comply with regulations regarding standard transactions at 45 CFR part 162. (d) Exception. (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraphs (a) or (b) of this section, the issuer must include as part of its QHP application a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of non-compliance upon enrollees, the current or proposed means of providing health information to providers and/or payers, and solutions and a timeline to achieve PO 00000 Frm 00097 Fmt 4701 Sfmt 4702 82681 compliance with the requirements of this section. (2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraphs (a) or (b) of this section if the Exchange determines that making such health plan available through such Exchange is in the interests of qualified individuals and qualified employers in the State or States in which such Exchange operates. ■ 28. Section 156.223 is added to read as follows: § 156.223 Documentation and prior authorization. (a) Requirements to support provider documentation discovery and to support prior authorization. Subject to paragraph (b) of this section: (1) Documentation Requirement Lookup Service (DRLS) Application Programming Interface (API). Beginning January 1, 2023, a QHP issuer on a Federally-facilitated Exchange must implement and maintain a standardsbased API compliant with § 156.221(c), (d), and (e): (i) That is populated with the QHP issuer’s list of covered items and services, not including prescription drugs, for which prior authorization is required, and with the QHP issuer’s documentation requirements for submitting a prior authorization request, including a description of the required documentation; and (ii) That is conformant with the implementation specifications at § 170.215(c)(1) and (2). (2) Prior Authorization Support API. Beginning January 1, 2023, a QHP issuer on a Federally-facilitated Exchange must implement and maintain a standards-based API compliant with § 156.221(c), (d), and (e): (i) That facilitates a HIPAA-compliant prior authorization request and response, including any other forms or medical record documentation required by the QHP issuer for the items or services for which the provider is seeking prior authorization, conformant with the requirements at § 172.110(a)(3) of this subchapter; (ii) That is conformant with the implementation specification at § 170.215(c)(3) of this subchapter; and (iii) That includes in the response whether the QHP issuer approves (and for how long), denies, or requests more information related to the prior authorization request, along with a standard denial reason code in the case of denial; (iv) A QHP issuer on a Federallyfacilitated Exchange must include a specific reason for a denial in the case of a denial with all prior authorization E:\FR\FM\18DEP2.SGM 18DEP2 khammond on DSKJM1Z7X2PROD with PROPOSALS2 82682 Federal Register / Vol. 85, No. 244 / Friday, December 18, 2020 / Proposed Rules decisions, regardless of the method used to send the prior authorization decision. (3) Public reporting of prior authorization metrics. Beginning March 31, 2023, a QHP issuer on a Federallyfacilitated Exchange must make the following information about the issuer level prior authorization decisions specified, publicly accessible by posting directly on its website or via publicly accessible hyperlink(s), annually by the end of the first calendar quarter, data for the prior calendar year: (i) A list of all items and services, not including prescription drugs, that require prior authorization; (ii) The percentage of standard prior authorization requests that were approved, reported separately for items and services, not including prescription drugs; (iii) The percentage of standard prior authorization requests that were denied, reported separately for items and services, not including prescription drugs; (iv) The percentage of standard prior authorization requests that were approved after appeal, reported separately for items and services, not including prescription drugs; (v) The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, reported separately for items and services, not including prescription drugs; (vi) The percentage of expedited prior authorization requests that were approved, reported separately for items and services, not including prescription drugs; and (vii) The average and median time that elapsed between the submission of a request and a determination by the issuer, for standard prior authorizations, reported separately for items and services, not including prescription drugs. (b) Exception. (1) If a plan applying for QHP certification to be offered through a Federally-facilitated Exchange believes it cannot satisfy the requirements in paragraph (a)(1) and/or (a)(2) of this section, the issuer must include as part of its QHP application a narrative justification describing the reasons why the plan cannot reasonably satisfy the requirements for the applicable plan year, the impact of noncompliance upon enrollees, the current or proposed means of providing health information to providers, and solutions and a timeline to achieve compliance with the requirements of this section. (2) The Federally-facilitated Exchange may grant an exception to the requirements in paragraph (a) of this section if the Exchange determines that VerDate Sep<11>2014 22:30 Dec 17, 2020 Jkt 253001 making such health plan available through such Exchange is in the interests of qualified individuals and qualified employers in the State or States in which such Exchange operates. PART 170—HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY 29. The authority citation for part 170 continues to read as follows: ■ Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 552. 30. Section 170.215 is amended— a. By revising the section heading; b. In paragraph (a), by adding a paragraph heading; ■ c. In paragraph (b), by revising the paragraph heading; and ■ d. By adding paragraph (c). The revisions and additions read as follows: ■ ■ ■ § 170.215 Application Programming Interface Standards and Implementation Specifications. * * * * * (a) Base Standard and Implementation Specifications. * * * * * * * * (b) Security Standard. * * * (c) Standards and Implementation Specifications for Health Care Operations. (1) Prior authorization implementation specification. HL7 FHIR Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide: Version STU 1.0.0 (incorporated by reference in § 170.299). (2) Prior authorization implementation specification. HL7 FHIR Da Vinci—Documentation Templates and Rules (DTR) Implementation Guide: Version STU 1.0.0 (incorporated by reference in § 170.299). (3) Prior authorization implementation specification. HL7 FHIR Da Vinci—Prior Authorization Support (PAS) Implementation Guide: Version STU 1.0.0 (incorporated by reference in § 170.299). (4) Payer data implementation specification. HL7 FHIR Da Vinci— Payer Coverage Decision Exchange (PCDE) Implementation Guide: Version STU 1.0.0 (incorporated by reference in § 170.299). (5) Payer data implementation specification. HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide: Version STU 1.0.0 (incorporated by reference in § 170.299). PO 00000 Frm 00098 Fmt 4701 Sfmt 9990 (6) Payer data implementation specification. HL7 FHIR Da Vinci Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0 (incorporated by reference in § 170.299). (7) Payer data implementation specification. HL7 FHIR Da Vinci— Payer Data Exchange (PDex) US Drug Formulary Implementation Guide: Version STU 1.0.1 (incorporated by reference in § 170.299). (8) Provider directory implementation specification. HL7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide: Version STU 1.0.0 (incorporated by reference in § 170.299). ■ 31. Section 170.299 is amended by adding paragraphs (f)(35) through (42) to read as follows: § 170.299 Incorporation by reference. * * * * * (f) * * * (35) HL7 FHIR® Da Vinci—Coverage Requirements Discovery (CRD) Implementation Guide, Version STU 1.0.0, IBR approved for § 170.215(c). (36) HL7 FHIR® Da Vinci— Documentation Templates and Rules (DTR) Implementation Guide, Version STU 1.0.0, IBR approved for § 170.215(c). (37) HL7 FHIR® Da Vinci—Prior Authorization Support (PAS) Implementation Guide, Version STU 1.0.0, IBR approved for § 170.215(c). (38) HL7 FHIR® Da Vinci—Payer Coverage Decision Exchange (PCDE) Implementation Guide, Version STU 1.0.0, IBR approved for § 170.215(c). (39) HL7 FHIR® Consumer Directed Payer Data Exchange (CARIN IG for Blue Button®) Implementation Guide, Version STU 1.0.0, IBR approved for § 170.215(c). (40) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Implementation Guide, Version STU 1.0.0, IBR approved for § 170.215(c). (41) HL7 FHIR® Da Vinci—Payer Data Exchange (PDex) US Drug Formulary Implementation Guide, Version STU 1.0.1, IBR approved for § 170.215(c). (42) HL7 FHIR® Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide, Version STU 1.0.0, IBR approved for § 170.215(c). * * * * * Dated: December 2, 2020. Seema Verma, Administrator, Centers for Medicare & Medicaid Services. Dated: December 10, 2020. Alex M. Azar II, Secretary, Department of Health and Human Services. [FR Doc. 2020–27593 Filed 12–14–20; 11:15 am] BILLING CODE 4120–01–P E:\FR\FM\18DEP2.SGM 18DEP2

Agencies

[Federal Register Volume 85, Number 244 (Friday, December 18, 2020)]
[Proposed Rules]
[Pages 82586-82682]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2020-27593]

[[Page 82585]]

Vol. 85

Friday,

No. 244

December 18, 2020

Part II

Department of Health and Human Services

-----------------------------------------------------------------------

Centers for Medicare & Medicaid Services

-----------------------------------------------------------------------

42 CFR Parts 431, 435, 438, et al.

45 CFR Parts 156 and 170

Medicaid Program; Patient Protection and Affordable Care Act; Reducing
Provider and Patient Burden by Improving Prior Authorization Processes,
and Promoting Patients' Electronic Access to Health Information for
Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and
CHIP Managed Care Entities, and Issuers of Qualified Health Plans on
the Federally-Facilitated Exchanges; Health Information Technology
Standards and Implementation Specifications; Proposed Rule

Federal Register / Vol. 85 , No. 244 / Friday, December 18, 2020 /
Proposed Rules

[[Page 82586]]

-----------------------------------------------------------------------

DEPARTMENT OF HEALTH AND HUMAN SERVICES

Centers for Medicare & Medicaid Services

42 CFR Parts 431, 435, 438, 440, and 457

Office of the Secretary

45 CFR Parts 156 and 170

[CMS-9123-P]
RIN 0938-AT99

Medicaid Program; Patient Protection and Affordable Care Act;
Reducing Provider and Patient Burden by Improving Prior Authorization
Processes, and Promoting Patients' Electronic Access to Health
Information for Medicaid Managed Care Plans, State Medicaid Agencies,
CHIP Agencies and CHIP Managed Care Entities, and Issuers of Qualified
Health Plans on the Federally-Facilitated Exchanges; Health Information
Technology Standards and Implementation Specifications

AGENCY: Centers for Medicare & Medicaid Services (CMS), HHS; Office of
the National Coordinator for Health Information Technology (ONC), HHS.

ACTION: Proposed rule.

-----------------------------------------------------------------------

SUMMARY: This proposed rule would place new requirements on state
Medicaid and CHIP fee-for-service (FFS) programs, Medicaid managed care
plans, CHIP managed care entities, and Qualified Health Plan (QHP)
issuers on the Federally-facilitated Exchanges (FFEs) to improve the
electronic exchange of health care data, and streamline processes
related to prior authorization, while continuing CMS' drive toward
interoperability, and reducing burden in the health care market. In
addition, on behalf of the Department of Health and Human Service
(HHS), the Office of the National Coordinator for Health Information
Technology (ONC) is proposing the adoption of certain specified
implementation guides (IGs) needed to support the proposed Application
Programming Interface (API) policies included in this rule. Each of
these elements plays a key role in reducing overall payer and provider
burden and improving patient access to health information.

DATES: To be assured consideration, comments must be received at one of
the addresses provided below, no later than 5 p.m. on January 4, 2021.

ADDRESSES: In commenting, please refer to file code CMS-9123-P.
Comments, including mass comment submissions, must be submitted in
one of the following three ways (please choose only one of the ways
listed):
1. Electronically. You may submit electronic comments on this
regulation to https://www.regulations.gov. Follow the ``Submit a
comment'' instructions.
2. By regular mail. You may mail written comments to the following
address ONLY: Centers for Medicare & Medicaid Services, Department of
Health and Human Services, Attention: CMS-9123-P, P.O. Box 8016,
Baltimore, MD 21244-8016.
Please allow sufficient time for mailed comments to be received
before the close of the comment period.
3. By express or overnight mail. You may send written comments to
the following address ONLY: Centers for Medicare & Medicaid Services,
Department of Health and Human Services, Attention: CMS-9123-P, Mail
Stop C4-26-05, 7500 Security Boulevard, Baltimore, MD 21244-1850.
For information on viewing public comments, see the beginning of
the SUPPLEMENTARY INFORMATION section.

FOR FURTHER INFORMATION CONTACT:
Alexandra Mugge, (410) 786-4457, for general issues related to this
rule and CMS interoperability initiatives.
Denise St. Clair, (410) 786-4599, for the API policies,
implementation guides (IGs), general issues related to this rule, and
CMS interoperability initiatives.
Lorraine Doo, (443) 615-1309, for prior authorization process
policies and CMS interoperability initiatives.
Amy Gentile, (410) 786-3499, for issues related to Medicaid managed
care.
Kirsten Jensen, (410) 786-8146, for issues related to Medicaid fee
for service (FFS).
Cassandra Lagorio, (410) 786-4554, for issues related to the
Children's Health Insurance Program (CHIP).
Russell Hendel, (410) 786-0329, for issues related to the
Collection of Information and Regulatory Impact Analysis.
Rebecca Zimmermann, (301) 492-4396, for issues related to Qualified
Health Plans (QHPs).

SUPPLEMENTARY INFORMATION:
Inspection of Public Comments: All comments received before the
close of the comment period are available for viewing by the public,
including any personally identifiable or confidential business
information that is included in a comment. We post all comments
received before the close of the comment period on the following
website as soon as possible after they have been received: https://www.regulations.gov. Follow the search instructions on that website to
view public comments. CMS will not post on Regulations.gov public
comments that make threats to individuals or institutions or suggest
that the individual will take actions to harm the individual. CMS
continues to encourage individuals not to submit duplicative comments.
We will post acceptable comments from multiple unique commenters even
if the content is identical or nearly identical to other comments.

Table of Contents

I. Background and Summary of Provisions
A. Purpose
B. Summary of Major Proposals
II. Provisions of the Proposed Rule
A. Patient Access API
B. Provider Access APIs
C. Documentation and Prior Authorization Burden Reduction
Through APIs
D. Payer-to Payer Data Exchange on FHIR
E. Adoption of Health IT Standards and Implementation
Specifications
III. Requests for Information
A. Request for Information: Methods for Enabling Patients and
Providers to Control Sharing of Health Information
B. Request for Information: Electronic Exchange of Behavioral
Health Information
C. Request for Information: Reducing Burden and Improving
Electronic Information Exchange of Prior Authorization
D. Request for Information: Reducing the Use of Fax Machines
E. Request for Information: Accelerating the Adoption of
Standards Related to Social Risk Data
IV. Incorporation by Reference
V. Collection of Information
VI. Response to Comments
VII. Regulatory Impact Analysis
Regulations Text

I. Background and Summary of Provisions

A. Purpose

In the May 1, 2020 Federal Register, we published the first phase
of CMS interoperability rulemaking in the ``Medicare and Medicaid
Programs; Patient Protection and Affordable Care Act; Interoperability
and Patient Access for Medicare Advantage Organization and Medicaid
Managed Care Plans, state Medicaid Agencies, CHIP Agencies and CHIP
Managed Care Entities, Issuers of Qualified Health Plans on the
Federally-facilitated Exchanges and Health Care Providers'' final rule
(85 FR 25510) (hereinafter referred to as the ``CMS Interoperability
and Patient Access final rule'').
This proposed rule emphasizes improving health information exchange

[[Page 82587]]

and achieving appropriate and necessary access to complete health
records for patients, providers, and payers, while simultaneously
reducing payer, provider, and patient burden by improving prior
authorization processes, and helping to ensure that patients remain at
the center of their own care. In this rule, we are proposing to enhance
certain policies from the CMS Interoperability and Patient Access final
rule, as described below, and add several new proposals to increase
data sharing and reduce overall payer, provider, and patient burden
through proposed changes to prior authorization practices. ``Prior
authorization'' refers to the process through which a provider must
obtain approval from a payer before providing care and prior to
receiving payment for delivering items or services. In some programs,
this may be referred to as ``pre-authorization'' or ``pre-claim
review.'' Prior authorization requirements are established by payers to
help control costs and ensure payment accuracy by verifying that an
item or service is medically necessary, meets coverage criteria, and is
consistent with standards of care before the item or service is
provided rather than undertaking that review for the first time when a
post-service request for payment is made.
We are taking an active approach to move participants in the health
care market toward interoperability and reduced burden by proposing
policies for the Medicaid program; the Children's Health Insurance
Program (CHIP); and qualified health plan (QHP) issuers on the
individual market Federally-facilitated Exchanges (FFEs).
For purposes of this proposed rule, references to QHP issuers on
the FFEs exclude issuers offering only stand-alone dental plans
(SADPs). Likewise, we are also excluding QHP issuers only offering QHPs
in the Federally-facilitated Small Business Health Options Program
Exchanges (FF-SHOPs) from the proposed provisions of this rule. We
believe that the proposed standards would be overly burdensome to both
SADP and SHOP issuers, as their current enrollment numbers and premium
intake from QHP enrollment are unlikely to support the costs of the
requirements that this proposed rule would impose, and could result in
those issuers no longer participating in the FFEs, which would not be
in the best interest of enrollees. We note that, in this proposed rule,
FFEs include those Exchanges in states that perform plan management
functions. State-based Exchanges on the Federal Platform (SBE-FPs) are
not FFEs, even though consumers in these states enroll in coverage
through HealthCare.gov, and QHP issuers in SBE-FPs would not be subject
to the requirements in this proposed rule. We encourage states
operating Exchanges to consider adopting similar requirements for QHPs
on the State-based Exchanges (SBEs).
In the CMS Interoperability and Patient Access final rule (85 FR
25510), we finalized policies impacting Medicare Advantage
organizations, state Medicaid and CHIP FFS programs, Medicaid managed
care plans, CHIP managed care entities, and QHP issuers on the FFEs.
The policies finalized in that rule requiring those impacted payers to
build and maintain application programing interfaces (APIs) were
critical and foundational policies, increasing patient access and data
exchange and improving interoperability in health care. In this
proposed rule, we are proposing certain policies to expand upon those
foundational policies for state Medicaid and CHIP FFS programs,
Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs. As further addressed later in this section of the
preamble, starting with this payer population is a critical first step
for these new proposals. For instance, state Medicaid and CHIP FFS
programs were excluded from the payer-to-payer data exchange policies
finalized in the CMS Interoperability and Patient Access final rule (85
FR 25564 through 25569). In our first phase of interoperability policy,
we chose to limit the burden on these programs so they could focus
their attention and resources on implementing the Patient Access and
Provider Directory APIs. This proposed rule is a critical step in
proposing to require state Medicaid and CHIP FFS programs to similarly
exchange patient health information in a more efficient and
interoperable way, as discussed in section II.D. of this proposed rule,
leveraging the technology and experience gained from implementing the
initial set of API policies to these new proposed policies.
``Churn'' in health care refers to the movement of patients between
payers and in and out of health care coverage. Churn occurs when a
patient moves between payer types and plans or dis-enrolls from
coverage (voluntarily or involuntarily) for a period of time. Patients
enrolled in Medicaid, CHIP, and QHPs in particular may move between and
among these payers due to a change in their eligibility status, or a
change in the availability of subsidies in the case of QHP enrollees.
Medicaid beneficiaries who churn in and out of Medicaid tend to have
higher utilization of emergency services. Overall, these patients face
more coverage instability than those enrolled in Medicare. Several of
the API proposals outlined in this proposed rule would particularly
benefit patients enrolled in Medicaid, CHIP, and QHPs by allowing them
to retain their health information in an electronic form, and have
their health information move with them from payer to payer and
provider to provider.
Our authority to regulate Medicaid and CHIP FFS, Medicaid and CHIP
managed care, and QHP issuers on the FFEs puts us in a unique position
to be able to align policies across these programs to the benefit of
patients across the nation. Patients enrolled in these programs may
churn from payer to payer within a given program, as well as from
program to program. For example, a Medicaid enrollee may change
eligibility status for Medicaid and enroll with a QHP issuer and back
in a given year. For this reason, our API proposals discussed in the
following sections are particularly valuable because they allow
patients to maintain an electronic copy of their health information
(Patient Access API discussed in section II.A.), share data directly
with their providers (Provider Access API discussed in section II.B. of
this proposed rule), and to bring their health information with them as
they move from one payer to another (Payer-to-Payer API discussed in
section II.D.), which is especially valuable to patients covered by
Medicaid and QHPs who experience churn both within and between
programs, and may also experience churn in and out of coverage.
While we are not making any proposals for MA organizations at this
time, we acknowledge that payers with multiple lines of business may
choose to implement these polices for their MA lines of business to
support better internal alignment as well as to create more
efficiencies and transparency for their patients. Neither the
provisions in the CMS Interoperability and Patient Access final rule
nor the proposed provisions here would preclude any payer from
implementing these proposed policies regardless of whether the payer is
directly impacted by the rule. We believe aligning these policies
across all payers would benefit all payers alike. However, we do not
believe our approach to start with state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs will have a negative impact on patients. We
believe these policies would provide a net benefit to these patients,
bringing these programs closer in alignment with one another. We are
aware that these proposals, if finalized,

[[Page 82588]]

would create misalignments between Medicaid and Medicare that could
affect dually eligible individuals enrolled in both a Medicaid managed
care plan and an MA plan. While we currently do not believe it is
necessary to apply these policies to Medicare Advantage organizations
at this time, we intend to further evaluate the implementation of these
policies to determine whether they would also be appropriate to apply
to Medicare Advantage organizations for future rulemaking. In this
proposed rule, when we refer to ``impacted payers,'' we are referring
to state Medicaid and CHIP FFS programs, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs.
Throughout this proposed rule, we refer to terms such as
``patient'', ``consumer'', ``beneficiary'', ``enrollee'', and
``individual.'' We note that every reader of this proposed rule is a
patient and has or will receive medical care at some point in their
life. In this proposed rule, we use the term ``patient'' as an
inclusive term, but because we have historically referred to patients
using the other terms noted above in our regulations, we use specific
terms as applicable in sections of this proposed rule to refer to
individuals covered under the health care programs that we administer
and regulate. We also note that when we discuss patients, the term
includes a patient's personal representative. Per the privacy
regulations issued under the Health Insurance Portability and
Accountability Act of 1996 (HIPAA) (Pub. L. 104-191, enacted on August
21, 1996), as modified, at 45 CFR 164.502(g), a personal
representative, generally, is someone authorized under state or other
applicable law to act on behalf of the individual in making health
care-related decisions (such as a parent, guardian, or person with a
medical power of attorney).\1\ A patient's personal representative
could address policies in this proposed rule that require a patient's
action.
---------------------------------------------------------------------------

\1\ See OCR guidance regarding personal representatives at
https://www.hhs.gov/hipaa/for-professionals/faq/2069/under-hipaa-when-can-a-family-member/ and https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/.
---------------------------------------------------------------------------

We also use terms such as ``payer'', ``plan'', and ``issuer'' in
this proposed rule. Certain portions of this proposed rule are
applicable to state Medicaid FFS programs, state CHIP FFS programs,
Medicaid managed care plans (managed care organizations (MCOs)),
prepaid inpatient health plans (PIHPs), and prepaid ambulatory health
plans (PAHPs)), CHIP managed care entities (MCOs, PIHPs, and PAHPs),
and QHP issuers on the FFEs. We use the term ``payer'' in the preamble
of this proposed rule as an inclusive term for all these programs and
(in the case of plans) plan types, but we also use specific terms as
applicable in sections of this proposed rule.
We reference ``items and services'' when discussing prior
authorization. Throughout this proposed rule, when we discuss ``items
and services,'' this does not include prescription drugs and/or covered
outpatient drugs. We did not include information about prescription
drugs and/or covered outpatient drugs in any of the proposals in this
rule.
Finally, we use the terms ``provider'' and ``supplier'' too, as
inclusive terms comprising individuals, organizations, and institutions
that provide health services, such as clinicians, hospitals, skilled
nursing facilities, home health agencies, hospice settings,
laboratories, suppliers of durable medical equipment (such as portable
X-ray services), community based organizations, etc., as appropriate in
the context used.

B. Summary of Major Proposals

To drive interoperability, improve care coordination, reduce burden
on providers and payers, and empower patients, we are proposing several
initiatives that would impact state Medicaid FFS programs, Medicaid
managed care plans, state CHIP FFS programs, CHIP managed care
entities, and QHP issuers on the FFEs. We are also including several
Requests for Information (RFIs) to gather information that may support
future rulemaking or other initiatives. As with the CMS
Interoperability and Patient Access rulemaking, our proposals provide
for program requirements to cross-reference technical specifications in
HHS regulations codified at 45 CFR part 170; in this rule, ONC is
proposing the adoption of certain specified implementation guides (IGs)
needed to support the proposed new API policies we are proposing here
for impacted payers.
In the CMS Interoperability and Patient Access final rule, we
required certain payers to implement and maintain standards-based
Patient Access and Provider Directory application programming
interfaces (APIs).\2\ The Patient Access API must allow patients to
easily access their claims and encounter information and a specified
sub-set of their clinical information as defined in the US Core for
Data Interoperability (USCDI) version 1 data set through third-party
applications of their choice (85 FR 25558 through 25559). The Provider
Directory API must make provider directory information publicly
available to third-party applications (85 FR 25563 through 25564).
Additionally, in the same final rule we required certain payers, with
the approval and at the direction of a patient, to exchange specified
clinical data (specifically the USCDI version 1 data set) through a
Payer-to-Payer Data Exchange (85 FR 25568 through 25569).
---------------------------------------------------------------------------

\2\ Impacted payers under that rule include MA organizations,
state Medicaid FFS programs, Medicaid managed care plans, state CHIP
FFS programs, CHIP managed care entities, and QHP issuers on the
FFEs for the Patient Access API. The Provider Directory API
requirement applies to all those impacted payers except the QHP
issuers on the FFEs. The Payer-to-Payer Data Exchange applies to all
those impacted payers except state Medicaid and CHIP FFS programs.
---------------------------------------------------------------------------

In this proposed rule, we are proposing to enhance the Patient
Access API for impacted payers by requiring the use of specific IGs,
proposed for adoption by ONC on behalf of HHS, and by proposing payers
include information about pending and active prior authorization
decisions. In addition, we are proposing to require that impacted
payers establish, implement, and maintain a process to facilitate
requesting an attestation from a third-party app developer requesting
to retrieve data via the Patient Access API that indicates the app
adheres to certain privacy provisions. We are also proposing to require
these impacted payers to report certain metrics about patient data
requests via the Patient Access API quarterly to CMS. In addition, we
are proposing to require use of a specific IG for the Provider
Directory API. And, we are proposing to extend the patient-initiated
Payer-to-Payer Data Exchange requirements to state Medicaid and CHIP
FFS programs.
We also propose to enhance and expand the Payer-to-Payer Data
Exchange, and to require this exchange be conducted via a specified
Health Level Seven International[supreg] (HL7) Fast Healthcare
Interoperability Resources[supreg] (FHIR)-based API. We are proposing
that impacted payers must implement and maintain a Payer-to-Payer API
to facilitate the exchange of patient information between impacted
payers, both with the approval and at the direction of the patient and
when a patient moves from one payer to another as permitted, and in
accordance with applicable law. Specifically, we are proposing that
impacted payers implement the Payer-to-Payer API in accordance with the
specified HL7 FHIR version 4.0.1 IGs, as well as the HL7

[[Page 82589]]

FHIR Bulk Data Access (Flat FHIR) specification, to support exchanging
patient data including but not limited to: Adjudicated claims and
encounter data (not including cost information), clinical data as
defined in the USCDI, and information related to pending and active
prior authorization decisions.
To better facilitate the coordination of care across the care
continuum and in support of a move to value-based care, we are
proposing to require that impacted payers implement and maintain a
Provider Access API that, consistent with the APIs finalized in the
Interoperability and Patient Access final rule (85 FR 25510), utilizes
HL7 FHIR version 4.0.1 to facilitate the exchange of current patient
data from payers to providers, including adjudicated claims and
encounter data (not including cost information), clinical data as
defined in the USCDI, and information related to pending and active
prior authorization decisions.
In an effort to improve patient experience and access to care, we
are proposing several policies associated with the prior authorization
process that may ultimately reduce burden on patients, providers, and
payers. As described in the CMS Interoperability and Patient Access
proposed rule published on March 4, 2019 (84 FR 7610, 7613), we
partnered with industry stakeholders to build a FHIR-based web service
that would enable providers to search documentation and prior
authorization requirements for Medicare FFS directly from their
electronic health records (EHRs). This has significant potential to
decrease the burden associated with providers determining which items
and services need a prior authorization and what documentation is
needed to submit the prior authorization request. And, this could
reduce burden on payers who would receive fewer incomplete prior
authorization requests and fewer denied and appealed requests simply as
the result of missing or incorrect documentation. In this second phase
of interoperability proposals, we are proposing to require impacted
payers to implement and maintain a similar prior authorization
Documentation Requirement Lookup Service (DRLS) API. To further
streamline the process of submitting a prior authorization request, and
reduce processing burden on both providers and payers, we are also
proposing to require impacted payers to implement and maintain a FHIR-
based Prior Authorization Support (PAS) API that would have the
capability to accept and send prior authorization requests and
decisions, and could be integrated within a provider's workflow, while
maintaining alignment with, and facilitating the use of, HIPAA
transaction standards. Provider use of the PAS API would be voluntary
and payers may maintain their existing methods for processing prior
authorization requests.
We are also proposing several policies that would require impacted
payers, with the exception of QHP issuers on the FFEs, to respond to
prior authorization requests within certain timeframes. And, we are
proposing that impacted payers publicly report certain metrics about
prior authorization processes for transparency.
Finally, on behalf of HHS, the Office of the National Coordinator
for Health IT (ONC) is proposing to adopt the implementation
specifications described in this regulation at 45 CFR 170.215--
Application Programming Interfaces--Standards and Implementation
Specifications as standards and implementation specifications for
health care operations. ONC is proposing these implementation
specifications for adoption by HHS as part of a nationwide health
information technology infrastructure that supports reducing burden and
health care costs and improving patient care. By ONC proposing these
implementation specifications in this way, CMS and ONC are together
working to ensure a unified approach to advancing standards in HHS that
adopts all interoperability standards in a consistent manner, in one
location, for HHS use. Once adopted for HHS use, these specifications
would facilitate implementation of the proposed API policies in this
rule if finalized.
Although Medicare FFS is not directly impacted by this rule, we do
note that we are targeting to implement these proposed provisions, if
finalized. In this way, the Medicare implementations would conform to
the same requirements that apply to the impacted payers under this
rulemaking, as applicable, so that Medicare FFS beneficiaries would
also benefit. And, we encourage other payers not directly impacted by
this rule to join us in moving toward reduced burden and greater
interoperability.
We are also including several RFIs to gather information that may
support future rulemaking or other initiatives. Specifically, we are
seeking input for potential future rulemaking on whether patients and
providers should have the ability to selectively control the sharing of
data in an interoperable landscape. We request comment on whether
patients and/or providers should be able to dictate which data elements
from a medical record are shared when and with whom.
We are additionally seeking comment on how CMS might leverage APIs
(or other solutions) to facilitate electronic data exchange between and
with behavioral health care providers, and also community based
organizations, who have lagged behind other provider types in adoption
of EHRs.
We are also seeking comment on how to reduce barriers, and actively
encourage and enable greater use of electronic prior authorization,
particularly among providers who could benefit most by being able to
engage in the prior authorization process directly from their
workflows. And, we request comment specifically on including an
Improvement Activity under the Merit-based Incentive Payment System
(MIPS) to support the use of the Prior Authorization Support (PAS) API.
We are continually looking for ways to facilitate efficient,
effective, and secure electronic data exchange to help ensure timely,
better quality, and highly coordinated care. We believe one way to do
this is to generally reduce or eliminate the use of facsimile (fax)
technology across CMS programs, as possible and appropriate. The use of
fax technology limits the ability of the health care sector to reach
true interoperability. To work toward this goal and enable electronic
data exchange, we request information on how CMS can reduce or
eliminate the use of fax technology across programs where fax
technology is still in use.
Finally, we request information on barriers to adopting standards,
and opportunities to accelerate adoption of standards, related to
social risk data. We recognize that social risk factors (for example,
housing instability and food insecurity) influence patient health and
health care utilization. In addition, we understand that providers in
value-based arrangements rely on comprehensive, high-quality social
risk data. Given the importance of these data, we look to understand
how to better standardize and liberate these data.

II. Provisions of the Proposed Rule

A. Patient Access API

1. Background
Claims and encounter data, used in conjunction with clinical data,
can offer a more complete picture of an individual's health care
experience. In the CMS Interoperability and Patient Access final rule
(85 FR 25523), we noted examples of how claims data can be used to
benefit patients, as well as providers. For example, inconsistent

[[Page 82590]]

benefit utilization patterns in an individual's claims data, such as a
failure to fill a prescription or receive recommended therapies, can
indicate to a provider or a payer that the individual has had
difficulty financing a treatment regimen, may require less expensive
prescription drugs or therapies, or may need additional explanation
about the severity of their condition. Claims data can also include
other information that could be used to understand care utilization and
create opportunities for future services or care coordination or
management. These are a few examples of how access to these data can
improve patient care.
Patients tend to access care from multiple providers throughout
their lifetime, leading to fractured patient health records in which
various pieces of an individual's data are locked in disparate, siloed
data systems. With patient data scattered among these segregated
systems, it can be challenging for providers to get a clear picture of
the patient's care history, and patients may forget or be unable to
provide critical information to their provider during an office visit.
This lack of comprehensive patient data can impede care coordination
efforts and access to appropriate care. Through the FHIR-based Patient
Access API, finalized in the CMS Interoperability and Patient Access
final rule (85 FR 25558 through 25559), we required certain impacted
payers to share, among other things, patient claims and encounter data
and a sub-set of clinical data with the third-party apps of a patient's
choice so that patients could get their health information in a way
that was most meaningful and useful to them. We noted that this FHIR-
based API could also allow the patient to facilitate their data moving
from their payer to their provider, and discussed the benefits of
sharing patient claims and encounter data with providers, which we
discuss in more detail in section II.B. of this proposed rule.
2. Enhancing the Patient Access API
In the CMS Interoperability and Patient Access final rule that
certain payers, specifically MA organizations, state Medicaid and CHIP
FFS programs, Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs, must permit third-party applications to
retrieve, with the approval and at the direction of a current enrollee,
data specified at 42 CFR 422.119, 431.60, 457.730, and 45 CFR 156.221,
respectively. We required that the Patient Access API must, at a
minimum, make available adjudicated claims (including provider
remittances and enrollee cost-sharing); encounters with capitated
providers; and clinical data, including laboratory results when
maintained by the payer. We required that data must be made available
no later than one (1) business day after a claim is adjudicated or
encounter data are received. And, that these payers make available
through the Patient Access API the specified data they maintain with a
date of service on or after January 1, 2016.
a. Patient Access API Implementation Guides (IGs)
When we finalized the Patient Access API, we provided a link to a
CMS website that identified IGs and related reference implementations
demonstrating use of these IGs available to support implementation (85
FR 25529): https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index. On this website, we provide links and
information about certain IGs, including:
HL7 Consumer Directed Payer Data Exchange (CARIN IG for
Blue Button[supreg]) IG: Version STU 1.0.0 to facilitate the exchange
of the claims and encounter data; \3\
---------------------------------------------------------------------------

\3\ HL7 International. (n.d.). Consumer Directed Payer Data
Exchange (CARIN IG for Blue Button[supreg]) Implementation Guide
Publication (Version) History. Retrieved from https://hl7.org/fhir/us/carin-bb/history.html.
---------------------------------------------------------------------------

HL7 FHIR US Core IG: Version STU 3.1.0 or HL7 FHIR Da
Vinci Payer Data Exchange (PDex) IG: Version STU 1.0.0 to facilitate
the exchange of the clinical information as defined in the USCDI;
^{4 5} and
---------------------------------------------------------------------------

\4\ HL7 International. (n.d.). US Core Implementation Guide
(FHIR IG) Publication (Version) History. Retrieved from https://hl7.org/fhir/us/core/history.html.
\5\ HL7 International. (n.d.). Da Vinci Payer Data Exchange
(FHIR IG) Publication (Version) History. Retrieved from https://hl7.org/fhir/us/davinci-pdex/history.html.
---------------------------------------------------------------------------

HL7 FHIR Da Vinci Payer Data Exchange (PDex) US Drug
Formulary IG: Version STU 1.0.1 to facilitate the exchange of current
formulary information.\6\
---------------------------------------------------------------------------

\6\ HL7 International. (n.d.). US Drug Formulary (FHIR IG)
Publication (Version) History. Retrieved from https://hl7.org/fhir/us/Davinci-drug-formulary/history.html.
---------------------------------------------------------------------------

On this website, we explain how these IGs can help payers meet the
requirements of the final rule efficiently and effectively in a way
that reduces burden on them and ensures patients are getting timely
access to their health information in a way that they can best make use
of these data so that they can make informed decisions about their
health. Although these IGs were available for payers and third-party
app vendors, we did not require payers to use these IGs in the CMS
Interoperability and Patient Access final rule. We did not specifically
propose these IGs for possible finalizing in the final rule as general
practice had been to include such information in sub-regulatory
guidance. However, the June 3, 2019 Azar v. Allina Health Services, 139
S. Ct. 1804 (2019) decision held that under section 1871 of the Act,
CMS must undertake notice-and-comment rulemaking for any rule,
requirement, or other statement of policy that establishes or changes a
``substantive legal standard'' for the Medicare Program. IGs are
considered a ``substantive legal standard'' per this decision. As such,
we are now officially proposing to finalize these IGs through notice-
and-comment rulemaking to ensure that all impacted payers are using
these IGs in order to support true interoperability. If these IGs
remain optional, there is a chance that the required APIs could be
built in such a way that creates misalignment between and among payer
APIs and with third-party apps. For example, where there is optionality
in the technical build of the API, if that optionality is interpreted
differently by the payer and a third-party app, that app may be unable
to access and use the data as needed. By removing this optionality in
the technical implementation, we better ensure that the APIs can
support true interoperability and facilitate the desired data exchange.
Additionally, as these same IGs are proposed for use for other APIs
proposed in this rule, it would mean that providers (see section II.B.
of this proposed rule) and payers (see section II.D. of this proposed
rule) would also not be able to access and use the data as needed if
misalignment is introduced during implementation. Proposing these IGs
be required removes the current optionality resulting from only
suggested use of the IGs, which could be a barrier to interoperability.
We are proposing to require these specific IGs for the Patient
Access API, by amending 42 CFR 431.60(c)(3)(iii) for state Medicaid FFS
programs, 42 CFR 457.730(c)(3)(iii) for state CHIP FFS programs, and 45
CFR 156.221(c)(3)(iii) for QHP issuers on the FFEs. These requirements
would be equally applicable to Medicaid managed care plans and CHIP
managed care entities based on cross-references to the state Medicaid
and CHIP FFS requirements at 42 CFR 438.242(b)(5) for Medicaid managed
care plans and 42 CFR 457.1233(d)(2) for CHIP managed care entities. If
finalized, beginning January 1, 2023, impacted payers would be required
to ensure their APIs are

[[Page 82591]]

conformant with these IGs (for Medicaid managed care plans and CHIP
managed care entities, by the rating period beginning on or after
January 1, 2023). The CARIN IG for Blue Button, the PDex IG, and the
PDex US Drug Formulary IG are proposed for HHS use at 45 CFR
170.215(c). The US Core IG was adopted by HHS at 45 CFR 170.215(a)(2)
in the ONC 21st Century Cures Act final rule.
We recognize that while we have proposed to require compliance with
the specific IGs noted above, the need for continually evolving IGs
typically outpaces our ability to amend regulatory text. Therefore, we
propose to amend 431.60(c)(4), 438.242(b)(5), 457.730(c)(4),
457.1233(d)(2), and 45 CFR 156.221(c)(4) to provide that, if finalized,
regulated entities would be permitted to use an updated version of any
or all IGs proposed for adoption in this rule if use of the updated IG
does not disrupt an end user's ability to access the data through any
of the specified APIs discussed in this rule. This would then amend the
process to allow payers to use new standards as they are available, as
we finalized in the CMS Interoperability and Patient Access final rule
to these proposed IGs.
In making these proposals, we note that these IGs are publicly
available at no cost to a user (see section IV. of this proposed rule
for more information). All HL7 FHIR IGs are developed through an
industry-led, consensus-based public process. HL7 is an American
National Standards Institute (ANSI)-accredited standards development
organization. HL7 FHIR standards are unique in their ability to allow
disparate systems that otherwise represent data differently and speak
different languages to exchange such information in a standardized way
that all systems can share and consume via standards-based APIs. HL7
FHIR IGs are also open source, so any interested party can go to the
HL7 website and access the IG. Once accessed, all public comments made
during the balloting process as well as the IG version history are
available for review. In this way, all stakeholders can fully
understand the lifecycle of a given IG. Use of IGs developed through
such a public process would facilitate a transparent and cost-effective
path to interoperability that ensures the IGs are informed by, and
approved by, industry leaders looking to use technology to improve
patient care.
We request comment on these proposals.
We finalized in the CMS Interoperability and Patient Access final
rule that the Patient Access API at 42 CFR 422.119(b)(1)(iii),
431.60(b)(3), and 457.730(b)(3), and 45 CFR 156.221(b)(1)(iii) must
make available clinical data, including laboratory results. We
specified at 42 CFR 422.119(c)(3)(i), 431.60(c)(3)(i), and
457.730(c)(3)(i), and 45 CFR 156.221(c)(3)(i) that such clinical data
must comply with the content and vocabulary standards at 45 CFR
170.213, which is the USCDI version 1. Through a cross-reference to 45
CFR 170.215(a)(2) and (c)(6), at 42 CFR 431.60(c)(3)(iii) for state
Medicaid FFS programs, 42 CFR 457.730(c)(3)(iii) for state CHIP FFS
programs, and 45 CFR 156.221(c)(3)(iii) for QHP issuers on the FFEs, we
propose that payers would be allowed to conform with either the US Core
IG or the PDex IG to facilitate making the required USCDI data
available via the Patient Access API. In section II.E. of this proposed
rule, ONC, on behalf of HHS, proposes to adopt the PDex IG at 45 CFR
170.215(c)(6); currently, the US Core IG is adopted at 45 CFR
170.215(a)(2). These proposed new requirements to conform with either
IG would be equally applicable to Medicaid managed care plans and CHIP
managed care entities based on cross-references to the state Medicaid
and CHIP FFS requirements at 42 CFR 438.242(b)(5) for Medicaid managed
care plans and 42 CFR 457.1233(d)(2) for CHIP managed care entities.
When we first finalized the CMS Interoperability and Patient Access
final rule and suggested IGs payers could use to implement the APIs, we
only suggested the US Core IG; however, some payers informed us that
they preferred to leverage the PDex IG because it offered additional
resources for payer-specific use cases and was compatible with the US
Core IG ensuring interoperable data regardless of which IG was used
(see https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index for additional information). We seek comment on
the pros and cons of requiring the use of either one of these IGs or if
only one of the two proposed IGs should ultimately be required and why.
b. Additional Information
In addition to enhancing the Patient Access API by proposing to
require that the API be conformant with the specified IGs, we are also
proposing to require that information about prior authorization
decisions be made available to patients through the Patient Access API
in addition to the accessible content finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25558 through
25559). The primary goal of the Patient Access API is to give patients
access to and use of their health information. By ensuring patient
access to this additional information, we intend to help patients be
more informed decision makers and true partners in their health care.
In section II.C. of this proposed rule, we advance a number of
proposals focused on making the prior authorization process less
burdensome for payers and providers, and in turn, avoiding care delays
for patients, which we anticipate would also improve patient outcomes.
Patients can only truly be informed if they understand all aspects of
their care. We believe that more transparency would help ensure that
patients better understand the prior authorization process. By having
access to their pending and active prior authorization decisions via
the Patient Access API, a patient could see, for instance, that a prior
authorization is needed and has been submitted for a particular item or
service, and might better understand the timeline for the process and
plan accordingly. If a patient can see the supporting documentation
shared with their payer they might better understand what is being
evaluated and even potentially help providers get the best and most
accurate information to payers to facilitate a successful prior
authorization request, thus potentially avoiding unnecessary delays in
care and reducing burden on providers and payers. As a result, we are
proposing to require impacted payers to provide patients access to
information about the prior authorization requests made on their behalf
through the Patient Access API. Specifically, we are proposing at
431.60(b)(5) for state Medicaid FFS programs, at 438.242(b)(5) for
Medicaid managed care plans, at 457.730(b)(5) for state CHIP FFS
programs, at 457.1233(d)(2) for CHIP managed care entities, and at 45
CFR 156.221(b)(1)(iv) for QHP issuers on the FFEs to require these
payers to make available to patients information about any pending and
active prior authorization decisions (and related clinical
documentation and forms) for items and services via the Patient Access
API conformant with the HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG
no later than one (1) business day after a provider initiates a prior
authorization request or there is a change of status for the prior
authorization. We believe one (1) business day is appropriate because
in order for patients to have true transparency into the process, they
need to see the information timely. As discussed more in section II.C.
of this proposed rule, we are proposing expedited prior authorization

[[Page 82592]]

timeframes. If this information is provided any later, it would be of
less value in supporting the process. We propose that this requirement
begin January 1, 2023 (for Medicaid managed care plans and CHIP managed
care entities, by the rating period beginning on or after January 1,
2023).\7\
---------------------------------------------------------------------------

\7\ HL7 International. (n.d.). Da Vinci Payer Data Exchange
(FHIR IG) Publication (Version) History. Retrieved from https://hl7.org/fhir/us/davinci-pdex/history.html.
---------------------------------------------------------------------------

By ``active prior authorization decisions,'' we mean prior
authorizations that are currently open and being used to facilitate
current care and are not expired or no longer valid. By ``pending prior
authorization decisions,'' we mean prior authorizations that are under
review, either pending submission of documentation from the provider,
or being evaluated by the payer's medical review staff, or for another
reason have not yet had a determination made. As discussed in section
I.B. of this proposed rule, for the purposes of this rule, when we say
``items and services,'' we are talking about items and services
excluding prescription drugs and/or covered outpatient drugs. And,
``status'' of the prior authorization means information about whether
the prior authorization is approved, denied, or if more information is
needed to complete the request. We also note that the required
information and documentation through the API would include the date
the prior authorization was approved, the date the authorization ends,
the units and services approved, and those used to date.
Similarly, as further discussed in section II.B. of this proposed
rule, we are proposing to require impacted payers to share the same
information about prior authorization decisions with a patient's
provider via the Provider Access API upon a provider's request, and, in
section II.D. of this rule, we are proposing that the same information
about prior authorization decisions be made available via the Payer-to-
Payer API. In this way, if a patient authorizes their new payer to
access data from their old payer, this data exchange would include
information about pending and active prior authorizations, if such
information is applicable.
We did not include information about denied or expired prior
authorization decisions in this proposed requirement because this could
result in a significant amount of information being shared that may or
may not be clinically relevant at the moment in time the data are
exchanged. Pending and active prior authorizations are much more likely
to be clinically relevant and important for patients, providers, and
payers to know in order to support treatment and care coordination, as
well as efficient and effective payer operation that can lead to the
best possible outcomes for patients. We do note that if a prior
authorizations is ``pending,'' and the status changes to ``denied,''
that information would be shared as a ``change in status.'' As a
result, a patient would have access to that information via the API per
this proposal.
We anticipate that requiring payers to share prior authorization
information through the Patient Access API, with their patient's
approval and at their direction, might help patients better understand
the items and services that require prior authorization, the
information being considered and specific clinical criteria being
reviewed to determine the outcome of that prior authorization, and the
lifecycle of a prior authorization request. This proposed requirement
could provide patients with an opportunity to better follow the prior
authorization process and help their provider and payer by producing
missing documentation or information when needed. The proposed
requirement might also help to reduce the need for patients to make
repeated calls to the provider and payer to understand the status of a
request, or to inquire why there is a delay in care. We therefore
believe this proposal would help give patients more agency in their
health care journey and reduce burden on both the providers and the
payers working through prior authorization requests, allowing them to
more simply and efficiently administer the prior authorization process.
As with all information being made available via the Patient Access
API, we believe industry is in the best position to develop
applications, or apps, that patients can use to most effectively use
this information, and we look to innovators in industry to produce apps
that would help patients understand this information and access it in a
way that is useful to them.
In addition, we believe it would be highly valuable for payers to
share pending and active prior authorization decisions with providers,
as proposed in section II.B. of this proposed rule, and other payers,
as proposed in section II.D. of this proposed rule. Currently,
providers know which prior authorizations they have initiated for a
patient, but they may not be able to see pending and active prior
authorizations other providers have outstanding or in place for the
patient. Having this information could support care coordination and
more informed decision making. Additionally, if a new payer has
information from a previous payer about pending and active prior
authorization decisions, it could support improved care coordination
and continuity of care, also potentially improving patient outcomes.
We request comment on this proposal.
We also request comment for possible future consideration on
whether or not impacted payers should be required to include
information about prescription drug and/or covered outpatient drug
pending and active prior authorization decisions with the other items
or services proposed via the Patient Access API, the Provider Access
API, or the Payer-to-Payer API. We did not include information about
prescription drugs and/or covered outpatient drugs in any of the
proposals in this rule. However, we are interested in better
understanding the benefits and challenges of potentially including drug
information in future rulemaking. For example, what specific
considerations should we take into account? Are there unique
considerations related to the role Pharmacy Benefit Managers (PBMs)
play in this process? Overall, we do think it would be very valuable to
payers, providers, and patients to have information about a patient's
prescription drug and/or covered outpatient drug pending and active
prior authorization decisions, and we would like to better understand
how to most efficiently and effectively consider including this
information in these API provisions in the future.
c. Privacy Policy Attestation
As we discussed in detail throughout the CMS Interoperability and
Patient Access final rule, one of the most important aspects of
unleashing patient data is protecting the privacy and security of
patient health information, especially appreciating that once a
patient's data is received by a third-party app, it is no longer
protected under HIPAA. Throughout the final rule, we noted the
limitations to our authority to directly regulate third-party
applications. We previously finalized a provision that payers could
deny Patient Access API access to a third-party app that a patient
wished to use only if the payer determined that such access would pose
a risk to the PHI on their system. See 42 CFR 422.119(e) for Medicare
Advantage organizations, 431.60(e) for state Medicaid FFS programs,
438.242(b)(5) for Medicaid managed care plans, 457.730(e) for state
CHIP FFS programs, and 45 CFR 156.221(e) for QHP issuers on the FFEs.

[[Page 82593]]

In the ONC 21st Century Cures Act final rule (85 FR 25814 through
25815), ONC noted that it is not information blocking to provide
information that is factually accurate, objective, unbiased, fair, and
non-discriminatory to inform a patient about the advantages and
disadvantages and any associated risks of sharing their health
information with a third party. We previously finalized provisions at
42 CFR 422.119(g) for Medicare Advantage organizations, at 431.60(f)
for state Medicaid FFS programs, at 438.242(b)(5) for Medicaid managed
care plans, at 457.730(f) for state CHIP FFS programs, at
457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(g)
for QHP issuers on the FFEs, requiring that impacted payers share
educational resources with patients to help them be informed stewards
of their health information and understand the possible risk of sharing
their data with third-party apps. In response to comments on the CMS
Interoperability and Patient Access proposed rule, we noted in the
final rule (85 FR 25549 through 25550) commenters' beliefs that it is a
risk when patients do not understand what happens after their data are
transmitted to a third-party app and are no longer protected by the
HIPAA Rules. Commenters were specifically concerned about secondary
uses of data, such as whether or not their data would be sold to an
unknown third-party for marketing purposes or other uses. In the final
rule, we noted that a clear, plain language privacy policy is the
primary way to inform patients about how their information will be
protected and how it will be used once shared with a third-party app.
Taking into consideration comments indicating strong public support
for additional privacy and security measures, we encouraged, but did
not require, impacted payers to request an attestation from third-party
app developers indicating the apps have certain privacy provisions
included in their privacy policy prior to the payer providing the app
access to the payer's Patient Access API (85 FR 25549 through 25550).
We are now proposing to make it a requirement that impacted payers
request a privacy policy attestation from third party app developers
when their app requests to connect to the payer's Patient Access API.
We are proposing at 42 CFR 431.60(g) for state Medicaid FFS
programs, at 42 CFR 438.242(b)(5) for Medicaid managed care plans, at
42 CFR 457.730(g) for state CHIP FFS programs, at 42 CFR 457.1233(d)(2)
for CHIP managed care entities, and at 45 CFR 156.221(h) for QHP
issuers on the FFEs that beginning January 1, 2023 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2023), that impacted payers must
establish, implement, and maintain a process for requesting an
attestation from a third-party app developer requesting to retrieve
data via the Patient Access API that indicates the app adheres to
certain privacy provisions.
We recognize that there are many ways that an impacted payer could
meet this proposed requirement and we do not wish to be overly
prescriptive regarding how each payer could implement this process. For
instance, a reliable private industry third party may offer a pathway
for apps to attest that they have established a minimum set of privacy
provisions to be in compliance with this proposed requirement. A payer
could work with such an organization to meet this requirement. Or, an
impacted payer could establish its own process and procedures to meet
this proposed requirement. This process could be automated.\8\ We
believe it is important to allow the market to develop and make
available innovative solutions, and we do not look to preclude use of
such options and services. Regardless of this proposed flexibility,
impacted payers must not discriminate in implementation of this
proposed requirement, including for the purposes of competitive
advantage. Whatever method a payer might choose to employ to meet this
proposed requirement, the method must be applied equitably across all
apps requesting access to the payer's Patient Access API.
---------------------------------------------------------------------------

\8\ See Example 1 in ONC's 21st Century Cures at final rule (85
FR 25816).
---------------------------------------------------------------------------

At a minimum, we propose that the requested attestation include
whether:
The app has a privacy policy that is publicly available
and accessible at all times, including updated versions, and that is
written in plain language,\9\ and the third-party app developer has
affirmatively shared this privacy policy with the patient prior to the
patient authorizing the app to access their health information. To
``affirmatively share'' means that the patient had to take an action to
indicate they saw the privacy policy, such as click or check a box or
boxes.
---------------------------------------------------------------------------

\9\ Plain Language Action and Information Network. (2011, May).
Federal Plain Language Guidelines. Retrieved from https://www.plainlanguage.gov/media/FederalPLGuidelines.pdf.
---------------------------------------------------------------------------

The app's privacy policy includes, at a minimum, the
following important information:
++ How a patient's health information may be accessed, exchanged,
or used by any person or other entity, including whether the patient's
health information may be shared or sold at any time (including in the
future);
++ A requirement for express consent from a patient before the
patient's health information is accessed, exchanged, or used, including
receiving express consent before a patient's health information is
shared or sold (other than disclosures required by law or disclosures
necessary in connection with the sale of the application or a similar
transaction);
++ If an app will access any other information from a patient's
device; and
++ How a patient can discontinue app access to their data and what
the app's policy and process is for disposing of a patient's data once
the patient has withdrawn consent.
As we discussed in the CMS Interoperability and Patient Access
final rule (85 FR 25550), payers can look to industry best practices,
including the CARIN Alliance's Code of Conduct and the ONC Model
Privacy Notice for other provisions to include in their attestation
request that best meet the needs of their patient
population.^{10 11} In particular, we believe that explaining
certain practices around privacy and security in a patient-friendly,
easy-to-read privacy policy would help inform patients about an app's
practices for handling their data. It helps patients understand if and
how the app will protect their health information and how they can be
an active participant in the protection of their information. Also, as
explained in the CMS Interoperability and Patient Access final rule (85
FR 25517), if an app has a written privacy policy and does not follow
the policies as written, the Federal Trade Commission (FTC) has
authority to take action.
---------------------------------------------------------------------------

\10\ See https://www.carinalliance.com/our-work/trust-framework-and-code-of-conduct/.
\11\ See https://www.healthit.gov/topic/privacy-security-and-hipaa/model-privacy-notice-mpn.
---------------------------------------------------------------------------

We propose that impacted payers must request the third-party app
developer's attestation at the time the third-party app engages the
API. Under our proposal, the payer must inform the patient within 24
hours of requesting the attestation from the app developer of the
status of the attestation--positive, negative, or no response, with a
clear explanation of what each means. The patient would then have 24
hours to respond to this information. For

[[Page 82594]]

instance, if the app developer cannot attest that the app meets these
provisions, or if there is no response to the payer's request for the
attestation, the payer can inform the patient there may be risk
associated with sharing their health information with the app. The
patient may choose to change his or her mind and, at that point, the
payer would no longer be obligated to release the patient's data via
the API. However, if the patient does not respond or the patient
indicates they would like their information made available regardless,
the payer would be obligated to make the data available via the API.
The patient would have already authorized the app to access their data,
as the request from the payer for an attestation could only happen
after the patient has already authorized the app to access their
information and provided information about their payer to the app. As a
result, the patient's original request must be honored. Because the
patient has already consented to the app receiving their data, it is
important that this process not overly delay the patient's access to
their health information via the app of their choice. However, we are
interested in comments from the public that discuss this process, and
the payer's obligation to send the data regardless of whether or not
the patient responds to the payer after notification of the app's
attestation results, specifically notification if the app does not
attest to meeting the above privacy provisions.
We believe it is important for patients to have a clear
understanding of how their health information may be used by a third
party, as well as how to stop sharing their health information with a
third party, if they so choose. We believe the use of this required
attestation, if finalized as proposed, in combination with patient
education,\12\ would help patients be as informed as possible.
Therefore, we propose that the payer must include information about the
specific content of their privacy policy provisions included in the
attestation in the required enrollee resources. The enrollee resources
must also include, at a minimum, the timeline for the attestation
process, the method for informing enrollees about the app developer's
attestation response or non-response. The enrollee resources would also
have to include the enrollee's role and rights in this process, such as
what actions the enrollee may take when a payer informs the enrollee
about the status of the attestation, and information about an
enrollee's right to access their data via a third-party app of their
choice no matter what the status of the attestation request is.
Together, this privacy policy attestation framework and the requirement
for payers to provide patients with educational resources would help
ensure a more secure data exchange environment and more informed
patients. And, this would help build patient trust in apps, therefore
encouraging them to take advantage of this opportunity to access their
health information through a third-party app.
---------------------------------------------------------------------------

\12\ In the CMS Interoperability and Patient Access final rule,
we required impacted payers to make available enrollee resources
regarding privacy and security on its public website and through
other appropriate mechanisms through which it ordinarily
communicates with current and former patients at 42 CFR 422.119(g),
42 CFR 431.60(f), 42 CFR 457.30(f), and 45 CFR 156.221(g).
---------------------------------------------------------------------------

Privacy and security remain a critical focus for CMS, and we look
forward to continuing to work with stakeholders to keep patient privacy
and data security a top priority. Accordingly, we request comment on
additional content requirements for the attestation that impacted
payers must request and additional required enrollee resources that
impacted payers must make available related to the attestation in this
proposal. We are particularly interested in hearing feedback on how
best to engage available industry-led initiatives, as well as the level
of flexibility payers think is appropriate for defining the process for
requesting, obtaining, and informing patients about the attestation.
For instance, would payers prefer that CMS require the specific types
of communication methods payers can use to inform patients about the
attestation result, such as via email or text or other electronic
communication only? How should CMS account for third-party solutions
that present a list of apps that have already attested? In this
situation a payer would not need to take action for these apps, but
would need to have a process in place for apps not included on such a
list.
We also request comment on whether the request for the app
developer to attest to certain privacy provisions should be an
attestation that all provisions are in place, as it is currently
proposed, or if the app developer should have to attest to each
provision independently. We wish to understand the operational
considerations of an ``all or nothing'' versus ``line-item'' approach
to the attestation for both the app developers and the payers who would
have to communicate this information to patients. And, we wish to
understand the value to patients of the two possible approaches.
We request comment on the proposal to require impacted payers to
request a privacy policy attestation from third-party app developers.
d. Patient Access API Metrics
We are proposing to require impacted payers to report metrics about
patient use of the Patient Access API to CMS.\13\ We believe this is
necessary to better understand whether the Patient Access API
requirement is efficiently and effectively ensuring that patients have
the required information and are being provided that information in a
transparent and timely way. We would be better able to evaluate whether
policy requirements are achieving their stated goals by having access
to aggregated, patient de-identified data on the use of the Patient
Access API from each payer. With this information, we expect that we
would be better able to support payers in making sure patients have
access to their data and can use their data consistently across payer
types. As a first step in evaluating the adoption of the Patient Access
API, we propose to require states operating Medicaid and CHIP FFS
programs at the state level, Medicaid managed care plans at the plan
level, CHIP managed care entities at the entity level, and QHP issuers
on the FFEs at the issuer level to report to CMS. We also seek comment
on whether we should consider requiring these data be reported to CMS
at the contract level for those payers that have multiple plans
administered under a single contract or permit Medicaid managed care
plans, CHIP managed care entities, or QHP issuers on the FFEs to
aggregate data for the same plan type to higher levels (such as the
payer level or all plans of the same type in a program).
---------------------------------------------------------------------------

\13\ We note that the regulation text for QHP issuers on the
FFEs in part 156 refers to HHS. In the regulation text for QHPs on
the FFEs, we propose the reporting to HHS for consistency, noting
that CMS is a part of HHS.
---------------------------------------------------------------------------

Specifically, we propose that these payers report quarterly:
The total number of unique patients whose data are
transferred via the Patient Access API to a patient designated third-
party app; and
The number of unique patients whose data are transferred
via the Patient Access API to a patient designated third-party app more
than once.
Tracking multiple transfers of data would indicate repeat access
showing patients are either using multiple apps or are allowing apps to
update their information over the course of the quarter.
We are proposing these new reporting requirements at 42 CFR
431.60(h) for state Medicaid FFS programs, at 42 CFR 438.242(b)(5) for
Medicaid managed

[[Page 82595]]

care plans, at 42 CFR 457.730(h) for state CHIP FFS programs, at 42 CFR
457.1233(d)(2) for CHIP managed care entities, and at 45 CFR 156.221(i)
for QHP issuers on the FFEs. Under this proposal, we would redesignate
existing paragraphs as necessary to codify the new proposed text. We do
not intend to publicly report these data at the state, plan, or issuer
level at this time, but may reference or publish them at an aggregate,
de-identified level. We are proposing that by the end of each calendar
quarter, payers would report the previous quarter's data to CMS
starting in 2023. In the first quarter the requirement would become
applicable, payers would be required to report, by the end of the first
calendar quarter of 2023, data for the fourth calendar quarter of 2022.
Therefore, beginning March 31, 2023 all impacted payers would need to
report to CMS the first set of data, which would be the data for
October, November, and December 2022.
We request comment on this proposal.
We are proposing a quarterly data collection. We seek comment on
the burden associated with quarterly reporting versus annual reporting,
as well as stakeholder input on the benefits and drawbacks of quarterly
versus annual reporting. In addition, we request comment on what other
metrics CMS might require payers to share with CMS, and potentially the
public, on Patient Access API use, so that CMS can consider this
information for possible future rulemaking.\14\ In particular, we seek
comment on the potential burden if payers were required to report the
names of the unique apps that access the payer's API each quarter or
each year. We are considering collecting this information to help
identify the number of apps being developed, potentially review for
best practices, and evaluate consumer ease of use.
---------------------------------------------------------------------------

\14\ We note that the regulation text for QHP issuers on the
FFEs in Part 156 refers to HHS. In the regulation text for QHP
issuers on the FFEs, we propose the reporting to HHS for
consistency, noting that CMS is a part of HHS.
---------------------------------------------------------------------------

e. Patient Access API Revisions
We note that to accommodate the proposed requirements regarding the
use of the Patient Access API, we are proposing two minor changes to
the requirements finalized in the CMS Interoperability and Patient
access final rule.
First, we are proposing to revise language about the clinical data
to be made available via the Patient Access API 42 CFR 431.60(b)(3) for
state Medicaid FFS programs, 42 CFR 457.730(b)(3) for state CHIP FFS
programs, and 45 CFR 156.221(b)(1)(iii) for QHP issuers on the FFEs. In
the CMS Interoperability and Patient Access final rule, these specific
provisions require payers to make available ``clinical data, including
laboratory results.'' We are proposing to revise these paragraphs to
read, ``clinical data, as defined in the USCDI version 1.'' Lab results
are part of the USCDI, and clinical data were operationalized as the
USCDI version 1 under the ``technical requirements'' where the content
standard at 45 CFR 170.213 is adopted. Specifically calling out the
USCDI here would help avoid unnecessary confusion, as it would be
explicitly noted that the clinical data that must be available through
the Patient Access API is the USCDI version 1 data elements.
Second, we are proposing to revise the language previously
finalized for denial or discontinuation of access to the API to require
that the payer make such a determination to deny or discontinue access
to the Patient Access API using objective, verifiable criteria that are
applied fairly and consistently across all applications and developers
through which parties seek EHI. We are proposing to change the terms
``enrollees'' and ``beneficiaries'' to ``parties'' as we are proposing
to apply this provision to the Provider Access API, Payer-to-Payer API,
and the prior authorization APIs discussed further in sections II.B.,
II.C., and II.D. of this proposed rule. As other parties may be
accessing these APIs, such as providers and payers, we believe it is
more accurate to use the term ``parties'' rather than ``enrollees'' or
``beneficiaries.'' We are proposing these revisions 431.60(e)(2),
457.730(e)(2), and 45 CFR 156.221(e)(2).
We request comment on these proposals.
Although Medicare FFS is not directly impacted by this rule, we do
note that we are targeting to implement the provisions, if finalized.
In this way, the Medicare FFS implementation would conform to the same
requirements that apply to the impacted payers under this rulemaking,
so that Medicare FFS beneficiaries would also benefit from this data
sharing. CMS started to liberate patients' data with Blue Button 2.0,
which made Parts A, B, and D claims data available via an API to
Medicare beneficiaries. In an effort to align with the API provisions
included in the CMS Interoperability and Patient Access final rule, we
are updating the Blue Button 2.0 API to FHIR R4, and will begin use of
the CARIN IG for Blue Button.\15\ If the provisions in this rule are
finalized, we will work to align and enhance Blue Button accordingly,
as possible.
---------------------------------------------------------------------------

\15\ https://bluebutton.cms.gov/blog/FHIR-R4-coming-to-the-blue-button-api.html.
---------------------------------------------------------------------------

f. Provider Directory API Implementation Guide
We are also proposing to require that the Provider Directory API
finalized in the CMS Interoperability and Patient Access final rule (85
FR 25563 through 25564) be conformant with a specified IG. The Provider
Directory API provision requires impacted payers to ensure provider
directory information availability to third-party applications.
Specifically, payers need to make, at a minimum, provider names,
addresses, phone numbers, and specialties available via the public-
facing API. All directory information must be available through the API
within 30 calendar days of a payer receiving the directory information
or an update to the directory information. We are proposing a new
requirement at 42 CFR 431.70(d) for Medicaid state agencies, and at 42
CFR 457.760(d) for CHIP state agencies that the Provider Directory API
be conformant with the implementation specification at 45 CFR
170.215(c)(8) beginning January 1, 2023. Therefore, we are proposing
that the Provider Directory API be conformant with the HL7 FHIR Da
Vinci PDex Plan Net IG: Version 1.0.0.\16\ Currently, because QHP
issuers on the FFEs are already required to make provider directory
information available in a specified, machine-readable format, the
Provider Directory API proposal does not include QHP issuers.\17\
---------------------------------------------------------------------------

\16\ HL7 International. (n.d.). Da Vinci Payer Data Exchange
PlanNet (FHIR IG) Publication (Version) History. Retrieved from
https://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml.
\17\ Available at https://cmsgov.github.io/QHP-provider-formulary-APIs/developer/.
---------------------------------------------------------------------------

Currently, because of the existing cross-references at 42 CFR
438.242(b)(6) (cross referencing the Medicaid FFS Provider Directory
API requirement at 42 CFR 431.70) and 42 CFR 457.1233(d)(3) (cross
referencing the CHIP FFS Provider Directory API requirement at 42 CFR
457.760), Medicaid managed care plans and CHP managed care entities
must also implement and maintain Provider Directory APIs. We are
proposing here that Medicaid managed care plans and CHIP managed care
entities must comply with the implementation specification at 45 CFR
170.215(c)(8) (that is, the HL7 FHIR Da Vinci PDex Plan Net IG: Version
1.0.0) by the rating period that begins on or after January 1, 2023.
Because of the different compliance deadline for the managed care
programs, we are also proposing

[[Page 82596]]

additional revisions at 42 CFR 438.242(b)(6) and 42 CFR 457.1233(d)(3).
We request comment on these proposals.
3. Statutory Authorities for the Patient Access and Provider Directory
API Proposals
a. Medicaid and CHIP
For the reasons discussed below, our proposed requirements in this
section for Medicaid managed care plans and Medicaid state agencies
fall generally under our authority in section 1902(a)(4) of the Act,
which requires that a state Medicaid plan provide such methods of
administration as are found by the Secretary to be necessary for the
proper and efficient operation of the state Medicaid plan. The
proposals in this section are also authorized under section 1902(a)(8)
of the Act, which requires states to ensure that Medicaid services are
furnished with reasonable promptness to all eligible individuals.
Additionally, they are authorized by section 1902(a)(19) of the Act,
which requires states to ensure that care and services are provided in
a manner consistent with simplicity of administration and the best
interests of the recipients.
We are proposing to require that state Medicaid agencies and
Medicaid managed care plans implement the Patient Access and Provider
Directory APIs finalized in the CMS Interoperability and Patient Access
final rule conformant with specific IGs, as discussed in section
II.A.2. above in this proposed rule. In sections II.B.3., II.B.5.,
II.C.3., II.C.4., and II.D.2. of this proposed rule, we are also
proposing that these payers be required to implement new APIs,
specifically the Provider Access APIs, the DRLS API, the PAS API, and
the Payer-to-Payer API, in a manner that is conformant with specific
IGs. Use of these APIs would support more efficient administration of
the state plan, because, as discussed in more detail below, CMS expects
that the APIs would improve the flow of information relevant to the
provision of Medicaid services among beneficiaries, providers, and the
state Medicaid program and its contracted managed care plans. Improving
the flow of that information could also help states to ensure that
Medicaid services are provided with reasonable promptness and in a
manner consistent with simplicity of administration and the best
interests of the beneficiaries, as discussed in the CMS
Interoperability and Patient Access final rule related to the Patient
Access and Provider Directory APIs and the Payer-to-Payer data exchange
(for Medicaid managed care) (see 85 FR 25526). The state is also
required to make provider directory data for the FFS program available
per section 1902(a)(83) of the Act; Medicaid managed care plans are
similarly required to make a provider directory available under 42 CFR
438.10(g). Making provider directory information available via a
standards-based API, and updating this information through this API,
again adds efficiencies to administration of this process and our
proposal here is intended to further standardize implementation of the
Provider Directory API. The DRLS API and the PAS API both have the
potential to significantly improve the efficiency and response time for
Medicaid prior authorization processes, making them more efficient in
many ways, including limiting the number of denials and appeals or even
eliminating requests for additional documentation. In all of these
ways, the APIs are expected to make administration of the Medicaid
program more efficient.
Proposing to require these APIs be conformant with specific IGs is
expected to simplify the process of implementing and maintaining each
API, including preparing the information that must be shared via each
specific API, and ensuring data are provided as quickly as possible to
beneficiaries (in the case of the Patient Access API and the Provider
Directory API), to providers (in the case of the Provider Access API),
and to other payers (in the case of the Payer-to-Payer API).
Implementing these APIs across payers using the same IGs, as would be
the case via the Payer-to-Payer API, would ensure these APIs are
functioning as intended, and are able to perform the data exchanges
specified in a way that is interoperable and of value to both the
sender and receiver of the information, and thus could help to ensure
the APIs would improve the efficient operation of the state Medicaid
program, consistent with section 1902(a)(4) of the Act. These IGs, by
further ensuring that each API is built and implemented in a consistent
and standardized way, transmitting data that are mapped and
standardized as expected by both the sending and receiving parties,
would further increase the efficiency of the APIs. It would help ensure
that the data sent and received are usable and valuable to the end
user, whether that is the patient looking to have timely access to
their records or the provider or payer looking to ensure efficient care
and increased care coordination to support the timely administration of
services. As a result, proposing to adopt these IGs would further
contribute to proper and efficient operation of the state plan, and is
expected to facilitate data exchange in a way that is consistent with
simplicity of administration of the program and the best interest of
the participants. Requiring that the APIs be conformant with these IGs
is therefore expected to make the APIs more effective in terms of
improving the efficient operation of the Medicaid state plan and
Medicaid managed care plans. If the APIs operate more efficiently,
that, in turn, may help to ensure that beneficiaries and enrollees
receive care with reasonable promptness and in a manner consistent with
simplicity of administration and beneficiaries' and enrollees' best
interests.
The proposed requirement to make available information about
pending and active prior authorization decisions and associated
documentation through the Patient Access API is expected to allow
beneficiaries to more easily obtain the status of prior authorization
requests submitted on their behalf, so that they could ultimately use
that information to make more informed decisions about their health
care, improve the efficiency of accessing and scheduling services, and
if needed, provide missing information needed by the state to reach a
decision. Receiving missing information more quickly could allow states
to respond more promptly to prior authorization requests, thus
improving providers' and beneficiaries' experience with the process by
facilitating more timely and successful prior authorizations, which
would help states fulfill their obligations to provide care and
services in a manner consistent with simplicity of administration and
the best interests of the recipients, and to furnish services with
reasonable promptness to all eligible individuals. Improving the prior
authorization process could also help states improve the efficient
operation of the state plan. In these ways, these proposals are
consistent with our authorities under section 1902(a)(4), (8), and (19)
of the Act.
We also propose that payers would be required to ask app developers
to attest to whether they have certain privacy policy provisions in
place prior to making a beneficiary's or enrollee's data available via
the Patient Access API. Proposing to require state Medicaid agencies
and Medicaid managed care plans to implement a privacy policy
attestation process is expected to help ensure beneficiaries be
informed about how their information would be protected or not
protected when it is provided by the state Medicaid agency

[[Page 82597]]

or Medicaid managed care plan to a third-party app at their request.
This attestation process is expected to help a beneficiary or enrollee
better understand how their data would be used, and what they can do to
further control how and when their data is shared by other entities
associated with the app. Taking additional steps to protect patient
privacy and security would help to ensure that the Medicaid program,
whether through FFS or managed care, is providing Medicaid-covered care
and services in a manner consistent with the best interests of
beneficiaries and enrollees. In this way, it is within our authority
under section 1902(a)(19) of the Act to propose to require this privacy
policy attestation.
We are also proposing to require state Medicaid agencies and
Medicaid managed care plans to report Patient Access API metrics to CMS
quarterly. We believe that having these metrics would support CMS'
oversight, evaluation, and administration of the Medicaid program, as
it would allow us to evaluate beneficiary and enrollee access to the
Patient Access API. Use of the API could indicate that the policy is
supporting program efficiencies and ensuring access to information in a
timely and efficient way and in the best interest of beneficiaries, as
intended. Section 1902(a)(6) of the Act authorizes CMS to request
reports in such form and containing such information as the Secretary
from time to time may require. These metrics would serve as a report to
evaluate the implementation and execution of the Patient Access API.
For CHIP, we propose these requirements under the authority in
section 2101(a) of the Act, which sets forth that the purpose of title
XXI is to provide funds to states to provide child health assistance to
uninsured, low-income children in an effective and efficient manner
that is coordinated with other sources of health benefits coverage.
This provision provides us with authority to adopt these requirements
for CHIP because the proposed requirements increase access to patient
data, which can improve the efficacy of CHIP programs, allow for more
efficient communication and administration of services, and promote
coordination across different sources of health benefits coverage.
As discussed above for Medicaid programs, requiring that the APIs
finalized in the CMS Interoperability and Patient Access final rule, as
well as those APIs proposed in this rule, be conformant with specific
IGs would support program efficiency. By ensuring that these APIs are
implemented in a consistent, standardized way, use of the IGs is
expected to help support patient, provider, and payer access to data
they can best use to make informed decisions, support care
coordination, and for the state, support efficient operations.
We believe that requiring CHIP agencies, as well CHIP managed care
entities, to make CHIP enrollees' prior authorization data and other
standardized data available through standards-based APIs would
ultimately lead to these enrollees accessing that information in a
convenient, timely, and portable way. This improved access would help
to ensure that services are effectively and efficiently administered in
the best interests of beneficiaries, consistent with the requirements
in section 2101(a). We believe making patient data available in this
format would result in better health outcomes and patient satisfaction
and improve the cost effectiveness of the entire health care system,
including CHIP. Allowing beneficiaries or enrollees easy and simple
access to certain standardized data can also facilitate their ability
to detect and report fraud, waste, and abuse--a critical component of
an effective program.
These proposals align with section 2101(a) in that they also
improve the efficiency of CHIP programs. For example, adding
information about pending and active prior authorization decisions to
the Patient Access API allows beneficiaries to easily obtain the status
of prior authorization requests made on their behalf. This allows
patients to make scheduling decisions, and provide any missing
information needed by a payer to reach a decision, which makes the
prior authorization process more efficient, ultimately streamlining the
prior authorization process.
Additionally, proposing to require the CHIP programs (FFS and
managed care) to put a process in place to ask third-party app
developers to attest to whether they have certain privacy provisions in
place would allow CHIP to provide services in a way that is in the
beneficiary's best interest by providing additional information to them
about how they can best protect the privacy and security of their
health information.
Finally, proposing to require state CHIP agencies and CHIP managed
care plans report Patient Access API metrics to CMS quarterly would
help states and CMS understand how this API can be used to continuously
improve the effectiveness and efficiency of state CHIP operations by
providing information about its use, which is an indication of the
effectiveness of the API. The more we understand about the use of the
Patient Access API, the better we can assess that the API is leading to
improved operational efficiencies and providing information to
beneficiaries in a way that supports their best interests.
Regarding the requiring the use of the PlanNet IG for the Provider
Directory API under CHIP, we note that 42 CFR 457.1207 requires CHIP
managed care entities to comply with the provider directory (and other
information disclosure) requirements that apply to Medicaid managed
care plans under 42 CFR 438.10.
b. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we propose these new requirements
under our authority in section 1311(e)(1)(B) of the Affordable Care
Act, which affords the Exchanges the discretion to certify QHPs if the
Exchange determines that making available such health plans through the
Exchange is in the interests of qualified individuals in the state in
which the Exchange operates.
Existing and emerging technologies provide a path to make
information and resources for health care and health care management
universal, integrated, equitable, more accessible, and personally
relevant. Requiring the APIs discussed in this rule, including the
Patient Access API, the Provider Access API, the DRLS API, the PAS API,
and the Payer-to-Payer API be conformant with specific IGs would permit
QHP issuers on the FFEs to meet the proposed requirements of this
rulemaking efficiently by simplifying the process of implementing and
maintaining each API, including preparing the needed information to be
shared via each specific API, and ensuring data, and ultimately
services, are provided to enrollees as quickly as possible. These IGs,
by further ensuring that each API is built and implemented in a
consistent and standardized way, transmitting data that are mapped and
standardized as expected by both the sending and receiving parties,
would further increase the efficiency of the APIs. It would help ensure
that the data sent and received are usable and valuable to the end
user, whether that is the patient looking to have timely access to
their records or the provider or payer looking to ensure efficient care
and increased care coordination to support the timely administration of
services. This could add significant operational efficiencies for QHP
issuers on the FFEs. This would help each proposed policy be most
effective, the API solutions to be truly interoperable, and for QHP
issuers on the FFEs to meet

[[Page 82598]]

these requirements in a way that ensures enrollees' needs are best met.
We believe generally that certifying only health plans that take
steps to make enrollees' pending and active prior authorization
decisions and related clinical documentation available through
interoperable technology would ultimately lead to these enrollees
having access to that information in a convenient, timely, and portable
way, which is in the best interests of enrollees. Having simple and
easy access, without special effort, to their health information also
facilitates enrollees' ability to detect and report fraud, waste, and
abuse--a critical component of an effective program. Adding information
about pending and active prior authorization decisions to the Patient
Access API would allow enrollees to easily obtain the status of prior
authorization requests submitted on their behalf and use that
information effectively to make more informed decisions about their
health care, improve the efficiency of accessing and scheduling
services, and if needed, provide missing information needed by the
issuer to reach a decision. This could allow QHP issuers on the FFEs to
more promptly address prior authorization requests, streamlining this
process, and thus simplifying prior authorization processes, and
enrollees' experience with the process, by facilitating timelier and
potentially more successful initial prior authorization requests. We
encourage State-based Exchanges (SBEs) to consider whether a similar
requirement should be applicable to QHP issuers.
Proposing to require QHP issuers on the FFEs to implement a privacy
policy attestation process would ensure enrollees are informed about
how their information would be protected and how it would be used, and
would add an additional opportunity for issuers to promote the privacy
and security of their enrollees' information. This again ensures
enrollees' needs are best met.
Finally, proposing to require QHP issuers on the FFEs report
Patient Access API metrics to CMS quarterly would help CMS understand
the impact this API is having on enrollees and would inform how CMS
could either enhance the policy or improve access or use through such
things as additional consumer education. These data could help CMS
understand how best to leverage this API, and consumer access to it, to
ensure this requirement is being met efficiently and adding value to
CMS operations, including leading to the efficiencies intended.

B. Provider Access APIs

1. Background
As mentioned in the CMS Interoperability and Patient Access final
rule, the Patient Access API (85 FR 25558 through 25559) could allow
the patient to facilitate their data being accessible to their
provider. A patient could use their mobile phone during a visit with
their provider to show the provider their data to help inform their
discussion. In the CMS Interoperability and Patient Access final rule
(85 FR 25555), we discussed the benefits of sharing patient health
information with providers. We also encouraged payers to consider an
API solution to allow providers to access patient health information
through payer APIs, such as for treatment purposes, and received
comments in support of this type of data exchange. We sought comment
for possible consideration in future rulemaking on the feasibility of
providers being able to request information on a shared patient
population using a standards-based API. Among the comments we received,
some comments stated that allowing providers to receive data directly
from payers would allow the FHIR-based data exchange to be
significantly more valuable for patients, providers, and payers, as the
data would be available at the moment of care when providers need it
most, affording patients the maximum benefit from the data exchange. We
also received some comments that having providers receive information
about prior authorization decisions would reduce burden on providers
and their staff (85 FR 25541).
While the use of the Patient Access API is a significant first step
in facilitating sharing individual patient health information, we
believe the benefits of making patient data available via a standards-
based API would be greatly enhanced if providers had direct access to
their patients' data. As discussed later in this section we are now
working to get providers direct access to data through certain CMS
programs, and based on this experience to date, we believe it would
benefit providers if they were allowed ongoing access to information
about their patients, particularly if they could access that
information directly from clinical workflows in their EHRs or other
health IT systems. We further believe provider access to patient
information would improve both the provider and patient experience.
Ensuring that providers have access to comprehensive patient data at
the point of care could potentially reduce the burden on patients to
recall certain information during an appointment, and might provide an
additional way for both the provider and patient to confirm that the
patient's recollection of a prior care episode is accurate. If
providers could access information about the care their patient
received outside of the provider's care network prior to a patient's
visit, the information might improve clinical efficiency and provide a
more comprehensive understanding of the patient's health, thus
potentially saving time during appointments and potentially improving
the quality of care delivered.
While we have no data, we anticipate that putting patient data in
the hands of the provider at the point of care would reduce provider
burden and improve patient care. Providers would be empowered to view
their patient's claims history and available clinical data, including
the identity of other providers who are working, or have worked, with
the patient. This proposal might also improve a patient's care
experience as it may lessen the burden on patients not only in relation
to recall, as noted above, but it may spare patients from having to
fill out the same medical history forms repeatedly. Used wisely, the
data available to providers under these proposals might give patients
and providers more time to focus on the patient's needs. In addition,
if a patient's entire care team has access to the same information,
this may help improve the efficiency and effectiveness of patient care.
2. HIPAA Disclosures and Transaction Standards
As reflected in our proposals below, providers would be allowed to
request the claims and encounter data for patients to whom they provide
services for treatment purposes. The HIPAA Privacy Rule, at 45 CFR
164.502, generally permits a covered entity to use or disclose
protected health information (PHI) for treatment, payment, or health
care operations without individual authorization. Covered entities must
reasonably limit their disclosures of, and requests for, PHI for
payment and health care operations to the minimum necessary to
accomplish the intended purpose of the use, disclosure, or request (45
CFR 164.502(b)). However, covered entities are not required to apply
the minimum necessary standard to disclosures to or requests by a
health care provider for treatment purposes (45 CFR
164.502(b)(2)(i)).\18\
---------------------------------------------------------------------------

\18\ See, Office for Civil Rights. (2013, July 26). Uses and
Disclosures for Treatment, Payment, and Health Care Operations (45
CFR 164.506). Retrieved from https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/disclosures-treatment-payment-health-care-operations/.

---------------------------------------------------------------------------

[[Page 82599]]

HIPAA also identifies specific transactions for which the Secretary
must adopt standards and specifies a process for updating those
standards. A HIPAA transaction is an electronic exchange of information
between two parties to carry out financial or administrative activities
related to health care (for example, when a health care provider sends
a claim to a health plan to request payment for medical services).
Under HIPAA, HHS has adopted multiple standards for transactions
involving the exchange of electronic health care data, including:
Health care claims or equivalent encounter information.
Health care electronic funds transfers (EFT) and
remittance advice.
Health care claim status.
Eligibility for a health plan.
Enrollment and disenrollment in a health plan.
Referrals certification and authorization.
Coordination of benefits.
Health plan premium payments.
Medicaid pharmacy subrogation.
We note that the HHS Secretary has not adopted an applicable HIPAA
transaction standard for communications of claims or encounter data
that are not sent for the purpose of requesting payment. Although our
proposals detailed below would facilitate payers sharing claims data
with providers, this would not be done for the purpose of obtaining (or
making) payment (as described under 45 CFR 162.1101(a)). We are not
proposing to report health care encounters in connection with a
reimbursement contract that is based on a mechanism other than charges
or reimbursement rates for specific services (as described under 45 CFR
162.1101(b)). Therefore, the use of a HIPAA transaction standard is not
required for our proposals in this section, or for our proposals
regarding data sharing in sections II.C. and II.D. of this proposed
rule, because the Secretary has not adopted a HIPAA transaction
applicable to communications of claims or encounter information for a
purpose other than requesting payment.\19\
---------------------------------------------------------------------------

\19\ See 45 CFR 162.923(a).
---------------------------------------------------------------------------

In this section, we propose to require that certain payers
implement a standards-based Provider Access API that makes patient data
available to providers both on an individual patient basis and for one
or more patients at once using a bulk specification, as permitted by
applicable law, so that providers could use data on their patients for
such purposes as facilitating treatment and ensuring their patients
receive better, more coordinated care. As noted, the HIPAA Privacy Rule
generally permits HIPAA covered entities to use and disclose PHI for
these purposes without need of an individual's authorization.\20\
However, under other federal, state, local, or tribal laws (for
example, the ``part 2'' regulations addressing substance use disorder
data at 42 CFR part 2), payers and providers may need to obtain some
specified form of patient consent to request or disclose behavioral
health, certain substance use disorder treatment, or other sensitive
health-related information, or they may have to use specified
transactions to carry out certain defined data transfers between
certain parties for specific purposes. We note these proposals do not
in any way alter a payer's or a provider's obligations under all
existing federal, state, local, or tribal laws.
---------------------------------------------------------------------------

\20\ See 45 CFR 164.506.
---------------------------------------------------------------------------

3. Proposed Requirements for Payers: Provider Access API for Individual
Patient Information Access
In the CMS Interoperability and Patient Access final rule (85 FR
25558 through 25559), we required impacted payers to make certain
health information available to third-party apps with the approval and
at the direction of a patient though the Patient Access API for patient
use. We believe there would be value to providers having access to the
same patient data through a FHIR-based API that allows the provider to
request data for a single patient as needed. And, we recognize that the
impacted payers under this proposed rule will have largely prepared the
necessary infrastructure and implemented the FHIR standards to support
the Patient Access API finalized in the CMS Interoperability and
Patient Access final rule (85 FR 25558 through 25559) by January 1,
2021 (for QHP issuers on the FFEs, for plan years beginning on or after
January 1, 2021). As a result, we are now proposing to require impacted
payers to implement a Provider Access API.
Both this proposed Provider Access API and the Patient Access API
would facilitate the FHIR-based exchange of claims and encounter data,
as well as the same set of clinical data as defined in the USCDI
version 1, where such clinical data are maintained by the payer, and
formulary data or preferred drug list data, where applicable. Both APIs
also require the sharing of pending and active prior authorization
decisions (and related clinical documentation and forms) for items and
services. One difference is that the Provider Access API would not
include remittances and beneficiary cost-sharing information. Another
key difference is that in the case of the Provider Access API
proposals, the provider, not the patient, requests and ultimately
receives the patient's information, and would typically make such a
request for treatment or care coordination purposes. Where a patient
would receive this data via a third-party app for use on a mobile
device, in the case of the Provider Access API, the provider would
receive the data directly from the payer and incorporate it into their
EHR or other practice management system.
Through a proposed cross-reference to the Patient Access API
requirements, the Provider Access API also requires adherence to the
same technical standards, API documentation requirements, and
discontinuation and denial of access requirements. For a complete
discussion of these requirements, we refer readers to the CMS
Interoperability and Patient Access final rule (85 FR 25526 through
25550) and to section II.A. of this proposed rule.
We are proposing two approaches to the Provider Access API. First,
we are proposing a Provider Access API that allows providers to have
access to an individual patient's information. Second, we are proposing
that the Provider Access API allow access to multiple patients'
information at the same time; this is discussed in section II.B.5. of
this proposed rule. The individual request approach may be better
suited for situations such as, but not limited to, when the provider
needs ``real-time'' access to a patient's data prior to or even during
a patient visit or for small practices with limited server bandwidth.
In these situations, providers may wish to gain access to patient data
through an API that yields the data through an individual patient
request.
To support this individual patient use case, we are proposing to
require state Medicaid and CHIP FFS programs at 42 CFR 431.61(a)(1)(i)
and 457.731(a)(1)(i) respectively; and QHP issuers on the FFEs at 45
CFR 156.222(a)(1)(i), to implement and maintain a Provider Access API
conformant with the requirements at 45 CFR 170.215, as detailed in
section II.A.2. of this proposed rule for the Patient Access API. This
proposed Provider Access API would leverage the same IGs in the same
way as proposed for the Patient Access API. These requirements would be
equally applicable to Medicaid managed care plans and CHIP managed care

[[Page 82600]]

entities based on cross-references to the state Medicaid and CHIP FFS
requirements at 42 CFR 438.242(b)(7) for Medicaid managed care plans
other than Non-Emergency Medical Transportation (NEMT) PAHPs \21\ and
42 CFR 457.1233(d)(4) for CHIP managed care entities. We propose that
payers implement this Provider Access API individual patient data
approach for data maintained by the payer with a date of service on or
after January 1, 2016 by January 1, 2023 (for Medicaid managed care
plans and CHIP managed care entities, by the rating period beginning on
or after January 1, 2023). We note that providers may or may not have a
provider agreement with or be in- or out-of-network with the payer that
is providing the information, as we believe providers should have
access to their patients' data regardless of their relationship with
the payer. Therefore, our proposal does not permit a payer to deny use
of or access to the Provider Access API based on whether the provider
using the API is under contract with the payer. A provider that is not
in network would need to demonstrate to the patient's payer that they
do have a care relationship with the patient.
---------------------------------------------------------------------------

\21\ See 42 CFR 438.9(b)(7).
---------------------------------------------------------------------------

In the context of Medicaid managed care, we are proposing that NEMT
PAHPs, as defined at 42 CFR 438.9(a), would not be subject to the
requirement to establish a Provider Access API. MCOs, PIHPs, and non-
NEMT PAHPs are subject to this proposed rule. We believe that the
unique nature and limited scope of the services provided by NEMT PAHPs
is not consistent with the proposed purposes of the Provider Access API
proposed at 42 CFR 431.61(a). Specifically, we do not believe that
providers have any routine need for NEMT data nor that having NEMT
PAHPs implement and maintain a Provider Access API would help achieve
the goals of the proposal, namely to help avoid patients needing to
recall prior services, ensure that providers are able to spend time
with patients focusing on care versus collecting redundant information,
or improve patient care through enhanced care coordination. However, we
include NEMT PAHPs in the scope of some of our other requirements that
apply to all other Medicaid managed care plans under proposed 42 CFR
438.242(b)(5) through (8). Currently, NEMT PAHPs are exempt from
compliance with requirements in 42 CFR part 438 unless the provision is
listed in Sec. 438.9(b), which does currently apply 42 CFR 438.242 to
NEMT PAHPs. We are therefore proposing to revise 42 CFR 438.9(b)(7) to
require compliance with the requirements in 42 CFR 438.242(b)(5)
through (8) other than the reference to 42 CFR 431.61(a) and (c) at
438.242(b)(7).
We request public comment on this proposal for impacted payers to
implement a Provider Access API for individual patient information
access.
4. The MyHealthEData Initiative Experience With Sharing Patient Data
With Providers
Understanding the benefits of provider access to patient
information discussed above, as part of the MyHealthEData initiative,
we launched the Beneficiary Claims Data API (BCDA), which enables
Accountable Care Organizations (ACOs) participating in the Shared
Savings Program to retrieve Medicare Part A, Part B, and Part D claims
data for their prospectively assigned or assignable beneficiaries.\22\
To better facilitate the coordination of care across the care continuum
and in support of a move to value-based care, the BCDA utilizes the HL7
FHIR Bulk Data Access (Flat FHIR) specification to allow us to respond
to requests for large amounts of patient-level Medicare FFS claims data
on behalf of ACO participating practices.\23\ Using a bulk data
exchange reduces burden for ACOs and CMS, and adds a number of
efficiencies for ACOs and their participating practices by facilitating
the exchange of data for many patients at once. It also gets data to
providers when and where they need it most.
---------------------------------------------------------------------------

\22\ Centers for Medicare and Medicaid Services. (n.d.).
Beneficiary Claims Data API. Retrieved from https://bcda.cms.gov/.
\23\ HL 7 International. (n.d.). FHIR Bulk Data Access (Flat
FHIR). Retrieved from https://hl7.org/fhir/uv/bulkdata/history.html.
---------------------------------------------------------------------------

In addition, in July 2019, we announced a pilot program called
``Data at the Point of Care'' (DPC) \24\ in support of our mission to
transform the health care system. Also part of the MyHealthEData
initiative, DPC-- utilizing the HL7 FHIR Bulk Data Access (Flat FHIR)
specification--allows health care providers to access synthetic
Medicare FFS claims data, either by integrating with their EHR or with
the health IT system they utilize to support care, without requiring
access to other applications. Currently, approximately 1,000
organizations representing over 130,000 providers have engaged with the
synthetic data in the pilot. Participants include a diversity of
practice types including primary care practices, single or small office
specialist practices, academic medical centers, non- and for-profit
health systems, and dialysis centers. The provider organization is the
official demonstration participant, but each organization is taking
part with its EHR vendor.
---------------------------------------------------------------------------

\24\ Data at the Point of Care. (n.d.). Retrieved from https://dpc.cms.gov/.
---------------------------------------------------------------------------

Both BCDA and DPC have started to demonstrate the value of
exchanging data on multiple patients at once via FHIR. The HL7 FHIR
Bulk Data Access (Flat FHIR) specification can reduce the number of API
requests and support a secure connection for third-party application
access to specified data stored in EHRs and data warehouse
environments.\25\ CMS has developed our projects leveraging the HL7
FHIR Bulk Data Access (Flat FHIR) specification using open source
programming. The documentation, specifications, and reference
implementations are available at https://github.com/CMSgov/bcda-app and
https://github.com/CMSgov/dpc-app.
---------------------------------------------------------------------------

\25\ Office of the National Coordinator, Computational Health
Informatics Program, & Boston Children's Hospital. (2017, December
15). The Intersection of Technology and Policy: EHR Population Level
Data Exports to Support Population Health and Value. Retrieved from
https://smarthealthit.org/an-app-platform-for-healthcare/meetings/bulk-data-export-meeting-and-report/.
---------------------------------------------------------------------------

When leveraged, the HL7 FHIR Bulk Data Access (Flat FHIR)
specification permits the efficient retrieval of data on entire patient
populations or defined cohorts of patients via the bulk transfer of
data using standard data exchanges. Providers who are responsible for
managing the health of multiple patients may need to access large
volumes of data. Exchanging patient data for large numbers of patients
may require large exports, which would usually require multiple
requests and a number of resources to manage the process that can
overburden organizations and be time consuming and costly. Even using
more efficient methods of data exchange like secure APIs can present
challenges for a large number of patient records. For example, for a
health system with thousands of Medicaid patients, accessing those
patients' claims data one by one would require thousands of API
calls.\26\ We believe that providing a streamlined means of accessing
this information via FHIR-based APIs utilizing the HL7 FHIR Bulk Data
Access (Flat FHIR) specification greatly improves providers' ability to
deliver quality, value-based care, and ultimately better manage patient
health.
---------------------------------------------------------------------------

\26\ A `call' is an interaction with a server using an API to
deliver a request and receive a response in return.

---------------------------------------------------------------------------

[[Page 82601]]

5. Proposed Requirements for Payers: Bulk Data Provider Access API
We believe that the benefits of data sharing would be greatly
enhanced if other payers were sharing health information about their
patients with health care providers for multiple patients at once, as
CMS is now beginning to do under BCDA and as we are also further
testing through the DPC pilot, for instance. As a result, we are
proposing a second approach to require impacted payers to implement
payer-to-provider data sharing using the HL7 FHIR Bulk Data Access
(Flat FHIR) specification--a Bulk Data Provider Access API.
Given the many benefits of giving providers efficient access to
their patients' data, and the relative ease of doing so by leveraging
the HL7 FHIR Bulk Data Access (Flat FHIR) specification, we are
proposing to require that all Medicaid and CHIP FFS programs at 42 CFR
431.61(a)(1)(ii) and 457.731(a)(1)(ii), Medicaid managed care plans at
42 CFR 438.242(b)(7), CHIP managed care entities at 42 CFR
457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR 156.222(a)(1)(ii)
implement and maintain a standards-based Provider Access API using the
HL7 FHIR Bulk Data Access (Flat FHIR) specification at 45 CFR
170.215(a)(4) to allow providers to receive the same information as
indicated above for the individual patient request Provider Access
API--their patients' claims and encounter data (not including cost
information such as provider remittances and enrollee cost-sharing);
clinical data as defined in the USCDI version 1, where such clinical
data are maintained; and formulary data or preferred drug list data,
where applicable; as well as information on pending and active prior
authorization decisions. The regulations for Medicaid managed care
plans and CHIP managed care entities are cross-referenced and
incorporate the regulations we propose for state Medicaid and CHIP FFS
programs.
We are proposing that payers would be required to implement this
Bulk Data Provider Access API approach for data maintained by the payer
with a date of service on or after January 1, 2016, by January 1, 2023
(for Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2023). We request public
comment on whether this timeline is feasible and whether the benefits
would out weight the costs of this Bulk Data Provider Access API
proposal.
We understand and acknowledge that payers and developers may view
these proposed requirements as burdensome, as they could involve
building multiple APIs to share data between payers and providers. We
invite public comment on the benefits of having the Provider Access API
available with and without the use of the HL7 FHIR Bulk Data Access
(Flat FHIR) specification. As we look to balance providing this
flexibility with the burden of potentially implementing and maintaining
multiple APIs, we invite input on whether we should require payers to
implement just one API that leverages the HL7 FHIR Bulk Data Access
(Flat FHIR) specification for when they are requesting data for just
one patient, or for more than one patient, or should we finalize as we
are proposing here to have payers implement one API solution that does
not leverage the Bulk specification for a single patient request (as
discussed in section II.B.3. above in this proposed rule), and a second
solution that uses the Bulk specification for requests for more than
one patient. We believe both proposed functionalities offer necessary
benefits to providers depending on the specifics of the situations in
which they would need patient data. For example, a large health system
or large group practice may benefit from using the bulk specification
if it is updating records annually. We also believe that requiring
payers to have both API approaches available gives providers
flexibility. For example, a provider practicing within a large health
system, such as in the example above, may want quick access to a
specific patient's information right before that patient's scheduled
appointment.
We request comment on this proposal.
States operating Medicaid and CHIP programs may be able to access
federal matching funds to support their implementation of this Provider
Access API, because the API is expected to help the state administer
its Medicaid and CHIP state plans properly and efficiently, consistent
with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more
detail in section II.B.7.a. of this proposed rule.
We do not consider state expenditures for implementing this
proposal to be attributable to any covered item or service within the
definition of ``medical assistance.'' Thus, we would not match these
expenditures at the state's regular federal medical assistance
percentage. However, federal Medicaid matching funds under section
1903(a)(7) of the Act, at a rate of 50 percent, for the proper and
efficient administration of the Medicaid state plan, might be available
for state expenditures related to implementing this proposal for their
Medicaid programs, because use of the Provider Access API would help
ensure that providers can access data that could improve their ability
to render Medicaid services effectively, efficiently, and
appropriately, and in the best interest of the patient, and thus help
the state more efficiently administer its Medicaid program.
States' expenditures to implement these proposed requirements might
also be eligible for enhanced 90 percent federal Medicaid matching
funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can
be attributed to the design, development, or installation of mechanized
claims processing and information retrieval systems. Additionally, 75
percent federal matching funds under section 1903(a)(3)(B) of the Act
may be available for state expenditures to operate Medicaid mechanized
claims processing and information retrieval systems to comply with this
proposed requirement.
States request Medicaid matching funds under section
1903(a)(3)(A)(i) or (B) of the Act through the Advance Planning
Document (APD) process described in 45 CFR part 95, subpart F. States
are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to
ensure that any system for which they are receiving enhanced federal
financial participation under section 1903(a)(3)(A)(i) or (B) of the
Act aligns with and incorporates the ONC Health Information Technology
standards adopted in accordance with 45 CFR part 170, subpart B. The
Provider Access API, and all APIs proposed in this rule, complement
this requirement because these APIs further interoperability through
the use of HL7 FHIR standards proposed for adoption by ONC for HHS use
at 45 CFR 170.215.\27\ In addition, states are reminded that 42 CFR
433.112(b)(10) explicitly supports exposed APIs as a condition of
receiving enhanced federal financial participation under section
1903(a)(3)(A)(i) or (B) of the Act.
---------------------------------------------------------------------------

\27\ See SHO #20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
---------------------------------------------------------------------------

Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of
Medicaid technologies and systems as a condition of receiving enhanced
federal financial participation under section 1903(a)(3)(A)(i) or (B)
of the Act. CMS would interpret that sharing and re-use requirement
also to apply to technical documentation associated with a technology
or system, such as technical documentation for connecting to a state's
APIs. Making the needed

[[Page 82602]]

technical documentation publicly available so that systems that need to
connect to the APIs proposed in this rule can do so would be required
as part of the technical requirements at 42 CFR 431.60(d) for all
proposed APIs in this rule, including the Provider Access API.
Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act,
limiting administrative costs to no more than 10 percent of CHIP
payments to the state, would apply in developing the APIs proposed in
this rule.
We note that the temporary federal medical assistance percentage
(FMAP) increase available under section 6008 of the Families First
Coronavirus Response Act (Pub. L. 116-127) does not apply to
administrative expenditures.
6. Additional Proposed Requirements for the Provider Access APIs
In general, the proposals discussed in this section would align
with the requirements for the Patient Access API finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25558 through
25559) and as proposed in section II.A.2. of this rule with respect to
the data that are available through the API and the technical
specifications (other than the proposed use of the Bulk specification).
We anticipate that this alignment would provide consistency and help
ensure that payers could build on the foundation of work done to meet
the final Patient Access API requirements to meet the proposed
requirements related to the Provider Access API. The accessible
content, technical standards, API documentation requirements, and
discontinuation and denial of access requirements would generally be
consistent between the Patient Access API and the Provider Access API
proposals, and thus we will not repeat the details of these
requirements here. There are additional proposed requirements specific
to the Provider Access API proposals related to attribution, patient
opt-in, and provider resources. These are discussed in this section.
a. Attribution
Data sharing between the payer and provider via the Provider Access
API starts with a request from the provider for one or more patients'
health information. Data sharing via the Provider Access API would be
possible only if the patients for whom the provider is requesting
information can be identified, especially if the provider is requesting
data for more than one patient at a time using the proposed Bulk
specification. We do not believe there is only one approach to
identifying the patients whose information would be requested, and we
look to provide impacted payers with the opportunity to establish a
process that will work best for them in light of their existing
provider relationships.
As discussed in the CMS Interoperability and Patient Access final
rule, use of a standards-based FHIR API consistent with the privacy and
security technical standards required provides a base level of
protections (see 85 FR 25515 through 25519 and 85 FR 25544 through
25547). For instance, use of the API would allow payers to determine if
the provider who is requesting the data is who they say they are by
leveraging the required authorization and authentication protocols at
45 CFR 170.215. And, as mentioned above, the existing HIPAA Privacy and
Security Rules apply. As a covered entity under HIPAA, it is the
provider's responsibility to use and disclose data in accordance with
these existing rules.
As part of the DPC pilot, as one example, we are planning to test a
process that allows for the provider to add their active patients to a
roster through self-attestation, which is further checked against
claims to verify the provider has furnished services to the patient.
The provider must attest electronically that they have an active
treatment need for the data, and the provider must agree to the DPC
terms of use for each roster submitted or updated.\28\ This approach
was identified given the specific goals of the DPC pilot and the
provider and patient population involved. For new patients, payers
could consider a process for confirming a patient has an upcoming
appointment scheduled to facilitate data sharing when there is not a
claims history to use to verify a care relationship.
---------------------------------------------------------------------------

\28\ Data at the Point of Care. (n.d.). Terms of Service.
Retrieved from https://dpc.cms.gov/terms-of-service.
---------------------------------------------------------------------------

We recognize that the payers impacted by this proposed rule have a
variety of provider relationships to consider. We are therefore
proposing that each payer establish, implement, and maintain for
itself, a process to facilitate generating each provider's current
patient roster to enable this proposed payer-to-provider data sharing
via the Provider Access API.
We are proposing this at 42 CFR 431.61(a)(2) for state Medicaid
FFS, at 42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR
431.61(a)) for Medicaid managed care plans other than non-emergency
transportation (NEMT) PAHPs, at 42 CFR 457.731(a) for state CHIP FFS,
at 42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR
457.731(a)) for CHIP managed care, and at 45 CFR 156.222(a)(2) for QHP
issuers on the FFEs. To facilitate this data sharing, it is necessary
that providers give payers a list of the patients whose data they are
requesting. We do not wish to be overly prescriptive about how to
generate this list for all payers. But, we note that it would be
necessary for payers to put a process in place that is compliant with
existing HIPAA Privacy and Security Rules and provides the information
they need to complete their payer-specific compliance processes.
We request comments on this proposal. And, we also seek comment on
whether payers would like to maintain the option to define their own
process or if they would prefer us to require a process across payers,
such as the one we plan to test as part of the DPC pilot.
b. Opt-In
We are proposing that impacted payers would be permitted to put a
process in place for patients to opt-in to use of the Provider Access
API for data sharing between their payer and their providers. As with
the attribution process discussed above, we did not want to be overly
prescriptive regarding how this opt-in process might be implemented.
However, we are considering whether to suggest a specific process for
all payers who choose to implement this opt-in. One possible approach
might be for CMS to have all payers engaging in an opt-in approach to
include information about the ability to opt-in to this data sharing as
part of their annual notice or regular communication with patients--
such as when they communicate with patients about claims, and to permit
opt-in via a variety of options, including by phone, via a website, or
using an app, for instance.
Currently the HIPAA Privacy Rule does not require health plans to
obtain patient consent to share data with health care providers for
treatment purposes or care coordination, for instance. However, we
believe it is important to honor patient privacy preferences, and thus
see value in possibly providing patients with options regarding which
providers have access to their information as it relates to this
proposed policy. We do note, as discussed above, that all existing
applicable laws and regulations apply. This opt-in option is only
specific to using the Provider Access API as the means to share data
that the payer otherwise has authority to share with the provider.
Therefore, we are specifically proposing at 42 CFR

[[Page 82603]]

431.61(a)(3) for state Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply
with the requirement at 42 CFR 431.61(a)(3)) for Medicaid managed care,
at 42 CFR 457.731(a)(3) for state CHIP FFS, at 42 CFR 457.1233(d)(4)
(to comply with the requirement at 42 CFR 457.731(a)(3)) for CHIP
managed care, and at 45 CFR 156.222(a)(3) for QHP issuers on the FFEs
that payers may put a process in place to allow a patient to opt-in to
the Provider Access API data exchange for each provider from whom they
are currently receiving care or are planning to receive care.
We request comment on this proposal. In addition, we seek comment
on whether payers would like to maintain the option to define their own
process or if they would prefer CMS to suggest a process, such as the
examples provided above, for all payers who would be required to
implement and maintain the Provider Access API. We do note that we also
considered the following alternatives: (1) Permit an opt-out process,
(2) default to data sharing without patient engagement in the process
consistent with the HIPAA Privacy Rule, and require an opt-out process.
We seek comment on whether stakeholders would prefer we finalize an
opt-out versus an opt-in approach, and whether either opt-out, or as
currently proposed--opt-in, be permitted but not required. We request
comment on the associated benefits and burdens with these different
approaches, and any other considerations we should take into
consideration as we consider a final policy.
c. Provider Resources
We are proposing that payers make educational resources available
to providers that describe how a provider can request patient data
using the payer's Provider Access APIs in non-technical, simple, and
easy-to-understand language. This requirement would be codified at 42
CFR 431.61(a)(4) for Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply
with the requirement at 42 CFR 431.61(a)) for Medicaid managed care
other than NEMT PAHPs as defined at 42 CFR 438.2, at 42 CFR
457.731(a)(4) for CHIP FFS, at 42 CFR 457.1233(d)(4) (to comply with
the requirement at 42 CFR 457.731(a)) for CHIP managed care, and at 45
CFR 156.222(a)(4) for QHP issuers on the FFEs. As proposed, this would
include information on using both the individual patient request
function as well as the bulk data request function. We are proposing
that these resources be made available on the payer's website and
through other appropriate mechanisms through which the payer ordinarily
communicates with providers. We believe these resources would help
providers understand how they can leverage the available APIs to access
patient data, thus helping to ensure that the full value of the
proposed APIs is realized and that providers gain access to needed
patient data for use at the moment of care.
We request comment on this proposal.
d. Extensions and Exemptions for Medicaid and CHIP FFS Programs
If our proposals regarding the Provider Access API are finalized,
we would strongly encourage state Medicaid and CHIP FFS programs to
implement the Provider Access API as soon as possible understanding the
many benefits of the API as discussed previously in this section.
However, we also recognize that state Medicaid or CHIP FFS agencies
could face certain unique circumstances that would not apply to other
impacted payers, as discussed in more detail later in this section. As
a result, a few states might need to seek an extension of the
compliance deadline or an exemption from these requirements. To address
this concern, we are proposing a process through which states may seek
an extension of and, in specific circumstances, an exemption from, the
Provider Access API requirements if they are unable to implement these
API requirements. Providing for these flexibilities might allow these
states to continue building technical capacity in support of overall
interoperability goals consistent with their needs. We therefore
propose the following.
Extension. At 42 CFR 431.61(e)(1) and 42 CFR 457.731(e)(1),
respectively, we propose to provide states--for Medicaid FFS and CHIP
FFS--the opportunity to request a one-time extension of up to one (1)
year for implementation of the Provider Access API specified at 42 CFR
431.61(a) and 42 CFR 457.731(a). Unique circumstances that might
present a challenge to specific states to meet the proposed compliance
date could include resource challenges, such as funding. Depending on
when the final rule is published in relation to a state's budget
process and timeline, some states may not be able to secure the needed
funds in time to both develop and execute implementation of the API
requirements by the proposed compliance date. A one-year extension
could help mitigate this issue. And, some states may need to initiate a
public procurement process to secure contractors with the necessary
skills to support a state's implementation of these proposed API
policies. The timeline for an open, competed procurement process,
together with the time needed to onboard the contractor and develop the
API, could require additional time as well. Finally, a state might need
to hire new staff with the necessary skillset to implement this policy.
Again, the time needed to initiate the public employee hiring process,
vet, hire, and onboard the new staff may make meeting the proposed
compliance timeline difficult, because, generally speaking, public
employee hiring processes include stricter guidelines and longer time-
to-hire periods than other sectors.\29\ In all such situations, a state
might need more time than other impacted payers to implement the
requirements.
---------------------------------------------------------------------------

\29\ State hiring processes are comparable with federal hiring
processes. According to OMB, the average time-to-hire for federal
employees was 98.3 days in 2018, significantly higher than the
private sector average of 23.8 days. See: https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

If a state believes it can demonstrate the need for an extension,
its request must be submitted and approved as a part of its annual
Advance Planning Document (APD) for Medicaid Management Information
System (MMIS) operations costs and must include the following: (1) A
narrative justification describing the specific reasons why the state
cannot reasonably satisfy the requirement(s) by the compliance date,
and why those reasons result from circumstances that are unique to
states operating Medicaid or CHIP FFS programs, (2) a report on
completed and ongoing implementation activities to evidence a good
faith effort toward compliance, and (3) a comprehensive plan to meet
implementation requirements no later than one year after the initial
compliance date.
An extension would be granted if CMS determines based on the
information provided in the APD that the request adequately establishes
a need to delay implementation, a good faith effort to implement the
proposed requirements as soon as possible, and a clear plan to
implement no later than one year after the proposed compliance date. We
would expect states to explain why the request for an extension results
from circumstances that are unique to states operating Medicaid or CHIP
FFS programs. We also solicit comment on whether our proposal would
adequately address the unique circumstances that affect states, and
that might make timely compliance with the proposed API requirement
sufficiently difficult for states and thus justify an extension. In
particular, we seek comment on

[[Page 82604]]

whether we should require or use additional information on which to
base the determination or whether we should establish different
standards in the regulation text for evaluating and granting the
request.
Exemption. At 42 CFR 431.61(e)(2) and 42 CFR 457.731(e)(2),
respectively, we propose two circumstances that would permit state
requests for exemption; namely, (1) when at least 90 percent of all
covered items and services are provided to Medicaid or CHIP
beneficiaries through Medicaid or CHIP managed care contracts with
MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or
(2) when at least 90 percent of the state's Medicaid or CHIP
beneficiaries are enrolled in Medicaid or CHIP managed care
organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10
for CHIP. In both circumstances, the time and resources that the state
would need to expend to implement the API requirements may outweigh the
benefits of implementing and maintaining the API. Unlike other impacted
payers, state Medicaid and CHIP FFS programs do not have a diversity of
plans to balance implementation costs for those plans with low
enrollment. If there is low enrollment in a state Medicaid or CHIP FFS
program, there is no potential for the technology to be leveraged for
additional beneficiaries as states, unlike other payers, do not
maintain additional lines of business.
We acknowledge that the proposed exemption could mean that a few
Medicaid or CHIP FFS systems would not receive the benefits of having
this API available to facilitate health information exchange. To
address this, we propose that states meeting the above thresholds would
be expected to employ an alternative plan to enable the electronic
exchange and accessibility of health information for those
beneficiaries who are served under the FFS program.
A state meeting the above criteria would be permitted to submit a
request for an exemption to the requirements for the Provider Access
API once per calendar year for a one (1) year exemption. The state
would be required to submit this annual request as part of a state's
annual APD for MMIS operations costs. The state would be required to
include in its request documentation that it meets the criteria for the
exemption using data from any one of the three most recent and complete
calendar years prior to the date the exemption request is made. We note
we propose that this request be made annually as from year-to-year the
nature of the FFS population could change and so it is important that
the state provide the most current information for CMS' consideration.
Exemptions would be granted for a one-year period if a state
establishes to CMS' satisfaction that it meets the criteria for the
exemption and has established a plan to ensure that providers will have
efficient electronic access to the same information through alternative
means.
We request comment on the proposed extension and exemption.
For Medicaid and CHIP managed care, we are not proposing an
extension process at this time because we believe that managed care
plans are actively working to develop the necessary IT infrastructure
to be able to comply with the existing requirements in 42 CFR part 438
and part 457 and also benefit from efficiencies resulting from their
multiple lines of business impacted by these interoperability policies.
Many managed care plans are part of parent organizations that maintain
multiple lines of business, including Medicaid managed care plans and
plans sold on the Exchanges. As discussed in the CMS Interoperability
and Patient Access final rule (85 FR 25607, 25612, 25620), work done by
these organizations can benefit all lines of business and, as such, we
do not believe that the proposals in this rule impose undue burden or
are unachievable by the compliance date. We are soliciting comment on
whether our belief concerning the scope of resources and ability of
managed care parent organizations to achieve economies of scale is
well-founded. Further, we seek comment on whether an extension process
is warranted for certain managed care plans to provide additional time
for the plan to comply with the requirement at 42 CFR 438.61(a) (which
cross references 42 CFR 438.242(b)(7)) for Medicaid managed care plans
and at proposed 42 CFR 457.731(a) (which cross references 42 CFR
457.1223(d)(4)) for CHIP managed care entities. While we are not
proposing such a process for managed care plans and entities and do not
believe one is necessary for the reasons outlined here, we are open to
considering one if necessary. If we adopt an extension process for
these managed care plans and entities, what criteria would a managed
care plan or entity have to meet to qualify for an extension? Should
the process consider, for example, enrollment size, plan type, or some
unique characteristic of certain plans that could hinder their
achievement of the proposed requirements by the proposed compliance
date? Also, we seek comment on whether, if finalized such a process for
Medicaid managed care plans or CHIP managed care entities, the state or
CMS should manage the process and whether states could successfully
adopt and implement the process on the timeline necessary to fulfill
the goals and purposes of the process. Consistent with the exception
process proposed for QHP issuers on the FFEs at 45 CFR 156.222(d), we
would expect any extension request to include, at a minimum, a
narrative justification describing the reasons why a plan or entity
cannot reasonably satisfy the requirements by the proposed compliance
date, the impact of non-compliance upon enrollees, the current or
proposed means of providing electronic health information to providers,
and a corrective action plan with a timeline to achieve compliance.
e. Exception for QHP issuers
For QHP issuers on the FFEs, we propose an exception at 45 CFR
156.222(d) to these Provider Access API proposals. We propose that if
an issuer applying for QHP certification to be offered through a FFE
believes it cannot satisfy the proposed requirements in 45 CFR
156.222(a) for the Provider Access APIs, the issuer must include as
part of its QHP application a narrative justification describing the
reasons why the issuer cannot reasonably satisfy the requirements for
the applicable plan year, the impact of non-compliance upon providers
and enrollees, the current or proposed means of providing health
information to providers, and solutions and a timeline to achieve
compliance with the requirements of this section. We propose that the
FFE may grant an exception to the requirements in 45 CFR 156.222(a) for
the Provider Access APIs if it determines that making such health plan
available through such FFE is in the interests of qualified individuals
in the state or states in which such FFE operates. This proposal would
be consistent with the exception for QHP issuers on the FFEs we
finalized for the Patient Access API in the Interoperability and
Patient Access final rule (85 FR 25552 through 25553). For instance, as
noted in that final rule, that exception could apply to small issuers,
issuers who are only in the individual or small group market,
financially vulnerable issuers, or new entrants to the FFEs who
demonstrate that deploying standards based API technology consistent
with the required interoperability standards would pose a significant
barrier to the issuer's ability to provide coverage to consumers, and
not certifying the issuer's QHP or QHPs would result in consumers
having few

[[Page 82605]]

or no plan options in certain areas. We believe that having a QHP
issuer offer QHPs through an FFE is in the best interest of consumers
and would not want consumers to have to go without access to QHP
coverage because the issuer is unable to implement this API timely.
As mentioned in section II.A. of this proposed rule, although
Medicare FFS is not directly impacted by this rule, we do note that we
are targeting to implement a Provider Access API, if finalized. In this
way, the Medicare FFS implementation would conform to the same
requirements that apply to the impacted payers under this rulemaking,
as applicable, so that Medicare FFS beneficiaries would also benefit
from this data sharing.
7. Statutory Authorities for Provider Access API Proposals
a. Medicaid and CHIP
As is discussed in more detail below, our proposed requirements in
this section for Medicaid managed care plans and Medicaid state
agencies fall generally under the authority in the following provisions
of the statute.
Section 1902(a)(4) of the Act, which requires that a state
Medicaid plan provide such methods of administration as are found by
the Secretary to be necessary for the proper and efficient operation of
the state Medicaid plan.
Section 1902(a)(8) of the Act, which requires states to
ensure that Medicaid services are furnished with reasonable promptness
to all eligible individuals.
Section 1902(a)(19) of the Act, which requires states to
ensure that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
We note statutory authority for proposals to require specific IGs
for this and all APIs proposed in this rule is discussed in section
II.A.3. of this proposed rule.
We believe these proposals are generally consistent with all these
provisions of the Act, because they would help ensure that providers
can access data that could improve their ability to render Medicaid
services effectively, efficiently, and appropriately. The proposals are
thus expected to help states fulfill their obligations to operate their
state plans efficiently and to ensure that Medicaid services are
furnished with reasonable promptness and in a manner consistent with
the best interest of patients.
Proposing to require states to implement a Provider Access API to
share data about certain claims, encounter, and clinical data,
including data about pending and active prior authorization decisions,
for a specific individual beneficiary or for more than one beneficiary
at a time could improve the efficiency of and simplify how states
ensure the delivery of Medicaid services. This API would enable
providers to easily access accurate and complete beneficiary
utilization and authorization information at the time of care, or prior
to a patient encounter, and that, in turn, would enable the provider to
spend more time on direct care. This would support efficient and prompt
delivery of care as well as care in the best interest of patients.
These proposals also are expected to allow for better access to other
providers' prior authorization decisions. This would give a provider a
more holistic view of a patient's care that could reduce the likelihood
of ordering duplicate or misaligned services. This could also
facilitate easier and more informed decision making by the provider and
would therefore support efficient provision of care in the best
interest of patients. Additionally, because the data could be
incorporated into the provider's EHR or other practice management
system, the proposal is expected to support efficient access to and use
of the information. The proposal is expected to make it more likely
that a more complete picture of the patient could be available to the
provider at the point of care, which could result in the provision of
more informed and timely services. These process efficiencies may
ultimately improve practice efficiency and make more of providers' time
available for appointments. These outcomes and process efficiencies
would help states fulfill their obligations to ensure prompt access to
services in a simpler manner and in a manner consistent with the best
interest of beneficiaries, consistent with section 1902(a)(8) and (19)
of the Act, and the efficiencies created for providers might help the
state to administer its Medicaid program more efficiently, consistent
with section 1902(a)(4) of the Act.
The proposal related to the Bulk specification for the Provider
Access API would help facilitate data sharing about one or more
beneficiaries at once. This could further improve the efficiency and
simplicity of operations because it would eliminate the need for a
provider to make individual API calls when seeking information about a
large number of beneficiaries, taxing both the payer's and provider's
systems. The ability to receive beneficiary data in bulk would also
permit practices to analyze practice and care patterns across patient
populations, thus helping them to improve processes and maximize
efficiencies that could lead to better health outcomes. All of these
expected positive outcomes could help states fulfill their obligations
to ensure prompt access to services in a simpler manner and in a manner
consistent with the best interest of beneficiaries, consistent with
section 1902(a)(8) and (19) of the Act, and the efficiencies created
for providers might help the state to administer its Medicaid program
more efficiently, consistent with section 1902(a)(4) of the Act.
For CHIP, we are proposing these requirements under the authority
in section 2101(a) of the Act, which states that the purpose of title
XXI is to provide funds to states to provide child health assistance to
uninsured, low-income children in an effective and efficient manner
that is coordinated with other sources of health benefits coverage. We
believe this proposed rule could strengthen states' ability to fulfill
these title XXI statutory obligations in a way that recognizes and
accommodates the use of electronic information exchange in the health
care industry today and would facilitate a significant improvement in
the delivery of quality health care to CHIP beneficiaries.
When providers have access to patient utilization and authorization
information directly from their EHRs or other health IT systems, they
can provide higher quality care. Improving the quality of care aligns
with section 2101(a), which requires states to provide CHIP services in
an effective and efficient manner. The more information a provider has
to make informed decisions about a patient's care, the more likely it
is that patients will receive care that best meets their needs.
Additionally, providers can be more effective and efficient in their
delivery of CHIP services by having direct access to patient
utilization and authorization information. If a provider has
information about a patient prior to or at the point of care, the
provider will be able to spend more time focused on the patient versus
on their need to collect information. And, the information they do
collect will not be based solely on patient recall. As noted above for
Medicaid, this could save time, improve the quality of care, and
increase the total amount of direct care provided to CHIP
beneficiaries. When data are standardized, and able to be incorporated
directly into the provider's EHR or practice management system, they
can be leveraged as needed at the point of care by the provider, but
also be used to support coordination across

[[Page 82606]]

providers and payers. This is inherently more efficient, and
ultimately, more cost effective, as the information does not have to be
regularly repackaged and reformatted to be shared or used in a valuable
way. As such, the Provider Access API proposals also align with section
2101(a) in that these proposals could improve coordination between CHIP
and other health coverage. For these reasons, we believe this proposal
is in the best interest of the beneficiaries and within our
authorities.
b. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we are proposing these new
requirements under our authority in section 1311(e)(1)(B) of the
Affordable Care Act, which affords the Exchanges the discretion to
certify QHPs if the Exchange determines that making available such
health plans through the Exchange is in the interests of qualified
individuals in the state in which the Exchange operates. We note
statutory authority for proposals to require specific IGs for this and
all APIs proposed in this rule are discussed in section II.A.3. of this
proposed rule.
We believe that certifying only health plans that make enrollees'
health information available to their providers via the Provider Access
API is in the interests of enrollees. Giving providers access to their
patients' information supplied by QHP issuers on the FFEs would ensure
that providers are better positioned to provide enrollees with seamless
and coordinated care, and helps to ensure that QHP enrollees on the
FFEs are not subject to duplicate testing and procedures, and delays in
care and diagnosis. Access to the patients' more complete medical
information may also maximize the efficiency of an enrollee's office
visits. We encourage SBEs to consider whether a similar requirement
should be applicable to QHP issuers participating in their Exchanges.
We also believe that requiring QHP issuers on the FFEs to use the
Bulk specification for the Provider Access API would improve the
efficiency and simplicity of data transfers by allowing the provider to
get all the info for a full panel of patients at once.

C. Reducing the Burden of Prior Authorization Through APIs

1. Background
Improving the prior authorization process is an opportunity to
reduce burden for payers, providers, and patients. The proposals in
this rule build on the foundation set out in the CMS Interoperability
and Patient Access final rule to improve health information exchange
and increase interoperability in the health care system. Proposals in
this section were developed based on industry input from CMS sponsored
listening sessions, stakeholder meetings, and reports.
We use the term ``prior authorization'' to refer to the process
through which a provider must obtain approval from a payer before
providing care and prior to receiving payment for delivering items or
services. In some programs, this may be referred to as ``pre-
authorization'' or ``pre-claim review.'' Prior authorization
requirements are established by payers to help control costs and ensure
payment accuracy by verifying that an item or service is medically
necessary, meets coverage criteria, and is consistent with standards of
care before the item or service is provided rather than undertaking
that review for the first time when a post-service request for payment
is made. However, stakeholders have stated that diverse payer policies,
provider workflow challenges, and technical barriers have created an
environment in which the prior authorization process is a primary
source of burden for both providers and payers, a major source of
burnout for providers, and a health risk for patients when it causes
their care to be delayed.
The policies in this proposed rule would apply to any formal
decision-making process by which impacted payers render an approval or
disapproval determination, or decision, regarding payment for clinical
care based on the payer's coverage guidelines and policies before
services are rendered or items provided.
We have been studying prior authorization and its associated burden
to identify the primary issues that stakeholders believe need to be
addressed to alleviate that burden. To advance the priorities of the
21st Century Cures Act,\30\ specifically the aim to reduce burden, ONC
and CMS created a working group to investigate the prior authorization
ecosystem and identify opportunities for potential solutions. Burdens
associated with prior authorization include difficulty in determining
payer-specific requirements related to items and services that require
prior authorization; inefficient use of provider and staff time to
submit and receive prior authorization requests through burdensome
channels such as fax, telephone, and various web portals; and
unpredictable and lengthy amounts of time to receive payer decisions.
---------------------------------------------------------------------------

\30\ ONC Strategy to reduce provider burden. Report required
under the 21st Century Cures Act: https://www.healthit.gov/topic/usability-and-provider-burden/strategy-reducing-burden-relating-use-health-it-and-ehrs.
---------------------------------------------------------------------------

In 2018, the American Medical Association (AMA) conducted a
physician survey that indicated a weekly per-physician average of 31
prior authorization requests, consuming an average of 14.9 hours of
practice time per workweek for physicians and their staff.
Additionally, 36 percent of physicians have staff that work exclusively
on prior authorizations.\31\ In 2019, CMS conducted a number of
listening sessions with payers, providers, patients, and other industry
representatives to gain insight into issues with prior authorization
processes and to identify potential areas for improvement. While both
providers and payers agreed that prior authorization provides value to
the health care system through cost control, utilization management,
and program integrity measures, some stakeholders expressed concerns
that certain steps in the prior authorization processes are burdensome.
For example, the information required from payers to receive prior
authorization can be inconsistent from payer to payer, and it can be
difficult for providers to determine the rules for items or services
that require prior authorization or what documentation is needed to
obtain approval. Furthermore, the documentation requirements are not
centralized because the rules vary for each payer, and access to those
requirements may require the use of proprietary portals. These
challenges were described in the ONC 2020 report on reducing electronic
health record burdens, which stated, ``Each payer has different
requirements and different submission methods, and clinicians report
finding it burdensome and time-consuming trying to determine whether
prior authorization requirements exist for a given patient, diagnosis,
insurance plan, or state.'' \32\
---------------------------------------------------------------------------

\31\ American Medical Association. (2019, February). 2018 AMA
Prior Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/files/2019-02/prior-auth-2018.pdf.
\32\ Office of the National Coordinator for Health Information
Technology. (n.d.) Strategy on Reducing Regulatory and
Administrative Burden Relating to the Use of Health IT and EHRs [PDF
file]. Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
---------------------------------------------------------------------------

In the CMS listening sessions, as well as the surveys and reports
referenced throughout this section, stakeholders suggested that payers
should disclose their prior authorization requirements in a standard
format. Stakeholders raised concerns that once a provider has
identified the appropriate prior authorization requirement for a given

[[Page 82607]]

patient, payer, and item or service, the process of submitting a prior
authorization request relies on an array of cumbersome submission
channels, including payer-specific web-based portals, telephone calls,
and fax exchange technology. In addition, after a provider has
completed the process of submitting a prior authorization request and
received approval for an item or service from a particular payer, the
provider may need to re-submit a new prior authorization request for
the same, already approved, item or service should the patient
experience a change in health coverage, which could include switching
payers, or switching between private coverage and public coverage.
Should this occur, the provider must start the prior authorization
process anew with the patient's new payer, which may have different
documentation requirements and submission formats.
In 2017, a coalition of 16 provider organizations collaborated with
payer associations to develop a set of principles to identify ways to
reduce administrative burdens related to prior authorizations and
improve patient care. The coalition published a consensus paper
identifying 21 specific opportunities for improvement in prior
authorization programs and processes and specifically called out the
need for industry-wide adoption of electronic prior authorization to
improve transparency and efficiency.\33\ Nonetheless, industry is still
at a point where payers and IT developers have addressed prior
authorization in an ad hoc manner with the implementation of unique
interfaces that reflect their own technology considerations, lines of
business, and customer-specific constraints.\34\ The proposals in this
proposed rule reflect several principles cited in the industry
consensus statement, including transparency and communication regarding
prior authorization to encourage effective communication between health
plans, providers, and patients to minimize care delays and articulate
prior authorization requirements, as well as automation to improve
transparency, through the adoption and implementation of electronic
prior authorization with the potential to streamline and improve the
process for all stakeholders.
---------------------------------------------------------------------------

\33\ American Medical Association. (2018). Consensus Statement
on Improving the Prior Authorization Process. Retrieved from https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc-public/prior-authorization-consensus-statement.pdf.
\34\ Office of the National Coordinator for Health Information
Technology. (2020, February). Strategy on Reducing Regulatory and
Administrative Burden Relating to the Use of Health IT and EHRs.
Retrieved from https://www.healthit.gov/sites/default/files/page/2020-02/BurdenReport_0.pdf.
---------------------------------------------------------------------------

There is increasing demand from providers, with support from the
payer and vendor community, as well as the Secretary's advisory
committees, to address the burdens associated with the prior
authorization process. In March and November of 2019, the Health IT
Advisory Committee (HITAC) and National Committee on Vital and Health
Statistics (NCVHS) held joint hearings with stakeholders to discuss the
ongoing challenges with prior authorization workflow, standards, and
payer policies. During these hearings, payers and providers agreed that
solutions to address prior authorization issues may not rest with one
single action, but, rather, they believed that the opportunity to use
new standards and/or technology, coupled with the movement towards more
patient focused policies, would provide substantial relief and
progress. At the November 13, 2019 NCVHS Full Committee meeting,\35\
ONC joined NCVHS and invited six industry experts to discuss ongoing
challenges with prior authorization standards, policies, and practices.
The themes from panelists were consistent with information provided
elsewhere in this proposed rule, that changes are still needed in
technology, payer policies, and payer/provider workflow. America's
Health Insurance Plans (AHIP) reported the results of its 2019 fall
plan survey, which included both AHIP and non-AHIP members, and
reported that plans were evaluating opportunities for prior
authorization policy changes to address issues. AHIP launched a pilot
of alternative prior authorization strategies with several plans in
2020.\36\ In early 2020, NCVHS and HITAC convened another task force,
the Intersection of Clinical and Administrative Data (ICAD), which met
weekly to address an overarching charge to convene industry experts and
produce recommendations related to electronic prior authorizations.\37\
The task force report was presented to HITAC in November 2020.\38\
Several recommendations pertaining to the use of FHIR based APIs for
prior authorization were included in the ICAD report, and are
consistent with proposals in this proposed rule. Those recommendations
and others are described in more detail in the section II.E. of this
proposed rule.
---------------------------------------------------------------------------

\35\ National Committee on Vital and Health Statistics. (2019,
November 13). Committee Proceedings [Transcript]. Retrieved from
https://ncvhs.hhs.gov/wp-content/uploads/2019/12/Transcript-Full-Committee-Meeting-November-13-2019.pdf.
\36\ America's Health Insurance Plans. (2020, January 6). New
Fast PATH Initiative Aims to Improve Prior Authorization for
Patients and Doctors. Retrieved from https://www.ahip.org/new-fast-path-initiative-aims-to-improve-prior-authorization-for-patients-and-doctors/.
\37\ See https://www.healthit.gov/hitac/committees/intersection-clinical-and-administrative-data-task-force.
\38\ Final report from ICAD Task Force November 17, 2020:
https://www.healthit.gov/sites/default/files/page/2020-11/2020-11-17_ICAD_TF_FINAL_Report_HITAC.pdf.
---------------------------------------------------------------------------

In a November 4, 2019 letter to the CMS Administrator, the American
Hospital Association (AHA) described the ongoing impact of prior
authorization on patient care, health system costs, and burdens.\39\ In
the letter, the AHA shared results from the previously referenced 2018
AMA survey of more than 1,000 physicians, which indicated that 90
percent of respondents stated prior authorization had a significant or
somewhat negative clinical impact on care.\40\ Furthermore, 27 percent
of survey respondents stated that delays in the provision of care due
to prior authorization processes had led to a serious adverse event
such as a death, hospitalization, disability, or permanent bodily
damage. The AHA's letter affirmed what we have stated above--prior
authorization is a burden that can lead to patient harm. According to
the AHA, hospitals and provider offices have many full-time employees
whose sole role is to manage payer prior authorization requests. One
hospital system spends $11 million annually just to comply with payer
prior authorization requirements. Operational costs such as these are
often factored into negotiated fees or charges to patients to ensure
financial viability for health care organizations including providers
and facilities, and we believe this to be the case for small and large
organizations. We believe our proposals in the following sections would
make meaningful progress in alleviating the burdens described above and
facilitating more efficient and prompt health care service delivery to
patients.
---------------------------------------------------------------------------

\39\ American Hospital Association. (2019, November 4). RE:
Health Plan Prior Authorization [PDF file]. Retrieved from https://www.aha.org/system/files/media/file/2019/11/aha-to-cms-health-plan-prior-authorization-11-4-19.pdf.
\40\ American Medical Association. (2019, February). 2018 AMA
Prior Authorization (PA) Physician Survey. Retrieved from https://www.ama-assn.org/system/files/2019-02/prior-auth-2018.pdf.
---------------------------------------------------------------------------

2. Electronic Options for Prior Authorization
To mitigate provider burden, and improve care delivery to patients,
we are proposing requirements for payers to implement APIs that are
conformant with certain implementation guides that

[[Page 82608]]

would facilitate the exchange of information between payers and
providers and allow providers to more effectively integrate the prior
authorization process within their clinical workflow. We believe, and
stakeholder input has confirmed, that payers and providers do not take
advantage of standards that are currently available for the exchange of
electronic prior authorization transactions and resort to proprietary
interfaces and web portals supplemented by inefficient and time
consuming manual processes such as phone calls or faxes. However, if
payers made the requirements for prior authorization more accessible
and understandable through APIs, and providers had access to the tools
to initiate a prior authorization from within their workflow, providers
would be more likely to submit the request and necessary documentation
to the payer using electronic standards.
In section II.B.2. of this proposed rule, we reference transactions
for which the Secretary must adopt electronic standards for use by
covered entities (health plans, health care clearinghouses, and certain
health care providers), and list the transactions there. The two
standards adopted for referrals certifications and authorizations
(hereafter referred to as the prior authorization transaction standard)
under HIPAA (45 CFR 162.1302) include:
NCPDP Version D.0 for retail pharmacy drugs; and
X12 Version 5010x217 278 (X12 278) for dental,
professional, and institutional request for review and response for
items and services.
Though payers are required to use the X12 278 standard for
electronic prior authorization transactions, and providers have been
encouraged to conduct the transaction electronically, the prior
authorization standard transaction has not achieved a high adoption
rate by covered entities. The Council for Affordable and Quality Health
Care (CAQH) releases an annual report called the CAQH Index, which
includes data on payer and provider adoption of HIPAA standard
transactions. In the 2019 report, among the seven transactions
benchmarked, prior authorization using the X12 278 standard was the
least likely to be supported by payers, practice management systems,
vendors, and clearinghouse services.\41\ According to this report, 14
percent of the respondents indicated that they were using the adopted
standard in a fully electronic way while 54 percent responded that they
were conducting electronic prior authorization using web portals,
Integrated Voice Response (IVR) and other options, and 33 percent were
fully manual (phone, mail, fax, and email). Reported barriers to use of
the HIPAA standard include lack of vendor support for provider systems,
inconsistent use of data content from the transaction, and lack of an
attachment standard to submit required medical documentation (CAQH
Index). The proposed PAS API could support increased use of the HIPAA
standard through its capability to integrate with a provider's system
directly, automation, and improved timeliness for obtaining a response
to a prior authorization request, particularly when paired with the
DRLS API. However, we are interested in hearing from commenters if
there are other steps CMS could take to further implementation of the
X12 278 standard and what challenges would remain if the standard was
more widely utilized.
---------------------------------------------------------------------------

\41\ CAQH. (2019). 2019 CAQH Index: A Report of Healthcare
Industry Adoption of Electronic Business Transactions and Cost
Savings [PDF file]. Retrieved from https://www.caqh.org/sites/default/files/explorations/index/report/2019-caqh-index.pdf?token=SP6YxT4u.
---------------------------------------------------------------------------

HIPAA also requires that HHS adopt operating rules for the HIPAA
standard transactions. Operating rules are defined at 45 CFR 162.103 as
the ``necessary business rules and guidelines for the electronic
exchange of information that are not defined by a standard or its
implementation specifications as adopted for purposes of HIPAA
Administrative Simplification.'' The NCVHS reviews potential HIPAA
operating rules and advises the Secretary as to whether HHS should
adopt them (section 1173(g) of the Act). The Secretary adopts operating
rules in regulations in accordance with section 1173(g)(4) of the Act.
To date, HHS has adopted operating rules for three of the HIPAA
standard transactions: Eligibility for a health plan and health care
claim status (76 FR 40458), health care electronic funds transfers
(EFT), and remittance advice (77 FR 48008). In February 2020, CAQH,
which develops operating rules for HIPAA standards, submitted two
operating rules for the HIPAA referral certification and authorization
transaction for consideration to NCVHS, which held a hearing to discuss
those operating rules in August 2020. Should HHS adopt operating rules
for the HIPAA referral certification and authorization transaction, we
would evaluate them to determine their effect, if any, on proposals in
this proposed rule.
3. Proposed Requirement for Payers: Documentation Requirement Lookup
Service (DRLS) API
Based on information from the listening sessions and non-
governmental surveys, we believe one of the most highly burdensome
parts of the prior authorization process for payers and providers
include identifying the payer rules and determining what documentation
is required for an authorization. As described earlier, this issue is
one of the key principles in the industry consensus paper \42\ under
transparency and communication, in which the parties agreed to
``encourage transparency and easy accessibility of prior authorization
requirements, criteria, rationale, and program changes to contracted
health care providers and patients/enrollees.'' In concert with this
effort towards collaboration, the AMA launched an outreach campaign
called #fixpriorauth \43\ to drive awareness to the scope of the
challenges of the prior authorization process. Industry input
underscores the fact that while there is no single solution to
improving the prior authorization process, some action on certain
burdens could be transformative. Therefore, we propose to streamline
access to information about prior authorization and related
documentation requirements to potentially reduce this burden. To that
end, at 42 CFR 431.80(a)(1), 438.242(b)(7), 457.732(a)(1),
457.1233(d)(4), and 45 CFR 156.223(a)(1), we propose to require that,
beginning January 1, 2023 (for Medicaid managed care plans and CHIP
managed care entities, by the rating period beginning on or after
January 1, 2023), state Medicaid and CHIP FFS programs, Medicaid
managed care plans, CHIP managed care entities, and QHP issuers on the
FFEs, implement and maintain a FHIR-based DRLS API conformant with the
HL7 FHIR Da Vinci Coverage Requirements Discovery (CRD) IG: Version STU
1.0.0 \44\ and the HL7 FHIR Da Vinci Documentation Templates and Rules
(DTR): Version STU 1.0.0 \45\ IG, populated with their list of covered
items and services, not

[[Page 82609]]

including prescription drugs and/or covered outpatient drugs, for which
prior authorization is required, and with the organization's
documentation requirements for submitting a prior authorization
request, including a description of the required documentation.
---------------------------------------------------------------------------

\42\ Consensus Statement for Improving Prior Authorization:
https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc-public/prior-authorization-consensus-statement.pdf.
\43\ AMA website link with resources regarding the prior
authorization challenges: https://fixpriorauth.org/resources.
\44\ HL7 International. (n.d.). Da Vinci Coverage Requirements
Discovery (CRD) FHIR Implementation Guide. Retrieved from https://hl7.org/fhir/us/davinci-crd/history.html.
\45\ HL7 International. (n.d.). Da Vinci Documentation Templates
and Rules. Retrieved from https://hl7.org/fhir/us/davinci-dtr/history.html.
---------------------------------------------------------------------------

Through a proposed cross-reference to the Patient Access API
requirements at 42 CFR 431.80(a)(1) for Medicaid FFS; at 42 CFR
438.242(b)(7) (to comply with the requirement at 42 CFR 431.80) for
Medicaid managed care; at 42 CFR 457.732(a)(1) for CHIP FFS; at 42 CFR
457.1233(d)(4) (to comply with the requirement at 42 CFR 457.732) for
CHIP managed care; and at 45 CFR 156.223(a)(1) for QHP issuers on the
FFEs, we are proposing to require that the DRLS API comply with the
same technical standards, API documentation requirements, and
discontinuation and denial of access requirements as apply to the
Patient Access API (and as proposed for the Provider Access API in
section II.B. of this proposed rule). For a complete discussion of
these requirements, we refer readers to the CMS Interoperability and
Patient Access final rule (85 FR 25526 through 25550).
We believe payer implementation of DRLS APIs conformant with the
CRD and DTR IGs which are proposed at 45 CFR 170.215(c)(1) and (2) in
section II.E. of this proposed rule, would make prior authorization
requirements and other documentation requirements electronically
accessible and more transparent to health care providers at the point
of care. As explained, because each payer has different rules to
determine when a prior authorization is required, and what information
is necessary to obtain approval, providers must use different methods
to keep track of the rules and requirements, which is often time
consuming and cumbersome. The payer's DRLS API would enable a query to
their prior authorization requirements for each item and service and
identify in real time the specific rules and documentation
requirements. Based on the information, the provider could be prepared
to submit any necessary documentation to the payer based on those
requirements, and complete any available electronic forms or templates,
which would be incorporated into the API. For example, once the payer
has built a DRLS API and made it available, a provider could initiate a
query to the payer's DRLS API to determine if a prior authorization and
documentation is required. If the response is affirmative, the DLRS API
would indicate what is required, and might provide a link to submit the
required documentation. In some cases, certain patient data available
in the provider's system could be used to meet documentation
requirements.
Payers who implement and maintain a DRLS API could see improvements
and efficiencies in the prior authorization process within their own
organization, by reducing the number of unnecessary requests,
minimizing follow up, and through fewer denials or appeals. For similar
reasons, this could contribute to burden reduction for providers as
well. We believe that requiring impacted payers to implement the API
would increase provider demand for this functionality if offered by
these payers. Providers would want access to the API if the payer does
offer it. We are interested in comments on steps that HHS could take to
encourage development of these functions within provider EHR systems.
We are also interested in comments for consideration for future
policies to require or incentivize providers to use the payer DRLS API
in their workflows.
By the time this proposed DRLS API would be required to be
implemented beginning January 1, 2023 should this proposal be finalized
as proposed, impacted payers would have the technology needed to
support a FHIR API, because they would have implemented the Patient
Access API as adopted in the CMS Interoperability and Patient Access
final rule (85 FR 25558 through 25559). We intend to enforce the
requirement for a Patient Access API, as adopted in that rule, starting
July 1, 2021, taking into account the 6 months of enforcement
discretion we are exercising due to the public health emergency.\46\ In
order to implement the Patient Access API, payers will have installed
the FHIR servers, mapped claims and clinical data for data exchange via
FHIR, and implemented a FHIR API. We believe the experience of
implementing the Patient Access API, including having made upgrades to
their computer systems and trained or hired staff to support its use,
would enable impacted payers under this proposed rule to implement the
DRLS API by January 1, 2023 (or, for Medicaid managed care plans and
CHIP managed care entities, by the rating period beginning on or after
January 1, 2023). We considered whether it would be beneficial for
payers to implement the proposed DRLS APIs in phases. For example, we
considered whether payers should implement the DRLS API via an
incremental approach, incorporating the top 10 percent or top 10
highest volume prior authorization rules in the first year, and
continue adding to the DRLS API over a 2- or 3-year period before the
DRLS is fully implemented. However, we believe that fully implementing
the DRLS API in year one of such a phased timeline, by January 1, 2023,
would be critical to streamlining the prior authorization process, and
would be instrumental in moving towards increased use of electronic
prior authorization.
---------------------------------------------------------------------------

\46\ For more information, visit: https://www.cms.gov/Regulations-and-Guidance/Guidance/Interoperability/index.
---------------------------------------------------------------------------

We request comments on this proposal for impacted payers to
implement a DRLS API. We also request input on a potential short-term
solution to address the challenge of accessing payer requirements for
prior authorizations. We solicit feedback on how payers currently
communicate prior authorization requirements, and on the potential for
payers to post, on a public-facing website, their list of items and
services for which prior authorization is required, populate the
website with their associated documentation rules as in interim step
while they implement the DRLS. This is not intended to harmonize prior
authorization requests, but rather to quickly address the issue
identified by stakeholders regarding access to prior authorization
information. If payers could post their prior authorization
requirements on a website, how could that information be presented and
organized for providers to easily identify the services and items which
require prior authorization? Finally, we request comments on how the
posting of this information on payer websites would provide a
satisfactory interim solution to the challenge of accessing payer
requirements for prior authorizations in advance of implementing the
DRLS API.
4. Proposed Requirement for Payers: Implementation of a Prior
Authorization Support API
Electronic prior authorizations are not used consistently between
payers and providers, even with the availability of an adopted HIPAA
standard. The burden of navigating the various submission mechanisms
falls on the provider and can detract from providing care to patients.
Additionally, many provider administrative practice management systems
and vendors do not support the adopted HIPAA standard. To help address
this issue, we are proposing that impacted payers implement a Prior
Authorization Support (PAS) API that facilitates a HIPAA compliant
prior authorization request and response, including any forms or
medical record documentation

[[Page 82610]]

required by the payer for items or services for which the provider is
seeking authorization.
Specifically, we propose to require that Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs implement and maintain a PAS API conformant
with the HL7 FHIR Da Vinci Prior Authorization Support (PAS) IG
beginning January 1, 2023 (for Medicaid managed care plans and CHIP
managed care entities, by the rating period beginning on or after
January 1, 2023). We propose to codify this requirement at 42 CFR
431.80(a)(2) and 457.732(a)(2), and 45 CFR 156.223(a)(2) and, as with
our proposal for the Provider Access API (discussed in section II.B. of
this proposed rule), we propose to use cross-references in 42 CFR
438.242(b)(7) and 42 CFR 457.1233(d)(4) to impose this new PAS API
requirement on Medicaid managed care plans and CHIP managed care
entities. The API would be required to be conformant with the
implementation specification at 45 CFR 170.215(c)(3). If this provision
is finalized as proposed, the payer would be required to implement the
API, and, when sending the response, include information regarding
whether the organization approves (and for how long), denies, or
requests more information for the prior authorization request, along
with a reason for denial in the case of a denial. The PAS API would
provide an opportunity to leverage the convenience of API technology,
while maintaining compliance with the adopted HIPAA transaction
standard. Furthermore, use of the PAS API would accelerate adoption and
use of electronic prior authorization transactions by impacted payers
and by providers, particularly when coupled with implementation of the
DRLS API, increasing efficiencies for both parties.
We are aware that the flow of the payer API may not be intuitive to
all readers, therefore, please refer to the implementation guides for
payer API flow details. We also provide a high-level description here.
The payer would make a PAS API available for providers. When a patient
needs authorization for a service, the payer's PAS API would enable the
provider, at the point of service, to send a request for an
authorization. The API would send the request through an intermediary
(such as a clearinghouse) that would convert it to a HIPAA compliant
X12 278 request transaction for submission to the payer. It is also
possible that the payer converts the request to a HIPAA compliant X12
278 transaction, and thus the payer acts as the intermediary. The payer
would receive and process the request and include necessary information
to send the response back to the provider through its intermediary,
where the response would be transformed into a HIPAA compliant 278
response transaction. The response through the API would indicate
whether the payer approves (and for how long), denies, or requests more
information related to the prior authorization request, along with a
reason for denial in the case of a denial.
We believe it would be valuable for payers to implement the PAS API
for prior authorizations, because doing so would enhance the overall
process generally, and, specifically, would increase the uptake of
electronic prior authorizations by providers. Implementation of the PAS
API would also maintain compliance with the adopted HIPAA standards, so
other legacy system changes may not be necessary. We also believe that
existing business arrangements with intermediaries or clearinghouses
would remain in place to support transmission of the X12 transaction.
Payers who implement the PAS API would likely see an improvement in
efficiencies, particularly when coupled with implementation of the DRLS
API because when providers know clearly what documentation is required
to support a prior authorization request, they do not need to call or
fax for additional instructions. Fewer phone calls or errors would
decrease administrative costs for a payer. Use of the PAS API could
facilitate a real time exchange of the authorization request, so that
payers could provide a real time response.
In particular, we expect that our proposals to require payers to
implement the DRLS and PAS APIs would improve the electronic data
exchange landscape between the impacted payers and providers once
providers' practice management system or EHR make the connection to the
payer's API. That is why it is important for the payers to make the
APIs available first. It is burdensome and time-consuming for providers
to use multiple mechanisms--including numerous payer-specific web
portals and fax numbers--to submit prior authorization requests and
receive prior authorization decisions. Our outreach and industry
research show that providers are eager for the opportunity to have
access to this technology to reduce burden.
We request comment on these proposals.
We believe that requiring the impacted payers to implement the FHIR
based APIs that would be available for providers might ultimately
result in broader industry-wide changes to address the prior
authorization issues identified by stakeholders and discussed above.
Similarly, if the APIs are successfully implemented by the impacted
payers as proposed, the demand for this functionality would motivate
EHR vendors to invest in integrating a PAS API directly into a
provider's workflow, which might ultimately result in APIs becoming the
preferred and primary method to facilitate prior authorization
processes. As with the proposed DRLS API, we note that functionality to
interact with the proposed PAS API is not standardized across provider
systems today, but that industry interest in this initiative is
extremely high. Industry participation is increasing in the HL7 work
groups developing and testing the IGs for these APIs, including
increased participation by providers, payers, and vendors. We believe
that EHR developers would increasingly make this functionality
available to their customers to support increased use of the payer APIs
should this proposed rule be finalized. We request comment on steps
that HHS could take to educate providers on the benefits of these APIs
and incentive their use. We also request comment on opportunities to
encourage health IT developers to implement these functions within
EHRs, including the potential future addition of certification criteria
in the ONC Health IT Certification Program.
a. Requirement To Provide a Reason for Denial
When a provider has submitted an electronic prior authorization
request, there is an expectation for a response to indicate that an
item or service is approved (and for how long), denied, or if there is
a request for more information. Regardless of the mechanism through
which a prior authorization request is received and processed, in the
case of a denial, providers need to know why the request has been
denied, so that they can either re-submit it with updated information,
identify alternatives, appeal the decision, or communicate the decision
to their patients. A payer might deny a prior authorization because the
items or services are not covered, because the items or services are
not medically necessary, or because documentation to support the
request was missing or inadequate. However, payers do not always
provide consistent communication about the reasons for denials or
information about what is required for approval.

[[Page 82611]]

To improve the timeliness, clarity, and consistency of information
for providers regarding prior authorization status, specifically
denials, we are proposing that impacted payers send certain response
information regarding the reason for denying a prior authorization
request. Based on the surveys referenced above, stakeholders agree that
payers do not provide consistent information about the status of a
prior authorization or the reasons for a denial, nor do they use the
adopted X12 278 HIPAA standard transaction to communicate prior
authorization status information. Therefore, we propose at 42 CFR
431.80(a)(2)(iii) for Medicaid FFS, at 42 CFR 438.242(b)(7) (to comply
with the requirement at 42 CFR 431.80) for Medicaid managed care, at 42
CFR 457.732(a)(2)(iii) for CHIP FFS, at 42 CFR 457.1233(d)(4) (to
comply with the requirement at 42 CFR 457.732) for CHIP managed care,
and at 45 CFR 156.223(a)(2)(iii) for QHP issuers on the FFEs that
impacted payers transmit, through the proposed PAS API, information
regarding whether the payer approves (and for how long), denies, or
requests more information related to the prior authorization request.
In addition, we propose at 42 CFR 431.80(a)(2)(iv) for Medicaid FFS, at
42 CFR 438.242(b)(7) (to comply with the requirement at 42 CFR 431.80)
for Medicaid managed care, at 42 CFR 457.732(a)(2)(iv) for CHIP FFS, at
42 CFR 457.1233(d)(4) (to comply with the requirement at 42 CFR
457.732) for CHIP managed care, and at 45 CFR 156.223(a)(2)(iv) for QHP
issuers on the FFEs that impacted payers include a specific reason for
denial with all prior authorization decisions, regardless of the method
used to send the prior authorization decision.
Under our proposal, impacted payers would be required to provide a
specific reason a prior authorization request is denied, such as
indicating necessary documentation was not provided, the services are
not determined to be medically necessary, or the patient has exceeded
limits on allowable (that is, covered) care for a given type of item or
service, so that a provider is notified why a request was denied and
can determine what their best next steps may be to support getting the
patient the care needed in a timely manner. A clear and specific reason
for a denial would help ensure both providers and payers have the
opportunity to benefit from consistent communication, and supports our
drive to reduce payer, provider, and even patient burden.
States operating Medicaid and CHIP programs may be able to access
federal matching funds to support their implementation of the DRLS and
PAS APIs, because these APIs are expected to help the state administer
its Medicaid and CHIP state plans properly and efficiently by
supporting a more efficient prior authorization process, consistent
with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more
detail in section II.C.7.a. of this proposed rule.
We do not consider state expenditures for implementing this
proposal to be attributable to any covered item or service within the
definition of ``medical assistance.'' Thus, we would not match these
expenditures at the state's regular federal medical assistance
percentage. However, federal Medicaid matching funds under section
1903(a)(7) of the Act, at a rate of 50 percent, for the proper and
efficient administration of the Medicaid state plan, might be available
for state expenditures related to implementing this proposal for their
Medicaid programs, because use of the DRLS and PAS APIs would help the
state more efficiently administer its Medicaid program by increasing
the efficiencies in the prior authorization process. For instance, use
of these APIs would allow administrative efficiencies by making the
process more timely, and by helping reduce the number of denied and
appealed prior authorization decisions, making the process more clear
and transparent via the APIs.
States' expenditures to implement these proposed requirements might
also be eligible for enhanced 90 percent federal Medicaid matching
funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can
be attributed to the design, development, or installation of mechanized
claims processing and information retrieval systems. Additionally, 75
percent federal matching funds under section 1903(a)(3)(B) of the Act
may be available for state expenditures to operate Medicaid mechanized
claims processing and information retrieval systems to comply with this
proposed requirement.
States request Medicaid matching funds under section
1903(a)(3)(A)(i) or (B) of the Act through the APD process described in
45 CFR part 95, subpart F. States are reminded that 42 CFR
433.112(b)(12) and 433.116(c) require them to ensure that any system
for which they are receiving enhanced federal financial participation
under section 1903(a)(3)(A)(i) or (B) of the Act aligns with and
incorporates the ONC Health Information Technology standards adopted in
accordance with 45 CFR part 170, subpart B. The DRLS and PAS APIs, and
all APIs proposed in this rule, would complement this requirement
because these APIs further interoperability through the use of HL7 FHIR
standards proposed for adoption by ONC for HHS use at 45 CFR
170.215.\47\ And, states are reminded that 42 CFR 433.112(b)(10)
explicitly supports exposed APIs as a condition of receiving enhanced
federal financial participation under section 1903(a)(3)(A)(i) or (B)
of the Act.
---------------------------------------------------------------------------

\47\ See SHO # 20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
---------------------------------------------------------------------------

Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of
Medicaid technologies and systems as a condition of receiving enhanced
federal financial participation under section 1903(a)(3)(A)(i) or (B)
of the Act. CMS would interpret that sharing and re-use requirement
also to apply to technical documentation associated with a technology
or system, such as technical documentation for connecting to a state's
APIs. Making the needed technical documentation publicly available so
that systems that need to connect to the APIs proposed in this rule can
do so would be required as part of the technical requirements at 42 CFR
431.60(d) for all proposed APIs in this rule, including the DRLS and
PAS APIs.
Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act,
limiting administrative costs to no more than 10 percent of CHIP
payments to the state, would apply in developing the APIs proposed in
this rule.
We note that the temporary federal medical assistance percentage
(FMAP) increase available under section 6008 of the Families First
Coronavirus Response Act (Pub. L. 116-127) does not apply to
administrative expenditures.
b. Program Specific Notice Requirements To Accompany Prior
Authorization Denial Information--Medicaid and CHIP Managed Care
Some of the payers impacted by this proposed rule are required by
existing regulations to notify providers and patients when they have
made an adverse decision regarding a prior authorization. The proposal
above to send a denial reason would not reduce or replace such existing
notification requirements. Rather, the proposed requirement to use the
PAS API to provide a notification whether the authorization has been
approved (and for how long) or denied (along with a reason for the
denial) would supplement current notice requirements for those payers,
and offer an efficient method of providing such information for those
payers who currently do not have a requirement to notify providers of
the decision on a prior authorization request. We believe use of the
proposed

[[Page 82612]]

denial reasons in addition to the notification requirements provides
enhanced communication which increases transparency and would reduce
burden and improve efficiencies for both payers and providers.
For Medicaid managed care plans and CHIP managed care entities,\48\
existing regulations at 42 CFR 438.210(c) requires notice to the
provider without specifying the format or method while 42 CFR
438.210(c) and 42 CFR 438.404(a) require written notice to the enrollee
of an adverse benefit determination. As part of our proposal, we intend
that an indication of whether the payer approves, denies, or requests
more information for the prior authorization request, if transmitted to
providers via the PAS API, and a denial reason in the case of denial,
would be sufficient to satisfy the current requirement for notice to
providers at 42 CFR 438.210(c) and (d). Therefore, the payer would not
be required to send the response via the PAS API and a denial reason,
as well as a separate notice in another manner to the provider with
duplicate information. We remind managed care plans that their
obligations to provide these required notices would not be reduced or
eliminated regardless of the proposals included in this rule. We
acknowledge that some providers may need more time to adapt to
submitting prior authorization requests via an API and until such time,
we encourage managed care plans to comply with other applicable
regulations to ensure that their prior authorization practices and
policies do not lead to impeding timely access to care or affect
network adequacy. Lastly, we note that the proposal to electronically
transmit information through the PAS API about whether the payer
approves, denies, or requests more information for the prior
authorization request is about notice to the provider and is limited to
transmission to a provider's EHR or practice management system. This
proposal would have no effect on the requirements for notice to an
enrollee at 42 CFR 438.210(c) and (d) and 438.404.
---------------------------------------------------------------------------

\48\ CHIP managed care entities are required to comply with
these standards by 42 CFR 57.1230(d).
---------------------------------------------------------------------------

We would like to hear from the provider community how current
notifications are received and whether the proposed communication via
the PAS API could be more useful than the current notification process.
For instance, are the current notifications integrated into EHRs and
could this proposal improve communications?
5. Seeking Comment on Prohibiting Post-Service Claim Denials for Items
and Services Approved Under Prior Authorization
During the listening sessions, stakeholders raised concerns about
denials of claims for approved prior authorizations explaining that
provider staff spend significant time on appeals to resolve these
denials, and in some cases, patients receive unexpected bills for the
services, after the fact. Generally, a prior authorization is currently
only a determination by a payer that an item or service is medically
necessary, and is not a promise of payment. However, when a valid claim
for an approved service is denied, this creates inefficiencies in
processes for both payers and providers and could affect patient care.
We wish to learn how new policies could help improve this process, and
therefore request input from payers and other industry stakeholders, on
the issues that could inform a future proposal to prohibit impacted
payers from denying claims for covered items and services for which a
prior authorization has been approved.
We are requesting input on the criteria that could be included in a
new policy, and the potential costs of such a policy on payers.
Specifically we are soliciting input on what requirements would be
appropriate to include in a policy to ensure that claims that meet
certain guidelines for approved authorizations are not denied. In
addition, we seek comment on whether it would be important that the
patient be enrolled with the payer at the time the items or services
were provided, or that certain conditions exist for the provider's
contract status with the payer. And, we seek comment on what other
requirements would be appropriate to include in a policy to ensure that
the claims that meet certain guidelines for approved authorizations are
not denied.
We would also like input on the criteria payers could use to deny
claims once they are submitted to the claims processing system. For
example, do payers deny claims when there is reliable evidence of
technical errors, a duplicate claim for the approved item or service,
or evidence that an approved prior authorization was procured based on
material inaccuracy or by fraud? We believe payers have program
integrity practices through which they determine if a prior
authorization was procured by fraud, and coordinate investigations
under relevant programmatic authorities or state laws. Commenters are
encouraged to provide examples of program integrity practices used by
payers to identify and address fraudulent claims.
We also seek comment on whether all payer types should be required
to comply with a policy to prohibit payers from denying a claim for
payment after approving a prior authorization for covered items and
services, or if any payer types should be excluded, and for what
reasons. Finally, we would like input on the unintended consequences,
cost implications, and cost estimates related to prohibiting a prior
authorized claim from being denied, to the extent data can be provided.
We are interested in what legitimate reasons for denial could be
restricted by the adoption of specific criteria. We also invite payers
to comment on whether such a policy could increase improper payments or
program costs, decrease state use of prior authorization, or impact
enforcement of third-party liability.
If we were to address these topics, we would do so in a future
notice and proposed rulemaking.
6. Requirements for Prior Authorization Decision Timeframes and
Communications
a. Overview of Decision Timeframe Issue
We also heard from providers that excessive wait times for prior
authorization decisions often caused delays in the delivery of services
to patients. One risk of the time burden associated with some of the
prior authorization processes is the potential patient harm resulting
from delays in responses to prior authorization requests--whether for
the approval of the initial request, or delays in the resolution of the
request--for example, waiting for a payer's review and decision based
on required documentation for the request. The AMA study reported that
28 percent of physicians stated that delays in care due to the prior
authorization process, specifically the wait for approval, led to
serious, life-threatening adverse events, including death, for their
patients.\49\ In addition, 91 percent of physicians reported that
delays related to prior authorization have had other negative impacts
on their patients.\50\ As described earlier, in 2019 CMS conducted
outreach with external

[[Page 82613]]

stakeholders through listening sessions, interviews, observational
visits, RFIs and a special email box, to obtain information about how
to improve the transparency, efficiency, and standardization of the
prior authorization process. From the high volume of comments we
received on the subject of timeframes for processing prior
authorizations, it is apparent that delays in securing approvals for
prior authorization directly affect patient care by, for example,
delaying access to services, transfers between hospitals and post-acute
care facilities, treatment, medication, and supplies. These delays
occur, in part, because of the variation in processes used by each
payer to review prior authorization requests, inconsistent use of
available technologies to process prior authorizations, and the ongoing
reliance on manual systems such as phone, fax, and mail, which require
more labor-intensive human interactions. Some commenters noted that the
large variations in payer prior authorization policies for the same
items and services and the difficulty discovering each payer's
policies--which requires substantial staff research and time--
contribute to delays in care.
---------------------------------------------------------------------------

\49\ American Medical Association. (n.d.). 2017 AMA Prior
Authorization Physician Survey. Retrieved from https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc/prior-auth-2017.pdf.
\50\ American Medical Association. (n.d.). 2017 AMA Prior
Authorization Physician Survey. Retrieved from https://www.ama-assn.org/sites/ama-assn.org/files/corp/media-browser/public/arc/prior-auth-2017.pdf.
---------------------------------------------------------------------------

In this proposed rule, we use the term ``standard'' prior
authorization to refer to non-expedited request for prior authorization
and the term ``expedited'' prior authorization to indicate an urgent
request. This is consistent with the provisions at 42 CFR 438.210(d)
(for Medicaid managed care plans). A standard prior authorization is
for non-urgent items and services. An expedited prior authorization is
necessary when failure to decide could jeopardize the health or life of
the patient.
b. Current Regulations Establishing Timeframes for Certain Payers for
Standard and Expedited Prior Authorization Requests
We have regulated in this area previously and have established
timeframes for certain payers to make decisions and provide notice
regarding prior authorizations as well as time requirements for certain
decisions on appeals. Specifically, in the Medicaid managed care
program, and for CHIP managed care entities, payers must, for standard
authorization decisions, make a decision, and send notice of that
decision, as expeditiously as the enrollee's condition requires and
within state-established timeframes that may not exceed 14 calendar
days following receipt of the request for items or services (42 CFR
438.210(d)(1), 457.495(d), and 457.1230(d)). For cases in which a
provider indicates or the payer determines that following the standard
timeframe could seriously jeopardize the enrollee or beneficiary's
life, health or ability to attain, maintain, or regain maximum
function, the Medicaid managed care plan, or CHIP managed care entity
must make an expedited authorization decision and provide notice as
expeditiously as the enrollee's health condition requires, but no later
than 72 hours after receiving the request (42 CFR 438.210(d)(2) and
457.1230(d)).
In addition, under these existing regulations, the enrollee or the
provider may request an extension of up to 14 additional calendar days
from the standard timeframe to make a decision on a prior authorization
request for an item or service, or the payer may also initiate the
extension up to 14 additional calendar days if the payer can justify a
need for additional information and how the extension is in the
enrollee or beneficiary's interest (42 CFR 438.210(d)(2) and
457.1230(d)). For example, a payer may need to gather additional
information by consulting with additional providers with expertise in
treating a particular condition to enable the payer to make a more
informed decision.
Under existing CHIP regulations, prior authorization of health
services must be completed within 14 days after receipt of a request
for services or in accordance with existing state law regarding prior
authorization of health services (42 CFR 457.495(d)). This means the
CHIP managed care entities must decide, and send notice of that
decision within 14 calendar days following receipt of the request for a
medical item or service by the provider. An extension of 14 days may be
permitted if the enrollee requests the extension or if the physician or
health plan determines that additional information is needed (42 CFR
457.495(d)(1)). For cases in which a provider indicates, or the payer
determines, that the standard timeframe of 14 days could seriously
jeopardize the enrollee's life; health; or ability to attain, maintain,
or regain maximum function, the CHIP managed care entity must make an
expedited authorization decision and provide notice no later than 72
hours after receiving the request (42 CFR 457.1230(d)).
c. Proposals To Address Timeframes for Standard Prior Authorization
Requests
Given our interest in patient health outcomes, we are proposing to
require that state Medicaid and CHIP FFS programs, Medicaid managed
care plans, and CHIP managed care entities provide notice of prior
authorization decisions as expeditiously as a beneficiary's health
condition requires and under any circumstances not later than 72 hours
of receiving a request for expedited decisions. Notice should be
provided no later than 7 calendar days after receiving a request for
standard decisions. For Medicaid managed care plans, we are also
proposing to maintain that an extension of 14 days is authorized if the
enrollee requests it or a health plan determines additional information
is needed.
We are not proposing at this time to change timeframes for prior
authorization (pre-service) claims processes for QHP issuers on the
FFEs, as further discussed below.
We are not proposing that a prior authorization would be
automatically approved should the impacted payer fail to meet the
required timeframe. If the deadline is missed, providers may need to
contact the payer to determine the status of the request and whether
additional information is needed. Further, under the Medicaid managed
care rules (at 42 CFR 438.404(c)(5)), a payer's failure to decide
within the required timeframe is considered a denial and the right to
appeal that denial is available to the enrollee or provider. We are not
proposing to change this existing rule. In addition to these proposals,
we request comments on the impact of proposing a policy whereby a payer
would be required to respond to a prior authorization request within
the regulated timeframes, and if the payer failed to meet the required
timeframe, the prior authorization would be automatically approved. We
are interested in stakeholder feedback on the potential volume of such
occurrences, the costs to payers in increasing prior authorization
staffing levels or inappropriate items and services and the benefits to
providers and patients in terms of reduced burden and faster access to
necessary items and services.
We propose at 42 CFR 440.230(d)(1)(i) for Medicaid FFS, at 42 CFR
457.495(d) for CHIP FFS, at 42 CFR 438.210(d) for Medicaid managed
care, at 42 CFR 457.1233 for CHIP managed care (through the existing
requirement to comply with 42 CFR 438.210), that impacted payers must
meet these timeframes beginning January 1, 2023 (for Medicaid managed
care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2023). We are not proposing to change
the timeframes that apply to expedited authorization decisions made by
Medicaid managed care plans and CHIP managed care entities under 42 CFR
438.210(d)(2) and 457.1230(d), which already apply a 72 hour

[[Page 82614]]

timeframe, with an opportunity to extend the timeframe by up to 14 days
under certain conditions.
d. Requirements for Notifications Related to Prior Authorization
Decision Timeframes
This section addresses current requirements for certain impacted
payers to maintain communications about prior authorization decisions
with patients through notifications, in concert with our proposals to
improve the timeliness of prior authorization decisions.
For Medicaid, we are proposing a new paragraph (d)(1)(i) at 42 CFR
440.230 to specify regulatory timeframes for providing notice of both
expedited and standard prior authorization requests. The new
requirements would be applied to prior authorization decisions
beginning January 1, 2023.
Under this proposal for Medicaid, notice of the state Medicaid
program's decision regarding an expedited request for prior
authorization would have to be communicated as expeditiously as a
beneficiary's health condition requires, and in any event not later
than 72 hours after receiving a provider's request for an expedited
determination. Notice of a decision on a standard request for a prior
authorization would have to be communicated to the requesting provider
as expeditiously as a beneficiary's health condition requires, and
under any circumstance, within 7 calendar days. If the state determines
that it needs additional information from a provider to make a
decision, or if the beneficiary or provider requests an extension, this
proposed decision-making and communication timeframe could be extended
by up to 14 calendar days. State Medicaid FFS programs must also comply
with the requirements in section 1927 of the Act regarding coverage and
prior authorization of covered outpatient drugs. Nothing in this
proposed rule would change these requirements.
This proposal is consistent with section 1902(a)(19) of the Act,
which requires that care and services be provided in a manner
consistent with simplicity of administration and the best interests of
recipients, because it is expected to help make the prior authorization
process less burdensome for the state, providers, and beneficiaries.
The proposed requirements and standards could result in more prompt
prior authorization decisions, improve delivery of covered services,
reduce burden on providers, and improve efficiency of operations for
the program, thereby serving the best interest of Medicaid
beneficiaries.
Under current Medicaid notice and fair hearing regulations, notice
and fair hearing rights already apply to state decisions about Medicaid
fee-for-service prior authorization requests. Specifically, Medicaid
notice and fair hearing regulations apply to all prior authorization
decisions, including partial or total denials of prior authorization
requests, failures to make prior authorization decisions in a timely
fashion, and terminations, suspensions of, and reductions in benefits
or services for which there is a current approved prior authorization.
We propose the following changes in regulation text to make it explicit
that existing Medicaid notice and fair hearing rights apply to Medicaid
fee-for-service prior authorization decisions. First, we propose a new
paragraph (1)(ii) in 42 CFR 440.230(d) to specify that states must
provide beneficiaries with notice of the Medicaid agency's prior
authorization decisions and fair hearing rights in accordance with 42
CFR 435.917 and part 431, subpart E. Second, we propose to revise the
definition of an ``action'' at 42 CFR 431.201 to include termination,
suspension of, or reduction in benefits or services for which there is
a current approved prior authorization. We also propose to revise the
definition of the term ``action'' to improve readability. Third, to
align with our proposal at 42 CFR 431.201 (definition of ``action'')
and 42 CFR 440.230(d)(1)(ii), we propose to modify 42 CFR 431.220(a)(1)
to add a new paragraph (vi) to add a prior authorization decision to
the list of situations in which a state must provide the opportunity
for a fair hearing. Fourth, we propose a modification to 42 CFR
435.917(b)(2) to add a notice of denial or of change in benefits or
services to the types of notices that need to comply with the
requirements of 42 CFR 431.210. Finally, we propose modifications to
the headers at 42 CFR 435.917(a) and (b) to clarify that the
information contained in 42 CFR 435.917 relates broadly to eligibility,
benefits, and services notices. Specifically, we propose to remove the
word ``eligibility'' from the headers of paragraphs (a) and (b) of 42
CFR 435.917 to more accurately reflect the content of these paragraphs.
These proposed changes are intended to make it explicit in
regulation text how existing Medicaid fair hearing regulations apply to
states' prior authorization decisions. As noted above, the partial or
total denial of a prior authorization request is appealable through a
state fair hearing under current regulations. Even though current
regulations at 42 CFR 431.220(a)(1) do not expressly refer to denials
of prior authorization requests, a denial of a prior authorization
request is a denial of benefits or services as described in that
section because a prior authorization denial results in denial of
coverage of a benefit or service requested by the beneficiary.
Therefore, the state must provide a beneficiary who receives a partial
or total denial of a prior authorization request the opportunity to
have a fair hearing.\51\
---------------------------------------------------------------------------

\51\ See discussion in the ``Medicaid and Children's Health
Insurance Programs: Eligibility Notices, Fair Hearing and Appeal
Processes for Medicaid and Other Provisions Related to Eligibility
and Enrollment for Medicaid and CHIP'' final rule (hereinafter
``Eligibility and Appeals Final Rule''), published in the Federal
Register on November 30, 2016 (81 FR 86382, 86395)(approvals of
prior authorization requests for an amount, duration, or scope that
is less than what the beneficiary requested are subject to fair
hearing requirements in 42 CFR 431, subpart E).
---------------------------------------------------------------------------

Similarly, under current regulations at 42 CFR 431.220(a)(1), the
state must provide beneficiaries the opportunity to request a fair
hearing if the state fails to act on a claim with reasonable
promptness. Just as states must furnish medical assistance to eligible
individuals with reasonable promptness under section 1902(a)(8) of the
Act, states must also provide individuals with access to a fair hearing
if the state fails to act on a claim for medical assistance with
reasonable promptness under section 1902(a)(3) of the Act. Therefore,
for example, after January 1, 2023, the failure to render a prior
authorization decision within the timeframe at proposed 42 CFR
440.230(d)(1)(i) would be considered a failure to act with reasonable
promptness and subject to fair hearing rights available to individuals
under 42 CFR part 431, subpart E. Finally, existing regulations require
that states grant Medicaid beneficiaries the opportunity for a fair
hearing whenever a state takes an action as defined in 42 CFR 431.201.
This definition includes ``a termination, suspension of, or reduction
in covered benefits or services.'' Therefore, under the current
definition of ``action'' at 42 CFR 431.201, any termination, suspension
of, or reduction in benefits or services for which there is a current
approved prior authorization is considered an action for which the
state must afford a beneficiary the opportunity for a fair hearing in
accordance with 42 CFR 431.220(a)(1).
The proposed changes at 42 CFR 440.230(d)(1)(ii) are also intended
to make it explicit in regulation text that existing Medicaid notice
regulations apply to states' prior authorization

[[Page 82615]]

decisions. Under 42 CFR 435.917(a), a state must provide timely and
adequate written notice of its prior authorization decisions,
consistent with 42 CFR 431.206 through 431.214. This notice must
include information about the beneficiary's fair hearing rights. Under
our proposals, a state would be required to provide notice of a
decision within the timeframes in 42 CFR 440.230(d)(1)(i) when the
state approves or partially or totally denies a prior authorization
request after January 1, 2023. However, whenever a state makes a prior
authorization decision that is considered an action, including the
termination, suspension of, or reduction in benefits or services for
which there is a current approved prior authorization, the state must
provide the individual at least 10 days advance notice consistent with
42 CFR 431.211 prior to taking the action and afford the beneficiary
the right to the continuation of services pending the resolution of the
state fair hearing, in accordance with 42 CFR 431.230. Under 42 CFR
431.206(c)(2), the state must inform the beneficiary in writing
whenever a fair hearing is required per 42 CFR 431.220(a), which
includes when a state has not acted upon a claim with reasonable
promptness. For example, after January 1, 2023, this would mean that a
state must also provide notice to the beneficiary when it fails to
reach a decision on a prior authorization request within the timeframes
in proposed 42 CFR 440.230(d)(1)(i).
To enhance beneficiary notice, we are proposing to explicitly link
the required notice content in 42 CFR 431.210 to denials of or changes
in benefits or services for beneficiaries receiving medical assistance
by proposing amendments to 42 CFR 435.917(b)(2) to include a reference
to denials of or changes in benefits and services for beneficiaries
receiving medical assistance. The notice content requirements at 42 CFR
431.210 include a requirement that notices include a clear statement of
the specific reasons supporting the intended action, so this proposed
amendment would ensure that individuals receiving medical assistance
who are denied benefits or services receive a notice clearly explaining
the reasons for a denial. As we explained above, because a denial of a
prior authorization request is a denial of a benefit or service, this
change would also apply to notices for denials of prior authorization
decisions.
We note that the current application of existing notice and fair
hearing requirements to Medicaid fee-for-service prior authorization
decisions, which we propose to make explicit in regulation text, is
consistent with current regulations for notice and appeal rights for
managed care prior authorization decisions (sometimes referred to as
service authorizations or adverse benefit determinations). See 42 CFR
438.400 (definition of adverse benefit determination), 42 CFR 438.404
(timely and adequate notice for adverse benefit determination), and 42
CFR 438.420 (continuation of benefits while managed care plan appeal
and the state fair hearing process are pending).
As noted above, these proposed modifications generally apply
existing regulations to prior authorization decisions and do not
generally change Medicaid notice or fair hearing policy. As such, we
propose that the revisions to 42 CFR 431.201, 431.220, 431.917, and
440.230(d)(1)(ii) would be effective upon publication of the final
rule, with the understanding that any notice or fair hearing rights
based solely on new provisions proposed in this rulemaking would take
effect in accordance with the proposed effective date for the proposed
new provisions, including the proposed timeframes for notifications
about prior authorization decisions. We seek comment both on how states
apply these notice and fair hearing rights to prior authorization
decisions currently and on our proposals. We also seek comment on
whether we should change this policy through future rulemaking, and not
require fair hearing rights for prior authorization denials.
To implement the proposed authorization timeframes for Medicaid
managed care, we also propose to revise 42 CFR 438.210(d)(1). Under our
proposal, the new timeframes for Medicaid managed care plans to issue
decisions on prior authorization requests would apply beginning with
the rating period on or after January 1, 2023. Therefore, we propose to
add at the end of the current regulation that, beginning with the
rating period that starts on or after January 1, 2023, the state-
established timeframe that a decision may not exceed 7 calendar days
following the plan's receipt of the request for service would go into
effect. This effectively would limit the period of time that a Medicaid
managed care plan must make and provide notice of an authorization
decision to a maximum of 7 days (or fewer if the state establishes a
shorter timeline) unless there is an extension. We propose that the
authority to extend that timeframe by up to 14 additional calendar days
would continue to apply. Our proposal would not change the current
provisions for how failure to issue a decision within the required time
frame constitutes an adverse benefit determination that can be appealed
under 42 CFR 438.404(c)(5). Section 438.404 and the other regulations
governing appeal rights in 42 CFR part 438, subpart F, would continue
to apply. This is also consistent with how the definition of ``adverse
benefit determination'' in 42 CFR 438.400(b) includes a failure of a
Medicaid managed care plan to make an authorization decision within the
regulatory timeframes. We also note that under current regulations at
42 CFR 438.3(s)(1) and (s)(6) and 438.210(d)(3), Medicaid managed care
plans must also comply with the requirements in section 1927 of the Act
regarding coverage and prior authorization of covered outpatient drugs.
Nothing in this proposed rule would change these requirements. We also
note that Medicaid managed care plans that are applicable integrated
plans as defined in 42 CFR 438.2 would continue to follow the decision
timeframes defined in 42 CFR 422.631(d).
We believe implementing these proposed prior authorization
timeframes for Medicaid FFS and managed care programs would help states
to ensure that they are furnishing medical assistance services with
reasonable promptness as described in section 1902(a)(8) of the Act and
with reasonable program safeguards to ensure that services would be
provided in the best interests of the recipients, in accordance with
section 1902(a)(19) of the Act. In addition, this proposal would
implement section 1932(b)(4) of the Act, which provides that each
Medicaid managed care organization must establish an internal grievance
procedure under which an enrollee who is eligible for medical
assistance may challenge the denial of coverage of or payment for such
assistance. Reducing plan response time for prior authorizations should
enable enrollees to file appeals timelier, when needed, and receive
faster resolution. The prior authorization proposals in this rule,
particularly the proposal to reduce the maximum amount of time for a
managed care plan to make a standard prior authorization decision from
14 days to 7 days, are consistent with how section 1932(c)(2)(A) of the
Act indicates that timely access to care should be assured for
enrollees. Currently, and under our proposal, 42 CFR 438.210 applies
the same appeal and grievance requirements for PIHPs and PAHPs as for
MCOs; for this proposal, we rely on our authority in section 1902(a)(4)
to adopt these standards for PIHPs and PAHPs. This is consistent with
our prior practice for adopting standards for Medicaid

[[Page 82616]]

managed care plans (81 FR 27507). We believe that the proposal to
shorten the maximum amount of time for a plan to make a prior
authorization decision from 14 days to 7 days would improve the
efficient operation of the Medicaid program by facilitating faster
receipt of services or filing of appeals.
We are not proposing any changes to the required timeframes for
expedited decisions at 42 CFR 438.210(d)(1) nor the authority for a 14-
day extension provided at 42 CFR 438.210(d)(1) and (2)(ii). This
proposed requirement would be applicable to CHIP managed care through
the cross reference to 42 CFR 438.210 in current 42 CFR 457.1230(d).
To implement the proposed prior authorization timeframes for CHIP,
we propose to revise 42 CFR 457.495, such that beginning January 1,
2023, decisions related to prior authorization of health services would
be required to be completed in accordance with the medical needs of the
patient, but no later than 7 calendar days after the date of the
receipt of the request for a standard determination and 72 hours
following the receipt of the request for an expedited determination. We
are retaining the authority for an extension of up to 14 days to be
granted if the enrollee requests or the physician or health plan
determines that additional information is needed. We propose to remove
the option for states to follow existing state law regarding prior
authorization of health services, requiring states to instead follow
these updated timeframes. However, if state laws are more stringent,
states are not prohibited from complying with enhanced decision
timelines. We believe timely prior authorization decisions are an
important beneficiary protection, and CHIP beneficiaries should be
afforded the same decision timeframes as Medicaid beneficiaries. We
seek comment on this proposal, and most specifically from states.
Existing CHIP regulations at 42 CFR 457.1130(b) require a state to
ensure that an enrollee has an opportunity for external review of
health services matters, including a delay, denial, reduction,
suspension, or termination of health services, in whole or in part,
including a determination about the type or level of service. Under
this regulation, CHIP enrollees must have an opportunity for external
review of prior authorization decisions. We are not proposing any
changes to this requirement, as it already applies to decisions related
to the prior authorization of services.
In the case of QHP issuers on the FFEs, regulations at 45 CFR
147.136 establish internal claims and appeals processes, external
review processes, and pre-service claims requirements for all non-
grandfathered group and individual market plans or coverage.
Specifically, at 45 CFR 147.136(b)(3), individual health insurance
issuers are required to meet minimum internal claims and appeals
standards. To avoid adding to the burden that this proposal might
impose by applying multiple, potentially inconsistent regulatory
standards for individual and group market plans, we are considering,
and solicit comments on, whether to extend the timeframes for
processing of prior authorizations applicable to other payers, as
discussed in this section, to QHP issuers on the FFEs. Specifically, we
seek comment on whether having different processing timelines for prior
authorizations for QHP issuers on the FFEs would be operationally
feasible for issuers, or if such a requirement would have the
unintended effect of increasing burden for issuers that are already
subject to different requirements.\52\ Finally, we note that the
alternative of making changes to regulations applicable to all non-
grandfathered group and individual market plans or coverage for
consistency with our proposed approach here would be outside the scope
of this regulation.
---------------------------------------------------------------------------

\52\ We are not proposing in this proposed rule to impose on
individual and group market plans generally timelines for processing
of prior authorizations consistent with those we propose for other
payers, as such requirements would require rulemaking by the
Departments of Labor, the Treasury, and Health and Human Services.
---------------------------------------------------------------------------

Overall, we believe that the decision timeframes proposed for the
impacted payers in this rule would help ensure that prior authorization
processes do not inappropriately delay patient access to necessary
services. The introduction of decision timeframes that are the same
across all impacted payers for items and services that require prior
authorization would also help providers better organize and manage
administrative resources and allow more time for providers to render
patient-centered care. We believe these proposals would make
substantive progress in improving the care experience for patients and
lead to better health outcomes. In turn, better health outcomes would
contribute to more efficient use of program resources.
We request comment on these proposals, specifically those that
include feedback on any unintended consequences of these proposed
policies to reduce payer decision timeframes.
In addition to comments on the proposals regarding timelines and
notifications, we seek comment on several related topics. For example,
are alternative timeframes feasible or appropriate for prior
authorization for items and services?
Under what circumstances could payers approve an expedited
prior authorization in less than the proposed 72 hours? Are there
circumstances in which a payer should be required to approve an
expedited prior authorization in 24 hours for items and services other
than prescription or outpatient drugs? What are the operational and
system requirements for a more streamlined scenario for prior
authorization approvals?
Under what circumstances could an approval be provided in
less than 7 calendar days for a complex case?
We also seek comment on process challenges with prior
authorization. For example, are there scenarios that could be
appropriate to support temporary coverage of services, such as,
temporary access to DME, while the patient waits for an authorization
during the 14-day review timeframe? What policy conditions might be
necessary to include in such authorization determinations? Commenters
are encouraged to provide examples of best-case and worst-case
scenarios, and explain what changes in process, policy, or technology
would be necessary.
7. Proposed Extensions, Exemptions and Exceptions for Medicaid and CHIP
and QHP Issuers
a. Extensions and Exemptions for Medicaid and CHIP FFS Programs
If our proposals regarding the DRLS and PAS APIs are finalized, we
would strongly encourage state Medicaid and CHIP FFS programs to
implement these APIs as soon as possible, in light of the many benefits
of these APIs as discussed previously in this section. However, we also
recognize that state Medicaid or CHIP FFS agencies could face certain
unique circumstances that would not apply to other impacted payers, as
discussed in more detail later in this section. As a result, a few
states might need to seek an extension of the compliance deadline or an
exemption from these requirements. To address this concern, we are
proposing a process through which states may seek an extension of and,
in specific circumstances, an exemption from, the DRLS and PAS API
requirements if they are unable to implement these API requirements,
consistent with the extension and exemption proposals for the Provider
Access API in section II.B., and the Payer-to-Payer API in section
II.D. of this proposed rule. Providing these flexibilities might allow
these states to continue building technical

[[Page 82617]]

capacity in support of overall interoperability goals consistent with
their needs. We therefore propose the following.
Extension. At 42 CFR 431.80(b)(1) and 42 CFR 457.732(b)(1)
respectively, we propose to provide states--for Medicaid FFS and CHIP
FFS--the opportunity to request a one-time extension of up to one (1)
year for the implementation of the PAS API specified at 42 CFR
431.80(a)(1) and 42 CFR 457.732(a)(2) and DRLS API specified at 42 CFR
431.80(a)(1) and 42 CFR 457.732(a)(1). Unique circumstances that might
present a challenge to specific states to meet the proposed compliance
date could include resource challenges, such as funding. Depending on
when the final rule is published in relation to a state's budget
process and timeline, some states may not be able to secure the needed
funds in time to both develop and execute implementation of the API
requirements by the proposed compliance data. A one-year extension
could help mitigate this issue. And, some states may need to initiate a
public procurement process to secure contractors with the necessary
skills to support a state's implementation of these proposed API
policies. The timeline for an open, competed procurement process,
together with the time needed to onboard the contractor and develop the
API, could require additional time as well. Finally, a state might need
to hire new staff with the necessary skillset to implement this policy.
Again, the time needed to initiate the public employee hiring process,
vet, hire, and onboard the new staff may make meeting the proposed
compliance timeline difficult, because, generally speaking, public
employee hiring processes include stricter guidelines and longer time-
to-hire periods than other sectors.\53\ In all such situations, a state
might need more time than other impacted payers to implement the
requirements.
---------------------------------------------------------------------------

\53\ State hiring processes are comparable with federal hiring
processes. According to OMB, the average time-to-hire for federal
employees was 98.3 days in 2018, significantly higher than the
private sector average of 23.8 days. See: https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

If a state believes it can demonstrate the need for an extension,
its request must be submitted and approved as a part of its annual
Advance Planning Document (APD) for MMIS operations costs and must
include the following: (1) A narrative justification describing the
specific reasons why the state cannot reasonably satisfy the
requirement(s) by the compliance date, and why those reasons result
from circumstances that are unique to states operating Medicaid or CHIP
FFS programs; (2) a report on completed and ongoing implementation
activities to evidence a good faith effort toward compliance; and (3) a
comprehensive plan to meet implementation requirements no later than
one year after the initial compliance date.
An extension would be granted if CMS determines based on the
information provided in the APD that the request adequately establishes
a need to delay implementation, a good faith effort to implement the
proposed requirements as soon as possible, and a clear plan to
implement no later than one year after the proposed compliance date. We
would expect states to explain why the request for an extension results
from circumstances that are unique to states operating Medicaid or CHIP
FFS programs. We solicit comment on whether our proposal would
adequately address the unique circumstances that affect states, and
that might make timely compliance with the proposed API requirement
sufficiently difficult for states, and thus justify an extension. In
particular, we seek comment on whether we should require or use
additional information on which to base the determination or whether we
should establish different standards in the regulation text for
evaluating and granting the request.
Exemption. At 42 CFR 431.80(b)(2) and 42 CFR 457.732(b)(2),
respectively, we propose two circumstances that would permit state
requests for exemption; namely, (1) when at least 90 percent of all
covered items and services are provided to Medicaid or CHIP
beneficiaries through Medicaid or CHIP managed care contracts with
MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or
(2) when at least 90 percent of the state's Medicaid or CHIP
beneficiaries are enrolled in Medicaid or CHIP managed care
organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10
for CHIP. In both circumstances, the time and resources that the state
would need to expend to implement the API requirements may outweigh the
benefits of implementing and maintaining the API. As discussed in
section II.B. of this proposed rule, unlike other impacted payers,
state Medicaid and CHIP FFS programs do not have a diversity of plans
to balance implementation costs for those plans with low enrollment. If
there is low enrollment in a state Medicaid or CHIP FFS program, there
is no potential for the technology in which they have invested to be
leveraged for additional beneficiaries as states, unlike other payers,
do not maintain additional lines of business.
We acknowledge that the proposed exemption could mean that a few
Medicaid or CHIP FFS systems would not receive the benefits of having
these APIs available to facilitate health information exchange. To
address this, we propose that states meeting the above thresholds would
be expected to employ an alternative plan to enable the electronic
exchange and accessibility of health information for those
beneficiaries who are served under the FFS program.
A state meeting the above criteria would be permitted to submit a
request for an exemption to the requirements for the DRLS and PAS APIs
once per calendar year for a one (1) year exemption. The state would be
required to submit this annual request as part of a state's annual APD
for MMIS operations costs. The state would be required to include in
its request document that it meets the criteria for the exemption using
data from any one of the three most recent and complete calendar years
prior to the date the exemption request is made. We propose that this
request be made annually as from year-to-year the nature of the FFS
population could change and so it is important that the state provide
the most current information for CMS's consideration.
Exemptions would be granted for a one-year period if a state
establishes to CMS's satisfaction that it meets the criteria for the
exemption and has established a plan to ensure that providers would
have efficient electronic access to the same information through
alternative means.
We request comment on the proposed extension and exemption.
For Medicaid and CHIP managed care, we are not proposing an
extension process at this time because we believe that managed care
plans are actively working to develop the necessary IT infrastructure
to be able to comply with the existing requirements in 42 CFR part 438
and part 457, and also benefit from efficiencies resulting from their
multiple lines of business impacted by these interoperability policies.
Many managed care plans are part of parent organizations that maintain
multiple lines of business, including plans on the Exchanges. As
discussed in the CMS Interoperability and Patient Access final rule (85
FR 25607, 25612, 25620), work done by these organizations can benefit
all lines of business and, as such, we do not believe that the
proposals in this rule impose undue burden or are unachievable by the
compliance date. We are soliciting comment on whether

[[Page 82618]]

our belief concerning the scope of resources and ability of managed
care parent organizations to achieve economies of scale is well-
founded. Further, we seek comment on whether an extension process is
warranted for certain managed care plans to provide additional time for
the plan to comply with requirements at proposed 42 CFR 431.80(a)(1)
and 431.80(a)(2), which cross references 42 CFR 438.242(b)(5) for
Medicaid managed care plans and at proposed 42 CFR 457.732(a)(1) and
457.732(a)(2) which cross reference 42 CFR 457.1223(d)(2) for CHIP
managed care entities. While we are not proposing such a process for
managed care plans and entities and do not believe one is necessary for
the reasons outlined here, we are open to considering one if necessary.
If we adopt an extension process for these managed care plans and
entities, what criteria would a managed care plan or entity have to
meet to qualify for an extension? Should the process consider, for
example, enrollment size, plan type, or some unique characteristic of
certain plans that could hinder their implementation of the proposed
requirements by the proposed compliance date? Also, we seek comment on
whether, if we finalize such a process for Medicaid managed care plans
or CHIP managed care entities, the state or CMS should manage the
process and whether states could successfully adopt and implement the
process on the timeline necessary to fulfill the goals and purpose of
the process. Consistent with the exception process proposed for QHP
issuers on the FFEs at 45 CFR 156.222(d), we would expect any extension
request to include, at a minimum, a narrative justification describing
the reasons why a plan or entity cannot reasonably satisfy the
requirements by the proposed compliance date, the impact of non-
compliance upon enrollees, the current or proposed means of providing
electronic health information to providers, and a corrective action
plan with a timeline to achieve compliance.
We request comment on this proposal.
b. Exceptions for QHP Issuers
For QHP issuers on the FFEs, we propose an exceptions process to
the DRLS API requirements proposed at 45 CFR 156.223(a)(1) and the PAS
API requirements at proposed at 45 CFR 156.223(a)(2). We propose that
if an issuer applying for QHP certification to be offered through an
FFE believes it cannot satisfy the requirements to establish one or
both of these APIs, the QHP issuer would have to include, as part of
its QHP application: (1) A narrative justification describing the
reasons why the plan cannot reasonably satisfy the requirements for the
applicable plan year; (2) the impact of non-compliance upon enrollees;
(3) the current or proposed means of providing health information to
providers; and (4) solutions and a timeline to achieve compliance with
the requirements of this section. Further, we propose that the FFE may
grant an exception if it determines that making a health plan available
through the FFE is in the interests of qualified individuals in the
state or states in which such FFE operates. This exceptions process is
proposed at 45 CFR 156.223(b). As we noted in the Interoperability and
Patient Access Final Rule at 45 CFR 156.221(h), we anticipate that the
exception would be provided in limited situations. For example, we
would consider providing an exception to small issuers, issuers who are
only in the individual market, financially vulnerable issuers, or new
entrants to the program who demonstrate that deploying standards based
API technology would pose a significant barrier to the issuer's ability
to provide coverage to consumers, however, not certifying the issuer's
QHP or QHPs would result in consumers having few or no plan options in
certain areas. We believe that having a QHP issuer offer QHPs through
an FFE is in the best interests of consumers. We seek comment on other
circumstances in which the FFE should consider granting an exception.
We request comment on these proposed extensions, exemptions and
exceptions for Medicaid and CHIP FFS, Medicaid and CHIP managed care,
and the QHP issuers on the FFEs.
8. Public Reporting of Prior Authorization Metrics
We are proposing to require impacted payers to publicly report
certain prior authorization metrics on their websites at the state-
level for Medicaid and CHIP FFS, at the plan-level for Medicaid and
CHIP managed care, and at the issuer-level for QHP issuers on the FFEs.
As discussed in section II.C.11. of this proposed rule, publicly
reporting these metrics would support efficient operations, timely
service, and ensure prior authorization processes are executed in such
a way as to be in the best interest of patients. Specifically, public
reporting of this information would provide patients and providers with
important information about Medicaid managed care plans, CHIP managed
care entities, and QHP issuers when the patient is making a decision
about a plan. When looking for a new plan, patients may compare a
variety of factors including, but not limited to, access to care
(authorizations), premiums, benefits, and cost sharing or coinsurance.
We believe access to care is a critical factor for patients to consider
when choosing a plan, and transparency regarding prior authorization
processes could be an important consideration.
Similarly, providers may find metrics about prior authorization
approvals or appeals useful when selecting payer networks to join, and
when considering whether to contract with a payer. Providers should be
armed with information about how they will be able to treat their
patients, and whether that will be in a manner they believe will
support value-based care and services that are appropriate and
necessary for each patient's health.
Therefore, we are proposing to require state Medicaid and CHIP FFS
programs at 42 CFR 440.230(d)(2) and 457.732(a)(3), respectively;
Medicaid managed care plans at 42 CFR 438.210(f); CHIP managed care
entities through operation of existing 42 CFR 457.1233(d)(2); and QHP
issuers on the FFEs at 45 CFR 156.223(a)(3) to publicly report, at
least annually, prior authorization metrics on their websites or via
publicly accessible hyperlink(s). We propose that each metric would be
reported separately for each item and service, not including
prescription drugs and/or covered outpatient drugs, and that the data
would be required to be publicly reported for each metric. We propose
that these metrics would include, at a minimum, the following:
A list of all items and services that require prior
authorization;
The percentage of standard prior authorization requests
that were approved, reported separately for items and services;
The percentage of standard prior authorization requests
that were denied, reported separately for items and services;
The percentage of standard prior authorization requests
that were approved after appeal, reported separately for items and
services;
The percentage of prior authorization requests for which
the timeframe for review was extended, and the request was approved,
reported separately for items and services;
The percentage of expedited prior authorization requests
that were approved, reported separately for items and services;
The average and median time that elapsed between the
submission of a request and a decision by the payer, plan or issuer,
for standard prior

[[Page 82619]]

authorizations, reported separately for items and services.
In this proposal, when we state ``reported separately for items and
services,'' we mean each payer would report a percentage for all prior
authorization requests in a given year that meet the specified criteria
for requests that were for items and a percentage for all prior
authorization requests that year for the same criteria that were for
services. In this way, a payer's prior authorization requests would be
separated into two distinct categories, and these metrics would, if
this proposal is finalized, be reported for each of these categories.
By sharing information about prior authorization requirements for
items and services, and data about prior authorization decisions,
patients and providers would have a better understanding of a payer's
prior authorization review and approval processes. Such information may
be helpful for making decisions at the time of open enrollment, special
enrollment, or plan selection throughout the year. We are proposing
that, beginning March 31, 2023, these data be publicly reported
annually, by the end of the first calendar quarter each year for the
prior year's data. For example, for all impacted payers, all available
data for calendar year 2022 would be publicly reported by the end of
the first calendar quarter of 2023, or by March 31, 2023.
We acknowledge that the first set of publicly available data would
reflect current practices, rather than payer behavior based on
compliance with this proposed rule. However, should our proposals be
finalized, we anticipate that, over time, data might show improvements.
In addition, year-over-year comparisons could demonstrate positive (or
negative) trends, which alone could be useful information for patients
who are making enrollment decisions. Publicly available data would aid
interested providers and patients in understanding payer performance
with respect to prior authorization processes for decisions, approvals,
denials, and appeals.
We request comments on the proposed reporting of metrics on prior
authorization requests, including comments on the proposal to report a
separate percentage for all prior authorization requests in a given
year that meet the criteria for items and a separate percentage for all
prior authorization requests that year for the criteria that were for
services, and comments on the proposed reporting dates.
In order to more directly facilitate the incorporation of such data
into a consumer-friendly comparison tool, we may consider proposing in
future rulemaking to use these data to help develop quality measures to
incorporate into quality star ratings across certain payer programs
over time, specifically for QHP issuers on the FFEs.
For Medicaid managed care, we propose to remove the text currently
at 42 CFR 438.210(f), which addresses the applicability date for the
provisions in that section. That text was added in 2016 to clarify that
the prior requirements in that section would remain in effect until the
new provisions begin starting with rating periods beginning on or after
July 1, 2017. As several rating periods have passed since July 1, 2017,
we do not believe this clarifying text is needed. We propose to replace
the current text at 42 CFR 438.210(f) with the proposed public
reporting of prior authorization metrics, as explained above.
9. Request for Comments on ``Gold-Carding'' Programs for Prior
Authorization
During the CMS listening sessions, we heard about the potential for
additional efficiencies in the prior authorization process, through
certain payer policies, including decisions about when to require prior
authorization. For example, prior authorization is sometimes required
for certain items and services that are almost always approved or for
some providers who have demonstrated a history of complying with all
payer requirements. Stakeholders stated that it could be more efficient
and cost effective if prior authorization requirements were minimized
or removed in these cases.
Some payers have implemented what they term ``gold-carding'' or
similar programs to relax or reduce prior authorization requirements
for providers that have demonstrated a consistent pattern of
compliance. For example, some payers have relieved certain providers
from the requirement to request prior authorizations based on data
indicating adherence to submission requirements, appropriate
utilization of items or services, or other evidence-driven criteria
that they deem relevant. CMS uses an approach similar to gold-carding
in the Medicare FFS Review Choice Demonstration for Home Health
Services, under which home health agencies in demonstration states that
select certain review choice options and have a review affirmation rate
or claim approval rate of 90 percent or greater over 6 months are given
the option to continue in the pre-claim review program or choose a
selective post-payment review or spot check review process.\54\
---------------------------------------------------------------------------

\54\ Centers for Medicare and Medicaid Services. (2019, October
7). Review Choice Demonstration for Home Health Services. Retrieved
from https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFS-Compliance-Programs/Review-Choice-Demonstration/Review-Choice-Demonstration-for-Home-Health-Services.html.
---------------------------------------------------------------------------

We believe the use of gold-carding programs could help alleviate
provider burden related to prior authorization and believe these
programs could facilitate more efficient and prompt delivery of health
care services to beneficiaries. We encourage payers to adopt gold-
carding approaches that would allow prior authorization exemptions or
more streamlined reviews for certain providers who have demonstrated
compliance with requirements. Gold-carding policies could reduce burden
on providers and payers, while improving the patient experience. By
taking this step, payers can join CMS in helping to build an
infrastructure that would allow clinicians to deliver care in a timely
and value-based manner. While we are not including any proposals here,
and are not intending to be overly prescriptive in defining
requirements in future rulemaking for gold-carding programs, we
emphasize the importance of reducing provider burden and seek comment
for consideration for future rulemaking on how best to measure whether
and how these types of approaches and programs actually reduce provider
and payer burden.
To further encourage the adoption and establishment of gold-carding
programs, we have considered including gold-carding as a factor in
quality star ratings, where applicable, as a way for payers to raise
their score in the quality star ratings for QHP issuers. We seek
comment for potential future rulemaking on the incorporation of gold-
carding into star ratings for QHP issuers on the FFEs. We also
considered proposing gold-carding as a requirement in payer's prior
authorization policies and seek comment on how such programs could be
structured to meet such a potential requirement.
10. Additional Requests for Comment
We seek comment on additional topics pertaining to prior
authorization, as feedback may be useful for future rulemaking.
We understand from our listening sessions that there may be
opportunities to improve the prior authorization process for
individuals with chronic medical conditions. For example, when a
patient has a chronic condition that

[[Page 82620]]

requires ongoing treatment, the provider is often required to resubmit
repeated prior authorization requests for the same service, each time
treatment is needed. One such condition described in listening sessions
was macular degeneration. Patients shared their experience of needing
monthly prior authorizations for their monthly injection treatments,
despite the fact that those injections are required to avoid loss of
vision, and despite the fact that there is no cure for their condition.
Repeatedly submitting a prior authorization request for the same item
or service, which is always approved, creates a burden on both the
patient and the provider and adds costs to the overall health care
system. We seek comment on whether there should be certain restrictions
regarding requirements for repeat prior authorizations for items and
services for chronic conditions, or whether there can be approvals for
long term authorizations. What alternative programs are in place or
could be considered to provide long-term authorizations for terminal or
chronic conditions?
Another topic identified in listening sessions was patient concerns
about losing access to approved services after changing health plans.
Patients expressed concern about being able to continue a specific
course of care where, for example, they might be in the middle of an
approved course of care requiring physical therapy, but then change
health plans (payer). We seek comments on whether a prior authorization
decision should follow a patient when they change from one qualified
health plan on the Exchange to another, or to another health plan
impacted by this proposed rule, and under what circumstances that prior
authorization could follow a patient from payer to payer. We also seek
comment for potential future rulemaking on other prior authorization
topics, such as whether prior authorizations should be valid and
accepted for a specified amount of time. We are interested in comments
on who should determine how long an existing approved prior
authorization from a previous payer should last and whether prior
authorization should be regulated by amount of time and/or by
condition.
An additional topic from our listening sessions was the issue of
the number of different forms used by payers for prior authorization
requests, each with different information requirements (data elements)
and methods for submission. The lack of standard forms and requirements
from payers is considered burdensome and time consuming for both
patients and providers. We request input on solutions to standardizing
prior authorization forms, including the possibility of developing an
HL7 FHIR based questionnaire for prior authorization requests. Input on
requiring the use of a standardized questionnaire could inform future
rulemaking.
Finally, we request comments on how to potentially phase out the
use of fax technology to request and send information for prior
authorization decisions. As we described earlier in this section, we
believe the standards-based API process should be the preferred and
primary form of exchanging prior authorization communications. However,
we acknowledge that providers could vary in their ability to develop
and implement API-based prior authorization submission and receipt
technology and that there must be a channel for prior authorization for
providers whose systems are not API-capable. In particular, we
anticipate that providers in rural areas, small providers, and certain
types of service providers, such as home and community-based services
providers in Medicaid, may be subject to prior authorization processes
but may not have the technical expertise, access to high speed
internet, infrastructure, or financial resources to implement
connectivity with and use the DRLS and PAS APIs. Further, non-API
mechanisms like fax, phone, and web portals may be needed in times when
other technology is not available or other unexpected emergencies. We
request comment on how payers and providers might begin to phase out
the use of fax technology, and what barriers must still be overcome to
accomplish this goal.
As mentioned previously in this proposed rule, although Medicare
FFS is not directly impacted by this rule, we do note that we are
evaluating implementation of these provisions, if finalized. In this
way, Medicare FFS implementations would conform to the same
requirements that apply to the impacted payers under this rulemaking,
as applicable, so that participating Medicare providers and
beneficiaries would benefit from the APIs and process improvements.
11. Statutory Authorities To Require Prior Authorization Burden
Reduction Proposals
a. Medicaid and CHIP
For the reasons discussed below, our proposed requirements in this
section for Medicaid managed care plans and Medicaid state agencies
fall generally under our authority in section 1902(a)(4) of the Act,
which requires that a state Medicaid plan provide such methods of
administration as are found by the Secretary to be necessary for the
proper and efficient operation of the state Medicaid plan. The
proposals in this section are also authorized under section 1902(a)(8)
of the Act, which requires states to ensure that Medicaid services are
furnished with reasonable promptness to all eligible individuals.
Additionally, they are authorized by section 1902(a)(19) of the Act,
which requires states to ensure that care and services are provided in
a manner consistent with simplicity of administration and the best
interests of the recipients.
The proposed requirement for the states and Medicaid managed care
plans to implement the DRLS and PAS API (section II.C.3. and II.C.4. of
this proposed rule; statutory authority for proposals to require
specific IGs is discussed in section II.A.3. of this proposed rule) is
expected to improve the efficiency and timeliness of the prior
authorization process for Medicaid beneficiaries, providers, and state
Medicaid agencies and Medicaid managed care plans by addressing
inefficiencies that appear to exist in the process today. These
proposals would ensure that all states and Medicaid managed care plans
would provide easily accessible information about when a prior
authorization is required, and what documentation requirements must be
fulfilled to submit the request. The DRLS API would allow a provider to
determine if a prior authorization is required, and what the
documentation requirements are for that prior authorization request.
When using the PAS API, the state or Medicaid managed care plan would
send a real time response to a provider's request with the status of
the request included. Use of these APIs by states (for FFS programs)
and managed care plans could ensure that Medicaid providers are able to
submit a request for a prior authorization with the correct and
complete documentation, and avoid an incorrect submission which might
result in an unnecessary denial. The PAS API would: (i) Enable
providers to submit a prior authorization request faster and easier,
(ii) support more timely notice to provider and beneficiary of the
disposition of the prior authorization request sooner, and (iii) permit
faster scheduling of services or filing appeals, depending on the
decision. The DRLS API and the PAS API both have the potential to
improve the prior

[[Page 82621]]

authorization process by making it more efficient, including by
limiting the number of denials and appeals, or even by eliminating
requests for additional documentation, as noted elsewhere. For the
state, these requirements would thus align with section 1902(a)(4) of
the Act, which requires that a state Medicaid plan provide such methods
of administration as are found by the Secretary to be necessary for the
proper and efficient operation of the state Medicaid plan. For the
Medicaid managed care program, these requirements align with section
1932(c)(1)(A)(i) of the Act, which requires that states using managed
care organizations must develop and implement a quality assessment and
improvement strategy that includes standards for evaluating access to
care so that covered services are available within reasonable
timeframes.
The proposal would implement section 1932(b)(4) of the Act, which
provides that each Medicaid managed care organization must establish an
internal grievance procedure under which an enrollee who is eligible
for medical assistance may challenge the denial of coverage of or
payment for such assistance. This proposal would enable enrollees to
file appeals, when needed, and support them in receiving resolution.
Our proposal to clarify that current notice and fair hearing
requirements apply to Medicaid fee-for-service prior authorization
decisions is authorized under section 1902(a)(3) of the Act. Section
1902(a)(3) of the Act requires that a Medicaid state plan provide for
granting an opportunity for a fair hearing to any individual whose
claim for medical assistance under the plan is denied or is not acted
upon with reasonable promptness. These proposed clarifications are also
supported by the 14th Amendment to the United States Constitution and
case law on due process, specifically, Goldberg v. Kelly, 397 U.S. 254
(1970). States must establish timely notice and fair hearing processes
meeting due process standards under Golberg v. Kelly, as incorporated
into existing Medicaid fair hearing regulations at 42 CFR part 431,
subpart E; see 431.205(d).
The proposed requirement that states and Medicaid managed care
plans meet certain timeframes to provide notice of decisions for prior
authorizations, including the requirements that expedited decisions be
made and communicated in 72 hours and standard decisions be made and
communicated in 7 calendar days, may provide an improvement from the
current standards for decision timeframes for Medicaid managed care
(section II.C.6. of this proposed rule). The proposal is intended to
establish more certainty in the prior authorization process for
Medicaid providers and enhance beneficiary access to timely and
appropriate care, consistent with states' obligations to provide
Medicaid services with reasonable promptness and in a manner consistent
with beneficiaries' best interests. Improved decision timeframes could
improve communication to providers and beneficiaries, as well as
increase access to care. The proposal is consistent with, and might
help states comply with, section 1902(a)(8) of the Act, which requires
the provision of medical assistance with reasonable promptness. A
uniform and consistent timeline for Medicaid program prior
authorization decisions might improve beneficiaries' prompt access to
Medicaid-covered services.
Standardizing Medicaid prior authorization decision timeframes
could also support process improvements for the state and Medicaid
managed care plans, including the creation of standard operating
procedures and internal metric reports for program operations. This is
consistent with section 1902(a)(4) of the Act, which requires that a
state Medicaid plan provide such methods of administration as are found
by the Secretary to be necessary for the proper and efficient operation
of the state Medicaid plan.
The proposal is also authorized under section 1902(a)(17) of the
Act, as implemented under the existing Medicaid regulations at 42 CFR
440.230. This section of the Act requires state Medicaid programs to
establish reasonable standards that are consistent with the objectives
of title XIX of the Act to determine the extent of covered medical
assistance. As set forth at 42 CFR 440.230, these standards could
include appropriate limits on a service based on such criteria as
medical necessity or on utilization control procedures, so long as each
service is sufficient in amount, duration, and scope to reasonably
achieve its purpose. Items and services covered under Title XIX benefit
authorities are subject to 42 CFR 440.230, unless statute or regulation
expressly provides for an exception or waiver. This would include
covered items and services described in sections 1905(a), 1915(c),
1915(i), 1915(j), 1915(k), 1915(l), 1937, and 1945 of the Act, and any
other authorities as established by Congress.
The proposal is also consistent with section 1902(a)(19) of the
Act, which requires that care and services be provided in a manner
consistent with simplicity of administration and the best interests of
recipients, because it is expected to help make the prior authorization
process less burdensome for the state, providers, and beneficiaries.
The proposed requirements and standards could result in more prompt
prior authorization decisions, improve delivery of covered services,
and improve efficiency of operations for the program, thereby serving
the best interest of Medicaid beneficiaries.
Our proposal to require states and Medicaid managed care plans to
publicly report prior authorization metrics (section II.C.8. of this
proposed rule) would support CMS and state Medicaid agency oversight,
and evaluation and administration of the state plan, as it would allow
for an evaluation of the implementation of the policies proposed in
this rule. The data may indicate that payers have implemented the APIs
(by showing improvements in prior authorization numbers) or made other
improvements in policies and processes that result in improved metrics
in the areas that we propose to be reported. Section 1902(a)(6) of the
Act authorizes us to request reports from state Medicaid agencies in
such form and containing such information as the Secretary may require
from time to time. By reporting metrics, states and Medicaid managed
care plans could review data to identify areas for improvement.
Requiring Medicaid managed care plans to publicly report their prior
authorization metrics would hold them accountable and enable them to
more easily monitor their own performance and identify process
improvement opportunities which could be an integral part of
implementing a quality assessment and improvement strategy, consistent
with the requirements for quality strategies for managed care programs
at section 1932(c)(1)(A)(i) of the Act.
For CHIP, we propose these requirements under the authority in
section 2101(a) of the Act, which sets forth that the purpose of title
XXI is to provide funds to states to provide child health assistance to
uninsured, low-income children in an effective and efficient manner
that is coordinated with other sources of health benefits coverage.
This provision authorizes us to adopt these requirements for CHIP
because they would also provide access to program data, which can
improve the efficacy of CHIP programs, and allow for more efficient
administration of services.
As discussed above, we propose to require implementation of the
DRLS API and PAS API (section II.C.3. and II.C.4.

[[Page 82622]]

of this proposed rule; statutory authority for proposals to require
specific IGs is discussed in section II.A.3. of this proposed rule) to
improve the prior authorization process for patients, providers and
payers by addressing deficiencies and inefficiencies that exist in the
current process. Today, a payer's rules about when a prior
authorization is required, and what documentation requirements must be
fulfilled to submit the request are not easily accessible for
providers, which requires phone calls, access to multiple websites, and
use of hard copy manuals, etc. This takes time away from actual patient
care. The DRLS API allows a provider to determine if a prior
authorization is required, and what the documentation requirements are
for that prior authorization request. While we expect providers to be
the primary stakeholders that benefit from the DRLS API, making this
information available in a standardized way and permitting access
through an API also serves the requirements in section 2101(a) of the
Act that CHIP ensure access to coverage and coordinate care.
The proposed PAS API would be a mechanism for receiving and
responding to requests for coverage determinations before the services
are furnished; the PAS APIs would streamline the initial authorization
process for the payer, by sharing this information in an easily
accessible way; this also allows the provider to know what to do if a
prior authorization is required for a certain service, which improves
the providers ability to treat the patient timely. The proposed PAS API
would enable the payer to send a real time response back to a provider,
based on a request for authorization. This too would improve the
efficiency of providing services to the patient, because the request
and response would be automated, and in real time. Payer use of these
APIs could ensure that a provider is able to submit a request for a
prior authorization with the correct and complete documentation to
avoid an incorrect submission which might result in an unnecessary
denial. The PAS API would: (i) Enable providers to submit a prior
authorization request faster and easier, (ii) support more timely
notice to provider and enrollee of the disposition of the prior
authorization request, and (iii) permit faster scheduling of services
or filing appeals, depending on the decision. The DRLS API and the PAS
API both have the potential to improve the prior authorization process
by making it more efficient, including limiting the number of denials
and appeals, or even eliminating requests for additional documentation,
as noted elsewhere.
The proposed requirement that CHIP FFS and managed care entities
meet certain timeframes to provide decisions for prior authorizations,
including the requirement that expedited decisions be given in 72 hours
and standard decisions be given in 7 calendar days, is an improvement
from the current state, when there is uncertainty about expectations
for when a prior authorization might be approved (section II.C.6. of
this proposed rule). The proposal is intended to establish more
certainty in the prior authorization process for providers and enhance
patient access to timely and appropriate care. As payers provide notice
under a shorter timeframe, patients would have more timely access to
care. This is often not the case today, as providers and patients could
wait longer for the payer to respond to a request for certain services.
This could have an impact on health, particularly for individuals with
chronic conditions or who have health risks. Improving certainty around
decision timeframes could also reduce administrative time and expense,
because providers would not need to make repeat inquiries to payers for
a status on the authorization request. The proposal to improve
timeliness in responding to providers and patients could support
process improvements for the state and managed care programs and is
consistent with our authorities under section 2101(a) of the Act in
that they improve the efficiency of the CHIP programs.
Our proposal to require CHIP FFS and CHIP managed care entities to
report prior authorization metrics also supports the states oversight,
evaluation and administration responsibilities, as it would allow us to
evaluate the impact of the prior authorization policies in this
proposed rule (section II.C.8. of this proposed rule). The data may
indicate use of the APIs (improvements in prior authorization numbers)
or changes in total numbers, denials and appeals.
b. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we are proposing these new
requirements pursuant to the authority of section 1311(e)(1)(B) of the
Affordable Care Act, which affords the Exchanges the discretion to
certify QHPs if the Exchange determines that making available such
health plans through the Exchange is in the interests of qualified
individuals in the state in which the Exchange operates.
We believe that the policies included here would improve the
efficiency of the issuers who are certified to participate in the QHP
program and improve the quality of services they provide to providers
and their patients. Qualified individuals in FFEs may receive covered
services more quickly, and the information may be more accurate with
the use of the APIs. These proposals could improve the quality of the
patient experience with their providers by increasing the efficiency in
the prior authorization submission and review process. Therefore, we
believe generally, that certifying only health plans that implement
FHIR based APIs and adhere to the other proposals herein, would be in
the interests of qualified individuals in the state or states in which
an FFE operates. We encourage SBEs to consider whether a similar
requirement should be applicable to QHP issuers participating in their
Exchanges.
In sections II.C.3. and II.C.4. of this rule, we propose that QHPs
implement two APIs for the prior authorization process (statutory
authority for proposals to require specific IGs are discussed in
section II.A.3. of this proposed rule). The DRLS API would allow
providers to quickly and efficiently know if a prior authorization is
needed and locate the documentation requirements easily. This would
enable faster, more accurate submission of prior authorization requests
and potentially more prompt delivery of services. We also propose that
QHPs implement a PAS API, to allow providers to efficiently, and with
greater simplicity submit prior authorization requests directly from
within their workflow and would allow QHP issuers to respond to the
prior authorization request quickly and efficiently, thus enabling more
prompt delivery of services.
We also include in our proposal that QHPs provide a denial reason
when sending a response to a prior authorization request, to facilitate
better communication and understanding between the provider and issuer.
This could enable efficient resubmission of the prior authorization
request with additional information or an appeal, which could more
promptly facilitate the needed patient care.
Finally, proposing to require QHP issuers to publicly report prior
authorization metrics would hold issuers accountable to their providers
and patients, which could help them improve their program
administration (section II.C.8. of this proposed rule.). These data
could help QHPs evaluate their processes and determine if there are
better ways to leverage the APIs, including the quality and sufficiency
of

[[Page 82623]]

the coverage and documentation information included in the APIs.

D. Payer-to-Payer Data Exchange on FHIR

1. Background
Research shows that the more complete a patient's record is, and
the more data there are at the point of care, the better patient
outcomes can be.\55\ More data lead to better-coordinated care and more
informed decision-making. Data sharing among payers is one powerful way
to facilitate this critically valuable flow of information through the
health care ecosystem. As a result, in the CMS Interoperability and
Patient Access final rule, we finalized a requirement for certain
impacted payers to exchange, at a minimum, clinical information as
defined in the USCDI version 1 (85 FR 25568 through 25569). We did not
specify an API standard for data sharing in that final rule, however,
understanding at the time that there may be a variety of transmission
solutions that payers could employ to meet this requirement. We did
encourage impacted payers to consider the use of a FHIR-based API in
line with the larger goal of leveraging FHIR-based APIs to support a
number of interoperability use cases for improving patient, provider,
and payer access to health care data in order to reduce burden,
increase efficiency, and ultimately facilitate better patient care. In
addition, we also signaled our intent to consider a future requirement
to use FHIR-based APIs for payer-to-payer data sharing, envisioning the
increasing implementation of FHIR-based APIs within the industry.
---------------------------------------------------------------------------

\55\ Office of the National Coordinator. (2019, June 4).
Improved Diagnostics & Patient Outcomes. Retrieved from https://www.healthit.gov/topic/health-it-basics/improved-diagnostics-patient-outcomes.
\55\ See SHO # 20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
\55\ HL7 International. (n.d.). Da Vinci Payer Coverage Decision
Exchange (PCDE) FHIR IG. Retrieved from https://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
\55\ State hiring processes are comparable with federal hiring
processes. According to OMB, the average time-to-hire for federal
employees was 98.3 days in 2018, significantly higher than the
private sector average of 23.8 days. See https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

In the time since we proposed the initial payer-to-payer data
exchange requirements in the CMS Interoperability and Patient Access
rule, we have begun to leverage new tools, most notably the HL7 FHIR
Bulk Data Access (Flat FHIR) specification, as discussed in more detail
in section II.B. of this proposed rule. We believe the HL7 FHIR Bulk
Data Access (Flat FHIR) specification, in particular, provides an
opportunity to continue to build upon the requirement for payer-to-
payer data sharing in a way that adds valuable efficiencies for payers,
further simplifying administration and reducing burden. We believe that
the suite of tools that the CMS Interoperability and Patient Access
final rule (85 FR 25510) requires and that this proposed rule would
require for payers would ultimately lead to payers having more complete
information available to share with patients and providers. As a
result, we are now proposing an enhanced set of payer-to-payer data-
sharing requirements that would build on the policy finalized in the
CMS Interoperability and Patient Access final rule (85 FR 25568 through
25569) by leveraging FHIR-based APIs to further support greater
interoperability and information flow.
2. Payer-to-Payer Data Exchange on FHIR
There are three primary proposals we are making regarding the
payer-to-payer data exchange in this proposed rule. First, we propose
to extend the payer-to-payer data exchange to state Medicaid and CHIP
FFS programs at 42 CFR 431.61(b) and 457.731(b). We previously
finalized in the CMS Interoperability and Patient Access final rule (85
FR 25568 through 25569) that MA organizations, Medicaid managed care
plans, CHIP managed care entities, and QHP issuers on the FFEs were
required, at the patient's request, to share a specified subset of
clinical data with another payer of the patient's choice.
Second, we propose to enhance this payer-to-payer data exchange
triggered by a patient's request beyond what was previously finalized
(for MA organizations, Medicaid managed care plans, CHIP managed care
entities, and QHP issuers on the FFEs) in the CMS Interoperability and
Patient Access final rule. In the final rule, we required impacted
payers to exchange, at the patient's request, clinical data as defined
in the USCDI, but we did not finalize in what electronic form or how
these data would be transmitted. In this rule, we are proposing to
require a FHIR-based API for this data exchange. In addition, we
propose that this standards-based API must be conformant with specific
IGs. We also propose that this Payer-to-Payer API, at the patient's
request, must make not just clinical data as defined in the USCDI
available, but also claims and encounter data (not including cost
information), and information about pending and active prior
authorization decisions. We propose these enhancements to the required
payer-to-payer exchanges for Medicaid managed care plans (other than
NEMT PAHPs) at 42 CFR 438.242(b)(7), CHIP managed care entities at 42
CFR 457.1233(d)(4), and QHP issuers on the FFEs at 45 CFR
156.221(f)(2). We are also proposing to include these enhancements as
part of extending the payer-to-payer data exchange requirements to
Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 42 CFR
457.731(b). We believe these proposed enhancements would facilitate
more efficient data sharing between payers. In addition, the proposed
additions to the data the API must be able to share would be consistent
with the proposals discussed in sections II.A. and II.B. of this
proposed rule, which would require these payers to share the same types
of data with patients and providers via FHIR-based APIs. This would add
efficiencies for payers and maximize the value of the work being done
to implement APIs, overall reducing burden for all impacted payers.
Third, we propose a second payer-to-payer data exchange policy that
would use this Payer-to-Payer API to facilitate data sharing between
payers at enrollment. When a patient enrolls with a new payer or when a
patient identifies concurrent coverage, we propose that the patient
would have an opportunity to opt-in to this data sharing. Unlike the
payer-to-payer exchange finalized previously, where the patient must
make a request to initiate the data sharing, under this proposal the
patient would be presented with data sharing as an option at
enrollment. As more than one patient could be moving from one payer to
another at enrollment, this new Payer-to-Payer API proposal to share
data at enrollment would include a requirement for impacted payers to
facilitate data sharing both for individual patients and for more than
one patient using the HL7 FHIR Bulk Data Access (Flat FHIR)
specification, discussed previously in section II.B. of this proposed
rule. We are proposing to codify the requirement for this Payer-to-
Payer API, including use of the HL7 FHIR Bulk Data Access (Flat FHIR)
specification, at 42 CFR 431.61(c) for Medicaid FFS, at 42 CFR
438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c) for CHIP
FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR
156.222(b) for QHP issuers on the FFEs.

[[Page 82624]]

3. Payer-to-Payer Data Sharing in Medicaid and CHIP
In the CMS Interoperability and Patient Access final rule, we did
not include Medicaid and CHIP FFS programs in the payer-to-payer data
exchange policies. In that rule, we also did not specify how these data
must be exchanged. As discussed in sections II.B.6.d. and II.C.7., and
again later in this section of this proposed rule, Medicaid and CHIP
FFS programs can face unique circumstances that might make it more
challenging for them to meet new requirements within the same timeframe
as other payers. As a result, in our first phase of interoperability
policy, we chose to limit the burden on these programs so they could
focus their attention and resources on implementing the Patient Access
and Provider Directory APIs. Now that we are looking to transition the
payer-to-payer data exchange to an API, and understanding the fact that
this new API will be leveraging the same data and technical standards,
and nearly all the same implementation guides as the Patient Access
API, we believe that asking these programs to now implement this payer-
to-payer data exchange via a Payer-to-Payer API would not be as
burdensome as it would have been had we required these FFS programs to
implement a payer-to-payer data exchange that does not require an API
in the CMS Interoperability and Patient Access final rule effective
January 1, 2022. By the time these programs would need to start
preparing to implement this new Payer-to-Payer API, they are expected
to have implemented the Patient Access API, and they would thus be able
to leverage the work done for that to make implementing this new API
more manageable. As a result, we now propose to extend this requirement
to Medicaid and CHIP FFS programs at 42 CFR 431.61(b) and 457.731(b),
respectively.
In the case of Medicaid and CHIP FFS programs, the state agency is
the ``payer'' that can share patient data with other payers. As we
discuss in more detail in section II.D.4. of this proposed rule, use of
the Payer-to-Payer API could improve operational efficiencies for the
state, thereby reducing burden for the state, and leading to better
coordinated patient care and improved health outcomes. We thus expect
the proposed Payer-to-Payer API requirement to lead to more effective
administration of the state plan, and to better enable Medicaid and
CHIP programs to ensure care and services are provided in a manner that
is consistent with their beneficiaries' best interests. Ensuring that
information can follow Medicaid and CHIP beneficiaries as they enter
the programs could potentially lead to better care coordination for
these patients, and better continuity of care. It could also reduce
burden for patients and providers. Payers would have additional
information to share via the Patient Access API and the Provider Access
API. As a result, patients would have more readily available
information to support informed decision making, and providers would
have more information about the care their patients are receiving. This
could potentially lead to fewer duplicate tests or less time taken
collecting and recollecting information about the patient during a
visit. Any opportunity a state takes to evaluate the data from a
patient's previous payer could allow the state to avoid wasteful or
unnecessary action that the previous payer may have already completed,
such as an involved process or series of tests to support receipt of
certain services. In this way, extending this Payer-to-Payer API to
state Medicaid and CHIP programs could benefit them by helping them to
operate more efficiently.
Also, as discussed in the CMS Interoperability and Patient Access
final rule (85 FR 255664 through 25569), we believe there are numerous
benefits for payers to be able to maintain a cumulative record of their
current patients' health information. If payers do so, they can make
information available to patients and their providers and can help
ensure that patient information follows patients as they move from
provider to provider and payer to payer. We believe it is important to
propose that Medicaid and CHIP FFS agencies facilitate this data access
and sharing for their beneficiaries, so that the benefits of both the
data sharing required in the final rule and the data sharing proposed
in sections II.A. through the Patient Access API and II.B. through the
Provider Access API of this proposed rule would extend to Medicaid and
CHIP FFS beneficiaries in the same way across other impacted payers. In
this way, as a patient moves in and out of Medicaid or CHIP FFS, they
will not lose access to their health information--that information
would continue to follow them to new payers and providers by virtue of
payers being able to send and receive their data and make it available
to the patient and providers through these APIs.
States operating Medicaid and CHIP programs may be able to access
federal matching funds to support their implementation of this Payer-
to-Payer API, because this API is expected to lead to more efficient
administration of the Medicaid and CHIP state plans and improved care
coordination and health outcomes for Medicaid beneficiaries consistent
with sections 1902(a)(4) and 2101(a) of the Act, as discussed in more
detail in section II.D.8.a. of this proposed rule.
Consistent with the discussion regarding funding and the Provider
Access API proposal discussed in section II.B. of this proposed rule
and the DRLS and API APIs in section II.C., we do not consider state
expenditures for implementing this Payer-to-Payer API proposal to be
attributable to any covered item or service within the definition of
``medical assistance.'' Thus, we would not match these expenditures at
the state's regular federal medical assistance percentage. However,
federal Medicaid matching funds under section 1903(a)(7) of the Act, at
a rate of 50 percent, for the proper and efficient administration of
the Medicaid state plan, might be available for state expenditures
related to implementing this proposal for their Medicaid programs,
because use of the Payer-to-Payer API would help ensure that payers can
access data that could improve their ability to render Medicaid
services effectively, efficiently, and appropriately, and in the best
interest of the patient.
States' expenditures to implement these proposed requirements might
also be eligible for enhanced 90 percent federal Medicaid matching
funds under section 1903(a)(3)(A)(i) of the Act if the expenditures can
be attributed to the design, development, or installation of mechanized
claims processing and information retrieval systems. Additionally, 75
percent federal matching funds under section 1903(a)(3)(B) of the Act
may be available for state expenditures to operate Medicaid mechanized
claims processing and information retrieval systems to comply with this
proposed requirement.
States request Medicaid matching funds under section
1903(a)(3)(A)(i) or (B) of the Act through the Advance Planning
Document (APD) process described in 45 CFR part 95, subpart F. States
are reminded that 42 CFR 433.112(b)(12) and 433.116(c) require them to
ensure that any system for which they are receiving enhanced federal
financial participation under section 1903(a)(3)(A)(i) or (B) of the
Act aligns with and incorporates the ONC Health Information Technology
standards adopted in accordance with 45 CFR part 170, subpart B. The
Payer-to-Payer API, and all APIs proposed in this rule, complement this
requirement

[[Page 82625]]

because these APIs further interoperability through the use of HL7 FHIR
standards proposed for adoption by ONC for HHS use at 45 CFR
170.215.\56\ And, states are reminded that 42 CFR 433.112(b)(10)
explicitly supports exposed APIs as a condition of receiving enhanced
federal financial participation under section 1903(a)(3)(A)(i) or (B)
of the Act.
---------------------------------------------------------------------------

\56\ See SHO # 20-003, https://www.medicaid.gov/federal-policy-guidance/downloads/sho20003.pdf.
---------------------------------------------------------------------------

Similarly, 42 CFR 433.112(b)(13) requires the sharing and re-use of
Medicaid technologies and systems as a condition of receiving enhanced
federal financial participation under section 1903(a)(3)(A)(i) or (B)
of the Act. As noted in section II.B. of this proposed rule, CMS would
interpret that sharing and re-use requirement also to apply to
technical documentation associated with a technology or system, such as
technical documentation for connecting to a state's APIs. Making the
needed technical documentation publicly available so that systems that
need to connect to the APIs proposed in this rule can do so would be
required as part of the technical requirements at 42 CFR 431.60(d) for
all proposed APIs in this rule, including the Payer-to-Payer API.
Separately, for CHIP agencies, section 2105(c)(2)(A) of the Act,
limiting administrative costs to no more than 10 percent of CHIP
payments to the state, would apply in developing the APIs proposed in
this rule.
Again, we note that the temporary federal medical assistance
percentage (FMAP) increase available under section 6008 of the Families
First Coronavirus Response Act (Pub. L. 116-127) does not apply to
administrative expenditures.
In the CMS Interoperability and Patient Access final rule, the
payer-to-payer data exchange is required for Medicaid managed care
plans with an applicability date of January 1, 2022 and codified at 42
CFR 438.62(b)(1)(vi) and (vii). Because this rule proposes to require
implementation and use of a Payer-to-Payer API for Medicaid FFS
programs, and to be consistent with the other provisions of this rule,
we propose to codify the requirement for states in connection with
Medicaid FFS programs at 42 CFR 431.61(b), amend the requirement
specific to Medicaid managed care plans at 42 CFR 438.62(b)(1)(vii) to
sunset the requirements at 438.61(b)(1)(vi) when the new requirements
take effect with the rating period beginning on or after January 1,
2023, and revise 42 CFR 438.242(b)(7) to add a requirement for Medicaid
managed care plans to comply with the requirement imposed on Medicaid
FFS program using a cross reference to 42 CFR 431.61. Codifying the
requirement for Medicaid managed care plans this way would ensure that
the same standards for payer-to-payer data exchange apply across the
Medicaid program, regardless of it is through the FFS or managed care
delivery system. Similarly, we are proposing revisions to the CHIP
managed care regulations to require CHIP managed care entities to
comply with the requirement for an API for payer-to-payer data
exchanges that applies to CHIP FFS programs; the CHIP managed care
entities would also have to comply by the rating period beginning on or
after January 1, 2023. We propose to codify this policy for CHIP
managed care entities at 42 CFR 457.1233(d)(4). Because CHIP managed
care entities are required by current 42 CFR 457.1216 to comply with 42
CFR 438.62, our proposed revisions to 42 CFR 438.62 (for Medicaid
managed care plans) would also apply to CHIP managed care entities.
We request comment on these proposals.
4. Enhancing the Payer-to-Payer Data Exchange--Payer-to-Payer API
In the Interoperability and Patient Access final rule, we
established a payer-to-payer data exchange that required certain
impacted payers to share clinical data as defined in the USCDI version
1 data set with the approval and at the direction of a current or
former enrollee. We did not require that this data exchange take place
using an API, though we encouraged payers to look at an API solution.
We are now proposing to enhance this payer-to-payer data exchange in
two ways. First, we are proposing to require that this payer-to-payer
data exchange take place via an API. Second, we propose to require
impacted payers to make available, at a minimum, not only the USCDI
version 1 data, but also claims and encounter data (not including cost
information) that the payer maintains with a date of service on or
after January 1, 2016, conformant with the same IGs proposed for these
data types in sections II.A. and II.B. of this rule, as well as
information about pending and active prior authorization decisions,
beginning January 1, 2023 (for Medicaid managed care plans and CHIP
managed care entities, by the rating period beginning on or after
January 1, 2023) via this standards-based Payer-to-Payer API. This
Payer-to-Payer API is proposed to use the technical standards and the
same base content and vocabulary standards used for the Patient Access
API. These proposed requirements would be codified for Medicaid and
CHIP FFS programs at 42 CFR 431.61(b) and 42 CFR 457.731(b), Medicaid
managed care plans other than NEMT PAHPs at 42 CFR 438.242(b)(7), CHIP
managed care entities at 42 CFR 457.1233(d)(4), and QHP issuers on the
FFEs at 45 CFR 156.221(f)(2). Ultimately, we believe sharing this
information across payers can improve operational efficiencies, reduce
unnecessary care, reduce care costs, and improve patient outcomes.
Consistent with what was finalized in the CMS Interoperability and
Patient Access final rule, impacted payers who receive these data would
be required to incorporate the data into the payer's records about the
enrollee, making these data part of the data maintained by the
receiving payer. We note that unless expressly stated as part of a
specific proposal, CMS is not proposing to require the receiving payer
to specifically review or act on the data received from other payers.
As explained in the CMS Interoperability and Patient Access final rule
for the Payer-to-Payer Data Exchange, payers could choose to indicate
the part of a data exchange that was received from a previous payer so
a future receiving payer, provider, or even patient, would know where
to direct questions (such as how to address contradictory or inaccurate
information); and we propose that the same principle would apply to
this enhancement. As noted in the CMS Interoperability and Patient
Access final rule (85 FR 25566), impacted payers would be under no
obligation under this proposal to review, utilize, update, validate, or
correct data received from another payer. However, if a payer should
choose to review or otherwise use received data, the payer would not be
prohibited from doing so under any of the policies in this proposed
rule.
We believe a patient's current payer is in an optimal position to
maintain a cumulative record for the patient and facilitate that record
following the patient through their health care journey. Whereas
patients may see many providers, patients' payers have a more holistic
view of a patient's care across providers over time. It is important to
note that, under these proposals, impacted payers would not be required
to exchange any cost information, such as enrollee cost-sharing and
provider remittances. While there could be some value to patients
accessing this cost information via the Patient Access API, sharing
this cost information between payers would have only limited beneficial
impact on care

[[Page 82626]]

coordination. We believe that sharing claims and encounter information
without the cost details, however, could complement the clinical data
as defined in the USCDI by providing more information to support care
coordination and efficient operation, including, for example,
information about the patient's care history. As we discussed in the
CMS Interoperability and Patient Access final rule, and in section
II.B. of this proposed rule, claims and encounter data, used in
conjunction with clinical data, can offer a broader and more holistic
understanding of an individual's interactions with the health care
system (85 FR 25523).
In addition, we believe it would be highly valuable for payers to
share pending and active prior authorization decisions generally, and
particularly when a patient enrolls with a new payer. Currently, when a
patient enrolls with a new payer, little to no information is sent from
the previous payer to the new payer about the prior authorization
decisions the previous payer made or was in the process of making
relevant to the patient's ongoing care. While some previous payers will
make this information available to the new payer upon request, most new
payers do not request such information. Instead, most payers with a
newly enrolling patient require the treating provider to request a new
prior authorization, even for items or services for which a patient has
a valid and current prior authorization approval. The burden of
repeating the prior authorization process with the new payer falls on
the provider and patient, which often impedes continuity of care,
impacting patient outcomes and complicating care coordination. In
addition, it adds burden to payers who must expend time and effort to
review a potentially unnecessary and duplicative prior authorization
request. While we do not propose to require the new payer that would
receive the prior authorization information and documentation under
this proposal to specifically consult this information, at the very
least this information would now form part of the patient's cumulative
record and thus be available to be shared by the payer with the patient
and the patient's care team. Should a payer choose to consult this
information, it could reduce payer, provider, and patient burden, and
possibly cost, over time. If a new payer consulted this information, it
could mean fewer prior authorization requests the provider needs to
send and the payer needs to process. Patients would not have to wait
for a new prior authorization for an item or service they have already
demonstrated they need and would benefit from. This is especially true
of patients with chronic conditions who are changing payers. As a
result, sharing this information between payers could have a
significant impact on payers, providers, and patients. Payers and
providers could see reduced burden, and patients could experience
better, continuous care.
We discuss prior authorization and our proposals regarding prior
authorization processes in more depth in section II.C. of this proposed
rule. As part of this Payer-to-Payer API proposal, we propose at 42 CFR
431.61(b) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid
managed care, at 42 CFR 457.731(b) for CHIP FFS, at 42 CFR
457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.221(f)(2) for
QHP issuers on the FFEs to require all impacted payers make available
pending and active prior authorization decisions (and related clinical
documentation and forms) via the Payer-to-Payer API using the HL7 FHIR
Da Vinci Payer Coverage Decision Exchange (PCDE) \57\ IG proposed at 45
CFR 170.215(c)(4) and integrate this information into the patient's
record for review and consideration. For purposes of this proposal,
``active prior authorization decisions'' means prior authorizations
that are currently open, and being used to facilitate current care, and
are not expired or no longer valid. By ``pending prior authorization
decision,'' we mean prior authorizations that are under review, either
pending submission of documentation from the provider, or being
evaluated by the payer's medical review staff, or for another reason
have not yet had a determination made. As discussed in section II.A.2.
of this proposed rule, when we say ``items and services,'' for purposes
of this rule, we are talking about items and services excluding
prescription drugs and/or covered outpatient drugs. ``Status'' of the
prior authorization means information about whether the prior
authorization is approved, denied, or if more information is needed to
complete the request. We are proposing that impacted payers, consistent
with the proposals for the Patient Access API in section II.A. and the
Provider Access API in section II.B. of this proposed rule, limit
sharing to pending and active authorizations to reduce the volume of
outdated or irrelevant information shared between payers. We propose
that this documentation would include the date the prior authorization
was approved, the date the authorization ends, as well as the units and
services approved and those used to date.
---------------------------------------------------------------------------

\57\ HL7 International. (n.d.). Da Vinci Payer Coverage Decision
Exchange (PCDE) FHIR IG. Retrieved from https://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
---------------------------------------------------------------------------

We request comment on this proposal.
In addition to these proposals, we also seek comment for possible
future rulemaking on the extent to which we should consider explicitly
requiring payers to demonstrate that they have reviewed and considered
these previous prior authorization decisions and associated clinical
documentation from a patient's previous payer before requiring patients
to undergo a new prior authorization process. Such a requirement could
minimize the possibility of duplicate testing for the purposes of
reaffirming coverage or renewing a prior authorization for a covered
benefit that is part of the patient's current care plan. As discussed
in section II.C., providers experience burden when navigating through
each payer's set of prior authorization policies or rules. It is a
burden to payers to administer a prior authorization process. In
addition, requiring a new prior authorization can also delay patient
care. We also seek comment for possible future rulemaking on whether
to, in the alternative, require payers to honor a previous payer's
active prior authorization decisions at the time the enrollee moves
from one payer to a new payer for some length of time, such as 30, 45,
or 60 days, or if there are situations where this may not be possible
or appropriate and why.
This Patient Access API requirement was finalized at 42 CFR
422.119(a) through (e) for MA organizations, 42 CFR 431.60(a) through
(e) for Medicaid FFS, 42 CFR 438.242(b)(5) for Medicaid managed care,
42 CFR 457.730(a) through (e) for CHIP FFS, 42 CFR 457.1233(d) for CHIP
managed care, and at 45 CFR 156.221(a) through (e) for QHP issuers on
the FFEs (85 FR 25558 through 25559). Further, we are proposing the
same content and compliance with the same technical standards, the same
documentation requirements, and the same discontinuation and denial of
access requirements for the Patient Access API (discussed in section
II.A. of this proposed rule) and the Provider Access API (discussed in
section II.B. of this proposed rule) as we are proposing for this
proposed Payer-to-Payer API. This degree of overlap and use of the same
requirements should ease the burden for payers in developing and
implementing these various APIs.

[[Page 82627]]

In addition, all of these APIs would need to be conformant with the
same IGs proposed for claims and encounter data as well as the USCDI
version 1 data as discussed in section II.A. for the Patient Access API
and section II.B. of this proposed rule for the Provider Access API.
The Patient Access API, in particular, provides the foundation
necessary to share claims, encounter, and clinical data. Because the
same data elements would be exchanged through all three APIs, payers
would have already formatted these data elements and prepared their
systems to share these standardized data via a FHIR-based API, doing
much of the work needed to implement this Payer-to-Payer API. As a
result, we believe payers would have devoted the development resources
needed to stand up a FHIR-based API infrastructure that could be
adapted for expanded interoperability use cases after 2021, when they
have implemented the Patient Access API.
However, we are proposing that the Payer-to-Payer API and the
Patient Access and Provider Access APIs be conformant with different
IGs for sharing prior authorization decisions. In sections II.A. and
II.B. of this proposed rule, we propose that the Patient Access and
Provider Access APIs would need to be conformant with the PDex IG when
sharing prior authorization decisions with patients and providers,
respectively. We propose to require the Payer-to-Payer API be
conformant with the PCDE IG instead, when sharing this information, as
this IG addresses data sharing between payers more specifically. PDex
would be better suited for an exchange from a payer to patients and
providers. Given the shared FHIR resources across the two IGs, we do
not believe requiring the use of both IGs--one for each appropriate
recipient of the data--adds significant burden to payers.
5. Payer-to-Payer API--Sharing Data at Enrollment
As finalized in the CMS Interoperability and Patient Access final
rule, the payer-to-payer data exchange is initiated at the direction of
the patient. We discussed proposed enhancements to this patient-
directed data sharing in the previous section where we noted this data
exchange would now require the use of an API and include additional
data to be shared. In addition to this case-by-case, patient-directed
data sharing, however, we also propose a second, new Payer-to-Payer API
data sharing opportunity that would be offered to all patients
receiving coverage from a payer impacted by this proposed rule as an
option at the time of enrollment with a new payer, if both the current
payer and new payer would be subject to the requirements in this
proposal. We propose to codify this new Payer-to-Payer API requirement
at 42 CFR 431.61(c) for Medicaid FFS, at 42 CFR 438.242(b)(7) for
Medicaid managed care, at 42 CFR 457.731(c) for CHIP FFS, at 42 CFR
457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b) for QHP
issuers on the FFEs. We are proposing that this exchange be offered to
patients receiving coverage from payers impacted by this proposed rule
as an option when they enroll with a new payer. The new payer, if an
impacted payer under this proposed rule, could then request the data
from the previous payer for patients who opt-in to this data sharing
via the Payer-to-Payer API.
We are proposing the following if a patient enrolls during a
specified annual open enrollment period, or, for a payer that does not
have such an enrollment period, during the first calendar quarter of
each year. If such a patient opts-in to having their new payer obtain
the applicable data from their previous payer at this specified time,
we are proposing to require that impacted new payers request such data
from the previous payers via the Payer-to-Payer API using the HL7 FHIR
Bulk Data Access (Flat FHIR) specification within one week of the end
of the enrollment period or the first calendar quarter of each year.
The previous payer, if an impacted payer, would be required to respond
to this request within one business day of receiving the request.
We do recognize that not every impacted payer has a dedicated
annual open enrollment period. For those payers, we are proposing that
the opt-in Bulk data sharing occur at the end of the first calendar
quarter of each year. We seek comment on whether this is the best time
to require the data sharing for such payers. Based on our experience
with Bulk data sharing discussed in section II.B.4. of this proposed
rule, and based on discussions with payers and technology developers,
we believe the efficiencies afforded by having at least one time per
year where payers could facilitate this data sharing and employ the
Bulk specification to leverage the opportunity to make data available
for as many patients as possible at one time could be potentially
significant because such an asynchronous data sharing option could
limit drain on system resources and promote a dedicated and efficient
opportunity each year to ensure patients have their health information
follow them as they move from payer to payer, permitting better care
coordination and potentially better health outcomes. Therefore, we seek
comment on how best to operationalize this across impacted payers. We
also see comment on whether the timeframes for the new payer requesting
these data--within one week of this enrollment or other defined period
ending--and the old payer sending these data--within one business day
of receiving the request--are the optimal timeframes and what other
timeframes payers may want us to consider. Would payers be able to
accommodate a shorter request timeframe--such as one to three business
days after the end of the defined enrollment period? Or, do payers need
more than one business day to respond to a request? If so, would payers
want to have a one week turnaround for data requests? We do think it is
important for patient data to move to the new payer as soon as possible
to facilitate care coordination, and to ensure the patient's data is
available to their providers and to them, hence our current proposal.
We also seek comment on whether we should consider any other factors
regarding the process and timeline for this Payer-to-Payer API data
sharing at enrollment.
Efficient data sharing between payers would ensure that information
that could support payer operations and benefit patient care is
available to a new payer at the very start of the patient's care
covered by a new payer. This could facilitate care coordination and
continuity of care. This proposal would require the new payer to adopt
a process to obtain the name of an enrollee's previous payer, or
concurrent payer if the enrollee has coverage through more than one
payer, as part of the enrollment process. Subsequently, the new payer
would be required to receive the enrollee's clinical data as defined in
the USCDI version 1 and adjudicated claims and encounter data, as well
as pending and active prior authorization decisions, from the previous
or concurrent payer, if that payer maintains such data for the relevant
enrollee.
Under this proposal, impacted payers would be required to maintain
a process for capturing data about each patient's previous payer and
concurrent payer (if there is one) at enrollment to facilitate this
payer-to-payer data sharing. While we wish to leave it to each impacted
payer how they choose to implement capturing this information, we seek
comment on potential solutions to support payers in obtaining this
previous and concurrent payer information in an effort to provide all
impacted payers with options to consider. As to concurrent payers, we
anticipate that many payers already

[[Page 82628]]

have a process in place to request and update information of this sort
for coordination of benefits or to implement Medicare Secondary Payer
requirements (if applicable), and we wish to allow payers to maintain
their current processes if that is beneficial and feasible when
incorporating the use of the Payer-to-Payer API into this process.
We are proposing at 42 CFR 431.61(c)(5) for Medicaid FFS, at 42 CFR
438.242(b)(7) for Medicaid managed care, at 42 CFR 457.731(c)(5) for
CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP managed care, and at 45 CFR
156.222(b)(5) for QHP issuers on the FFEs, that payers put a process in
place to allow enrollees to opt-in to this payer-to-payer data sharing
at enrollment, similar to the opt-in proposal under the Provider Access
APIs detailed in section II.B. of this proposed rule. If enrollees do
not actively opt-in, impacted payers would not be required to share
their data through the Payer-to-Payer API as described under this
proposal. This means that only at the defined enrollment period, or at
the end of the first calendar quarter for payers that do not have a
defined enrollment period, are impacted payers required under this
proposal to have a process in place to capture a patient's preference
to opt-in to this data sharing under this proposal. If a patient would
like their data shared with another payer at another time throughout a
given year, the patient could request that data exchange under the
enhanced payer-to-payer data exchange proposal discussed in section
II.D.4. of this proposed rule.
We seek comment on these proposals.
Some individuals may have concurrent coverage with two or more of
the payers impacted by this proposal. We also propose at 42 CFR
431.61(c)(4) for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid
managed care, at 42 CFR 457.731(c)(4) for CHIP FFS, at 42 CFR
457.1233(d)(4) for CHIP managed care, and at 45 CFR 156.222(b)(4) for
QHP issuers on the FFEs that when an enrollee has concurrent coverage
with two or more impacted payers, the impacted payers must make the
patient's data available to the concurrent payer quarterly, in addition
to when the enrollee obtains new coverage from a payer subject to these
proposed requirements. We propose to require payers to provide
enrollees the opportunity to opt-in to initiate this quarterly data
sharing. This data exchange among concurrent payers is expected to
support better care coordination and more efficient operations. We also
considered whether to propose more frequent exchange (weekly or
monthly), and less frequent exchange (semi-annually or annually);
however, we believe a quarterly data exchange would strike the right
balance in providing accurate, timely data with minimal payer burden.
We request comment on this proposal, including the appropriate
frequency for this payer-to-payer exchange for enrollees with
concurrent coverage. We also seek comment on whether payers prefer the
flexibility to define their own process for facilitating how patients
opt-in to this quarterly data sharing and if there are additional
considerations that we should take into account to facilitate data
sharing using the Payer-to-Payer API between concurrent payers.
We appreciate that a patient may be moving to or from a payer, or
have concurrent coverage with a payer not subject to the requirements
in this proposed rule, such as when a patient moves from a QHP on the
FFE to an employer-based plan, as an employer-based plan is not
impacted by this rulemaking. We encourage all payers to consider the
value of implementing a Payer-to-Payer API so that all patients,
providers, and payers in the U.S. health care system may ultimately
experience the benefits of such data sharing. For instance, we are
exploring best next steps for the Medicare FFS program to participate
in a Payer-to-Payer API data exchange with all interested payers. That
said, if an impacted payer learns that a previous or concurrent payer
is not subject to this proposal, we encourage the new payer to evaluate
if the other payer can accommodate an API data exchange and seek such
exchange in accordance with applicable law. However, an impacted payer
would not be required to try to send data to or receive data from a
payer that is not required to exchange data through the Payer-to-Payer
API under this proposal.
As discussed in section II.B. of this proposed rule, and as further
illustrated in the discussion in this section of this proposed rule, it
may be valuable for a payer to share data with another payer for more
than one patient at a time. It is likely that if payers are sharing
data at enrollment, impacted payers would have many patients' data to
share at one time. In such a situation, it can be burdensome to make an
API call for each patient. This could require significant technological
resources and time. To introduce additional efficiencies, we are
proposing that this required Payer-to-Payer API must be able to share
the specified data conformant with the HL7 FHIR Bulk Data Access (Flat
FHIR) specification at 45 CFR 170.215(a)(4) to facilitate sharing
information relevant to one or more patients at one time. We are
proposing to codify this specific requirement at 42 CFR 431.61(c)(1)
for Medicaid FFS, at 42 CFR 438.242(b)(7) for Medicaid managed care, at
42 CFR 457.731(c)(1) for CHIP FFS, at 42 CFR 457.1233(d)(4) for CHIP
managed care, and at 45 CFR 156.222(b)(1) for QHP issuers on the FFEs.
We request comment on this proposal.
As with the proposal for the Provider Access API, discussed in
section II.B. of this proposed rule, we invite comment on the tradeoffs
and benefits of having the Payer-to-Payer API available with and
without the use of the HL7 FHIR Bulk Data Access (Flat FHIR)
specification. We believe both approaches would offer benefits to
payers depending on the specifics of the situation in which they would
need to share patient data. As we look to balance providing this
flexibility with the burden of implementing and maintaining APIs, we
invite public comment on the benefits of having the Payer-to-Payer API
available with and without the use of the HL7 FHIR Bulk Data Access
(Flat FHIR) specification, which can be leveraged to request the data
for a single patient or multiple patients.
6. Extensions and Exemptions for Medicaid and CHIP
If our proposals regarding the Payer-to-Payer API are finalized, we
would encourage state Medicaid and CHIP FFS programs to implement the
Payer-to-Payer API as soon as possible understanding the many benefits
of the API as discussed previously in this section.
However, we also recognize that state Medicaid or CHIP FFS agencies
could face certain unique circumstances that would not apply to other
impacted payers, as discussed in more detail later in this section. As
a result, a few states might need to seek an extension of the
compliance deadline or an exemption from these requirements. To address
this concern, we are proposing a process through which states may seek
an extension of and, in specific circumstances, an exemption from, the
Payer-to-Payer API requirements if they are unable to implement these
API requirements, consistent with the extension and exemption proposals
for the Provider Access API in section II.B., and the DRLS and PAS APIs
in section II.C. of this proposed rule. Providing these flexibilities
might allow these states to continue building technical capacity in
support of overall interoperability goals consistent with their needs.
Therefore, we propose the following.

[[Page 82629]]

Extension. At 42 CFR 431.61(e)(1) and 42 CFR 457.731(e)(1),
respectively, we propose to provide states--for Medicaid FFS and CHIP
FFS--the opportunity to request a one-time extension of up to one (1)
year for the implementation of the Payer-to-Payer API specified at 42
CFR 431.61(b) and (c) and 42 CFR 457.731(b) and (c). Unique
circumstances that might present a challenge to specific states to meet
the proposed compliance date could include resource challenges, such as
funding. Depending on when the final rule is published in relation to a
state's budget process and timeline, some states may not be able to
secure the needed funds in time to both develop and execute
implementation of the API requirements by the proposed compliance date.
A one-year extension could help mitigate this issue. And, some states
may need to initiate a public procurement process to secure contractors
with the necessary skills to support a state's implementation of these
proposed API policies. The timeline for an open, competed procurement
process, together with the time needed to onboard the contractor and
develop the API, could require additional time as well. Finally, a
state might need to hire new staff with the necessary skillset to
implement this policy. Again, the time needed to initiate the public
employee hiring process, vet, hire, and onboard the new staff may make
meeting the proposed compliance timeline difficult, because, generally
speaking, public employee hiring processes include stricter guidelines
and longer time-to-hire periods than other sectors.\58\ In all such
situations, a state might need more time than other impacted payers to
implement the requirements.
---------------------------------------------------------------------------

\58\ State hiring processes are comparable with federal hiring
processes. According to OMB, the average time-to-hire for federal
employees was 98.3 days in 2018, significantly higher than the
private sector average of 23.8 days. See: https://www.opm.gov/news/releases/2020/02/opm-issues-updated-time-to-hire-guidance/.
---------------------------------------------------------------------------

If a state believes it can demonstrate the need for an extension,
its request must be submitted and approved as a part of its annual
Advance Planning Document (APD) for MMIS operations costs and must
include the following: (1) A narrative justification describing the
specific reasons why the state cannot reasonably satisfy the
requirement(s) by the compliance date, and why those reasons result
from circumstances that are unique to states operating Medicaid or CHIP
FFS programs, (2) a report on completed and ongoing implementation
activities to evidence a good faith effort toward compliance, and (3) a
comprehensive plan to meet implementation requirements no later than
one year after the initial compliance date.
An extension would be granted if CMS determines based on the
information provided in the APD that the request adequately establishes
a need to delay implementation, a good faith effort to implement the
proposed requirements as soon as possible, and a clear plan to
implement no later than one year after the proposed compliance date. We
would expect states to explain why the request for an extension results
from circumstances that are unique to states operating Medicaid or CHIP
FFS programs. We also solicit comment on whether our proposal would
adequately address the unique circumstances that affect states, and
that might make timely compliance with the proposed API requirement
sufficiently difficult for states and thus justify an extension. In
particular, we seek comment on whether we should require or use
additional information on which to base the determination or whether we
should establish different standards in the regulation text for
evaluating and granting the request.
Exemption. At 42 CFR 431.61(e)(2) and 42 CFR 457. 731(e)(2),
respectively, we propose two circumstances that would permit state
requests for exemption; namely, (1) when at least 90 percent of all
covered items and services are provided to Medicaid or CHIP
beneficiaries through Medicaid or CHIP managed care contracts with
MCOs, PIHPs, or PAHPs, rather than through a FFS delivery system; or
(2) when at least 90 percent of the state's Medicaid or CHIP
beneficiaries are enrolled in Medicaid or CHIP managed care
organizations as defined in 42 CFR 438.2 for Medicaid and 42 CFR 457.10
for CHIP. In both circumstances, the time and resources that the state
would need to expend to implement the API requirements may outweigh the
benefits of implementing and maintaining the API. As discussed in
section II.B. of this proposed rule, unlike other impacted payers,
state Medicaid and CHIP FFS programs do not have a diversity of plans
to balance implementation costs for those plans with low enrollment. If
there is low enrollment in a state Medicaid or CHIP FFS program, there
is no potential for the technology to be leveraged for additional
beneficiaries as states, unlike other payers, do not maintain
additional lines of business.
We acknowledge that the proposed exemption could mean that a few
Medicaid or CHIP FFS systems would not receive the benefits of having
this API available to facilitate health information exchange. To
address this, we propose that states meeting the above thresholds would
be expected to employ an alternative plan to enable the electronic
exchange and accessibility of health information for those
beneficiaries who are served under the FFS program.
A state meeting the above criteria would be permitted to submit a
request for an exemption to the requirements for the Payer-to-Payer API
once per calendar year for a one-year exemption. The state would be
required to submit this annual request as part of a state's annual APD
for MMIS operations costs. The state would be required to include in
its request documentation that it meets the criteria for the exemption
using data from any one of the three most recent and complete calendar
years prior to the date the exemption request is made. We note we
propose that this request be made annually as from year-to-year the
nature of the FFS population could change and so it is important that
the state provide the most current information for CMS's consideration.
Exemptions would be granted for a one-year period if a state
establishes to CMS's satisfaction that it meets the criteria for the
exemption and has established a plan to ensure that all impacted payers
would have efficient electronic access to the same information through
alternative means.
We request comment on the proposed extension and exemption.
For Medicaid and CHIP managed care, we are not proposing an
extension process at this time because we believe that managed care
plans are actively working to develop the necessary IT infrastructure
to be able to comply with the existing requirements in 42 CFR part 438
and part 457 and also benefit from efficiencies resulting from their
multiple lines of business impacted by these interoperability policies.
Many managed care plans are part of parent organizations that maintain
multiple lines of business, including Medicaid managed care plans and
plans sold on the Exchanges. As discussed in the CMS Interoperability
and Patient Access final rule (85 FR 25607, 25612, 25620), work done by
these organizations can benefit all lines of business and, as such, we
do not believe that the proposals in this rule impose undue burden or
are unachievable by the compliance date. We are soliciting comment on
whether our belief concerning the scope of resources and ability of
managed care parent organizations to achieve economies of scale is
well-founded. Further, we seek comment on whether an extension process
is warranted for

[[Page 82630]]

certain managed care plans to provide additional time for the plan to
comply with the requirement at proposed 42 CFR 438.242(b)(7) (which
cross references 42 CFR 438.61(b) and (c)) for Medicaid managed care
plans and at proposed 42 CFR 457.1233(d)(4) (which cross references 42
CFR 457.731(b) and (c)) for CHIP managed care entities. While we are
not proposing such a process for managed care plans and entities and do
not believe one is necessary for the reasons outlined here, we are open
to considering one if necessary. If we adopt an extension process for
these managed care plans and entities, what criteria would a managed
care plan or entity have to meet to qualify for an extension? Should
the process consider, for example, enrollment size, plan type, or some
unique characteristic of certain plans that could hinder their
achievement of the proposed requirements by the proposed compliance
date? Also, we seek comment on whether, if we finalize such a process
for Medicaid managed care plans or CHIP managed care entities, the
state or CMS should manage the process and whether states could
successfully adopt and implement the process on the timeline necessary
to fulfill the goals and purposes of the process. Consistent with the
exception process proposed for QHP issuers on the FFEs at 45 CFR
156.222(d), we would expect any extension request to include, at a
minimum, a narrative justification describing the reasons why a plan or
entity cannot reasonably satisfy the requirements by the proposed
compliance date, the impact of non-compliance upon enrollees, the
current or proposed means of providing electronic health information to
providers, and a corrective action plan with a timeline to achieve
compliance.
We do propose, however, to exclude non-emergency transportation
(NEMT) PAHPs from the Payer-to-Payer API proposals. In this rule, we
propose to require MCOs, PIHPs, and PAHPs other than NEMT PAHPs (as
defined at 42 CFR 438.9(a)) to implement and maintain the Payer-to-
Payer API. We believe that the unique nature and limited scope of the
services provided by NEMT PAHPs is not consistent with the proposed
purposes of the Payer-to-Payer API proposed at 42 CFR 431.61(b) and
(c). Specifically, we do not believe that having all other Medicaid
managed care plans, such as acute care or dental managed care plans, be
required to request, receive, and incorporate into the plan's records
NEMT data from an enrollee's prior or concurrent payer would help
achieve the goals of the Payer-to-Payer API, namely to help avoid
unnecessary care, ensure that providers are able to spend time with
patients focusing on care versus collecting redundant information, or
improve patient care through enhanced care coordination. Conversely, we
do not believe having NEMT PAHPs be required to request, receive, and
incorporate into its records enrollee data from other managed care
plans contributes to achieving the goals of the Payer-to-Payer API
given the unique nature and limited scope of the services they provide.
We note that the HIPAA Privacy Rule, at 45 CFR 164.502, permits a
covered entity to use or disclose PHI for certain treatment, payment,
or health care operations without individual authorization. As such, we
believe a health plan that needs NEMT PAHP utilization for treatment,
payment, or the applicable health care operations for a current
enrollee, would generally be permitted to under the applicable HIPAA
provisions.
As mentioned previously in this proposed rule, although Medicare
FFS is not directly impacted by this rule, we do note that we are
targeting to implement a Payer-to-Payer API for the Medicare FFS
program, if finalized. In this way, the Medicare FFS Payer-to-Payer API
would conform to the same requirements that apply to the impacted
payers under this rulemaking, as applicable, so that Medicare FFS
beneficiaries would also benefit from this data sharing.
7. Exception for QHP Issuers
With regard to QHP issuers on the FFEs, similar to our exceptions
process noted in the CMS Interoperability and Patient Access final rule
for the Patient Access API (85 FR 25552 through 25553) and in section
II.B.6.e. of this proposed rule for the Provider Access API, we are
also proposing an exception for the Payer-to-Payer API at 45 CFR part
156.222(d). As such, if a plan applying for QHP certification to be
offered through a FFE believes it cannot satisfy the Payer-to-Payer API
requirements, the issuer must include as part of its QHP application a
narrative justification describing the reasons why the plan cannot
reasonably satisfy the requirements for the applicable plan year, the
impact of non-compliance upon enrollees, the current or proposed means
of providing health information to payers, and solutions and a timeline
to achieve compliance with the requirements of this section. Further,
we propose that the FFE may grant an exception to these requirements if
the Exchange determines that making such health plan available through
such Exchange is in the interests of qualified individuals and
qualified employers in the state or states in which such Exchange
operates.
We request comment on this proposal.
8. Statutory Authorities for Payer Exchange Proposals
a. Medicaid and CHIP
For Medicaid managed care plans and Medicaid state agencies, we are
proposing to require the implementation of a Payer-to-Payer API to
exchange claims, encounter, clinical, and pending and active prior
authorizations data between payers at a patient's request or any time a
patient changes payers using a FHIR-based API. Our proposals in this
section fall generally under our authority in the following provisions
of the statute:
Section 1902(a)(4) of the Act, which requires that a state
Medicaid plan provide such methods of administration as are found by
the Secretary to be necessary for the proper and efficient operation of
the state Medicaid plan.
Section 1902(a)(8) of the Act, which requires states to
ensure that Medicaid services are furnished with reasonable promptness
to all eligible individuals.
Section 1902(a)(19) of the Act, which requires states to
ensure that care and services are provided in a manner consistent with
simplicity of administration and the best interests of the recipients.
We note statutory authority for proposals to require specific IGs
for this and all APIs proposed in this rule is discussed in section
II.A.3. of this proposed rule.
We believe these proposals related to the Payer-to-Payer API are
authorized by these provisions of the Act for the following reasons.
First, because the Payer-to-Payer API is designed to enable efficient
exchange of data between payers, it is anticipated to help state
Medicaid programs improve the efficiencies and simplicity of their own
operations, consistent with sections 1902(a)(4) and (a)(19) of the Act.
Use of the Payer-to-Payer API could introduce efficiencies in providing
Medicaid services, by reducing duplicate prior authorization requests,
referrals, or tests. In addition, as is discussed in section II.B. of
this proposed rule, with respect to the Provider Access API and the
Bulk specification, this Payer-to-Payer API, by allowing payers to
share health information for one or more patients at once, could
increase efficiency and simplicity of administration. It could give
payers access to all of their enrollees' information with limited

[[Page 82631]]

effort and enable the state to then make that information available to
providers and to patients through the Provider Access and Patient
Access APIs. And, it could reduce the amount of time needed to evaluate
a patient's current care plan and possible implications for care
continuity, which could introduce efficiencies and improve care. Use of
the proposed Bulk specification allows state Medicaid programs to
receive information on a full panel of patients at once, thus
expediting the data collection process. Sharing patient information for
a full panel of patients at a specified time annually, such as at the
end of the first calendar quarter, would help to ensure payers receive
patient information in a timely manner when a beneficiary moves to a
new payer, and therefore, could lead to more appropriate service
utilization and higher beneficiary satisfaction by supporting efficient
care coordination and continuity of care as beneficiaries move from
payer to payer, which could lead to better health outcomes.
Second, the proposals are expected to help states and managed care
plans furnish Medicaid services with reasonable promptness and in a
manner consistent with beneficiaries' best interests, consistent with
section 1902(a)(8) and (a)(19) of the Act, for the following reasons.
If states were to share information about Medicaid beneficiaries or
former beneficiaries with other payers with whom these beneficiaries
are enrolled, they could support opportunities for improved care
coordination for Medicaid beneficiaries and former beneficiaries.
Exchanging information about Medicaid beneficiaries and former
beneficiaries between payers might also reduce the amount of time
needed to evaluate a Medicaid beneficiary's current care plan, their
health risks, and their health conditions at the time that beneficiary
enrolls with the Medicaid program. Exchanging this information between
payers could also better support care continuity for Medicaid
beneficiaries. As discussed in section II.D.4. of this proposed rule,
if a state Medicaid program has access to a previous payer's pending
and active prior authorization decisions, the Medicaid program could
choose to accept the existing decision and support continued patient
care without requiring a new prior authorization or duplicate tests.
This information exchange might be of particular value in improving
care continuity for beneficiaries who might churn into and out of
Medicaid coverage, or have concurrent coverage in addition to Medicaid.
The proposal could also improve the provision of Medicaid services, by
potentially helping to ensure that Medicaid beneficiaries who may
require coordinated services with concurrent payers could be identified
and provided case management services, as appropriate.
For Medicaid managed care plans, the proposed exchange of claims,
encounter, USCDI, and some prior authorization data would greatly
enhance an MCO's, PIHP's, or PAHP's ability to fulfill its obligations
under 42 CFR 438.208(b) which require them to: Implement procedures to
deliver care to and coordinate services including ensuring that each
enrollee has an ongoing source of appropriate care; coordinate services
between settings of care, among Medicaid programs, and with community
and social support providers; make a best effort to conduct an initial
screening of each enrollee's needs; and share with the state or other
MCOs, PIHPs, and PAHPs serving the enrollee the results of any
identification and assessment of that enrollee's needs to prevent
duplication of those activities. The data provided via the Payer-to-
Payer API proposed in this rule would give managed care plans the
information needed to much more easily perform these required
functions, thus enhancing the effectiveness of the care coordination
and helping enrollees receive the most appropriate care in an effective
and timely manner.
For CHIP, we are proposing these requirements under our authority
in section 2101(a) of the Act, which states that the purpose of title
XXI is to provide funds to states to provide child health assistance to
uninsured, low-income children in an effective and efficient manner
that is coordinated with other sources of health benefits coverage. We
believe the provisions in this proposed rule could strengthen our
ability to fulfill these statutory obligations in a way that recognizes
and accommodates the use of electronic information exchange in the
health care industry today and would facilitate a significant
improvement in the delivery of quality health care to our
beneficiaries.
As with the Medicaid FFS and Medicaid managed care programs, the
proposals in this section of the proposed rule for CHIP FFS and CHIP
managed care require the use of a Payer-to-Payer API to exchange
claims, encounter, clinical and pending and active prior authorization
data at a beneficiary's request, or any time a beneficiary changes
payers, using a FHIR-based API. The current payer could use data from
the prior payer to more effectively or accurately respond to a request
for a prior authorization, because under this proposal, a new payer
would have historical claims or clinical data upon which they may
review a request with more background data. Access to information about
new patients could enable appropriate staff within the CHIP program to
more effectively coordinate care and conduct the care management
because they would have better data available to make decisions for
planning. In many cases, patients do not remember what services they
have had, what vaccines they have had, or other possibly relevant
encounters that could help payers manage their care. This proposal is
consistent with the goal of providing more informed and effective care
coordination, which could help to ensure that CHIP services are
provided in a way that supports quality care, which aligns with section
2101(a).
b. QHP Issuers on the FFEs
For QHP issuers on the FFEs, we are proposing these new
requirements under our authority in section 1311(e)(1)(B) of the
Affordable Care Act, which affords the Exchanges the discretion to
certify QHPs if the Exchange determines that making available such
health plans through the Exchange is in the interests of qualified
individuals in the state in which the Exchange operates. Existing and
emerging technologies provide a path to make information and resources
for health and health care management universal, integrated, equitable,
accessible to all, and personally relevant.
Requiring QHP issuers on the FFEs to build and maintain a Payer-to-
Payer API would allow the seamless flow of claims and encounter data,
the clinical data the payer maintains for a patient as defined in the
USCDI version 1, as well as their pending and active prior
authorization decisions, from payer to payer. We believe that ensuring
a means for an enrollee's new issuer to electronically obtain the
enrollee's claims, encounter, and clinical data, as well as prior
authorization information with corresponding medical records, from the
previous issuer will reduce administrative burden and result in more
timely and efficient care coordination and responses to prior
authorization requests.
We believe it is necessary that QHP issuers on FFEs have systems in
place to send information important to care coordination with departing
enrollees, and that QHP issuers also have systems in place to receive
such information from payer to payer on behalf of new and concurrent
enrollees, as appropriate

[[Page 82632]]

and consistent with the proposals in this section. Therefore, we
believe certifying only health plans that make enrollees' health
information available to them and their providers, and as discussed in
this section, other payers, in a convenient, timely, and portable way
is in the interests of qualified individuals and qualified employers in
the state in which an FFE operates. We encourage SBEs to consider
whether a similar requirement should be applicable to QHP issuers
participating in their Exchange.
We previously finalized the Payer-to-Payer Data Exchange in the CMS
Interoperability and Patient Access final rule, where, with the
approval and at the direction of an enrollee, one payer would have to
send clinical data as defined in the USCDI version 1 to another payer
named by the enrollee. We are now requiring this to be done via an API
and adding claims and encounter data, as well as pending and active
prior authorization decisions.
We also believe that requiring QHP issuers on the FFEs to use the
Bulk Specification for the Payer-to-Payer API would improve the
efficiency and simplicity of data transfers between issuers, by
enabling the exchange of all data for all patients at once. We believe
the opportunity to support an exchange of large volumes of patient
data, rather than data for one patient at a time, may be cost effective
for the issuers, and having patient care at the beginning of a new
plan, could assist the new payer in identifying patients who need care
management services, which could reduce the cost of care. Taking in
volumes of data would also enable the QHPs to perform analysis on the
types of new patients in their plan, if they choose to analyze data for
existing patients as well.

E. Adoption of Health IT Standards and Implementation Specifications

As first mentioned in section II.A. of this proposed rule, at 45
CFR 170.215, ONC is proposing the specific IGs discussed in sections
II.A., II.B., II.C., and II.D. of this proposed rule for HHS adoption
in support of the API provisions included in this proposed rule. This
section outlines ONC's authority to do so, and how this will support
HHS generally, and CMS specifically, in continuing to advance standards
and the use of FHIR to reduce burden, improve the prior authorization
process, and support patient electronic access to health information.
1. Statutory Authority
The Health Information Technology for Economic and Clinical Health
(HITECH) Act, Title XIII of Division A and Title IV of Division B of
the American Recovery and Reinvestment Act of 2009 (the Recovery Act)
(Pub. L. 111-5), was enacted on February 17, 2009. The HITECH Act
amended the Public Health Service Act (PHSA) and created ``Title XXX--
Health Information Technology and Quality'' (Title XXX) to improve
health care quality, safety, and efficiency through the promotion of
health IT and exchange of electronic health information (EHI).
Subsequently, Title IV of the 21st Century Cures Act (Pub. L. 114-255)
(``Cures Act'') amended portions of the HITECH Act by modifying or
adding certain provisions to the PHSA relating to health IT.
a. Adoption of Standards and Implementation Specifications
Section 3001 of the PHSA directs the National Coordinator for
Health Information Technology (National Coordinator) to perform duties
in a manner consistent with the development of a nationwide health
information technology infrastructure that allows for the electronic
use and exchange of information. Section 3001(b) of the PHSA
establishes a series of core goals for development of a nationwide
health information technology infrastructure that:
Ensures that each patient's health information is secure
and protected, in accordance with applicable law;
Improves health care quality, reduces medical errors,
reduces health disparities, and advances the delivery of patient-
centered medical care;
Reduces health care costs resulting from inefficiency,
medical errors, inappropriate care, duplicative care, and incomplete
information;
Provides appropriate information to help guide medical
decisions at the time and place of care;
Ensures the inclusion of meaningful public input in such
development of such infrastructure;
Improves the coordination of care and information among
hospitals, laboratories, physician offices, and other entities through
an effective infrastructure for the secure and authorized exchange of
health care information;
Improves public health activities and facilitates the
early identification and rapid response to public health threats and
emergencies, including bioterror events and infectious disease
outbreaks;
Facilitates health and clinical research and health care
quality;
Promotes early detection, prevention, and management of
chronic diseases;
Promotes a more effective marketplace, greater
competition, greater systems analysis, increased consumer choice, and
improved outcomes in health care services; and
Improves efforts to reduce health disparities.
Section 3004 of the PHSA identifies a process for the adoption of
health IT standards, implementation specifications, and certification
criteria, and authorizes the Secretary to adopt such standards,
implementation specifications, and certification criteria. As specified
in section 3004(a)(1) of the PHSA, the Secretary is required, in
consultation with representatives of other relevant federal agencies,
to jointly review standards, implementation specifications, and
certification criteria endorsed by the National Coordinator under
section 3001(c) of the PHSA and subsequently determine whether to
propose the adoption of any grouping of such standards, implementation
specifications, or certification criteria. The Secretary is required to
publish all determinations in the Federal Register.
Section 3004(b)(3) of the PHSA, which is titled ``Subsequent
Standards Activity,'' provides that the Secretary shall adopt
additional standards, implementation specifications, and certification
criteria as necessary and consistent with the schedule published by the
Health IT Advisory Committee (HITAC). As noted in the final rule,
``2015 Edition Health Information Technology (Health IT) Certification
Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition,
and ONC Health IT Certification Program Modifications'' (``ONC 2015
Edition Final Rule''), published on October 16, 2015, we consider this
provision in the broader context of the HITECH Act and the Cures Act to
continue to grant the Secretary the authority and discretion to adopt
standards, implementation specifications, and certification criteria
that have been recommended by the HITAC and endorsed by the National
Coordinator, as well as other appropriate and necessary health IT
standards, implementation specifications, and certification criteria
(80 FR 62606).
Under the authority outlined in section 3004(b)(3) of the PHSA, the
Secretary may adopt standards, implementation specifications, and
certification criteria as necessary even if those standards have not
been recommended and endorsed through the process established for the
HITAC under section 3002(b)(2) and (3) of the PHSA. Moreover, while HHS
has traditionally adopted standards and implementation

[[Page 82633]]

specifications at the same time as adopting certification criteria that
reference those standards, the Secretary also has the authority to
adopt standards or implementation specifications apart from the
certification criteria adopted specifically for the voluntary
certification of health IT under the ONC Health IT Certification
Program.
Finally, the Cures Act amended the PHSA to add section 3004(c) of
the PHSA to specify that in adopting and implementing standards under
this section, the Secretary shall give deference to standards published
by standards development organizations and voluntary consensus-based
standards bodies.
b. Coordination of Federal Activities With Adopted Standards and
Implementation Specifications, and Application to Private Entities
Section 13111 of the HITECH Act requires that when a federal agency
implements, acquires, or upgrades health information technology systems
used for the direct exchange of individually identifiable health
information between agencies and with non-federal entities, it shall
utilize, where available, health information technology systems and
products that meet standards and implementation specifications adopted
under section 3004 of the PHSA, as added by section 13101 of the HITECH
Act. Similarly, section 13112 of the HITECH Act states that federal
agencies shall require in its contracts and agreements with providers,
plans, or issuers that as each provider, plan, or issuer implements,
acquires, or upgrades health information technology systems, it shall
utilize, where available, health information technology systems and
products that meet standards and implementation specifications adopted
under section 3004 of the PHSA.
2. Background
Consistent with section 3004(b)(3) of the PHSA, we believe the
standards and implementation specifications proposed at 45 CFR 170.215
by ONC for HHS adoption are appropriate and necessary and would, if
adopted, contribute to key health care priorities of a nationwide
health IT infrastructure as described in section 3001(b) of the PHSA.
The use of the identified implementation specifications across health
IT systems would support more effective prior authorization
transactions between providers and payers, and would help to reduce
administrative burden and support medical decision-making. Use of the
proposed payer data implementation specifications would help to bring
together administrative and clinical data, and make such data
accessible, which is an essential step to connecting cost and quality
data to promote a more effective marketplace, greater competition,
greater systems analysis, increased consumer choice, and improved
outcomes in health care services. Finally, use of the additional
implementation specifications for a Provider Directory API would
support more robust care coordination and increased patient choice
through improved availability of health care provider contact and
exchange information. In support of these likely outcomes, we note that
the CMS proposals in sections II.A., II.B., II.C., and II.D. of this
rule detail further benefits that would result from the use of these
implementation specifications for each of the relevant CMS payer API
requirement proposals.
In the following section, consistent with section 3004(b)(3) of the
PHSA and on behalf of the Secretary, ONC proposes to adopt at 45 CFR
170.215(c) implementation specifications for APIs based upon the
HL7[supreg] FHIR[supreg] Release 4 base standard adopted by ONC on
behalf of HHS at 45 CFR 170.215(a). The proposed implementation
specifications were developed through a voluntary consensus-based
standard organization, HL7[supreg], a non-profit standard development
organization. In concert with CMS, ONC has led or participated in a
variety of activities related to monitoring and evaluating the
standards and implementation specifications identified in this proposed
rule, utilizing available mechanisms for gathering input on these
standards from stakeholders and experts. Based on these activities and
input, it is appropriate to propose these specifications for adoption.
a. Standards Development Organization Activities
Consistent with section 3004(c) of the PHSA, the implementation
specifications proposed for adoption have been developed through an
industry-led, consensus-based public process by a nationwide voluntary
consensus-based standards body. HL7[supreg] is an American National
Standards Institute (ANSI) accredited standards development
organization. HL7[supreg] FHIR[supreg] standards are unique in their
ability to allow disparate systems that otherwise represent data
differently to exchange such data in a standardized way that all
systems can share and consume via standards-based APIs. HL7[supreg]
FHIR[supreg] IGs are also openly accessible, so any interested party
can go to the HL7[supreg] website and access the IG. Once accessed, all
public comments made during the balloting process as well as the IG
version history are available for review.
A number of the FHIR[supreg] IGs proposed for adoption have been
developed by the Da Vinci project, an initiative established in 2018 to
help payers and providers positively impact clinical, quality, cost,
and care management outcomes.\59\ The Da Vinci project is part of the
HL7[supreg] FHIR[supreg] Accelerator Program.\60\ Under the Da Vinci
project, industry stakeholders have facilitated the definition, design,
and creation of use-case-specific reference implementations of
solutions based upon the HL7[supreg] FHIR[supreg] platform to address
value-based care initiatives. Because the Da Vinci project is aligned
with HL7[supreg], new and revised requirements can become open industry
standards.
---------------------------------------------------------------------------

\59\ See https://www.hl7.org/about/davinci/.
\60\ See https://www.hl7.org/documentcenter/public/pressreleases/HL7_PRESS_20190211.pdf.
---------------------------------------------------------------------------

b. Interoperability Standards Advisory
ONC's Interoperability Standards Advisory (ISA) supports the
identification, assessment, and public awareness of interoperability
standards and implementation specifications that can be used by the
United States health care industry to address specific interoperability
needs (see https://www.healthit.gov/isa). The ISA is updated on an
annual basis based on recommendations received from public comments and
subject matter expert feedback. This public comment process reflects
ongoing dialogue, debate, and consensus among industry stakeholders
when more than one standard or implementation specification could be
used to address a specific interoperability need.
ONC currently identifies the IGs referenced throughout this
proposed rule within the ISA as available standards for a variety of
potential use cases. For instance, the HL7[supreg] FHIR[supreg] Da
Vinci PDex IG proposed for adoption at 45 CFR 170.215(c)(6) is
currently identified under the ``Query for Documents Outside a Specific
Health Information Exchange Domain'' within the ISA.\61\ We encourage
stakeholders to review the ISA to better understand key applications
for the IGs proposed for adoption in this proposed rule.
---------------------------------------------------------------------------

\61\ See https://www.healthit.gov/isa/query-documents-outside-a-specific-health-information-exchange-domain.
---------------------------------------------------------------------------

c. Alignment With Federal Advisory Committee Activities
The HITECH Act established two federal advisory committees, the HIT

[[Page 82634]]

Policy Committee (HITPC) and the HIT Standards Committee (HITSC). Each
was responsible for advising the National Coordinator on different
aspects of health IT policy, standards, implementation specifications,
and certification criteria.
Section 3002 of the PHSA, as amended by section 4003(e) of the
Cures Act, replaced the HITPC and HITSC with one committee, the Health
Information Technology Advisory Committee (HIT Advisory Committee or
HITAC). After that change, section 3002(a) of the PHSA established that
the HITAC would advise and recommend to the National Coordinator on
different aspects of standards, implementation specifications, and
certification criteria, relating to the implementation of a health IT
infrastructure, nationally and locally, that advances the electronic
access, exchange, and use of health information. The Cures Act
specifically directed the HITAC to advise on two areas: (1) A policy
framework to advance an interoperable health information technology
infrastructure (section 3002(b)(1) of the PHSA); and (2) priority
target areas for standards, implementation specifications, and
certification criteria (section 3002(b)(2) and (3) of the PHSA).
For the policy framework, as described in section 3002(b)(1)(A) of
the PHSA, the Cures Act tasks the HITAC with providing recommendations
to the National Coordinator on a policy framework for adoption by the
Secretary consistent with the Federal Health IT Strategic Plan under
section 3001(c)(3) of the PHSA. In February of 2018, the HITAC made
recommendations to the National Coordinator for the initial policy
framework \62\ and has subsequently published a schedule in the Federal
Register, and an annual report on the work of the HITAC and ONC to
implement and evolve that framework.\63\ For the priority target areas
for standards, implementation specifications, and certification
criteria, section 3002(b)(2)(A) of the PHSA identified that in general,
the HITAC would recommend to the National Coordinator, for purposes of
adoption under section 3004 of the PHSA, standards, implementation
specifications, and certification criteria and an order of priority for
the development, harmonization, and recognition of such standards,
specifications, and certification criteria. In October of 2019, the
HITAC finalized recommendations on priority target areas for standards,
implementation specifications, and certification criteria.\64\
---------------------------------------------------------------------------

\62\ HITAC Policy Framework Recommendations, February 21, 2018:
https://www.healthit.gov/sites/default/files/page/2019-07/2018-02-21_HITAC_Policy-Framework_FINAL_508-signed.pdf.
\63\ HITAC Annual Report CY 2019 published March 2, 2020:
https://www.healthit.gov/sites/default/files/page/2020-03/HITAC%20Annual%20Report%20for%20FY19_508.pdf.
\64\ HITAC recommendations on priority target areas, October 16,
2019: https://www.healthit.gov/sites/default/files/page/2019-12/2019-10-16_ISP_TF_Final_Report_signed_508.pdf.
---------------------------------------------------------------------------

As described above and in the ONC 2015 Edition final rule (80 FR
62606), section 3004(b)(3) of the PHSA provides broad authority for the
Secretary to adopt standards, implementation specifications, and
certification criteria that have been recommended by the HITAC and
endorsed by the National Coordinator, as well as other appropriate and
necessary health IT standards, implementation specifications, and
certification criteria. Under this authority, the Secretary may adopt
standards, implementation specifications, and certification criteria as
necessary even if those standards have not been recommended and
endorsed through the process established for the HITAC under section
3002(b)(2) and (3) of the PHSA. While the implementation specifications
we are proposing to adopt have not been specifically recommended and
endorsed through the HITAC process, the HITAC has recommended the
adoption of interoperability standards for specific data flows
addressed by the standards we propose to adopt in this proposed rule.
In other instances, the HITAC has addressed issues related to
interoperability standards for health care operations relevant to these
proposed standards. In addition, our proposal to adopt the identified
implementation specifications for health care operations under section
3004(b)(3) of the PHSA is consistent with the HITAC policy framework
schedule as well as with the priority target areas for standards and
implementation specifications.
In the October 16, 2019 recommendations from the HITAC establishing
the Interoperability Standards Priority Target Areas, the HITAC
recommendations identified a ``need for standards to support the
integration of prior authorization (PA).'' The 2019 HITAC annual report
(published March 2020) describes a hearing held by the HITAC related to
prior authorization and administrative simplification. The report
identifies continuing work in this area including highlighting the HL7
standards development organization efforts to improve automation and
interoperability of administrative and clinical data, and the Da Vinci
Project use case supporting payers sending administrative data to
providers using the HL7 FHIR standard.\65\
---------------------------------------------------------------------------

\65\ HITAC Annual Report CY 2019 published March 2, 2020:
https://www.healthit.gov/sites/default/files/page/2020-03/HITAC%20Annual%20Report%20for%20FY19_508.pdf.
---------------------------------------------------------------------------

In CY 2020, ONC charged the HITAC to establish the Intersection of
Clinical and Administrative Data (ICAD) Task Force to produce
information and considerations related to the merging of clinical and
administrative data. The ICAD Task Force explored a wide range of
considerations including transport and exchange structures, areas for
clinical and operations data alignment, and privacy and security rules
and protections. The ICAD Task Force, which included members of the
HITAC, NCVHS, industry, and the public, received input from a variety
of experts and stakeholders in the field. In November 2020, the ICAD
Task Force presented final recommendations \66\ to the HITAC, which
were then approved by the full Committee. These included a
recommendation to ``Establish Standards for Prior Authorization
Workflows.'' Specifically, the final report recommends that ONC work
with CMS, other federal actors, and standards development organizations
to ``develop programmatic (API) specifications to create an
authorization (digital prior authorization or related determinations
such as Medical Necessity) such that the authorization and related
documentation can be triggered in workflow in the relevant workflow
system where the triggering event for the authorization is created.''
In addition, the final report identifies for consideration the
potential use of HL7[supreg] FHIR[supreg] standards as part of this
recommendation including discussion of: The HL7[supreg] FHIR[supreg] Da
Vinci CRD and DTR IGs, and the HL7[supreg] FHIR[supreg] Da Vinci PAS
IG. These implementation specifications, which ONC proposes to adopt on
behalf of HHS in this proposed rule, are discussed extensively as part
of the final report as examples of FHIR[supreg] specifications that can
support prior authorization. ONC has considered these recommendations
and considerations in our decision to propose to adopt these prior
authorization implementation specifications for health care operations
at 45 CFR 170.215(c)(1) through (3) as

[[Page 82635]]

described below in section II.E.3. of this proposed rule.
---------------------------------------------------------------------------

\66\ Final Recommendations of the ICAD Task Force, November
2020: https://www.healthit.gov/sites/default/files/facas/ICAD_TF_FINAL_Report_HITAC_2020-11-06_0.pdf.
---------------------------------------------------------------------------

In addition to the recommendation regarding standards, the final
report includes several additional recommendations to support the
convergence of clinical and administrative data to improve data
interoperability to support clinical care, reduce burden, and improve
efficiency. We believe our proposal to adopt implementation
specifications for health care operations relating to payer data
exchange and provider directories at 45 CFR 170.215(c)(4) through (8)
will help to advance these aims (see section II.E.3. of this proposed
rule for further detail). These include recommendations relating to
prioritizing administrative efficiency in relevant federal programs,
focusing on convergence of health care standards, and developing
patient-centered workflows and standards. We agree with the findings in
the final report which state that these recommendations will help to
form a solid basis on which to develop the future policies, standards,
and enabling technologies that will truly put the patient at the center
of an efficient health care information ecosystem.
d. Coordination of Federal Activities With Adopted Standards and
Implementation Specifications
Consistent with sections 13111 and 13112 of the HITECH Act, ONC has
worked with CMS, HHS agencies, and other federal partners to ensure
that federal activities involving the implementation, acquisition, and
upgrade of systems that collect and process health information are
consistent with the standards and implementation specifications adopted
under section 3004 of the PHSA. Aligning the use of such standards and
implementation specifications would ensure that the same health IT
standards are utilized by federal government programs and federal
partners in the health care industry and reduce the risk of competing
or inconsistent regulatory requirements increasing stakeholder burden.
In addition, alignment of standards and implementation guidance would
be expected to reduce fragmentation between and among systems
supporting interoperability across the health care continuum for a wide
range of use cases.
This includes specific efforts to align federal activities with the
standards for APIs adopted in the ONC 21st Century Cures Act final rule
as proposed in 2019 and finalized in 2020 (85 FR 25642). The ONC 21st
Century Cures Act final rule implements provisions of the Cures Act,
which prioritize the adoption of APIs across the health care industry.
In the API requirements for payers finalized in the CMS
Interoperability and Patient Access final rule (85 FR 25510), which
serve as the basis for several additional proposals in this proposed
rule, CMS specified alignment of their final policies with technical
standards for APIs adopted in the ONC 21st Century Cures Act final rule
at 45 CFR 170.215, as well as the USCDI version 1 standard vocabulary
standard adopted at 45 CFR 170.213.
In addition to the efforts described in this proposed rule, HHS
agencies are exploring areas for alignment to these adopted standards
to improve health information exchange for a wide range of use cases.
Some examples include:
In fall 2019, NIH published a request for information on
the use of FHIR-based APIs to support research use cases (https://grants.nih.gov/grants/guide/notice-files/NOT-OD-19-150.html).
In partnership with the CDC, ONC has worked with HL7 and
other standards development process participants to develop an IG to
provide developers and IT staff details on how to access prescription
drug monitoring program (PDMP) data from clinical systems. This ongoing
work includes aligning the IG with updates to existing standards and
specifically FHIR Release 4 (https://hl7.org/fhir/us/meds/2018May/pdmp.html).
CMS is leading the PACIO Project for the development of
post-acute care FHIR implementation specifications and reference
implementations that will facilitate health data exchange through
standards-based APIs (https://confluence.hl7.org/display/PC/PACIO+Project).
As these efforts continue, ONC will continue to work with federal
partners and monitor and analyze interoperability standards and
implementation specifications for potential adoption on behalf of the
Secretary and HHS. This ongoing process aims to support coordination
and alignment of federal activities involving the broad collection and
submission of health information, as well as the applicability to
private entities engaged in health information exchange with federal
partners. The overarching goal is to continue to support the
advancement of a nationwide health information technology
infrastructure that reduces burden and health care costs, and, most
importantly, improves patient care.
3. Proposal To Adopt the Standards for Use by HHS
Consistent with section 3004(b)(3) of the PHSA and the efforts
described above to evaluate and identify standards for adoption, on
behalf of the Secretary, we propose to adopt the implementation
specifications for health care operations at 45 CFR 170.215 to support
the continued development of a nationwide health information technology
infrastructure as described under section 3001(b) of the PHSA and to
support federal alignment of standards for interoperability and health
information exchange. Specifically, we propose to adopt the latest
versions of the following standards at 45 CFR 170.215 under a new
paragraph (c), ``Standards and Implementation Specifications for Health
Care Operations.'' We note that each IG is discussed in detail in
relation to the specific API it will support in sections II.A., II.B.,
II.C., and II.D. of this proposed rule, as well as in section IV. of
this proposed rule. The latest version of each standard may be accessed
at the links provided:
HL7 FHIR Da Vinci--Coverage Requirements Discovery (CRD)
Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/davinci-crd/history.html.
HL7 FHIR Da Vinci--Documentation Templates and Rules (DTR)
Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/davinci-dtr/history.html.
HL7 FHIR Da Vinci--Prior Authorization Support (PAS)
Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/davinci-pas/history.html.
HL7 FHIR Da Vinci--Payer Coverage Decision Exchange (PCDE)
Implementation Guide: Version STU 1.0.0. URL: https://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG
for Blue Button[supreg]) Implementation Guide: Version STU 1.0.0. URL:
https://hl7.org/fhir/us/carin-bb/history.html.
HL7 FHIR Da Vinci Payer Data Exchange (PDex)
Implementation Guide: Version STU 1.0.0. URL: https://hl7.org/fhir/us/davinci-pdex/history.html.
HL7 FHIR Da Vinci--Payer Data Exchange (PDex) US Drug
Formulary Implementation Guide: Version STU 1.0.1. URL: https://hl7.org/fhir/us/Davinci-drug-formulary/history.html.
HL7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net
Implementation Guide: Version STU 1.0.0. URL: https://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml.

[[Page 82636]]

The implementation specifications proposed for adoption in this
rule would be important additions to the group of interoperability
specifications adopted by HHS. We believe that by adopting these
standards, as proposed at 45 CFR 170.215(c), we would support future
alignment across health care system stakeholders and the development of
a robust nationwide health IT infrastructure.
Unlike other rulemakings in which ONC has engaged, we are not
proposing new or revised certification criteria based on the proposed
adoption of these standards, nor are we proposing to require testing
and certification to these implementation specifications for any
existing certification criteria in the ONC Health IT Certification
Program. These proposals focus on the adoption of standards and
implementation specifications for health information technology to
support interoperability and health information exchange across a wide
range of potential use cases. We expect that, as new models of care
delivery continue to connect clinical and payment data in innovative
ways to reduce burden and increase efficiency, the implementation
specifications we are proposing to adopt at 45 CFR 170.215(c) will
contribute to advancing the interoperability of data across clinical
and administrative systems. We further believe this approach will
support federal alignment and coordination of federal activities with
adopted standards and implementation specifications for a wide range of
systems, use cases, and data types within the broad scope of health
information exchange. As noted above under section II.E.1.b. of this
proposed rule, historically, state, federal, and local partners have
leveraged the standards adopted by ONC on behalf of HHS (as well as
those identified in the ISA) to inform program requirements, technical
requirements for grants and funding opportunities, and systems
implementation for health information exchange. We believe the adoption
of these standards will support these HHS partners in setting technical
requirements and exploring the use of innovative health IT solutions
for health information exchange for health care operations.
We additionally propose to make minor revisions to the regulation
text at 45 CFR 170.215 to support clarity in the short descriptions of
the standards and implementation specifications previously adopted at
45 CFR 170.215(a) and (b). However, we are not proposing any changes to
the standards and implementation specifications, or versions thereof,
previously adopted in 45 CFR 170.215(a) or (b). For the implementation
specifications proposed for adoption at 45 CFR 170.215(c) Standards and
Implementation Specifications for Health Care Operations, we propose to
incorporate by reference the specified version of each implementation
specification at 45 CFR 170.299.

III. Requests for Information

A. Methods for Enabling Patients and Providers To Control Sharing of
Health Information

The CMS Interoperability and Patient Access final rule (85 FR
25510) and this proposed rule are focused on unleashing data in order
to empower patients to make informed decisions and empowering providers
with the data they need at the moment they are caring for their
patients. Stakeholders have shared that they believe part of empowering
patients and providers is being sure both have a say in what specific
data are shared, when, and with whom. We have started to address this
issue within these two regulations. However, we received several
comments on the CMS Interoperability and Patient Access proposed rule
(84 FR 7610) indicating that patients and providers want more options
for controlled sharing of health information beyond what is currently
in place under current federal and state laws and regulations.
Commenters indicated a preference for a framework that honors an
individual's privacy rights, without constricting permissible uses of
health information to improve the health and wellness of individuals
and populations.
Commenters indicated that some patients want the right to choose
which data elements from their health record are shared with specified
providers, payers, and third parties. Other patients want the ability
to opt out of information exchanges between payers and other
stakeholders, such as health care providers and health information
exchanges. Some patients indicated that they want their preferences
considered in the determination of what data should be shared, and they
desire the ability to deem certain aspects of their health information
as sensitive and not to be shared under pre-defined circumstances.
These patient preferences could provide the opportunity to continue
support for patient autonomy and encourage greater patient
participation, as patients should have an understanding of how their
health information is being shared and used, given this could have an
impact on their care.
We received comments indicating that providers want the right to
choose if all or some of a patient's data should be shared with other
providers and/or the patient themselves, especially if they believe
sharing specific information could lead to negative outcomes. One
example mentioned is where a provider may want to edit or remove a
section of a patient's clinical notes before sharing the record with
the patient and/or another provider if the notes indicate a possible
diagnosis that may be misunderstood by the patient or lead to
stigmatization by another provider who does not possess sufficient
context prior to reading the notes.
In regards to providers having the ability to choose which data are
shared, we noted that the HIPAA Privacy Rule allows for certain limited
circumstances for which a provider may deny a patient access to all or
a portion of a patient's data under 45 CFR 164.524(a)(2) and 45 CFR
164.524(a)(3). While there may also be relevant state laws, those that
applied additional restrictions on individual access would be preempted
by HIPAA, and we note that providing patients with easy access to their
health information empowers them to be more in control of decisions
regarding their health and well-being.
We also note that in ONC's 21st Century Cures Act final rule (85 FR
25642), ONC finalized certain exceptions to the practice of information
blocking, which would allow health care providers, health IT
developers, exchanges, and networks to withhold data from other health
care providers, health IT developers, exchanges, and networks under
certain circumstances. This allows organizations to respect an
individual's request not to share information, where not required or
prohibited by law.
Additionally, we received comments about the maturity of existing
processes that impact access controls of heath IT systems, such as data
segmentation, or processes that enable more granular consent
capabilities. Commenters indicated concerns that the current standards
available are not well adopted or appropriately conformant with the
FHIR version 4 (85 FR 25546).
Taking into consideration applicable federal, state, local, and
tribal law, we are interested in stakeholder feedback on different
methods that enable patients and providers to have more granular
control over the sharing of patient health information. Specifically,
we are seeking stakeholder feedback on the following questions:
Patient Engagement and Provider Discretion. What role
should patients and providers play in data segmentation

[[Page 82637]]

decisions? Should patients assume this responsibility and are there
mechanisms currently in place or available that could support the
documenting of these preferences? Would providing opportunities to
express these preferences negatively impact patients who are unable or
choose not to state their preferences? For instance, would a patient
who did not fully understand how, or, or the pros and cons of, sharing
some data but not other data be at a disadvantage in some way? How can
patients be engaged in these decisions and acquire adequate
understanding of how their data are being shared without burdening
them? Are there specific situations, use cases, or considerations that
should limit how the impacted entity responds to a data segmentation
request to either restrict uses and disclosures of some of the data, or
to obtain access to some of the data from a patient or provider? Are
there unintended consequences of such data segmentation requests or
options? If so, how can they be addressed?
Methods and Readiness. What are examples of effective
tools and methods for patients and providers to control access to
portions of patients' health data? What is the readiness and
feasibility of implementing successful access control methods?
Resource Burden. Commenters raised concerns about the
potential cost and burden of data segmentation at the data element
level. Specifically, would requiring the ability to segment the data
by, for instance, conducting data tagging, place additional burden on
clinical providers? Please describe the nature of any additional
burden. What are possible solutions to consider to address these
concerns?
Current Patient Consent Practices. How do current consent
practices inform patients of opportunities for patient engagement and
provider discretion in responding to patient requests? What technology
and policy gaps exist for achieving widespread successful segmentation
practices?
FHIR Utility. What recommendations do stakeholders have to
improve the data segmentation capabilities of existing FHIR standards?
How would you describe the state of development projects or standards
efforts planned or ongoing to address data segmentation (or
segmentation of sensitive information) on FHIR or other standards? What
are the key gaps or constraints that exist within ongoing and emerging
efforts?
Technical Considerations. What general data segmentation
strategies can we leverage for the programs described in this proposed
rule from standards like the Substance Abuse and Mental Health Services
Administration's (SAMSHA) Consent2Share \67\ and HL7 Data Segmentation
for Privacy (DS4P)? \68\ What lessons can we learn from use of these
existing standards?
---------------------------------------------------------------------------

\67\ HL7 International Community-Based Care and Privacy. (n.d.).
Consent2Share Implementation Guide. Retrieved from https://gforge.hl7.org/gf/project/cbcc/frs/?action=FrsReleaseBrowse&frs_package_id=303.
\68\ Office of the National Coordinator for Health Information
Technology. (2020). Data Segmentation of Sensitive Information.
Retrieved from https://www.healthit.gov/isa/data-segmentation-sensitive-information.
---------------------------------------------------------------------------

How can existing tools, resources, and approaches with
data segmentation be used to help inform any approaches or strategies
that CMS might consider proposing for impacted entities? \69\
---------------------------------------------------------------------------

\69\ For selected resources on practices for privacy and data
segmentation, see p. 61 of the Health IT Advisory Committee Notice
of Proposed Rulemaking Task Force. (2019, June 3). Information
Blocking Task Force Recommendations. Retrieved from https://www.healthit.gov/sites/default/files/page/2019-07/2019-06-03_All%20FINAL%20HITAC%20NPRM%20Recs_508-signed.pdf.
---------------------------------------------------------------------------

Patient Options. Should preferences be something that data
senders should try to honor but retain flexibility to deny in certain
situations, when consistent with applicable regulations? For example,
the HIPAA Privacy Rule requires a covered entity to permit an
individual to request restrictions on the entity's uses and disclosures
of PHI, but only requires the entity to agree to the request in limited
circumstances (see 45 CFR 164.522(a)(1)(vi)).
Current Segmentation Efforts. Varied segmentation
practices exist, and we are seeking stakeholder input from those who
have implemented or piloted patient-controlled segmentation models,
individual provider-controlled models, or other related models or
tools. What prevents patients and/or providers from recording,
maintaining, or using a patient's privacy preferences when exchanging
health information? How can data segmentation decisions be automated?
Are there particular processes or workflows related to patient privacy
preferences, consent, or data segmentation that could be improved by
automation and/or standardization?

B. Electronic Exchange of Behavioral Health Information

Several factors have led to an EHR adoption rate that is
significantly lower among behavioral health providers compared to other
types of health care providers. One possible contributing factor was
that the Health Information Technology for Economic and Clinical Health
Act (Pub. L. 111-5, enacted February 17, 2009) (HITECH Act) made
Medicare fee-for-service and Medicaid incentive payments for the
adoption and meaningful use of certified EHR technology available only
to eligible professionals, eligible hospitals, and critical access
hospitals (CAH). Behavioral health providers that did not meet the
criteria to be considered an eligible professional, eligible hospital,
or CAH were not eligible for these incentive payments. For example,
behavioral health providers who were physicians (eligible
professionals) could receive the incentive payments, but other types of
non-physician behavioral health providers may not have been eligible.
Today, behavioral health providers lag behind their peers in the
ability to electronically share health information across providers and
with patients. ONC noted that, in 2017, only 12 percent of office-based
physicians reported sending data to behavioral health providers, while
14 percent of office-based physicians reported receiving data from
behavioral health providers.\70\ Other technical and regulatory
restrictions, such as 42 CFR part 2, which governs the confidentiality
of substance use disorder patient records maintained by a covered
substance use disorder treatment program can also inhibit the exchange
of behavioral health information.
---------------------------------------------------------------------------

\70\ Office of the National Coordinator. ``Interoperability
among Office-Based Physicians in 2015 and 2017.'' ONC Data Brief No.
47 (May 2019). Retrieved from https://www.healthit.gov/sites/default/files/page/2019-05/2015to2017PhysicianInteroperabilityDataBrief_0.pdf.
---------------------------------------------------------------------------

[[Page 82638]]

Over the past few years, HHS continued to highlight the importance
of coordinated care and removing any unnecessary obstacles. In 2018,
HHS launched the ``Regulatory Sprint to Coordinated Care'' prompting
agencies within the Department to assess a variety of long-standing
regulatory requirements to see whether they hinder innovative progress
and how they can better incentivize coordination. We have also seen the
Substance Abuse and Mental Health Services Administration (SAMHSA)
publish regulations related to improved care coordination among
providers that treat substance use disorders as well as protecting
those patients' records (42 CFR part 2), and the enactment of the
Substance Use-Disorder Prevention that Promotes Opioid Recovery and
Treatment for Patients and Communities Act (SUPPORT for Patients and
Communities Act) (Pub. L. 115-271, October 24, 2018), which encouraged
us to consider ways to facilitate information sharing among behavioral
health providers. In the spirit of the ``Regulatory Sprint to
Coordinated Care'' and these policies, we are looking for innovative
approaches to addressing the need to facilitate the electronic exchange
of behavioral health information, as well as approaches to support the
exchange of health information to behavioral health providers to inform
care and provision of behavioral health services.
Many behavioral health providers are in the community. As a result,
when thinking about behavioral health specifically, it is valuable to
think about community-based providers more broadly.
We are interested in public comments on how we might best support
electronic data exchange of behavioral health information between and
among behavioral health providers, other health care providers, and
patients, as well as how we might best inform and support the movement
of health data (and its consistency) to behavioral health providers for
their use to inform care and treatment of behavioral health services.
Specifically, we are seeking public comments on the following
questions:
Can applications using FHIR-based APIs facilitate
electronic data exchange between behavioral health providers and with
other health care providers, as well as their patients, without greater
EHR adoption? Is EHR adoption needed first? What opportunities do FHIR-
based APIs provide to bridge the gap? What needs might not be addressed
by the use of applications with more limited functionality than
traditional EHRs?
What levers could CMS consider using to facilitate greater
electronic health data exchange from and to behavioral health
providers? What costs, resources, and/or burdens are associated with
these options?
Are there particular considerations for electronic data
exchange for behavioral health providers who practice independently,
are community-based, or are non-traditional providers? What about
rural-based behavioral health providers? How could an API-based
solution help address these considerations?
Are there state or federal regulations or payment rules
that are perceived as creating barriers to technical integration of
systems within these practices? What additional policy issues,
technical considerations, and operational realities should we consider
when looking at ways to best facilitate the secure electronic exchange
of health information that is maintained by behavioral health providers
including sensitive health information?
What levers and approaches could CMS consider using and
advancing to facilitate greater electronic health data exchange from
and to community-based health providers including use of relevant
health IT standards as feasible? What costs, resources, and/or burdens
are associated with these options?
We seek comments on these questions and issues for future
consideration.

B. Electronic Exchange of Behavioral Health Information

Several factors have led to an EHR adoption rate that is
significantly lower among behavioral health providers compared to other
types of health care providers. One possible contributing factor was
that the Health Information Technology for Economic and Clinical Health
Act (Pub. L. 111-5, enacted February 17, 2009) (HITECH Act) made
Medicare fee-for-service and Medicaid incentive payments for the
adoption and meaningful use of certified EHR technology available only
to eligible professionals, eligible hospitals, and critical access
hospitals (CAH). Behavioral health providers that did not meet the
criteria to be considered an eligible professional, eligible hospital,
or CAH were not eligible for these incentive payments. For example,
behavioral health providers who were physicians (eligible
professionals) could receive the incentive payments, but other types of
non-physician behavioral health providers may not have been eligible.
Today, behavioral health providers lag behind their peers in the
ability to electronically share health information across providers and
with patients. ONC noted that, in 2017, only 12 percent of office-based
physicians reported sending data to behavioral health providers, while
14 percent of office-based physicians reported receiving data from
behavioral health providers.\71\ Other technical and regulatory
restrictions, such as 42 CFR part 2, which governs the confidentiality
of substance use disorder patient records maintained by a covered
substance use disorder treatment program can also inhibit the exchange
of behavioral health information.
---------------------------------------------------------------------------

\71\ Office of the National Coordinator. ``Interoperability
among Office-Based Physicians in 2015 and 2017.'' ONC Data Brief No.
47 (May 2019). Retrieved from https://www.healthit.gov/sites/default/files/page/2019-05/2015to2017Physician
InteroperabilityDataBrief_0.pdf.
---------------------------------------------------------------------------

Understanding the time and cost of implementing an EHR system, we
are interested in evaluating whether using other applications that
exchange data using FHIR-based APIs and do not require implementation
of a full EHR system might be a way to help behavioral health providers
leverage technology to exchange health data to improve care quality and
coordination in a more agile fashion. Specifically, would small
practices, community-based providers, and other non-traditional
providers be able to more quickly adopt applications using API
technology to exchange health information when the technology is not
tied to an EHR? Would these providers be able to achieve the same care
coordination goals using such applications as with a more extensive EHR
implementation, or would the value be lower but still sufficient to
improve care quality and care coordination?
Over the past few years, HHS continued to highlight the importance
of coordinated care and removing any unnecessary obstacles. In 2018,
HHS launched the ``Regulatory Sprint to Coordinated Care'' prompting
agencies within the Department to assess a variety of long-standing
regulatory requirements to see whether they hinder innovative progress
and how they can better incentivize coordination. We have also seen the
Substance Abuse and Mental Health Services Administration (SAMHSA)
publish regulations related to improved care coordination among
providers that treat substance use disorders as well as protecting
those patients' records (42 CFR part 2), and the enactment of the
Substance Use-Disorder Prevention that Promotes Opioid Recovery and
Treatment for Patients and Communities Act (SUPPORT for Patients and

[[Page 82639]]

Communities Act) (Pub. L. 115-271, October 24, 2018), which encouraged
us to consider ways to facilitate information sharing among behavioral
health providers. In the spirit of the ``Regulatory Sprint to
Coordinated Care'' and these policies, we are looking for innovative
approaches to addressing the need to facilitate the electronic exchange
of behavioral health information, as well as approaches to support the
exchange of health information to behavioral health providers to inform
care and provision of behavioral health services.
Many behavioral health providers are in the community. As a result,
when thinking about behavioral health specifically, it is valuable to
think about community-based providers more broadly.
We are interested in public comments on how we might best support
electronic data exchange of behavioral health information between and
among behavioral health providers, other health care providers, and
patients, as well as how we might best inform and support the movement
of health data (and its consistency) to behavioral health providers for
their use to inform care and treatment of behavioral health services.
Specifically, we are seeking public comments on the following
questions:
Can applications using FHIR-based APIs facilitate
electronic data exchange between behavioral health providers and with
other health care providers, as well as their patients, without greater
EHR adoption? Is EHR adoption needed first? What opportunities do FHIR-
based APIs provide to bridge the gap? What needs might not be addressed
by the use of applications with more limited functionality than
traditional EHRs?
What levers could CMS consider using to facilitate greater
electronic health data exchange from and to behavioral health
providers? What costs, resources, and/or burdens are associated with
these options?
Are there particular considerations for electronic data
exchange for behavioral health providers who practice independently,
are community-based, or are non-traditional providers? What about
rural-based behavioral health providers? How could an API-based
solution help address these considerations?
Are there state or federal regulations or payment rules
that are perceived as creating barriers to technical integration of
systems within these practices? What additional policy issues,
technical considerations, and operational realities should we consider
when looking at ways to best facilitate the secure electronic exchange
of health information that is maintained by behavioral health providers
including sensitive health information?
What levers and approaches could CMS consider using and
advancing to facilitate greater electronic health data exchange from
and to community-based health providers including use of relevant
health IT standards as feasible? What costs, resources, and/or burdens
are associated with these options?
We seek comments on these questions and issues for future
consideration.

D. Reducing Burden and Improving Electronic Information Exchange of
Prior Authorizations

As discussed in section II.C. of this proposed rule, we believe
there are many benefits to using electronic prior authorization
solutions. Specifically, we propose to require impacted payers to
implement, maintain, and use a Prior Authorization Support API.
However, as we discuss in section VII. of this proposed rule, the
health care system would gain maximum benefits if providers adopted use
of the Prior Authorization Support API as well. As a result, we are
requesting information for consideration in future rulemaking regarding
how CMS can best incentivize providers to use electronic prior
authorization solutions.
1. Electronic Prior Authorization for Medicare- and Medicaid-
Participating Providers and Suppliers
We have been working with the provider community to ensure that the
Conditions of Participation, Conditions for Certification, and
Conditions for Coverage (CoPs and CfCs) reflect the latest advances in
health information technology and interoperability to the greatest
extent possible. For instance, the CMS Interoperability and Patient
Access final rule (85 FR 25510, finalized on May 1, 2020) revised the
CoPs for hospitals, psychiatric hospitals, and critical access
hospitals (CAHs) by adding new standards that require a hospital,
including a psychiatric hospital, or a CAH, which utilizes an
electronic medical records system or other electronic administrative
system that meets certain technical specifications, to demonstrate that
it sends electronic patient event notifications to the patient's
primary care practitioner, practice group, or other practitioner or
practice group identified by the patient as being responsible for his
or her primary care, when a patient is admitted to, and discharged
(and/or transferred) from, the hospital or the CAH.
The notifications must include, at a minimum, the patient's name,
the name of the treating practitioner, and the name of the sending
institution. These provisions were finalized at Sec. 482.24(d),
``Electronic notifications,'' for hospitals; at Sec. 482.61(f),
``Electronic notifications,'' for psychiatric hospitals; and at Sec.
485.638(d), ``Electronic notifications,'' for CAHs. The CMS
Interoperability and Patient Access final rule (85 FR 25510) requires
hospitals, including psychiatric hospitals, and CAHs to implement the
patient event notification provisions by April 30, 2021. As we
explained in that final rule, there is growing evidence that health
information exchange can lower cost and improve outcomes, particularly
when the exchange of information, such as a patient event notification,
is between providers. These exchanges are associated with better care
coordination, a reduction in 30-day readmissions, and improved
medication reconciliation, for instance (85 FR 25585).
In reviewing other areas where the electronic exchange of patient
information through interoperable systems offers significant
opportunities for improvements for direct patient care, and also to
overall health care system efficiency, we have identified electronic
prior authorization as an area that might benefit from these
technological advances. As we have discussed elsewhere in this proposed
rule, we believe that the electronic prior authorization process is an
opportunity to reduce burden and improve care. Prior authorization is
the request and approval for payment of items and services (including
prescription drugs) provided by Medicare- and Medicaid-participating
providers and suppliers (including, but not limited to, hospitals,
psychiatric hospitals, and CAHs) to beneficiaries. We recognize that
there are gaps in the current prior authorization process, including:
Prior authorization requirements not residing within a
provider's EHR or not being visible to the provider or staff members as
part of the workflow;
Inability to rely on a consistent submission method for
prior authorization requests. In many cases, only some of the process
is automated, or electronic, making for a hybrid process that is
partially computer-based through an EHR or practice management system,
and partially manual, requiring phone calls, faxes, or emails,
resulting in various workarounds that may or may not meld together;
Paper forms and portals require manual data reentry that
may already reside electronically within an EHR; and
There are multiple routes to obtain a prior authorization
depending on the

[[Page 82640]]

payer, item or service, and provider (such as a hospital).
We are interested in learning what barriers exist for hospitals
(and other providers and suppliers) to electronically transmit prior
authorization requests and receive prior authorization decisions for
patients receiving care and services by the applicable provider. We
believe answers to the following questions would be beneficial in
obtaining additional information on the overall electronic prior
authorization process, the impact of this process on patient health and
safety issues, and whether the hospital (and other providers and
suppliers)CoP requirements are a good vehicle to achieve nearly
universal adoption and use of electronic prior authorization requests
and receipts:
What are the current barriers to transmitting prior
authorization requests and receipts electronically? What actions could
CMS and/or industry take to remove barriers?
Do the current methods for electronic transmission of
prior authorization requests and receipts, including the adopted
standard, and any that have been established and maintained by third-
party health care insurers (including Medicare) provide the efficient
and timely request and receipt of prior authorization decisions? Please
provide relevant detail in your response.
Would the CMS CoP/CfC requirements for hospitals and other
providers and suppliers be the appropriate lever by which CMS should
propose new or additional provisions that would require the electronic
request and receipt of prior authorization decisions? If so, under
which provisions would this best be accomplished?
We intend to utilize this information as we evaluate opportunities
to revise the hospital and CAH CoP requirements related to electronic
prior authorization request and receipt.
2. Request for Information: Future Electronic Prior Authorization Use
in the Merit-Based Incentive Payment System (MIPS)
As discussed in section II.C. of this proposed rule, we believe the
tools to support more efficient electronic prior authorization
processes have the potential to greatly reduce the amount of time
needed for submitting, reviewing, and making prior authorization
decisions. We are considering ways to encourage clinicians to use
electronic prior authorization solutions and are seeking input on the
addition of an improvement activity for the Merit-Based Incentive
Payment System (MIPS). The Medicare Access and CHIP Reauthorization Act
of 2015 (Pub. L. 114-10) established MIPS for certain Medicare-
participating eligible clinicians, a system that will make payment
adjustments based upon scores from four performance categories. We
first established policies for MIPS in the CY 2017 Quality Payment
Program final rule (81 FR 77008 through 77831) and annually thereafter.
Section 1848(q)(2)(C)(v)(III) of the Act defines an improvement
activity as an activity that relevant eligible clinician organizations
and other relevant stakeholders identify as improving clinical practice
or care delivery, and that the Secretary determines, when effectively
executed, is likely to result in improved outcomes. For previous
discussions on the background of the improvement activities performance
category, we refer readers to the CY 2017 Quality Payment Program final
rule (81 FR 77177 through 77178), the CY 2018 Quality Payment Program
final rule (82 FR 53648 through 53661), the CY 2019 Physician Fee
Schedule (PFS) final rule (83 FR 59776 through 59777), and the CY 2020
PFS final rule (84 FR 62980 through 62990). We also refer readers to 42
CFR 414.1305 for the definition of improvement activities and
attestation, Sec. 414.1320 for the performance period, Sec. 414.1325
for data submission requirements, Sec. 414.1355 for the improvement
activity performance category generally, Sec. 414.1360 for data
submission criteria, and Sec. 414.1380(b)(3) for improvement
activities performance category scoring.
In section II.C of this proposed rule, we note that prior
authorization is the process through which a provider must obtain
approval from a payer before providing care, and prior to receiving
payment for delivering items or services. In that section, we propose
that state Medicaid and CHIP FFS programs, Medicaid managed care plans,
CHIP managed care entities, and QHP issuers on the FFEs implement and
maintain a Prior Authorization Support (PAS) Application Programing
Interface (API) conformant with the HL7 Fast Healthcare
Interoperability Resources (FHIR) (PAS) IG beginning January 1, 2023
(for Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2023). We believe the
PAS API would provide an opportunity to leverage the convenience and
efficiency of API technology, while maintaining compliance with the
mandated HIPAA transaction standard, to accelerate electronic prior
authorization adoption and use by enabling the prior authorization
process to be integrated into a provider's EHR or practice management
system. Providers could leverage the PAS API to improve care
coordination and patient and clinician shared decision making through
improvements to the prior authorization process, particularly if the
API is integrated into the provider workflow.
We believe that MIPS eligible clinicians would also benefit from
the PAS API, and we are seeking comment on whether we should add a MIPS
improvement activity to our Inventory that would utilize this PAS API
to facilitate submitting and receiving electronic prior authorization
requests and decisions to reduce burden, improve efficiency, and
ultimately ensure patients receive the items and services they need in
a timely fashion. We believe this could fall under the care
coordination subcategory (81 FR 77188) and section 1848(q)(2)(B)(iii)
of the Act. We refer readers to Table H in the Appendix of the CY 2017
Quality Payment Program final rule (81 FR 77177 through 77199), Tables
F and G in the Appendix of the CY 2018 Quality Payment Program final
rule (82 FR 54175 through 54229), Tables X and G in the Appendix 2 of
the CY 2019 PFS final rule (83 FR 60286 through 60303), and Tables A,
B, and C in the Appendix 2 of the CY 2020 PFS final rule (84 FR 63514
through 63538) for our previously finalized improvement activities
Inventory. We also refer readers to the Quality Payment Program website
at https://qpp.cms.gov/ for a complete list of the most current
improvement activities.
We are interested in comments regarding the addition of a MIPS
improvement activity, and if this area will be appropriate to encourage
clinicians to make certain improvements.
Is this an activity that stakeholders identify as
improving clinical practice or care delivery?
When effectively executed, is implementation of such
technology and use of these standards likely to result in improved
outcomes?
If yes, should this activity be assigned a medium-weight
or high-weight?
We refer readers to section III.I.3.h.(4)(d)(i)(C) of CY 2019 PFS
final rule (83 FR 59776 through 59777) where we discussed that high-
weighting should be used for activities that directly address areas
with the greatest impact on beneficiary care, safety, health, and well-
being and/or is of high intensity, requiring significant investment of
time and resources. If the

[[Page 82641]]

addition of a MIPS improvement activity incorporating the use of a
FHIR-based Prior Authorization Support API is not an incentive to
encourage clinicians to use electronic prior authorization solutions,
are there other ways that we could do so?
In addition to the above questions, we are also seeking comment on
the following questions regarding how best to encourage the use of
electronic prior authorization:
Should CMS consider adding a measure to the Medicare
Promoting Interoperability Program for eligible hospitals and critical
access hospitals and the MIPS Promoting Interoperability performance
category for clinicians and groups to encourage the use of electronic
prior authorization through a payer's Prior Authorization Support API?
What are the primary considerations for developing such a
measure?
How would the measure require the use of certified
electronic health record technology?
Should the Prior Authorization Support IG be incorporated
into potential future certification requirements for health IT under
the ONC Health IT Certification Program?
Should CMS consider additional measures and activities
under MIPS Quality, Cost, or Improvement Activities performance
categories involving FHIR-based electronic prior authorization
solutions?
If so, what are the primary considerations for developing
such measures and activities?
What other approaches should CMS consider to help support
clinician use of electronic prior authorization solutions such as the
Prior Authorization Support API?

E. Reducing the Use of Fax Machines

CMS is continually looking for ways to facilitate efficient,
effective, and secure electronic data exchange to help ensure more
timely, better quality, and highly coordinated care. Historically, we
have relied on fax technology as a primary method for sharing
information across the health care system, which can allow for easy
sending and receiving of documents. However, the data in those
documents are not easily integrated electronically into a patient's
medical record or shared in an interoperable way with other payers and
providers. Therefore, using fax technology limits our ability to reach
true interoperability.
Fax technology creates inefficiencies. It requires time spent
manually pulling together clinical and administrative data from EHRs
and practice management systems, transmitting data back and forth
between health care providers and payers using a mechanism slower than
the internet, and making frequent follow-up phone calls between health
care providers and other providers and payers to clarify unclear
transaction statuses in real-time. We discuss examples of these
inefficiencies further in sections II.C. and V.C. of this proposed
rule, to which we refer readers.
To work toward true interoperability, we believe we must reduce or
completely eliminate the use of fax technology in health care. To this
end, we seek comment on how CMS can reduce or completely eliminate the
use of fax technology across programs, including both hospitals and
post-acute care facilities, so that information can be shared
electronically in real time without extensive follow-up to determine if
the information was received. At CMS, we are working to identify all
programs and processes that currently require and/or encourage the use
of fax technology for data exchange to determine whether the use of fax
can be removed or significantly reduced in those programs. We
acknowledge that there are instances where the use of fax may be
necessary to send data, for example, where rural providers do not have
sufficient internet access to exchange certain data electronically and
must rely on fax technology, and also the impact of reduced fax use on
preparedness and response to disasters. We note section 202(c) of the
E-Government Act of 2002 (Pub. L. 107-347, December 17, 2002), requires
CMS to avoid diminished access for those lacking internet access or
computer access. We seek a balance and want to ensure that elimination
of fax technology in CMS programs does not eliminate options for those
without internet access.
In an effort to reduce burden and increase efficiency, we are
requesting feedback from the public on how electronic data exchange
could replace fax technology. Specifically, we are seeking stakeholder
feedback on the following questions:
What specific programs, processes, workflows, or cases are
you currently using a fax machine to accomplish? In what ways would
replacing this with an electronic data exchange, such as via a FHIR-
based API, add value, efficiencies, and/or improve patient care? Are
there specific processes (such as prior authorization) that you would
prioritize first to reduce the reliance on fax technology? Has your
organization implemented an electronic data exchange in an effort to
reduce the reliance on the fax machine?
What challenges might payers and providers face if use of
the fax technology for health care data exchange is completely
eliminated? Are there particular types of providers or health care
settings that would be more negatively impacted than others? What
solutions might mitigate these challenges?
What recommendations are there for balancing the goal of
improving efficiencies in health care data exchange through reducing
the use of fax while ensuring that health care providers without ready
access to internet can still share information?
To what extent can electronic and cloud-based fax
technology bridge the gap between electronic transmission and
traditional fax technology?
What impact will the reduction of use of fax technology
have on preparedness and response to disasters? How might organizations
begin to reduce reliance on this technology, and mitigate these
impacts?

F. Request for Information: Accelerating the Adoption of Standards
Related to Social Risk Data

CMS recognizes that social risk factors (for example, housing
instability, food insecurity) impact beneficiary health and utilization
outcomes. Providers in value-based payment arrangements rely on
comprehensive, high-quality data to identify opportunities to improve
patient care and drive value. When implemented effectively, value-based
payment encourages clinicians to care for the whole person and address
the social risk factors that are critical for beneficiaries' quality of
life.
As value-based payment has grown, so has provider interest in data
on social risk factors. For example, a recent study \72\ found that 24
percent of hospitals and 16 percent of physician practices were
screening patients for all five health-related social needs (housing,
food, transportation, utilities, and safety needs) included in the
Accountable Health Communities model. Providers use these data to
inform care and connect patients with the right community resources and
supports.
---------------------------------------------------------------------------

\72\ See https://www.ncbi.nlm.nih.gov/pubmed/31532515.
---------------------------------------------------------------------------

Unfortunately, social risk data are often fragmented and
duplicative due to a lack of clear standards for recording and
exchanging these data. For example, multiple providers who cannot
exchange these data with each other may ask the same beneficiary
similar

[[Page 82642]]

questions, or hospitals within a single system may all collect varying
food insecurity data in different formats. Additionally, relevant data
collected by community-based organizations outside the health sector
can be difficult to integrate and utilize. Siloed data increase the
burden on beneficiaries, create inefficiencies in managing referrals
for social services, create duplicative workflows in an already
strained system, and impede opportunities to provide higher quality
care.
As providers assume greater accountability for costs and outcomes
through value-based payment, they need tools to successfully identify
and address social risk factors to improve care and health outcomes.
Over the last several years, a variety of community led efforts are
developing industry-wide standards \73\ to collect social risk data,
electronically represent these data, and enable exchange of person-
centered data between medical providers and community-based
organizations through health information technology platforms. CMS
seeks input on barriers the health care industry faces to using
industry standards and opportunities to accelerate adoption of
standards related to social risk data. Specifically:
---------------------------------------------------------------------------

\73\ See https://www.healthit.gov/buzz-blog/interoperability/advancing-interoperable-social-determinants-of-health-data.
---------------------------------------------------------------------------

What are the challenges in representing and exchanging
social risk and social needs data from different commonly used
screening tools? How do these challenges vary across screening tools or
social needs (for example, housing, food)?
What are the barriers to the exchange of social risk and
social needs data across providers? What are key challenges related to
exchange of social risk and social needs data between providers and
community-based organizations?
What mechanisms are currently used to exchange social risk
and social needs data (EHRs, HIEs, software, cloud-based data
platforms, etc.)? What challenges, if any, occur in translating social
risk data collected in these platforms to Z-codes on claims?
How can health care payers promote exchange of social risk
and social needs data? Are there promising practices used by public or
private payers that can potentially be further leveraged in other
settings?

IV. Incorporation by Reference

A. Standards, Implementation Guides, and Specifications

1. National Technology Transfer and Advancement Act
The National Technology Transfer and Advancement Act (NTTAA) of
1995 (15 U.S.C. 3701 et seq.) and the Office of Management and Budget
(OMB) Circular A-119 \74\ require the use of, wherever practical,
technical standards that are developed or adopted by voluntary
consensus standards bodies to carry out policy objectives or
activities, with certain exceptions. The NTTAA and OMB Circular A-119
provide exceptions to electing only standards developed or adopted by
voluntary consensus standards bodies, namely when doing so would be
inconsistent with applicable law or otherwise impractical. In these
cases, agencies have the discretion to decline the use of existing
voluntary consensus standards, and instead can use a government-unique
standard or other standard. In addition to the consideration of
voluntary consensus standards, the OMB Circular A-119 recognizes the
contributions of standardization activities that take place outside of
the voluntary consensus standards process. Therefore, as stated in OMB
Circular A-119, in instances where use of voluntary consensus standards
would be inconsistent with applicable law or otherwise impracticable,
other standards should be considered that meet the agency's regulatory,
procurement, or program needs; deliver favorable technical and economic
outcomes; and, are widely utilized in the marketplace. In this proposed
rule, we propose use of voluntary consensus standards, including
implementation guides (IGs) and specifications.
---------------------------------------------------------------------------

\74\ https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A119/revised_circular_a-119_as_of_1_22.pdf.
---------------------------------------------------------------------------

2. Compliance With Adopted Standards, Implementation Guides, and
Specifications
In accordance with the Office of the Federal Register (OFR)
regulations related to ``incorporation by reference,'' 1 CFR part 51,
which we follow when we adopt proposed standards, implementation
guides, or specifications in any subsequent final rule, the entire
standard, implementation guide, or specification document is deemed
published in the Federal Register when incorporated by reference
therein with the approval of the Director of the Federal Register. Once
published, compliance with the standard, implementation guide, or
specification includes the entire document unless specified otherwise
in regulation. For example, if the Health Level 7[supreg] (HL7) Fast
Healthcare Interoperability Resources[supreg] (FHIR) Da Vinci--Coverage
Requirements Discovery (CRD) Implementation Guide: Version STU 1.0.0
proposed in this rule is adopted (see section II.E. of this proposed
rule), and API requirements for payers based on this IG are finalized
(see section II.D. of this proposed rule, payers developing and
implementing a Documentation Requirements Lookup Service (DRLS)
application programming interface (API) would need to demonstrate
compliance with all mandatory elements and requirements of the IG. If
an element of the IG is optional or permissive in any way, it would
remain that way for compliance unless we specified otherwise in
regulation. In such cases, the regulatory text would preempt the
permissiveness of the implementation guide. This also applies to
standards and specifications.
3. ``Reasonably Available'' to Interested Parties
The OFR has established requirements for materials (for example,
standards, implementation guides, and specifications) that agencies
propose to incorporate by reference in Federal Regulations (79 FR
66267; 1 CFR 51.5(a)). To comply with these requirements, in this
section we provide summaries of, and uniform resource locators (URLs)
to the standards, implementation guides, and specifications we propose
to adopt and subsequently incorporate by reference in the Code of
Federal Regulations (CFR). To note, we also provide relevant
information about these standards, implementation guides, and
specifications throughout the relevant sections of the proposed rule.

B. Incorporation by Reference

OFR has established requirements for materials (for example,
standards, IGs, or specifications) that agencies propose to incorporate
by reference in the CFR (79 FR 66267; 1 CFR 51.5(a)). Section 51.5(a)
requires agencies to discuss, in the preamble of a proposed rule, the
ways that the materials it proposes to incorporate by reference are
reasonably available to interested parties or how it worked to make
those materials reasonably available to interested parties, and
summarize in the preamble of the proposed rule, the material it
proposes to incorporate by reference.
To make the materials we intend to incorporate by reference
reasonably

[[Page 82643]]

available, we provide a URL for the IGs and specifications. In all
cases, these IGs and specifications are accessible through the URLs
provided by selecting the specific version number from the version
history page the URL directly links to. In all instances, access to the
IGs or specification can be gained at no-cost (monetary). There is also
no requirement for participation, subscription, or membership with the
applicable standards developing organization (SDO) or custodial
organization to obtain these materials.
As noted above, the NTTAA and OMB Circular A-119 require the use
of, wherever practical, technical standards that are developed or
adopted by voluntary consensus standards bodies to carry out policy
objectives or activities, with certain exceptions. As discussed, HHS
has followed the NTTAA and OMB Circular A-119 in proposing standards,
IGs, and specifications for adoption. HHS has worked with HL7 to make
the IGs and specifications being proposed for adoption and subsequently
incorporated by reference in the Federal Register, available to
interested stakeholders. As discussed in section II.B. of this proposed
rule, all HL7 FHIR IGs are developed through an industry-led,
consensus-based public process. HL7 is an American National Standards
Institute (ANSI) accredited standards development organization. HL7
FHIR standards are unique in their ability to allow disparate systems
that otherwise represent data differently to exchange such data in a
standardized way that all systems can share and consume via standards-
based APIs. HL7 FHIR IGs are also openly accessible, so any interested
party can go to the HL7 website and access the IG. Once accessed, all
public comments made during the balloting process as well as the
version history of the IGs are available for review. In this way all
stakeholders can fully understand the lifecycle of a given IG. Use of
such guidance facilitates interoperability in a transparent and cost-
effective way that ensures the IGs are informed by, and approved by,
industry leaders looking to use technology to improve patient care. As
such, all of the standards we propose for HHS adoption and subsequent
incorporation by reference are developed and/or adopted by voluntary
consensus standards bodies.
As required by Sec. 51.5(a), we provide summaries of the standards
we propose to adopt and subsequently incorporate by reference in the
Code of Federal Regulations. We also provide relevant information about
these standards, implementation guides, and specifications throughout
the relevant sections of the proposed rule.
Standards Including Implementation Guides and Specifications for Health
Care Interoperability--45 CFR Part 170
HL7 FHIR Da Vinci--Coverage Requirements Discovery (CRD)
Implementation Guide: Version STU 1.0.0.
URL: https://hl7.org/fhir/us/davinci-crd/history.html.
This is a link to the version history. Select the specified version
from the list on this page to access the IG and all related
documentation.
Summary: The purpose of this IG is to define a workflow whereby
payers can share coverage requirements with clinical systems at the
time treatment decisions are being made. This ensures that clinicians
and administrative staff have the capability to make informed decisions
and can meet the requirements of the patient's insurance coverage. We
are specifically proposing this IG to support the DRLS API discussed by
CMS in section II.C. of this proposed rule. The various CMS-regulated
insurance and coverage products accepted by a given provider may have
very different requirements for prior authorization documentation.
Providers who fail to adhere to payer requirements may find that costs
for a given service are not covered or not completely covered. The
outcome of this failure to conform to payer requirements can be
increased out of pocket costs for patients, additional visits and
changes in the preferred care plan, and increased burden.
The information that may be shared using this IG includes:

--Updated coverage information.
--Alternative preferred/first-line/lower-cost services/products.
--Documents and rules related to coverage.
--Forms and templates.
--Indications of whether prior authorization is required.

HL7 FHIR Da Vinci--Documentation Templates and Rules (DTR)
Implementation Guide: Version STU 1.0.0.
URL: https://hl7.org/fhir/us/davinci-dtr/history.html.
This is a link to the version history. Select the specified version
from the list on this page to access the IG and all related
documentation.
Summary: This IG specifies how payer rules can be executed in a
provider context to ensure that documentation requirements are met. The
DTR IG is a companion to the CRD IG, which uses Clinical Decision
Support (CDS) Hooks \75\ to query payers to determine if there are
documentation requirements for a proposed medication, procedure, or
other service. When those requirements exist, CDS Hooks Cards will be
returned with information about the requirements. This IG leverages the
ability of CDS Hooks to link to a Substitutable Medical Applications,
Reusable Technologies (SMART) on FHIR \76\ app to launch and execute
payer rules. The IG describes the interactions between the SMART on
FHIR app and the payer's IT system to retrieve the payer's
documentation requirements, in the form of Clinical Quality Language
(CQL) \77\ and a FHIR Questionnaire resource, for use by the provider.
---------------------------------------------------------------------------

\75\ https://cds-hooks.org/.
\76\ https://docs.smarthealthit.org/.
\77\ https://cql.hl7.org/.
---------------------------------------------------------------------------

The goal of DTR is to collect clinical documentation and/or to
encourage the completion of documentation that demonstrates medical
necessity for a proposed medication, procedure, or other service. To
accomplish this, the IG details the use of a payer provided
Questionnaire resource and results from CQL execution to generate a
Questionnaire Response resource containing the necessary information.
Essentially, the provider's EHR communicates to the payer's system,
which informs the EHR of the documentation that needs to be completed--
this is the Questionnaire resource. To populate the Questionnaire
response, this IG supports the provider's EHR in populating the
response form with the relevant patient information from the patient's
electronic record. As much as can be auto-populated by the system is
completed. The IG then instructs the system to alert a provider to any
gaps in information that may need to be manually filled before the
Questionnaire response resource is sent back to the payer through the
EHR via the SMART on FHIR app. This IG will also support the DRLS API
discussed by CMS in section II.C. of this proposed rule.
HL7 FHIR Da Vinci--Prior Authorization Support (PAS)
Implementation Guide: Version STU 1.0.0.
URL: https://hl7.org/fhir/us/davinci-pas/history.html.
This is a link to the version history. Select the specified version
from the list on this page to access the IG and all related
documentation.
Summary: The PAS IG uses the FHIR standard as the basis for
assembling the information necessary to substantiate the need for a
particular treatment and submitting that information and the

[[Page 82644]]

request for prior authorization to an intermediary end point. That
endpoint is responsible for ensuring that any HIPAA requirements are
met. The response from the payer is intended to come back to that
intermediary endpoint and be available to the provider's EHR solution
using the FHIR standard. The goal is to provide real time prior
authorization, where possible, in the provider's clinical workflow.
This IG, in this way, strives to enable direct submission of prior
authorization requests initiating from a provider's EHR system or
practice management system. To meet regulatory requirements, these FHIR
interfaces will communicate with an intermediary that converts the FHIR
requests to the corresponding X12 instances prior to passing the
requests to the payer. Responses are handled by a reverse mechanism
(payer to intermediary as X12, then converted to FHIR and passed to the
provider's EHR). Direct submission of prior authorization requests from
the provider's EHR will reduce costs for both providers and payers and
result in faster prior authorization decisions resulting in improved
patient care and experience.
When combined with the Da Vinci CRD and DTR IGs, direct submission
of prior authorization requests will further increase efficiency by
ensuring that authorizations are always sent when (and only when)
necessary, and that such requests will almost always contain all
relevant information needed to make the authorization decision on
initial submission.
This IG also defines capabilities around the management of prior
authorization requests, including checking the status of a previously
submitted request, revising a previously submitted request, and
cancelling a request. This IG will support the Prior Authorization
Support API discussed by CMS in section II.C. of this proposed rule.
HL7 FHIR Da Vinci--Payer Coverage Decision Exchange (PCDE)
Implementation Guide: Version STU 1.0.0.
URL: https://www.hl7.org/fhir/us/davinci-pcde/history.cfml.
This is a link to the version history. Select the specified version
from the list on this page to access the IG and all related
documentation.
Summary: The IG defines standardized mechanisms for a patient or
payer to enable a transfer of ``current active treatments'' with other
relevant metadata and coverage-related information from a prior payer
to a new payer. It also defines a standardized structure for organizing
and encoding that information to ease its consumption by the new payer
organization.
This IG addresses the need for continuity of treatment when
patients move from one payer's health insurance or benefit plan to
another. In the current situation, the patient and new payers often do
not have the information needed to continue treatment in progress or to
determine that the therapies are necessary or medically appropriate. As
a result, patients can face a break in continuity of care, challenges
to share additional information, and increased costs as tests are re-
run or prior therapies need to be re-tested in order to comply with the
rules of the new payer. By enabling an authorized transfer of
information from the original payer to the new payer, the new payer can
have access to information about what therapies are currently in place
and the rationale for them, as well as what precursor steps have been
taken to demonstrate the medical necessity and appropriateness of the
current therapy. By automating this exchange and maximizing the
computability of the information shared, a process that frequently
takes weeks or months can be reduced to a few days or even minutes
reducing costs and improving patient safety, quality, and experience.
This IG will support the Payer-to-Payer API discussed by CMS in section
II.D. of this proposed rule.
HL7 FHIR Consumer Directed Payer Data Exchange (CARIN IG
for Blue Button[supreg]) Implementation Guide: Version STU 1.0.0.
URL: https://hl7.org/fhir/us/carin-bb/history.html.
This is a link to the version history. Select the specified version
from the list on this page to access the IG and all related
documentation.
Summary: This IG describes the CARIN for Blue Button Framework,
providing a set of resources that payers can exchange with third-
parties to display to consumers via a FHIR-based API. This IG will help
impacted payers share adjudicated claims and encounter data via the
Patient Access API discussed by CMS in section II.A. of this proposed
rule. It includes data elements and coding instructions each impacted
payer can use to prepare and share the specified data.
HL7 FHIR Da Vinci Payer Data Exchange (PDex)
Implementation Guide: Version STU 1.0.0.
URL: https://hl7.org/fhir/us/davinci-pdex/history.html.
This is a link to the version history. Select the specified version
from the list on this page to access the IG and all related
documentation.
Summary: This IG enables payers to create a member's health history
from clinical Resources based on FHIR Release 4 that can be exchanged
with other payers, providers, and thirty-party applications. It
supports patient-authorized exchange to a third-party application, such
as the patient-requested prior authorization information via the
Patient Access API as discussed in section II.A. of this proposed rule.
It will also support exchanging active prior authorization decisions
between payers and providers via the Provider Access API discussed by
CMS in section II.B. of this proposed rule.
HL7 FHIR Da Vinci--Payer Data Exchange (PDex) US Drug
Formulary Implementation Guide: Version STU 1.0.1.
URL: https://hl7.org/fhir/us/Davinci-drug-formulary/history.html.
This is a link to the version history. Select the specified version
from the list on this page to access the IG and all related
documentation.
Summary: This IG defines a FHIR interface to a health insurer's
current drug formulary information for patient access. A drug formulary
is a list of brand-name and generic prescription drugs a payer agrees
to pay for, at least partially, as part of health insurance or benefit
coverage. Drug formularies are developed based on the efficacy, safety,
and cost of drugs. The primary use cases for this FHIR interface is to
enable patients' ability to understand the costs and alternatives for
drugs that have been or can be prescribed, and to enable the comparison
of their drug costs across different insurance plans. This IG would
support the inclusion of current formulary and preferred drug list
information via the Patient Access API as discussed by CMS in section
II.A. of this proposed rule.
HL7 FHIR Da Vinci Payer Data Exchange (PDex) Plan Net
Implementation Guide: Version STU 1.0.0.
URL: https://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml.
This is a link to the version history. Select the specified version
from the list on this page to access the IG and all related
documentation.
Summary: This IG is modeled off of the Validated Healthcare
Directory Implementation Guide (VHDir), an international standard
developed to support a conceptual, centralized, national source of
health care data that would be accessible to local directories and used
across multiple use cases. VHDir, as a basis for a centralized health
care directory, is in development. This PlanNet IG leverages the
lessons learned

[[Page 82645]]

and input provided throughout the extended VHDir development process,
which has been informed by a large cross-section of stakeholders, and
to address a more narrow scope of health care directory needs. This IG
specifically allows payers to share basic information about their own,
local networks via a publicly-accessible API. At a minimum, this IG
will support impacted payers sharing their providers' names, addresses,
phone numbers, and specialties, which is the information required to be
shared via the Provider Directory API discussed by CMS in section II.A.
of this proposed rule. Where the VHDir IG looks to create a central
resource that a payer, for instance, could use to populate their local
directory; the PlanNet IG allows the payer to make their local
directory accessible to the public via an API.

V. Collection of Information Requirements

Under the Paperwork Reduction Act of 1995, we are required to
provide 30-day notice in the Federal Register and solicit public
comment before a collection of information requirement is submitted to
the Office of Management and Budget (OMB) for review and approval. To
fairly evaluate whether an information collection should be approved by
OMB, section 3506(c)(2)(A) of the Paperwork Reduction Act of 1995
requires that we solicit comment on the following issues:
The need for the information collection and its usefulness
in carrying out the proper functions of our agency.
The accuracy of our estimate of the information collection
burden.
The quality, utility, and clarity of the information to be
collected.
Recommendations to minimize the information collection
burden on the affected public, including automated collection
techniques.
We are soliciting public comment on each of these issues for the
following sections of this document that contain information collection
requirements (ICRs):

A. Background

Payers are in a unique position to offer patients and providers a
holistic view of a patient's health care data that might otherwise be
distributed across disparate IT systems. Payers should have the
capability to exchange data with patients and providers for care and
payment coordination or transitions, and to facilitate more efficient
care.
To advance our commitment to interoperability, we are proposing new
requirements for various impacted CMS-regulated payers to implement a
series of standards-based APIs. These standards-based APIs would permit
patients and providers to have access to a defined set of standardized
data. We believe that these proposals would help facilitate coordinated
care by helping to ensure that patients can access their own health
information, and that providers can access the health care data of
their patients through the use of common technologies, without special
effort and in an easily usable digital format.
We additionally propose to reduce prior authorization burden on
payers, providers, and patients, especially in terms of delays in
patient care, through a number of proposals that would require impacted
payers to implement standards-based APIs for prior authorization
processes, reduce the amount of time to process prior authorization
requests, and publicly report certain metrics about prior authorization
processes for transparency, among other proposals.

B. Wage Estimates

To derive average costs, we use data from the U.S. Bureau of Labor
(BLS) Statistics' National Occupational Employment and Wage Estimates
for Direct Health and Medical Insurance Carriers (NAICS Code 524114)
(https://www.bls.gov/oes/current/oes_nat.htm). Table 1 presents the
mean hourly wage, the cost of fringe benefits (calculated at 100
percent of salary), and the adjusted hourly wage.
[GRAPHIC] [TIFF OMITTED] TP18DE20.000

As indicated, we are adjusting the employee hourly wage estimates
by a factor of 100 percent. This is necessarily a rough adjustment,
both because fringe benefits and overhead costs vary significantly
across employers, and because methods of estimating these costs vary
widely across studies. Nonetheless, there is no practical alternative,
and we believe that doubling the hourly wage to estimate

[[Page 82646]]

total cost is a reasonably accurate estimation method.

C. Information Collection Requirements (ICRs)

Consistent with our approach in the CMS Interoperability and
Patient Access final rule (85 FR 25622-25623), we determine ICRs by
evaluating cost and burden at the parent organization level, as defined
and discussed in detail in that rule. In that final rule, we provided a
detailed rationale for how we determined the number of parent
organizations (85 FR 25622). For this proposed rule, we used a similar
approach to determine the number of parent organizations. We started by
reviewing the parent organizations of health plans across Medicaid and
CHIP managed care and QHP issuers on the FFEs to remove organizations
that would not be subject to our proposed policies. We then de-
duplicated the list to accurately represent those parent organizations
that have multiple lines of business across programs only once.
Ultimately, we determined that there are 209 parent organizations
across Medicaid managed care plans, CHIP managed care entities, and QHP
issuers on the FFEs. In addition, we again identified 56 states,
territories, and U.S. commonwealths which operate FFS programs, as well
as one state that operates its CHIP and Medicaid FFS programs
separately, for a total of 266 parent organizations that together
represent the possible plans, entities, issuers, and state programs
impacted by these proposals. We are interested to hear from the public
regarding this methodology and whether parent organizations can
implement the following information collection requirements across
their lines of business.
1. ICRs Regarding Patient Access API Proposal (42 CFR 431.60, 438.242,
457.730, 457.1233, and 45 CFR 156.221)
To improve patient access to their health information, as discussed
in section II.A. of this proposed rule, we are proposing to expand the
Patient Access API finalized in the CMS Interoperability and Patient
Access final rule (85 FR 25510). Specifically, we are proposing that
impacted payers implement the API conformant with a specific set of IGs
at 45 CFR 170.215 to improve interoperability. We are also proposing to
enhance the API by proposing to require information about pending and
active prior authorization decisions be made available by all impacted
payers.
The cost of upgrading the Patient Access API to be conformant with
the specified IGs is accounted for in the maintenance costs estimated
in the CMS Interoperability and Patient Access final rule (85 FR
25607). We note that those maintenance costs also include costs for MA
organizations, which are still relevant to the CMS Interoperability and
Patient Access final rule policies, and would not be directly regulated
by these proposed policies. As discussed therein, the maintenance we
estimated accounts for additional capability testing and long-term
support of the APIs, increased data storage needs, such as additional
servers, or cloud storage to store any additional patient health
information, and allocation of resources to maintain the FHIR server.
In the CMS Interoperability and Patient Access final rule (85 FR
25510), we provided a link to additional information about the set of
IGs that we are now proposing to require, and we encouraged, but did
not require, the use of the these IGs. We understand that most payers
are currently using these IGs to implement the API. We seek comment on
our assumptions that use of these IGs is adequately accounted for in
the maintenance costs of the Patient Access API in the CMS
Interoperability and Patient Access final rule.
We are also proposing to require the Privacy Policy Attestation
provision that we had presented as an option in the CMS
Interoperability and Patient Access final rule (85 FR 25549 through
25550). Facilitating this attestation process is part of the regular
work of keeping the API up to date and functioning.
2. ICRs Regarding Reporting Patient Access API Metrics to CMS Proposal
(42 CFR 431.60, 438.242, 457.730, 457.1233, and 45 CFR 156.221)
In order to assess whether our policy requirements concerning the
Patient Access API finalized in the CMS Interoperability and Patient
Access final rule (85 FR 25558) are providing patients information in a
transparent and timely way, we are proposing at 42 CFR 431.60(h),
438.242(b)(5), 457.730(h), 457.1233(d)(2), and 45 CFR 156.221(i) to
require impacted payers to report quarterly to CMS certain metrics on
use of the Patient Access API. We estimate that impacted payers would
conduct two major work phases: 1) implementation, which includes
defining requirements and system design (and updates) to generate and
compile reports; and 2) maintenance, compiling and transmitting
quarterly reporting to CMS. In the first phase (implementation), we
believe impacted payers would need to define requirements concerning
the types and sources of data that would need to be collected on the
use of the Patient Access API and build the capability for a system to
generate data that can be sent to CMS. In the second phase
(maintenance), we believe impacted payers would need to prepare the
quarterly data to be transmitted to CMS.
The burden estimate related to the new proposed requirements
reflects the time and effort needed to collect the information
described above and to disclose the information. We estimate an initial
set of one-time costs associated with implementing the reporting
infrastructure, and an ongoing annual maintenance cost to report after
the reporting infrastructure is set up.
Table 2 presents our estimates for first year implementation and
ongoing maintenance costs. For example, in the second row of Table 2,
we estimate for first-year implementation that Business Operations
Specialists would spend 60 hours at a wage of $72.62 an hour for a
total cost of $4,357.20.
As captured in the bottom two rows of Table 2:
First-year implementation would require, on average, a
total of 160 hours per organization at an average cost of $14,645.20
per organization.
Therefore, the aggregate burden of the first-year
implementation across 266 parent organizations would be 42,560 hours
(160 hours * 266 parent organizations) at a cost of $3,895,623
($14,645.20 * 266 parent organizations).
Similarly, ongoing maintenance after the first year would
require a total of 40 hours per organization per year at an average
cost of $2,904.80 per organization.
Therefore, the aggregate burden of ongoing maintenance
across 266 parent organizations would be 10,640 hours (40 hours * 266
parent organizations) at a cost of $772,677 ($2,904.80 * 266 parent
organizations).

[[Page 82647]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.001

We solicit comment on our assumptions and approach.
3. ICRs Regarding Provider Directory API Proposal (42 CFR 431.70,
438.242, 457.760, and 457.1233)
As discussed in section II.A. of this proposed rule, we are
proposing to require impacted payers implement and maintain the
Provider Directory API conformant with the HL7 FHIR Da Vinci Payer Data
Exchange Plan Net IG. The Provider Directory API was finalized in the
CMS Interoperability and Patient Access final rule (85 FR 25564). We
note that those maintenance costs also include costs to MA
organizations, which are still relevant to the CMS Interoperability and
Patient Access final rule policies, and would not be directly regulated
by these proposed policies. In the CMS Interoperability and Patient
Access final rule (85 FR 25562), we encouraged, but did not require the
use of this IG. We seek comment on this assumption that use of the IG
is fully accounted for in the maintenance costs from the CMS
Interoperability and Patient Access final rule.
4. ICRs Regarding Provider Access API Proposal (42 CFR 431.61, 438.242,
457.731, 457.1233, and 45 CFR 156.222)
To promote our commitment to interoperability, we propose new
requirements for APIs at 42 CFR 431.61(a), 438.242(b)(5), 457.731(a),
457.1233(d)(2), and 45 CFR 156.222(a). This standards-based Provider
Access API would permit providers to retrieve standardized patient data
to facilitate coordinated care. To estimate costs to implement the new
requirements for all new APIs proposed in this rule, we are using the
same methodology that we used in the CMS Interoperability and Patient
Access final rule (85 FR 25510).
In the CMS Interoperability and Patient Access final rule (85 FR
25510), we estimated that impacted payers would conduct three major
work phases: Initial design; development and testing; and long-term
support and maintenance. In this proposed rule, we assume the same
major phases of work would be required, with a different level of
effort during each work phase for each of the new proposed APIs.
Consistent across all new proposed API provisions, we describe below
the tasks associated with the first two phases. Where we believe
additional effort associated with these tasks is necessary, we describe
those as relevant in subsequent ICRs depending on how we believe they
impact cost estimates. We discuss the costs for the third phase, long-
term support and maintenance, and our methodology for the development
of those costs in aggregate for all proposed APIs below in this
section.
In the initial design phase, we believe tasks would include:
Determining available resources (personnel, hardware, cloud storage
space, etc.); assessing whether to use in-house resources to facilitate
an API connection or contract the work to a third party; convening a
team to scope, build, test, and maintain the API; performing a data
availability scan to determine any gaps between internal data models
and the data required for the necessary FHIR resources; and, mitigating
any gaps discovered in the available data.
During the development and testing phase, we believe impacted
payers would need to conduct the following: Map existing data to the
HL7 FHIR standards, which would constitute the bulk of the work
required for implementation; allocate hardware for the necessary
environments (development, testing, production); build a new FHIR-based
server or leverage existing FHIR-based servers; determine the frequency
and method by which internal data is populated on the FHIR-based
server; build connections between the databases and the FHIR-based
server; perform capability and security testing; and vet provider
requests.
The payers impacted by the proposed Provider Access API provision
are required by the CMS Interoperability and Patient Access final rule
by January 1, 2021 (beginning with plan years beginning on or after
January 1, 2021 for QHP issuers on the FFEs) \78\ (85 FR 25510) to
implement a FHIR-based Patient Access API using the same baseline
standards. These include HL7 FHIR Release 4.0.1, and complementary
security and app registration protocols, specifically the SMART
Application Launch Implementation Guide (SMART IG) 1.0.0 (including
mandatory support for the ``SMART on FHIR Core Capabilities''), which
is a profile of the OAuth 2.0 specification. Therefore, we believe
payers will be able to gain efficiencies and leverage efforts and
knowledge of the staff required to build, implement, and maintain the
Provider Access API (as well as the other APIs in this proposed rule)
because part of the cost of training and staff necessary is built into
the development of the APIs required in the CMS Interoperability and
Patient Access final rule (85 FR 25510).
---------------------------------------------------------------------------

\78\ In the CMS Interoperability and Patient Access final rule,
we finalized that these provisions would be applicable to data with
a date of service on or after January 1, 2016, beginning January 1,
2021, and enforced beginning July 1, 2021 taking into account the 6
months of enforcement discretion we are exercising as a result of
the current public health emergency (PHE).
---------------------------------------------------------------------------

One additional requirement new for both the Provider Access API and
the Payer-to-Payer API is conformance with the HL7 FHIR Bulk Data
Access (Flat FHIR) specification. We believe this is an additional
package layer on top of the baseline standards that supports the
exchange of health information for one or more patients at a time in a
secure manner. We believe this would require additional development. We
are also proposing that the Provider Access API include active and
pending prior authorization decisions and related clinical
documentation and forms, including the date the prior authorization was
approved, the date the authorization ends, as well as the units and
services approved and those used to-date. We factor in these proposed
requirements in the estimated

[[Page 82648]]

costs for the Provider Access API in Table 3. We assume this cost
accounted for here will absorb costs to include the same data in other
proposed APIs. As a result, we account for these new costs once
appreciating the efficiencies of using the same mapped data across more
than one API. We seek comment on this assumption that the underlying
content and exchange standards can be shared across the multiple APIs
discussed in this proposed rule.
Our estimates as summarized in Table 3 are based on feedback from
industry experts on the anticipated burden to implement the HL7 FHIR
Bulk Data Access (Flat FHIR) specification--including input based on
CMS' experience with the DPC pilot discussed in section II.B. of this
proposed rule. Therefore, we believe this to be a reasonable estimate
of the implementation burden.
The burden estimate related to the new requirements for APIs
reflects the time and effort needed to collect the information
described above and to disclose this information. We estimate an
initial set of one-time costs associated with implementing the proposed
Provider Access API requirements. Below we describe the burden
estimates for the development and implementation phases for the
Provider Access API.
Table 3 presents the total activities, hours, and dollar burdens
for the implementation of the Provider Access API (initial design phase
and the development and testing phase). Based on the same assumptions
as those included in the CMS Interoperability and Patient Access final
rule (85 FR 25510), we have selected the medium estimate as the primary
estimate. As can be seen from the bottom rows of Table 3:
One-time implementation efforts for the first two phases
would (for the primary estimate) require on average a total of 2,800
hours per organization at an average cost of $275,743 per organization.
The aggregate burden of the first-year implementation
across 266 parent organizations would be 744,800 hours (2,800 hours *
266) at a cost of $73.3 million ($275,743 * 266). This corresponds to
the primary estimate; the primary and high estimates are obtained by
multiplying the low estimate by a factor of two and three,
respectively.
[GRAPHIC] [TIFF OMITTED] TP18DE20.002

Although this provision would be first applicable January 1, 2023,
we believe it is reasonable that the APIs will be under development
prior to this date. Acknowledging that impacted payers will have
varying technological and staffing capabilities, we estimate that
development of the APIs will require six to 12 months of work.
Expecting that this rule will be finalized in early 2021, we have
distributed the cost estimates over approximately 2 calendar years of
time to reflect payers being given flexibility regarding when they
complete the work (see Table 10, summary table).
We solicit comment on our approach and assumptions for the cost of
the Provider Access API, including whether our estimates and ranges are
reasonable or should be modified.

[[Page 82649]]

a. API Maintenance Costs
We discuss the costs for the third phase, long-term support and
maintenance, and our methodology for the development of those costs in
aggregate for all four proposed APIs below.
As relevant to the APIs discussed in sections V.C.4., 5., 6., and
10., we estimate ongoing maintenance costs for the Provider Access API,
DRLS API, PAS API, and Payer-to-Payer API in aggregate. This approach
aligns with the approach taken in the CMS Interoperability and Patient
Access final rule (85 FR 25606-25607) whereby the costs of API
development are split into three phases: Initial design, development
and testing, and long-term support and maintenance. However, unlike the
CMS Interoperability and Patient Access final rule, this rule assumes
that maintenance costs only account for cost associated with the
technical requirements as outlined in this rule. Any changes to
requirements would require additional burden which would be discussed
in future rulemaking. Throughout this Collection of Information
section, we discuss initial design and development, and testing costs
per API. We now discuss a total maintenance cost for all four APIs.
As discussed in the CMS Interoperability and Patient Access final
rule (85 FR 25606), once the API is established, we believe that there
would be an annual cost to maintain the FHIR server, which includes the
cost of maintaining the necessary patient data, supporting the privacy
policy attestation, and performing capability and security testing. We
do believe there are efficiencies gained in implementation and
maintenance due to the fact that these proposed APIs rely on several of
the same underlying foundational technical and content. For example,
the same baseline standards including the HL7 FHIR Release 4.0.1, and
complementary security and app registration protocols--specifically the
SMART Application Launch Implementation Guide (SMART IG) 1.0.0
(including mandatory support for the ``SMART on FHIR Core
Capabilities''), which is a profile of the OAuth 2.0 specification, as
noted above. However, we do believe that maintenance costs will be
higher than what we estimated for the CMS Interoperability and Patient
Access final rule (85 FR 25510) for the new APIs proposed in this rule
as our estimates also account for new data mapping needs, standards
upgrades, additional data storage, system testing, initial bug fixes,
fixed-cost license renewals, contracting costs, and ongoing staff
education and training.
In order to account for these maintenance costs, we based our
estimates on input from industry experience piloting and demoing APIs
for provider access, prior authorization, and payer-to-payer data
exchange. We estimate an annual cost averaging approximately 25 percent
of the primary estimate for one-time API costs, or $575,285 per parent
organization ($275,743 (Provider Access API) + $984,181 (DRLS API) +
$936,400 (PAS API) + $104,816 (Payer-to-Payer API) * 25 percent) (see
V.C.4., 5., 6., and 10. for calculation of these estimates). Therefore,
the aggregate maintenance burden across 266 parent organizations would
be approximately $153,025,810 ($575,284 * 266). In Table 10 (summary
table) we account for this maintenance cost separately for each API (at
25 percent of the one-time API cost) but, as discussed previously, the
overlap in IGs across the proposed APIs, for example, is a shared
efficiency that we believe supports the assumption that maintenance
should be accounted for in aggregate and is presented in this section
as such.
We solicit public comment on our approach and assumptions for the
aggregate maintenance cost of the APIs, including whether our estimate
is reasonable or should be modified.
5. ICRs Regarding Documentation Requirement Lookup Service (DRLS) API
Proposal (42 CFR 431.80, 438.242, 457.732, 457.1233, and 45 CFR
156.223)
To promote our commitment to interoperability, we propose
requirements for DRLS API at 42 CFR 431.80(a)(1), 438.242(b)(5),
457.732(a)(1), 457.1233(d)(2), and 45 CFR 156.223(a)(1). This DRLS API,
would permit providers to access data showing whether prior
authorization is required by the payer for the requested item or
service, and if so, the documentation requirements for submitting the
prior authorization request. This API is proposed to be conformant with
the CRD and DTR IGs, and would begin January 1, 2023 (for Medicaid and
CHIP managed care plans, by the rating period beginning on or after
January 1, 2023).
As discussed above regarding the Provider Access API, to implement
the new requirements for the DRLS API, we estimate that impacted payers
would conduct three major work phases: Initial design, development and
testing, and long-term support and maintenance. Additionally, for this
proposed API, we believe additional tasks are necessary to accomplish
the proposed requirements, which we describe below as they impact the
cost estimates. As discussed previously, the costs for the third phase,
long-term support and maintenance, and our methodology for the
development of those costs in aggregate for all proposed APIs is
presented in section V.C.4. of this proposed rule.
We base our estimates on feedback from industry experts on the
anticipated burden to implement the DRLS API, including input from our
own experience working on the prototype as further discussed in section
II.C. of this proposed rule. We base our estimates on our own
experience because we believe many impacted payers will find the
experience similar to that used to estimate the cost. Additionally, the
necessary IGs are openly available as HL7 provides access to all IGs as
open source materials. Thus, HL7 IGs and many reference implementations
and test scripts are also available free of charge to the health care
community. These shared resources help support our belief that other
payers will incur similar costs. Lessons learned from this DRLS
prototype experience to-date indicate the efforts may require clinical
expertise and software and web developers. As such, we have accounted
for the necessary engineers, subject matter experts, and health
informaticists. These personnel resources would, for example, need to
convert payer prior authorization documentation rules into computable
formats, create provider questionnaires regarding whether a patient had
a medical necessity for a medical item or service, create formats that
could interface with the provider's EHR or practice management system,
and integrate the DRLS API with the payer's system.
Table 4 presents the total activities, hours, and dollar burdens
for the implementation of the DRLS API (initial design phase and the
development and testing phase). Based on the same assumptions as those
included in the CMS Interoperability and Patient Access final rule (85
FR 25510), we have selected the mid-range estimate as the primary
estimate. As can be seen from the bottom rows of Table 4:
One-time implementation efforts for the first two phases
would (for the primary estimate) require on average a total of 9,630
hours per organization at an average cost of $984,181 per organization.
Aggregate burden of the one-time implementation costs
across 266 parent organizations would be 2,561,580 hours (9,630 hours *
266) at a cost of $261.8 million ($984,181 * 266). This

[[Page 82650]]

corresponds to the primary estimate; the primary and high are obtained
by multiplying the low estimate by a factor of two and three,
respectively.
[GRAPHIC] [TIFF OMITTED] TP18DE20.003

As noted previously, although this provision would be first
applicable January 1, 2023, we believe it is reasonable that the APIs
will be under development prior to that date. Acknowledging that
impacted payers will have varying technological and staffing
capabilities, we estimate that development of the APIs will require six
to 12 months of work. Expecting that this rule will be finalized in
early 2021, we have distributed the cost over approximately two
calendar years of time to give payers the flexibility to complete the
work necessary (see Table 10, summary table).
We solicit public comment on our approach and assumptions for the
cost of the DRLS API, including whether our estimates and ranges are
reasonable or should be modified.
6. ICRs Regarding Prior Authorization Support (PAS) API Proposal (42
CFR 431.80, 438.242, 457.732, 457.1233, and 45 CFR 156.223)
We are also proposing new requirements for a PAS API at 42 CFR
431.80(a)(2), 438.242(b)(5), 457.732(a)(2), 457.1233(d)(2), and 45 CFR
156.223(a)(2). Impacted payers would be required to implement the PAS
API, and, when sending the response, include information regarding
whether the organization approves (and for how long), denies, or
requests more information for the prior authorization request. This API
must be conformant with the HL7 FHIR Da Vinci Prior Authorization
Support (PAS) IG beginning January 1, 2023 (for Medicaid and CHIP
managed care plans, by the rating period beginning on or after January
1, 2023).
As discussed previously, to implement the new requirements for the
PAS API, we estimate that impacted payers would conduct three major
work phases: Initial design, development and testing, and long-term
support and maintenance. Additionally, for this proposed PAS API, we
believe additional tasks are necessary to accomplish the proposed
requirements, which we describe below as they impact the cost
estimates. As discussed previously, the costs for the third phase,
long-term support and maintenance, and our methodology for the
development of those costs in aggregate for all proposed APIs is
presented in section V.C.4. of this proposed rule.
Our estimates are based on feedback from industry experts on the
anticipated burden to implement the PAS API. We believe this to be a
reasonable estimate of the implementation burden. Payers would need to
develop APIs that could receive providers' prior authorization
requests, and associated documentation and send the payer's decision.
In addition to implementing the PAS API, these payers would also be
required to send a reason for denial for any prior authorization
decisions that are denied. We note, as discussed in section II.C. of
this proposed rule, while the PAS API will leverage the HL7 FHIR
standard, the prior authorization transactions would remain conformant
with the X12 278 standard and thus remain HIPAA-compliant. As such,
given the added complexity of accounting for the HIPAA standards, we
have accounted for the multiple skill sets required in developing the
burden estimates.
Table 5 presents the total activities, hours, and dollar burdens
for the implementation of the PAS API (initial design phase and the
development and testing phase). Based on the same assumptions as those
included in the CMS Interoperability and Patient Access

[[Page 82651]]

final rule (85 FR 25510), we have selected the medium estimate as the
primary estimate. As can be seen from the bottom rows of Table 5:
One-time implementation efforts for the first two phases
would (for the primary estimate) require on average a total of 9,200
hours per organization at an average cost of $936,400 per organization.
The aggregate burden of the one-time implementation costs
across 266 parent organizations would be 2,447,200 hours (9,200 hours *
266) at a cost of $249.1 million ($936,400 * 266). This corresponds to
the primary estimate; the primary and high are obtained by multiplying
the low estimate by a factor of two and three, respectively.
[GRAPHIC] [TIFF OMITTED] TP18DE20.004

As noted previously, although compliance with this provision is
required to begin January 1, 2023, the APIs will be under development
prior to this date in order to be implemented and operational on
January 1, 2023 (or the rating period that begins on or after January
1, 2023 for Medicaid managed care plans and CHIP managed care
entities). Acknowledging that impacted payers will have varying
technological and staffing capabilities, we estimate that development
of the APIs will require six to 12 months of work. Expecting that this
rule will be finalized in early 2021, we have distributed the cost over
approximately two calendar years of time to give payers the flexibility
to complete the work necessary (see Table 10, summary table).
We solicit public comment on our approach and assumptions for the
one-time implementation cost of the PAS API, including whether our
estimates and ranges are reasonable or should be modified. The burden
of this provision will be included in OMB Control #0938-NEW.
7. ICRs Regarding Requirement To Send Prior Authorization Decisions
Within Certain Timeframes Proposals (42 CFR 438.210, 440.230, 457.495,
and 457.1230)
To increase transparency and reduce burden, we are proposing to
require that impacted payers, not including QHP issuers on the FFEs,
send prior authorization decisions within 72 hours for urgent requests
and 7 calendar days for non-urgent requests at 42 CFR 438.210(d)(1),
440.230(d)(1), and 457.495(d)(1). We are proposing that the payers
would have to comply with these provisions beginning January 1, 2023
(for Medicaid and CHIP managed care plans, by the rating period
beginning on or after January 1, 2023).
Since this provision is only applicable to Medicaid and CHIP, only
235 of the 266 Parent Organizations, those parent organizations that
offer Medicaid or CHIP plans, would have to implement this provision.
In order to implement this policy, there would be up-front costs
for impacted payers to update their policies and procedures, the burden
for which we now estimate. We anticipate this burden per payer is 8
hours to update policies and procedures reflecting two half-days of
work. We estimate a per entity cost of $946.40 (8 hours to develop *
$118.30/hour, the hourly wage for General and Operations Managers). The
total burden for all 235 payers is 1,880 hours (8 hours * 235), at an
aggregate first year cost of $222,404 ($946.40 * 235).
These calculations are summarized in Table 6.
[GRAPHIC] [TIFF OMITTED] TP18DE20.005

[[Page 82652]]

We solicit public comments on our assumptions and approach.
8. ICRs Regarding Public Reporting of Prior Authorization Metrics
Proposal (42 CFR 438.210, 440.230, 457.732, 457.1233, and 45 CFR
156.223)
In order to support transparency for patients in choosing health
coverage, and for providers when selecting payer networks to join, we
are proposing to require at 42 CFR 438.210(g), 440.230(d)(2),
457.732(a)(3), 457.1233(d)(2), and 45 CFR 156.223(a)(3) the applicable
payers to publicly report, annually, certain plan-level prior
authorization metrics on their websites or via publicly accessible
hyperlink(s). Impacted payers would be required to report once,
annually, by the end of the first calendar quarter each year for the
prior year's data beginning March 31, 2023.
We estimate that impacted payers would conduct two major work
phases: (1) Implementation, which includes defining requirements and
system design (and updates) to generate and compile reports; and (2)
maintenance, including annual compilation of reports and public
reporting of metrics on a website or through a publicly accessible
hyperlink(s). In the first phase, we believe impacted payers would need
to define requirements concerning the types and sources of data that
would need to be compiled regarding prior authorization activities,
build the capability for a system to generate reports, and update or
create a public web page to post the data. In the second phase, we
believe impacted payers would need to create the quarterly reports and
post to a public web page on an annual basis.
First-year implementation would require on average a total
of 320 hours per organization at an average cost of $28,685.20 per
organization.
Therefore, the aggregate burden of the first-year
implementation across 266 parent organizations would be 85,120 hours
(320 hours * 266) at a cost of $7,630,263 ($28,685.20/organization *
266).
Similarly, ongoing maintenance after the first year will
require a total of 120 hours per organization at an average cost of
$8,714.40 per organization.
Therefore, the aggregate burden of ongoing maintenance
across 266 parent organizations would be 31,920 hours (120 hours * 266
parent organizations) at a cost of $2,318,030 ($8,714.40 * 266).
[GRAPHIC] [TIFF OMITTED] TP18DE20.006

We solicit comment on this approach and our assumptions.
9. ICRs for Implementing Third Party Application Attestation for
Privacy Provisions (42 CFR 431.60(g), 438.242(b)(5), 457.70(g),
457.1233(d)(2), and 45 CFR 156.221(h))
We are proposing at 42 CFR 431.60(g) for state Medicaid FFS
programs, at 42 CFR 438.242(b)(5) for Medicaid managed care plans, at
42 CFR 457.730(g) for state CHIP FFS programs, at 42 CFR 457.1233(d)(2)
for CHIP managed care entities, and at 45 CFR 156.221(h) for QHP
issuers on the FFEs that beginning January 1, 2023 (for Medicaid
managed care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2023), that impacted payers must
establish, implement, and maintain a process for requesting an
attestation from a third-party app developer requesting to retrieve
data via the Patient Access API that indicates the app adheres to
certain privacy provisions.
Since the two tasks of establishing, implementing, and maintaining
a process for requesting an attestation from a third-party app
developer and the task of informing patients of the privacy policy
evaluation of the third-party app developer are connected, we estimate
the cost together.
We estimate the system work required is similar to the system work
required for the public reporting requirements (Table 7) which involves
both data lookup and data display. We therefore assume that first year
development costs would involve 180 hours by a software developer
working in collaboration with a business operations specialist for 140
hours to develop these systems. After the first year, the business
operations specialist would require 120 hours to maintain the system.

[[Page 82653]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.007

The aggregate first year burden is therefore 85,120 hours (266
parent organizations *(180 for development plus 140 for input from a
business operations specialist)) at a cost of $7.6 million (266
organizations * (180 hr * $102.88/hr for a software and web developer
plus 140 hr * $72.62/hr for a business operations specialist). Second
and later year burden would be 31,920 hours (266 parent organizations *
120 hr) at a cost of $2.3 million (266 parent organizations * 120 hr *
$72.62/hr).
10. ICRs Regarding Payer-to-Payer API Proposal (42 CFR 431.61, 438.242,
457.731, 457.1233, and 45 CFR 156.222)
To reduce payer, and ultimately, provider burden and improve
patient access to their health information through care coordination
between payers, as discussed in section II.D. of this proposed rule, we
are proposing new requirements at 42 CFR 431.61(c), 438.242(b),
457.731(c), 457.1233(d), and 45 CFR 156.222(b). These proposals would
improve care coordination between payers by requiring payers to
exchange, at a minimum, adjudicated claims and encounter data (not
including remittances and enrollee cost-sharing information), clinical
information as defined in the USCDI (version 1), and pending and active
prior authorization decisions, using a FHIR-based Payer-to-Payer API by
January 1, 2023 (for Medicaid and CHIP managed care plans, by the
rating period beginning on or after January 1, 2023).
As discussed for the other APIs being proposed in this rule, we
estimate that impacted payers would conduct three major work phases:
Initial design, development and testing, and long-term support and
maintenance. Additionally, for this proposed API, we believe additional
tasks are necessary to accomplish the proposed requirements, which we
describe below as they impact the cost estimates. The costs for the
third phase, long-term support and maintenance, and our methodology for
the development of those costs in aggregate for all proposed APIs is
presented in section V.C.4. of this proposed rule.
Payers should be able to leverage the API infrastructure already
accounted for in other requirements, including the Patient Access API
finalized in the CMS Interoperability and Patient Access final rule (85
FR 25510) and the Provider Access API proposal in this rule. As
discussed in the CMS Interoperability and Patient Access final rule (85
FR 25510) (as well as the companion ONC 21st Century Cures Act final
rule (85 FR 25642)) and this proposed rule, payers would be using the
same FHIR standards for content and transport; IGs to support
interoperability of data sharing; as well as the same underlying
standards for security, authentication, and authorization. In addition,
impacted payers would be required to implement the HL7 FHIR Bulk Data
Access (Flat FHIR) specification for the Provider Access API, the same
specification proposed for this Payer-to-Payer API, to support the
exchange of patient health information for one or more patients at a
time. Taken together, these standards would also support the proposed
Payer-to-Payer API. Thus, we believe there will be some reduced
development costs to implement the Payer-to-Payer API because of
efficiencies gained in implementing many of the same underlying
standards and IGs for the Patient Access API and the other APIs
proposed in this rule.
We do believe there will be some costs for impacted payers to
implement the proposed Payer-to-Payer API that are unique to this
proposal. Even though there will be some efficiencies gained in using
the same standards and IGs as other APIs, we believe based on input
from industry experience in implementing APIs that there will be costs
to test and integrate the Payer-to-Payer API with payer systems, albeit
potentially lower costs than estimated for the Provider Access API. We
estimate the one-time implementation costs at about one-third the cost
of a full de novo Provider Access API implementation based on input
from developers who have implemented and piloted prototype APIs using
the proposed required standards and IGs. As such, we have accounted for
the necessary staff required as we also believe there will be unique
costs for implementing the HL7 FHIR Payer Coverage Decision Exchange IG
so that payers can exchange active and pending prior authorization
decisions and related clinical documentation and forms when an enrollee
or beneficiary enrolls with a new impacted payer.
Table 9 presents the total activities, hours, and dollar burdens
for the implementation of the Payer-to-Payer API given our assumptions
above (initial design phase and the development and testing phase).
Based on the same assumptions as those published in the CMS
Interoperability and Patient Access final rule (85 FR 25510), we have
selected the medium estimate as the primary estimate. As can be seen
from the bottom rows of Table 9:
One-time implementation efforts for the first two phases
would (for the primary estimate) require on average a total of 1,012
hours per organization at an average cost of $104,816 per organization.
Therefore, the aggregate burden of the one-time
implementation costs across 266 parent organizations would be 269,192
hours (1,012 hours * 266) at a cost of $27.9 million ($104,816 * 266).
This corresponds to the primary estimate; the primary and high are
obtained by multiplying the low estimate by a factor of two and three,
respectively.

[[Page 82654]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.008

As noted previously, although this provision would first be
applicable January 1, 2023, we believe it is reasonable that the APIs
will be under development prior to that date. Acknowledging that
impacted payers will have varying technological and staffing
capabilities, we estimate that development of the APIs will require six
to twelve months of work. Expecting that this rule will be finalized in
early 2021, we have distributed the cost estimates over approximately
two calendar years of time to reflect impacted payers being given
flexibility regarding when they complete the work (see Table 10).
We solicit public comments on our approach and assumptions for the
cost of the Payer-to-Payer API, including whether our estimates and
ranges are reasonable or should be modified.
c. Summary of Information Collection Burdens
The previous sections have detailed costs of individual provisions.
Table 10 summarizes costs for the first, second, and subsequent years
of these provisions (as described in detail above). Table 10 reflects
an assumption of an early 2021 publication date for the final rule; the
API provisions would be effective January 1, 2023. Table 10 reflects
the primary estimates. Calculations of the high and low estimates for
the APIs may be found in the tables and narrative of the relevant
sections for each of the provisions as discussed in this Collection of
Information section. Labor costs are either BLS wages when a single
staff member is involved, or a weighted average representing a team
effort obtained by dividing the aggregate cost (calculated in the
tables above) by the aggregate hours; for example, in the first row the
$91.53 equals the aggregate $3.9 million cost divided by the aggregate
42,560 hours.
BILLING CODE 4120-01-P

[[Page 82655]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.009

BILLING CODE 4120-01-C

D. Conclusion

The provisions of this proposed rule could greatly improve data
sharing across stakeholders by facilitating access, receipt, and
exchange of patient data. This could both increase access to patient
data and decrease burden associated with gaining access to patient
data. We are committed to providing patients, providers, and payers
with timely access to patient health information. We welcome comments
on our approaches for estimating cost burden and cost savings.
The requirements of this proposed rule are extensions of the
requirements of the CMS Interoperability and Patient Access final rule
(85 FR 25510). Therefore, the information collection requirements will
be submitted to OMB for review and approval.
If you would like to provide feedback on these information
collections, please submit your comments electronically as specified in
the ADDRESSES section of this proposed rule.
Comments must be received on/by January 4, 2021.

VI. Response to Comments

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

VII. Regulatory Impact Analysis

A. Statement of Need

As described in prior sections of this proposed rule, the proposed
changes to 42 CFR parts 431, 435, 438, 440, and 457, and 45 CFR parts
156 and 170 further support the agency's efforts to reduce burden on
patients, providers, and payers, and to empower patients and providers
by increasing electronic access to health care data, while keeping that
information safe and secure. The proposals in this rule would largely
build on the foundation we laid in the CMS Interoperability and Patient
Access final rule (85 FR 25510). This proposed rule continues the
efforts started with that final rule to move the health care system
toward greater interoperability and reduce burden by proposing to
increase the data sharing capabilities of impacted payers, encourage
health care providers' use of new capabilities, and

[[Page 82656]]

make patient data more easily available to them through standards-based
technology.
The provisions in this proposed rule would allow providers and
payers new means to receive their patient population's data from
impacted payers through the Provider Access and Payer-to-Payer APIs.
This would allow providers to improve their ability to deliver quality
care and improve care coordination by ensuring that providers have
access to patient data at the point of care. These proposals would also
assist impacted payers by improving their ability to exchange claims
and clinical data on enrollees who switch payers or have concurrent
payers, which would reduce burden and improve continuity of care for
patients, as well as ensure more efficient payer operations. Further,
patients would have more timely access to their claims and other health
care information from impacted payers, empowering them to more directly
understand and manage their own care through enhancements to the
Patient Access API.
Additionally, we believe these proposals would reduce burden on
patients, providers, and payers, as well as reduce interruptions or
delays in patient care by improving some aspects of the prior
authorization process. To accomplish this, we are proposing a number of
requirements, including proposing to require impacted payers implement
and maintain a FHIR-based API to support a documentation requirement
lookup service (DRLS). The DRLS API would be able to integrate with a
provider's EHR or practice management system to allow providers to
discover the items and services that require prior authorization, as
well as the documentation required to submit a prior authorization.
Impacted payers would also be required to implement and maintain a
Prior Authorization Support (PAS) API that would have the capability to
accept and send prior authorization requests and decisions, and could
be integrated directly in a provider's workflow, while maintaining
alignment with, and facilitating the use of, the required HIPAA
transaction standards.
As noted below, we believe that the policies in this proposed rule,
if finalized, would result in some financial burdens for impacted
payers. We have weighed these potential burdens against the potential
benefits, and believe the potential benefits justify potential costs.

B. Overall Impact

We have examined the impacts of this proposed rule as required by
Executive Order 12866 on Regulatory Planning and Review (September 30,
1993), Executive Order 13563 on Improving Regulation and Regulatory
Review (January 18, 2011), the Regulatory Flexibility Act (RFA)
(September 19, 1980, Pub. L. 96-354), section 1102(b) of the Social
Security Act, section 202 of the Unfunded Mandates Reform Act of 1995
(March 22, 1995; Pub. L. 104-4), Executive Order 13132 on Federalism
(August 4, 1999), and Executive Order 13771 on Reducing Regulation and
Controlling Regulatory Costs (January 30, 2017).
Executive Orders 12866 and 13563 direct agencies to assess all
costs and benefits of available regulatory alternatives and, if
regulation is necessary, to select regulatory approaches that maximize
net benefits (including potential economic, environmental, public
health and safety effects, distributive impacts, and equity). Section
3(f) of Executive Order 12866 defines a ``significant regulatory
action'' as an action that is likely to result in a rule: (1) Having an
annual effect on the economy of $100 million or more in any one year,
or adversely and materially affecting a sector of the economy,
productivity, competition, jobs, the environment, public health or
safety, or state, local or tribal governments or communities (also
referred to as ``economically significant''); (2) creating a serious
inconsistency or otherwise interfering with an action taken or planned
by another agency; (3) materially altering the budgetary impacts of
entitlement grants, user fees, or loan programs or the rights and
obligations of recipients thereof; or (4) raising novel legal or policy
issues arising out of legal mandates, the President's priorities, or
the principles set forth in the Executive Order.
A Regulatory Impact Analysis must be prepared for major rules with
economically significant effects ($100 million or more in any one
year). We estimate that this rulemaking is ``economically significant''
as measured by the $100 million threshold, and hence a major rule under
the Congressional Review Act. Accordingly, we have prepared a
Regulatory Impact Analysis that, to the best of our ability, presents
the costs and benefits of this rulemaking.

C. Regulatory Flexibility Act

Executive Order 13272 requires that HHS thoroughly review rules to
assess and take appropriate account of their potential impact on small
business, small governmental jurisdictions, and small organizations (as
mandated by the Regulatory Flexibility Act (RFA)). If a proposed rule
may have a significant economic impact on a substantial number of small
entities, then the proposed rule must discuss steps taken, including
alternatives considered, to minimize burden on small entities. The RFA
does not define the terms ``significant economic impact'' or
``substantial number.'' The Small Business Administration (SBA) advises
that this absence of statutory specificity allows what is
``significant'' or ``substantial'' to vary, depending on the problem
that is to be addressed in rulemaking, the rule's requirements, and the
preliminary assessment of the rule's impact. Nevertheless, HHS
typically considers a ``significant'' impact to be three to five
percent or more of the affected entities' costs or revenues.
For purposes of the RFA, we estimate that many impacted payers are
small entities as that term is used in the RFA, either by being
nonprofit organizations or by meeting the SBA definition of a small
business. For purposes of the RFA, small entities include small
businesses, nonprofit organizations, and small governmental
jurisdictions. The North American Industry Classification System
(NAICS) is used in the U.S., Canada, and Mexico to classify businesses
by industry. While there is no distinction between small and large
businesses among the NAICS categories, the SBA develops size standards
for each NAICS category.\79\ Note that the most recent update to the
NAICS went into effect for the 2017 reference year.
---------------------------------------------------------------------------

\79\ Office of Management and Budget. (2017). North American
Industry Classification System. Retrieved from: https://www.census.gov/eos/www/naics/2017NAICS/2017_NAICS_Manual.pdf.
---------------------------------------------------------------------------

We first review the provisions of this rule at a high level, and
then discuss each of the impacted payer types, and through this
discussion evaluate the impact on small entities.
1. Overview of Overall Impact
The annual information collection burden estimates for the proposed
requirements in this rule are summarized in Table 10 of the Collection
of Information (section V. of this proposed rule). The specific
information collection requirement (ICR) proposals, which we have
calculated burden estimates for, include: (1) Provider Access API
(Table 3); (2) DRLS API (Table 4); (3) PAS API (Table 5); (4) Proposed
requirement to send prior authorization decisions within certain
timeframes (Table 6); (5) Payer-to-Payer API (Table 9); (6) two metrics
reporting requirements (specifically, Patient Access API and prior
authorization metrics) (Tables 2

[[Page 82657]]

and 7) and (7) Requirements to comply with privacy policy attestations
(Table 8).
Additionally, this Regulatory Impact Analysis section provides an
analysis about potential savings from voluntary provider compliance
with the DRLS and PAS API proposed provisions (however, this savings is
neither included in monetized tables nor in summary tables, as further
discussed below). We have identified assumptions for these analyses,
and we solicit public comment.
In analyzing the impact of this proposed rule, we note that there
would be a quantifiable impact for the proposed Provider Access, DRLS,
and PAS APIs. The proposed requirements would apply to 266 parent
organizations. Throughout this proposed rule we use the term ``parent
organizations'' to refer to impacted payers. These parent organizations
include the states that administer state Medicaid and CHIP FFS
programs, Medicaid managed care plans, CHIP managed care entities, and
QHP issuers on the FFEs.
The NAICS category relevant to these proposed provisions is Direct
Health and Medical Insurance Carriers, NAICS 524114, who have a $41.5
million threshold for ``small size.'' Seventy-five percent of insurers
in this category have under 500 employees, thereby meeting the
definition of small business.
We are certifying that, for impacted payers, this proposed rule
does not have a significant economic impact on a substantial number of
small entities with regard to the provisions noted above.
2. Health Coverage Groups
If the proposals in this rule are finalized, the 266 parent
organizations, including state Medicaid and CHIP agencies, would be
responsible for implementing and maintaining four new APIs, updating
policies and procedures regarding timeframes for making prior
authorization decisions, and reporting certain metrics either to CMS or
the public. Medicaid managed care plans, CHIP managed care entities,
and QHP issuers on the FFEs are classified as NAICS code 524, direct
health insurance carriers. We are assuming that a significant number of
these entities are not small. And, we note that none of the state
Medicaid and CHIP agencies are considered small.
At a high level, state Medicaid managed care plans and CHIP managed
care entities have many of their costs covered through capitation
payments from the federal government or through state payments.
Therefore, there is no significant burden, as detailed below. If
finalized as proposed, QHP issuers on the FFEs and certain states
operating Medicaid and CHIP FFS programs would be able to apply for an
extension, exception or exemption under which they would not be
required to meet the new API provisions of the proposed rule on the
proposed compliance dates, provided certain conditions are met as
discussed in sections II.B., II.C., and II.D. of this proposed rule. We
therefore believe there is no significant burden to a significant
number of entities from this proposed rule for these provisions as
discussed.
a. Medicaid and CHIP
Title XIX of the Act established the Medicaid program as a federal-
state partnership for the purpose of providing and financing medical
assistance to specified groups of eligible individuals. States claim
federal matching funds on a quarterly basis based on their program
expenditures. Since states are not small entities under the Small
Business Act we need not further discuss in this section the burden
imposed on them by this rule.
With regard to Medicaid managed care plans and CHIP managed care
entities, since managed care plans receive 100 percent capitation
payments from the state, we generally expect that the costs associated
with the provisions of this proposed rule would be included in their
capitation rates and may be reasonable, appropriate, and attainable
costs whether they are a small business or not. Consequently, we can
assert that there is no significant impact on a significant number of
entities.
As discussed in sections II.B., II.C., and II.D. for the new
proposed API provisions, states operating Medicaid FFS and CHIP FFS
programs could submit an application for an extension of up to one year
to comply with the requirements of this rule. Additionally, we propose
that states operating Medicaid and CHIP FFS programs with very low
enrollment and high managed care penetration rates (at least 90
percent), can apply for an exemption under which they would not be
required to meet certain proposed requirements, provided certain
conditions are met.
b. QHP Issuers on the FFEs
Few, if any, QHP issuers on the FFEs are small enough to fall below
the size thresholds for a small business established by the SBA.
Consistent with previous CMS analyses, we estimate that any issuers
that would be considered a small business are likely to be subsidiaries
of larger issuers that are not small businesses (78 FR 33238) and thus
do not share the same burdens as an independent small business.
Therefore, even though QHP issuers do not receive federal reimbursement
for the costs of providing care, we do not conclude that there would be
a significant small entity burden for these issuers. In addition, we
propose an exception process for QHP issuers on the FFEs from certain
proposed requirements, which further helps to address burden that could
otherwise prohibit a QHP issuer from participating in an FFE.
Based on the above, we conclude that the requirements of the RFA
have been met by this proposed rule.

D. UMRA and E.O. 13132 Requirements

Section 202 of the Unfunded Mandates Reform Act of 1995 (UMRA)
requires that agencies assess anticipated costs and benefits before
issuing any rule whose mandates require spending in any one year of
$100 million in 1995 dollars, updated annually for inflation. In 2020,
that threshold is approximately $156 million. This proposed rule would
not impose an unfunded mandate that would result in the expenditure by
state, local, and tribal governments, in the aggregate, or by the
private sector, of more than $156 million in any one year.
Executive Order 13132 establishes certain requirements that an
agency must meet when it promulgates a proposed rule (and subsequent
final rule) that imposes substantial direct requirement costs on state
and local governments, preempts state law, or otherwise has federalism
implications. As previously outlined, while the API provisions would be
a requirement for state Medicaid and CHIP agencies under these
proposals, the cost per enrollee for implementation is expected to be
negligible when compared with the overall cost per enrollee. This
analysis does not take into account federal matching funds provided to
state Medicaid and CHIP agencies, but the conclusion is the same: There
is not expected to be a significant cost impact on state entities.
For Medicaid and CHIP, we do not believe that the proposals in this
rule would conflict with state law, and therefore, do not anticipate
any preemption of state law. However, we invite states to submit
comments on this proposed rule if they believe any proposal in this
rule would conflict with state law, so that we can fully evaluate any
potential conflicts.
If regulations impose administrative costs on private entities,
such as the time needed to read and interpret this proposed or final
rule, we should estimate the cost associated with

[[Page 82658]]

regulatory review. We model our estimates of review burden based on
similar estimates presented in the CMS Interoperability and Patient
Access final rule (85 FR 25510).
The particular staff involved in such a review would vary from one
parent organization to another. We believe that a good approximation
for a range of staff would be a person such as a medical and health
service manager or a lawyer. Using the wage information from the BLS
for medical and health services managers (Code 11-9111) and lawyers
(Code 23-1011) we estimate that the cost of reviewing this proposed
rule is $125.23 per hour, including overhead and fringe.\80\ This
number was obtained by taking the average wage of a medical manager and
lawyer.
---------------------------------------------------------------------------

\80\ U.S. Bureau of Labor Statistics. (2019, April 02). May 2018
National Occupational Employment and Wage Estimates. Retrieved from
https://www.bls.gov/oes/current/oes_nat.htm.
---------------------------------------------------------------------------

In the CMS Interoperability and Patient Access final rule (85 FR
25510), we estimated six hours of reading time. Therefore, we believe
10 hours would be enough time for each parent organization to review
relevant portions of this proposed rule.
We believe the review would be done by parent organizations that
would be required to implement the proposed provisions. There are 266
parent organizations accounted for in our estimates. Thus, we estimate
a one-time aggregated total review cost of $333,112 million ($125.23 *
10 hours * 266 entities). We solicit comments on our estimate.

E. Impact of Individual Proposals

The proposed provisions of this rule would have information
collection-related burden. Consequently, the impact analysis may be
found in Table 10 of the Collection of Information in section V. of
this proposed rule. To facilitate review of the provisions and
estimates made in the Collection of Information, we include Table 11,
which provides the related ICRs in section V. of this proposed rule,
the tables in section V. where impact is presented, as well as a title
used for cross-reference in the remainder of this Regulatory Impact
Analysis section.
Table 19 of this section, using Table 10 as a basis, provides a 10-
year impact estimate. Table 19 includes impact by year, by type (parent
organizations, including Medicaid and CHIP state agencies), as well as
the cost burden to the federal government, allocations of cost by
program, and payments by the federal government to Medicaid and CHIP,
as well as the premium tax credits (PTC) paid to certain enrollees in
the individual market.
[GRAPHIC] [TIFF OMITTED] TP18DE20.010

F. Alternatives Considered

In this proposed rule, we continue to build on the efforts
initiated with the CMS Interoperability and Patient Access final rule
(85 FR 25510) and the work we have done to reduce burden in the health
care system, to advance interoperability, improve care coordination,
reduce burden, and empower patients with access to their health care
data. This proposed rule covers a range of policies aimed at achieving
these goals. We carefully considered alternatives to the policies we
are proposing in this rule. We concluded that none of the alternatives
would adequately or immediately begin to address the critical issues
related to patient access and interoperability or help to address the
processes that contribute to payer, provider, and patient burden.
We now discuss the alternatives we considered to our proposed
provisions and the reasons why we did not select them as proposed
policies.
1. Alternatives Considered for the Proposed Patient Access API
Enhancements
We are proposing to require that payers make enhancements to the
Patient Access API finalized in the CMS Interoperability and Patient
Access final rule (85 FR 25510) including requiring the Patient Access
API be conformant with the IGs specified in section II.A.2. of this
proposed rule, proposing additional information be made available to
patients through the Patient Access API, proposing a privacy
attestation policy, and proposing certain metrics about patient use of
the Patient Access API be reported directly to CMS quarterly. Before
proposing to require these provisions, we considered several policy
alternatives.
As we discussed in the CMS Interoperability and Patient Access
final rule (85 FR 25627), one alternative to the proposed updates to
the Patient Access API we considered is allowing payers and providers
to upload patient

[[Page 82659]]

data directly to a patient portal, operated by a provider. However,
despite the availability of patient portals, ONC reported in 2017 that
only 52 percent of individuals have been offered online access to their
medical records by a health provider or payer. And of the 52 percent
that were offered access, only half of those viewed their record.\81\
Therefore, we do not believe that patient portals are meeting patients'
needs and would not be a suitable policy option to propose. We also
believe that there would be additional burden associated with using
portals, because providers and patients would need to utilize multiple
portals and websites, requiring various log-ins, to access all of a
patient's relevant data--one for each provider a patient is associated
with--instead of a single app. Portals would require developers to link
systems or ensure system-level compatibility to enable patients to see
a more comprehensive picture of their care. Alternatively, FHIR-based
APIs have the ability to make data available without the need to link
multiple systems or portals and would provide a patient a single point
of access to their data. APIs that make data available to third-party
apps permit the patient to choose how they want to access their data
and promote innovation in industry to find solutions to best help
patients interact with their data in a way that is most meaningful and
valuable to them. The nature of portals does not lend as well to such
interoperability or innovation. Because business models and processes
pertaining to patient portals are varied across the industry, and any
one patient could be associated with a number of different portals, we
believe it would be very difficult to evaluate the cost impacts of
requiring individual portals versus the estimates for enhancing the
Patient Access API.
---------------------------------------------------------------------------

\81\ Patel, V. & Johnson, C. (2018, April). Individuals' Use of
Online Medical Records and Technology for Health Needs (ONC Data
Brief N. 40). Retrieved from https://www.healthit.gov/sites/default/files/page/2018-03/HINTS-2017-Consumer-Data-Brief-3.21.18.pdf.
---------------------------------------------------------------------------

As explained in the CMS Interoperability and Patient Access final
rule (85 FR 25627), another alternative considered was to allow Health
Information Exchanges (HIEs) and Health Information Networks (HINs) to
serve as a central source for patients to obtain aggregated data from
across their providers and payers in a single location. HIEs and HINs
could provide patients with information via an HIE portal that is
managed by the patient. However, as described above, there are various
reasons why patient portal access does not lend itself to
interoperability or innovation, and not all patients might have access
to an HIE or HIN. For these reasons, we ultimately decided to proceed
with our proposed requirements versus this alternative.
We had also considered alternative compliance dates for the
proposed policies. For instance, we considered January 1, 2022, as a
possible compliance date for the Patient Access API enhancements.
However, due to the current public health emergency and the enforcement
discretion we are exercising for the API policies finalized in the CMS
Interoperability and Patient Access final rule, we believe it is more
appropriate, and less burdensome to impacted payers to propose
compliance dates for these policies beginning January 1, 2023 (for
Medicaid managed care plans and CHIP managed care entities, by the
rating period beginning on or after January 1, 2023).
2. Alternatives Considered for the Proposed Provider Access API
In this proposed rule, to better facilitate the coordination of
care across the care continuum, we are proposing to require impacted
payers to implement and maintain a Provider Access API conformant with
the specified HL7 FHIR IGs, as well as the HL7 FHIR Bulk Data Access
(Flat FHIR) specification to support exchanging data for one or more
patients at a time. This proposed API would require payers to make
available to providers the same types of data they would make available
to patients via the enhanced Patient Access API.
Alternatively, we considered other data types that could be
exchanged via the Provider Access API. We considered only requiring the
exchange of clinical data, as defined in the USCDI. While this would be
less data to exchange and, thus, potentially less burdensome for payers
to implement, we believe that claims and encounter information can
complement the USCDI data and offer a broader and more holistic
understanding of a patient's interactions with the health care system.
Furthermore, the data that we propose to be available through the
proposed Provider Access API aligns with the data that we propose be
available to individual patients through the Patient Access API.
Therefore, we do not believe there is significant additional burden to
include these data as once the data are mapped and prepared to share
via one FHIR-based API, these data are available for all payer APIs to
use.
We did also consider only having payer claims and encounter data
available to providers, understanding that providers are generally the
source of clinical data. Again, this could potentially reduce burden on
payers by potentially requiring less data to be made available.
However, even if a provider is the source for the clinical data
relevant to their patients' care, a provider may not have access to
clinical data from other providers a patient is seeing. As a result,
and understanding payers were already preparing these data for use in
other APIs, we decided a more comprehensive approach would be most
beneficial to both providers and patients and thus aligned the proposed
Provider Access API data requirements with those proposed for the
Patient Access API.
We also considered including additional data elements in this
proposal. We considered requiring the patient's complete medical
record. However, we believe this would require additional resources and
be overly burdensome for impacted payers at this time. The USCDI is a
standardized set of health data classes and constituent data elements
for nationwide, interoperable health information exchange.\82\ Because
this limited set of data has been standardized, and corresponding HL7
FHIR IGs have been developed, payers can map these data and make them
more easily available via an API. Industry has not yet fully developed
the needed IGs to facilitate sharing a patient's full medical record.
Before this alternative would be feasible, more FHIR development work
needs to be done, and important questions about data segmentation, and
a patient's role in potentially specifying what parts of their medical
record could or should be available to which providers, need to be
considered.
---------------------------------------------------------------------------

\82\ Interoperability Standards Advisory. (n.d.). U.S. Core Data
for Interoperability. Retrieved from https://www.healthit.gov/isa/united-states-core-data-interoperability-uscdi.
---------------------------------------------------------------------------

3. Alternatives Considered for the Proposed DRLS API and PAS API and
Other Prior Authorization Proposals
In this rule, we are also proposing several policies that would
reduce burden associated with the prior authorization process. First,
we are proposing to require all impacted payers implement and maintain
a DRLS API conformant with the HL7 FHIR CRD and DTR IGs. We believe
this would reduce burden for payers, providers, and patients by
streamlining access to information about which items and services
require a prior authorization and the associated documentation
requirements, potentially reducing the number of incomplete and denied
prior authorization requests. This would add efficiencies for both
payers and

[[Page 82660]]

providers, and it would improve patient care by avoiding gaps and
delays in care.
As proposed, by January 1, 2023, (for Medicaid managed care plans
and CHIP managed care entities, by the rating period beginning on or
after January 1, 2023), impacted payers would be required to implement
the DRLS API, populate the API with their list of items and services
for which prior authorization is required, populate the API with their
associated documentation rules, and ensure the DRLS API is functional.
Alternatively, we considered proposing a phased approach to the DRLS
API where payers would first upload a specified subset of documentation
to the DRLS API, as opposed to all of the documentation for all
applicable items and services at one time. For instance, we considered
requiring that payers only prepare the DRLS for a specific set of
services most commonly requiring prior authorization across payers.
However, we believe this would be more burdensome in some ways. It
would require payers to use different systems to find requirements for
different services for a single payer, for instance. If the
requirements for different services were in different places--such as
some information in payer portals and some through the DRLS API--
providers would have to spend additional time searching for the
information in multiple locations for one payer. Therefore, we believe
it is ultimately less burdensome overall to require impacted payers to
populate the prior authorization and documentation requirements for all
items and services at the same time.
We also considered whether we should propose to require that payers
post, on a public-facing website, their list of items and services for
which prior authorization is required, populate the website with their
associated documentation rules as in interim step while they implement
the DRLS. However, we are aware that payers already have this
information publicly available, and determined that this would not
provide any reduced burden on payers or providers at this time. We seek
comment on whether a payer website to provide additional transparency
to prior authorization requirements and documentation would be
beneficial in reducing overall burden in this process.
We are also proposing to require impacted payers implement and
maintain a FHIR-based PAS API conformant with the HL7 FHIR Da Vinci PAS
IG that would have the capability to accept and send prior
authorization requests and decisions. This API would be accessible to
providers to integrate directly into their workflow, while maintaining
alignment with, and facilitating the use of, the required HIPAA
transaction standards. This requirement is proposed to be effective at
the same time as the DRLS API, January 1, 2023 (for Medicaid managed
care plans and CHIP managed care entities, by the rating period
beginning on or after January 1, 2023). We considered a phased timeline
approach to implement both of these APIs. For instance, we considered
first requiring implementation of the DRLS API in 2022 and then a year
later requiring implementation of the PAS API. However, given the
current situation with the public health emergency, and taking into
account the enforcement discretion we are exercising as a result for
the APIs finalized in the CMS Interoperability and Patient Access final
rule (85 FR 25510), we believe it is more appropriate, and less
burdensome to impacted payers, to propose compliance dates for both of
these policies in 2023, providing payers with more time to potentially
implement both policies. We further determined that because the DRLS
API and the PAS API are steps in the same prior authorization workflow,
the full benefits of both APIs are best realized when used
concurrently.
We are proposing other provisions to reduce prior authorization
burden including requiring payers to ensure that prior authorization
decisions are made within 72 hours of receiving an expedited request
and no later than 7 days after receiving a standard requests, and
proposing to require impacted payers to publicly report prior
authorization metrics on their websites or via publicly accessible
hyperlink(s) annually.
We considered several alternative policies before deciding to
propose these policies. We considered alternative timeframes such as
whether payers could provide a decision in less than 72 hours (for
expedited decisions) and 7 days (for standard decisions). For example,
we considered requiring payers to provide a decision in 48 hours for
expedited requests and 3 days for standard requests. Despite the
importance of having providers and patients get decisions as quickly as
possible, we believe that the timeframes we propose in this rule would
help increase reliability in the prior authorization process and
establish clear expectations without being overly burdensome for
payers. These timeframes would allow payers to process the prior
authorization decisions in a timely fashion and give providers and
patients an expectation for when they can anticipate a decision, while
at the same time encouraging a timelier decision-making process. We
also considered whether more than 7 days would be necessary for complex
cases. We did not propose this alternative, however, because we believe
it is important for patients and providers to be able to receive a
decision in a shorter timeframe. We believe 7 days is sufficient time
for a payer to process prior authorization decisions.
Regarding publicly reporting prior authorization metrics, we
considered requiring impacted payers to publicly report these metrics
more frequently than annually. For instance, we considered a quarterly
requirement. While we considered this alternative, we believe that our
proposal is sufficient to accomplish our goals without creating
additional burden. Because patients typically shop for health coverage
on an annual basis, we believe updating this information annually would
be sufficient for supplying patients and providers with transparent and
valuable information. We also considered reporting these metrics at the
parent organization versus at the plan or issuer level for all impacted
payers. After further consideration, we decided this may not be truly
operational and may be too aggregated a level of reporting for some
payer types to provide true transparency or useful information for
patients and providers. As a result, we are proposing reporting at the
state-level for Medicaid and CHIP FFS, plan-level for Medicaid and CHIP
managed care, and at the issuer-level for QHP issuers on the FFEs.
4. Alternatives Considered for the Proposed Payer-to-Payer API
We are proposing to require impacted payers to implement and
maintain a Payer-to-Payer API that makes the same data available to
other payers via a FHIR-based API as we propose payers make available
to patients and providers, conformant with the same IGs as proposed for
the Patient Access API discussed in section II.A. and the Provider
Access API discussed in section II.B. of this proposed rule. Before
proposing these policies, we considered several policy alternatives.
We considered proposing to enhance the Payer-to-Payer Data Exchange
finalized in the CMS Interoperability and Patient Access final rule
without naming a specific standard. We considered maintaining a payer's
ability to share data with another payer without requiring the use of
an API, and instead only requiring the additional

[[Page 82661]]

types of data be made available to share. But, ultimately, there are
numerous benefits to requiring the FHIR-based API conformant with the
specified IGs for this data sharing. We have heard from several
stakeholders that sharing these data in a standardized way is the only
way to introduce valuable efficiencies and achieve true
interoperability. Furthermore, for the Payer-to-Payer API, once an
organization implements the other proposed APIs, there would be less
additional investment necessary to implement the Payer-to-Payer API as
payers would be able to leverage the infrastructure already established
for the Patient Access API and Provider Access API. Given this
available infrastructure, and the efficiencies of sharing standardized
data via the API, we determined it was most advantageous for payers to
again leverage an API for this enhanced data exchange.
We also considered which data elements would be the most
appropriate. Similar to the Provider Access API alternatives, we
considered only requiring the exchange of clinical data as defined in
the USCDI via an API. As we described above, we believe that claims and
encounter information can complement the USCDI data and potentially
allow for better care coordination, as well as more efficient payer
operations. And, we do not believe there would be significant
additional burden once the data are mapped to FHIR for the other
proposed APIs.
We also considered requiring payers to exchange all prior
authorization decisions, including expired decisions, via the Payer-to-
Payer API. However, we recognize that much of this information may be
outdated and may not have an effect on the new payer's prior
authorization process. Therefore, in an effort to reduce the volume of
outdated or irrelevant information shared among payers, we have decided
to limit the proposal to only active and pending prior authorization
decisions.

G. Analysis of Potential Impact for Savings by Voluntary Participation
of Individual Providers in the Proposed Prior Authorization Provisions

To support our commitment to promoting interoperability and
reducing burden on payers, providers, and patients, as discussed in
section II.C. of this proposed rule, we are proposing new requirements
related to prior authorization for states operating Medicaid FFS
programs at 42 CFR 431.80 and 440.230; states operating CHIP FFS
programs at 42 CFR 457.495 and 457.732; Medicaid managed care plans at
42 CFR 438.210 and 438.242; CHIP managed care entities at 42 CFR
457.495, 457.1230, and 457.1233; and QHP issuers on the FFEs at 45 CFR
156.223. While we discussed the ICRs regarding cost estimates of those
proposals with anticipated impact in sections V.C.5. through V.C.8.,
here, we discuss the anticipated cost savings of these proposals to the
health care industry.
We have detailed in this section the cost impact of creating the
proposal discussed in section II.C. of this rule, including the DRLS
and PAS APIs, as well as a number of other policies focused on reducing
burden associated with the prior authorization process. Potentially
offsetting some of these costs are the savings that would result from
reduced administrative work associated with existing prior
authorization protocols.
These savings would be true savings, not transfers, since they
reflect savings in reducing the administrative costs required to
process prior authorizations. However, these savings would be an
indirect consequence of the proposed rule, not direct savings. To be
clear, this proposed rule does not reduce the current paperwork
required for prior authorization. Rather, a consequence of the
efficiencies resulting from the prior authorization proposals would be
significantly reduced time spent on the paperwork. In general, it is
only appropriate to claim that a regulatory provision's benefits are in
excess of its costs after a substantive, and preferably quantitative,
assessment of the pre-existing market failure and the provision's
suitability for addressing it. As a result of data limitations and
other analytic challenges preventing such an assessment in this, the
case illustrative savings estimates are neither included in the
monetized table, nor the summary table of the Regulatory Impact
Analysis in section VII. of this proposed rule, nor in the 2016-dollar
calculation. Nevertheless, the savings could be significant and we
believe should be a factor in the evaluation of this proposed rule.
In calculating these potential savings, uncertainties arise in five
areas, described below. The result of this illustrative analysis is
that we find a potential savings impact of a billion dollars over 10
years. In this section, we carefully explain each uncertainty, indicate
how we approached estimation, and solicit public comment.
The five areas of uncertainty we had to take into account include:
(1) Assumptions on the number of providers voluntarily engaging
with the provisions of this proposed rule: A major obstacle in
estimating impact is the fact that these provisions, if finalized,
would be mandatory for impacted payers but engagement by providers is
voluntary. Before proposing this rule, we conducted conversations with
stakeholders who indicated that more efficient prior authorization
processes would ultimately reduce burden for all affected parties and
would therefore likely be utilized by providers.
To address the voluntary nature of provider utilization of the
electronic prior authorization tools, we assume no provider
participation in the first year, gradually increasing to 25 percent
participation in 10 years. We believe this is a usefully illustrative
assumption.\83\ We also believe that it is reasonable to assume that
additional providers would participate as prior authorization
capabilities become more widely available in EHRs, which are not
regulated by this rule, and the benefits of having more efficient prior
authorization processes become clear through burden reduction and
improved patient care.
---------------------------------------------------------------------------

\83\ This assumption may be supported by some states already
adopting legislation around electronic prior authorization, and
federal legislation such as provision 6062 in the SUPPORT Act (H.R.
6) where electronic prior authorization is stipulated for drugs
covered under Medicare Part D by January 1, 2021. However, reasons
for electronic prior authorization tools to be used are not
necessarily reasons why their use is attributable to this proposed
rule; they might instead be reasons why use would occur even in the
rule's absence. We request comment that would help with identifying
impacts attributable to this proposal.
---------------------------------------------------------------------------

In going from no providers leveraging the technology in the first
year of implementation to 25 percent of providers using the technology
in 10 years, we did not believe it appropriate to use a strict linear
approach of a 2.5 percent increase of providers per year. We are aware
that many providers do not yet have the necessary technical
capabilities to facilitate interoperable exchange of data for prior
authorization. Specifically, their EHR systems are not yet prepared to
leverage the DRLS or PAS APIs. Absent that technology in the EHR, the
DRLS and PAS APIs would provide minimal benefit to providers. We assume
that providers in hospitals and providers in large health systems who
already have such software would use it as soon as technologically
feasible. Therefore, we modeled the growth of providers participating
with a gradually increasing exponential model, since the exponential
model is typically used to indicate slow growth in the beginning but
faster growth later on. Our numerical assumptions of the percent of
providers using DRLS and PAS APIs are presented in Table 12.

[[Page 82662]]

(Note, exponential models cannot start at 0; therefore, we started at
0.01 percent.)
We solicit public comments on all assumptions: The assumption of no
providers in the first year; the assumption of 25 percent participation
in the tenth year; and the use of an exponential model.
[GRAPHIC] [TIFF OMITTED] TP18DE20.011

(2) Assumptions on the current workload hours for prior
authorization: To estimate the savings impact, we first require
estimates of the current amount of paperwork involved in prior
authorization, the type and number of staff involved, the type of
physician offices involved, and hours per week spent engaged in prior
authorization processes. Our assumptions are based on a well-conducted
survey presented in Casalino et al. (2009) \84\, which gives a detailed
analysis based on a validated survey instrument employed in 2006.
---------------------------------------------------------------------------

\84\ Casalino, L.P., Nicholson, S., Gans, D., Hammons, T.,
Morra, D., Karrison, T., & Levinson, W. (May 2009). What Does It
Cost Physician Practices To Interact With Health Insurance Plans?
Health Affairs, 28(4): w533-w543. doi: 10.1377/hlthaff.28.4.w533.
---------------------------------------------------------------------------

This survey excluded certain physician practices, including health
maintenance organizations (HMOs), but analyzed workload by staff type
(doctor, nurse, clerical, administrator, lawyer, and accountant),
office type (solo, three to 10 physicians, 10 or more physicians), and
type of medical work involved (prior authorization, formulary, claims
billing, quality, etc.). Consistent with our approach, we restricted
ourselves to prior authorization activities, though formulary work
could possibly add to burden related to prior authorization activities.
Using the methods and data from Casalino et al. (2009), Table 13
presents an estimate of the current average annual paperwork burden per
physician office for prior authorization activities. Table 13 estimates
an annual burden per physician office of 1,060.8 hours at a cost of
$73,750.
[GRAPHIC] [TIFF OMITTED] TP18DE20.012

Table 13 estimates are based on Casalino et al. (2009). Several
other examples in the literature were reviewed
^{85 86 87 88 89} which, although reflecting more recent
research, either did not show the basis for their calculations, showed
a basis based on a very small number of people, or used a non-validated
survey. For this reason, we used the Casalino et al. (2009) article for
our calculations.
---------------------------------------------------------------------------

\85\ Morley, C.P., Badolato, D.J., Hickner, J., Epling, J.W.
(2013, January). The Impact of Prior Authorization Requirements on
Primary Care Physicians' Offices: Report of Two Parallel Network
Studies. The Journal of the American Board of Family Medicine,
26(1), 93-95. doi: 10.3122/jabfm.2013.01.120062.
\86\ Ward, V. (2018, April). The Shocking Truth About Prior
Authorization in Healthcare. Retrieved from https://getreferralmd.com/2018/04/prior-authorization-problems-healthcare/.
\87\ Center for Health Innovation & Implementation Science.
(2018, July 26) The Prior Authorization Burden in Healthcare.
Retrieved from https://www.hii.iu.edu/the-prior-authorization-burden-in-healthcare/.
\88\ Robeznieks, A. (2018, November 16). Inside Cleveland
Clinic's $10 million prior authorization price tag. Retrieved from
https://www.ama-assn.org/practice-management/sustainability/inside-cleveland-clinic-s-10-million-prior-authorization-price.
\89\ American Medical Association. (2019, June). Prior
Authorization and Utilization Management Reform Principles.
Retrieved from https://www.ama-assn.org/system/files/2019-06/principles-with-signatory-page-for-slsc.pdf.
---------------------------------------------------------------------------

The wages in Table 13 have been updated from those used in the
Casalino et al. (2009) work to the latest BLS wages. The hours should
also be adjusted for 2021, to account for increased prior authorization
requirements. However, we do not have a more recent reliable survey on
which to base this. Table 16 in this section presents an alternate
estimate assuming a 4 percent growth rate in hours per week spent on
prior authorization, the 4 percent coming from the articles cited
above. We solicit public comment on these assumptions on the hours per
week spent on prior authorization paperwork.
(3) Assumptions on the total number of physician practices: Table
13 presents current hour and dollar burden per physician office. To
obtain aggregate annual burden of prior authorization over all
physician practices including those exclusively furnishing services to
Fee For Service (FFS) enrollees, Casalino et al. (2009) multiplies the
Table 13 burdens for physician office by the total number of physician
practices. Thus, we need an estimate of total number of physician
practices. Additionally, in this section, we need to

[[Page 82663]]

modify the total number of physician practices by a factor accounting
for the fact that only a percentage of physician practices accept
enrollees in the Medicaid, CHIP, and QHP programs.
We first discuss the total number of physician practices. Casalino
et al. (2009) cited that the AMA listed a figure of 560,000 physician
offices in 2006. Casalino et al. (2009) criticized this 560,000
(rounded from 560,118 physician offices exactly) based on available
sources in 2006 and reduced it to 450,000 physician offices (rounded
from 453,696 physician offices exactly). The sources cited in the
article have not been updated. Furthermore, the CY 2012 PFS final rule
redefined physician group practice to require at least 25 physicians.
As of 2016, there are 230,187 physician practices (76 FR 73026). We
note that this number is lower than the value used in the 2016 survey,
which makes sense given the high rates of consolidation in the medical
field. In Table 16 later in this section, we present an alternative
analysis of savings with 450,000 practices. We solicit public comment
on our assumptions of the number of physician offices.
(4) Percent of providers accepting Medicaid, CHIP, or QHP: The
230,187 physician practices just mentioned include providers who
exclusively service Fee For Service enrollees. We must therefore adjust
this number by the percent of providers furnishing services to
Medicaid, CHIP, and QHP enrollees. According to the Medicaid and CHIP
Payment and Access Commission (MACPAC),\90\ 71 percent of providers
accept Medicaid, but only 36 percent of psychiatrists accept new
Medicaid patients, and 62 percent accept private insurance. Therefore
we estimate that 50 percent of provider groups treat patients in the
Medicaid and QHP. Although we don't account for it, we note that these
provisions, which reduce the amount of paperwork, might encourage a
greater participation in the coming years of providers accepting
Medicaid, CHIP, and QHPs in the FFEs.
---------------------------------------------------------------------------

\90\ Kayla Holgash and Martha Heberlin, ``Physician Acceptance
of New Medicaid Patients,'' January 24, 2019 https://www.macpac.gov/wp-content/uploads/2019/01/Physician-Acceptance-of-New-Medicaid-Patients.pdf
---------------------------------------------------------------------------

(5) Assumptions on the reduction in hours spent on prior
authorization as a result of the provisions of this proposed rule:
Table 13 provides current hours spent on prior authorization; to
calculate potential savings we must make an assumption on how much
these hours are being reduced as a result of the provisions of this
rule. Therefore, we review the specific provisions of this proposed
rule.
We believe two provisions in this proposed rule would reduce prior
authorization burden:
Section II.C. of this proposed rule would require payers
to implement a DRLS API. This service, if voluntarily used by
providers, would allow them, at the point of care, to discover whether
a requested item or service requires prior authorization and, if so,
the relevant documentation requirements. All provider office staff
types, including doctors, nurses, and clerical staff, would experience
reductions in the time needed to locate prior authorization rules and
documentation requirements, which are currently either not readily
accessible or available in many different payer-specific locations and
formats. We believe that our proposal would make it possible for
provider staff to use one system (such as their EHR or practice
management system) or software application to find the prior
authorization rules and documentation requirements for all impacted
payers. With these rules and requirements more consistently and easily
accessible, we anticipate a reduction in the need for providers to make
multiple attempts at submitting the full set of information necessary
for the payer to approve or deny a prior authorization. As a
consequence, a DRLS API could also reduce appeals and improper
payments,\91\ but we are not addressing such savings here, as we have
no real-world basis on which to make an estimate. (We also note that
reduction in improper payments, though experienced as savings by
certain entities, would be categorized as transfers from a society-wide
perspective.)
---------------------------------------------------------------------------

\91\ Centers for Medicare and Medicaid Services. (2019, November
15). Simplifying Documentation Requirements. Retrieved from https://www.cms.gov/Research-Statistics-Data-and-Systems/Monitoring-Programs/Medicare-FFS-Compliance-Programs/SimplifyingRequirements.html.
---------------------------------------------------------------------------

Overall, once the APIs are in place and providers integrate with
them, we assume providers and nurses could experience a 25 percent
reduction in hours spent working to identify prior authorization rules
and requirements. (Again, we are uncertain when providers may connect
to the APIs.) The level annual 25 percent reduction reflects the belief
that these provisions would accomplish savings through reduced
administrative burden and therefore in the absence of additional data,
the 25 percent reflects a midpoint between 0 percent and 50 percent
indicating some savings (more than 0 percent but not more than 50
percent). We solicit public comment on the estimated reduction in hours
spent determining prior authorization rules and requirements due to the
DRLS API proposal in this proposed rule. We are interested in
understanding if there is burden reduction prior to the development of
an EHR integration with the API. We also note that Table 16 in this
section provides an alternative analysis using a 75 percent reduction
for doctors and nurses. The intent in Table 16 is to provide a broad
range inclusive of many possibilities (hence 25 percent to 75 percent
for providers and nurses).
Section II.C. of this proposed rule would require that
payers implement and maintain a PAS API that would, if voluntarily used
by providers, allow them, through an existing EHR or practice
management system that is capable of connecting to the API, to submit
prior authorization requests along with any associated documentation
needed, and receive an approval or denial decision from the payer,
including any ongoing communications regarding additional information
needed or other status updates. Currently, most prior authorization
requests and decisions are conducted through one of several burdensome
channels, including telephone, fax, or payer-specific web portals--each
of which require taking actions and monitoring status across multiple
and varying communication channels. Since submission support is
predominantly done by clerical staff, not by doctors or nurses, we
would estimate no savings to doctors and nurses, but a 50 percent
reduction in hours spent by clerical staff. The 50 percent reduction
represents a reasonable estimate of time spent in the absence of any
experience or data. We solicit comments on this estimated 50 percent
reduction in hours spent by clerical staff and whether our assumptions
of the affected staff type are accurate.
Having presented our assumptions on the number of providers
voluntarily using the DRLS and PAS APIs for electronic prior
authorization, the current hour and dollar burden per week spent on
prior authorization, the number of physician practices, and the
reduction in hours arising from the proposed provisions of this rule,
Tables 14 and 15 present total hours and dollars saved. Table 14
presents the savings per physician practice. Table 15 multiplies these
per physician practice savings by 50 percent of the 230,187 provider
practices to obtain aggregate savings The following illustrative
calculations help explain the entries in Table 14 and 15:

[[Page 82664]]

In Table 14, the row on nurses cites Table 13, which shows
that currently, annually, per physician practice, nurses spend 681.2
hours per year on prior authorization. Multiplying this number of hours
by our assumed savings for nurses of 25 percent, we obtain 170.3 hours
per year saved. Multiplying these reduced hours by the hourly wage for
nurses of $74.48, we obtain a savings of $12,684 per physician practice
for nurses. This calculation is repeated for all staff and then summed
to obtain the total hours and dollars saved per physician practice. We
save 347.1 hours per physician practice per year and $21,648 per
physician practice per year.
Table 15 now multiplies the 347.1 hours and $21,648 saved
per physician practice by 50 percent (percent of providers furnishing
enrollees in Medicaid, CHIP, and QHP), times 230,187 (total number of
physician practices) times the percent of providers using these
technologies by year as outlined in Table 12. For example, for the 1st
year, 2023, we multiply, $21,648 * 50 percent * 230,187 * 0.01% to
obtain a reduced dollar spending of $0.2 million. The other rows in
Table 15 are similarly calculated. As can be seen, the total savings
over 10 years is 17.2 million hours and $1.1 billion.
The savings for the first three years, obtained by summing the
first three rows, is 36,254 hours and $2.26 million. The method of
calculating the hours and dollars in these rows was just illustrated.
Because we assume a 10-year gradual increase in voluntary provider
participation, we present a 10-year horizon in Table 15 in this
section.
[GRAPHIC] [TIFF OMITTED] TP18DE20.013

[GRAPHIC] [TIFF OMITTED] TP18DE20.014

The analysis in Table 15 represents our illustrative analysis for
this proposed rule, which we put forward for stakeholder review and
comment. In Table 16, we present some alternative analysis of the
savings. Despite the wide range of alternatives, the resulting range of
savings is estimated at about $1.1 billion to about $5.2 billion. As
indicated earlier, we solicit comments from stakeholders on our
assumptions and methodology. We provide four

[[Page 82665]]

alternative assumptions as follows to the assumptions made in Tables 12
through 15:
We assumed in this section that the number of hours per
week that providers spend on prior authorization has not changed since
2006. In Table 16, we allow for an alternative with 4 percent annual
growth. This number came from several papers cited in section V. of
this proposed rule.
We assumed in this section that the reduction of hours per
week that provider teams spend on prior authorization is a result of a
25 percent reduction for doctors and nurses and a 50 percent reduction
for clerical staff. In the Table 16, we provide an alternative analysis
assuming a 75 percent reduction for doctors and nurses and a 50 percent
reduction for clerical staff. These alternative numbers are not based
on published articles or experience but rather meant to span a range of
alternatives.
In this section, we assumed 230,187 physician practices.
In Table 16, we also use an alternate assumption of 450,000 physician
practices, also discussed in this section.. We modified these numbers
by a factor of 50 percent to account for the fact that only half of
provider groups accept Medicaid, CHIP, and QHP.
For purposes of comparison we present the 10-year savings
assuming all providers participate as well as the 10-year savings from
reduced paperwork assuming a gradual increase in participation from 0
percent in the base year to 25 percent in the tenth year.
In making these assumptions, the goal was to obtain a range of
possible alternatives. We have no experience basis to justify any
particular assumption and data vary widely in the literature. As can be
seen from Table 16, the potential savings range from about $1 billion
to about $5 billion. We believe the magnitude of such a number is
important for stakeholders when evaluating and commenting on the
provisions of this rule. We solicit public comment on the four
assumptions and their impact in estimating these savings.
BILLING CODE 4120-01-P

[[Page 82666]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.015

BILLING CODE 4120-01-P

H. Summary of Costs

In this section, we present a 10-year summary table of costs, an
analysis for federal impacts, and the monetized table.
To analyze the cost of this rule to the federal government, we
utilize a method of allocating costs by program (Medicaid, CHIP, and
QHP issuers on the FFEs). As the cost is shared by the 266 parent
organizations, including Medicaid and CHIP state agencies, there is no
readily available way to allocate costs per parent organization across
programs since the percentage of each parent organization's
expenditures on the different programs is not publicly available.
To address this, we utilize the same method that was used in the
CMS Interoperability and Patient Access final rule (85 FR 25612). In
that final rule, we used the public CMS Medical Loss Ratio (MLR) files,
which break out total premiums across the various programs. The
advantages and disadvantages of such an approach are fully discussed in
that rule, to which we refer readers. At the time this proposed rule is
being written, 2019 is the latest available year with published data.
Table 17 presents the 2019 MLR data of premiums by program and the
resulting percentages by program. We use these percentages to allocate
costs by programs. This allocation of cost by program forms a basis to
calculate the federal government's cost for the proposed provisions of
this rule.

[[Page 82667]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.016

We can calculate the federal Medicaid payments using the
percentages in Table 18.
[GRAPHIC] [TIFF OMITTED] TP18DE20.017

In Table 18, the first row shows that 52 percent of federal
government payments go to the states for expenditures related to their
FFS programs and 48 percent go to states for their Medicaid managed
care programs. For state expenditures on Medicaid mechanized claims
processing and information retrieval systems, the federal government
pays states 90 percent of their expenditures on the design,
development, installation, or enhancement of such systems, and 75
percent of their expenditures on the ongoing operation of such systems.
States receive an average of 58.44 percent (FMAP) for their managed
care program costs. Therefore, the percent of costs paid in the first
year by the federal government is 74.85 percent (90 percent * 52
percent + 58.44 percent * 48 percent). The percent of costs paid in
later years is 67.05 percent (75 percent * 52 percent + 58.44 percent *
48 percent). By applying these percentages to the total Medicaid costs,
we obtain federal costs for the program. These percentages are used to
calculate the total dollars going from the federal government to
states.
We can now calculate all impacts of this proposed rule by program,
government, and QHP issuers. The numerical impacts are presented in
Table 19.

[[Page 82668]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.018

For Table 19:
Cost of Proposed Rule by Year column: The total cost for
years 2021 to 2023 matches the costs in the Collection of Information
(section V.) summary table (Table 10).
The total 10-year cost (including payers but excluding PTC payments
and savings from prior authorization) is, as shown in Table 19, $1.9
billion. This number uses the primary estimates for the API provisions.
The low and high 10-year total costs are $1.0 billion and $2.8 billion,
respectively.
Cost of Proposed Rule to Payers by Program columns: We
apply the percentages from Table 17 to obtain the cost of the rule to
Payers by program (Medicaid, CHIP, and QHP issuers on the FFEs).
Cost of Proposed Rule to Government by Program columns: We
apply the percentages of payment by the federal government discussed in
Table 18 to obtain the cost by program.
PTC Payments: The government does not reimburse QHPs,
neither partially nor totally, neither prospectively nor retroactively,
for their expenses in furnishing benefits. However, the government does
offer eligible QHP enrollees PTCs to help cover the cost of the plan.
QHP issuers on selling on the Exchanges have the option to deal with
increased costs of complying with the requirements as proposed in this
rule by either temporarily absorbing them (for purposes of market
competitiveness), increasing premiums to enrollees, or reducing non-
essential health benefits. To the extent that issuers increase premiums
for individual market plans on the FFEs, there would be federal PTC
impacts. The purpose of the PTC is to assist enrollees in paying
premiums. Since PTCs are only available if an individual purchases an
individual market plan on an Exchange and the individual has an income
between 100 and 400 percent of the Federal Poverty Level, the PTC
estimates apply only to Exchange plans. In the PTC estimate, we have
accounted for the fact that some issuers have both Exchange and non-
Exchange plans, and some issuers have only non-Exchange plans. We
reflected these assumptions with global adjustments, so we believe the
estimates are reasonable in aggregate.
The methodology to estimate the PTC impact of the of the projected
expense burdens is consistent with the method used to estimate the PTC
impact in the CMS Interoperability and Patient Access final rule (85 FR
25612). Within the FFE states, the estimated expense burden would
impact premium rates in the individual market and is spread across both
Exchange and non-Exchange plans. PTCs are only paid in the Exchanges
and are calculated as a function of the second lowest cost silver plan
and the eligible individuals' income. The estimate of these impacts
uses the assumption that the industry would increase the second lowest
cost silver plan premium rate in the same amount as the overall premium
rate increase as a result of the expense estimate. This assumption
allows application of the overall rate increase to the projected PTC
payments in the FFE states to estimate the impact to PTC payments.
There are no increases in PTC payments included for 2021 since by
the time this proposed rule is projected to be published these rates
will already have been determined. The total cost to the government is
the sum of payments related to each program. This payment is a transfer
from the government to payers for Medicaid, CHIP, and to QHP enrollees.
Remaining Cost to Payers columns: For Medicaid and CHIP,
the remaining costs are the difference between total cost to payers and
what the federal government pays. For the individual markets, the
remaining costs to payers would be the total cost absorbed by the
payers and not passed on through premium increases. Since the PTC is
paid on behalf of individuals and not the payers, it therefore does not
reduce expenses of the payers.
Note: The $1.1 billion savings from reduced paperwork
burden for use of

[[Page 82669]]

electronic prior authorization (Table 16) is not included in Table 19.
We next explain how the various plans (and states) would bear the
costs remaining after federal payments. We follow the same methodology
and discussion presented in the CMS Interoperability and Patient Access
final rule (85 FR 25612).
[GRAPHIC] [TIFF OMITTED] TP18DE20.019

In Table 20, we explain possible ways payers may manage these extra
costs. We emphasize that Table 20 lists possibilities. Payers will
ultimately make decisions about how to defray these remaining costs
based on market dynamics and internal business decisions, and we have
no uniform way of predicting what these actual behaviors and responses
will be.
Individual Market Plans: Individual market plans have the option of
absorbing costs or passing costs to enrollees either in the form of
higher premiums or reduced benefits that are not essential health
benefits (EHBs). The experience of the Office of the Actuary is that
frequently, plans, for reasons of market competitiveness, will absorb
costs rather than increase premiums or reduce benefits.
Medicaid and CHIP: Assuming roughly 75 million enrollees
nationally, including Medicaid and CHIP FFS programs, Medicaid managed
care plans and CHIP managed care entities are adding a cost of under a
dollar per beneficiary per year; this contrasts with a total cost per
beneficiary per year for the Medicaid and CHIP programs of several
thousand dollars.

I. Accounting Statement and Table

As required by OMB Circular A-4 (available at https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/circulars/A4/a-4.pdf), we have prepared an accounting statement in Table 21 showing
the classification of annualized costs associated with the provisions
of this proposed rule for the 10-year period 2021 through 2030. This
accounting table is based on Table 19. It includes costs of this
proposed rule to providers, Medicaid and CHIP state entities, and
issuers offering QHPs on the FFEs. It does not include the potential
savings (Tables 14 and 15) of at least $1.1 billion arising from
reduced burden due to providers voluntarily complying with electronic
prior authorization as discussed in the illustrative earlier in this
section.

[[Page 82670]]

[GRAPHIC] [TIFF OMITTED] TP18DE20.020

J. Regulatory Reform Analysis Under E.O. 13771

Executive Order 13771, titled Reducing Regulation and Controlling
Regulatory Costs, was issued on January 30, 2017 and requires that the
costs associated with significant new regulations ``shall, to the
extent permitted by law, be offset by the elimination of existing costs
associated with at least two prior regulations.'' This proposed rule,
if finalized, is considered an E.O. 13771 regulatory action. We
estimate that the medium (primary) estimates of this proposed rule
would generate annual costs of $136.3 million in 2016 dollars when
calculated at a 7 percent discount over a perpetual time horizon. (The
low estimates would generate $70.6 million in annualized costs, while
the high estimates would generate $202.1 million in annualized costs,
discounted at 7 percent relative to 2016, over a perpetual time
horizon.) Details on the estimated costs of this proposed rule can be
found in the preceding analyses.
In accordance with the provisions of Executive Order 12866, this
regulation was reviewed by the Office of Management and Budget (OMB).

List of Subjects

42 CFR Part 431

Grant programs-health, Health facilities, Medicaid, Privacy,
Reporting and recordkeeping requirements, State fair hearings.

42 CFR Part 435

Aid to Families with Dependent Children, Grant programs-health,
Medicaid, Notices, Reporting and recordkeeping requirements,
Supplemental Security Income (SSI), Wages.

42 CFR Part 438

Grant programs-health, Medicaid, Reporting and recordkeeping
requirements.

42 CFR Part 440

Grant programs-health, Medicaid.

42 CFR Part 457

Administrative practice and procedure, Grant programs-health,
Health insurance, Reporting and recordkeeping requirements.

45 CFR Part 156

Administrative practice and procedure, Advertising, Brokers,
Conflict of interests, Consumer protection, Grant programs-health,
Grants administration, Health care, Health insurance, Health
maintenance organizations (HMO), Health records, Hospitals, Indians,
Individuals with disabilities, Intergovernmental relations, Loan
programs-health, Medicaid, Organization and functions (Government
agencies), Prescription drugs, Public assistance programs, Reporting
and recordkeeping requirements, Technical assistance, Women, Youth.

45 CFR Part 170

Computer technology, Health, Health care, Health insurance, Health
records, Hospitals, Indians, Incorporation by reference, Laboratories,
Medicaid, Medicare, Privacy, Public health, Reporting and recordkeeping
requirements, Security measures.

For the reasons set forth in the preamble, the Centers for Medicare
& Medicaid Services (CMS) proposes to amend 42 CFR chapter IV as set
forth below:

PART 431--STATE ORGANIZATION AND GENERAL ADMINISTRATION

0
1. The authority citation for part 431 continues to read as follows:

Authority: 42 U.S.C. 1302.

0
2. Section 431.60 is amended by--
0
a. Revising paragraph (b)(3);
0
b. Adding paragraph (b)(5);
0
c. Revising paragraph (c)(3) introductory text;
0
d. Adding paragraph (c)(3)(iii);
0
e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and
(e)(2);
0
f. Redesignating paragraph (g) as paragraph (i); and
0
g. Adding new paragraphs (g) and (h).

[[Page 82671]]

The revisions and addition read as follows:

Sec. 431.60 Beneficiary access to and exchange of data

* * * * *
(b) * * *
(3) Clinical data, as defined in the USCDI version 1, if the State
maintains any such data, no later than 1 business day after the data
are received by the State;
* * * * *
(5) Beginning January 1, 2023, pending and active prior
authorization decisions and related clinical documentation and forms
for items and services, not including covered outpatient drugs,
including the date the prior authorization was approved, the date the
authorization ends, as well as the units and services approved and
those used to date, no later than 1 business day after a provider
initiates a prior authorization request for the beneficiary or there is
a change of status for the prior authorization.
(c) * * *
(3) Must comply with the content and vocabulary standards
requirements in paragraphs (c)(3)(i) and (ii) of this section, as
applicable to the data type or data element, unless alternate standards
are required by other applicable law, and be conformant with the
requirements in paragraph (c)(3)(iii) of this section:
* * * * *
(iii) Beginning January 1, 2023, be conformant with the
implementation specifications at 45 CFR 170.215(c)(5) for data
specified in paragraphs (b)(1) and (2), 45 CFR 170.215(a)(2) or 45 CFR
170.215(c)(6) for data specified in paragraph (b)(3) of this section,
45 CFR 170.215(c)(7) for data specified in paragraph (b)(4) of this
section, and 45 CFR 170.215(c)(6) for data specified in paragraph
(b)(5) of this section.
(4) May use an updated version of any standard or all standards and
any or all implementation guides or specifications required under
paragraphs (b) or (c) of this section, and Sec. Sec. 431.61, 431.70,
431.80, where:
* * * * *
(ii) * * *
(C) Use of the updated version of the standard, implementation
guide, or specification does not disrupt an end user's ability to
access the data described in paragraph (b) of this section or the data
described in Sec. Sec. 431.61, 431.70, and 431.80 through the required
API.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all applications and
developers through which parties seek to access electronic health
information, as defined at 45 CFR 171.102, including but not limited to
criteria that may rely on automated monitoring and risk mitigation
tools.
* * * * *
(g) Privacy policy attestation. (1) Beginning January 1, 2023, the
State must establish, implement, and maintain a process for requesting
an attestation from a third-party app developer requesting to retrieve
data via the Patient Access API that indicates the app adheres to
certain privacy provisions. The State must:
(i) Independently, or through the support of a third party, request
a third-party app developer to attest whether:
(A) The app has a privacy policy that is publicly available and
accessible at all times, including updated versions, and that is
written in plain language, and that the third-party app has
affirmatively shared with the beneficiary prior to the beneficiary
authorizing the app to access their health information. To
``affirmatively share'' means that the beneficiary had to take an
action to indicate they saw the privacy policy, such as click or check
a box or boxes.
(B) The app's privacy policy includes, at a minimum:
(1) How a beneficiary's health information may be accessed,
exchanged, or used by any person or other entity, including whether the
beneficiary's health information may be shared or sold at any time
(including in the future);
(2) A requirement for express consent from a beneficiary before the
beneficiary's health information is accessed, exchanged, or used,
including receiving express consent before a beneficiary's health
information is shared or sold (other than disclosures required by law
or disclosures necessary in connection with the sale of the application
or a similar transaction);
(3) If an app will access any other information from a
beneficiary's device; and
(4) How a beneficiary can discontinue app access to their data and
what the app's policy and process is for disposing of a beneficiary's
data once the beneficiary has withdrawn consent.
(ii) Include information in the beneficiary resources required in
paragraph (f) of this section about the specific content of the State's
privacy policy attestation required under this paragraph, and, at a
minimum, the timeline for the attestation process, the method for
informing the beneficiary about the app developer's response or non-
response to the State's request, and the beneficiary's role and rights
in this process; and
(iii) Request the attestation at the time the third-party app
engages the API and notify the beneficiary as follows:
(A) The State must inform the beneficiary within 24 hours of
requesting the attestation from the third-party app developer regarding
the status of the attestation--positive, negative, or no response, with
a clear explanation of what each means;
(B) If a beneficiary does not respond within 24 hours of when the
State sends notice of the attestation status to the beneficiary, the
State must proceed with making the beneficiary's data available to the
third-party app consistent with the beneficiary's original request.
(2) The State must not discriminate when implementing this
requirement, including for the purposes of competitive advantage; the
method employed to meet this requirement must be applied equitably
across all apps requesting access the Patient Access API.
(h) Reporting on the use of the Patient Access API. (1) Beginning
March 31, 2023, a State must report to CMS, at the State agency level,
by the end of each calendar quarter, based on the previous quarter's
data as follows:
(i) The total number of unique beneficiaries whose data are
transferred via the Patient Access API to a beneficiary-designated
third-party application; and
(ii) The number of unique beneficiaries whose data are transferred
via the Patient Access API to a beneficiary designated third-party
application more than once.
(2) [Reserved].
* * * * *
0
3. Section 431.61 is added to read as follows:

Sec. 431.61 Access to and exchange of health data to providers and
payers.

[[Page 82672]]

after January 1, 2016, within one (1) business day of receipt,
conformant with the implementation specifications at 45 CFR
170.215(c)(5) for data specified at Sec. 431.60(b)(1) and (2) not
including remittances and enrollee cost sharing information, 45 CFR
170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified at Sec.
431.60(b)(3), 45 CFR 170.215(c)(7) for data specified at Sec.
431.60(b)(4), and 45 CFR 170.215(c)(6) for data specified at Sec.
431.60(b)(5); and
(ii) Bulk data access. The Provider Access API must be able to
share the data specified in paragraph (a)(1)(i) of this section
conformant with the implementation specification at 45 CFR
170.215(a)(4) to facilitate sharing the specified data relevant to one
or more beneficiary at one time.
(2) Attribution. A State must establish, implement, and maintain a
process to facilitate generating each provider's current beneficiary
roster to enable this payer-to-provider data sharing via the Provider
Access API.
(3) Opt-in. A State may put a process in place to allow a
beneficiary or the beneficiary's personal representative to opt-in to
permit the State's use of the Provider Access API for sharing with each
of the beneficiary's provider(s) currently providing care, or planning
to provide care, the data specified in paragraph (a)(1) of this
section.
(4) Provider resources regarding APIs. A State must provide on its
website and through other appropriate mechanisms through which it
ordinarily communicates with providers, educational resources in non-
technical, simple, and easy-to-understand language explaining general
information concerning how a provider may make a request to the State
for beneficiary data using the standards-based Provider Access API
required under paragraph (a)(1) of this section, both for individual
access and bulk data requests.
(5) Out-of-network provider access. A State cannot deny use of, or
access to, the Provider Access API based on a provider's contract
status.
(b) Coordination among payers--Payer-to-Payer Data Exchange. (1)
Beginning January 1, 2023, a State must implement and maintain a
standards-based API compliant with Sec. 431.60(c), (d), and (e) that
makes available to another payer, at a minimum, the data maintained by
the state with a date of service on or after January 1, 2016, within
one (1) business day of receipt, conformant with the implementation
specifications at 45 CFR 170.215(c)(5) for data specified at Sec.
431.60(b)(1) and (2) not including remittances and enrollee cost
sharing information, 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for
data specified at Sec. 431.60(b)(3), 45 CFR 170.215(c)(7) for data
specified at Sec. 431.60(b)(4), and 45 CFR 170.215(c)(6) for data
specified at Sec. 431.60(b)(5). Such information received by a State
must be incorporated into the State's records about the current
beneficiary.
(2) With the approval and at the direction of a current or former
beneficiary or the beneficiary's personal representative, the State
must:
(i) Receive all such data for a current beneficiary from any other
payer that has provided coverage to the beneficiary within the
preceding 5 years;
(ii) At any time a beneficiary is currently enrolled with the State
and up to 5 years after disenrollment, send all such data to any other
payer that currently covers the beneficiary or to a payer the
beneficiary or the beneficiary's personal representative specifically
requests receive the data; and
(iii) Send data received from another payer under this paragraph in
the electronic form and format it was received.
(c) Coordination among payers at enrollment--Payer-to-Payer API.
(1) Accessible content and API requirements. Beginning January 1, 2023,
a State must make the standards-based API specified in paragraph (b)(1)
of this section conformant with the implementation specification at 45
CFR 170.215(a)(4) to facilitate sharing the data specified in paragraph
(b)(1) of this section relevant to one or more beneficiaries at one
time.
(2) Requesting data exchange. (i) When a beneficiary enrolls in
coverage with the State, the State may request the data from a previous
payer through the standards-based API described in paragraph (c)(1) of
this section, as permitted by the beneficiary per paragraph (c)(5) of
this section, and as permitted by applicable law;
(ii) For any beneficiaries who enroll with the State during the
first calendar quarter of each year, the State must request the
specified data within one (1) week of the end of the first calendar
quarter from any previous payers through the standards-based API
described in paragraph (c)(1) of this section, as permitted by the
beneficiary per paragraph (c)(5) of this section, and as permitted by
applicable law;
(iii) If a State receives a request from another payer to make data
available for one or more former beneficiaries who have enrolled with
the new payer, the State must respond by making the required data
available via the standards-based API described in paragraph (c)(1) of
this section within one (1) business day of receiving the request.
(3) Previous or concurrent payer. A State must adopt a process to
obtain from a new beneficiary the name of the new beneficiary's
previous payer as part of the enrollment process, and the name of the
new beneficiary's concurrent payer or payers if the beneficiary has
coverage through more than one payer, to facilitate data sharing using
the Payer-to-Payer API described in paragraph (c)(1) of this section.
(4) Concurrent payer exchange. When a beneficiary has concurrent
coverage with another payer also subject to CMS regulations on the
Payer-to-Payer API, the State must make available to the other payer
the data described in paragraph (b)(1) of this section through the
standards-based API described in paragraph (c)(1) of this section
quarterly.
(5) Opt-in. A State must put a process in place to allow a
beneficiary or the beneficiary's personal representative to opt-in to
permit the State's use of the Payer-to-Payer API data sharing specified
in paragraph (c)(1) of this section.
(d) Obligations. The requirements under this section do not in any
way alter or change a State's obligation as a HIPAA covered entity to
comply with regulations regarding standard transactions at 45 CFR part
162.
(e) Extensions and Exemptions. (1) Extension. (i) A State may
submit a written application to request to delay implementation of the
requirements in paragraphs (a) through (c) of this section one-time for
up to one (1) year with respect to its Medicaid fee-for-service
program. The written application must be submitted and approved as part
of the State's annual Advance Planning Document for MMIS operations
costs and must include:
(A) A narrative justification describing the specific reasons why
the State cannot reasonably satisfy the requirement(s) by the
compliance date and explaining why those reasons result from
circumstances that are unique to States operating Medicaid fee-for
service programs;
(B) A report on completed and ongoing State implementation
activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no
later than 1 year after the initial compliance date.
(ii) CMS will grant the State's request if it determines based on
the information provided in the State's annual Advance Planning
Document for MMIS operations costs that the request

[[Page 82673]]

adequately establishes a need to delay implementation, that this need
results from circumstances that are unique to States operating Medicaid
fee-for-service programs, that the State has made a good faith effort
to implement the proposed requirements as soon as possible, and that
the State has a clear plan to implement the requirements no later than
one (1) year after the proposed compliance date.
(2) Exemption. (i) A State operating a Medicaid program under which
at least 90 percent of all covered items and services are provided to
Medicaid beneficiaries through Medicaid managed care contracts with
MCOs, PIHPs, or PAHPs, rather than through a fee-for-service delivery
system, or under which at least 90 percent of the State's Medicaid
beneficiaries are enrolled in Medicaid managed care organizations as
defined in Sec. 438.2, may request that its fee-for-service program be
exempted from the requirement(s) in paragraphs (a) through (c) of this
section.
(A) A state may submit an exemption request once per calendar year
for a one (1) year exemption.
(B) The annual request must be submitted as part of a state's
annual Advance Planning Document for MMIS operations costs.
(C) The State's request must include documentation that the State
meets the criteria for the exemption, using data from any one of the
three most recent and complete calendar years prior to the date the
exemption request is made.
(ii) CMS will grant the exemption for a one-year period if the
State establishes to CMS's satisfaction that the State meets the
criteria for the exemption and has established a plan to ensure there
will be efficient electronic access to the same information through
alternative means.
0
4. Section 431.70 is amended by adding paragraph (d) to read as
follows:

Sec. 431.70 Access to published provider directory information.

* * * * *
(d) Beginning January 1, 2023, the Provider Directory API must be
conformant with the implementation specification at 45 CFR
170.215(c)(8).
0
5. Section 431.80 is added to subpart B to read as follows:

Sec. 431.80 Documentation and prior authorization.

(a) Requirements to support provider documentation discovery and to
support prior authorization. At a minimum:
(1) Documentation Requirement Lookup Service (DRLS) Application
Programming Interface (API). Beginning January 1, 2023, a State must
implement and maintain a standards-based API compliant with Sec.
431.60(c), (d), and (e):
(i) That is populated with the State's list of covered items and
services, not including covered outpatient drugs, for which prior
authorization is required, and with the State's documentation
requirements for submitting a prior authorization request, including a
description of the required documentation; and
(ii) That is conformant with the implementation specifications at
45 CFR 170.215(c)(1) and (2).
(2) Prior Authorization Support API. Beginning January 1, 2023, a
State must implement and maintain a standards-based API compliant with
Sec. 431.60(c), (d), and (e):
(i) That facilitates a HIPAA-compliant prior authorization request
and response, including any forms or medical record documentation
required by the State for the items or services for which the provider
is seeking prior authorization;
(ii) That is conformant with the implementation specification at 45
CFR 170.215(c)(3); and
(iii) That includes in the response whether the State approves (and
for how long), denies, or requests more information related to the
prior authorization request, along with a standard denial reason code
in the case of denial;
(iv) A State must include a specific reason for a denial in the
case of a denial with all prior authorization decisions, regardless of
the method used to send the prior authorization decision.
(b) Extensions and Exemptions. (1) Extension. (i) A State may
submit a written application to request to delay implementation of the
requirements in paragraphs (a)(1) and (2) of this section one-time for
up to one (1) year with respect to its Medicaid fee-for-service
program. The written application must be submitted and approved as part
of the State's annual Advance Planning Document for MMIS operations
costs and must include:
(A) A narrative justification describing the specific reasons why
the State cannot reasonably satisfy the requirement(s) by the
compliance date and explaining why those reasons result from
circumstances that are unique to States operating Medicaid fee-for
service programs;
(B) A report on completed and ongoing State implementation
activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no
later than 1 year after the initial compliance date.
(ii) CMS will grant the State's request if it determines based on
the information provided in the State's annual Advance Planning
Document for MMIS operations costs that the request adequately
establishes a need to delay implementation, that this need results from
circumstances that are unique to States operating Medicaid fee-for-
service programs, that the State has made a good faith effort to
implement the proposed requirements as soon as possible, and that the
State has a clear plan to implement the requirements no later than one
(1) year after the proposed compliance date.
(2) Exemption. (i) A State operating a Medicaid program under which
at least 90 percent of all covered items and services are provided to
Medicaid beneficiaries through Medicaid managed care contracts with
MCOs, PIHPs, or PAHPs, rather than through a fee-for-service delivery
system, or under which at least 90 percent of the State's Medicaid
beneficiaries are enrolled in Medicaid managed care organizations as
defined in Sec. 438.2, may request that its fee-for-service program be
exempted from the requirement(s) in paragraphs (a)(1) and (2) of this
section.
(A) A state may submit an exemption request once per calendar year
for a one (1) year exemption.
(B) The annual request must be submitted as part of a state's
annual Advance Planning Document for MMIS operations costs.
(C) The State's request must include documentation that the State
meets the criteria for the exemption, using data from any one of the
three most recent and complete calendar years prior to the date the
exemption request is made.
(ii) CMS will grant the exemption for a one-year period if the
State establishes to CMS's satisfaction that the State meets the
criteria for the exemption and has established a plan to ensure there
will be efficient electronic access to the same information through
alternative means.
0
6. Section 431.201 is amended by revising the definition of ``Action''
to read as follows:

Sec. 431.201 Definitions.

* * * * *
Action means:
(1) A termination, suspension of, or reduction in covered benefits
or services, including benefits or services for which there is a
current approved prior authorization;
(2) A termination, suspension of, or reduction in Medicaid
eligibility, or an increase in beneficiary liability, including a
determination that a beneficiary must incur a greater amount

[[Page 82674]]

of medical expenses in order to establish income eligibility in
accordance with Sec. 435.121(e)(4) or Sec. 435.831 of this chapter;
(3) A determination that a beneficiary is subject to an increase in
premiums or cost-sharing charges under subpart A of part 447 of this
chapter; or
(4) A determination by a skilled nursing facility or nursing
facility to transfer or discharge a resident and an adverse
determination by a State with regard to the preadmission screening and
resident review requirements of section 1919(e)(7) of the Act.
* * * * *
0
7. Section 431.220 is amended--
0
a. In paragraph (a)(1)(iv) by removing the term ``or'' from the end of
the paragraph;
0
b. In paragraph (a)(1)(v) by removing ``.'' from the end of the
paragraph and adding in its place ``; or''; and
0
c. By adding paragraph (a)(1)(vi).
The addition reads as follows:

Sec. 431.220 When a hearing is required.

(a) * * *
(1) * * *
(vi) A prior authorization decision.
* * * * *

PART 435--STATE ORGANIZATION AND GENERAL ADMINISTRATION

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

Authority: 42 U.S.C. 1302.

0
9. Section 435.917 is amended by:
0
a. Revising the paragraph headings of paragraphs (a) and (b); and
0
b. Revising paragraph (b)(2).
The revisions read as follows:

Sec. 435.917 Notice of agency's decision concerning eligibility,
benefits, or services.

(a) Notice of determinations. * * *
* * * * *
(b) Content of notice. * * *
* * * * *
(2) Notice of adverse action including denial, termination or
suspension of eligibility or change in benefits or services. Any notice
of denial, termination or suspension of Medicaid eligibility or, in the
case of beneficiaries receiving medical assistance, denial of or change
in benefits or services must be consistent with Sec. 431.210 of this
chapter.
* * * * *

PART 438--MANAGED CARE

0
10. The authority citation for part 438 continues to read as follows:

Authority: 42 U.S.C. 1302.
0
11. Section 438.9 is amended by revising paragraph (b)(7) to read as
follows:

Sec. 438.9 Provisions that apply to non-emergency medical
transportation PAHPs.

* * * * *
(b) * * *
(7) The PAHP standards in Sec. Sec. 438.206(b)(1), 438.210,
438.214, 438.224, 438.230, and 438.242, excluding the requirement in
Sec. 438.242(b)(7) to comply with Sec. 431.61(a) and (c) of this
chapter.
* * * * *
0
12. Section 438.62 is amended by revising paragraph (b)(1)(vii)(A)
introductory text to read as follows:

Sec. 438.62 Continued services to enrollees.

* * * * *
(b) * * *
(1) * * *
(vii) * * *
(A) The MCO, PIHP, or PAHP must comply with the requirements in
paragraph (b)(1)(vi) of this section beginning January 1, 2022 until
the start of the rating period beginning on or after January 1, 2023
with regard to data:
* * * * *
0
13. Section 438.210 is amended by--
0
a. Revising paragraph (d)(1); and
0
b. Adding paragraph (g).
The addition and revision read as follows:

Sec. 438.210 Coverage and authorization of services.

* * * * *
(d) * * *
(1) Standard authorization decisions. For standard authorization
decisions, provide notice as expeditiously as the enrollee's condition
requires and within State-established timeframes that may not exceed 14
calendar days following receipt of the request for service, with a
possible extension of up to 14 additional calendar days, and for
standard authorization decisions made beginning with the rating period
on or after January 1, 2023, may not exceed 7 calendar days following
receipt of the request for service, with a possible extension of up to
14 additional calendar days if--
* * * * *
(g) Public reporting of prior authorization metrics. Beginning
March 31, 2023, the MCO, PIHP, or PAHP must make the following
information about plan level prior authorization publicly accessible by
posting directly on its website or via publicly accessible
hyperlink(s), annually by the end of the first calendar quarter, data,
for the prior rating period:
(1) A list of all items and services, not including covered
outpatient drugs, that require prior authorization;
(2) The percentage of standard prior authorization requests that
were approved, reported separately for items and services, not
including covered outpatient drugs;
(3) The percentage of standard prior authorization requests that
were denied, reported separately for items and services, not including
covered outpatient drugs;
(4) The percentage of standard prior authorization requests that
were approved after appeal, reported separately for items and services,
not including covered outpatient drugs;
(5) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
reported separately for items and services, not including covered
outpatient drugs;
(6) The percentage of expedited prior authorization requests that
were approved, reported separately for items and services, not
including covered outpatient drugs; and
(7) The average and median time that elapsed between the submission
of a request and a determination by the MA organization, for standard
prior authorizations, reported separately for items and services, not
including covered outpatient drugs.
0
14. Section 438.242 is amended by--
0
a. Revising paragraphs (b)(5) introductory text;
0
b. Adding paragraph (b)(5)(ii);
0
c. Revising paragraph (b)(6); and
0
b. Adding paragraphs (b)(7) and (8).
The revisions and additions read as follows:

Sec. 438.242 Health information systems.

* * * * *
(b) * * *
(5) Subject to paragraph (b)(8) of this section, implement a
Patient Access Application Programming Interface (API) as specified in
Sec. 431.60 of this chapter as if such requirements applied directly
to the MCO, PIHP, or PAHP and include:
* * * * *
(ii) Reporting metrics specified at Sec. 431.60(h) of this chapter
at the plan level.
(6) Except for Sec. 431.70(d) of this chapter implement, by
January 1, 2021, and maintain a publicly accessible standard-based
Provider Directory API described at Sec. 431.70 of this chapter, which
must include all information specified at Sec. 438.10(h)(1) and (2) of
this chapter. The State must require, at a minimum, that each MCO,
PIHP, and PAHP comply with Sec. 431.70(d) by the rating period
beginning on or after January 1, 2023.
(7) By the rating period beginning on or after January 1, 2023,
comply with Sec. 431.61(a) through (d) and Sec. 431.80(a)

[[Page 82675]]

of this chapter as if such requirements applied directly to the MCO,
PIHP, or PAHP.
(8) The following timeframes apply to paragraph (b)(5) of this
section:
(i) Except for the requirements at Sec. Sec. 431.60(b)(5),
431.60(c)(3)(iii), 431.60(g), and 431.60(h) of this chapter, comply
with the by the requirements of Sec. 431.60 of this chapter by January
1, 2021.
(ii) Comply with the requirements at Sec. Sec. 431.60(b)(5),
431.60(c)(3)(iii), and 431.60(g) of this chapter by the rating period
beginning on or after January 1, 2023.
(iii) Comply with the reporting requirements at Sec. 431.60(h) of
this chapter beginning with the end of the first full quarter of the
rating period beginning on or after January 1, 2023 based on the
previous quarter's data.
* * * * *

PART 440--SERVICES: GENERAL PROVISIONS

0
15. The authority citation for part 440 continues to read as follows:

Authority: 42 U.S.C. 1302.

0
16. Section 440.230 is amended by adding paragraphs (d)(1) and (2) to
read as follows:

Sec. 440.230 Sufficiency of amount, duration, and scope.

* * * * *
(d) * * *
(1) Prior authorization decision timeframes. The State Medicaid
agency must--
(i) Beginning January 1, 2023, provide notice of prior
authorization decisions for items and services, not including covered
outpatient drugs, as expeditiously as a beneficiary's health condition
requires and under any circumstances not later than 72 hours of
receiving a request for an expedited determination and not later than 7
calendar days for standard requests. The timeframe for authorization
decisions could be extended by up to 14 calendar days for standard
requests if the beneficiary or provider requests an extension, or if
the state agency or its authorized representative determines that
additional information from the provider is needed to make a decision.
(ii) Provide the beneficiary with notice of the agency's prior
authorization decision and fair hearing rights in accordance with Sec.
435.917 and part 431, subpart E of this chapter.
(2) Public reporting of prior authorization metrics. Beginning
March 31, 2023, the State Medicaid agency must make the following
information about State agency level prior authorization decisions
publicly accessible by posting directly on its website or via publicly
accessible hyperlink(s), annually by the end of the first calendar
quarter, data for the prior calendar year:
(i) A list of all items and services, not including covered
outpatient drugs, that require prior authorization;
(ii) The percentage of standard prior authorization requests that
were approved, reported separately for items and services, not
including covered outpatient drugs;
(iii) The percentage of standard prior authorization requests that
were denied, reported separately for items and services, not including
covered outpatient drugs;
(iv) The percentage of standard prior authorization requests that
were approved after appeal, reported separately for items and services,
not including covered outpatient drugs;
(v) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
reported separately for items and services, not including covered
outpatient drugs;
(vi) The percentage of expedited prior authorization requests that
were approved, reported separately for items and services, not
including covered outpatient drugs; and
(vii) The average and median time that elapsed between the
submission of a request and a determination by the state Medicaid
agency, for standard prior authorizations, reported separately for
items and services, not including covered outpatient drugs.

PART 457--ALLOTMENTS AND GRANTS TO STATES

0
17. The authority citation for part 457 continues to read as follows:

Authority: 42 U.S.C. 1302.
0
18. Section 457.495 is amended by revising paragraph (d) to read as
follows:

Sec. 457.495 State assurance of access to care and procedures to
assure quality and appropriateness of care.

* * * * *
(d) Decisions related to the prior authorization of health
services. (1) That decisions related to the prior authorization of
health services are completed in accordance with the medical needs of
the patient, but no later than 7 calendar days after the date of
receipt of the request for a standard determination and by no later
than 72 hours after the date of receipt of the request for an expedited
determination. A possible extension of up to 14 days may be permitted
if the enrollee requests the extension or if the physician or health
plan determines the additional information is needed.
(2) Reserved.
0
19. Section 457.700 is amended by revising paragraph (c) to read as
follows:

Sec. 457.700 Basis, scope, and applicability.

* * * * *
(c) Applicability. The requirements of this subpart apply to
separate child health programs and Medicaid expansion programs, except
that Sec. Sec. 457.730, 457.731, and 457.732 do not apply to Medicaid
expansion programs. Separate child health programs that provide
benefits exclusively through managed care organizations may meet the
requirements of Sec. Sec. 457.730, 457.731, and 457.732 by requiring
the managed care organizations to meet the requirements of Sec.
457.1233(d)(2).
0
20. Section 457.730 is amended by--
0
a. Revising paragraphs (b)(3);
0
b. Adding paragraph (b)(5);
0
c. Revising paragraph (c)(3) introductory text;
0
d. Adding paragraph (c)(3)(iii);
0
e. Revising paragraphs (c)(4) introductory text, (c)(4)(ii)(C), and
(e)(2);
0
f. Redesignating paragraph (g) as paragraph (i); and
0
g. Adding new paragraphs (g) and (h).
The revisions and additions read as follows:

Sec. 457.730 Beneficiary access to and exchange of data.

[[Page 82676]]

requirements in paragraphs (c)(3)(iii) of this section:
* * * * *
(iii) Beginning January 1, 2023, be conformant with the
implementation specifications at 45 CFR 170.215(c)(5) for data
specified in paragraphs (b)(1) and (2) of this section, 45 CFR
170.215(a)(2) or 45 CFR 170.215(c)(6) for data specified in paragraph
(b)(3), 45 CFR 170.215(c)(7) for data specified in (b)(4), and 45 CFR
170.215(c)(6) for data specified in paragraph (b)(5) of this section.
(4) May use an updated version of any standard or all standards and
any or all implementation guides or specifications required under
paragraphs (b) or (c) of this section, Sec. Sec. 457.731, 457.732, and
457.760, where:
* * * * *
(ii) * * *
(C) Use of the updated version of the standard, implementation
guide, or specification does not disrupt an end user's ability to
access the data described in paragraph (b) of this section, or the data
described in Sec. Sec. 457.731, 457.732, and 457.760 of this chapter
through the required API.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all applications and
developers through which parties seek to access electronic health
information, as defined at 45 CFR 171.102, including but not limited to
criteria that may rely on automated monitoring and risk mitigation
tools.
* * * * *
(g) Privacy policy attestation. (1) Beginning January 1, 2023, the
State must establish, implement, and maintain a process for requesting
an attestation from a third-party app developer requesting to retrieve
data via the Patient Access API that indicates the app adheres to
certain privacy provisions. The State must:
(i) Independently, or through the support of a third party, request
a third-party app developer to attest whether:
(A) The app has a privacy policy that is publicly available and
accessible at all times, including updated versions, and that is
written in plain language, and that the third-party app has
affirmatively shared with the beneficiary prior to the beneficiary
authorizing app access to their health information. To ``affirmatively
share'' means that the beneficiary had to take an action to indicate
they saw the privacy policy, such as click or check a box or boxes.
(B) The app's privacy policy includes, at a minimum:
(1) How a beneficiary's health information may be accessed,
exchanged, or used by any person or other entity, including whether the
beneficiary's health information may be shared or sold at any time
(including in the future);
(2) A requirement for express consent from a beneficiary before the
beneficiary's health information is accessed, exchanged, or used,
including receiving express consent before a beneficiary's health
information is shared or sold (other than disclosures required by law
or disclosures necessary in connection with the sale of the application
or a similar transaction);
(3) If an app will access any other information from a
beneficiary's device; and
(4) How a beneficiary can discontinue app access to their data and
what the app's policy and process is for disposing of a beneficiary's
data once the beneficiary has withdrawn consent.
(ii) Include information in the beneficiary resources required in
paragraph (f) of this section about the specific content of the State's
privacy policy attestation required under this paragraph, and, at a
minimum, the timeline for the attestation process, the method for
informing beneficiary about the app developer's response or non-
response to the State's request, and the beneficiary's role and rights
in this process; and
(iii) Request the attestation at the time the third-party app
engages the API and notify the beneficiary as follows:
(A) The State must inform the beneficiary within 24 hours of
requesting the attestation from the third-party app developer regarding
the status of the attestation--positive, negative, or no response, with
a clear explanation of what each means;
(B) If a beneficiary does not respond within 24 hours of when the
State sends notice of the attestation status to the beneficiary, the
State must proceed with making the beneficiary's data available to the
third-party app consistent with the beneficiary's original request.
(2) The State must not discriminate when implementing this
requirement, including for the purposes of competitive advantage; the
method employed to meet this requirement must be applied equitably
across all apps requesting access to the Patient Access API.
(h) Reporting on the use of the Patient Access API. (1) Beginning
March 31, 2023, a State must report to CMS, at the State agency level,
by the end of each calendar quarter, based on the previous quarter's
data as follows:
(i) The total number of unique beneficiaries whose data are
transferred via the Patient Access API to a beneficiary-designated
third-party application; and
(ii) The number of unique beneficiaries whose data are transferred
via the Patient Access API to a beneficiary-designated third-party
application more than once.
(2) [Reserved].
* * * * *
0
21. Section 457.731 is added to subpart G to read as follows:

Sec. 457.731 Access to and exchange of health data to providers and
payers.

(a) Application Programming Interface to support data transfer from
payers to providers--Provider Access API.--(1) Accessible content and
API requirements. Beginning January 1, 2023, a State must implement and
maintain a standards-based Application Programming Interface (API)
compliant with Sec. 457.730(c), (d), and (e):
(i) Individual beneficiary data. The Provider Access API must make
available to providers, if requested by the provider, as permitted by
the beneficiary per paragraph (a)(3) of this section, and as permitted
by applicable law, at a minimum, data maintained by the State with a
date of service on or after January 1, 2016, within one (1) business
day of receipt, conformant with the implementation specifications at 45
CFR 170.215(c)(5) for data specified at Sec. 431.60(b)(1) and (2) of
this chapter, not including remittances and enrollee cost sharing
information, 45 CFR 170.215(a)(2) or 45 CFR 170.215(c)(6) for data
specified at Sec. 431.60(b)(3) of this chapter, 45 CFR 170.215(c)(7)
for data specified at Sec. 431.60(b)(4), and 45 CFR 170.215(c)(6) for
data specified at Sec. 431.60(b)(5) of this chapter; and
(ii) Bulk data access. The Provider Access API must be able to
share the data specified in (a)(1)(i) of this section conformant with
the implementation specification at 45 CFR 170.215(a)(4) to facilitate
sharing the specified data relevant to one or more beneficiaries at one
time.
(2) Attribution. A State must establish, implement, and maintain a
process to facilitate generating each provider's current beneficiary
roster to enable this payer-to-provider data sharing via the Provider
Access API;
(3) Opt-in. A State may put a process in place to allow a
beneficiary or the beneficiary's personal representatives to opt-in to
permit the State's use of the Provider Access API for sharing with

[[Page 82677]]

the each of the beneficiary's provider(s) currently providing care, or
planning to provide care, the data specified in paragraph (a)(1) of
this section.
(4) Provider resources regarding APIs. A State must provide on its
website and through other appropriate mechanisms through which it
ordinarily communicates with providers, educational resources in non-
technical, simple and easy-to-understand language explaining general
information concerning how a provider may make a request to the State
for beneficiary data using the standards-based Provider Access API
required under paragraph (a)(1) of this section, both for individual
access and bulk data requests.
(5) Out-of-network provider access. A State cannot deny use of, or
access to, the Provider Access API based on a provider's contract
status.
(b) Coordination among payers--Payer-to-Payer Data Exchange. (1)
Beginning January 1, 2023, a State must implement and maintain a
standards-based API compliant with Sec. 457.730(c), (d), and (e) that
makes available to another payer, at a minimum, the data maintained by
the State with a date of service on or after January 1, 2016, within
one (1) business day of receipt, conformant with the implementation
specifications at 45 CFR 170.215(c)(5) for data specified at Sec.
431.60(b)(1) and (2) of this chapter not including remittances and
enrollee cost sharing information, 45 CFR 170.215(a)(2) or 45 CFR
170.215(c)(6) for data specified at Sec. 431.60(b)(3) of this chapter,
45 CFR 170.215(c)(7) for data specified at Sec. 431.60(b)(4) of this
chapter, and 45 CFR 170.215(c)(6) for data specified at Sec.
431.60(b)(5) of this chapter. Such information received by a State must
be incorporated into the State's records about the current beneficiary.
(2) With the approval and at the direction of a current or former
beneficiary or the beneficiary's personal representative, the State
must:
(i) Receive all such data for a current beneficiary from any other
payer that has provided coverage to the beneficiary within the
preceding 5 years;
(ii) At any time a beneficiary is currently enrolled with the State
and up to 5 years after disenrollment, send all such data to any other
payer that currently covers the beneficiary or a payer the beneficiary
or the beneficiary's personal representative specifically requests
receive the data; and
(iii) Send data received from another payer under this paragraph in
the electronic form and format it was received.
(c) Coordination among payers at enrollment--Payer-to-Payer API.--
(1) Accessible content and API requirements. Beginning January 1, 2023,
a State must make the standards-based API specified in paragraph (b)(1)
of this section conformant with the implementation specification at 45
CFR 170.215(a)(4) to facilitate sharing the data specified in paragraph
(b)(1) of this section relevant to one or more beneficiaries at one
time.
(2) Requesting data exchange. (i) When a beneficiary enrolls in
coverage with the State, the State may request the data from a previous
payer through the standards-based API described in paragraph (c)(1) of
this section, as permitted by the enrollee per paragraph (c)(5) of this
section, and as permitted by applicable law;
(ii) For any beneficiaries who enroll with the State during the
first calendar quarter of each year, the State must request the
specified data within one (1) week of the end of the first calendar
quarter from any previous payers through the standards-based API
described in paragraph (c)(1) of this section, as permitted by the
beneficiary per paragraph (c)(5) of this section, and as permitted by
applicable law;
(iii) If a State receives a request from another payer to make data
available for one or more former beneficiaries who have enrolled with
the new payer, the State must respond by making the required data
available via the standards-based API described in paragraph (c)(1) of
this section within one (1) business day of receiving the request.
(3) Previous or concurrent payer. A State must maintain a process
to obtain from a new beneficiary the name of the new beneficiary's
previous payer as part of the enrollment process, and concurrent payer
if the beneficiary has coverage through more than one payer, to
facilitate data sharing using the Payer-to-Payer API described in
paragraph (c)(1) of this section.
(4) Concurrent payer exchange. When a beneficiary has concurrent
coverage with another payer also subject to CMS regulations on the
Payer-to-Payer API, the State must make available to the other payer
the data described in paragraph (b)(1) of this section through the
standards-based API described in paragraph (c)(1) of this section
quarterly.
(5) Opt-in. A State must put a process in place to allow a
beneficiary or the beneficiary's personal representative to opt-in to
permit the State's use of the Payer-to-Payer API data sharing specified
in paragraph (c)(1) of this section.
(d) Obligations. The requirements under this section do not in any
way alter or change a State's obligation as a HIPAA covered entity to
comply with regulations regarding standard transactions at 45 CFR part
162.
(e) Extensions and Exemptions--(1) Extension. (i) A State may
submit a written application to request to delay implementation of the
requirements in paragraphs (a) through (c) of this section one-time for
up to one (1) year with respect to its Medicaid fee-for-service
program. The written application must be submitted and approved as part
of the State's annual Advance Planning Document for MMIS operations
costs and must include:
(A) A narrative justification describing the specific reasons why
the State cannot reasonably satisfy the requirement(s) by the
compliance date and explaining why those reasons result from
circumstances that are unique to States operating CHIP fee-for service
programs;
(B) A report on completed and ongoing State implementation
activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no
later than 1 year after the initial compliance date.
(ii) CMS will grant the State's request if it determines based on
the information provided in the State's annual Advance Planning
Document for MMIS operations costs that the request adequately
establishes a need to delay implementation, that this need results from
circumstances that are unique to States operating CHIP fee-for-service
programs, that the State has made a good faith effort to implement the
proposed requirements as soon as possible, and that the State has a
clear plan to implement the requirements no later than one (1) year
after the proposed compliance date.
(2) Exemption. (i) A State operating a CHIP program under which at
least 90 percent of all covered items and services are provided to
beneficiaries through managed care contracts with MCOs, PIHPs, or
PAHPs, rather than through a fee-for-service delivery system, or under
which at least 90 percent of the State's beneficiaries are enrolled in
managed care organizations as defined in Sec. 457.10, may request that
its fee-for-service program be exempted from the requirement(s) in
paragraphs (a) through (c) of this section.
(A) A state may submit an exemption request once per calendar year
for a one (1) year exemption.
(B) The annual request must be submitted as part of a state's
annual

[[Page 82678]]

Advance Planning Document for MMIS operations costs.
(C) The State's request must include documentation that the State
meets the criteria for the exemption, using data from any one of the
three most recent and complete calendar years prior to the date the
exemption request is made.
(ii) CMS will grant the exemption for a one-year period if the
State establishes to CMS's satisfaction that the State meets the
criteria for the exemption and has established a plan to ensure there
will be efficient electronic access to the same information through
alternative means.
(f) Applicability. This section is applicable beginning January 1,
2023.
0
22. Section 457.732 is added to subpart G to read as follows:

Sec. 457.732 Documentation and prior authorization.

(a) Requirements to support provider documentation discovery and to
support prior authorization. At a minimum:
(1) Documentation Requirement Lookup Service (DRLS) Application
Programming Interface (API). Beginning January 1, 2023, a State must
implement and maintain a standards-based API compliant with Sec.
457.730(c), (d), and (e) --
(i) That is populated with the State's list of covered items and
services, not including covered outpatient drugs, for which prior
authorization is required, and with the State's documentation
requirements for submitting a prior authorization request, including a
description of the required documentation; and
(ii) That is conformant with the implementation specifications at
45 CFR 170.215(c)(1) and (2).
(2) Prior Authorization Support API. Beginning January 1, 2023, a
State must implement and maintain a standards-based API compliant with
Sec. 457.730(c), (d), and (e) --
(i) That facilitates a HIPAA-compliant prior authorization request
and response, including any forms or medical record documentation
required by the State for the items or services for which the provider
is seeking prior authorization;
(ii) That is conformant with the implementation specifications at
45 CFR 170.215(c)(1) and (2).
(iii) That includes in the response whether the State approves (and
for how long), denies, or requests more information related to the
prior authorization request, along with a denial reason code in the
case of denial;
(iv) A State must include a specific reason for a denial in the
case of a denial with all prior authorization decisions, regardless of
the method used to send the prior authorization decision.
(b) Extensions and Exemptions.--(1) Extension. (i) A State may
submit a written application to request to delay implementation of the
requirements in paragraphs (a)(1) and (2) of this section one-time for
up to one (1) year with respect to its Medicaid fee-for-service
program. The written application must be submitted and approved as part
of the State's annual Advance Planning Document for MMIS operations
costs and must include:
(A) A narrative justification describing the specific reasons why
the State cannot reasonably satisfy the requirement(s) by the
compliance date and explaining why those reasons result from
circumstances that are unique to States operating CHIP fee-for service
programs;
(B) A report on completed and ongoing State implementation
activities that evidence a good faith effort towards compliance; and
(C) A comprehensive plan to meet implementation requirements no
later than 1 year after the initial compliance date.
(ii) CMS will grant the State's request if it determines based on
the information provided in the State's annual Advance Planning
Document for MMIS operations costs that the request adequately
establishes a need to delay implementation, that this need results from
circumstances that are unique to States operating CHIP fee-for-service
programs, that the State has made a good faith effort to implement the
proposed requirements as soon as possible, and that the State has a
clear plan to implement the requirements no later than one (1) year
after the proposed compliance date.
(2) Exemption. (i) A State operating a CHIP program under which at
least 90 percent of all covered items and services are provided to
beneficiaries through managed care contracts with MCOs, PIHPs, or
PAHPs, rather than through a fee-for-service delivery system, or under
which at least 90 percent of the State's beneficiaries are enrolled in
managed care organizations as defined in Sec. 457.10, may request that
its fee-for-service program be exempted from the requirement(s) in
paragraphs (a)(1) and (2) of this section.
(A) A state may submit an exemption request once per calendar year
for a one (1) year exemption.
(B) The annual request must be submitted as part of a state's
annual Advance Planning Document for MMIS operations costs.
(C) The State's request must include documentation that the State
meets the criteria for the exemption, using data from any one of the
three most recent and complete calendar years prior to the date the
exemption request is made.
(ii) CMS will grant the exemption for a one-year period if the
State establishes to CMS's satisfaction that the State meets the
criteria for the exemption and has established a plan to ensure there
will be efficient electronic access to the same information through
alternative means.
(3) Public reporting of prior authorization metrics. Beginning
March 31, 2023, the State must make the following information about
State agency level prior authorization decisions publicly accessible by
posting directly on its website or via publicly accessible
hyperlink(s), annually by the end of the first calendar quarter, data
for the prior calendar year:
(i) A list of all items and services, not including covered
outpatient drugs, that require prior authorization;
(ii) The percentage of standard prior authorization requests that
were approved, reported separately for items and services, not
including covered outpatient drugs;
(iii) The percentage of standard prior authorization requests that
were denied, reported separately for items and services, not including
covered outpatient drugs;
(iv) The percentage of standard prior authorization requests that
were approved after appeal, reported separately for items and services,
not including covered outpatient drugs;
(v) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
reported separately for items and services, not including covered
outpatient drugs;
(vi) The percentage of expedited prior authorization requests that
were approved, reported separately for items and services, not
including covered outpatient drugs; and
(vii) The average and median time that elapsed between the
submission of a request and a determination by the State, for standard
prior authorizations, reported separately for items and services, not
including covered outpatient drugs.
0
23. Section 457.760 is amended by adding paragraph (d) to read as
follows:

Sec. 457.760 Access to published provider directory information

* * * * *
(d) Beginning January 1, 2023, the Provider Directory API must be
conformant with the implementation specification at 45 CFR
170.215(c)(8).
0
24. Section 457.1233 is amended by--

[[Page 82679]]

0
a. Revising paragraph (d)(2) introductory text;
0
b. Adding paragraph (d)(2)(ii);
0
c. Revising paragraph (d)(3); and
0
d. Adding paragraph (d)(4) and (5).
The revisions and additions read as follows:

Sec. 457.1233 Structure and operations standards.

* * * * *
(d) * * *
(2) Subject to paragraph (d)(5) of this section, each MCO, PIHP,
and PAHP must implement a Patient Access Application Programming
Interfaces (APIs) as specified in Sec. 457.730 as if such requirements
applied directly to the MCO, PIHP, or PAHP, and include:
* * * * *
(ii) Reporting metrics specified at Sec. 457.730(h) at the plan
level.
(3) Except for Sec. 457.760(d), implement, by January 1, 2021, and
maintain a publicly accessible standards-based Provider Directory API
described at Sec. 457.760 of this chapter, which must include all
information specified in Sec. 438.10(h)(1) and (2) of this chapter.
The state must require, at a minimum, that each MCO, PIHP, and PAHP
comply with Sec. 457.760(d) by the rating period beginning on or after
January 1, 2023.
(4) By the rating period beginning on or after January 1, 2023,
comply with Sec. Sec. 457.731(a) through (d) and 457.732(a) as if such
requirements applied directly to the MCO, PIHP, or PAHP.
(5) The following timeframes apply to paragraph (d)(2) of this
section:
(i) Except for the requirement at Sec. Sec. 457.730(b)(5),
457.730(c)(3)(iii), 457.730(g), and 457.730(h), comply with the by the
requirements of Sec. 457.730 by January 1, 2021.
(ii) Comply with the requirements at Sec. Sec. 457.730(b)(5),
457.730(c)(3)(iii), and 457.730(g) by the rating period beginning on or
after January 1, 2023.
(iii) Comply with the reporting requirement at Sec. 457.730(h)
beginning with the end of the first full quarter of the rating period
beginning on or after January 1, 2023 based on the previous quarter's
data.
* * * * *
For the reasons set forth in the preamble, the Department of Health
and Human Services (HHS) proposes to amend 45 CFR subtitle A,
subchapter B as set forth below:

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

0
25. The authority citation for part 156 continues to read as follows:

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

0
26. Section 156.221 is amended by--
0
a. Revising paragraph (b)(1)(iii);
0
b. Adding paragraph (b)(1)(iv);
0
c. Revising paragraph (c)(3) introductory text;
0
d. Adding paragraph (c)(3)(iii);
0
e. Revising paragraph (c)(4) introductory text, (c)(4)(ii)(C), (e)(2),
and (f)(1) introductory text;
0
f. Adding paragraph (f)(2);
0
g. Redesignating paragraphs (h) and (i) as paragraphs (j) and (k);
0
h. Adding new paragraphs (h) and (i); and
0
i. Revising newly redesignated paragraph (j).
The revisions and addition read as follows:

Sec. 156.221 Access to and exchange of health data and plan
information.

* * * * *
(b) * * *.
(1) * * *
(iii) Clinical data, as defined in the USCDI version 1, if the QHP
issuer maintains any such data, no later than 1 business day after data
are received by the QHP issuer; and
(iv) Beginning January 1, 2023, pending and active prior
authorization decisions and related clinical documentation and forms
for items and services, not including prescription drugs, including the
date the prior authorization was approved, the date the authorization
ends, as well as the units and services approved and those used to
date, no later than 1 business day after a provider initiates a prior
authorization for the enrollee or there is a change of status for the
prior authorization.
* * * * *
(c) * * *
(3) Must comply with the content and vocabulary standard
requirements in paragraphs (c)(3)(i) and (ii) of this section, as
applicable to the data type or data element, unless alternate standards
are required by other applicable law, and be conformant with the
requirements in paragraph (c)(3)(iii) of this section:
* * * * *
(iii) Beginning January 1, 2023, be conformant with the
implementation specifications at Sec. 170.215(c)(5) for data specified
at Sec. 156.221(b)(1)(i) and (ii), Sec. 170.215(a)(2) or Sec.
170.215(c)(6) of this subchapter for data specified at Sec. Sec.
156.221(b)(1)(iii), and 170.215(c)(6) of this subchapter for data
specified in paragraph (b)(1)(iv) of this section.
(4) May use an updated version of any standard or all standards and
any or all implementation guides or specifications required under
paragraphs (b), (c), or (f) of this section, Sec. Sec. 156.222 or
156.223, where:
* * * * *
(ii) * * *
(C) Use of the updated version of the standard, implementation
guide, or specification does not disrupt an end user's ability to
access the data described in paragraph (b) or (f) of this section or
the data described in Sec. Sec. 156.222 or 156.223 of this chapter
through the required API.
* * * * *
(e) * * *
(2) Makes this determination using objective, verifiable criteria
that are applied fairly and consistently across all applications and
developers through which parties seek to access electronic health
information, as defined at Sec. 171.102 of this subchapter, including
but not limited to criteria that may rely on automated monitoring and
risk mitigation tools.
(f) * * *
(1) From January 1, 2022 until December 31, 2022, a QHP issuer on a
Federally-facilitated Exchange must maintain a process for the
electronic exchange of, at a minimum, the data classes and elements
included in the content standard adopted at Sec. 170.213 of this
subchapter. Such information received by a QHP issuer on a Federally-
facilitated Exchange must be incorporated into the QHP issuer's records
about the current enrollee. With the approval and at the direction of a
current or former enrollee or the enrollee's personal representative, a
QHP issuer on a Federally-facilitated Exchange must:
* * * * *
(2) Beginning January 1, 2023, a QHP issuer on a Federally-
facilitated Exchange must implement and maintain an API compliant with
Sec. 156.221(c)(1), (c)(2), (c)(3)(i), and (c)(3)(ii), (d), and (e),
and that is conformant with the implementation specifications at Sec.
170.215(c)(5) of this chapter for data specified at Sec.
156.221(b)(1)(i) and (ii) not including remittances and enrollee cost
sharing information, Sec. 170.215(a)(2) or 170.215(c)(6) of this
subchapter for data specified at Sec. 156.221(b)(1)(iii), and Sec.
170.215(c)(6) of this subchapter for

[[Page 82680]]

data specified in paragraph (b)(1)(iv). Such information received by a
QHP issuer on a Federally-facilitated Exchange must be incorporated
into the QHP issuer's records about the current enrollee.
(i) With the approval and at the direction of a current or former
enrollee or the enrollee's personal representative, a QHP issuer on a
Federally-facilitated Exchange must:
(A) Receive all such data for a current enrollee from any other
payer that has provided coverage to the enrollee within the preceding 5
years;
(B) At any time an enrollee is currently enrolled in the plan and
up to 5 years after disenrollment, send all such data to any other
payer that currently covers the enrollee or a payer the enrollee or the
enrollee's personal representative specifically requests receive the
data; and
(C) Send data received from another payer under this paragraph
(f)(2) of this section in the electronic form and format it was
received.
(ii) [Reserved].
* * * * *
(h) Privacy policy attestation. (1) Beginning January 1, 2023, a
QHP issuer on a Federally-facilitated Exchange must establish,
implement, and maintain a process for requesting an attestation from a
third-party app developer requesting to retrieve data via the Patient
Access API that indicates the app adheres to certain privacy
provisions. The QHP issuer on a Federally-facilitated Exchange must:
(i) Independently, or through the support of a third party, request
a third-party app developer to attest whether:
(A) The app has a privacy policy that is publicly available and
accessible at all times, including updated versions, and that is
written in plain language, and that the third-party app has
affirmatively shared with the enrollee prior to the enrollee
authorizing app access to their health information. To ``affirmatively
share'' means that the enrollee had to take an action to indicate they
saw the privacy policy, such as click or check a box or boxes.
(B) The app's privacy policy includes, at a minimum:
(1) How an enrollee's health information may be accessed,
exchanged, or used by any person or other entity, including whether the
enrollee's health information may be shared or sold at any time
(including in the future);
(2) A requirement for express consent from an enrollee before the
enrollee's health information is accessed, exchanged, or used,
including receiving express consent before an enrollee's health
information is shared or sold (other than disclosures required by law
or disclosures necessary in connection with the sale of the application
or a similar transaction);
(3) If an app will access any other information from an enrollee's
device; and
(4) How an enrollee can discontinue app access to their data and
what the app's policy and process is for disposing of an enrollee's
data once the enrollee has withdrawn consent.
(ii) Include information in the enrollee resources required in
paragraph (g) of this section about the specific content of the QHP
issuer's privacy policy attestation required under this paragraph, and,
at a minimum, the timeline for the attestation process, the method for
informing enrollees about the app developer's response or non-response
to the QHP issuer's request, and the enrollee's role and rights in this
process; and
(iii) Request the attestation at the time the third-party app
engages the API and notify the enrollee as follows:
(A) The QHP issuer on a Federally-facilitated Exchange must inform
the enrollee within 24 hours of requesting the attestation from the
third-party app developer regarding the status of the attestation--
positive, negative, or no response, with a clear explanation of what
each means;
(B) If an enrollee does not respond within 24 hours of when the QHP
issuer send the notice of the attestation status to the enrollee, the
QHP issuer must proceed with making the enrollee's data available to
the third-party app consistent with the enrollee's original request.
(2) A QHP issuer must not discriminate when implementing this
requirement, including for the purposes of competitive advantage; the
method employed to meet this requirement must be applied equitably
across all apps requesting access the Patient Access API.
(i) Reporting on the use of the Patient Access API. (1) Beginning
March 31, 2023, a QHP issuer on a Federally-facilitated Exchange must
report to HHS, at the issuer level, by the end of each calendar
quarter, based on the previous quarter's data:
(i) The total number of unique enrollees whose data are transferred
via the Patient Access API to an enrollee designated third-party
application; and
(ii) The number of unique enrollees whose data are transferred via
the Patient Access API to an enrollee designated third-party
application more than once.
(2) [Reserved].
(j) Exception. (1) If a plan applying for QHP certification to be
offered through a Federally-facilitated Exchange believes it cannot
satisfy the requirements in paragraphs (a) through (i) of this section,
the issuer must include as part of its QHP application a narrative
justification describing the reasons why the plan cannot reasonably
satisfy the requirements for the applicable plan year, the impact of
non-compliance upon enrollees, the current or proposed means of
providing health information to enrollees, and solutions and a timeline
to achieve compliance with the requirements of this section.
(2) The Federally-facilitated Exchange may grant an exception to
the requirements in paragraphs (a) through (i) of this section if the
Exchange determines that making such health plan available through such
Exchange is in the interests of qualified individuals and qualified
employers in the State or States in which such Exchange operates.
* * * * *
0
27. Section 156.222 is added to read as follows:

Sec. 156.222 Access to and exchange of health data and plan
information to providers and payers.

(a) Application Programming Interface to support data transfer from
payers to providers--Provider Access API. Subject to paragraph (d) of
this section:
(1) Accessible content and API requirements. Beginning January 1,
2023, a QHP issuer on a Federally-facilitated Exchange must implement
and maintain a standards-based Application Programming Interface (API)
compliant with Sec. 156.221(c), (d), and (e):
(i) Individual enrollee data. The Provider Access API must make
available to providers, if requested by the provider, as permitted by
the enrollee per paragraph (a)(3) of this section, and as permitted by
applicable law, at a minimum, data maintained by the QHP with a date of
service on or after January 1, 2016, within one (1) business day of
receipt, conformant with the implementation specifications at Sec.
170.215(c)(5) of this subchapter for data specified at Sec.
156.221(b)(1)(i) and (ii), not including remittances and enrollee cost
sharing information, Sec. 170.215(a)(2) or (c)(6) of this subchapter
for data specified at Sec. 156.221(b)(1)(iii), and Sec. 170.215(c)(6)
of this subchapter for data specified in paragraph (b)(1)(iv) of this
section; and
(ii) Bulk data access. The Provider Access API must be able to
share the data described in paragraph (a)(1)(i) of

[[Page 82681]]

this section conformant with the implementation specification at Sec.
170.215(a)(4) to facilitate sharing the specified data relevant to one
or more QHP enrollees at one time;
(2) Attribution. A QHP issuer on a Federally-facilitated Exchange
must establish, implement, and maintain a process to facilitate
generating each provider's current enrollee rosters to enable payer-to-
provider data sharing via the Provider Access API.
(3) Opt-in. A QHP issuer on a Federally-facilitated Exchange may
put a process in place to allow an enrollee or the enrollee's personal
representative to opt-in to permit the QHP's use of the Provider Access
API for sharing with each of the enrollee's provider(s) currently
providing care, or planning to provide care, the data specified in
paragraph (a)(1) of this section.
(4) Provider resources regarding APIs. A QHP issuer on a Federally-
facilitated Exchange must provide on its website and through other
appropriate mechanisms through which it ordinarily communicates with
providers, educational resources in non-technical, simple, and easy-to-
understand language explaining general information concerning how a
provider may make a request to the QHP for QHP enrollee data using the
standards-based Provider Access API, required under paragraph (a)(1) of
this section, both for individual access and bulk data requests.
(5) Out-of-network provider access. A QHP issuer on a Federally-
facilitated Exchange cannot deny use of, or access to, the Provider
Access API based on a provider's contract status.
(b) Coordination among payers at enrollment--Payer-to-Payer API.
Subject to paragraph (d) of this section:
(1) Accessible content and API requirements. Beginning January 1,
2023 a QHP issuer on a Federally-facilitated Exchange must make the
standards-based API specified at Sec. 156.221(f)(2) conformant with
the implementation specification at Sec. 170.215(a)(4) of this
subchapter to facilitate sharing the data specified at Sec.
156.221(f)(2) relevant to one or more QHP enrollees at one time.
(2) Requesting data exchange. (i) When an enrollee enrolls in a QHP
on a Federally-facilitated Exchange, the QHP issuer may request the
data from the previous payer through the standards-based API described
in paragraph (b)(1) of this section, as permitted by the enrollee per
paragraph (b)(5) of this section, and as permitted by applicable law.
(ii) For any enrollees who enrolled in a QHP on a Federally-
facilitated Exchange during the annual open enrollment period
applicable to the Federally-facilitated Exchange, the QHP issuer must
request the specified data within one (1) week of the end of the
enrollment period from any previous payers through the standards-based
API described in paragraph (b)(1) of this section, as permitted by
enrollees per paragraph (b)(5) of this section, and as permitted by
applicable law;
(iii) If a QHP issuer receives a request from another payer to make
data available for one or more former enrollee who have enrolled with
the new payer, the QHP issuer must respond by making the required data
available via the standards-based API described in paragraph (b)(1) of
this section within one (1) business day of receiving the request.
(3) Previous or concurrent payer. A QHP issuer on a Federally-
facilitated Exchange must maintain a process to obtain from a new QHP
enrollee the name of the new QHP enrollee's previous payer, and
concurrent payer if the enrollee has coverage through more than one
payer, to facilitate data sharing using the Payer-to-Payer API
described in paragraph (b)(1) of this section.
(4) Concurrent payer exchange. When a QHP enrollee has concurrent
coverage with another payer also subject to HHS regulations on the
Payer-to-Payer API, the QHP issuer on the Federally-facilitated
Exchange must make available to the other payer the data described at
Sec. 156.221(f)(2) through the standards-based API described in
paragraph (b)(1) of this section quarterly.
(5) Opt-in. A QHP issuer on a Federally-facilitated Exchange must
put a process in place to allow an enrollee or the enrollee's personal
representative to opt-in to permit the QHP issuer to use the Payer-to-
Payer API data sharing specified in paragraph (b)(1) of this section.
(c) Obligations. The requirements under this section do not in any
way alter or change a QHP issuer's obligation as a HIPAA covered entity
to comply with regulations regarding standard transactions at 45 CFR
part 162.
(d) Exception. (1) If a plan applying for QHP certification to be
offered through a Federally-facilitated Exchange believes it cannot
satisfy the requirements in paragraphs (a) or (b) of this section, the
issuer must include as part of its QHP application a narrative
justification describing the reasons why the plan cannot reasonably
satisfy the requirements for the applicable plan year, the impact of
non-compliance upon enrollees, the current or proposed means of
providing health information to providers and/or payers, and solutions
and a timeline to achieve compliance with the requirements of this
section.
(2) The Federally-facilitated Exchange may grant an exception to
the requirements in paragraphs (a) or (b) of this section if the
Exchange determines that making such health plan available through such
Exchange is in the interests of qualified individuals and qualified
employers in the State or States in which such Exchange operates.
0
28. Section 156.223 is added to read as follows:

Sec. 156.223 Documentation and prior authorization.

(a) Requirements to support provider documentation discovery and to
support prior authorization. Subject to paragraph (b) of this section:
(1) Documentation Requirement Lookup Service (DRLS) Application
Programming Interface (API). Beginning January 1, 2023, a QHP issuer on
a Federally-facilitated Exchange must implement and maintain a
standards-based API compliant with Sec. 156.221(c), (d), and (e):
(i) That is populated with the QHP issuer's list of covered items
and services, not including prescription drugs, for which prior
authorization is required, and with the QHP issuer's documentation
requirements for submitting a prior authorization request, including a
description of the required documentation; and
(ii) That is conformant with the implementation specifications at
Sec. 170.215(c)(1) and (2).
(2) Prior Authorization Support API. Beginning January 1, 2023, a
QHP issuer on a Federally-facilitated Exchange must implement and
maintain a standards-based API compliant with Sec. 156.221(c), (d),
and (e):
(i) That facilitates a HIPAA-compliant prior authorization request
and response, including any other forms or medical record documentation
required by the QHP issuer for the items or services for which the
provider is seeking prior authorization, conformant with the
requirements at Sec. 172.110(a)(3) of this subchapter;
(ii) That is conformant with the implementation specification at
Sec. 170.215(c)(3) of this subchapter; and
(iii) That includes in the response whether the QHP issuer approves
(and for how long), denies, or requests more information related to the
prior authorization request, along with a standard denial reason code
in the case of denial;
(iv) A QHP issuer on a Federally-facilitated Exchange must include
a specific reason for a denial in the case of a denial with all prior
authorization

[[Page 82682]]

decisions, regardless of the method used to send the prior
authorization decision.
(3) Public reporting of prior authorization metrics. Beginning
March 31, 2023, a QHP issuer on a Federally-facilitated Exchange must
make the following information about the issuer level prior
authorization decisions specified, publicly accessible by posting
directly on its website or via publicly accessible hyperlink(s),
annually by the end of the first calendar quarter, data for the prior
calendar year:
(i) A list of all items and services, not including prescription
drugs, that require prior authorization;
(ii) The percentage of standard prior authorization requests that
were approved, reported separately for items and services, not
including prescription drugs;
(iii) The percentage of standard prior authorization requests that
were denied, reported separately for items and services, not including
prescription drugs;
(iv) The percentage of standard prior authorization requests that
were approved after appeal, reported separately for items and services,
not including prescription drugs;
(v) The percentage of prior authorization requests for which the
timeframe for review was extended, and the request was approved,
reported separately for items and services, not including prescription
drugs;
(vi) The percentage of expedited prior authorization requests that
were approved, reported separately for items and services, not
including prescription drugs; and
(vii) The average and median time that elapsed between the
submission of a request and a determination by the issuer, for standard
prior authorizations, reported separately for items and services, not
including prescription drugs.
(b) Exception. (1) If a plan applying for QHP certification to be
offered through a Federally-facilitated Exchange believes it cannot
satisfy the requirements in paragraph (a)(1) and/or (a)(2) of this
section, the issuer must include as part of its QHP application a
narrative justification describing the reasons why the plan cannot
reasonably satisfy the requirements for the applicable plan year, the
impact of non-compliance upon enrollees, the current or proposed means
of providing health information to providers, and solutions and a
timeline to achieve compliance with the requirements of this section.
(2) The Federally-facilitated Exchange may grant an exception to
the requirements in paragraph (a) of this section if the Exchange
determines that making such health plan available through such Exchange
is in the interests of qualified individuals and qualified employers in
the State or States in which such Exchange operates.

PART 170--HEALTH INFORMATION TECHNOLOGY STANDARDS, IMPLEMENTATION
SPECIFICATIONS, AND CERTIFICATION CRITERIA AND CERTIFICATION
PROGRAMS FOR HEALTH INFORMATION TECHNOLOGY

0
29. The authority citation for part 170 continues to read as follows:

Authority: 42 U.S.C. 300jj-11; 42 U.S.C 300jj-14; 5 U.S.C. 552.
0
30. Section 170.215 is amended--
0
a. By revising the section heading;
0
b. In paragraph (a), by adding a paragraph heading;
0
c. In paragraph (b), by revising the paragraph heading; and
0
d. By adding paragraph (c).
The revisions and additions read as follows:

Sec. 170.215 Application Programming Interface Standards and
Implementation Specifications.

* * * * *
(a) Base Standard and Implementation Specifications. * * *
* * * * *
(b) Security Standard. * * *
(c) Standards and Implementation Specifications for Health Care
Operations.
(1) Prior authorization implementation specification. HL7 FHIR Da
Vinci--Coverage Requirements Discovery (CRD) Implementation Guide:
Version STU 1.0.0 (incorporated by reference in Sec. 170.299).
(2) Prior authorization implementation specification. HL7 FHIR Da
Vinci--Documentation Templates and Rules (DTR) Implementation Guide:
Version STU 1.0.0 (incorporated by reference in Sec. 170.299).
(3) Prior authorization implementation specification. HL7 FHIR Da
Vinci--Prior Authorization Support (PAS) Implementation Guide: Version
STU 1.0.0 (incorporated by reference in Sec. 170.299).
(4) Payer data implementation specification. HL7 FHIR Da Vinci--
Payer Coverage Decision Exchange (PCDE) Implementation Guide: Version
STU 1.0.0 (incorporated by reference in Sec. 170.299).
(5) Payer data implementation specification. HL7 FHIR Consumer
Directed Payer Data Exchange (CARIN IG for Blue Button[supreg])
Implementation Guide: Version STU 1.0.0 (incorporated by reference in
Sec. 170.299).
(6) Payer data implementation specification. HL7 FHIR Da Vinci
Payer Data Exchange (PDex) Implementation Guide: Version STU 1.0.0
(incorporated by reference in Sec. 170.299).
(7) Payer data implementation specification. HL7 FHIR Da Vinci--
Payer Data Exchange (PDex) US Drug Formulary Implementation Guide:
Version STU 1.0.1 (incorporated by reference in Sec. 170.299).
(8) Provider directory implementation specification. HL7 FHIR Da
Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide: Version
STU 1.0.0 (incorporated by reference in Sec. 170.299).
0
31. Section 170.299 is amended by adding paragraphs (f)(35) through
(42) to read as follows:

Sec. 170.299 Incorporation by reference.

* * * * *
(f) * * *
(35) HL7 FHIR[supreg] Da Vinci--Coverage Requirements Discovery
(CRD) Implementation Guide, Version STU 1.0.0, IBR approved for Sec.
170.215(c).
(36) HL7 FHIR[supreg] Da Vinci--Documentation Templates and Rules
(DTR) Implementation Guide, Version STU 1.0.0, IBR approved for Sec.
170.215(c).
(37) HL7 FHIR[supreg] Da Vinci--Prior Authorization Support (PAS)
Implementation Guide, Version STU 1.0.0, IBR approved for Sec.
170.215(c).
(38) HL7 FHIR[supreg] Da Vinci--Payer Coverage Decision Exchange
(PCDE) Implementation Guide, Version STU 1.0.0, IBR approved for Sec.
170.215(c).
(39) HL7 FHIR[supreg] Consumer Directed Payer Data Exchange (CARIN
IG for Blue Button[supreg]) Implementation Guide, Version STU 1.0.0,
IBR approved for Sec. 170.215(c).
(40) HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex)
Implementation Guide, Version STU 1.0.0, IBR approved for Sec.
170.215(c).
(41) HL7 FHIR[supreg] Da Vinci--Payer Data Exchange (PDex) US Drug
Formulary Implementation Guide, Version STU 1.0.1, IBR approved for
Sec. 170.215(c).
(42) HL7 FHIR[supreg] Da Vinci Payer Data Exchange (PDex) Plan Net
Implementation Guide, Version STU 1.0.0, IBR approved for Sec.
170.215(c).
* * * * *

Dated: December 2, 2020.
Seema Verma,
Administrator, Centers for Medicare & Medicaid Services.
Dated: December 10, 2020.
Alex M. Azar II,
Secretary, Department of Health and Human Services.
[FR Doc. 2020-27593 Filed 12-14-20; 11:15 am]
BILLING CODE 4120-01-P

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.