FHIR Chat · FHIRPath Quantity Comparisons · implementers

Stream: implementers

Topic: FHIRPath Quantity Comparisons


view this post on Zulip Grahame Grieve (Dec 05 2017 at 21:31):

@Bryn Rhodes @Ewout Kramer @Brian Postlethwaite I thought that we set up quanity for comparisons - and I did comparisons in my code...?

view this post on Zulip Grahame Grieve (Dec 05 2017 at 21:31):

see GF#14194

view this post on Zulip Bryn Rhodes (Dec 05 2017 at 21:44):

Yeah, I thought we did as well, and we even have examples in the spec that use quantity comparisons. But after looking for it, the submitter is right, we don't explicitly define the semantics for quantity arithmetic, except for date/time values.

view this post on Zulip Bryn Rhodes (Dec 05 2017 at 21:49):

Here's what we say about it in general in CQL:

view this post on Zulip Bryn Rhodes (Dec 05 2017 at 21:49):

Note that complete support for unit conversion for all valid UCUM units would be ideal, but practical CQL implementations will likely provide support for a subset of units for commonly used clinical dimensions. At a minimum, however, a CQL implementation must respect units and throw an error if it is not capable of normalizing the quantities involved in a given expression to a common unit.

view this post on Zulip Bryn Rhodes (Dec 05 2017 at 21:49):

And then we have specific wording for each operator family, for instance, comparisons:

view this post on Zulip Bryn Rhodes (Dec 05 2017 at 21:49):

For comparisons involving quantities, the dimensions of each quantity must be the same, but not necessarily the unit. For example, units of 'cm' and 'm' are comparable, but units of 'cm2' and 'cm' are not. Attempting to operate on quantities with invalid units will result in a run-time error.

view this post on Zulip Ewout Kramer (Dec 06 2017 at 08:44):

I can certainly see the value of adding it - how else to create meaningful constraints on quantity or use FhirPath expressions in CQL? The only counter argument may be that implementing quantity comparisons is not easy, so it sets a higher bar for implementers of an evaluation engine if we add it.

view this post on Zulip Bryn Rhodes (Dec 06 2017 at 15:25):

True about the bar for implementation, but the language we have in CQL only requires that implementations respect units, not that necessarily implement full support. In addition, we have Java, .NET, and I believe JS implementations of the UCUM library, so integrating the support should be straightforward.


Last updated: Apr 12 2022 at 19:14 UTC