1up FHIR Platform
1up Patient Connect
1up Population Connect
1up Comply
1up Exchange
1up Analyze
During our recently hosted webinar, we received several great questions from our audience. Here are our responses to those questions.
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 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.
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. Wondering what your thoughts are in light of the new rule?
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.
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?
As discussed above, 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.
The current Implementation Guides will not be valid come 1/1/27. 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)?
I think this is a reference to the Davinci Guides with respect to the prior authorization API specifications. While a lot can happen in three years with respect to the evolution of standards and implementation guides, it is hard to really give you a direct “yes” or “no” as this 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.
I think first and foremost, 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?
So while I do encourage you to be thoughtful around technical development, because you are correct that standards can evolve over the course of time, I do not encourage you to wait to address the prior authorization requirements, in general, until such time, because in doing so, you will definitely be putting yourself in a position of missing the enforcement deadline.
For the Payer-to-Payer API, when a member opts in, whose responsibility is it for identifying former and current payers: the org that manages the API, the Payer who is being requested for information, or the state?
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.
How do you support the CMS requirement for providing adverse determinations in a members preferred language or alternate format (braille, large print, audio recordings)? Since there are no ‘standard’ IGs required, with Payer to Payer API– will payers have to support multiple formats?
It is a little hard to answer this question concretely, as you are totally correct that there is no standard around this today. 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.
For more information on the final rule, watch the Navigating the CMS Final Rule Series on demand.
