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.