A Business Case For Interoperability

CMS Interoperability and Patient Access Final Rule was developed to connect healthcare technology systems  so members can access their own data. All CMS-backed plans—Medicare Advantage plans, Medicare plans and ACA plans will be required to provide a patient access API, a provider API, and a payer-to-payer data exchange system.

An API is an application program interface. An API is like an electrical outlet—there's a standard shape and size for the outlet and all electrical devices in the U.S. are designed to connect to it. The API is designed to provide the technical ability to access and exchange data in a standardized way.

For the patient access API, this provides the member with a way to access all of their health information from the health plan including clinical data, claims data, enrollment data, etc. The provider directory API provides members with a way to find providers within their health plan and it allows providers with an expedited way to obtain prior authorization. CMS's goal is to incentivize innovation and enhance the member experience. Once the APIs are developed, the industry will have the foundation for continual improvement. The final API is the payer-to-payer data exchange, which provides a connection between health plans so if a member switches plans, their historical data follows them. This will encourage better quality and continuity of care by empowering providers with a full health history, the member retains all of their data, and the plans can identify gaps in care immediately rather than waiting to develop their own historical data. The entire healthcare ecosystem benefits from a collaborative data exchange.

Health plans are facing some challenges with the implementation of interoperability standards. Most health plans are insurance companies and do not have a technology arm. In order to meet the compliance standards, plans must form vendor partnerships that are specialized in technical solutions for government-sponsored health plans. The goal of a 3rd party vendor in interoperability is to: create an environment where PHI is both protected and available, craft a strong authentication layer, shield proprietary information from competing health plans in the payer-to-payer data exchange, and provide an operational ecosystem where data is maximized across different aspects of the business.

Host: Welcome to Episode 12, A Business Case For Interoperability. Today, we’re here with Brian Edwardson, whose longstanding career in healthcare technology, mostly in the quality space, gave him the necessary background to help build out an interoperability product in response to the CMS mandate. Welcome Brian!

Brian: Thanks for the warm welcome. I’m excited to be here.  

Host: So, Brian, CMS’s shift towards member-centricity has been a great reframe for how plans do business in terms of establishing and keeping the core mission at the forefront of every decision. You know, the member. And it’s an exciting challenge to be a part of, trailblazing how to get all aspects of the business to become interoperable and share data. Brian, would you share some of the benefits and challenges of interoperability?  

Brian: Yeah, to start, let’s talk about what it means to be interoperable. It’s really the connection of systems, and this isn’t anything new; other industries have been doing it for a while. For example, when you go to book airline tickets and all of the prices for flights are aggregated to one website—this is a form of interoperability because multiple systems are talking to each other. Another example is mint.com. You can log in to one place and see all of your financial data: bank accounts, investments, 401K. When it comes to healthcare, there’s a big initiative from CMS, Centers for Medicare and Medicaid Services, to incentivize the connecting of healthcare systems so that the end user, the member, has access to all of their data, creating a longitudinal health record. The idea is that if some entity has a piece of your data, then CMS believes that you should also have the ability to access that data. It sounds simple in theory, but in reality, to do that, a lot of pieces need to be tied together: providers, clinics, health plans, etcetera—to make them interoperable. The big initiative from the CMS Interoperability and Patient Access Final Rule was to mandate all CMS-backed plans in the nation—so that’s all Medicare Advantage plans, most Medicaid plans, and ACA plans, to provide a patient access API, a provider API, and a payer-to-payer data exchange system. This means those health plans are required to provide an endpoint so other applications can consume that data with the member’s permission. The main goal is to unlock this data and create a landscape of potential innovation for new technology and applications to come in and make that data accessible to the individual.  

Host: Thanks, Brian. That provides a good understanding of what it means to be interoperable and why it’s important. Let’s dive into the specifics of the CMS mandate and what’s involved for health plans to make this a reality.  

