Key Takeaways:
- Always read the comments in Interoperability rules. They are rich with use cases, give clues as to how the regulator expects APIs to be implemented, and give insights as to how others in industry wish to use the APIs.
- APIs are meant to be used together. APIs are often called the ‘lego bricks‘ of software. They’re modular, re-usable, and can be deployed for multiple use cases.
- APIs should be implemented, not only for conformance to regulation, but to support intended use cases. Core to this is the logical relationships between Providers and Insurance Plans in Provider Directory API.
Re-Cap of the 2024 Rule
Our previous post included a summary of the 2024 CMS Interoperability and Prior Authorization Final Rule. The name of the rule makes it obvious that, of the multiple use cases described, Prior Authorization is the star. Over 35 million prior authorization requests were sent to Medicare Advantage plans in 2021. According to Medical Economics as part of their Physician Report, physicians spend more than 10 hours a week on prior authorizations. CMS estimates that provider savings as a result of Prior Authorization API adoption will be $1.2 billion in 2027, assuming 27.45% participation among all practices. CMS, understandably, picked a huge administrative problem to solve (in which providers and patients alike feel the pain), and backed it up with years of focused rule making.
While prior authorization is the star of the Rule, CMS wrote best supporting actor Provider Directory API into key scenes (use cases) and describes how the Directory API can work alongside the Patient Access API, Provider Access API, Payer-to-Payer API, and Prior Authorization API. This post explores how CMS contemplates Provider Directory API being used in these scenarios, and imagines how payers and developers can implement solutions leveraging a combination of these APIs to support multiple industry use cases.
If you want to follow along in the Rule, search for mentions of Directory in the questions and comments. CMS responds to multiple requests and questions around provider network status and plan information within the comments sections distributed throughout the Rule document.
How Provider Directory API supports Patient Access API
Multiple commenters asked CMS whether key directory information (name, contact, network status) could be included in the Patient Access API. Their thought was to use this information to recommend (to patients) providers ‘who can furnish the appropriate service within the time and distance standards required by law’. CMS responded by differentiating the purpose of the Patient Access API and Provider Directory API: ‘We understand that it is important for patients to know whether the provider they are seeing is in their payer’s network, but we do not believe that the appropriate place for that information is with prior authorization information.’ They then recommended that developers ‘integrate within their apps network information from payers’ Provider Directory APIs’ to be able to incorporate information on the network status of providers. Defacto Health has investigated this with developers integrating with Patient Access API. Upon investigation of a sample of payers’ Patient Access API ‘Coverage’ resource and Provider Directory API ‘Insurance Plan’ resources, there are mappings between these APIs to provide connective tissue between patient coverage and provider-plan participation. Imagine a member authorizing access to her payer’s Patient Access API, and using coverage, claims, provider, and drug data to ‘find the best health plan for me.’ This becomes possible by using both Directory and Patient Access APIs!
How Provider Directory API supports Provider Access API
Another use case CMS describes is verifying provider relationships to access the Provider Access API. In the Rule, payers are required to make patient data available via the Provider Access API to enrolled, in-network providers who have a treatment relationship with a member. CMS suggests using claims history to verify treatment relationship with a patient. It follows that payers could also use Provider Directory API (or, upstream source-of-truth provider data management systems) to verify network status for a provider. CMS says this in a later section: ‘Authenticating the identity of the provider will include confirming that the requesting provider is in-network or enrolled with the payer.’ CMS also contemplates payers implementing ‘granular controls’ that allow patients to opt-out of Provider Access API for individual providers or groups of providers (which will also necessarily require having structured data on logical relationships between practitioners and provider organizations). For vendors responsible for implementing both Provider Access APIs and Provider Directory APIs for payers, it may be convenient for them to leverage Directory APIs as part of a verification gate for Provider Access APIs.
How Provider Directory API supports Payer-to-Payer API
Cross-use between the Payer-to-Payer API and Provider Directory data is also considered in the Rule. CMS states that patient data from payer-to-payer ‘can give payers the information they need to assign a case manager or help the patient find providers in their new network’. One could imagine a provider recommendation workflow for new members that leverages data from Payer-to-Payer API and Provider Directory API. This could be a front-end for payer-driven primary care physician recommendation or specialist referral.
How Provider Directory API can support Prior Authorization
Some commenters expressed concerns that either a) patients may not be aware that a provider requesting prior authorization from a payer is out-of-network, and/or b) that patients should be able to access prior authorization information within their Patient Access API irrespective of the network status of the provider. CMS clarified that the Rule makes ‘no distinction in-network and out-of-network providers’ in terms of providing prior authorization data via API. That is, whether a provider is in-network or not, a prior authorization request can be submitted to a payer. If the provider is out-of-network, a future claim for the service could still be rejected or reimbursement reduced due to the provider’s network status. CMS states they ‘understand that it is important for patients to know whether the provider they are seeing is in their payer’s network, but we do not believe that the appropriate place for that information is with prior authorization information.’ They suggest that prior authorization workflows could include ‘network information from payers’ Provider Directory APIs’ to help avoid out-of-network surprise billing (which can be confusing to a patient if prior authorization was otherwise approved).
Clarifications in the Rule for Provider Directory API Implementors
There are relevant, clarifying information in CMS’s responses that indicate their expectations in how Provider Directory APIs should be implemented by payers:
Leased Networks: CMS clarifies the definition of ‘in-network or enrolled’ providers which may be applicable for Provider Directory API implementers. CMS states ‘Providers in a leased network are in-network for purposes of the Provider Access API requirement because the lease effectively creates a contract with the providers in that network.’ Defacto has observed that while many payers choose to publish leased network data in their APIs, others do not. There are also some who incorporated leased networks, but data is missing key information (e.g., NPIs, practitioner-plan relationships, practitioner-organization relationships). Payers should establish explicit requirements for leased network data in their APIs to be at parity with their data on non-leased networks.
Practitioner-Plan Relationships: CMS highlights use cases that require determining whether providers are in-network for a particular member with an Insurance Plan. Payers and vendors should consider this as they make decisions on what data, and what logical relationships they include within their APIs. The Practitioner-Plan relationship is an essential one for Provider Directory APIs to be usable by developers and patients. Most payers, when they understand the use cases, have updated their APIs to include this important information.