17 May, 2024 | 3 min read

Enhancing Interoperability and Streamlining Prior Authorization: A Look into CMS-0057-F

  • Nirmal Fernando
  • Associate Director/ Architect - WSO2


The Centers for Medicare & Medicaid Services (CMS) has taken a significant step forward in advancing interoperability and improving prior authorization processes with the publication of the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F). This rule imposes requirements on various healthcare stakeholders to implement Health Level 7® (HL7®) Fast Healthcare Interoperability Resources® (FHIR®) application programming interfaces (APIs) to facilitate the exchange of health data and streamline prior authorization procedures. Building on the technology foundation established by the CMS Interoperability and Patient Access Final Rule (CMS-9115-F), this rule is expected to further enhance these efforts. This first post provides an overview of the key provisions outlined in CMS-0057-F and their implications for impacted payers and healthcare providers. In our upcoming series, we will delve deeper into the technical details of the rule.

Applies To

  • Medicare Advantage (MA) organizations
  • State Medicaid and Children’s Health Insurance Program (CHIP)
  • Fee-for-Service (FFS) programs
  • Medicaid managed care plans
  • CHIP managed care entities
  • Qualified Health Plan (QHP) issuers on the Federally Facilitated Exchanges (FFEs)

Key Provisions




What needs to be done?



Patient Access API

Give patients access to their own health information via health apps.

  • The HL7® FHIR® Patient Access API should be in place as part of the CMS-9115-F final rule. 
  • As part of the new rule, we need to add information about the prior authorizations to the data available via the Patient Access API. It should follow the United States Core Data for Interoperability (USCDI) v3, where a new health insurance information data class has been added.

(1) The prior authorization status.

(2) The date the prior authorization was approved or denied.

(3) The date or circumstance under which the authorization ends.

(4) The items and services approved (excluding drugs).

(5) If denied, the specific reason why the request was denied.

  • Should respond no later than 1 business day after the payer receives the prior authorization request or there is another status change for the prior authorization.
  • Prior authorization information must be shared while the prior authorization is active and for 1 year after the last status change. Full prior authorization history is not required.

January 1, 2027

  • Metrics need to be reported to the CMS annually.
  1. The total number of unique patients whose data are transferred via the Patient Access API to a health app designated by the patient; and
  2. 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.

Note: The CMS will issue specific format and process guidance for submitting Patient Access API metrics before reporting is required.

January 1, 2026


Provider Access API

Makes patient data available to providers who have a contractual relationship with the payer and a treatment relationship with the patient. 

Patients should be able to opt out of the Provider Access API (by default opt in).

  • Claims, encounters and information about prior authorization have to be shared through this API similar to Patient Access API. 
  • Applicable patient data with a date of service on or after January 1, 2016.
  • Unlike the patient access API, this API would not include provider remittances and patient cost-sharing information.
  • Should respond no later than 1 business day after receiving a request from a provider who meets all other requirements to access the data.
  • The CMS did not propose a prohibition against payers charging providers a user fee to access their APIs.

January 1, 2027


Payer to Payer API

