Provider Directory API

Provider Directory API

Provider Directory API

Are payers impacted by the Interoperability and Patient Access final rule (CMS-9115-F) required to offer a public facing Provider Directory API? What information are they required to include through the Provider Directory API for in-network providers and contracted networks?

Medicare Advantage (MA) organizations, Medicaid state agencies, Medicaid managed care plans, Children’s Health Insurance Program (CHIP) state agencies and CHIP managed care entities are required to offer a public facing Provider Directory API which must include data on a payer’s network of contracted providers. [7]

Because Qualified Heath Plan (QHP) issuers on the Federally-Facilitated Exchanges (FFEs) at 45 CFR 156.221(i) were already required to make provider directory information available in a specified, machine-readable format, we did not require that QHP issuers would have to make provider directory information available through an API.

Impacted payers, other than the QHP Issuers on the FFEs, must make certain information accessible through the Provider Directory API, including provider names, addresses, phone numbers, and specialties. Directory information must be available to current and prospective enrollees and the public within 30 calendar days of a payer receiving provider directory information or an update to the provider directory information. [8] There are additional content requirements for the provider directory under the Medicaid and CHIP managed care program at 438.10(h)(1) and (2).

CMS does not specify how payers manage access to APIs for provider directories for providers managed through contracted networks. Therefore, payers may make appropriate business decisions for ensuring availability of the Provider Directory APIs, making them accessible, and providing information or links on the payer website to direct interested parties to those application programming interfaces (APIs).

The Provider Directory API must be publicly available and exclude the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations (see 85 FR 25543).

What are the requirements for the Provider Directory API for Medicare Advantage (MA) organizations that offer Medicare Advantage Prescription Drug (MA-PD) plans, with respect to including the mix and number of pharmacies in their network?

MA organizations that offer MA-PD plans must make available, at a minimum, pharmacy directory data and include the pharmacy name, address, phone number, number of pharmacies in the network, and mix (specifically the type of pharmacy, such as “retail pharmacy"). [9] In the Interoperability and Patient Access final rule (CMS-9115-F), CMS encouraged MA-PD plans to build a Provider Directory API that is conformant to the Health Level Seven International® (HL7®) PDex Plan-Net Implementation Guide (85 FR 25529).

May a payer require the developer of a third-party application or the third-party application itself to register in order to use the Provider Directory API?

No, a payer may not require the developer or the application that accesses the Provider Directory API (or its documentation) to register to use the Provider Directory API. The Provider Directory API endpoint must be made publicly accessible and payers subject to the Provider Directory API requirement must make that application programming interface (API) publicly accessible. The API technical standards for the Provider Directory API exclude the security protocols related to user authentication and authorization and any other protocols that restrict the availability of this information to particular persons or organizations. [10] In addition, payers must make sure that the API and its documentation are accessible via a public-facing digital endpoint on the payer's website. [11] Specifically, the final rule requires payers make the Provider Directory API accessible via a public-facing digital endpoint on their website to ensure public discovery and access. [12] Given this is generally publicly available information at this time, restrictions are not permitted. However, under the payer’s obligation to keep its systems secure under other rules, payers may put certain information behind an initial firewall in order to protect against a denial of service attack, much as they would currently protect data for any website. Otherwise this must be a truly public and unrestricted digital endpoint.


Footnotes

 

  • [7] 42 CFR § 422.120; 42 CFR § 431.70; 42 CFR § 438.242(b)(6); 42 CFR § 457.760; 42 CFR § 457.1233(d)(3).
  • [8] Id.
  • [9] 42 CFR § 422.119(b)(2).
  • [10] 42 CFR § 422.120; 42 CFR § 431.70; 42 CFR § 438.242(b)(6); 42 CFR § 457.760; 42 CFR § 457.1233(d)(3)
  • [11] 42 CFR §42 CFR § 422.120; 42 CFR § 431.70; 42 CFR § 438.242(b)(6); 42 CFR § 457.760; 42 CFR § 457.1233(d)(3).
  • [12] Id.
Page Last Modified:
09/06/2023 05:05 PM