FHIR Chat · Multiple unit choices for an answer

Stream: questionnaire

Topic: Multiple unit choices for an answer

Paul Lynch (Nov 02 2018 at 16:52):

If you have a Questionnaire question for height in which the user can choose units of either inches or meters, and then you want to do a BMI calculation (or something else) with that entered quantity, is there a way in which the FHIRPath expression can retrieve the value entered in a particular desired unit? For instance if the BMI rule is expecting the height in meters, but the user has selected inches, is there some way in which the height in meters can be obtained?

Now that I think about it, it might be possible to write a rather complicated FHIRPath expression for this if the possible units are known in advance (for instance, if it is known that the units are either inches or meters and not cm or feet). But is there, or should there be, some support for this from Questionnaire/QuestionnaireResponse?

Lloyd McKenzie (Nov 02 2018 at 17:04):

So you're asking if FHIRPath can do UCUM unit conversions for you? That sounds like a good question to ask in a FHIRPath specific stream. It'd be an awesome feature, but not one I can recall having seen in the spec.

Paul Lynch (Nov 02 2018 at 17:12):

No, although that is an interesting question as well. I was asking if Questionnaire/QR would have some support for doing that, for instance, by specifying that the value obtained from QR.answer.valueCoding would be in a particular unit, and not necessarily the unit the user selected when entering the data.

Just for reference, the following FHIRPath expression could work if it is known that the units are either inches or meters:

(%height.answer.valueQuantity.where(unit='[in_i]').value*0.0254).combine(%height.answer.valueQuantity.where(unit='m').value)

But, what I am really wondering here is whether that is necessary. There might be a situation in which the user could pick a UCUM unit not defined on the form (like cm).

Lloyd McKenzie (Nov 02 2018 at 17:19):

Not following how you could presume that the data would be in anything other than the unit the user specified...

Paul Lynch (Nov 02 2018 at 17:28):

The form renderer would convert what the user entered to the target unit specified in the Questionnaire, so that when the QR data was accessed, it would be in that unit.

Lloyd McKenzie (Nov 02 2018 at 17:33):

Transformation between user entry and what's stored? That's quite contrary to the base purpose of QuestionnaireResponse - which is to be a precise record of what the user actually entered. The transformation happens during the conversion process. If you wanted to calculate the value of a separate hidden question, you could do that, but I wouldn't be in favor of anything that changes user-entered data.

Paul Lynch (Nov 02 2018 at 17:39):

It would not need to affect the answer that was stored under item.answer.valueQuantity. Perhaps the transformed value could be stored on a different attribute.

Lloyd McKenzie (Nov 02 2018 at 17:48):

You could stick it in an extension I suppose, but I'd lean towards a hidden question.

Paul Lynch (Nov 02 2018 at 18:03):

A hidden question presumes that a form designer knows what transformation to make and put in the hidden question. I think it will probably be necessary for a some external library call to be made (e.g. by the form renderer) to do the transformation from the actual to desired unit.

The other option other than an extension on Questionnaire would be to put something in FHIRPath (as you mentioned) for converting one Quantity to another Quantity with the desired unit. That might have wider usefulness.

Brian Postlethwaite (Nov 03 2018 at 01:49):

Out of curiosity, what is the ucum unit that you're converting?

Paul Lynch (Nov 05 2018 at 16:43):

Inches to meters. [in_i] to m.

Grahame Grieve (Nov 09 2018 at 00:20):

so we haven't surfaced this in FHIRPath. It's not that hard to implement assuming you have a UCUM library (and there are UCUM libraries for most languages these days).

Grahame Grieve (Nov 09 2018 at 00:22):

given that we have quantity as a type, it would make sense to add 2 functions to it:
boolean quantity.convertsTo(String unit)
quantity quantity.convert(String unit)

Grahame Grieve (Nov 09 2018 at 00:22):

@Bryn Rhodes what say you?

Bryn Rhodes (Nov 09 2018 at 01:28):

Since we already have convertsToQuantity and toQuantity, I would suggest just adding an optional overload to those functions unit: String that would support the behavior.