Stream: questionnaire
Topic: launchContext off-list "names"
Paul Lynch (May 18 2021 at 17:34):
Per FHIR-29664, the name field is now bound extensibly to patient, encounter, location, or user, and type field can be any FHIR type. Could we specify that if the name field is some off-list name, that what is being requested is an instance of the resource indicated by "type" that is currently in the application's context? This would allow us to handle Diane's case of needing to pass in a QuestionnaireResponse from a different questionnaire for prepopulation in the current Questionnaire.
Paul Lynch (May 18 2021 at 17:38):
For example, launchContext with "name" = "qrForFirstQ", type = "QuestionnaireResponse", would define a variable qrForFirstQ, which would have the context QuestionnaireReponse (if there was one, as there is in Diane's case).
Oliver Egger (May 18 2021 at 19:08):
I like that apporach, for our usecase we have a document (FHIR Bundle) as the context for prepopulation, what do you think @Alexander Kreutz ? If this would be a possible solution, how we would specify the defined launchContext name, resource|reference pairs it in the $populate operation (raised also here https://chat.fhir.org/#narrow/stream/179255-questionnaire/topic/.24populate.20-.20launch.20Context ) ?
Lloyd McKenzie (May 18 2021 at 20:31):
That makes the presumption that there can only be one instance of a given type in an application's context. I don't think that's true.
Lloyd McKenzie (May 18 2021 at 20:32):
E.g. there could be multiple Practitioner instances in context (data entry person, author, supervisor, etc.)
Ilya Beda (May 18 2021 at 21:30):
I found Paul's solution reasonable. I have already been using launchContext in this way.
There is no issue with having multiple elements with the same type and different names.
launchContext with "name" = "author", type = "Practitioner", and "name" = "supervisor", type = "Practitioner".
Lloyd McKenzie (May 18 2021 at 22:32):
That means you must understand the meaning of the name in order to populate the context. If we make it extensible, 'name' will need to change to Coding so there can be a system which establishes context for the code.
Ilya Beda (May 19 2021 at 07:17):
The name should be a free text, exactly as it defined at https://build.fhir.org/ig/HL7/sdc/StructureDefinition-sdc-questionnaire-launchContext.html
The meaning is defined by the type. I see an issue with making it extensible.
It makes sense to keep binding for the type required and restrict it by a set of all FHIR resource names and FHIR data types.
I updated my task accordingly https://jira.hl7.org/browse/FHIR-32644
Paul Lynch (May 19 2021 at 10:06):
Lloyd McKenzie said:
E.g. there could be multiple Practitioner instances in context (data entry person, author, supervisor, etc.)
@Peter Muir raised the issue this morning that one might want to pull in the physician (I think he meant), and that the person filling in the form might be someone else in the office (e.g. an MA).
Paul Lynch (May 19 2021 at 10:10):
Lloyd McKenzie said:
If we make it extensible, 'name' will need to change to Coding so there can be a system which establishes context for the code.
I don't object to it becoming a Coding (though I am not sure if that helps) but we did already make it extensible in FHIR-29664.
Paul Lynch (May 19 2021 at 10:23):
I think the reason the "name" field was so limited was that we were following the SMART App launch scopes, which are extensibly limited to user, launch/patient, and launch/encounter. However, an application (SMART or not) might have the user working on more than one thing, and be able to provide more types of context resources.
Ilya Beda (May 19 2021 at 10:46):
SDC may be used outside of SMART App. So, I think that idea to limit launchContex.type by SMART App launch scopes was wrong.
Paul Lynch (May 19 2021 at 12:24):
After talking with Ilya, it seems like a good approach would be to have launchContext define (using name and type) context variables that the application can either know about or prompt the user to select. launchContext also includes a "description", so in cases where the application had to ask the user to find it, the description could guide them about what they were providing. For example, if there were two launchContexts:
launchContext extensions: [{
name: prac1
type: Practitioner
description: The practitioner entering the data.
},
{
name: prac2
type: Practitioner
description: The patient's physician
}]
then the application (if unfamiliar with the Questionnaire) could provide separate prompts for the user to select each practitioner from a list.
It would still be beneficial to keep the standard names we have defined, so the application would not always have to ask the user for the information even if showing an unknown Questionnaire.
Brian Postlethwaite (May 19 2021 at 12:47):
I don't think (not in my mind anyway) that the intent was to limit to SMART app launch, but as to how it would support/leverage smart all launch
Lloyd McKenzie (May 19 2021 at 16:21):
The meaning can't be defined by the type - because as pointed out, there can be different meanings associated with the type. We can allow it to be extensible, but if we do that, then the 'name' needs to be globally unique to avoid collisions, and that essentially means Coding.
Paul Lynch (May 20 2021 at 13:05):
I don't think we are trying to define new, globally unique names. The new names only have meaning in the context of a particular Questionnaire, just like Questionnaire variable names.
Paul Lynch (May 20 2021 at 13:07):
Either the application would know the Questionnaire's launchContext names and therefore know what resources should be passed in, or it would ask the user to pick appropriate resources before rendering the Questionnaire.
Diane (Feb 10 2022 at 21:14):
Is the LHC Forms able to support a QuestionnaireResponse as a launchContext now? @Paul Lynch
If yes, how do we set the launch context?
I see in the documentation:
LForms.Util.setFHIRContext(fhirContext);
Is this where we give the url/path to the resource and the resource ID? In our case, https://ourfhirserver.com/fhir/QuestionnaireResponse/6789
Paul Lynch (Feb 10 2022 at 22:08):
No, and I don't see an option for that in https://build.fhir.org/ig/HL7/sdc/ValueSet-launchContext.html. Is there a tracker item about that idea?
Lloyd McKenzie (Feb 11 2022 at 00:56):
Which idea?
Diane (Feb 11 2022 at 02:56):
It looks like Ilya's issue was solved with https://jira.hl7.org/browse/FHIR-32644.
I think the launchContext extension is a more FHIR-ish way to represent the QuestionnaireResponse being passed into the Questionnaire.
Last updated: Apr 12 2022 at 19:14 UTC
