FHIR Chat · Constraining precision for dates · questionnaire

Stream: questionnaire

Topic: Constraining precision for dates


view this post on Zulip Morten Ernebjerg (Dec 09 2020 at 11:03):

Hi :wave: We have a questionnaire where we ask for the patient's birth year. The appropriate data type for the answer would seem to be date, but that of course allows giving month and day, too (in conflict with the LOINC code we attach to the question, which is explicitly for just the year). Is there some standard way of telling a Questionnaire renderer that it should only allow the year? - something like the max decimal places extension, but for dates. With custom logic one could infer it from the LOINC code or one could switch to collecting the year as an integer, but neither of those solutions feel quite right.

view this post on Zulip Paul Lynch (Dec 09 2020 at 13:28):

Are there problems/issues with collecting it as an integer? If not, wouldn't that be preferable to adding another extension that needs to be supported?

view this post on Zulip Morten Ernebjerg (Dec 09 2020 at 14:29):

We definitely could collect it as an integer and I agree it has advantages. It just seemed slightly awkward, given that the FHIR date type actually supports year-only dates and hence seems to be the semantically correct data type.

view this post on Zulip Lloyd McKenzie (Dec 09 2020 at 15:18):

You could specify a max length as an extension, but I expect a lot of entry tools would struggle. When choosing the type in Questionnaire design, it's best to think "what user interface widget is that going to be associate with" - and most tools will use a calendar-type widget for dates, while an integer would let you just type in a value or maybe scroll it higher or lower.

view this post on Zulip Morten Ernebjerg (Dec 09 2020 at 19:00):

OK, that's a helpful way to think about it - I'll reconsider plain ol' integer, then.

view this post on Zulip Elliot Silver (Dec 12 2020 at 22:09):

I suppose the same applies to using dateTime items. FHIR has no problem with date-only dateTime data, but would a UI require both (and minute precision on the date)? Is there an example of best practice here? Do we need a time-only item-type?

view this post on Zulip Lloyd McKenzie (Dec 13 2020 at 03:32):

We allow 'time' as a stand-alone answer type.

view this post on Zulip Elliot Silver (Dec 13 2020 at 03:36):

You’re right. I missed that when I was looking earlier. (I need to read more carefully. It would cut down on the number of my posts.)

view this post on Zulip Brian Postlethwaite (Jan 11 2021 at 00:11):

I'd be using the fhirpath expression validation here - doesn't help with UI hints to make the user experience better, but it is should be adopted more easily?


Last updated: Apr 12 2022 at 19:14 UTC