CMS Issues a New “Advancing Interoperability and Improving Prior Authorization Processes” Proposed Rule

On December 6, 2022, the Centers for Medicare & Medicaid Services (CMS) issued a Proposed Rule that would (i) further enhance health data exchange by establishing data exchange standards for certain payers, (ii) improve patient and provider access to health information, and (iii) streamline processes related to prior authorization for medical items and services. The regulations impact CMS-regulated payers and provide incentives for providers and hospitals that participate in the Medicare Promoting Interoperability Program and the Merit-based Incentive Payment System (MIPS).

This Proposed Rule officially withdraws, replaces, and responds to the comments received from the December 2020 CMS Interoperability proposed rule, further builds on the May 2020 CMS Interoperability and Patient Access final rule, and diverges from the December 2020 CMS Interoperability proposed rule in a few key ways. Most of the Proposed Rule’s provisions will be effective on January 1, 2026. The deadline to submit comments is March 13, 2023. Our initial takeaways are summarized below.

The below summary does not focus on the Medicaid and Children’s Health Insurance Program (CHIP) Fee for Service (FFS) proposals. The Proposed Rule also notes that the Medicare FFS program is evaluating opportunities to improve automation of prior authorization processes, and, if the Proposed Rule is finalized, Medicare FFS would align its efforts for implementing its requirements as feasible.

1.  Proposed Rule withdraws, replaces, and responds to comments to the December 2020 CMS Interoperability proposed rule:

CMS reports that it received approximately 251 individual comments on the December 2020 CMS Interoperability proposed rule by the close of the comment period on January 4, 2021. The agency explains that the December 2020 CMS Interoperability proposed rule will not be finalized due to the concerns raised by the commenters—including concerns related to the short comment period for stakeholders to conduct a thorough analysis and provide feedback, as well as the short implementation timeframes. For these reasons, CMS withdrew the December 2020 CMS Interoperability proposed rule. The new Proposed Rule incorporates the feedback CMS had already received, proposes updates and provides additional time for public comment, until March 13, 2023.

2.  Proposed Rule builds on the May 2020 CMS Interoperability and Patient Access final rule:

This newly Proposed Rule builds on the May 2020 CMS Interoperability and Patient Access final rule by requiring impacted payers (newly included Medicare Advantage Organizations (MAO); state Medicaid and CHIP FFS programs; Medicaid managed care plans; CHIP managed care entities; and Qualified Health Plan (QHP) issuers on the Federally-facilitated Exchanges (FFE)) not only to establish standards-based Patient Access Application Programming Interface (API), but also to implement new Provider Access API, a standardized payer-to-payer data exchange API, and a Prior Authorization Requirements, Documentation and Decision (PARDD) API. To ensure providers utilize this technology, CMS also proposes to include the “electronic prior authorization” measure for the Merit-based Incentive Payment System (MIPS) Promoting Interoperability performance category for MIPS eligible providers and the Medicare Promoting Interoperability Program for eligible hospitals and critical access hospitals (CAHs).

a.  Patient Access API

(i) Security risk remains the only reason to deny an individual’s access request via Patient Access API.

CMS reiterates in the Proposed Rule that the only reason payers could deny API access to a health app that a patient wishes to use and access through the Patient Access API is potential security risk to the payer. CMS enumerates that these security risks include insufficient authentication or authorization controls, poor encryption, or reverse engineering. The payer must make that determination using objective, verifiable criteria that are applied fairly and consistently across all apps and developers through which patients seek to access their electronic health information.

(ii) Prior authorization information would be included via the Patient Access API.

CMS proposes to require impacted payers (now including  MAOs) to share certain prior authorization information through the Health Level 7® (HL7®) Fast Healthcare Interoperability Resources® (FHIR®) standard Patient Access API.

(iii) Payers would be required to report metrics about the use of Patient Access API.

Additionally, CMS proposes to require impacted payers to report metrics in the form of aggregated, de-identified data to CMS on an annual basis about how patients use the Patient Access API to assess whether CMS’s Patient Access API policies are successful. Specifically, CMS proposes that payers annually report:

• The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and
• The total number of unique patients whose data are transferred more than once via the Patient Access API to a health app designated by the patient.

(iv) Data provided via the Patient Access API would include all data classes and elements currently included in USCDI v.1.

Finally, CMS proposes a clarification that the data that impacted payers must make available are “all data classes and data elements included in a content standard at 45 C.F.R. 170.213,” instead of “clinical data, including laboratory results.” The current data standard at 45 C.F.R. 170.213 remains USCDI v. 1.   

b.  Provider Access API

