FAQs: Prior Authorization Final Rule

Advancing Interoperability and Improving Prior Authorization Processes: Final Rule FAQs

Full Rule here; Fact Sheet here

January 17, 2024

On January 17, 2024, the Centers for Medicare & Medicaid Services (CMS) finalized a long-awaited rule that mandates three new application programming interfaces (APIs), including a Prior Authorization API. It is called the Advancing Interoperability and Improving Prior Authorization Processes Rule. The rule was first proposed in December 2022 and faced opposition for its expense and lack of requirements on providers or their electronic health record vendors. Regardless, the final rule is very much the same as initially proposed, barring some changes to compliance dates.

Notably, the 822-page unpublished rule includes new requirements for impacted payers to facilitate health data exchange. In the following overview we focus on the three new APIs – Prior Authorization API, Provider Access API, and Payer-to-Payer API – changes to the Patient Access API, process updates for prior authorization, and updates to the Merit-based Incentive Payment System and the Medicare Promoting Interoperability Program. Some of the new policies take effect in 2026, but others will not start until 2027 to allow the industry more time to develop automated processes.

In the wake of increased attention to AI tools in healthcare, automated coverage decisions are under great scrutiny. Yet, the AHA applauded the rule when it was released, and CMS estimates the rule could save hospitals and doctors more than $15 billion over 10 years.

What are the “impacted payers” referenced by the rule?

The final rule applies to Medicare Advantage organizations, Medicaid and the Children’s Health Insurance Program (CHIP) fee-for-service (FFS) programs, Medicaid managed care plans, CHIP managed care entities, and issuers of Qualified Health Plans (QHPs) offered on the Federally-Facilitated Exchanges (FFEs).

These are referred to as “impacted payers” in the rule but will be further referred to as “health plans” or “plans” in this overview.

What are the compliance dates?

For each new FHIR-based API – Prior Authorization API, Provider Access API, and Payer-to-Payer API – the compliance date is January 1, 2027.

Health plans must make some changes to their prior authorization processes by January 1, 2026. We review these requirements below.

How does the rule define prior authorization?

“The process by which a provider must obtain approval from a payer before providing certain covered items and services to receive payment for delivering those items or services to a covered individual.”

Are there any items and services that require prior authorization that are not covered by this rule?

Yes. Any prescription drugs that may be self-administered, administered by a provider, or that may be dispensed or administered in a pharmacy or hospital, or over-the-counter drugs that may be covered by a health plan, are excluded from the prior authorization provisions in the rule.

How long do plans have to make prior authorization decisions?

Health plans must make prior authorization decisions within 72 hours for urgent requests and seven calendar days for standard, or non-urgent, requests. This requirement begins on January 1, 2026, and applies to rule-defined plans except issuers of Qualified Health Plans (QHPs) offered on the Federally-Facilitated Exchanges (FFEs).

Do plans have to give providers and patients a reason if they deny a prior authorization request?

Yes. Beginning January 1, 2026, plans must provide a specific reason for a denied prior authorization request. This is not limited to when the Prior Authorization API is used – any method of prior authorization communication must include a reason for denial including via portal, fax, email, mail, or phone.

Do plans have any reporting requirements?

Yes. Health plans are required to post a general set of prior authorization metrics on their public websites. The initial set of metrics must be reported by March 31, 2026, including:

1. A list of all the 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 plan, 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 plan for expedited prior authorizations, aggregated for all items and services.

Are plans required to tell patients about their prior authorization decisions?

Yes. Through the already established Patient Access API, plans must add information about prior authorizations, excluding those for drugs, to the data available through the API. The following will be required by January 1, 2027:

1. The prior authorization request and decision, including all of the following:
   • The prior authorization status.
   • The date the prior authorization was approved or denied.
   • The data or circumstance under which the prior authorization ends.
   • The items and services approved.
   • If denied, a specific reason why the request was denied.
   • Related structured administrative and clinical documentation submitted by a provider.
2. The above information must be:
   • Accessible no later than 1 business day after the payer receives a prior authorization request;
   • Updated no later than 1 business day after any status change; and
   • Continue to be accessible for the duration that the authorization is active and at least 1 year after the prior authorization’s last status change.

Does the final rule offer any alternatives to prior authorization, such as gold carding?

No. In its proposed rule, CMS solicited comments about gold-carding – a process that would exempt some physicians from prior authorization processes – but did not propose or finalize any policies. All comments regarding gold-carding and other exemption programs will be considered in future rulemaking.

What is the Prior Authorization API (Application Programming Interface – how two or more computer programs communicate with each other)?

Beginning January 1, 2027, plans must implement and maintain an API with the FHIR standard, which stands for the Fast Healthcare Interoperability Resources. The Prior Authorization API would allow a provider to query a payer’s system, determining whether prior authorization was required and identifying documentation requirements. The API would then send the prior authorization request from the provider’s EHR or practice management system to the payer. In practice, the Prior Authorization API would automate this process, helping providers know if additional information is required for approval, submitting that information, and assembling all necessary information for the prior authorization request.

Are there required standards or implementation guides?

Health plans must use the following standards:

• HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1)
• US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i)
• SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1)

