Yesterday, 13 months after proposing it, CMS finalized its Interoperability and Prior Authorization Rule. As CMS worked towards publishing this rule, payers, API vendors, and app developers were implementing the requirements of the previous 2020 Interoperability and Patient Access Rule. Even as some are still working out the kinks in 2020-era APIs, a new set of API requirements has landed on the payers’ collective doorstep.
This article summarizes the key provisions of the new rule, highlights the continued requirement of Provider Directory APIs, and describes the regulatory enforcement options CMS has at its disposal.
The Rule includes the following key provisions:
- Payers shall implement a Prior Authorization API that presents documentation requirements for covered items and services, and enables Prior Authorization requests and responses (including approval decisions).
- Payers shall expand their Patient Access APIs to include prior authorization decisions.
- Payers shall implement Provider Access API to share patient data (similar in scope to data within Patient Access API) with in-network providers to ‘facilitate care coordination.’
- After exercising enforcement discretion on Payer-to-Payer data exchange after the 2020 Rule, CMS set a deadline for implementation by 2027 and clarified that data will be exchanged using FHIR.
While there are no new requirements in the 2024 Final Rule for Provider Directory APIs, CMS continues to require that payers make these APIs publicly available to support a variety of patient access use cases. Given CMS’s continued support for this requirement, payers who have yet to implement their Provider Directory APIs (two and a half years from the effective date) or who are still resolving issues should view having a usable API as a necessity. We mentioned in this previous post that the best way to demonstrate compliance is to illustrate real world use. If participating apps are using Provider Directory API data to show in-network providers by health plan to members, providers, and others, that is the best signal of compliance to federal regulators.
The Arc of Interoperability Bends Toward Rule Enforcement and Standards
In the Final Rule, CMS reviews its options for enforcement of requirements for both the Provider Directory API and Patient Access API requirements (we can infer they are the same for other API requirements as well). These include: warning letters requiring corrective action, sanctions, civil monetary penalties, and ‘suppression and decertification’ options (these vary depending on CMS program participation).
In terms of standards, CMS re-iterates its support of FHIR by listing HL7 FHIR Release 4.0.1 as the required standard for all five APIs (Patient Access, Provider Access, Provider Directory, Prior Authorization, and Payer-to-Payer). As a reminder, the requirement of FHIR for Payer-to-Payer is new as of this Rule, and was not a requirement in the 2020 Rule. For Provider Directory API, CMS has strongly recommended the adoption of the HL7 Da Vinci Payer Data Exchange (PDex) Plan Net Implementation Guide. Most payers that have implemented the Provider Directory API have done so using the Plan Net implementation guide (virtually all with usable APIs have embraced Plan Net). California’s SB1419 sets forth a requirement for all payers in California to implement APIs ‘in accordance with standards published in a final rule issued by the federal Centers for Medicare and Medicaid Services’. Payers can expect federal and state agencies to increasingly embrace standards and IGs.
For those API vendors and internal architects building API infrastructure for payers, they should consider future proofing investments by building APIs that conform to the stated IGs out of the gate. This may be preferable compared to a rushed implementation and future retrofitting of APIs (hello, technical debt). Payers and vendors will want to do everything possible to avoid expensive API re-do’s and vendor switches.
Wherefore art thou, National Healthcare Directory?
In October 2022, CMS released an RFI to request industry feedback on the idea of a National Healthcare Directory. Such a directory would serve as a ‘centralized data hub’ on healthcare practitioners, organizations, their endpoints (and, in some use case descriptions, also payers). In this Final Rule, there are 17 mentions of the National Directory concept, but nothing concrete in terms of future direction (with the exception of describing how TEFCA participants will have access to a directory of digital endpoints). The pain of not having a national directory is highlighted multiple times in vivid terms: ‘industry-wide scramble and search for verified plan endpoints’, ‘lack of an authoritative central directory could create a significant gap in the ability for industry to move many critical interoperability initiatives forward’. CMS says they are ‘committed to exploring an NDH’. If and when concrete efforts materialize to build a National Directory, payers’ current Provider Directory APIs and their efforts to collect ‘digital contact information’ for providers will serve as a foundational layer. As we have seen, CMS presumes that payers comply with current requirements as it authors rules and future requirements.
A view towards cross-pollination between the APIs
In the Rule and responses to comments, CMS describes a number of ways the Provider Directory APIs can support target use cases for Patient Access, Provider Access, Payer-to-Payer Data Exchange, and Prior Authorization. In our next post, Defacto will review these use cases and imagine how payers and developers could implement the APIs (and machine-readable files) so that they can be used together.