In addition to the Patient Access API requirement, the Proposed Rule requires impacted payers to implement and maintain a FHIR API that makes patient information directly available to providers with whom payers have contractual relationships (i.e. in-network providers) and with whom patients have treatment relationships. The proposal includes a patient opt-out option (where the December 2020 CMS Interoperability proposed rule included an opt-in policy) by which patients could choose not to participate in the Provider Access API. Through this provision, CMS seeks to reduce the burden on patients and improve care by ensuring that providers can access comprehensive patient data. Importantly, both the proposed Patient and Provider Access APIs require that payers share prior authorization request and decision information for medical items and services (excluding drugs).

c.  Payer-to-Payer Data Exchange API

(i) Payers would be required to implement a FHIR API for payer-to-payer data exchange.

The Proposed Rule would rescind the payer-to-payer data exchange policy that did not impose a standard for the exchange, and proposes to require impacted payers to implement and maintain a payer-to-payer FHIR API to build a longitudinal patient record when the patient moves from one payer to another, or when the patient has concurrent coverage. CMS proposes an opt-out option for patients. While non-impacted payers may benefit from implementing the payer-to-payer API, they would not be under any obligation to do so. Therefore, the impacted payers in this Proposed Rule would only be responsible for their own side of the data sharing requests and responses.

(ii) Payers would have to exchange data with any concurrent payers that member reports within one week of the start of coverage.

The Proposed Rule requires impacted payers to collect information about any concurrent payer(s) from patients before the start of coverage with the impacted payer and, within one week of the start of a member’s coverage, to exchange data with any concurrent payers that the member reports. Such exchange would continue on at least a quarterly basis. The receiving impacted payer would have to respond with the appropriate data within one business day of receiving the request for a current patient’s data from a known concurrent payer for that patient. To the extent that an individual is enrolled with payers not subject to the Proposed Rule that refuse to exchange data with the impacted payer, the impacted payer would not be required to provide data to that concurrent payer and would not be required to continue to request data exchange quarterly. An impacted payer is required to respond to a non-impacted payer, however, if that non-impacted payer requests data exchange in accordance with the Proposed Rule.

d.  Prior Authorization Requirements, Documentation, and Decision (PARDD) API

(i) Payers would need to build a PARDD API to streamline authorization process.

CMS proposes requirements for an API to streamline the prior authorization processes, that is the process by which a provider must obtain approval from a payer before providing care in order to receive payment for delivering items or services.  Specifically, CMS proposes to require impacted payers to build and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision (PARDD) API. The Proposed Rule would not apply to outpatient drugs, drugs that may be prescribed, those that may be administered by a physician, or that may be administered in a pharmacy, or hospital.

CMS acknowledges that its PARDD API proposal will result in changes to the impacted payers’ customer service operations and procedures, and encourages payers to evaluate the procedural and operational changes as part of their implementation strategy, and to make appropriate resources available when the API is launched.

Given the delayed implementation date of January 1, 2026 (for Medicaid managed care plans and CHIP managed care entities, by the rating period beginning on or after January 1, 2026, and for QHP issuers on the FFEs, for plan years beginning on or after January 1, 2026), CMS encourages those payers that currently maintain cumbersome prior authorization processes on their individual websites or through proprietary portals to develop short-term mechanisms to make prior authorization information more easily understandable and publicly available to providers and patients, if they elect to wait until 2026 to implement the PARDD API.

(ii) Payers must share certain information with patients and providers.

As noted in the Patient Access API description, there are a few key pieces of information which payers are responsible for sharing with patients and providers within clear timelines under the Proposed Rule. Specifically, payers must share lists of covered items and services (excluding drugs) which require prior authorization, share the corresponding documentation requirements, respond to prior authorization requests within specified timeframes, provide clear reasoning for request denials, and publicly report prior authorization metrics including approvals, denials, and appeals.

The PARDD API, however, also would allow providers to query the payer’s system to determine whether a prior authorization was required for certain items and services and to identify documentation requirements. Further, the PARDD API would automate the compilation of necessary data for populating the HIPAA-compliant prior authorization transaction (X12 278) and enable payers to provide the status of the prior authorization request, including whether the request has been approved (and for how long) or denied (with a specific reason), which would support current Federal and state notice requirements for certain impacted payers.

(iii) Impacted payers would be required to annually report on prior authorization metrics.

CMS stated it believes that transparency regarding prior authorization processes would be an important consideration for individuals to choose new plans. CMS proposes to require impacted payers to publicly report annually (by March of each year), on the payer’s website or via a publicly accessible hyperlink(s), on the following nine aggregated metrics about prior authorization:

