Get Ready for Proposed Changes to Payer-to-Payer Data Exchange on FHIR Regulations

In March of 2020, the Centers for Medicare and Medicaid Services (CMS) issued its “Medicare and Medicaid Programs; Patient Protection and Affordable Care Act; Interoperability and Patient Access for Medicare Advantage Organization and Medicaid Managed Care Plans, State Medicaid Agencies, CHIP Agencies and CHIP Managed Care Entities, Issuers of Qualified Health Plans on the Federally-facilitated Exchanges, and Health Care Providers” (or more commonly referred to as the “Interoperability and Patient Access”) final rule. This final rule required federally-funded payers to ensure that individuals had better access to health information by requiring these payers to create and maintain certain APIs, namely the Patient Access and the Provider Directory API, and to participate in Payer-to-Payer (P2P) Data Exchange. 

In December of 2022, CMS issued a proposed rule that sought to not only expand the required APIs an eligible payer must maintain in support of interoperability, but also made material amendments to the Payer-to-Payer Data Exchange requirements. This blog covers the key differences between the current Payer-to-Payer Data Exchange requirements and the newly proposed Payer-to-Payer Data Exchange on FHIR requirements, and provides guidance around  what actions eligible payers should be thinking about today in preparation for these new requirements. 

CMS Proposed Rule: A Summary of the Key Changes

How: As the name implies, the first key difference between Payer-to-Payer in the proposed rule versus the final rule is the requirement for transactions between payers to be done via a FHIR API. The current Payer-to-Payer Data Exchange only required eligible payers to maintain and make clinical data available, but did not specify the specific methodology for doing that. 

Who: The proposed rule also expanded this requirement beyond just Medicare Advantage (MA) plans, the only group required to meet the Payer-to-Payer Data Exchange in the final rule. The proposed rule and the requirement to maintain a FHIR API to support Payer-to-Payer Data Exchange now includes (in addition to MA plans) State Medicaid plans, Children’s Health Insurance Program (CHIP) plans, and Qualified Health Plan (QHP) issuers on the Federally-Facilitated Exchanges (FFE). 

What: In addition to expanding the class of payers covered by this requirement, the proposed rule also expands the data elements to be shared by the payer via the FHIR API. The final rule only required payers to share clinical data for any encounter with a date of service on or after January 1, 2016. The proposed rule now includes the requirement to share clinical, claims, and encounter data for any encounter with a date of service on or after January 1, 2016, as well as any prior authorization data for any active prior authorization or for any request where the date of last status change was less than one (1) year prior.  

As used herein, “Clinical data” includes any data that fall within one of the data classes under the Content Standard at 45 C.F.R. 170.215, which is currently United States Core Data for Interoperability (USCDI) v.1; “Claims data” includes any data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal; “Encounter data” includes any data related to an encounter with a capitated provider; and “Prior Authorization data” includes any data related to a prior authorization request and decision, such as status of request, date of approval or denial, duration of approval, reason for denial, items or services being approved, and/or any other documentation provided by the provider in support of the request. 

When: Perhaps the biggest and most impactful change in the proposed rule is when information has to be requested from the member’s previous or concurrent payer. In the final rule, the requirements around data exchange were more focused on the payer responding to a request, such that if either an active member (or his or her personal representative) or a previous member with a disenrollment date within the previous five (5) years from the date of request, requested from such payer to share his or her data with its current or concurrent payer, then the payer to whom the request was made would need to make all clinical data maintained on behalf of such member available to the receiving payer identified by the member. 

In the proposed rule, while the responding payer is still obligated to provide data requested via a valid request within one (1) business day, there is the additional obligation on the requesting payer to obtain all the required information, as well as consent, from the new member during enrollment. In addition, after receiving such information and consent, the payer is now required to actively request the information from any identified former or concurrent payer within one (1) week from either the start of coverage or the date the payer received the appropriate information and consent, whichever ever occurs later. 

While this change not only requires payers to make adjustments to their enrollment processes to accommodate the need to obtain both information on the enrollee’s former and/or concurrent payers, as well as consent, the proposed rule expanded a payer’s reactive requirement to respond to a valid request, with a new proactive requirement to actually make a request on behalf of the member. 

