Stream: questionnaire
Topic: Custom error messages
Fred Hersch (Jun 03 2021 at 12:38):
When designing a Questionnaire that will be rendered in an app, we want to be able to return custom error messages (e.g. for specific items) in local language. Is there an extension for this? How is this currently handled? Thanks
@Jing Tang @Jose Costa Teixeira @Lloyd McKenzie
David Winters (Jun 03 2021 at 12:54):
Where would the error message be displayed? You could use cqf-calculatedValue on the text element of an item in the Questionnaire.
Fred Hersch (Jun 03 2021 at 13:42):
Thanks @David Winters the messages would be displayed on the UI .. in this instance it's an android app so under the field
Fred Hersch (Jun 03 2021 at 13:44):
This would still need to map to some content string that could have different language options ...
One solution, would be to have these be specified within the client application itself ... and they can be tailored by the implementer .. not within the Questionnaire itself
Jose Costa Teixeira (Jun 03 2021 at 14:05):
AFAIK, there is no extension for this. I think it's a reasonable ask
Jose Costa Teixeira (Jun 03 2021 at 14:05):
IIRC, we're talking about a message like Incorrect date format. Please use the format yyyy-mm-dd. I think the client might have some generic capabilities, but this could be an interesting extension when the messages are specific for a question.
Fred Hersch (Jun 03 2021 at 14:09):
@Jose Costa Teixeira Yes, that is correct. Thanks for adding that context :)
Jose Costa Teixeira (Jun 03 2021 at 14:24):
@Lloyd McKenzie @Paul Lynch, others - is this the first time this request comes up?
Lloyd McKenzie (Jun 03 2021 at 14:44):
You can have enableWhen (and the enableWhenExpression extension) turned on for 'display' items the same as questions and groups. And you can have translations for display items the same as you can have for other elements. That's what you can do within the Questionnaire design itself. If you're wanting to change the messages spit out by the data entry tool in response to regular rules (e.g. typing characters in a numeric or date field, specifying a non-existent month, going over length limits, etc.), that's a problem for the tool and not something that would show up in the resource. (It would also be independent of what Questionnaire you were filling out.)
Fred Hersch (Jun 04 2021 at 01:17):
Thanks @Lloyd McKenzie that makes sense. cc: @Jing Tang @Kunjan Patel
Jing Tang (Jun 14 2021 at 11:33):
@Lloyd McKenzie thanks for the reply. I agree that for the most part, the error message for validation is nothing to do with the questionnaire itself. but i think there still are cases where the error message might be more tailored to the clinical setting and therefore should be provided by the questionnaire. i agree that a hidden display field can be used, but it does appear a bit "hacky", and depending on the UI it might not actually make sense (for example, maybe the validation message is part of your text input box to give the user the idea that the message is for the input, rather than the error message appearing as a totally separate item following the question and answer). if we already have the validation extensions, it seems to make sense to have error messages attached.
Brian Postlethwaite (Jun 14 2021 at 13:59):
When does are reported by the validation engine, they include the location of the question /answer with the error, and that message is usually highlighted beside the field.
When my server validates them, it includes the field text in the message too.
Brian Postlethwaite (Jun 14 2021 at 14:01):
E.g. Invalid date of birth value entered (17/17/2012)
Brian Postlethwaite (Jun 14 2021 at 14:02):
Or mandatory date of birth field missing
Jing Tang (Jun 15 2021 at 10:59):
yeah that makes perfect sense - but the error message isn't coming from the questionnaire right? i think what Lloyd proposed (using the hidden display item for custom error messages) would not be using the validation engine (or maybe you can have both, a validation engine that returns an validation error, and a custom message also displayed by showing an otherwise hidden field)
Lloyd McKenzie (Jun 24 2021 at 23:49):
I think those are your two options. If you want complete control over what the message is, then use a 'display' item (possibly as a child of your Question) that conditionally appears based on rules you specify. Otherwise, you can just specify the constraints and it'll be up to the rendering tool to decide how that gets displayed. Good ones will highlight the relevant field(s) and provide user-friendly messages, but you can't necessarily count on consistency.
Lloyd McKenzie (Jun 24 2021 at 23:50):
Obviously if you're controlling the data entry client, you can control the messaging. But I don't think we can reasonably try to allow 'standardized' customization of messaging from third-party rendering tools.
Brian Postlethwaite (Jun 24 2021 at 23:53):
I would fully recommend the fhirpath constraints from SDC if I wanted custom messages created, however incorporating entered data in those isn't described anywhere.
Brian Postlethwaite (Jun 24 2021 at 23:54):
And showing a display field conditionally as an error message feels very weird, and won't look like other errors handled by the renderer...
Ours has multiple choices depending on host context - all done through information coming out as an OperationOutcome - even when internal in the browser.
Lloyd McKenzie (Jun 25 2021 at 00:04):
The item.text can use an extension for CQL to define its content. We've got a pending approved change request to add that. That would give you your context-specific message.
Last updated: Apr 12 2022 at 19:14 UTC
