cqframework / cqframework/cql-execution
Quantity comparisons for "unconvertible" units when they are the same
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 84
- Forks
- 38
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 1
Description
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?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the GreaterOrEqual example with Quantity values using the exact same unit [IU]/mL, then trace the engine's Quantity comparison and UCUM conversion behavior. Done means the expected behavior for identical arbitrary units is decided and covered by a regression test, including whether the comparison returns true rather than null.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100