On December 8, 2021, CMS announced its decision to exercise enforcement discretion to not take action on certain payer-to-payer data exchange provisions of the May 2020 Interoperability and Patient Access final rule (CMS-9115-F) until identified implementation challenges could be addressed in future rulemaking. The CMS Interoperability and Prior Authorization final rule (CMS-0057-F), released on January 17, 2024, addresses those challenges with its Payer-to-Payer API policies. For additional information on these policies, please refer to the final rule and fact sheet at https://www.cms.gov/priorities/key-initiatives/burden-reduction/policies-and-regulations/cms-interoperability-and-prior-authorization-final-rule-cms-0057-f

No. If a patient’s previous or concurrent payer is not an impacted payer, that payer would not be required to send data through the Payer-to-Payer API under the CMS Interoperability and Prior Authorization final rule (CMS-0057-F). However, we encourage all payers to implement a Payer-to-Payer API that allows patients to opt in to the data sharing with another payer, as long as there are no conflicts with other Federal or state laws, so that all patients, providers, and payers in the healthcare system may ultimately experience the benefits of these policies.

For more information on best practices for patient messaging related to the Payer-to-Payer API, please review our Best Practices Document found here (PDF).

Yes. Each impacted payer is responsible only for its own side of the transaction. For instance, when an impacted payer is required to request patient data from another payer, it must do so regardless of whether the other payer is an impacted payer (a status that may or may not be evident to the requesting payer). Similarly, if an impacted payer receives a request for patient data that meets all the requirements, the impacted payer must share those data, regardless of whether the requesting payer is an impacted payer (which, again, may or may not be evident to the payer sharing the data). In this way, payers not subject to this regulation that implement a Payer-to-Payer API (or other IT functionality to request or receive information through the impacted payer's API) and their patients can also benefit from the data exchange.

For more information on best practices for patient messaging related to the Payer-to-Payer API, please review our Best Practices Document found here. For more information on best practices for patient messaging related to the Payer-to-Payer API, please review our Best Practices Document found here (PDF).

It could be helpful for payers to supplement the data exchange required under this rule to account for any claims or data that are received after the initial data are sent to the new payer. While it is not required, we encourage payers to do so in order to pass along a complete patient record. Likewise, we encourage the new payer to send an additional request for data within 90 days of receiving the initial data response. The previous impacted payer would be required to respond to such a request.

For more information on best practices for patient messaging related to the Payer-to-Payer API, please review our Best Practices Document found here (PDF).

Impacted payers must incorporate into the payer’s patient record any data they receive through the Payer-to-Payer API. Once the information is incorporated into the patient’s record, it must be made available via the Patient Access, Provider Access, and Payer-to-Payer APIs, as appropriate. When incorporating data from a previous or concurrent payer, payers are free to indicate the provenance of that information in metadata, which would then be included when the patient, provider, or another payer accesses the data. As discussed in the CMS Interoperability and Prior Authorization final rule (89 FR 8945), we are recommending the PDex Implementation Guide for the Payer-to-Payer API to support the creation of provenance information.

For more information on best practices for patient messaging related to the Payer-to-Payer API, please review our Best Practices Document found here (PDF).