Stream: questionnaire
Topic: Cardinality of launchContext.type
Paul Lynch (Nov 06 2020 at 22:18):
The cardinality of the launchContext.type is currently 1..*. However, the type list is fixed to the four values 'patient', user, encounter, and location. Given the very different nature of those resources, does it make sense to list more than one type for same launchContext.name?
Lloyd McKenzie (Nov 06 2020 at 22:25):
I don't think so.
Paul Lynch (Nov 06 2020 at 22:32):
Paul Lynch (Nov 06 2020 at 22:33):
But we should see what @Brian Postlethwaite thinks.
Brian Postlethwaite (Nov 06 2020 at 22:34):
Why restrict to any specific set?
Brian Postlethwaite (Nov 06 2020 at 22:34):
User is the only odd one out here.
Brian Postlethwaite (Nov 06 2020 at 22:35):
And I would expect EpisodeOfCare to be another significant source.
Brian Postlethwaite (Nov 06 2020 at 22:35):
Location would come from a practitioner role.
Paul Lynch (Nov 06 2020 at 22:35):
It was done to align with the SMART on FHIR launch contexts (J#19500).
Brian Postlethwaite (Nov 06 2020 at 22:36):
The context my smart app is currently leveraging takes patient, practitioner, PractitionerRole, and Organization.
Brian Postlethwaite (Nov 06 2020 at 22:36):
The smart app launches defined there aren't exhaustive.
Brian Postlethwaite (Nov 06 2020 at 22:36):
And they are happy for others to go in.
Brian Postlethwaite (Nov 06 2020 at 22:37):
It's a point that I'm sure hasn't been properly exercised yet.
Brian Postlethwaite (Nov 06 2020 at 22:37):
Outside a very slim scope.
Paul Lynch (Nov 06 2020 at 22:37):
Well, I think there needs to be some standardized (possibly extensible) list or interoperability becomes a guessing game.
Brian Postlethwaite (Nov 06 2020 at 22:37):
Yes, agree. But the way it's defined is pretty simple from a smart and forms context.
Paul Lynch (Nov 06 2020 at 22:40):
The current version of the JavaScript SMART client (http://docs.smarthealthit.org/client-js/client.html) only supports accessing the patient, the user, and the encounter, or so it looks to me.
Brian Postlethwaite (Nov 06 2020 at 22:40):
There are 2 parts to the launch, the details of the user, (including roles orgs etc, not just the practitioners name, or patient ) and the data element in context in the UI, which could be patient, encounter, EpisodeOfCare, but could be a specific medication, or an observation or a practitioner if you were looking at a list of pracs.
Brian Postlethwaite (Nov 06 2020 at 22:41):
Which is my point, hasn't been used to really extend beyond a specific narrow use.
Paul Lynch (Nov 06 2020 at 22:43):
Then, maybe to allow for future development, the binding should be changed to Extensible?
Brian Postlethwaite (Nov 06 2020 at 22:45):
Yes pls.
Paul Lynch (Nov 06 2020 at 22:46):
In that case, the cardinality should probably left at 1..*.
Brian Postlethwaite (Nov 06 2020 at 22:46):
And that space is now... I'm actively working on getting that out here in Australia across primary care.
Brian Postlethwaite (Nov 06 2020 at 22:47):
I was also interested if that was an 'and' or an 'or' multi-cardinality?
Paul Lynch (Nov 06 2020 at 22:48):
I think it was "or".
Brian Postlethwaite (Nov 06 2020 at 22:48):
Great, if there's clarification being added that would be nice.
Brian Postlethwaite (Nov 06 2020 at 22:49):
An example would be a generic feedback form that could be used on any resource.
Paul Lynch (Nov 06 2020 at 22:53):
Updated J#29664
Paul Lynch (Nov 19 2020 at 23:48):
@Brian Postlethwaite The resolution of J#29664 was different than we discussed here. Does it look okay to you?
Paul Lynch (Nov 20 2020 at 14:05):
@Lloyd McKenzie The type of launchContext.name is currently "id", not "string", which I think it needs to be if, per J#29664 is to be bound to a ValueSet. "id" is not one of the types listed at https://www.hl7.org/fhir/terminologies.html#4.1 that can bound bound to a ValueSet. Does J#29664 need to be amended?
Lloyd McKenzie (Nov 20 2020 at 14:16):
@Grahame Grieve Is there a reason that 'id' couldn't be bound to a value set?
Ilya Beda (Feb 16 2021 at 16:48):
I see that https://jira.hl7.org/browse/FHIR-29664 is resolved so I can't comment there.
I think that Questionnaire launchContext should accept any type from https://www.hl7.org/fhir/datatypes.html with any name and don't be restricted by http://build.fhir.org/ig/HL7/sdc/ValueSet-launchContext.html
I provided me thoughts here https://docs.google.com/document/d/1tTgN_GrYFJO-YYXkHYGbRjR2yor2VYXkhnNQLfLlCNo/edit#heading=h.ir14xf8w8y1n
Should I reopen https://jira.hl7.org/browse/FHIR-29664 to continue conversation or create a new issue to continue the discussion, please advice?
Lloyd McKenzie (Feb 16 2021 at 19:34):
It would need to be a new one. The outcome of 29664 is for it to be extensible, so you're free to define additional ones, but there's no way we can generically expect clients to pass in arbitrary contexts
Brian Postlethwaite (Apr 06 2021 at 22:58):
I read the outcome of that and I'm confused about what it will look like.
Last updated: Apr 12 2022 at 19:14 UTC
