Stream: implementers
Topic: Why answerInstant in Questionnaire?
Marc de Graauw (Dec 06 2016 at 14:42):
Questionnaire has answerInstant of type instance. 'instance' says: "This is intended for precisely observed times (typically system logs etc.), and not human-reported times - for them, use date and dateTime. " and Questionnaire says: "...intended to solicit information from patients, providers or other individuals ". So why answerInstant? Seems it never should be used.
Lloyd McKenzie (Dec 06 2016 at 15:53):
@Marc de Graauw Good question. I know we looked carefully at all the data types and had a use-case for each one we retained, but I can't recall why we included this one - particularly that you can accomplish the same thing using dateTime with a constraint on length. Feel free to submit a change request.
Pascal Pfiffner (Dec 06 2016 at 18:45):
I can see a use-case when your system precisely reports when you tap the screen to answer a question (this would be a sister element to the question you want to measure – yes, quite the hack).
Grahame Grieve (Dec 06 2016 at 19:30):
agree. no need for instant; it's only real function is to force an answer to be the a fully specified time.
Marc de Graauw (Dec 06 2016 at 20:35):
Added item GF12434
Brian Postlethwaite (Dec 06 2016 at 21:38):
Although I'm not using the instant as the moment some questionnaires where may have fields are person entered, and others software entered (through the pre-population actions)
Without this will need to add additional validation to ensure all the values are included, and particularly if collecting content and then converting into other resources like that have an instant type property.
But yes, we can just use the dateTime type and convert if needed
Marc de Graauw (Dec 07 2016 at 08:17):
Prepopulation of fields which are then revivsed and submitted by humans does not justify answerInstant, I think. If there is a proper use case for system-prepopulated time fields which are NOT reviewed by humans, answerInstant is the right choice, but then the goal of Questionnaire should become: "... solicit information from patients, providers or other individuals OR SYSTEMS involved in the healthcare domain". Note: I'm not against answerInstant, I just noted an inconsistency in definitions.
Bryn Rhodes (Dec 07 2016 at 19:03):
Agree with that assessment, but my vote would be to change the definition as you suggest to allow Questionnaires to be used to capture content from both humans and systems.
Lloyd McKenzie (Dec 07 2016 at 22:35):
Questionnaires are focused on capturing information from humans. That doesn't mean they can't be used for capturing data solely from systems, but this use is well outside the 80% in terms of the design.
Brian Postlethwaite (Dec 10 2016 at 06:56):
I wasn't suggesting one or other, but a mix. some content is prefilled (prepopulate) then the user finish the rest (and potentially edit some of it)
Lloyd McKenzie (Dec 10 2016 at 15:18):
Prefilled content is focused on simplifying the user-entry experience. Questionnaires are still designed on the basis the user would have to fill in all of the information. The usecase of passing a questionnaire to share an arbitrary set of information between two systems is not a primary focus of the resource (and from an interoperability perspective is essentially passing around custom XML)
Michelle (Moseman) Miller (Jan 13 2017 at 14:16):
I was getting ready to apply GF#12434, but I think the tracker (and approved resolution) is a little vague in hind sight, so I wanted to double check the expected impact / stuff to be removed:
1) Questionnaire.item.enableWhen.answerInstant (remove instant data type choice)
2) Questionnaire.item.initialInstant (remove instant data type choice)
3) valueset-item-type - remove instant code from the value set
4) QuestionnaireResponse.item.answer.valueInstant (remove instant data type choice)
Does that match everyone's understanding?
Lloyd McKenzie (Jan 13 2017 at 15:48):
That matches with my understanding . . .
Last updated: Apr 12 2022 at 19:14 UTC
