Stream: implementers
Topic: FHIR UCUM Valueset concerns
Devin Craft (Aug 31 2018 at 20:22):
Hi all,
I'm growing concerned about some of the codes that are in the UCUM valueset. I've already found a few codes that are invalid (I'm eventually going to run all codes in the valueset through https://ucum.nlm.nih.gov/ucum-lhc/demo.html and submit the broken ones in a tracker item), but I am also concerned about some of the curly bracket codes (annotations) in the valueset.
Codes such as {2 or 3 times}/d are problematic, because, according to ucum: An annotation without a leading symbol implies the default unit 1 (the unity)
If the annotation is resolved to 1, then {2 or 3 times}/d will end up being interpreted as 1/d, which seems problematic. I'm thinking any use of annotations that have a numeric value other than 1 should be avoided.
Am I correct to be concerned about these codes?
Thanks!
Grahame Grieve (Aug 31 2018 at 20:52):
yes you are right to be concerned. Please let us know about such issues in tasks. Probably good to have different tasks for different kinds of problems. But I did think I had validated all the ucum codes for technical correctness
Lloyd McKenzie (Aug 31 2018 at 21:16):
The {2 or 3 times}/d is technically correct - but semantically wrong. We should probably flag all codes that have {} in them - as a rule, we should avoid those in most cases
Grahame Grieve (Aug 31 2018 at 21:18):
one question is what the purpose of the common ucum value set is - terminology servers / systems that don't support the grammar are using it as a proxy, which is why it's leaning towards comprehensiveness. (and you might think that this should be uncommon, but no.......)
Devin Craft (Sep 04 2018 at 12:44):
I agree with @Lloyd McKenzie that {} codes should be avoided whenever possible, however, I can see how keeping the context the annotations (curly brace codes} provide is useful. For example, {doses}/day and {times}/day both resolve to 1/day. But a system which recognizes them as individual codes can leverage the distinction. I don't know if that's technically correct, but might be a reality for systems migrating from another unit code system, such as snomed, to be compliant with FHIR.
I believe this case should be expressed as {times}/day and the quantity should be expressed elsewhere.
Devin Craft (Sep 04 2018 at 13:16):
Thinking aloud - it's possible this is due directly to the migration from snomed. See snomed code 396112008|Three to four times a day (qualifier value). @Lloyd McKenzie what would be the best way to model such a code with ucum? Or is that the wrong question? Should ucums even be used for such use cases?
Lloyd McKenzie (Sep 04 2018 at 14:19):
The 3-4 /day would be handled using Range data type. So it would be 3 1/d - 4 1/d where both the low and the high would have the 1/d unit. Our examples should only use brackets where it's essential to interpretation. E.g . mm{Hg}
Last updated: Apr 12 2022 at 19:14 UTC
