CMS Final Rule: Frequently Asked Questions

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. 

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. 

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. 

This is not the only area where we see a situation like this. Another example is in the context of Payer-to-Payer, where Payers are only mandated to share information on inactive or disenrolled members if they maintain such information. While there are certain retention requirements under both federal and state laws, respectively, there are no additional requirements built into the CMS regulation. It seems likely that some payers may opt to delete data for such members to reduce their requirements of sharing that data with other payers. Identifying areas where regulation requirements could ultimately be incentivizing unwanted behaviors is incredibly important, because it provides guidance for future rule-making. 

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. 

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?” 

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. 

That being said, I think the instinct to use the API, proactively, as a means to ensure relevant care teams members have access to data is a fantastic idea and it is those types of instincts that will bring about the improvements to this industry that are so desperately needed. While the API must be used to share the data elements identified with in-network and enrolled providers for CMS compliance purposes, there is absolutely nothing prohibiting the payer from using the API to share data for other regulatory or compliance purposes, such as sharing data to meet certain reporting obligations.  

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.”

Despite the fact that much of the data being shared via the Provider Access API could easily be considered as data shared under the TPO exception, data sharing under the CMS regulation actually falls into the latter category, as a use or disclosure that is “Required by law.” In the case of data disclosures under TPO exception, disclosers, depending on the purpose of the disclosure (i.e., treatments versus payment or operations), have to abide by HIPAA’s minimum necessary standard. In the case of disclosures that are “Required by law,” the minimum necessary standard is not applicable, as the law ultimately dictates what information should be shared. This is one of the main reasons CMS has decided to maintain the Payer-to-Payer API as an “opt-in” API. It is important to note that the opt-in process tied to the Payer-to-Payer API is designed to be specific to the Payer-to-Payer API and is not intended to be considered a consent mechanism or an agreed upon restriction as such term is used by HIPAA. 

That being said, all disclosures made via the Provider Access API still must be done in accordance with applicable federal and state laws. For example, if a federal or state regulation requires consent based on either the type of organization disclosing or the type of information disclosed, then such consent must still be obtained prior to disclosure.  

While payers must use the Provider Access API to share the relevant data classes identified in the regulation, nothing in the regulation changes or limits any pre-existing rights payers have under HIPAA to share data with providers for treatment or care coordination or with other payers for care coordination, nor are they limited from using the API, even if the member opts out, for such purposes. 

While it is hard to make a concrete assessment here, I do believe that if a responding payer takes all the requisite actions to validate the identity of the requesting organization and to abide by a received attestation, then it is likely they will not be held liable. I truly cannot imagine a situation where a payer would be held liable for a breach if they share information on a member if they received what appears to be a valid attestation that alleged that the member had opted-in to data sharing, unless the payer materially overlooked certain information or acted negligently.  

Of course, the context and circumstances of the situation will be relevant to truly make that assessment, but generally speaking, if the payer does the requisite due diligence and responds to valid attestation, to hold such payer liable for the errors of the requestor would be unjust.  Additionally, as discussed above, in the context of sharing data where the member did not actually opt in, if the payer is legally permitted to share that data under HIPAA or any other applicable law, that disclosure is still permissible. Similarly, in the situation where the wrong member is identified and information for that member is subsequently disclosed, this would still not constitute a Breach under HIPAA based on the four-factor analysis for breaches, given that the receiving entity is still a covered entity and would treat the received information as PHI, thus materially reducing the risk of harm to the individual of subsequent disclosures or misuse of the information.

Generally speaking, the goal of the CMS regulations is not to try and create more privacy lawsuits, claims, or fines. As long as payers are acting reasonably and doing some proactive due diligence during these processes, it is unlikely responding payers would be deemed responsible. 

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 an 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).

While a national network would be incredibly beneficial, 1upHealth is equally committed to maintaining and making available its own network of endpoints for those payers for whom it provides related services. 

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.

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. 

For all the APIs, prior authorization data expressly excludes drugs and only includes items and/or services. 

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. 

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. For standard prior authorization requests, QHP issuers on FFEs must provide status updates within fifteen (15) days instead of the seven (7) days that is required across all plan types. 

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 turn around times, those would essentially supersede the times mandated by CMS. Similarly, any additional notification requirements in those state/federal laws would also need to be upheld. While the coexistence of both sets of rules is definitely a challenge, outline all of your respective requirements under both sets of regulations, and work with your legal and compliance teams to ensure you are taking appropriate actions to comply with all applicable law. 

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.

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. Payers may need to adapt their strategies to align with the evolving regulatory landscape.

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. The more stringent requirement, whether from state or federal regulations, always takes precedence. 

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. 

That being said, there is a lot of administrative and process work that needs to happen with respect to prior authorization before you should even be thinking about the Prior Authorization API.

• First, conducting an internal audit of your current prior authorization processes is going to be crucial. What items or services require prior authorizations? Is that list sufficient today? Does it need to be modified, either by removing or adding items or services? Does it align with your current coverage policies? Do those policies require modification?

• Secondly, what documentation is required for each item or service, is that clearly defined? Should that be modified and refined for clarity and cohesiveness? 

• Lastly, how are you managing prior authorization today? Is this something you are doing in house and requires you to use multiple systems? Or is this something you are outsourcing, and if so, to how many vendors? 

The impacted payer is responsible for obtaining both the opt-in and the information with respect to a member’s former and/or concurrent payers. For Medicaid and CHIP, while Medicaid managed care plans and CHIP managed care entities are not required to maintain an opt-in process, as that should be maintained by the State on their behalf, they are still required to maintain a process to allow a member to identify their former and concurrent payers. To be clear, however, other than putting forth the requirement, there is no real guidance on how this process needs to occur and can be either integrated into the payer’s existing processes, or done through existing platforms, like a member portals. Payers can also define a totally new way to do this process, including using a vendor to help accomplish this.

Right now, per the text of the regulation, for Payer to Payer, impacted payers are required to make clinical, claims, and encounter data for encounters with a date of service five (5) years from the date of the request available in canonical FHIR format and prior authorization data, including both structured and unstructured clinical administrative data, for all active requests and for all requests with a status change within one (1) calendar year for all prior authorizations with a status other than “denied.” There is not a whole lot of guidance on how that prior authorization data needs to be delivered beyond being in FHIR, with the exception of the unstructured documentation that just needs to be made available. While this could (and hopefully does in fact) change as implementation guides and existing standards mature, today that is the extent of the requirements. That being said, nowhere in the regulation is there a requirement to make information available in other formats beyond that. We will continue to participate in industry groups, however, and will make sure to provide you with any relevant updates and information as this evolves over time.