State of Payer Compliance on Provider Directory APIs
It has been 18 months since the July 2021 effective date of the CMS Final Rule on Patient Access and Interoperability. In January 2022, we had identified Provider Directory APIs from 128 payers. Since then, we observed 78 additional payers publishing Provider Directory APIs. The addition of these payers brings total coverage of identified APIs to 73% of total US covered lives. The availability of these APIs is significant and should mean that most Americans with health insurance are able to access Provider Directory data via third-party workflows – if API availability was enough.
At the beginning of the enforcement period in July 2021, fewer than 10% of payers had APIs functioning well enough to support the most basic use cases described in the CMS final rule: in-network provider search and health plan comparison. After 18 months of payers working with Defacto Health to test and resolve API and data issues, we now see that number at 51%. The payers with functioning APIs had put forethought into how the APIs would be used, or they resourced their interop teams to be responsive to feedback post-deployment. While the improvement from 10% to 51% is dramatic, and payers come online monthly with Defacto, there remains much work to be done. Many payers are in the process of resolving issues: missing query parameters, performance issues, and upstream data issues.
Payers’ First Contact With Apps
When Defacto first made contact with payers on their APIs in the latter half of 2021, payers viewed us with surprise and curiosity. We often heard reactions like, “We didn’t know if any apps would show up” and “What in the world are you using the APIs for?” Some payers requested meetings with us to discuss use cases and our understanding of regulatory requirements. A few immediately prioritized resolution of issues and invited us to participate in live issue reproduction and testing. For the most part, these teams perceived our offers to explain use cases and provide testing support as a “we come in peace” message. Others took multiple months to resolve issues but were still responsive in communicating progress. We are appreciative of these teams embracing the spirit of interoperability and collaborating with us to resolve issues and to put the APIs to work for the benefit of their members. A shout out to the teams at Kaiser Permanente, Humana, UnitedHealthcare, and Florida Blue for working with us in the early days to ensure their APIs were functional.
Compliance-Only Mindset towards Interoperability
We encountered some payers who can be characterized as having a compliance-only mindset. Characteristics of this include hidden API information, no documentation (or links to IGs as ‘documentation’), no method of contact to report issues, and listing generic customer service phone numbers. We have had numerous conversations with perplexed Tier 1 support staff where we found ourselves educating about APIs, regulatory requirements, and use cases in an attempt to route the call. When we were lucky enough (or persistent enough) to get in touch with somebody responsible for the APIs, it was a mixed response. Some heard us out and said they would consider resolving the issue. A few, however, asserted that their API was compliant even when it was unusable for the most basic task: determining whether a provider is in-network.
It is understandable with new interop requirements every year, that payer teams have a lengthy backlog to work through. In fact, we are aware that some payers are already re-platforming their APIs after unsuccessful implementations. Some payers have very reasonably focused on the bare essentials for compliance, all the while others have continued apace beyond that and built out usable APIs that are being leveraged for use cases that are positively impacting patient access. Payers with usable APIs will be the best positioned to address future CMS rules that build on top of previous rules, and will be able to more quickly comply relative to their compliance-only counterparts. Not sure whether or not your API works? Ask your interoperability team to name one app that is successfully using your API for production use cases. Ask to talk to the apps, and see if they agree that the APIs work. More specifically, ask if an app could actually use your API to determine whether a provider accepts a specific health plan you offer. The ability to point to a third-party app that is using your API for production use cases is your best insurance (no pun intended) against non-compliance.
Interoperability is a Non Zero-Sum Game
Payers should view API usability as an opportunity rather than as a compliance checkbox. In an interoperable world, health plan selection will be powered by data sourced from payers’ APIs. Patients will seek care and book appointments in third-party workflows that depend on payer APIs and machine-readable data. Making your APIs usable will allow you to engage with members and prospective members beyond the boundaries of your web site and your call centers. If you are serious about an omnichannel strategy, that necessarily includes functioning APIs (by the way, any AI chatbot you wish to build will need to interface with those APIs in the next 18 months). If your API is unusable or unavailable, members may not see your plans’ names in the search dropdowns of the most popular consumer-facing healthcare properties on the Internet. Unusable APIs may lead to member dissatisfaction or lost business. Beyond member use cases, your solution vendors supporting analytics, network management, credentialing, and provider directories will ask to use your Provider Directory APIs. Doing so can mean lower maintenance costs for those solutions, accelerated impact, and better outcomes. As healthcare becomes more interoperable, functioning APIs will become table stakes. Not having a functioning API in 2023 will be like not having a website in 2003. Decision makers and technology leaders within payer organizations should consider these factors as they decide how to resource their interop teams and select FHIR vendors to maximize API usability.