CMS Advancing Interoperability & Improving Prior Authorization NPRM

The Advancing Interoperability and Improving Prior Authorization Processes Proposed Rule was released by CMS on December 13, 2022. It has a standard 90 day comment period, scheduled to close on March 13, 2023. Everything in the rule is scheduled to go into effect on January 1, 2026 (or the first new plan year thereafter).

The new proposed rule is similar to the previous frozen rule from December 2020/January 2021 and covers mostly the same items at the top level:

• Updates/changes to the Patient Access API
• New Provider Access API
• Updates/changes to the Payer => Payer exchange
• New Prior Authorization exchange
• Several RFIs (some the same, some new)

It also includes a new quality measure to track uptake of the prior authorization APIs.

General Approach

CMS sees this (and other interoperability rules) as a set of minimum requirements that they hope many will exceed. Throughout the rule are comments like "we hope XXX will choose to support Y even though we are not requiring it at this time" and "this does not mean ZZZ cannot support more than the K outlined in this rule; we encourage ZZZ to do so". Further, the rules are designed to make this relatively easy; the heaviest lift is the initial step required by the rule - adding more should, in theory, take less effort and resources. This is particularly true for things like supporting the requirements outlined in the rule for other plans supported by the same payers, but also includes things like supporting additional data exchange via the same mechanisms.

In a similar vein, CMS looks at the current set of interoperability rules and related requirements as a progression rather than as completely independent requirements. They are evaluating the feasibility and ease of implementation based on their expectations for support required in previous, already enforceable rules. Because the original Patient Access API from the May 2020 rule requires USCDI v1 clinical data exchange, supporting that level of exchange in any other FHIR API comes more-or-less for free, or at least cheaply. Similar for claims data and other data mandated for exchange in the previous rule. They assume the previously supported exchange is not segregated off into a process silo somewhere and that those responsible for implementing the new exchanges have access to the resources, knowledge, technology, and business processes used to implement it.

