From the Desk of Shreya Patel – CMS Prior Authorization Proposed Rule

VHIEC Blog

From the Desk of Shreya Patel – CMS Prior Authorization Proposed Rule

This month, CMS released their long-awaited proposed rule on Prior Authorization, Provider Access API, and Payer to Payer Exchange.

 

Initially released in December 2020, CMS proposed an expansion of the Patient Access Final Rule. As a reminder, the CMS Patient Access Final Rule required certain Federal payers to share clinical and claims information they maintained with their enrollees or beneficiaries through the use of open APIs and mobile applications. The expansion to this rule would have built upon the open API infrastructure that payers put in place for the patient access component. This would be achieved by allowing providers to have access to the same information patients would through a Provider Access API. In addition, payers would be required to share information with other payers as their enrollees or beneficiaries changed plans or had concurrent enrollment. Lastly, through the new Prior Authorization API, CMS urged payers to release information to patients, providers, and new payers on prior, current, pending, and denied prior authorization requests. This rule had a set compliance date of 2023, but it was never finalized after many voiced concerns surrounding the ability for payers to meet this deadline. Further, there was much ambiguity on the payer to payer exchange, which required drafters of the proposed rule to revisit.

 

As mentioned, this month CMS decided to retract the prior proposed rule and release a new one, which would cover the same topics listed above—and more. Below,  we have included our condensed fact sheet on important portions of this rule.

 

Prior Authorization API

CMS proposes to expand on Patient Access API to include a process for sending and receiving Prior Authorization.

 

Requirements:

  • What information must be made available via Patient Access API
    • All prior authorization requests and decisions for items and services (excluding drugs) for which the payer has data
    • Prior authorization status
      • Whether the decision is still pending, active, denied, expired, or is in another status
    • Date the prior authorization was approved or denied
    • Date or circumstance under which the authorization ends
    • Items and services approved
    • Quantity used to date under the authorization
    • Any materials that the provider sends to the payer to support a decision
    • Specific reason for denial
  • Implement and maintain a FHIR Prior Authorization Requirements, Documentation, and Decision API (PARDD API)
  • Automate the process to determine whether a prior authorization is required for an item or service
  • Query the payer’s prior authorization documentation requirements and make those requirements available within the provider’s workflow
  • Support an automated approach to compiling the necessary data elements to populate the HIPAA-compliant prior authorization transactions and enable payers to compile specific responses regarding the status of the prior authorization, including information about the reason for a denial
  • Respond to prior authorization requests within 1 day
  • Require impacted payers to publicly report certain metrics about their prior authorization processes for transparency (aggregated, deidentified)
    • The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient
    • 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.

 

Clarifications:

  • CMS proposed payer share the same information about prior authorization requests and decisions with a patient’s provider via the Provider Access API and via the Payer-to-Payer API, and of course PARDD
  • What does this not apply to:
    • Drugs of any type that could be covered by an impacted payer, including, for example, outpatient drugs, drugs that may be prescribed, drugs that may be administered by a provider, or drugs that may be administered in a pharmacy or hospital
  • How long must they be available
    • In the Patient Access API as long as the authorization is active and at least 1 year after the last status change

 

Provider Access API

CMS gives providers access to the same information patients get access to in the Patient Access API (includes USCDIv1 and all Prior Authorization decisions).

 

Requirements:

  • Requirement only for providers in payer’s network
  • Information required:
    • Claims and encounter data
    • All data classes and data elements included in a content standard adopted at 45 CFR 170.213 (USCDI v1) such as Immunizations, Procedures, and Assessment and Plan of Treatment
    • Only if the payer “maintains” that information
    • Prior authorization information for 1 year prior
    • No provider remittance information requirement
  • Educational materials to provide for Patients
    • Benefits of Provider Access API
    • Their opt out rights
    • Instructions for opting out and opting in after opting out
    • Non technical, easy to understand
    • Public, available at all times on website
  • Educational materials to provide for Providers
    • Resources about Provider Access API
    • Process for requesting patient data from payer using API
    • How to use attribution process to associate patients with the provider
    • Provide through payer website and other modes of communication

 