Brian: CMS has mandated three things: a patient access API, a provider directory API, and a payer-to-payer data exchange. Let’s start by talking about the APIs, application program interface. What that means is that you’ve built a technical ability for an external application to access data in a standard way. Think of an API like an electrical outlet. In the US, for example, there is a standard plug shape and a standard amount of electricity allowed through the connection. Setting this simple standard allows for a wide variety of electronics to be available to the entire US population. Without this standard, the ability to build and sell all of these electronics would be limited.  An API is the same concept—the goal is to give a standard endpoint so the external system can recognize it, read it, and understand what it is… to pull data in a standard way. So, the patient access API gives the ability for external applications to pull data from health plans with the member’s consent to do so. The data required to be available via the Patient Access API covers the full spectrum of data a health plan may have including clinical data, claims data, enrollment data, etcetera. All of the data that health plans have related to a member needs to be available via the patient access API.  

The provider directory API is similar, although a little less complicated. But it’s the same idea that data should be available to all members. The provider directory is exactly what it sounds like; it is all of the provider data for the providers throughout the system that are within the health plan. An example of a use case would be if an application developer wanted to build out a provider locator tool to see if the provider is within a certain network; they could connect the app to multiple health plan provider directory APIs. And then you could simply log in and see all of the providers in the health plan’s network. The possibilities of what can be done with these APIs are endless, and that’s the goal of CMS making this a mandate. They’re trying to incentivize innovation by making the data available to external applications, with the goal of enhancing the user experience for the member. The last piece is the payer-to-payer data exchange. This is the connection between health plans. The goal is to allow the data to follow the member across health plans. So, if I move from Blue Cross Blue Shield to Anthem and then the next year I move to United, I have the right to tell my previous plan to send my data over to my new plan. The idea is to keep the historical data of each member intact. There’s a little bit of nuance; the mandate was originally for Q1 of 2022, but CMS has held off on enforcing it, as many plans have asked for more direction on the technical requirements of the rule. However, there are some plans that have fully implemented a solution and have that ability now.  

Host: So, what does that solution look like? Are there any variances in what will be considered acceptable?  

Brian: CMS has actually just announced a proposed rule that provides clarity on how a Payer to Payer Data Exchange should work. Prior to this clarification, though, the required implementation was a bit of a blank check. Some health plans made some assumptions about what they think should be required from a technological standpoint and have already built a solution. Many plans saw that the requirements for a Patient Access API are very similar to a payer-to-payer data exchange. Therefore, they are simply reusing or duplicating their Patient Access API but adjusting it to be available to other health plans to connect and perform a one-time pull of a specific member’s historical data. To generalize, the Patient Access API and the Payer-to-Payer data exchange both provide an endpoint for an external party to access data based on the member’s authentication. The external party for the Patient Access API is a 3rd party application, and the external party for the Payer-to-Payer Exchange is another health plan. Both are accessing almost the exact same data.  

Host: If it’s something that all plans already have set up for patient access API, what’s the level of effort to convert that to a payer-to-payer platform? Brian: So, there is a level of effort there. A significant hurdle for meeting these requirements is the idea of making data available via an external application….it sets off a lot of alarm bells for people who have worked in healthcare for a while. Because there are such strict regulations around PHI, protected health information. A very important layer to the Patient Access API is the member authentication layer. The applications connect to the APIs, but they can’t actually pull data until the member logs into the application and sends authentication to the health plan that it is, in fact, the member. Once the authentication happens, signifying that the member themself has given the permission to share the data, then the data is passed through. So, how is this relevant to payer-to-payer data exchange? Well, it’s the same problem of authentication. In the first example, the application is doing the legwork to drive the authentication and send it back to the health plan. The health plan didn’t have to build that authentication layer. The onus is on the application. But, in payer-to-payer, you have an authentication layer that requires both health plans to confirm that the request came from the actual member and a legitimate health plan. This additional authentication layer adds to the complexity for health plans to implement a Payer to Payer Data Exchange.  

There also has been some nuance about what exact data should be sent. Some health plans feel that certain pieces of claims data are proprietary. That’s not something they want to share with their competitors. However, the latest proposed rule by CMS provides clarity on these items in order to pave the wave for nationwide Payer to Payer Data Exchanges to become a reality.  

