Stream: Da Vinci DTR
Topic: Question about new launch context
Keeyan Ghoreshi (Mar 15 2022 at 17:59):
In jira there is the following line:
"We will define two new launch contexts for SMART on FHIR that must be supported by DTR - current order and current QuestionnaireResponse."
I'm a bit confused on how DTR is supposed to decide whether to include or exclude these launch contexts? If you're trying to relaunch a previous session, how is DTR supposed to know that and ask for the launch/response scope? At the point where DTR will be asking for scopes, it has no information beyond the fhir server's endpoint and, if included, a launch id. During a standalone launch, DTR could ask for the launch/response scope, but when launching standalone the EHR won't have anything "in context" to return, given the nature of launching standalone.
Lloyd McKenzie (Mar 15 2022 at 18:17):
It depends what you're looking at in the EHR. If you're currently looking at an order and launch DTR, you'd pass in the currentOrder context. If you're currently looking at a QuestionnaireResponse, you'd pass in the current QR. If you're not looking at either, you'd only pass in the patient context. If you're not even looking at a patient, DTR launch should error out.
Keeyan Ghoreshi (Mar 15 2022 at 20:11):
Right, but theoretically DTR should be including one or both of these new launch contexts in its request to the EHR. Unless I'm misunderstanding what "launch context" means, when DTR sends a request for an auth code, it tacks on a launch/response to the scopes to tell the EHR to send the QuestionnaireResponse in context. But DTR isn't "smart" enough to make this decision.
The DTR app doesn't know whether it wants a QuestionnaireResponse or not, but it's the one that's supposed to make use of the launch/response scope.
As an example workflow, I'm in the EHR looking at a QuestionnaireResponse. I launch DTR and it opens the launch page with the iss and launch parameters. At this point, DTR needs to ask the EHR for an auth code, and it's here that it would put together the scopes it's going to ask for. How is DTR meant to decide whether to include launch/response, launch/order, both, or neither?
According to the SMART IG, the app doesn't need to include these contexts when launching in the EHR (or rather, they're just hints to the EHR). Though that still doesn't solve whether DTR should always be including both these scopes, or omitting them sometimes.
Lloyd McKenzie (Mar 15 2022 at 20:44):
When you launch DTR from the EHR, you pass in a launch context. These new contexts (one or the other) would appear alongside the patient context typically used. DTR doesn't ask for anything in terms of launch context. If no order or QR is provided on launch, then the app will need to guide the user through the process of selecting one.
Lloyd McKenzie (Mar 15 2022 at 20:44):
The 'scope' solicited by DTR is typically the whole patient record, though in some cases the app might know it needs less and thus ask for less.
Keeyan Ghoreshi (Mar 16 2022 at 06:46):
Ok, I think I may be confusing some terminology then. From my perspective, patient context is explicitly requested by DTR through inclusion of launch/patient in the scope. It is included on request for an authentication code, along with other contexts like launch or launch/encounter. To me, "context" refers to these values which are included in the scope.
For these new contexts, launch/response and /launch/order, it sounds more like a modification of the appContext bundle, with two extra fields the EHR may or may not fill out.
Lloyd McKenzie (Mar 17 2022 at 01:17):
@Keeyan Ghoreshi
After some more research, I understand exactly what you're saying. Also, the newest SMART Launch Framework spec provides some guidance and expectations that we didn't take into account when writing up the spec. So some changes are definitely in order.
My take is that we are wanting to use launch contexts - and you're correct that those do come back as part of the OAuth process. However, we don't want to make our requests as typical 'fhir' context requests, as that would cause the EHR to prompt the user to select something, and furthermore would prompt the user to satisfy all contexts - whereas we want one or the other and we don't want the EHR to prompt for either because DTR can do a smarter job of filtering candidate request resources and QuestionnaireResponses than a generic EHR-driven search.
I've created a place-holder tracker item for DTR and have started a discussion on the #smart stream. Once the most appropriate approach is landed, we can create a tracker for CRD too.
Last updated: Apr 12 2022 at 19:14 UTC
