1up FHIR Platform
1up Patient Connect
1up Population Connect
1up Comply
1up Exchange
1up Analyze
While the concept of having former and concurrent payers exchange data on members was originally introduced to us by the Centers for Medicare & Medicaid Services (CMS) in its Interoperability and Patient Access (CMS-9115) final rule, it was in its Interoperability and Prior Authorization (CMS-0057) final rule where CMS, in the words of famous chef and television personality Emeril Legasse, really “kicked it up a notch.”
While it’s clear there are some notable differences between what was ultimately finalized in the two aforementioned regulations, it would be reasonable to categorize the new Payer-to-Payer Data Exchange on FHIR as an expansion of the original concept.
This is especially true for those payers who leveraged a FHIR API (either directly or via a third-party vendor) to support the requirement in the CMS-9115 final rule, even though CMS didn’t directly mandate the use of such technology. For many of those payers, there is now an open question as to just how much of that original investment can be leveraged in support of these new requirements.
Reading between the lines of the CMS final rules
In order to best address this question, it’s important to understand the key differences between the two final rules. While the actual text of the codified regulation, in concert with the required and recommended Implementation Guides, provides the direct requirements, it’s the commentary provided by CMS as part of the final rule where we not only get more context as to CMS’ thought processes, but also a better idea of the intent behind the regulation. In other words, to truly understand each final rule, we have to not only read the lines themselves, but we also need to read between the lines.
For example, while CMS did not expressly mandate the use of a FHIR API to support the Payer-to-Payer Data Exchange requirements in the CMS-9115 final rule in the text of the regulations, in the comments section, CMS did heavily encourage payers to consider using a FHIR API to support this use case.
A FHIR API is now required by the CMS-0057 final rule
While this is not only a good example of the impact the CMS commentary can have on how a regulation should be interpreted, it’s also the first key difference we see between the CMS-9115 final rule and the CMS-0057 final rule. Unlike in the former, where a FHIR API was strongly recommended in the commentary and the recommended Implementation Guides, in the CMS-0057 final rule, a FHIR API is required, not just by the commentary, but by the text of the regulation itself.
An expansion of the impacted payers for Payer-to-Payer Data Exchange on FHIR
The CMS-0057 final rule did not just prescribe a method for data exchange, it also expanded the payers impacted by this requirement from just those with Medicare Advantage lines of business (the only impacted payers under the CMS-9115 final rule) to include Medicaid, CHIP, and Qualified Health Plan (QHP) Issuers on the Federally Facilitated Exchange (FFE).
The expansion of required data elements for Payer-to-Payer Data Exchange
The definition of “impacted payer” was not the only thing that was expanded by the CMS-0057 final rule. CMS also amended the required data elements that had to be shared from just clinical data for any member who was an active member within five (5) years from the date of the request to instead include clinical, claims, and encounter data for any current or former member encounter with a date of service within five (5) years from the date of the request, as well as any prior authorization data for any prior authorization (not including those with a status of denied) with a status change less than one (1) year prior to the date of the request.
Administrative requirements add complexity to payer responsibilities
While the foregoing expansions, with the added clarity on the mechanism to exchange such data (i.e., FHIR API) are substantial in and of themselves, the most impactful change the CMS-0057 final rule made to the Payer-to-Payer requirements were actually to the associated administrative requirements the payer had with respect to the regulation.
In the CMS-9115 final rule, payers simply had to be reactive – when a member requested that data be available to their current or concurrent payer, the impacted payer was required to ensure that such data be shared accordingly. The CMS-0057 final rule, however, takes a far more proactive approach.
Instead of waiting for a member to request the information be shared, for any new or current enrollee, within one week from either the start of coverage or receiving acceptance of enrollment from CMS, whichever is later, a payer is required to collect both the member’s opt-in to data sharing via Payer-to-Payer and any relevant information required to identify the member’s former and/or concurrent payers. Within one week from the date both are obtained by the payer, the payer is then required to request the required data elements from the identified former and/or concurrent payers.
While it’s likely that a FHIR API with a patient-mediated flow, as recommended in the CMS-9115 final rule, would have been sufficient with both the broadening of the definition of “impacted payer” and required data elements, it’s this new administrative requirement on the impacted payers that creates the real question as to sufficiency.
Shifting the burden of making the request from the member to the payer not only requires the payer to create additional administrative processes to support the data collection requirements, it also implies changes to the technical requirements of the API, switching out the atomic API with an authentication mechanism for a Bulk FHIR API that supports population-level data sharing.
Given that most payers are likely going to be doing most of the data requesting and collecting during their open enrollment periods, it’s likely they will have multiple members with the same concurrent or former payers. The payer can simply create a single member roster of all such individuals and submit such roster to the identified payer, allowing the requesting payer to make one request for multiple members, and similarly allowing the responding payer to make one response. However, this approach is likely not scalable with an atomic API, and is definitely not feasible with an authentication mechanism.
While this requirement is not in the text of the regulation, this conclusion is further supported both in the context of the required and recommended Implementation Guides and the supporting CMS commentary.
In the CMS-0057 final rule, CMS made the decision to remove the requirement for the Payer-to-Payer Data on FHIR API to adhere to both the SMART App Launch Implementation Guide and the OpenID Connect Core Implementation Guide – two Implementation Guides associated with a patient-mediated authentication mechanism. In the correlating commentary, the rationale for such a decision was that “protocols requiring user level credentials managed by the payer, such as those used with OpenID Connect Core, are generally not appropriate for business-to-business data exchanges like the Payer-to-Payer API.” CMS further clarifies that OpenID Core Connect “is not a scalable approach” and ultimately not “adequate to meet this use case.”
Further, CMS also added the Bulk Data Access Implementation Guide as a required Implementation Guide, and while addressing comments around the decision clarified that “Bulk data exchanges are usually used for system-to-system use cases and allow large volumes of information on a group of individuals to be shared in one exchange, which could be useful for sharing data between payers.” In addition, CMS also further states that even if it may not be necessary for payers to use Bulk FHIR for every data exchange, it does recommend using “the Bulk Data Access Implementation Guide to send bulk requests and responses for multiple patients at once,” during periods of peak volume, such as open enrollment.
Ultimately a Bulk FHIR API will be necessary to support the Payer-to-Payer requirement
Based on the foregoing, it is clear that a FHIR API that leverages a patient-mediated flow, on its own, is likely insufficient to meet the obligations outlined in the CMS-0057 final rule. Payers will be required to stand up and maintain a Bulk FHIR API that supports the ability of another payer to make requests for information on behalf of their members. This conclusion really should not be too surprising when one actually considers the intent behind the Payer-to-Payer requirements, and candidly behind all of the required APIs across these two final rules.
1upHealth empowers patients by empowering you
The overarching goal of the CMS Interoperability APIs is to empower individuals, and their respective care teams, to make better care decisions by giving them access to all the relevant information required to do so. Given the populations served by the impacted payers, shifting the obligation to request information on to the payer, rather than the member, significantly increases the likelihood that data will actually be exchanged between the parties responsible for ensuring that member receives the appropriate care.
While this obligation does materially impact those payers who have already invested in a patient-mediated flow, the one conciliation I can provide is that this is not a problem you have to solve on your own. For more information about the required administrative processes and for guidance on how to begin the process to define those, please view our ebook, Payer’s Playbook: CMS Interoperability Final Rule.
You can also learn more about the 1up Payer-to-Payer Data Exchange API, or contact us for more information.
