Stream: smart
Topic: 'Optional' launch parameters
Lloyd McKenzie (Mar 17 2022 at 01:14):
With the Da Vinci DTR specification, we want the EHR to pass in the current 'request' resource (MedicationRequest, ServiceRequest, NutritionOrder, etc.) OR the current DTR-relevant QuestionnaireResponse as part of launch context. However, we don't ever want both and we don't want the EHR to prompt the user for either if neither are present in current context - because a DTR-specific search within the app is going to be smarter about filtering what sets of orders or QRs are potentially relevant than a generic search.
Therefore, I think we don't want to use the launch context mechanism defined by the new SMART App Launch spec, which would mean passing in a request for launch/questionnaireresponse, launch/medicationrequest, launch/servicerequest, etc.
As I read things, we're better off defining a 'custom' context (or set of contexts) that would have the behavior we want. However, that's sort of unfortunate as I suspect we're not the only SMART app who would like to be launched in the context of "whichever of these resource types, if any, happen to be in current context - but don't prompt the user if there aren't any/all of them". Has this use-case been thought about? Is there already a way to do this that I somehow missed? If not, does it seem like something that would be worth standardizing? If we create something custom, would it still be appropriate for the results to come back in the fhirContext element?
Josh Mandel (Mar 17 2022 at 01:41):
Your assessment is correct -- we don't currently account for semantics like "exactly one of" or "only if it's already available". However assuming you're using the EHR launch, this is already in the realm of "system specific configuration", so it doesn't matter too much how you ask for it (or even if you ask explicitly at runtime or implicitly at configuration time).
Returning a result in fhirContext makes sense however it's requested, assuming you're targeting the new FHIR-35801 and defining a role value like "dtr-request".
(BTW @Vassil Peytchev is doing the work for this technical corrections still on your queue?)
Lloyd McKenzie (Mar 17 2022 at 02:59):
So you don't think there's utility in a 'standard' way to say "give me this resource if it's in current context, but don't prompt for it otherwise"?
Lloyd McKenzie (Mar 17 2022 at 03:00):
My understanding if we do something non-standard is it should be "__dtr-request"?
Lloyd McKenzie (Mar 17 2022 at 03:00):
or, to be extra safe "__davinci-dtr-request"
Josh Mandel (Mar 17 2022 at 03:12):
For scopes, you can prefix with underscores or use a full URL like http://hl7.org/fhir/us/davinci-dtr/smart-app-launch-request. But I'm not seeing a huge interop benefit to trying to standardize general purpose semantics (i.e., for scope modifiers like "exactly one of" or "only if you've got it already") at this stage because an EHR will need to write custom code to support DTR anyway
Josh Mandel (Mar 17 2022 at 03:12):
Just defining something use case specific seems OK
Josh Mandel (Mar 17 2022 at 03:14):
We don't even have super consistent support for our core scopes like encounter selection, so I'd hesitate to go deeper
Lloyd McKenzie (Mar 17 2022 at 03:25):
Ok. We don't really need to say "send one of". Simply saying "send if it's in context, but don't prompt for it" for all of the possibilities is sufficient. There's little likelihood of there being more than one in context, and if there is, it'll be up to the app to figure it out. So all we'd really be looking for is a standard resource context, with the ability to say "no-prompt". I'll leave it to others to see if they think there's value in that. For now, we'll proceed with something custom.
Josh Mandel (Mar 17 2022 at 03:41):
Even if you are just looking for standard resource context though, your initial message indicates that there is not any one specific resource type that you would want to ask for; and there is not currently a way to ask for context by role although that's presumably something that would be part of the technical correction.
Lloyd McKenzie (Mar 17 2022 at 03:52):
I would ask for a whole bunch - with the expectation I'd probably get only one, maybe a few.
E.g. launch/medicationrequest#noprompt, launch/servicerequest#noprompt, launch/questionnaireresponse#noprompt, etc.
Lloyd McKenzie (Mar 17 2022 at 04:34):
Does that +1 signal that you think there might be value in defining such a '#noprompt' mechanism as a standard part of SMART app launch in the future?
Mikael Rinnetmäki (Mar 17 2022 at 12:43):
Josh Mandel said:
We don't even have super consistent support for our core scopes like encounter selection, so I'd hesitate to go deeper
Could it be that going deeper could also bring value to the elementary use cases?
From my perspective, it would be nice to get the ref to the Encounter if the EHR considers it to be "in the context" of the launch and if I list patient/Encounter or user/Encounter in the scopes of my app. The same for Appointment, Observation, CarePlan, MedicationRequest, QuestionnaireResponse...
Mikael Rinnetmäki (Mar 17 2022 at 12:48):
Regarding prompts, and just as a side note, we have seen an implementation demanding that launch/patient be in scope for it to even allow stand-alone launch of a patient facing app, and others that select the right patient (you) based on login info to patient portal if you don't specify that scope, and require an extra step of selecting your identity (the only one available on a list) if you do include the scope.
Mikael Rinnetmäki (Mar 17 2022 at 12:56):
(I guess the latter is due to http://build.fhir.org/ig/HL7/smart-app-launch/scopes-and-launch-context.html#apps-that-launch-from-the-ehr saying
The EHR MAY refuse authorization requests including patient/ that do not also include a valid launch/patient scope, or it MAY infer the launch/patient scope.
That makes it hard to implement an app that works nicely (does not require a prompt when the patient can be inferred) and also with EHRs that require the launch/patient scope to be present.
Cooper Thompson (Mar 17 2022 at 13:46):
@Lloyd McKenzie - just double checking, but are you wanting to pass the resource as part of the launch context? Or a reference to the resource (like we do for encounter and patient)?
Josh Mandel (Mar 17 2022 at 14:26):
From my perspective, it would be nice to get the ref to the Encounter if the EHR considers it to be "in the context" of the launch and if I list patient/Encounter or user/Encounter in the scopes of my app. The same for Appointment, Observation, CarePlan, MedicationRequest, QuestionnaireResponse...
For EHR launch, this is already the case. You just ask for launch context and the EHR gives you all the contexts that it has that it thinks is relevant. What we're getting into in this discussion is more about hints about what an app thinks might be relevant to inform the EHR.
From http://hl7.org/fhir/smart-app-launch/scopes-and-launch-context.html#apps-that-launch-from-the-ehr describes EHR Launch context scopes as:
“hints” regarding which contexts the app would like the EHR to gather. The EHR MAY ignore these hints.
(Note this is different from standalone launch where the EHR SHOULD include any requested parameters and SHALL provide patient context if requested.)
Josh Mandel (Mar 17 2022 at 14:27):
Does that +1 signal that you think there might be value in defining such a '#noprompt' mechanism as a standard part of SMART app launch in the future?
No I was just signaling that I understood the request. If you did want to formulate one, given the language above it might be more helpful to formulate a "!important" type of suffix because the current requests are already pretty much optional. But again, I don't know that any of this really matters at runtime for interoperability in the use cases we have delineated here.
Vassil Peytchev (Mar 18 2022 at 18:59):
(BTW
Vassil Peytchevis doing the work for this technical corrections still on your queue?)
Yes, it is! HIMSS is over, so I will be spending more time in FHIR.
Last updated: Apr 12 2022 at 19:14 UTC