To meet the functional requirements of the Prior Authorization API, the final rule recommends plans use the following implementation guides; however, these are not required:

• CRD IG STU 2.0.1
• HL7® FHIR® Da Vinci Documentation Templates and Rules (DTR) IG STU 2.0.0
• PAS IG STU 2.0.1

Many commenters expressed concern over being forced to use the HIPAA-compliant X12 278 Transaction Standard. Is that still required?

While the HIPAA-compliant transaction is technically required in the rule itself, the press release about the rule suggested that HHS will not be enforcing this standard. This means that covered entities that implement an all-FHIR-based Prior Authorization API and who do not use the X12 278 standard will not be subject to penalties or other disciplinary action. It is unclear how long this flexibility will be allowed, but the agency seems to imply in its press release that it will consider further guidance in future rulemaking.

There is concern about the conflicting standards for electronic prior authorization and attachment standards. Did this rule fix that?

No, the final rule does not address health care attachments. More about the attachment standards here, here.

Are there any corollary requirements for providers to ensure the Prior Authorization API is being utilized?

Despite commenters requesting such requirements, the final rule does not impose requirements that providers’ health IT systems must use the Prior Authorization API. However, CMS finalized incentives for MIPS eligible clinicians and eligible hospitals and Critical Access Hospitals (CAHs).

Beginning in CY 2027 performance year – or CY 2029 MIPS payment year, a new measure titled “Electronic Prior Authorization” will be added to the Health Information Exchange objective for the MIPS Promoting Interoperability performance category. Eligible hospitals and CAHs will also have a new “Electronic Prior Authorization” measure beginning with the CY 2027 EHR reporting period.

Rather than the proposed numerator/denominator calculation, eligible clinicians, hospitals, and CAHs will instead report a yes/no response or claim an applicable exclusion. This was done to simplify the reporting for providers. To report the measure:

• Clinicians must attest “yes” to requesting a prior authorization electronically via a Prior Authorization API using data from certified electronic health record technology for at least one medical item or service ordered during the CY 2027 performance period.
• Eligible hospitals and CAHs must attest “yes” to requesting a prior authorization electronically via a Prior Authorization API using data from certified electronic health record technology for at least one medical item or service ordered during the 2027 EHR reporting period.

What is the Provider Access API?

Beginning January 1, 2027, health plans must implement and maintain a FHIR-based API that would allow a plan to provide an in-network or enrolled provider a patient’s data, including prior authorization information, claims data, and encounter data upon request. The Provider Access API is designed to improve care coordination and advanced value-based care by allowing a provider to access a patient’s comprehensive medical history.

What data must be included in the Provider Access API?

Upon request, a payer must provide all claims and encounter data (excluding provider remittances and patient cost-sharing information), USCDI data elements, and the following information relating to prior authorizations that are either active or for at least 1 year after a prior authorization’s last status change:

• The prior authorization status;
• The date the prior authorization was approved or denied;
• The date or circumstance under which the prior authorization ends;
• The items and services approved;
• If denied, a specific reason why the request was denied; and
• Related structured administrative and clinical documentation submitted by a provider.

Unlike the proposed rule, health plans will not be required to share the quantity of items or services under a prior authorization or any unstructured documentation related to prior authorizations.

Do patients get to choose if their information is shared in the Provider Access API?

Yes. Patients may choose to opt-out of information sharing through the Provider Access API. Health plans must provide members with the option and instructions on how to opt-out no later than one week following the start of coverage and then annually thereafter. These educational materials must be provided in plain language. A member may choose to change their status at any point during the coverage period.

This time period differs from the proposed one, in which a member must be given the option to opt-out within one week of enrollment.

Which providers must health plans share information with?

Health plans must share data, upon request, from all in-network or enrolled providers that have an established treatment relationship with a patient. Leased providers are considered “in-network” for the purposes of this rule.

Although CMS did not propose to include out-of-network providers in the Provider Access API, they will consider such requirements for future rulemaking.

When providers request information from plans, what does the plan have to do?

A health plan must fulfill a request when a patient has not opted out of the Provider Access API, the disclosure of data is not prohibited by law, and the payer has undergone required verification and attribution processes.

Plans must develop an attribution process to verify the identity of the provider, and that such provider has an established treatment relationship with a patient. CMS did not prescribe a specific process for this requirement; however, it acknowledged that a patient’s claims history, proof of appointment, or other information may be used to make this conclusion.

CMS declined to provide any standardized attribution method or minimum attribution criteria. However, CMS highlighted Medicare fee-for-service’s Data Point of Care (DPC) pilot, which currently establishes treatment relationships by identifying a processed claim with a provider’s NPI number for that patient within the past 18 months.

How fast does a plan have to respond to a provider request using the Provider Access API?

Plans must share the information listed above no later than one business day after receiving a request from a provider. Any information about prior authorizations must be updated no later than 1 business day after receiving a prior authorization request or making a prior authorization status change.

Are there required standards or implementation guides?

Yes. Health plans must use the following standards:

• HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1)
• US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i)
• SMART App Launch IG Release 1.0.0 at 45 CFR 170.215(c)(1)
• Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1)