1. A list of all items and services that require prior authorization.
2. The percentage of standard prior authorization requests that were approved, aggregated for all items and services.
3. The percentage of standard prior authorization requests that were denied, aggregated for all items and services.
4. The percentage of standard prior authorization requests that were approved after appeal, aggregated for all items and services.
5. The percentage of prior authorization requests for which the timeframe for review was extended, and the request was approved, aggregated for all items and services.
6. The percentage of expedited prior authorization requests that were approved, aggregated for all items and services.
7. The percentage of expedited prior authorization requests that were denied, aggregated for all items and services.
8. The average and median time that elapsed between the submission of a request and a determination by the payer, plan, or issuer, for standard prior authorizations, aggregated for all items and services.
9. The average and median time that elapsed between the submission of a request and a decision by the payer, plan or issuer, for expedited prior authorizations, aggregated for all items and services.

This proposed reporting would be at the organizational level for MA, the state level for Medicaid and CHIP FFS, the plan level for Medicaid and CHIP managed care, and the issuer level for QHP issuers on the FFEs.

(iv) CMS encourages payers to adopt prior authorization gold-carding programs.

The Proposed Rule also encourages payers to adopt gold-carding programs, where payers relax prior authorization requirements for providers that have a demonstrated history of compliance with all payer documentation requirements to support the requests, appropriate utilization of items or services, or other evidence-driven criteria. To further encourage the adoption and establishment of gold-carding programs, CMS is considering including a gold-carding measure as a factor in the quality star ratings and seeks comment for potential future rulemaking on the incorporation of such a measure into star ratings for these organizations and on imposing gold-carding as a requirement in payer’s prior authorization policies.

e. Electronic Prior Authorization for the MIPS Promoting Interoperability Performance Category and the Medicare Promoting Interoperability Program.

CMS acknowledges that the anticipated benefits of the PARDD API are contingent on providers using health IT products that can interact with payers’ APIs.  Therefore, the Proposed Rule also creates a new “electronic prior authorization” measure for MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS, as well as for eligible hospitals and critical access hospitals (CAHs) under the Medicare Promoting Interoperability Program. Under this proposal, MIPS eligible clinicians, eligible hospitals, and CAHs would be required to report the number of prior authorizations for medical items and services (excluding drugs) that are requested electronically using data from certified electronic health record technology (CEHRT) using a payer’s PARDD API. CMS determines a final score for each MIPS eligible clinician based on their performance in the MIPS performance categories and applies a payment adjustment (which can be positive, neutral, or negative) for the covered professional services they furnish based on their final score. Under the Medicare Promoting Interoperability Program, eligible hospitals and CAHs that do not successfully demonstrate meaningful use of CEHRT are subject to Medicare payment reductions. CMS requests comment on additional steps CMS could take to encourage providers and health IT developers to adopt the technology necessary to access payers’ PARDD APIs.

CMS also notes that on January 24, 2022, ONC published an RFI titled “Electronic Prior Authorization Standards, Implementation Specifications, and Certification Criteria” (87 FR 3475) requesting comment on how updates to the ONC Health IT Certification Program could support electronic prior authorization.

f.  Interoperability Standards for APIs

Finally, this Proposed Rule seeks to clarify the specific standards at 45 C.F.R. 170.215 that apply for each API discussed in the proposal. For example, CMS proposes to require impacted payers to implement an HL7 FHIR API that would work in combination with the adopted HIPAA transaction standard—ASC X12 Version 5010x217 278 (X12 278) for dental, professional, and institutional requests for review and response— and use certain HL7 FHIR Da Vinci Implementation Guidelines (IGs) developed specifically to support the functionality of the PARDD API to conduct the prior authorization process. Covered entities would continue to send and receive the HIPAA-compliant prior authorization transactions while using the FHIR PARDD API.

g.  Requests for Information (RFI)

There are also five RFIs in the Proposed Rule on the following topics:

• Accelerating adoption of standards related to social risk data;
• Electronic exchange of behavioral health data;
• Electronic exchange for Medicare fee-for-service;
• Incentives for exchange in accordance with the Trusted Exchange Framework and Common Agreement; and
• Advancing interoperability and improving prior authorization for maternal health.

3.  Summary of the Proposed Rule’s major changes from the December 2020 Interoperability proposed rule:

In sum, the Proposed Rule features the following major changes from the December 2020 proposed rule:

• Requiring impacted payers to use the health information technology standards at 45 C.F.R. 170.215 that are applicable to each corresponding set of API requirements, including the payer-to payer API;
• Including MAOs as impacted payers;
• Extending the implementation timeline for the policies within the newly proposed rule, with opportunities to seek extensions, exemptions, or exceptions for certain payers;
• Clarifying existing Medicaid beneficiary notice and fair hearing regulations that apply to Medicaid prior authorization, and changing terminology related to Patient Access API; and
• Including a new Electronic Prior Authorization measure for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program and MIPS eligible clinicians under the Promoting Interoperability performance category of MIPS.