Quantity comparisons for "unconvertible" units when they are the same
A recent fqm-execution issue (#352)[https://github.com/projecttacoma/fqm-execution/issues/352]. Uncovered an issue with comparison of unconvertible units in a GreaterOrEqual comparison of Quantity for [IU]/mL. ex logic:
Dalteparin.dosage ( ) >= 10000 '[IU]/mL'
The result of Datleparin.dosage ( ) is a Quantity 10000 '[IU]/mL'. It seems like this logic should result in true for the comparison, but it results in null. On deeper inspection this is occurring because the comparison logic for Quantity in the engine is converting the units even though they are the "same". The UCUM library we use refuses to convert [IU]/mL to [IU]/mL with the response "Attempt to convert arbitrary unit international unit per milliliter". This appears to be considered arbitrary because [IU] is different depending on the chemical.
This raises two questions?
- Is this actually correct that it should throw a fit here and return
nullfor this Quantity comparison of[IU]/mLto[IU]/mL? - Should Quantity comparisons of the same exact
unitactually skip past the conversion stop?
Ooooh. Interesting. I had to look this one up... It turns out that standalone conversion of units using [IU] is not possible because [IU] is considered an arbitrary unit; it means different things depending on the substance being measured.
I tried this using NLM's UCUM conversion web service (https://ucum.nlm.nih.gov/ucum-service/v1/ucumtransform/1/from/[IU]/mL/to/[IU]/mL) and got the following error (which, based on what I learned above, is expected):
ERROR: Attempt to convert to arbitrary unit "[IU]/mL".
Should CQL allow comparison between [IU]/mL and [IU]/mL?
-
Technically, no. When CQL does a comparison between two quantities, there is no guarantee that
[IU]means the same thing in quantity 1 as it does in quantity 2. Although they are notated the same ([IU]/mL) they do not necessarily represent the same thing. -
Practically, yes. If we were to reject any comparison using
[IU], then there would be some logic that could never be processed in CQL (or at least not without some pretty lame workarounds in the CQL). We probably need to support cases like the one you reported (Dalteparin.dosage ( ) >= 10000 '[IU]/mL').
The question is, how far do we want to go with this?
- Supporting comparison between
[IU]/mLand[IU]/mLis easy -- just skip the conversion. - But what about comparison between
[IU]/mLand[IU]/dL? The UCUM library would reject it as-is, so we'd need to essentially factor out the[IU]units (or replace them with a supported unit, like1). - And UCUM unit expressions can get even more complicated than that, so what about those?
- And to add one more wrinkle, apparently
[IU]and[iU]both mean "International Unit", so technically those are equivalent units (when measuring the same substance).
This is also complicated by the fact that although we're discussing [IU] for this case, [IU] is not the only arbitrary unit -- so if we wanted to support conversions between complex units that contain the same arbitrary unit components ([IU] or otherwise), we'd need to know what units are arbitrary (because we shouldn't special-case non-arbitrary units).
So... I think our options are:
- Go the "pure" route and say "no, we will not compare arbitrary units because technically they might mean different things". (This is the approach that NLM's UCUM library chose).
- Always skip conversion if the unit literal is exactly the same (e.g., support comparison of
[IU]/mLand[IU]/mL, but not[IU]/mLand[iU]/mL, nor[IU]/mLand[IU]/dL). - Attempt to support conversion of complex units involving arbitrary units (e.g.,
[IU]/mLand[IU]/dL) and potentially "equivalent" arbitrary units (e.g.,[IU]and[iU]).
I think we should do at least option 2 (support conversion when unit literals are an exact match). I'd like to consider option 3, but we'd probably want to investigate further since there may be some gotchas there.
Option 1 feels like the right approach and we could suggest the measure developers to check the unit and value in CQL logic. But the intent of the comparison they are doing is of the same exact substance. Presumably the logic has already filtered out the medications that are not the exact one measured by [IU]/mL.
Option 2 does make logical sense as a result of the most likely intent of the logic. This is also the easiest to implement and may speed up some calculations since we wont be diving into the conversion code for no reason.
Option 3 might be pretty difficult and seems like potentially the wrong approach. To do this we might convert the [IU] to 1 before passing into the UCUM library and asking it to convert.