To meet the functional requirements of the Provider Access API, the final rule recommends plans use the following implementation guides; however, these are not required:

• CARIN IG for Blue Button STU 2.0.0
• PDex IG STU 2.0.0
• SMART App Launch IG Release 2.0.0

Although CMS originally proposed to require health plans to use OpenID Connect Core, they did not finalize that provision.

Do providers have any requirements for the Provider Access API?

CMS did not propose or finalize any corollary provider requirements for the Provider Access API. However, the final rule does not prohibit plans from incentivizing or requiring the use of the Provider Access API. Additionally, the rule does not prohibit plans from charging user fees to access their APIs.

What is the Payer-to-Payer API?

Beginning January 1, 2027, health plans must implement and maintain a FHIR-based API that allows them to exchange a member’s data, including claims data and prior authorization information. This policy will support the continuity of care by allowing a beneficiary to request, upon enrolling in a new plan, for their new plan to retrieve their information from their previous plan. Additionally, if a beneficiary is enrolled in coverage under two or more concurrent plans, they may also request data be shared between those entities via the Payer-to-Payer API. Plans will then be required to integrate any new data into the patient’s record to support a comprehensive medical record.

What data must be included in the Payer-to-Payer API?

Upon request, a payer must provide all claims and encounter data (excluding provider remittances and patient cost-sharing information), USCDI data elements, and the following information relating to prior authorizations that are either active or for at least 1 year after a prior authorization’s last status change:

• The prior authorization status;
• The date the prior authorization was approved;
• The date or circumstance under which the prior authorization ends;
• The items and services approved;
• If denied, a specific reason why the request was denied; and
• Related structured and unstructured administrative and clinical documentation submitted by a provider.

Unlike the proposed rule, plans will not be required to share the quantity of items or services under a prior authorization, and will also not be required to include information about denied prior authorizations.

Also, unlike the proposed rule, plans will only be required to share five years of patient data, as opposed to the entire patient health record.

Do members get to choose if their information is shared in the Payer-to-Payer API?

Yes. However, unlike the Provider Access API which is an opt-out decision, patients may choose to opt-in to information sharing using the Payer-to-Payer API. Plans must provide members with the option and instructions on how to opt-in no later than one week following the start of coverage, and then annually.

For patients who are already enrolled, plans must obtain an opt-in decision by the compliance date.

What are the timeframes for Payer-to-Payer data exchange?

Health plans must establish a process to identify a patient’s previous or concurrent plans within one week of the start of their coverage. Additionally, a health plan must request data from the previous or concurrent plan no later than one week after the payer has sufficient information to do so.

Upon receiving a request from a patient’s new or concurrent plan, plans must share information within 1 business day.

After the initial data exchange, concurrent plans must continue to exchange data quarterly.

What happens if a member’s previous or concurrent payer is a nonimpacted payer?

While CMS encourages participation from all health plans, they emphasize that each health plan is only responsible for its own side of the data exchange transaction. While a nonimpacted payer, a health plan not identified in the rule, is not required to comply with a data exchange request from those named in the rule, if an impacted payer receives a request from a nonimpacted payer, they must share the relevant information through the Payer-to-Payer API.

Do plans have to consider previous payers’ prior authorization approvals?

The final rule did not propose nor include any provisions that require plans to review, consider, or honor the active prior authorization decision of a member’s former plan. However, CMS does highlight the benefits to doing so, such as evaluating whether a member has already undergone step-therapy.

CMS also notes that the CY 2024 Policy and Technical Changes to the Medicare Advantage Program, Medicare Prescription Drug Benefit Program, Medicare Cost Plan Program, and Programs of All-Inclusive Care for the Elderly final rule does contain provisions that require MA organizations to provide a minimum 90-day transition period when a member switches to a new payer, meaning the new MA plan cannot require prior authorization for an active course of treatment.

Are there required standards or implementation guides?

Health plans must use the following standards:

• HL7 FHIR Release 4.0.1 at 45 CFR 170.215(a)(1)
• US Core IG STU 3.1.1 at 45 CFR 170.215(b)(1)(i)
• Bulk Data Access IG v1.0.0: STU 1 at 45 CFR 170.215(d)(1)

To meet the functional requirements of the rule, plans may also use updated standards, specifications, or IGs such as US Core IG STU 6.1.0 and the Bulk Data Access IG v2.0.0: STU 2.  The final rule also recommends plans use the following implementation guides; however, these are not required:

• CARIN IG for Blue Button STU 2.0.0
• PDex IG STU 2.0.0
• SMART App Launch IG Release 2.0.0

How does CMS intend to coordinate with other interoperability initiatives to advance the Provider Access API and Payer-to-Payer API?

CMS intends to work with the Office of the National Coordinator for Health IT to see how TEFCA may support the exchange of information between payers and providers. Additionally, CMS highlighted how a National Directory of Healthcare (NDH) that contained payers’ and providers’ digital endpoints could greatly contribute to the success of the Provider Access API and Payer-to-Payer API, commenting that the agency will continue to explore the development of an NDH.

If you require further information or a presentation on this rule, please contact Julie.barnes@maverickhealthpolicy.com