CMS Final Rule: Frequently Asked Questions

Below are the frequently asked questions surrounding the Interoperability and Prior Authorization final rule (CMS-0057-F).

FAQs

Will payers be required by CMS to provide clinical data USCDI using V3 by 2026?
Yes, for the Patient Access API, to the extent Payers maintain data that is now included in the classes in Version 3 of the United States Core Data for Interoperability (USCDI), those data elements will need to be made available via the Patient Access API by January 1, 2026 at the latest. Given that the enforcement dates for the Payer-to-Payer and Provider Access APIs, respectively, are January 1, 2027, a full year after the mandated standard switch, any clinical data shared via such APIs should automatically align with such current standard.

When will the resource profiles used for the “Prior Authorization Data” be required to be made available on the Patient Access API?
As of right now, while there are prescribed implementation guides that are expressly required for each API, including Patient Access, there is less structure with respect to resource profiles. CMS does, however, recommend the use of HL7 FHIR Da Vinci Payer Data Exchange (PDex) IG STU 2.0.0, which does have a designated Prior Authorization Profile.

Does the carve out for unstructured data incentivize payers to use unstructured documents to avoid having to share this data?
There is a very legitimate concern that the majority of useful context lives in the unstructured documents. While a payer is obligated to share other information with respect to the prior authorization request, such as what items or services were covered and duration, the more relevant clinical context will live in that administrative and clinical documentation, and it is likely most of that will be unstructured. In the commentary, CMS also expressly specified that a payer is only required to share structured documentation that it maintains, but there is no requirement to actually parse through unstructured data in an effort to make it structured.

How will servers deal with scaling concerns with Bulk Data Access?
Bulk FHIR has still not been proven out in a real-world scenario. Bulk FHIR, as a batch-mode protocol, is inherently designed to address scaling concerns. For interoperability to be truly effective, we are going to need to support the ability to share population-level data effectively. Given its requirements here, we will likely see an uptick in utilization which will hopefully provide us with more insight into any technical pitfalls that will need to be addressed.

What are the thoughts on how to attribute a member to an ACO?
Members are either attributed to an ACO or they are not. Payers do not need to apply any special logic to make that determination, they just need to make sure that the attribution is clear in their records. In terms of their internal attribution processes, ultimately attribution lists can be maintained in a variety of ways, from robust population management tools to more simplistic Excel files. The question to ask when trying to determine which method is the best is really – “what process can I easily (and ideally, cost effectively) maintain to ensure accuracy and completeness?”

On a proactive attribution process: are you thinking about pushing data out through the API to a healthcare provider upon that provider’s assignment to a Medicare/MA member, for example?
This is less about the flow of data and more about the steps you take before data even moves anywhere. For example, once a member enrolls into your plan, there is certain information that is either made available by CMS, or by the member during such process that can support some attribution effort – such as whether or not the member is part of an ACO. More often than not, payers already maintain some form of ACO attribution list, so leveraging those resources to create proactive attribution files ensures that if said ACO makes a request for one or more of those members, the exercise in validation of the relationship has already occurred.

If a user opts out of sharing, can a payer share data only when required by law, or when permissible by law?
The short answer here is that nothing prohibits the sharing of data via the Provider Access API in situations where such disclosure is either “Required by law” or where the disclosure is otherwise legally permitted under applicable law without the need to obtain consent.

To flesh this out more and provide a little bit more color, here is a bit more context on how the CMS regulations intersect with federal and state privacy laws.
Putting the CMS regulation aside momentarily, generally speaking, under HIPAA, covered entities have different mechanisms that allow them to share data without the need to obtain patient consent. The first is under the treatment, payment, and healthcare operations (“TPO”) exception, where covered entities have a right to exchange protected health information, or PHI, in support of either their own, or for the receiving entities, treatment, payment, or healthcare operations use cases, without the need to obtain patient consent. The second is for uses or disclosures that are “Required by Law.”

