Stream: questionnaire
Topic: contained reference to an adaptive questionnaire
Brian Kaney (Jan 07 2020 at 19:56):
RE: Adaptive Questionnaire.
It seems in this IG, the contained Q should reference the AQ via the url http://fhir.org/guides/argonaut/questionnaire/adaptive.html#usage-1. However in this IG, the contained Q seems to use the identifier http://hl7.org/fhir/uv/sdc/2019May/adaptive.html for this purpose. Which is it?
Lloyd McKenzie (Jan 08 2020 at 15:57):
//reference to contained questionnaire
"questionnaire": "#q",
is using a relative URL to point to the contained resource. It's not pointing to the 'identifier'. That said, we're inconsistent in the examples about whether "questionnaire" is declared and it should be in all of them. Can you submit a change request?
Brian Kaney (Jan 09 2020 at 15:36):
Thanks @Lloyd McKenzie -- here is a PR: https://github.com/HL7/sdc/pull/2
Paul Lynch (Jan 09 2020 at 15:50):
Change requests to the SDC IG are usually made via a JIRA ticket. That being said, the pull request really helped me understand that inconsistency you are seeing. In the Argonaut IG, the contained Questionnaire resource has a "url" field but no "identifier", and in the SDC IG example the contained Questionnaire resource has an "identifier" but no "url".
Brian Kaney (Jan 09 2020 at 15:59):
Hi @Paul Lynch -- yes that's right! I prefer using url, so I hope that PR is approved :) .. LMK if it would be helpful to create a ticket.
Paul Lynch (Jan 09 2020 at 16:03):
Another (maybe bigger) inconsistency is the operations for getting the next question. In Argonaut:
POST [base]/Questionnaire/$next-question
but in SDC (note the ID):
POST [BaseURL]/Questionnaire/[id]/next-q
Brian Kaney (Jan 09 2020 at 16:04):
Oh yea, that is a big one. Generally speaking I saw Argonaut as a "feeder" into a ballot standard, and the SDC would be the one that will end up getting adopted. Is this the way I should be thinking?
Lloyd McKenzie (Jan 09 2020 at 16:13):
@Brian Kaney Please submit a Jira change proposal and point to your pull request. Pull requests can't be considered without a Jira ticket.
Paul Lynch (Jan 09 2020 at 17:47):
@Brian Kaney If you do submit a JIRA ticket, please post a link to it here so that people reading this thread can find it.
Brian Kaney (Jan 09 2020 at 18:10):
Sure thing. I am waiting to get granted access to JIRA. (BTW the footer still refers to gforge)
Brian Kaney (Jan 09 2020 at 18:26):
Here it is, thanks! https://jira.hl7.org/browse/FHIR-25434
Eric Haas (Jan 09 2020 at 19:58):
I think either endpoint should work
Eric Haas (Jan 09 2020 at 19:59):
The servers are smart enough to figure it out
Brian Kaney (Jan 09 2020 at 22:46):
Well, as an implementor/developer in one case you'd have to build an operation at the type-level (that would interrogate the body and the subsequently find the appropriate questionnaire), verses an instance-level operation. And it would be nice to not have to build the next-q(uestion) operation twice!
(I prefer an instance-level operation, it's a simpler to build e.g. /Questionnaire/[id]/$next-q)
Lloyd McKenzie (Jan 09 2020 at 23:13):
We can't always go with an instance-level operation because not all servers that support the operation will necessarily be Questionnaire repositories.
Paul Lynch (Jan 09 2020 at 23:22):
@Lloyd McKenzie Per http://hl7.org/fhir/uv/sdc/2019May/adaptive.html, the instance-level next-q is the only operation for adaptive SDC Questionnaires.
Lloyd McKenzie (Jan 09 2020 at 23:23):
Hmm. That's problematic. I'll submit a change request.
Lloyd McKenzie (Jan 09 2020 at 23:25):
Brian Kaney (Jan 09 2020 at 23:27):
Well in this case, it's more like "instance-level-like"... the service doesn't need to support FHIR instances, just this endpoint .. I think of it as putting the identifier to the Questionnaire in the URL segment instead of deeply nesting in the body.
Eric Haas (Jan 13 2020 at 01:04):
The adaptive-Q server may treat all incoming traffic the same, it knows nothing a priori, and will start from scratch each time, so its going to have to crack open the resource anyway, so it inspects the questionnaire's url to figure out what to do next.
I'm not sure if Lloyd is correct in what he said... I am not sure if the distinction of /Questionnaire$next-q and /Questionnaire/[id}/$next-q means that for the latter you have to have to be a FHIR Questionnaire repository. To the operation it is just another endpoint and can be treated as a black box. So the implementer can choose to have 1 general purpose endpoint or multiple specific endpoints.
I would think is easier for the service to maintain one endpoint and manage the standing up of new and deprecating of questionnaire processing behind the curtain. An easier for the client too. As an implementer you can use the (much ignored and unloved) CapStatement to define what you support.
Lloyd McKenzie (Jan 13 2020 at 01:58):
A system might have knowledge of a Questionnaire without necessarily exposing it at a RESTful endpoint. For some types of Questionnaires, the actual Questionnaire (with all of the logic about what questions are asked when, how they're scored, etc.) are never exposed to anyone. Obviously the contained Questionnaire will be shared, but that wouldn't have the URL that would be used when invoking the operation - as every contained Questionnaire will be unique to a given QuestionnaireResponse.
Eric Haas (Jan 13 2020 at 03:22):
in the Argo operation we document:
The Argo Adaptive QuestionnaireResponse Profile of the QuestionnaireResponse resource with a contained Questionnaire. The
urlelement in the contained Questionnaire identifies which set of questions are being requested.
and profile the url element to min =1 in both argo and sdc
I don't understand why this can not be used to key which AQ to run. Since the expectation is the AQ servers is stateless and starts from beginning every time. it only needs to know a starting point for its processing. is there some extension the AQ server should key off of instead?
Lloyd McKenzie (Jan 13 2020 at 03:42):
So your question is why the Questionnaire/[id]/$next-question version is necessary given that on invocation you can pass in the url? I'm thinking that it should be Questionnaire.derivedFrom, not Questionnaire.url though. Because the latter would be the canonical URL of the contained questionnaire - which would be unique to this specific QuestionnaireResponse...
Lloyd McKenzie (Jan 13 2020 at 03:43):
I guess I can by that the Questionnaire/[id] version isn't necessary. Care to submit a change request?
Eric Haas (Jan 13 2020 at 03:51):
OK so what you are saying the canonical is not the canonical for the proprietary AQ algorithm that company x produces ? but is rather the instance of the questionnaire that is regenerated each and every time the QR hits the endpoint? That questionnaire exists only in the context of the answers so I my mind there is nothing canonical about it. .derivedFrom makes sense based on the definition and should be min =1 question is should url be min=1?
Lloyd McKenzie (Jan 13 2020 at 04:31):
I don't see much point in having a URL on the contained questionnaire
Paul Lynch (Jan 13 2020 at 15:13):
@Lloyd McKenzie Then what indicates which adaptive Questionnaire (not the partial, contained one) is the one for which answers are being submitted?
Brian Kaney (Jan 13 2020 at 15:26):
@Paul Lynch -- I think if it's an instance-level operation, the adaptive Questionnaire would be the one specified in the URL path. If it's a type-level operation, we would need to have the URL in the contained (dynamic/partial) one for sure.
Brian Kaney (Jan 13 2020 at 15:27):
To follow up, I just realized the SDC IG has the operation without a dollar sign (it's just next-q), is this a typo, I would have expected to follow FHIR conventions with $next-q.
Lloyd McKenzie (Jan 13 2020 at 16:19):
The operation name doesn't included the dollar-sign. When invoking, you lead with the $. The notion is that when invoking next-question, you'd specify the Questionnaire.derivedFrom.
Lloyd McKenzie (Jan 13 2020 at 16:21):
Though as I think about queries, when you're searching you'd want to find all questionnaireResponses where questionnaire='official URL for questionnaire' - so maybe using URL is better. If we go that route, we're going to need to talk w/ FHIR-I about atypical use of a canonical reference...
Eric Haas (Jan 13 2020 at 18:50):
If we go that route, we're going to need to talk w/ FHIR-I about atypical use of a canonical reference...
I don't understand what is atypical. The url defines the adaptive Q and by definition the instance will be defined by the questions + algorithm?
Lloyd McKenzie (Jan 13 2020 at 19:25):
The canonical is supposed to be for the Questionnaire itself. Having different Questionnaire instances that share the same url (and the same version) even though they're contained may well be confusing. @Grahame Grieve, opinions?
Paul Lynch (Jan 13 2020 at 20:56):
In https://chat.fhir.org/#narrow/stream/179166-implementers/topic/Promoting.20contained.20resources.20to.20standalone/near/185530612, Grahame wrote "contained resources really shouldn't contain an identifier. that would be a clear marker for someone abusing contained resources". But, the SDC example of the contained Questionnaire has an identifier (http://hl7.org/fhir/uv/sdc/2019May/adaptive.html). @Lloyd McKenzie ?
Brian Kaney (Jan 13 2020 at 21:09):
I think we need to use the url then if identifier is off the table per that recommendation if it's not an instance-level operation.
Brian Kaney (Jan 13 2020 at 21:18):
In other word, the contained questionnaire is supposed to be ephemeral, but unless we only support instance-level operation /Questionnaire/:id/$next-q we don't have to worry about identification of the "authored" questionnaire, as it is expressed in the URL route. Otherwise we need it somewhere in the contained questionnaire...
Grahame Grieve (Jan 14 2020 at 02:35):
the URL does define the questionnaire. So each adaptive questionnaire instance will be different based on the process, and so have a different URL (a GUID, I'd expect). You'd use Questionnaire.identifier to link to the master definition for the Adaptive questionnaire
Eric Haas (Jan 14 2020 at 07:32):
https://jira.hl7.org/browse/FHIR-25460
Brian Postlethwaite (Jan 30 2020 at 10:50):
Someone correct me if I'm wrong, but isnt an adaptive Q still just a Q that dynamically gets questions?
Otherwise how do you know which one you're asking for?
AQ for mental health or AQ for home care or AQ for staff training?
Brian Postlethwaite (Jan 30 2020 at 10:51):
(essentially the catalog of start points)
Lloyd McKenzie (Jan 30 2020 at 20:53):
The contained questionnaire would be derivedFrom the authoritative Q
Brian Postlethwaite (Jan 30 2020 at 23:10):
Sure yes.
Brian Postlethwaite (Jan 30 2020 at 23:10):
But then is there anything authoratitive about an adaptive Q?
Lloyd McKenzie (Jan 31 2020 at 02:45):
The Q contained within the adaptive QR will be a 1-off. It won't likely have an identifier or a canonical URL
Last updated: Apr 12 2022 at 19:14 UTC
