In our previous post, we reviewed aggregate statistics on payers publishing provider directory APIs in the first six months of enforcement of the CMS Final Rule. In this post, we will look in more detail at the top 50 payers and understand and compare their processes around API access, registration (if required), issue reporting, and also take a look at the mix of issues observed upon initial review of the APIs.
Availability: Of the top 50 payers in the U.S., 40 published information about their provider directory APIs on their web sites, public endpoint directories, or their vendor’s web site. Of the 10 that have not published their APIs, 7 are state Medicaid agencies. The remaining 3 are private insurers (w/ Medicare and/or Medicaid business) that are currently building their APIs.
Registration: Of the 40 payers that have published, only 19 conformed to CMS’s requirement of making their provider directory APIs publicly accessible (i.e., without any registration or authentication gates), however Defacto was able to register with all but 2 of the remaining payers (registration or token issues currently being resolved). The registration process varied widely among payers. Some required only basic app registration information (e.g., name of app, purpose of app, contact information), and others required a more comprehensive process of sandbox testing, attestation questions, and identity verification. In these cases, the payers asked the same questions of apps irrespective of whether they requested access to the Provider Directory API or Patient Access API. Usability issues around app registration were present among some payers’ portals, resulting in the inability to submit information without intervention from support staff.
Support Models: Most payers offer documentation on their provider directory APIs, including OpenAPI or swagger documentation in either YAML or JSON format. Some payers offer “try it” capabilities in their developer portal to test sandbox APIs. Defacto discovered two payers offering downloadable Postman collections. In terms of accessing API support, most payers offer an e-mail address or contact form, and a handful provide telephone support (some even participating in live issue reproduction). There are some payers that simply link to the DaVinci Plan Net Implementation Guide as documentation, assert that their API conforms to the IG, and offer no additional support.
Types of Issues Observed: Of the payers publishing, most had observable issues within their provider directory APIs. These include missing data (e.g., identifiers, organization names), missing references (e.g., the connections between providers and networks, or providers and organizations), pagination issues (give me the next 10 results of a query), authentication and registration, and connectivity (intermittent availability of all services, or unavailability of specific provider directory resources). Most payers have been responsive and acknowledged when issues are reported, although a handful have yet to respond. Some payers have been expedient in resolving issues within days or weeks (or recommended workarounds), but many are waiting for sprint planning processes to slot issue resolution into releases beyond a month’s time.
Conclusion: Most payers are making a good faith effort to publish their provider directory APIs to comply with the CMS Final Rule. However, in the early days and with limited usage, many are still working through issues with their APIs. While there is conformance to DaVinci Plan Net, the standard allows for variability, and the variability among the payers’ implementations prevent developers from taking a pure ‘write once, run everywhere’ approach. There is still opportunity for code re-use, but per payer effort is required for registration, integration, and at least for the time being, issue resolution.