Is/will there be a registry of endpoints?
As discussed in the commentary, CMS is aware that a centralized National Directory of Healthcare (NDH) is likely to be required to support not only a centralized data hub for providers, but also as a repository of payer endpoints in support of Payer-to-Payer, and subsequently released a request for information with respect to such topic on October 22, 2022. While no such directory yet exists, CMS has made an express commitment to exploring such requirements, including leveraging some existing mechanisms like the Trusted Exchange Framework and Common Agreement (TEFCA).

Do we have to tag unstructured data to a PA?
The mechanisms for how this will look have not really been fully defined, as there were no prescribed implementation guides or standards for how this should look. That being said, it is likely over the course of the next three years, there will be some further maturation to some early-stage implementation guides, like CDex, for example, that will provide more guidance.

Can you please clarify what integrating P2P data into a member record needs to look like?
The requirement here is really to ensure that any data received from a former payer gets similarly shared via the Patient Access and Provider Access APIs. There is not a whole lot of guidance in terms of what that needs to look like, beyond treating that data the way you would treat your own data. For example, clinical data received via the Payer-to-Payer API would just need to be treated the way the payer treats its own clinical data that it makes available to active members under the Patient Access API.

Do prior authorization data requirements for all APIs exclude or include drugs?
For all the APIs, prior authorization data expressly excludes drugs and only includes items and/or services.

Patient opt-in/out APIs, do they have to have a smart app to utilize this feature or does the Covered entity have to provide a UI as well?
This will ultimately be a decision that is up to the payers in terms of how they chose to make this available to members. The opt in/out process can be done and managed in a handful of ways, and CMS was clear to not prescribe the methodology for how a payer has to do this. Payers can create their own UIs or use existing systems.

The 2026 response timeline requirements says it excludes QHP issuers on the FFEs. Is this the only item throughout the new set of mandates that excludes QHP?
Yes, this is the only item where we see variation amongst impacted payers, not including any exceptions or exemptions that were identified by the regulation that could change those dates for certain plan types.

Do the regulations defer to state rules or other established rules regarding TAT? Also, some rules require written notification (snail mail) in addition to any verbal or electronic communication. Will the rules addressing these requirements be changed?
Generally speaking, the CMS regulation will always defer to the more stringent requirement as the regulation does not intend to remove existing requirements imposed by federal or state laws. In other words, the requirements in the CMS regulation is the floor, while any stricter law is the ceiling. So if another law (state or federal) has even faster turnaround times, those would essentially supersede the times mandated by CMS.

For other areas of interoperability, there are standardized terminologies and knowledge vendors who supply the updates, such as ICD-10 diagnoses or billing codes, medications and interactions. What exists currently for standardized referrals?
Essentially, a referral for consultation would likely be codified using either a CPT4 code for a service or a procedure. Payers have multiple policies for referrals within and outside of their network.

Do you see advantages to payers “gold carding” providers in advance based on their PA performance, e.g. 90% approved?
Payers are moving to this model to reduce administrative burden for the providers. Gold carding providers in advance based on their prior authorization (PA) performance, such as a high approval rate, could potentially offer advantages. The approach aims to streamline administrative processes and reduce burdens for efficient providers. However, the effectiveness of gold carding has been limited historically and the new rule emphasizes transparency and standardization.

For Payer-to-Payer data exchange when the member is not involved, does this include the exchange of data that otherwise requires member consent for the data to be shared/released?
The CMS regulation does not supersede or replace any other, more stringent applicable state or federal law. If an applicable state or federal law expressly requires an organization to obtain consent prior to the sharing of data, either based on the nature of the information being disclosed, or due to the nature of the organization doing the disclosure, then consent to share such data via payer-to-payer data exchange is required.

Would you suggest people hold off developing until DaVinci comes out with guides that would be valid for 1/1/27 (built on US Core 6.1)?
While a lot can happen in three years with respect to the evolution of standards and implementation guides, it is hard to really give a direct “yes” or “no” as this is ultimately a decision you will need to make based on your current circumstances.