On Dec. 10, the Centers for Medicare & Medicaid Services (CMS) released a proposed rule citing potential reductions in provider and patient burden by improving prior authorization processes and increasing patient access to electronic health information. You can review the proposed rule and the CMS proposed rule fact sheet.

UPDATE: On Jan. 4, the AASM submitted a comment letter to CMS, applauding the agency’s effort to reduce the burden of prior authorization and urging CMS to establish and implement additional policies to further harmonize with AMA best practices.

AASM will continue advocating for reduced burden associated with prior authorization and will provide comments in response to this rule by the deadline of 5 p.m. on Jan. 4, 2021. Members also are encouraged to submit comments via the regulations.gov website (file code CMS-9123-P).

The following summary of the proposed rule is provided for AASM members, who may send questions regarding this document to coding@aasm.org.

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. Although Medicare fee-for-service (FFS) programs are not directly impacted by this rule, CMS is 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. CMS is also encouraging other payers not directly impacted by this rule to join in moving toward reduced burden and greater interoperability. These proposals have a potential implementation date of Jan. 1, 2023.

Through the Patient Access API, finalized in the CMS Interoperability and Patient Access final rule, CMS 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 would be most meaningful and useful to them. This API could also allow the patient to facilitate their data moving from their payer to their provider.

While the use of the Patient Access API is a significant first step in facilitating the sharing of individual patient health information, CMS believes 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.

CMS previously finalized that the Patient Access API must make available clinical data, including laboratory results, specifying that such clinical data must comply with the content and vocabulary standards.  A summary of additional proposals are included below:

  • CMS is 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. CMS believes that 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.
  • CMS is proposing to require payers to make available to patients information about any pending and active prior authorization decisions 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.
  • CMS is 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, that the same information about prior authorization decisions be made available via the Payer-to-Payer API.

CMS also believes it would be highly valuable for payers to share pending and active prior authorization decisions with providers and other payers. 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.

Patient Access API: Privacy Policy Attestation

CMS is 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. CMS is also proposing 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.

At a minimum, CMS proposes that the requested privacy policy 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, 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.
  • 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
    • 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
    • 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

CMS proposes that impacted payers must request the third-party app developer’s attestation at the time the third-party app engages the API. Under the 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.

CMS believes 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. The agency also believes that the use of this required attestation would help patients be as informed as possible. Therefore, CMS proposes the following:

  • 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, and 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.

Patient Access API Metrics

CMS is proposing to require impacted payers to report metrics about patient use of the Patient Access API to CMS, as they 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.

As a first step in evaluating the adoption of the Patient Access API, CMS is proposing that the payer agencies 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.

Provider Directory API Implementation Guide (IG)

CMS is proposing the following:

  • The Provider Directory API provision requires impacted payers to ensure provider directory information availability to third-party applications.
    • 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.

HIPAA Disclosures and Transaction Standards

CMS proposes 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.

Proposed Requirements for Payers: Provider Access API for Individual Patient Information Access

Both the Provider Access API and the Patient Access API would facilitate the exchange of claims and encounter data, as well as the same set of clinical data, 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.

CMS is proposing two approaches to the Provider Access API:

  1. A Provider Access API that allows providers to have access to an individual patient’s information.
  2. A Provider Access API that allows access to multiple patients’ information at the same time.

Proposed Requirements for Payers: Bulk Data Provider Access API

CMS believes 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 a result, CMS is proposing a second approach to require impacted payers to implement payer-to-provider data sharing using a Bulk Data Access specification – a Bulk Data Provider Access API.

Additional Proposed Requirements for the Provider Access APIs

The accessible content, technical standards, API documentation requirements, and discontinuation and denial of access requirements would generally be consistent between the Patient Access API and the Provider Access API proposals.

Attribution

CMS is proposing that each payer establish, implement, and maintain for itself, a process to facilitate generating each provider’s current patient roster to enable this proposed payer-to-provider data sharing via the Provider Access API. To facilitate this data sharing, it is necessary that providers give payers a list of the patients whose data they are requesting.

Opt-In

CMS is proposing that impacted payers would be permitted to put a process in place for patients to opt-in to use of the Provider Access API for data sharing between their payer and their providers. In addition, CMS seeks comment on the following:

  • Whether payers would like to maintain the option to define their own process or if they would prefer CMS to suggest a process
  • Whether stakeholders would prefer an opt-out approach

