Stream: questionnaire
Topic: Using one QR for many Qs
Eric Haas (Jul 12 2018 at 13:40):
Pondering whether/if the Q.questionnaire (url) should be on item so can mash multiple Qs in one QR. The use case is Adaptive Forms where each Q is a single item(question) could still be 1:1 , but would there be any advantage to 'many' Q : 1 QR
Lloyd McKenzie (Jul 12 2018 at 14:27):
The whole definition of QuestionnaireResponse is that it's a response to a Questionnaire. If you have a dynamic form, you still have a single "logical" Questionnaire that defines the scope and pattern for what questions were being asked. There's also a form-specific Questionnaire that reflects exactly what questions were asked in what order. The meaning for each question would come from the item.definition, not from pointing to multiple Questionnaires. The piece we may need to add is the ability to share a Questionnaire that doesn't actually include its questions so that we can expose the metadata for a globaly dynamic form definition. We might also need an ability to point to both the answer-specific questionnaire and to the global form.
Eric Haas (Jul 12 2018 at 15:44):
Right now I think a groupIdentifier like extension would work. I not sure the client would need to be aware of the form, since all they see is series of questions. What you end up with is essentially a flat form. All the magic is happening behind the curtain. If the Adaptive Q Server wants to share the form-specific questionnaire that is an implementation specific decision.
Lloyd McKenzie (Jul 12 2018 at 15:49):
A system consuming the QuestionnaireResponse would need the Questionnaire reference in order to be able to make sense of the data. You'd also need it to query for the QuestionnnaireResponses stored on a server
Eric Haas (Jul 12 2018 at 15:54):
- So Client initiates ---> Server Sends a Q1 = Intro page (item :group|display intro text|boolean to start)
- Client q1:a1 = True ----> Server Sends Q2 = item:q2
- Client q2:a2 = True ----> Server Sends Q8 = item:q8
- Client q8:a3 = True ----> Server Sends 'done: here is your score = ∞'
Q1..Q19 all belong to same group each with question.
Eric Haas (Jul 12 2018 at 15:57):
I agree with this
"A system consuming the QuestionnaireResponse would need the Questionnaire reference in order to be able to make sense of the data. You'd also need it to query for the QuestionnnaireResponses stored on a server"
Eric Haas (Jul 12 2018 at 15:59):
but if the magic is done by the server does it have to be represented in the questionnaire? ( what if its proprietary logic)
Eric Haas (Jul 12 2018 at 16:00):
so things like enableWhen etc. back to flatter is better :-) Just flatten the list to the actual questions?
Eric Haas (Jul 12 2018 at 16:02):
mmmm I'm thinking the client will need to construct on the fly a new QR with a new contained Q.....
Eric Haas (Jul 12 2018 at 16:02):
... thats the ticket for now...!
Lloyd McKenzie (Jul 12 2018 at 16:14):
Agree with the contained Q approach. The trick is how you query to find the QRs that all have "custom" embedded Qs that are all based on a shared "non-exposed" Q. The shared Q wouldn't necessarily expose the questions or the logic, but would be relevant for search purposes. The "custom" Qs would have the link to the data elements that provide the semantics and would show what answer choices the user was actually given
Last updated: Apr 12 2022 at 19:14 UTC