Data exchange among payers, specifically, sending patient data from a patient's previous/concurrent payer(s) to their new one, to ensure that patient information follows them through the healthcare system and improve care continuity.

  • Impacted payers to implement and maintain a payer-to-payer API using the FHIR standard. Shared data includes claims, encounter data, USCDI elements, and certain prior authorization information (excluding provider remittances and patient cost-sharing information). Refer to the Patient Access API.
  • Need to exclude the denied prior authorization data and the limitation to data within 5 years of the request.
  • The process of getting previous/concurrent payer info should ideally take place through an established point of contact with the patient to reduce the burden.
  • Patients are opted out from this API by default and must opt-in explicitly for their data to be shared between payers. However, patients declining to opt-in to the payer-to-payer API policy won't necessarily prohibit payers from using other permissible bases like the TPO (Treatment, Payment, and Operations) to disclose PHI.
  • It requires impacted payers to request data from a patient's previous/concurrent payer(s) no later than 1 week after the payer has sufficient identifying information and the patient has opted in, or within 1 week of a patient's request.
  • Requesting payers should use a combination of “must support” data fields (e.g., patient name, addresses, birth date) in USCore and PDex IGs in order to implement patient matching. 
  • Existing requirements require payers to make technical documentation about their API, including digital endpoint information, on a publicly accessible section of their website. When NDH comes into play, that could serve as a centralized place for impacted payers to find other payers' digital endpoints.
  • Bulk Data Access IG adopted as required IG for exchanging multiple patients' data simultaneously for system to system data exchange.
  • Use of Bulk Data Access IG, which is a required IG for the payer-to-payer API, contains a “SHOULD” (that is, strongly recommended) conformance statement to use SMART Backend Services for authentication and authorization.
  • An attestation must accompany the request for data, affirming patient enrollment and opt-in. PDex IG supports this with the use of consent resource and other resources in the member match request and CMS recommends to use a standard IG for the attestation.
  • The response timeframe for data exchange will remain at 1 business day as other APIs (Patient/Provider Access).
  • Payers will need to determine the data permissible for sharing via the payer-to-payer API. They are encouraged to develop processes that flag certain data elements requiring special permissions or prohibited disclosure under other laws.
  • New payers are encouraged to send an additional data request within 90 days of receiving the initial response. Previous impacted payers are obliged to respond to such additional requests for data.

January 1, 2027


Prior Authorization API

Streamline the prior authorization process and ensure that payers use technology to provide more useful information about when and how to obtain a prior authorization and the status of an approved or denied prior authorization. 

  • Allow a provider to query the payer’s system to determine whether prior authorization is required for certain items and services and identify documentation requirements. 
  • Prior authorization requests would be sent from the provider’s EMR or practice management system. 
  • Response from the payer side should either indicate whether the payer approves or denies the PA request or the fact that the payer requires more information from the provider to support the request. 
  • Does not have to be real-time. 
  • Prior Authorization API should be working with FHIR. In order to perform coverage requirement discovery, the payer system needs to support CDS Hooks. Payers also need to host a SMART app that launches from the Provider EHR - the app should contain the questionnaires related to coverage requirements. 
  • If the underlying payer systems understand only X12 not FHIR, then the payer should have an integration layer to transform the Prior Authorization request from FHIR to X12 278/275s and the response from X12 278 to FHIR. 

January 1, 2027

Required Standards

Implications and Future Directions

The implementation of CMS-0057-F holds significant implications for stakeholders across the healthcare ecosystem. By promoting interoperability and streamlining prior authorization processes, the rule aims to enhance patient care, improve care coordination, and reduce administrative burdens. Healthcare organizations and technology vendors will need to collaborate effectively to implement FHIR APIs and ensure compliance with the rule's requirements. Additionally, ongoing monitoring and evaluation will be essential to assess the impact of these initiatives and identify areas for further improvement.

Impact for Providers

While providers are not required to use the Prior Authorization API by this Final Rule, the CMS is incentivizing providers to use this API by finalizing new electronic prior authorization measures for MIPS eligible clinicians under the MIPS promoting performance category and for eligible hospitals and CAHs under the Medicare Promoting Interoperability Program.


CMS-0057-F represents a critical milestone in the journey towards achieving interoperability and optimizing prior authorization processes in healthcare. By mandating the use of FHIR APIs and introducing measures to incentivize electronic prior authorization, the rule lays the groundwork for a more connected and efficient healthcare ecosystem. As stakeholders work towards implementation and compliance, collaboration and innovation will be key to realizing the full potential of these initiatives and driving meaningful improvements in patient care and healthcare delivery.

We at WSO2 are ready to help you in your journey towards the CMS compliance by providing you an Internal Developer Platform with a set of prebuilt integrations that will help you to comply fast. Please visit our web page or contact us.