The Future of Payer Data Exchange

PDex is changing the game, Flexpa is making the game easy.

Flexpa's existing claims data network allows payers to access fast, identified, patient-consented, historical claims data. Today, that happens through our connectivity to a network of payer Patient Access APIs. The upcoming Payer-to-Payer API mandates in CMS-0057-F will make it even easier to access that data through Flexpa.

Flexpa is at the forefront of understanding the power of fast, identified, patient-consented claims data interoperability. We see how access to this data can actually improve the patient experience, and we want to do more. 

Flexpa attended the 2024 CMS HL7 Fhir Connectathon DaVinci PDex Track last month. We learned so much about some of the upcoming APIs, how they are being implemented right now, and the future of  Interop with UDAP and TEFCA.

Upcoming APIs

Part of improving the patient experience means working within the standards community to create, edit, and test new and upcoming interoperability standards. Some of the most exciting and relevant upcoming changes are surrounding the Payer Data Exchange (PDex) and the APIs detailed in the Implementation Guides. 

CMS-9115 and CMS-0057 together mandate a system of APIs meant to facilitate the sharing of claims data between providers and payers.

We think PDex is going to change the way claims data is shared. That’s why we recently participated in the 2024 CMS HL7 FHIR Connectathon on the Da Vinci PDex Track along with vendors and payers like 1up Health, Onyx Health, Optum, Aetna, CVS, and Elevance. This track was set up to test a few very important connection points required by CMS-0057:

1. Payer-to-Payer API

2. Provider Access API

In developing both of these APIs, CMS-0057 strongly recommends that payer implementers follow several FHIR Implementation Guides (see below). The CMS Connectathon track we attended specifically focused on Da Vinci PDex IG Version STU 2.0.0.

Current API Implementation Experience

Flexpa came to the Connectathon prepared to be a client in several different Payer-to-Payer scenarios. In this test scenario, there were several FHIR server implementations that supported the Payer-to-Payer Bulk and Single member match. Flexpa’s client was able to connect to these FHIR servers and pull data. 

Single Member

When a FHIR server requires HRex Member Match Operation 1.0.0 to query the existence of a member, the process is as follows:

1. Submit Demographics, previous payer member number, current payer member number, and a consent collected by the new payer (our client), receive a member identifier

2. Query for a patient with that identifier

3. Fetch resources for that patient

When a FHIR server requires HRex Member Match Operation 1.1.0 to query the existence of a member, the process is as follows:

1. Submit Demographics, previous payer member number, current payer member number, and a consent collected by the new payer (our client), and receive a Patient Reference

2. Fetch resources for that patient

Bulk Member

There were a few implementations that supported the Bulk Member Match Operation. Flexpa was able to integrate with one of those API implementations to pull member data in bulk. That process was as follows:

1. Submit Demographics, previous payer member number, current payer member number, and a consent collected by the new payer (our client) for each member (bundle of bundles)

2. Receive a list of matches, non-matches, and a group ID

3. Execute a $davinci-data-export operation to fetch matched member data in bulk

The Future of Interop

The Pains

Authentication and Authorization

Across the entire Connectathon, authentication and authorization were side-stepped. Based on my conversations with participants, auth was omitted because it makes it difficult to do connections at this stage of the IG. While I think that’s a valid point, I wonder why we are leaving the testing of authentication and authorization as details at the end. I can only assume authentication and authorization were defined just broadly enough and just ambiguously enough, that it would make it difficult to try to test connections using the recommended methods. 

According to some information buried in the Payer-to-Payer Single Member IG, there will need to be a trust framework established to identify endpoints, enable dynamic registration, and ultimately remove humans from much of the registration and authorization process. The Trusted Exchange Framework and Common Agreement (TEFCA) or the FAST National Directory is meant to support the discovery of payer endpoints. Unfortunately, neither is ready to step into this role yet. It’s likely that these missing parts have slowed the implementation of authentication and authorization in current FHIR implementations. The authors of this IG have suggested another solution to build a temporary trust network for endpoint discovery, but that, also isn’t set up yet.

Once an endpoint is discovered, the IGs suggest using the Unified Data Access Profiles developed by the FHIR at Scale (FAST) task force to dynamically register a client using a publicly hosted JSON Web Key Set (JWKS). This part of the authentication and authorization process is probably the most well defined and ripe for pushing forward with testing.

Given the lack of clear support for recommended authentication and authorization strategies, I think it’s difficult and imprudent to implement these for testers. I also think it’s important to do difficult and imprudent things to move a standard forward. I didn’t expect anyone to try implementing UDAP in this Connectathon, but, luckily, our friends over at Firely had been working on implementing parts of the Authentication and Authorization strategy and had a server we could test against. Initial testing of previously untested processes provides us and the rest of the standards team with invaluable feedback. We get to understand the difficult parts, adjust the impossible parts, and build something that hasn’t been built before. Neither Flexpa nor Firely had a full implementation but we are excited to be pushing the boundaries of authentication and authorization using UDAP.

API Implementation

Both the Provider Access API and Payer-to-Payer API are meant to support the transfer of claims data at very important events in the life of a patient. These are also very important moments for payers and providers. Having these APIs will make it simpler to connect to a single payer to pull historical data.

Unfortunately, the payer space is really big and implementation variance seems inevitable despite the promise of ONC’s HTI-2 requirements creating a dual compliance mandate. Flexpa expects that payers who want to adopt an opportunity mindset vs. treating Payer Data Exchange as a compliance checkbox will quickly need to find partners to develop network connectivity.

In any given enrollment period, members could come from any number of payers. Each historical payer represents a new set of connections that have to be implemented. Every patient onboarding at a provider’s office could present a new payer from which to pull data. Even though the process will be simpler, due to the simple consent model required by CMS-0057, it won’t be easy.

Even in the small sample set of a Connectathon track, there were 4 different implementations of the Payer-to-Payer API using 2 different versions of the HRex Member Match Operation. Working with these industry partners allowed us to build a client that could connect to all 4 implementations and pull data! 

The Joys

We deeply know the pain of connecting to multiple implementations of the same API. We have connected to over 200 Payer Patient Access APIs. We have seen the effort it takes to build relationships with implementing teams and understand their decisions regarding their APIs. We know how frustrating it can be to build flexibility for all the variances in these connections. Yet, we have delivered fast, identified, patient-consented claims data from those same APIs more than anyone else. Ever.   

The new Payer-to-Payer and Provider Access APIs will make it much simpler for Payers and providers to access data at specific patient/member events. Flexpa makes it easy to connect to hundreds of other payers to get claims data.

We fought hard for our experience, and we want to share it with you. If you have a Patient Access, Provider Access, or Payer-to-Payer API you are implementing or thinking about implementing, reach out to us at interop@flexpa.com! We’d love to talk about it, share our experience, test it with you, and build a better patient experience together!