Two years after the effective date of the CMS Final Rule on Patient Access and Interoperability, payers are reassessing their Provider Directory API vendors and implementations. Defacto Health has observed over 50 payers switching vendors or re-platforming their APIs in the past year. They are doing so to better comply with CMS requirements and to respond to third-party app vendor feedback. This post explores the reasons behind these changes, highlights key considerations when payers select a new vendor, and describes the importance of APIs functioning in a way to support CMS-described patient use cases.
Why are payers switching vendors?
As third-party app vendors integrated with health insurer APIs, it became evident that not all APIs were able to answer basic questions, such as whether a provider accepts a particular insurance plan or where the provider sees patients. Some vendors acted as trusted advisors and guided payers to prioritize necessary changes. Others simply took any data that was provided to them by the payer and presented it in the API (missing required data, unable to answer basic questions, or not supporting necessary logical relationships).
A third set of vendors offered payers a self-service API platform, placing the responsibility of loading the right data squarely on payers’ internal IT teams. This often resulted in APIs that were completely void of data for over a year. We have heard of at least two vendors who charged payers on a per query basis, resulting in unanticipated costs when third-party apps unexpectedly started querying their APIs.
Dissatisfaction with service, and at least one instance of a prominent vendor sunsetting its offering, has resulted in payers switching to new vendors for their Provider Directory APIs.
Key Considerations for Selecting a New Vendor
When health insurers decide to change their Provider Directory API vendors, several factors should be considered to ensure a smooth transition and improve functionality:
- Track Record of Success: Assess the performance of vendors by investigating their previous API implementations. Keep in mind that while no vendor has delivered functioning APIs for 100% of their payers, a strong track record of delivering functional APIs for payers is crucial.
- Ability to Work with Upstream Data Systems: Seek a full-service API vendor capable of collaborating with payers to load data from upstream provider data management systems. An ideal vendor will not only assist in data assessment but also provide consultative guidance on the type of data that can be made accessible through the API, and what questions it answers.
- Developer Feedback: If you are looking for feedback on Patient Access API vendors, reach out to app vendors like b.well, OneRecord, or Flexpa, who have experience working with them. For Provider Directory APIs, Defacto Health has integrated with the most and can provide you with thoughts on requirements. Those with hands-on experience using these APIs will provide you with the best feedback on which vendors deliver functioning APIs. Check out our previous post on what a good developer experience looks like.
- Review Documentation and Dev Portals: Take a close look at the vendor’s documentation and development portals. For Provider Directory APIs, which are meant to be public, ensure they can be tested to see if they present the expected and required directory information. It is often obvious which vendor is responsible for a particular API. Many APIs and documentation are hosted on the vendor’s site. Most of the times, vendor branding is present somewhere within payer documentation, or within the API capability statements.
- Can the APIs answer the right questions? Ensure the API can answer essential questions, such as querying a practitioner by NPI, presenting practice location addresses and phone numbers, and associating practitioners with the organizations they work for. Crucially, the API should indicate the insurance plans that a practitioner accepts, as described by the CMS Final Rule. Your vendor should approach building the API beyond a compliance-only mindset.
Defacto Health: Your No-Cost API Testing Partner
Defacto Health understands the significance of robust Provider Directory APIs for health insurers and their impact on patient access to healthcare. Once you have selected your vendor, and once they’ve updated your API, our team is ready to help you test its functionality at no additional cost. Check out our For Payers page to better understand how we test and assess payers’ Provider Directory APIs.
If you are still considering different API vendors, we are more than happy to discuss some of the considerations we’ve mentioned above, and provide guidance on important requirements for a well-functioning API.
To be clear, Defacto Health itself does not build Provider Directory APIs for payers. We integrate and use them to build our Insurances Accepted data set, which informs our perspective on API vendors.
Conclusion
The trend of payers revisiting their Provider Directory API vendors and implementations is encouraging news for patients and app developers alike. By selecting the right API vendor with a proven track record, the ability to collaborate on data integration, and a commitment to functional APIs, health insurers can better comply with CMS regulations and provide enhanced patient access to provider network and insurances information.