What payers need to know about CMS’ Payer-to-Payer Data Exchange requirement

How do you comply with a mandate that is not explained? That is a challenge payers face with only a few months to meet the current January 2022 deadline for the Payer to Payer Data Exchange, another part of the CMS/ONC Interoperability rule. CMS and ONC have not provided straightforward requirements, with partial references to this mandate badly scattered across the 900+ pages of regulation and lacking in vital details and much needed clarity.

Before examining the rule in detail, payers should avoid confusion regarding a proposed change to this part of the rule. In December of 2020, CMS issued proposed rule CMS-9123-P. Recognizing the insufficiency of the current (final) interoperability rule around the Exchange, the December proposed rule outlined requirements that were clearer and more actionable and delayed the deadline until 2023. Unfortunately, the proposal was issued after the 2020 elections and did not survive the change in administration. Instead of hoping for any possible delay, payers should act on the information they have today to comply with the rule.

What is Clear

There are elements of the final rule that are quite clear. Beginning on Jan. 1, payers regulated by CMS (Medicare Advantage, Managed Medicaid, CHIP, and Federal Exchange QHPs) must exchange the USCDI v1 data set, in electronic form, at the patient’s [member’s] request. It is a one-time, not continuous, data exchange. The goal is to allow the member to take their data with them as they move from Sending Payer (insurer with data) to Receiving Payer, creating a cumulative data set. [USCDI

As members move across plans over time and request data among the Sending and Receiving Payers, they create a “chain” of data transfers, and the plans become “links in the chain.” CMS intends that the data become a cumulative record as it moves among plans.

What is Unclear

Creating requirements from this rule will be a challenge. There is much unsaid that may prevent successful compliance efforts from accomplishing CMS goals.

CMS clearly prefers to make this an extension of the technology mandated for the Patient Access API. The rule states that APIs are a desired method for payer-to-payer transmission; CMS sees the value of repurposing the Patient Access API.

How can the Exchange be implemented by API? If CMS specified that the member make the request to the Receiving Payer (and not the Sending Payer), this would be straightforward. But the member request goes to the Sending Payer, which owns the mandate to move the data. The barrier is technology: It is unclear how either streaming or pub/sub (asynchronous messaging) can be established (absent additional federal standards) across our many-to-many-node payer industry to meet the requirement.

We know that CMS intended the use of APIs. Specifically, when the Sending Payer is a link in the chain and receives data from a previous plan via FHIR API, the rule requires the data be sent down the chain to the next Receiving Payer in the same format. If the Receiving Payer cannot accept it in the API, the Sending Payer is only required to share data via the Patient Access API that the Sending Payer already maintains and has prepared to otherwise be shared via FHIR-based API.

The industry cannot be asked to “figure it out” without more guidance.

• There is no standard for the method members should use to request that the Sending Payer initiate the exchange.
• It is unclear if the Sending Payer can require the member to access a portal and/or provide their member ID to initiate the request.
• There is no understanding on any of the timing requirements.
• Should either plan communicate with the member during and after fulfillment by either plan? If so, then how?
• If APIs cannot easily be used, what method of coordination should the Sending and Receiving Payers use?
• If the Receiving Payer does not have the member enrolled, what do they do with the data?

Most critically, what limits exist on the form or delivery method of the data? The rule only specifies that the transfer be electronic and cover the data elements in USCDI. But how should plans send it? Should they use digital endpoints like a Direct Address and/or a FHIR API endpoint? Without guidance, every Sending Payer could create its own method for sending data and each Receiving Payer must be equipped to handle it.

What Should Payers Do?

Payers must decide whether they want to become compliant to address the spirit of the rule or whether they want to take the shortest path to being compliant. The latter involves the following:

• Sending Payer
  • Create a basic physical representation of the USCDI for a single member out of the dataset used to meet the Patient Access API of the data created by the Sending Payer – a simple XML or CSV file
  • Assign staff to manually fulfill a member’s request:
    • Create the file of Sending Payer-created data
    • Check if this member had data sent to the Sending Payer previously as a link in the chain (and thus this is a serial data transfer); if so, make a copy of the electronic artifact used when it was received by the Sending Payer
    • Contact the Receiving Payer to arrange delivery in a HIPAA-secure manner, transferring the Sending Payer file including any “link in the chain” data

• Receiving Payer
  • Assign staff as the designated reception point for any incoming files:
    • Determine the best way to store within the Receiving Payer, meeting the requirements of “incorporated”
    • Retain the original file, for resending in the event of a serial data transfer

Such a manual workflow would certainly not well-realize the vision of CMS to create a cumulative data set. However, the volume is likely to be low and a plan compliance team may deem that approach is suitable.

For a plan to realize the vision of CMS, the USCDI data needs to be expressed and transferred using the FHIR format and API methods, despite the challenges listed above. The sending and receiving payers can coordinate with each other, to allow the receiving payer to call the Patient Access API of the sending payer.

Is This Rule Even Needed?

If a member wants a longitudinal record, or if a Payer wants to access historical member data, the Patient Access API now exists and is far superior to the Payer to Payer Data Exchange. It includes the USCDI but also a large volume of administrative data. It is well standardized. While both approaches are based on member action, using the Patient Access API would allow the Receiving Payer to organize the effort to get consent at scale, resulting in a meaningful flow of inbound data that will be more useful to the Receiving Payer and would justify the work to utilize the inbound data.

The healthcare industry stands at a transition; from a world where data was siloed to a world where it flows. As plans struggle to decide how to comply with a badly-worded portion of the final rule on interoperability, they should be thinking about the broader changes at work and whether their choices now prepare them for the world ahead.

This post appears through the MedCity Influencers program. Anyone can publish their perspective on business and innovation in healthcare on MedCity News through MedCity Influencers. Click here to find out how.