Differences between this and Patient Access API

  • Patient requests through health application, provider requests through EHR practice management system or other technology solution for treatment purposes
  • No provider remittances or cost sharing shared on Provider Access API
  • Proposing to require the FHIR Bulk Data Access Implementation Guide
  • If a provider does not have a provider agreement or is not enrolled with a payer that holds their patient’s data, the payer would not be required to provide patient data to this provider under this proposed rule
  • HIPAA interpretation- would this exchange be considered a healthcare transaction?
    • Although the proposals would facilitate sharing claims data from payers to providers, the transmission would not be subject to HIPAA transaction standards because the purpose of the exchange would not be to request or issue a payment.

 

Other proposals

  • Patient attribution
    • Acknowledged HIEs here- and guided payers to utilize these to not recreate the wheel. Utilize HIEs for patient attribution
  • Opt Out- Patients have an option to opt out of provider access API, whatever process that may be. Payer to Payer will be opt in.
    • They encourage granular opt out
    • Cited that opt out models are linked with significantly higher HIE utilization and maturation
    • CMS stated, “we also note that the HIPAA Rules permits health plans to disclose PHI, without an individual’s authorization, to providers via the Provider Access API for certain permitted purposes under the HIPAA Rules, such as, for example, treatment, payment, or health care operations”

 

Payer to Payer Exchange

Require existing payers to send a patient’s information to a new payer for a certain number of years after they leave the plan via API or to provide to individuals with concurrent coverage. This is meant to create a longitudinal record that follows the patient as they go from payer to payer.

 

Requirements:

  • Same data classes for the Patient Access API
  • OpenID Connect authorization and authentication protocols to authenticate identity of payer requesting access
  • FHIR Bulk Data Access (Flat FHIR) used for exchanging multiple patients’ data at one time
  • Allow patients to opt INTO payer to payer exchange (with previous and current payers) prior to start of coverage
    • Cannot be used as reason to delay an applicant’s eligibility for start of coverage
    • Only can request enough information to identify and make successful request of previous or concurrent payers
    • Opt in is to identify the appropriate payers using the patient as the source of truth, it is not an opt in to share health information that is able to be shared without patient authorization
  • Require the requesting payer to include an attestation with the request for the data affirming the patient has enrolled with the payer and opted in to payer to payer exchange
  • Information with Payer to Payer must be incorporated into the patient’s record with the new payer as longitudinal record
  • For concurrent coverage, exchange patient’s data available to each other every quarter at a minimum
    • Data retention requirements are not impacted
  • Patient education information requirements
    • Non technical, simple
    • On ability to opt in or withdraw opt in and instructions
    • Require to provide before requesting permission for payer to payer
    • Only must provide to those currently enrolled in plan- but available publicly on website (seems contradictory)
    • Must be provided annually

Information required:

  • USCDI version 1
  • Adjudicated claims and encounter data (not including provider remittances and enrollee cost-sharing information)
  • Prior authorization decisions
    • While patient will be required to resubmit prior auths under a new payer, this will help will efficiency

 

Important points:

  • This is a one time share, not an ongoing share
  • Patients can request subsequent data if they choose for other situations

Timeline:

  • Make request no later than 1 week after the start of the coverage
  • 1 business day turnaround time for other requests if an impacted payer receives a request from another payer to make data available for former patients who have enrolled with the new payer or a current patient who has concurrent coverage
    • This is if they have been authenticated and demonstrated opt in

Requests for Information

  1. Barriers to adopting standards, and opportunities to accelerate the adoption of standards, for social risk data (e.g. housing and food insecurity)
  2. How CMS could leverage APIs (or other technology) to facilitate electronic data exchange between and with behavioral healthcare providers
  3. How Medicare FFS could support improved medical documentation exchange between and among providers, suppliers, and patients
  4. How using data standards and electronic health records and prior authorization can improve maternal health outcomes
  5. How to encourage providers and payers to enable exchange under TEFCA to make patient information more readily available for access and exchange in a variety of circumstances