Host: Is there an expected date for this enforcement?  

Brian: The newly proposed rule does not provide a specific date for enforcement but given that it seems to clarify the reasons for delaying enforcement in the first place, we can expect the rule to be enforced within the near future. The new proposed Interoperability Rule continues to advance the goal of Interoperability, with a proposed effective date of 1/1/2026. Basically, it provides expanded requirements to the patient access API. A new Provider Access API that essentially allows providers to access the data as the Provider Access API for their patients and a big focus on Prior Authorization requirements/  A large portion of this rule boils down to trying to remove barriers for the prior authorization process. Prior authorization ensures a service is covered by the health plan. The idea is to give providers access to view a member’s benefits and move necessary medical care forward as quickly as possible and not get hung up in authorization delays.

Host: It sounds like a lot of change is happening really fast for health plans. There are all new systems and ways of doing things. What are the challenges that plans are facing to get these platforms up and running?  

Brian: Yeah, that’s exactly right—a lot of change in a relatively short amount of time, and the big problem is that the mandates by CMS are highly technical. At the end of the day, a health plan is an insurance company, and they don’t specialize in technical solutions. So, really, the hurdle is that plans don’t have the technical or even the business know-how to operate as a software-as-a-service model. Most plans do not have a technology arm to meet these mandates. That’s where vendors step in to help with compliance. In today’s world, health plans need vendors to plug their data into the tools for patient access API, provider directories, and payer-to-payer exchange systems. Now, plugging the data into a solution isn’t so easy. So, that’s another hurdle—to package the data and get it to the vendor. This is where it’s nice to have a vendor with multiple solutions for the same line of business. You know, in a sense, the data’s already there within the vendor’s ecosystem. So, it’s more like a flip-a-switch scenario.  

Host: Okay, so we’ve got all of this data now, moving around—and it certainly has its benefits and conveniences, it makes healthcare more thorough when you have a rich history available.  Let’s talk about PHI from a security standpoint. How do you both protect data while making it more available?  

Brian: Yeah, when this mandate came out, a lot of people didn’t understand it because they’d been so engrained in the line of thinking, “ I can never share data with anyone, ever.” And, of course, it’s true that PHI is highly protected data. That still stays the same, that it’s highly protected, but at the same time, the complexity is that it has to be available to the individual whose data it belongs to. A member should be able to access their own data. While I think most people would generally agree on this principle, it can almost be counterintuitive to those who have worked in the industry for so long as it has historically been “protect data at all costs.” " You know? We’re now saying expose that data via an external facing API for all applications to access. But, this is really where the industry needs to re-align its thinking and enable all members access to their data. it’s not as scary as it sounds; there simply needs to be robust data security measures put in place that have been implemented in other industries, such as the financial industry.  

Host: With all of this historical data being aggregated in one place, will this eventually be useful in improving risk, revenue, and quality of care?

Brian: In a world where these systems are working as they should, i.e. payer-to-payer data exchange and all payers are sending all of their historical data to the new payer. In that world, it should greatly increase the ability to provide quality of care, increase Star Ratings, increase member experience and use of the healthcare system, improve risk scores, and align with revenue goals. The idea is—that when a member goes to a new health plan, the health plan doesn’t start from zero anymore. That health plan now has the historical data that came along with the member. Now, on day one, they know what the member’s gaps are and what the member needs to do. In the past, it took a plan 6 months to a year to get enough information on a member to start actually driving initiatives to close gaps and provide them with a higher value of care.

Host: So, essentially, interoperability is a win-win for everyone—members get the data that they deserve, providers are maximally informed and can deliver care more effectively, and plans become better stewards of healthcare.

Brian: Exactly, it’s a win-win.

Host: Brian, it’s been great talking to you today. You shared a lot of valuable information. Thanks to our listeners for tuning in. If you liked the episode, share it with your colleagues on LinkedIn. See you in the next episode.