Both of these follow the general approach taken by CMS (and ONC and HHS more generally). There were also a few specific support decisions in this rule. In particular, CMS modified their approach to standards.. Instead of restricting to specific standards outlined in the rule or to external pages it links to that are expected to be static for the life of the rule, here CMS points to a de-linked external standards list maintained by ONC. This means that the required versions of specific standards such as USCDI or US Core (or FHIR itself) can be updated separately and independently of the rule making process instead of requiring a new regulation for adoption. CMS explicitly states that any listed version updates are only permitted if they don't disrupt an end user's ability to access data using the API (i.e., if it's a backwards compatible update), but that's going to be a hard requirement to manage. FHIR and most FHIR IGs don't include strict (or sometimes any) backwards compatibility requirements and even experts are notoriously bad at applying backwards compatibility requirements to when they do exist. Expect churn when new versions of major standards are added to the supported list.

On a similar note, CMS generally decided against mandating the use of specific FHIR implementation guides for different APIs and exchanges. Instead, they lay out the requirements and recommends (with varying degrees of strength) which DaVinci or other IGs to use to fulfill those requirements. The prior authorization workflows are completely compatible with the DaVinci CRD, DTS, and PAS IGs but no one has to use them. The Payer => Payer FHIR APIs recommend the use of the DaVinci PDEX IG but doesn't require it. And so on. This, too, will lessen the standardization and may open CMS up to some of the same feedback it's gotten in the past around not having detailed, standardized data exchange processes outlined in regulations.

Patient Access API

Differences from Frozen Rule:

• Rule now applied to Medicare Advantage plans
• Removed requirement for third party app attestation of privacy policy shared with patient
• Changed reporting requirement from quarterly to annual
• Minor language clarification around use of standards and otherwise

The Patient Access API introduced in the May 2020 Interoperability rule must be modified to include the following data for all prior authorization requests except those related to medications:

• PA status
• Specific reason for a denial, if denied
• Date or circumstance under which the authorization ends, if approved
• Items and services approved, if approved
• Quantity used to date under the authorization, if approved
• All data sent to the payer to support the PA decision (both structured and unstructured)

The big kicker here is the last bullet point which can involve a significant amount of clinical data that goes beyond the current USCDI v1 requirement. It's not clear if payers will render this data in any type of consistent way as in many cases it may be left to them to determine how to fit the data into FHIR resources.

This information must be available in the API within one day of the receipt of a prior authorization request or any change of its status and remain available for at least one year after its last status change.

The following information about usage (aggregated according to organization, state, or payer depending on the type of plan) must be reported to CMS annually with the previous year's metrics required by March 31 of the following year:

• The total number of unique patients who use a health app designated by the patient at least once
• The total number of unique patients who use a health app designated by the patient more than once

CMS devotes quite a bit of space in this section to a discussion of privacy and third party apps, most notably to reiterate that third party apps fall out of the purview of HIPAA (they are regulated by the FTC if the developer is a for-profit enterprise). Nonetheless, payers must comply with all patient requests for third party app access unless the app can be shown to actively harm or imperil the security of the payer's systems in some way. CMS actively solicits additional comments in this area, most notably around patient education and reporting of third party app usage.

Provider Access API

Differences from Frozen Rule:

• Rule now applied to Medicare Advantage plans
• Patient now may opt out instead of having to opt in before their data can be exchanged

The Provider Access API is new to this rule (it was part of the frozen rule from 2020/2021) and adds the missing leg to API data exchange: payer to provider. This API includes all of the data expected in the Patient Access API (both in the existing iteration and the new one outlined in this rule) except for patient cost sharing data and provider remittances.

Payers are required to support sending this data to all providers with a treatment relationship with the patient and a contractual relationship with the payer. Payers are also encouraged to send data to out of network providers but are not required to do so (CMS warns that payers should ensure the requestor is not on the List of Excluded Individuals/Entities first).

This is a B2B API and is not permitted for use by individual clinicians using their own mobile, web, or other apps not integrated into their practice's official health IT systems. Payers must support Bulk FHIR APIs to allow provider systems to request data for multiple patients at once.

The requirement to send patient data ends as soon as the patient enrollment with the payer ends. CMS doesn't precisely state this outright, but it's clear the expectation is that data would be transferred to the new payer at that time and the data sent to providers via that new payer's Provider Access API.

Patients are automatically included in Provider Access APIs unless they opt out (they must be allowed to opt back in later if they so choose). Payers are only required to support a global opt out/opt back in option, not more granular options that allow patients to pick and choose which providers should or should not get their data. However, CMS encourages payers to support opting in and out at a more granular level.

The opt out option must be available prior to enrollment (or prior to initial exchange implementation) and patients must be allowed to change their choice at any time. Payers must support the ability to opt in or out via electronic, phone, fax, or mail.

To ensure that patients have a treatment relationship with the providers requesting their data, payers must develop and maintain an attribution process. How this is done is up to the payer - the DaVinci Member Attribution List IG is recommended but not required.

There are also extensive patient and provider education requirements around this API including requirements at enrollment, for annual distribution, and always available on the payer's website.

Payer => Payer Data Exchange

Differences from Frozen Rule:

• Rule now applied to Medicaid and CHIP plans
• Payers are now required to request data within one week of the start of coverage if a patient opts in during enrollment or one week after the opt in request if it happens outside of the enrollment process.
• If a request for subsequent data (after the initial request) comes from a concurrent payer it must be fulfilled within 1 day
• Concurrent payers are required to exchange data with each other at least quarterly
• This version of the rule is much more focused on the enrollment time options as opposed to ad-hoc requests

This rule completely replaces the existing Payer => Payer data exchange outlined in the May 2020 Interoperability rule which was supposed to have an implementation date of January 1, 2022 but was delayed because of requests for more specific exchange requirements. This API includes all of the data expected in the Patient Access API (both in the existing iteration and the new one outlined in this rule) except for patient cost sharing data and provider remittances.

Patients must opt in to this exchange. Payers are required to include an opt in mechanism during the enrollment process and to offer opt in options on an adhoc basis after that. In general this is intended to be a one time data exchange so a subsequent opt out option is not required.

Unlike the original May 2020 rule, this version explicitly requires use of FHIR APIs for the data exchange. The old payer must authenticate the identity of the new payer; the new payer is expected to attest that the patient is enrolled in one of their plans and that they have permission from the patient to acquire the data but is not required to send specifics to the old payer. Payers can make individual requests for specific patients or use the Bulk FHIR API to request data for multiple patients at one. Payers have up to 7 days to request a patient's data after that patient opts into the process (time requirements are stricter for concurrent plans and these plans also require at least quarterly data exchange).

There are also payer education requirements - payers must educate patients at or before enrollment and annually thereafter in all of the mechanisms they use to communicate with their patients. Payers must also put educational materials on their public website.

Prior Authorization

Differences from Frozen Rule:

• Modified the name and description of the APIs (but not their purpose). The Document Requirements Lookup Service (DRLS) and Prior Authorization Support (PAS) are now combined into the Prior Authorization Requirements, Documentation, and Decision (PARDD) API
• Gold carding is explicitly supported

The main components of this portion of the rule include:

• Prior authorization API to streamline the PA process
• Requirements for response timeframes
• Inclusion of reasons for denials
• Public reporting on PA adjudication and appeals

These requirements apply to any formal decision making process using payer guidelines for prior authorization determinations for everything except drugs. CMS also raises the option for a gold carding program for payers who wish to implement one; specific requirements for such a program are not outlined in the rule.

The Prior Authorization Requirements, Documentation, and Determination (PARDD) API does the following:

• Allows a provider to query a payer system to determine if a prior authorization is needed for a specific item or service
• Identify documentation requirements for evaluating a PA request for that item or service
• Automate the compilation of the required data
• Enable payers to provide PA status to the requesting provider

Responses to requests must be sent as soon as possible, but no later than 7 days for standard requests and 3 days for expedited requests. PARDD maintains X12 278 transactions within the scope required by HIPAA - a conversion process between X12 278 and FHIR is an expected intermediate step between the payer and provider systems (organizations can choose to apply to CMS for a HIPAA exception to avoid this step if they wish).

Payers must post aggregated metrics about PARDD usage on their websites annually, with data from one year posted by March 31 of the following year.

RFIs

This rule includes five RFIs that give a lot of insight into the areas CMS is considering addressing in future regulations and into their approach to data and interoperability more generally. They are:

• Accelerating the Adoption of Standards Related to Social Risk Factor Data
• Electronic Exchange of Behavioral Health Data
• Improving the Electronic Exchange of Information in Medicare FFS
• Advancing TEFCA 
• Advancing Interoperability and Improving PA for Maternal Health

Final Thoughts

CMS has mostly retained the content of the frozen rule from December 2020/January 2021 but at the same time some of the specifics have been either simplified or been specified in less detail in this version of the rule. This, along with decisions to make DaVinci guides optional even in cases where the proscribed process matches them or was clearly built using them, means that this rule will likely come with a lot of implementation variation.

In general, we see this rule as big step forward in interoperability and in improving prior authorization workflows as well as their visibility to both providers and patients. The addition of a Provider Access API with payer => provider exchange provides the missing piece for full data exchange between payers, providers, and patients.

January 2026 is a long way off and at least some of these components could have been slated for implementation sooner. That said, there's a lot to do. Working together, we can make all of this happen and move toward a more inclusive, patient-centric health data system that ensures the right data is at the right place at the right time to provide the care everyone needs.