By using a data store vs. an API façade to exchange health data, payers can go beyond compliance, to exceeding member experience expectations.

What if all the health data your insurer has collected about you could be transferred seamlessly to your next insurer? Imagine prior authorizations rolling over automatically, instant enrollment in care management, elimination of phone calls, faxes and wait time. 

These are just a few of the possibilities that can become reality as payers work to meet the Payer-to-Payer Data Exchange requirements of the Interoperability and Patient Access final rule. Health plans will soon have the opportunity to receive a member’s historical care information from a previous plan and apply workflow and analytics to improve the enrollment process, utilization management, risk modeling and more.  

Complying with the Payer-to-Payer Data Exchange requirement presents a significant operational challenge, evident from the FAQs and other support documents prepared by The Centers for Medicare & Medicaid Services (CMS). Health plans should be prepared to manually send and receive member data from other plans through a Secure File Transfer Protocol (SFTP), among other means, to support compliance with and meet the Jan. 1, 2022 Phase 1 deadline.

By 2023, these data transactions go digital, and health plans will be required to use the SMART on FHIR® framework and FHIR® bulk data access.

The best option for health data exchange

Broadly speaking, there are two ways to comply with the Payer-to-Payer Data Exchange requirements: an API façade or a data store. Although the façade is the quicker and easier approach, the data store is far superior in terms of the greater benefits it offers over the long term.

Here’s how each option breaks down:

• API façade. With an API façade, required data is transformed into the HL7® FHIR® standard in real-time upon request, and then served via an API. Although the API façade can deliver the data when and where it’s needed, it has some shortcomings.
  
  First, it’s inefficient and can create a bottleneck when pulling the data out of the systems of record and translating it on-demand. This bottleneck makes it challenging to achieve the high data availability necessary for moving large sets of administrative and clinical data between plans. Second, while it will enable compliance with Phase 1, it will not meet the requirements of Phase 2.
  
  Health plans will likely want to store the “received” data separately from the member data they generate. But they will be required to make the received data available to the Patient Access API and will want to layer on analytics to take advantage of this new historical information. To accomplish all of this with an API façade, they’ll need to significantly rework their interoperability infrastructure. In short, we believe the short-term gain of an API façade for Phase 1 compliance is not worth the long-term pain and expense.

• HL7® FHIR® standard data store. With this approach, a data store holds the required data in the HL7® FHIR® standard for delivery upon request, then serves that data via an API. This is a more efficient approach for storing and delivering FHIR data, and it can scale to meet the demands of frequently moving large data sets between plans.
  
  Health plans can keep their data separate from the received data and make both available at scale for sharing with other plans and with third-party apps through the Patient Access API by utilizing data stores. By layering analytics capabilities onto these data stores, plans can derive new insights from the historical data, such as identifying a group of members at risk for diabetes or other chronic conditions. And because a data store can enable compliance with both phases of the Payer-to-Payer Data Exchange requirements, plans may implement the store once, saving time and resources.

Going beyond compliance

When plans consider their options for complying with the Payer-to-Payer Data Exchange requirements (as well as other regulations like the Transparency in Coverage rule or the No Surprises Act), they should identify growth opportunities that go beyond meeting minimum compliance requirements. While data access requirements and compliance options are primarily technical in nature, the plan’s choices for meeting these requirements will significantly affect their members and operations.

By building a data store rather than using an API façade, plans have opportunities to improve the member experience with analytics.  

Consider this scenario: A new member has been using a smartwatch app to manage her health. At enrollment, she opts in to import her health data from her previous plan. She also wants to import that historical data, as well as the data her new plan has collected, into her health app.

By processing these requests through a data store, the plan enables the new member to efficiently access the data she wants. The new plan can also use any data the member is willing to share to build a digital engagement experience that offers the following:

• Support for reaching the member’s health goals, reducing risk and costs for both the member and the health plan
  
  
• Help with understanding plan benefits so the member can select more affordable and higher quality care
  
  
• Improved satisfaction, increasing the likelihood of retaining the member’s business and capturing more value over the lifetime of the membership

The Payer-to-Payer Data Exchange requirements introduce both complexities and opportunities for plans to develop features and services that lead to a richer member experience and competitive differentiation. By using a data store, plans can develop a solution that not only supports compliance but also enables data access capabilities they can build on to exceed members’ expectations, control costs and improve outcomes.