Provider Resources

CMS is proposing that payers make available to providers educational resources that describe in non­technical, simple, and easy-to-understand language how a provider can request patient data using the payer’s Provider Access APIs.

The proposals in this proposed rule reflect several principles cited in the industry consensus statement, including transparency and communication regarding prior authorization to encourage effective communication between health plans, providers, and patients to minimize care delays and articulate prior authorization requirements, as well as automation to improve transparency, through the adoption and implementation of electronic prior authorization with the potential to streamline and improve the process for all stakeholders.

Electronic Options for Prior Authorization

To mitigate provider burden, and improve care delivery to patients, CMS is proposing requirements for payers to implement APIs that are conformant with certain implementation guides that would facilitate the exchange of information between payers and providers and allow providers to more effectively integrate the prior authorization process within their clinical workflow.

Proposed Requirement for Payers: Documentation Requirement Lookup Service (DRLS) API

CMS is proposing to streamline access to information about prior authorization and related documentation requirements to potentially reduce this burden, by requiring that payers implement and maintain a Fast Healthcare Interoperability Resources (FHIR)-based DRLS API, populated with their list of covered items and services, not including prescription drugs and/or covered outpatient drugs, for which prior authorization is required, and with the organization’s documentation requirements for submitting a prior authorization request, including a description of the required documentation.

Proposed Requirement for Payers: Implementation of a Prior Authorization Support API

Electronic prior authorizations are not used consistently between payers and providers, even with the availability of an adopted HIPAA standard. CMS is proposing that impacted payers implement a Prior Authorization Support (PAS) API that facilitates a HIPAA compliant prior authorization request and response, including any forms or medical record documentation required by the payer for items or services for which the provider is seeking authorization.

If this provision is finalized as proposed, the payer would be required to implement the API, and, when sending the response, include information regarding whether the organization approves (and for how long), denies, or requests more information for the prior authorization request, along with a reason for denial in the case of a denial.

Requirement to Provide a Reason for Denial

To improve the timeliness, clarity, and consistency of information for providers regarding prior authorization status, specifically denials, CMS is proposing that impacted payers send certain response information regarding the reason for denying a prior authorization request. Based on the surveys referenced above, stakeholders agree that payers do not provide consistent information about the status of a prior authorization or the reasons for a denial, nor do they use the adopted HIPAA standard transaction to communicate prior authorization status information.

Requirements for Prior Authorization Decision Timeframes and Communications

CMS is proposing to require that payer agencies provide notice of prior authorization decisions as expeditiously as a beneficiary’s health condition requires and under any circumstances not later than 72 hours after receiving a request for expedited decisions. Notice should be provided no later than 7 calendar days after receiving a request for standard decisions. For Medicaid managed care plans, they are also proposing to maintain that an extension of 14 days is authorized if the enrollee requests it or a health plan determines additional information is needed.

In addition to comments on the proposals regarding timelines and notifications, CMS is seeking comment on several related topics:

  • Under what circumstances could payers approve an expedited prior authorization in less than the proposed 72 hours? Are there circumstances in which a payer should be required to approve an expedited prior authorization in 24 hours for items and services other than prescription or outpatient drugs? What are the operational and system requirements for a more streamlined scenario for prior authorization approvals?
  • Under what circumstances could an approval be provided in less than 7 calendar days for a complex case?
  • CMS also seeks comment on process challenges with prior authorization.

Request for Comments on “Gold-Carding” Programs for Prior Authorization

Some payers have implemented what they term “gold-carding” or similar programs to relax or reduce prior authorization requirements for providers that have demonstrated a consistent pattern of compliance. CMS believes the use of gold-carding programs could help alleviate provider burden related to prior authorization and believe these programs could facilitate more efficient and prompt delivery of health care services to beneficiaries. CMS is encouraging payers to adopt gold-carding approaches that would allow prior authorization exemptions or more streamlined reviews for certain providers who have demonstrated compliance with requirements.

Additional Requests for Comment

