Stream: Da Vinci CRD
Topic: Pre-emptive prior authorization
Sreekanth Puram (Oct 20 2021 at 01:54):
@Lloyd McKenzie
I was going through the proposed changes under https://build.fhir.org/ig/HL7/davinci-crd/hooks.html#pre-emptive-prior-authorization
Since Claim response is not a resource that is covered under USCDI, I am not confident that many EHRs support this resource at least in the near future. Can we relax the specification in such a way that a Document reference with a LOINC code "51851-4" (administrative note) can also be annotated to the order? If we need to standardize the format of the content, it can still be a JSON / XML format of a ClaimResponse resource.
Lloyd McKenzie (Oct 20 2021 at 03:32):
I don't see any point in a DocumentReference. If all you've got is text, it's better to stick that in a note on the order than to create a separate resource that just wraps a tiny text blob. I recognize that in the short term, few EHRs are likely to support a separate ClaimResponse endpoint. If it were easier, another option would be a 'contained' ClaimResponse if that were easier, though it has the disadvantage that you couldn't have an authorization that spanned multiple orders.
Sreekanth Puram (Oct 20 2021 at 13:45):
Most of the commercial EHRs don't support 'Contained'.
Lloyd McKenzie (Oct 20 2021 at 14:10):
Right. This is going to be a "pick your poison" questions for the EHR vendors. If they want discrete representation of prior auth information, they're going to need to support ClaimResponse one way or the other. In the short-term, we'll probably have manage with just human-readable notes on the order.
Sreekanth Puram (Oct 21 2021 at 15:57):
Recently we were onboarding our app to one of the leading EHRs. They were insisting that we should not be having any machine-readable stuff in any of the Human-readable notes section.
Lloyd McKenzie (Oct 21 2021 at 20:22):
Totally agree. The content in notes must be human-readable. So it would be something like:
"Prior authorization granted by Payer XYZ under patient's SuperPlan coverage for a maximum 3 repetitions of 'Some physio procedure' (billing code A123B) for $97.50 for each occurrence. This authorization expires Jan 15, 2022. Please quote authorization number 098776 in your claim submission."
Absolutely not expected to be parsable.
Sreekanth Puram (Oct 22 2021 at 20:12):
@Lloyd McKenzie another question on Pre-emptive prior authorization. I understand that if the information in the EHR is sufficient to send an affirmed decision, the payer can opt for pre-emptive prior authorization. Is there any time out specified for the execution of the CDS service? The decision-making logic on the payer's end may require making multiple calls to the FHIR endpoint on the EHR as needed. The FHIR calls introduce network latency as the complexity of the questions increases.
We can't use submitting data as a part of prefetch as the prefetch data elements are defined for the entire CDS service and not individually for a specific Device/Medication or a service request. So the accurate implementation would be to fetch data from the EHR as needed which may have some effect on the performance of the CRD service. Is my understanding correct?
Lloyd McKenzie (Oct 22 2021 at 22:29):
CDS Hooks is supposed to be synchronous, so certainly sub-second. Best to ask for most of what you need up-front and be algorithmically efficient in soliciting more.
Sreekanth Puram (Oct 23 2021 at 02:17):
Since a payer has only one CDS service endpoint, the description of prefetch elements should be common across all the practice areas that the payer supports. so it is literally impossible to do a prefetch based on the area of specialty. so from a practical application point of view, we can do preemptive prior authorization only in cases where decisions can be made based on very common criteria like service request, patient info, practitioner info, encounter info, current diagnosis, etc. If there is a need to solicit additional data from the EHR, we should do one of the following
- Defer it to the PAS step
- Return the pre-emptive prior authorization message and annotate the orders in the background. The problem would occur only when the CRD response is not an affirmed prior authorization but a link to start the DTR process.
- Should we have something in the IG to support the handling of long-running prior authorization activities which do not require any interactive sessions with the provider?
Lloyd McKenzie (Oct 23 2021 at 02:40):
I'm not saying you can get everything on prefetch. But striving to avoid more than one or two subsequent queries should definitely be an objective. If the determination can't be done within the CRD timeframe, it can always be done within DTR.
Ellen Anderson (Nov 03 2021 at 20:27):
eviCore does have a good amount of prior authorization that can be done based on basic data, BTW. Using our machine learning models and scoring thresholds there's a good amount of that going on. - I also commented on the DTR thread about our "silent pathways" which goes hand in hand with this
Last updated: Apr 12 2022 at 19:14 UTC
