Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Medium
-
US Da Vinci DTR (FHIR)
-
current
-
Clinical Decision Support
-
DTR Questionnaire Response
-
Formal Specification
-
-
Bob Dieterle/Lloyd McKenzie: 14-5-5
-
Enhancement
-
Compatible, substantive
Description
This JIRA ticket is being created in response to the action item from the 2021-11-12 Burden Reduction call https://confluence.hl7.org/pages/viewpage.action?pageId=81004845
- Varghese Mathew - Write up proposed solution into a JIRA Ticket for getting feedback. Proposed solution to the DTR re-launch to save and finish later when ids may change or not exist yet so we can get feedback from other EHRs (Rajesh Godavarthi will get one more in the next wee.) Include how the write the questionnaireresponse and the order in launch context and the fully formed questionnaire being filled in the same response. (rough note to jog memory) - came up on 11/10 in context of JIRA ticket
FHIR-34128
-----------------------------------------------------
First, CRD will inform the Provider EHR in a semantically understandable fashion that prior authorization is/maybe required. (If it is an independent DTR launch without CRD, it could be EHR internal rules that make the determination that prior authorization is required).
Once it is know that for one or more services, prior authorization is required, we introduce a new SMART on FHIR launch context which can include
- (required) ServiceRequest(s)(or DeviceRequests etc.) that require prior authorization
- (optional) QuestionnaireResponse(s) from any previous DTR launch.
The very first time, the EHR launches DTR without #2 - QuestionnaireResponse(s). The DTR App will do it's "usual" work of determining the coverage and payer, fetching Questionnaire and CQL, and will gather information from the end user. Now whether the end user completes all required data or only partially fills DTR, the App files the (complete or partial) QuestionnaireResponse using the same mechanism described in current DTR spec to file the finished DTR questionnaire. This QuestionnaireResponse(s) is filed to the EHR FHIR server. The EHR already needs to have internal mechanisms to associate this QuestionnaireResponse(s) with the order(s) so that this can be included in the PAS request.
It must also be clarified that in this first launch, the EHR will pass the FHIR ID of the draft order(s) in the DTR launch. The QuestionnaireResponse will then have a reference to these orders through this FHIR ID provided to the DTR App when it files the QuestionnaireResponse with the EHR.
Now, if the FHIR ID of the order(s) changes, then the EHR is able to update the QuestionnaireResponse to have the correct FHIR IDs, since it understands this linkage.
Upon a subsequent launch, say to finish a previously partially filled out DTR (whether by the same user, or by a different user), the EHR will launch DTR with (1) the CURRENT FHIR ID(s) of the order(s), and (2) QuestionnaireResponse(s) it has previously saved associated with these orders.
(Optionally, we can also have the DTR App at this point do validation. If the FHIR IDs in the order reference do not match the order FHIR IDs in the launch, the DTR App can update the QuestionnaireResponse(s) with the correct order IDs. But I personally think, doing this on the EHR would be safer?)
Now, in this subsequent DTR launch, the App still determines payer and coverage from the order by fetching the order. Once the app determines payer and coverage, it fetches the Questionnaire and CQL per its usual process. If these have changed significantly, it may need to drop any previous QuestionnaireResponse(s) and start afresh, but that is the super uncommon case. Then it uses the information in the QuestionnaireResponse(s) to update the UI to whatever the user previously left off at. Now the user can continue from where they left off and fill additional information.
This repeated launch and filing back to EHR can be done how-many-ever times as necessary. After some iterations, all information is filled, and the App can file a completed QuestionnaireResponse completing the DTR interation.
At this point, the EHR will then begin the PAS workflow.
This also means
- There is no need for any Task or additional resources for this workflow.
- There is no need for additional secure connections between the App and the Payer allowing the app to file any data to payer, nor any security concerns arising out of so doing.
- There is no additional capability such as DocumentReference required either on the payer's or the EHR's side.
- In fact, even CRD does not need to return a DTR App link - all that CRD needs to return is the discrete information about whether prior authorization is required or not for each service.
- This model is simple and doesn't involve much additional work on either Payer or EHR for a mult-launch DTR as against a single launch DTR.
Let me know if I captured everything correctly per our discussion, or if there are any additional concerns.
Attachments
Issue Links
- is duplicated by
-
FHIR-33223 Formalize how DTR saves context of DTR for a relaunch
- Duplicate