CMS is seeking comments on the following items:

  • Whether there should be certain restrictions regarding requirements for repeat prior authorizations for items and services for chronic conditions, or whether there can be approvals for long-term authorizations
  • What alternative programs are in place or could be considered to provide long-term authorizations for terminal or chronic conditions?
  • Whether a prior authorization decision should follow patients when they change from one qualified health plan on the Exchange to another, or to another health plan impacted by this proposed rule, and under what circumstances that prior authorization could follow a patient from payer to payer
  • Whether prior authorizations should be valid and accepted for a specified amount of time
  • Who should determine how long an existing approved prior authorization from a previous payer should last?
  • Whether prior authorization should be regulated by amount of time and/or by condition
  • Solutions to standardizing prior authorization forms
  • Input on requiring the use of a standardized questionnaire could inform future rulemaking.
  • How to potentially phase out the use of fax technology to request and send information for prior authorization decisions

Data sharing among payers is one powerful way to facilitate this critically valuable flow of information through the health care ecosystem.

There are three primary proposals CMS is making regarding the payer-to-payer data exchange in this proposed rule.

  1. First, CMS proposes to extend the payer-to-payer data exchange to state Medicaid and CHIP FFS programs
  2. Second, CMS is proposing to enhance this payer-to-payer data exchange triggered by a patient’s request:
    • CMS would require an FHIR-based API for this data exchange.
    • This standards-based API must be conformant with specific implementation guides.
    • This Payer-to-Payer API, at the patient’s request, must make claims and encounter data available (not including cost information), along with information about pending and active prior authorization decisions.
  3. Third, CMS is proposing a second payer-to-payer data exchange policy that would use this Payer-to-Payer API to facilitate data sharing between payers at enrollment. When a patient enrolls with a new payer or when a patient identifies concurrent coverage, CMS proposes that the patient would have an opportunity to opt-in to this data sharing.

Enhancing the Payer-to-Payer Data Exchange – Payer-to-Payer API

CMS is proposing to enhance the payer-to-payer data exchange in two ways.

  1. CMS is proposing to require that this payer-to-payer data exchange take place via an API.
  2. CMS also proposes to require impacted payers to make available, at a minimum, not only the US Core for Data Interoperability (USCDI) version 1 data, but also claims and encounter data (not including cost information) that the payer maintains with a date of service on or after Jan. 1, 2016.

CMS is also proposing that impacted payers, consistent with the proposals for the Patient Access API, limit sharing to pending and active authorizations to reduce the volume of outdated or irrelevant information shared between payers. This documentation would include the date the prior authorization was approved, the date the authorization ends, as well as the units and services approved and those used to date.

CMS is also seeking comment for possible future rulemaking on the following:

  • The extent to which CMS should consider explicitly requiring payers to demonstrate that they have reviewed and considered these previous prior authorization decisions and associated clinical documentation from a patient’s previous payer before requiring patients to undergo a new prior authorization process.
  • Whether to, in the alternative, require payers to honor a previous payer’s active prior authorization decisions at the time the enrollee moves from one payer to a new payer for some length of time, such as 30, 45, or 60 days, or if there are situations in which this may not be possible or appropriate and why.

CMS is proposing the same content and compliance with the same technical standards, the same documentation requirements, and the same discontinuation and denial of access requirements for the Patient Access API and the Provider Access API as they are proposing for this proposed Payer-to-Payer API, to ease the burden for payers in developing and implementing these various APIs.

CMS is proposing a new Payer-to-Payer API data sharing opportunity that would be offered to all patients receiving coverage from a payer impacted by this proposed rule as an option at the time of enrollment with a new payer, if both the current payer and new payer would be subject to the requirements in this proposal. CMS is proposing that this exchange be offered to patients receiving coverage from payers as an option when they enroll with a new payer. The new payer could then request the data from the previous payer for patients who opt-in to this data sharing via the Payer-to-Payer API.

CMS is proposing that if a patient enrolls during a specified annual open enrollment period, or, for a payer that does not have such an enrollment period, during the first calendar quarter of each year, and opts-in to having their new payer obtain the applicable data from their previous payer at this specified time, impacted new payers would be required to request such data from the previous payers within one week of the end of the enrollment period or the first calendar quarter of each year. The previous payer would be required to respond to this request within one business day of receiving the request.

Lastly, CMS is proposing to require payers to provide enrollees the opportunity to opt-in to initiate quarterly data sharing. This data exchange among concurrent payers is expected to support better care coordination and more efficient operations.

Updated Jan. 8, 2021