# 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 > Briefs, arguments, decisions, and more. URL: https://www.frixlaw.com/law-library/documents/fr%3A2020-27593 ## Record - **Collection:** Federal Register - **Document type:** Proposed Rule - **Published:** December 18, 2020 - **Citation:** 85 FR 82586 ## Text 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 http://www.regulations.gov. Follow the “Submit a comment” instructions. 2. By regular mail. You may mail written comments to the following address ONLY: Centers for Medicare & Medicaid Services, Department of Health and Human Services, Attention: CMS-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: http://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 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, 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/index.html and https://www.hhs.gov/hipaa/for-professionals/faq/personal-representatives-and-minors/index.html. 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® (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 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 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®) 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®) Implementation Guide Publication (Version) History. Retrieved from http://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 http://hl7.org/fhir/us/core/history.html. 5 HL7 International. (n.d.). Da Vinci Payer Data Exchange (FHIR IG) Publication (Version) History. Retrieved from http://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 http://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 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 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 http://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. 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 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 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 http://www.hl7.org/fhir/us/davinci-pdex-plan-net/history.cfml. 17 Available at http://cmsgov.github.io/QHP-provider-formulary-APIs/developer/index.html. 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 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 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 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/index.html. 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 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 § 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. 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 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 requirement [Text truncated at 120,000 characters. The full text is on the page linked above.] --- Source: Frix Law Library, https://www.frixlaw.com/law-library/documents/fr%3A2020-27593. Public record. Not legal advice.