1up FHIR Platform
1up Patient Connect
1up Population Connect
1up Comply
1up Exchange
1up Analyze
In December of 2022, the Centers for Medicare and Medicaid Services (CMS) issued a proposed rule that sought to not only expand the required APIs an eligible payer must maintain in support of interoperability as outlined in the “Interoperability and Patient Access” final rule released in March of 2020, but also introduced a new API requirement – the Provider Access API.
While the Patient Access API is focused on making relevant information available to individuals (via a third-party application of their choice), and the Payer-to-Payer Data Exchange API is focused on making relevant information available to an individual’s current and/or concurrent payers, the Provider Access API, as the name implies, is geared towards making relevant information available to a patient’s care team.
This blog post provides a high level overview of the requirements of the currently proposed Provider Access API rule, along with some guidance around what actions eligible payers should be thinking about today in preparation for these upcoming requirements.
A Summary of the Proposed Provider Access API Requirements
How: Much like the Patient Access, Provider Directory, and the newly proposed Payer-to-Payer Data Exchange on FHIR APIs, the Provider Access API must be a FHIR API. However, unlike the three foregoing APIs, the requirements for data sharing with providers not only dictates the methodology for how data is shared, but also prescribes where the data must be shared. As currently proposed, the data shared by the payer via the Provider Access API must be shared to a provider’s electronic health record (EHR), practice management solution, or any other technology solution utilized by a provider for treatment purposes.
Who: The requirement to maintain a Provider Access API must be met by the following types of plans – Medicare Advantage (MA), State Medicaid, Children’s Health Insurance Program (CHIP), and Qualified Health Plan (QHP) issuers on the Federally-Facilitated Exchanges (FFE).
What: The proposed rule currently requires eligible payers to share clinical, claims, and encounter data for any encounter with a date of service on or after January 1, 2016, as well as any prior authorization data for any active prior authorization or for any request where the date of last status change was less than one (1) year prior.
As used herein, “Clinical data” includes any data that fall within one of the data classes under the Content Standard at 45 C.F.R. 170.215, which is currently United States Core Data for Interoperability (USCDI) v.1; “Claims data” includes any data concerning adjudicated claims, including claims data for payment decisions that may be appealed, were appealed, or are in the process of appeal; “Encounter data” includes any data related to an encounter with a capitated provider; and “Prior Authorization data” includes any data related to a prior authorization request and decision, such as status of request, date of approval or denial, duration of approval, reason for denial, items or services being approved, and/or any other documentation provided by the provider in support of the request.
When: This is where we really start seeing some divergence between the Provider Access API and the other required APIs. For the Patient Access and the Payer-to-Payer Data Exchange APIs, much of the data sharing is triggered by the member, in that the member either needs to actively authorize, in the context of the Patient Access API, the release of data, or, in the context of the Payer-to-Payer Data Exchange API, opt in to data sharing. With the Provider Access API, what triggers the data to be released is a request from a provider. Once such a request has been received, the payer has one (1) business day to deliver the required information.
However, three requirements must be met prior to any data being released:
- The first is that the provider is part of the payer’s current network of providers, as evidenced by either a written contract, or in the case of Medicaid or CHIP, where such provider is enrolled with the state as a Medicaid/CHIP provider.
- The second requirement is that the member must be attributed to the provider, by the payer, as evidenced by claims data.
- Lastly, the members to whom the data pertains must not have opted out of data sharing via the Provider Access API. While the Provider Access API is the first API to not require the member to actively opt in or consent to participation, the payer must not only honor a member’s desire to opt out, but must also provide a mechanism for them to do so.
If all three requirements are met, then data must be shared accordingly.
| Provider Access API | |
|---|---|
|
How |
FHIR API |
|
Who |
MA, Medicaid, CHIP, and QHP on the FFE |
|
What |
Clinical, Claims, Encounter, and Prior Authorization Data |
|
When |
One (1) business day from the receipt of a request from a provider IF: (a) the provider is in the payer’s network; (b) the provider is directly attributed to the member via claims data; and (c) the member has not opted out of data sharing. |
|
Effective Date
|
January 1, 2026
|
Actions Eligible Payers Should Be Taking Now to Get Ready for the Provider Access API Rule
While January 1, 2026 (assuming that is the finalized effective date of such regulation) feels like a far off date, there are certain actions payers should be thinking about today as they will require more preparation:
- Payers need to create and manage an attribution process based on claims data. In order to effectively support the requirements of the Provider Access API, while meeting the currently proposed one (1) business day timeline, payers are going to need to come up with an automated process for attributing members – based on claims data – to a provider. In addition, given it’s likely that providers could make additional requests for information for any given member, payers are also going to need to have the ability to maintain and validate such rosters.
- Payers will need to create content and collateral for members with information around the benefits of participating in exchange via the Provider Access API, as well as the ability to opt out of such participation and how to do it. This information will need to be updated and provided annually.
- Payers will need to create content and collateral for providers with directions on how to make requests for information and how the payer’s attribution process associates members with such providers.
- Payers will need to find a mechanism to support sharing data to a provider’s EHR, practice management solution, or other technology solution used for treatment. Given that the proposed rule currently requires data to be delivered into the provider’s current treatment workflow, payers are going to need to work with their provider partners to find the most effective way to do this. Generally speaking, EHR write-back functionality is currently somewhat limited. There also seems to be some hesitation from the industry around expanding write-back capabilities, namely around the integrity of the data and the ability to control the data maintained in the EHR. That said, payers still need to be ready to meet this requirement prior to 2026, and will need to start working with its provider partners today to determine the right methodology for data sharing via such technologies.
Final Thoughts on the Proposed Provider Access API Rule
Since the regulation is still in proposed status, it is really important to remember that we could see some variation between what has been proposed and what is ultimately finalized.
At this point in time, the proposed rule is currently in the Office of Management and Budget (OMB). It is likely that a final rule could be released any day now. Once released, we will update you on any relevant changes and will continue to support you through your compliance journey.
Stay tuned for more information and make sure to visit 1upHealth’s Modern Interoperability Resource Center as we will continue to update that with additional content.
