Q&A from the “Breaking Down the Final Rule: Takeaways & Actions” Webinar

1upHealth recently hosted a webinar entitled Breaking Down the Final Rule: Takeaways & Actions. During this session, we received a flood of amazing questions from the audience. My response to those questions follows. 

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

Can you speak to the resource profiles used for the “Prior Authorization Data” 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 a bit 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. 

While it is highly likely that as time passes we will see more sophistication and enrichment of Prior Authorization-related profiles and resources, today a lot of those resources are slightly lacking. We will continue to attend relevant industry groups tasked with developing such standards, and will make sure to provide regular updates to both our existing and prospective customers in terms of how we are thinking about prior authorization data in the context of FHIR transformation. 

Does the carve out for unstructured data incentivize payers to use unstructured documents to avoid having to share this data?

Unfortunately, I think your instincts here are spot on and it is a concern we similarly share. 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. 

Sadly, 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. While not the most uplifting response, identifying areas where regulation requirements could ultimately be incentivizing unwanted behaviors is incredibly important, because it provides guidance for future rule-making. 

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. That being said, given its requirements here, I am sure we will 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. I think the ultimate 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. 

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. As mentioned during the webinar, 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.  

If a user opts out of sharing, can a provider share data only when required by law, or when permissible by law?

I think the question was intended to say “payer” instead of “provider” given that these regulations are geared towards payers sharing data with either other payers or providers. I am going to answer the question based on that assumption. 

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 a bit more and provide a little bit more color, I am going to provide 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. 

Just to anticipate the topic related to electronic prior auth, ONC has indicated they will include that as a topic in their planned HTI-2 proposed rule to come out later in 2024 – what do you think ONC will propose if you were to guess? Use of the Da Vinci IGs? Certification of payer-focused Health IT? The ability of provider EHRs/HIT to connect to the Prior Auth API?

Some combination of the items you mentioned are definitely likely. While I am not sure if ONC will ultimately require the EHRs to use the provider-side APIs of the Da Vinci IGs, I think we are definitely going to see some more prior authorization standards get finalized – either later this year and/or over the course of the next three years collectively.

While broader than just prior authorization, what I think will be most interesting is to see ONC’s certification requirements in response to what accommodations EHRs and other health IT will need to make to support the receipt of information from payers. The requirements for both the Provider Access API and the Prior Authorization API in the CMS regulations are predicated on payers pushing certain data to providers, with the goal of having that data land within the provider’s existing workflows. For the majority of providers, that would pretty squarely equate to having that data land in the provider’s EHR. Today, EHR write-back capabilities are varied across the different EHRs and quite candidly, are lacking, in terms of what will be needed to support both of the aforementioned use cases. 

If, for some reason, the attestation was later found to be incorrect (identified the wrong member or they didn’t actually consent, etc), would the previous/sending plan be protected since they sent the data in good faith?

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. 

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

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.

As promised, we will continue to be apprised of these changes through participation in relevant 

industry groups and will make sure to keep you updated on those standards as they unfold. 

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 an UI as well?

I think 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. 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. 

For more information on the final rule, watch the Breaking Down the Final Rule: Takeaways & Actions webinar on demand.