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

1

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

2

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

3

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

4

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