In addition, while only federally-funded payers are required to maintain an API, a requesting payer is still required to request the information from a commercial payer (even if they are not required to respond to such request) if one is identified by the enrollee, and a responding payer is similarly required to provide information if a valid request is made by a commercial payer (even if they are not required to request such information). So long as a requesting payer includes a valid attestation with a request for data that affirms that the member is in fact enrolled with the payer and has opted into data exchange, the responding payer must respond to the request.   

The other interesting aspect of the changes made in the proposed rule is that even though this is still an opt-in model, in that the payer needs to obtain the enrollees’ consent first, the actual request for information is triggered not by the member, as implied in the final rule, but rather by the requesting payer. While this may feel like a small nuance, the implications of this on the process of how requests for information are made could be quite impactful. Instead of it being a member-driven process like what we see with the Patient Access API, a payer could instead leverage a more population- (or roster-) driven process, especially in regions where there are limited plans and it’s likely that multiple enrollees will identify the same plan as a former or concurrent plan. 

Payer-to-Payer Data Exchange (CMS Final Rule 2020) Payer-to-Payer Data Exchange on FHIR (CMS Proposed Rule 2022)
Methodology not specified
MA, Medicaid, CHIP, and QHP on the FFE
Clinical data
Clinical, Claims, Encounter, and Prior Authorization Data
At the request of an active member or previous member who was an active member within the last five (5) years from the date of request
One (1) week from the latter of (a) start of coverage or (b) the date the payer has obtained the necessary consent and information to make the request
Effective Date
July 1, 2022 (not enforced)
January 1, 2026


Actions Eligible Payers Should Be Taking Now

 While January 1, 2026 (assuming that is the finalized effective date of such regulation) feels like a far off date, the impact of the proposed Payer-to-Payer on FHIR Exchange requirements are more than just technical. In preparation for the final rule, there are certain actions payers should be thinking about today:

  1. Eligible payers are not only required to think through what changes need to be made to their enrollment processes to allow enrollees to both easily share previous and concurrent payer information and consent to data sharing within the Payer-to-Payer Data Exchange on FHIR framework, but they are also going to need to define a process to obtain this information from current members before January 1, 2026. To avoid having to go back to current members prior to 2026, payers should consider making changes to their enrollment processes for the 2024 – 2025 period to ensure such information is obtained in advance and to reduce the administrative burden of having to recollect such information. It is important to call out that while payers need a prescribed opt-in process, they also need to be provided an opt-out process as well. 
  2. Payers are also going to need to create content and collateral for members with information around the benefits of participating, as well as the ability to opt out of such participation and how to do it. This information will need to be updated and provided annually.
  3. In order to materially reduce the administrative burden of making duplicative requests to the same payers identified by enrollees, eligible payers should consider mechanisms or tools to support the ability to group or cluster members across identified former plans. Any roster- or population-level attribution mechanism submitted to a payer would still need to include a valid authorization or attestation as outlined above.  However, being able to effectively streamline the requesting process will materially improve the payer’s efficiency, thus allowing them to meet the proposed one (1) week timeframe, while also substantially reducing their need for administrative resources and associated costs.
  4. In addition to needing to have a mechanism to transform clinical, claims, encounter, and prior authorization data into the standard FHIR format so it can be made available via a FHIR APIs, payers are also going to need to make decisions around both what data to store and for how long. While the proposed rule removes certain requirements around how long data should be stored beyond compliance with applicable law, unlike the final rule, which required payers to store data for disenrolled member for up to five years from the date of disenrollment, eligible payers will need to ensure all data storage policies are up-to-date and all data storage is done in compliance with policies. As an aside, this may be an area where there is some discrepancy between the proposed rule and what is ultimately finalized as CMS did provide some commentary in the proposed rule that contemplated setting a prescribed storage period. 
  5. Lastly, for patients with concurrent coverage, payers are going to need to create a process that supports more than one data pull. The proposed rule currently requires payers that are providing coverage to the same member to exchange (both send and receive) information with each other on a quarterly basis. 

Final Thoughts on the Proposed Changes to P2P Data Exchange 

Since the regulation is still in proposed status, it is really important to remember that we could see some variation between what has been proposed and what is ultimately finalized. 

At this point in time, the proposed rule is currently in the Office of Management and Budget (OMB). It is likely that a final rule could be released any day now. Once released, we will update you on any relevant changes and will continue to support you through your compliance journey. 

Stay tuned for more information and make sure to visit 1upHealth’s Modern Interoperability Resource Center as we will continue to update that with additional content. 

Share with your community

Sign up to get the latest insights and updates from 1upHealth