FHIR Chat · Quantity Intervals

Stream: cql

Topic: Quantity Intervals

Alexander Kiel (Jan 10 2022 at 16:09):

Are Quantities a valid point type for intervals? The spec says:

An interval must be defined using a point type that supports comparison, as well as Successor and Predecessor operations, and Minimum and Maximum Value operations.

However neither Successor, Predecessor, Minimum or Maximum Value operations are defined for Quantity.

On the other hand there are tests with Quantity Intervals like QuantityIntervalUnion1To15.

Chris Moesel (Jan 10 2022 at 17:21):

@Alexander Kiel - I think the intent is that quantity is supported in an interval. Successor and Predecessor are actually defined for Quantity (see the CQL Reference). You're right that MinimumValue and MaximumValue are not explicitly defined for Quantity; probably because it's unclear what unit should be used for min/max Quantity type. But for the purposes of something like an interval, it's really the min/max of the Quantity.value (which is min/max of Decimal) that matters. So... sounds like a clarification is needed in the spec. @Bryn Rhodes?

Alexander Kiel (Jan 10 2022 at 17:30):

@Chris Moesel Thanks. You are right. Successor and Predecessor are defined for Quantity in the CQL Reference. But Quantity is not defined in the ELM Reference. Because I implement my CQL evaluator on top of ELM, I actually don't look in the CQL Reference very often. So I guess that the ELM Reference needs to be extended.

As for minimum- / maximum value. In an interval context the unit should just be the unit of the explicit boundary. But standalone the unit is not clear. Also it is not clear if the quantity is an integer or a decimal one.

Chris Moesel (Jan 10 2022 at 18:04):

I agree that the unit should be the unit of the boundary, but... the minimum/maximum functions take in a type declaration, and I don't think it's possible to put the quantity unit into a type declaration. So if Minimum/Maximum were to explicitly support Quantity then the unit in the return value I guess would have to just be null.

Things also get ambiguous for intervals w/ mixed units (e.g., Interval[1 'mg', 1000 'g']). If you just apply minimum/maximum to quantity values (w/out paying attention to unit at all), then you can get different max width intervals depending on if the interval quantity units are normalized or not. So that's fun.

As for a quantity being an integer or decimal, by definition, CQL Quantity value is always a Decimal.

Alexander Kiel (Jan 10 2022 at 18:45):

@Chris Moesel

As for a quantity being an integer or decimal, by definition, CQL Quantity value is always a Decimal.

If this is true than that sentence from the Successor - CQL Reference has redundant information. So the integer part should be removed.

For Quantity values, the successor is equivalent to adding 1 if the quantity is an integer, and the minimum precision value for the Decimal type if the quantity is a decimal. The units are unchanged.

Chris Moesel (Jan 10 2022 at 19:09):

Oh. I read right past that part. Ugh. It may be that although the datatype is a Decimal, successor should treat it like datatype Integer if it does not have a fractional component (i.e., a pseudo-Integer). This is probably another bit that should be clarified, as I agree that it is confusing. Good catch, @Alexander Kiel.

Alexander Kiel (Jan 11 2022 at 13:44):

@Bryn Rhodes @Chris Moesel What's next? Can I help to fix the spec? Should I issue PR's on the HL7/cql repo? I've currently two other PR's open on that repo.

Chris Moesel (Jan 11 2022 at 13:49):

Since these are proposed changes to the spec (even if just fixing errors / clarifying), I think you need to submit a change request on Jira so they can be voted on in a WG. Then they can be applied to the spec after that.

Bryn Rhodes (Feb 02 2022 at 16:49):

Apologies for the delays here @Alexander Kiel and @Chris Moesel , I've submitted trackers to clarify these and we'll get these included in the upcoming Errata.