Details
-
Change Request
-
Resolution: Not Persuasive
-
Medium
-
US Da Vinci CRD (FHIR)
-
current
-
Financial Mgmt
-
Supported Hooks
-
-
Bob Dieterle / Chris Cioffi : 8-0-0
Description
In CDS Hooks, early on in the design of specifications, we had identified 3 classes of results
- There are alerts to show
- There are no alerts to show
- We need more information before we can say if there are alerts to show
The App Link follow-up was particularly designed for the #3 use-case.
However, the CRD IG uses the App Link to show a DTR App. The DTR App can be an independent App and not necessarily a Payer DTR App. It's function is not to determine if prior authorization is required, but to collect supporting information for the prior authorization submission assuming prior authorization is required, and save it back to the EHR FHIR Server.
This means, CRD does not have a semantically distinguishable way to capture #3 case of "we don't have enough information to determine if prior authorization is necessary"
Using a card saying prior authorization "MAYBE" necessary - go fill out the DTR App, wouldn't work because
- the DTR App is not submitting the captured information to the payer, and so the payer doesn't have an opportunity to look at the info and make a determination until PAS submission comes through
- the provider side still has to fill out the same info (such as where is the service being performed? Who is the performing provider?) on the EHR side. This constitutes duplicative documentation, and there is no guarantee that the provider side will use the same values as they used in the App thereby invalidating the determination.
Realistically, what needs to happen is that the CRD Service needs to be able to say to the EHR in a semantically understandable / discretely captured fashion that we don't have enough information, maybe even these are the missing pieces, and call back when you have those captured.
Unfortunately, CDS Hooks may not be the best vehicle for this either