Add support for the questionnaire-unit extension

[williamito]

Is your feature request related to a problem? Please describe.
The full definition of the "quantity" type is:

Question with a combination of a numeric value and unit, potentially with a comparator (<, >, etc.) as an answer. (valueQuantity) There is an extension 'http://hl7.org/fhir/StructureDefinition/questionnaire-unit' that can be used to define what unit should be captured (or the unit that has a ucum conversion from the provided unit).

http://hl7.org/fhir/StructureDefinition/questionnaire-unit extension support is not listed either yes or no on FHIR specification support page, but based on some testing, we seem to ignore it. However, in the definition of the questionnaire-unit extension it states:

Context of Use: Use on Element ID Questionnaire.item or Element ID Questionnaire.item.item, with Context Invariant = type='integer' or type='decimal'

So the actual way to use type='quantity' are the unitOption or unitValueSet extensions which we explicitly do not support, but without which type='quantity' is just a strictly worse version of 'integer' or 'decimal'.

You can see examples of both versions in this LHC Forms unit test questionnaire JSON.

Describe the solution you'd like
Add support for the questionnaire-unit extension. If it is used on an item of type='integer' or type='decimal, it should:

1. Visibly show the unit in the rendered Questionnaire
2. In the questionnareResponse, generate a valueQuantity
3. Populate the valueQuantity with any unit, system, code information provided in questionnaire-unit

Prioritize support for unitOption or unitValueSet, where it should:
1. Show a unit picker (dropdown?) in the rendered Questionnaire
2. In the questionnareResponse, generate a valueQuantity
3. Populate the valueQuantity with any unit, system, code information provided in questionnaire-unit

Lower/caveat the stated support of type='quantity' until a method of unit selection is available.

[fredhersch]

@shelaghm can you work with @williamito on UI design for this

[williamito]

@fredhersch I edited this issue to just be for the questionnaire-unit extension and created #1600 for the rest. I think we discussed this scoping would be a P1?

[shelaghm]

@williamito Is there a UI design need here or are we all set?

[williamito]

@shelaghm Some design needed - how to render the unit associated with an item if specified in the Questionnaire. For example, a questionnaire might have a decimal item where the unit is specified as kg, so that should be shown somehow. I don't know what the longest string that might occur is. LMK if you need more context.

[shelaghm]

@williamito

Here are the existing design mocks I have. This implies that the user can select the unit type. I assume we also need functionality for a static unit like kg when there's only one option?

[williamito]

Thanks! Yes, this is specifically for the static case.

[shelaghm]

Could we use the hint text field to show the units? What do you think of that?
Alternative could be to have leading text. See screenshot for both options.

[williamito]

If the hint text isn't used for anything else, that makes sense to me.

[delcroip]

Dear,

I made a change that add the support of the extension when saving the answer (I need that for proper mapping and calculatedExpression) BUT this is my first Kotlin development AND I am not happy where I added to unit but the item object in not accessible anymore when the new answer is added/set

Index: datacapture/src/main/java/com/google/android/fhir/datacapture/views/QuestionnaireItemViewItem.kt
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/datacapture/src/main/java/com/google/android/fhir/datacapture/views/QuestionnaireItemViewItem.kt b/datacapture/src/main/java/com/google/android/fhir/datacapture/views/QuestionnaireItemViewItem.kt
--- a/datacapture/src/main/java/com/google/android/fhir/datacapture/views/QuestionnaireItemViewItem.kt	(revision f6806147caee3b9d91d7c95c5a801832027d2d0a)
+++ b/datacapture/src/main/java/com/google/android/fhir/datacapture/views/QuestionnaireItemViewItem.kt	(date 1667306276589)
@@ -26,8 +26,7 @@
 import com.google.android.fhir.datacapture.validation.ValidationResult
 import kotlinx.coroutines.Dispatchers
 import kotlinx.coroutines.runBlocking
-import org.hl7.fhir.r4.model.Questionnaire
-import org.hl7.fhir.r4.model.QuestionnaireResponse
+import org.hl7.fhir.r4.model.*
 
 /**
  * Data item for [QuestionnaireItemViewHolder] in [RecyclerView].
@@ -101,6 +100,18 @@
     check(questionnaireItem.repeats || questionnaireResponseItemAnswerComponent.size <= 1) {
       "Questionnaire item with linkId ${questionnaireItem.linkId} has repeated answers."
     }
+    /** add the unit from the extension */
+    if (!questionnaireItem.repeats && questionnaireItem.type === Questionnaire.QuestionnaireItemType.fromCode("quantity")) {
+      var unit_exts = questionnaireItem.extension.filter{ it.url.toString() == "http://hl7.org/fhir/StructureDefinition/questionnaire-unit"}
+      if (unit_exts.size > 0 ) {
+        var unit_ext: Extension = unit_exts.first()
+        var unit_coding: Coding = unit_ext.castToCoding(unit_ext.value)
+        questionnaireResponseItemAnswerComponent.filter { it.value is Quantity && it.valueQuantity.code == null &&  it.valueQuantity.unit == null}.forEach {
+          it.valueQuantity.code = unit_coding.code
+          it.valueQuantity.system = unit_coding.system
+        }
+      }
+    }
     answersChangedCallback(
       questionnaireItem,
       questionnaireResponseItem,

[jingtang10]

thanks patrick for this draft code snippet - we'll create a pr for this

[delcroip]

Update, indeed questionnaire-unit is not the right extension, my code might not be relevant, I will try with unitOption

[jingtang10]

If the hint text isn't used for anything else, that makes sense to me.

I like the alt version though - because I feel the UI would be more consistent with #1600. And the unit itself is more conspicuous.

@williamito @shelaghm

[shelaghm]

@jingtang10
Sounds good, I can go either way, so we can move forward with static units being shown as a trailing element behind the text field to be more consistent with #1600