FHIR Chat · Implicit Value sets for UCUM · terminology

Stream: terminology

Topic: Implicit Value sets for UCUM

Grahame Grieve (May 20 2020 at 21:34):

I would like to specify a way to define am implicit value set in UCUM. The implicit value sets would equate to "all units compatible with this canonical unit" e.g. all units that have a canonical unit of m for length, or s for time, mol/L for concentration etc.

We would also define one based on dimension, but I think that most real world units will be more complex than dimension.

Right now, we can do this in a value set:

  <compose>
    <include>
      <system value="http://unitsofmeasure.org"/>
      <filter>
       <property value="canonical"/>
       <op value="="/>
       <value value="mmol/L"/>
      </filter>
    </include>
  </compose>

Grahame Grieve (May 20 2020 at 21:35):

something like http://unitsofmeasure.org/vs?canonical=mmol/L

Christof Gessner (May 21 2020 at 00:19):

Why constrain it to canonical units?

Grahame Grieve (May 21 2020 at 01:39):

I'm not sure what you mean

Grahame Grieve (May 21 2020 at 01:40):

I want to constrain to all units compatible with a unit. What other value sets do you think would be useful?

Grahame Grieve (May 21 2020 at 01:40):

oh. scratch all this. I didn't read far enough. This is already defined

Christof Gessner (May 21 2020 at 10:25):

okay. where can I find the definition? I was just trying to suggest: ...equate to "all units compatible with this canonical unit" e.g. all units that have a the same canonical unit "

Christof Gessner (May 21 2020 at 10:28):

so if I have one unit, say inch, and I want to check if it is commensurable with another unit, say mm, I would just check if mm is in the said value set for inch (or vice versa). No need to find their common canonical unit beforehand.

Grahame Grieve (May 21 2020 at 10:50):

well, in practice, that's what it means, yes. https://www.hl7.org/fhir/ucum.html#4.3.4.5

Grahame Grieve (May 21 2020 at 10:51):

except that the definition is wrong. It should be

Grahame Grieve (May 21 2020 at 10:51):

<ValueSet xmlns="http://hl7.org/fhir">
  <text>
    <status value="generated"/>
    <div xmlns="http://www.w3.org/1999/xhtml">
      [some html that identifies that this value set
      includes all UCUM expressions that are comparable to the provided expression]
    </div>
  </text>
  <identifier value="http://unitsofmeasure.org/vs/[expression]"/>
  <version value="[optional - but recommended - UCUM version]"/>
  <name value="Ucum Expressions comparable to [expression]"/>
  <description value="Ucum Expressions comparable to [expression]"/>
  <status value="active"/>
  <date value="[optional date of UCUM release]"/>
  <compose>
    <include>
      <system value="http://unitsofmeasure.org"/>
      <filter>
        <property value="canonical"/>
        <op value="="/>
        <value value="[expression]"/>
      </filter>
    </include>
  </compose>
</ValueSet>

Christof Gessner (May 21 2020 at 11:18):

Thanks. Still not clear to me, why the term 'canonical' is used here. In the given context, 'comparable' could be more appropriate here.

Actually, looking at this documentation, I have another issue: It states that "Display: There is no defined display; the UCUM code is used directly for the display". I wouldn't agree, and we are actually having discussions on this in the European eHDSI project. UCUM is a code, it is not always correct to display the code verbatim. Instead, the correct 'displayable representation' should be derived from the rules in the ISO 80000 series. There is some ongoing collaboration between ISO/TC 215 and ISO/TC 12 on the issue, cf. Mike Glickman. (And in addition to that, people are also requesting a multilingual 'textual representation' like 'millimetros' in Spanish...)

Grahame Grieve (May 21 2020 at 11:20):

I agree that comparable would be clearer, but we'd have to change the definition of the filter instead of changing the definition of the implicit value set. I'm not sure whether anyone has used this... since I haven't and I don't think any tooling supports it, it might be safe to change

Grahame Grieve (May 21 2020 at 11:20):

with regard to the display.. I'm not so sure on that. We can't point to advice that doesn't exist... we can look at it once it does

Christof Gessner (May 21 2020 at 11:23):

I agree, there is no solution ready to use now. But to directly display the code is not correct, and might even be considered a safety issue. More so if it this rule is also applied to the dreaded {annotations}!

Christof Gessner (May 21 2020 at 11:25):

But I am leaving the topic of this thread, sorry.

Christof Gessner (May 21 2020 at 11:36):

My solution is to work on a vaue set level, using ValueSet.compose.include.concept.designation with appropriate values in concept.designation.use. I believe this is one case where "The system that defines the code or expression doesn't provide a display for this code", as described in 4.9.6. on https://www.hl7.org/fhir/valueset.html

Christof Gessner (May 21 2020 at 11:41):

Safety example: In UCUM '10*3' means 1000 - and not 30. You don't want to display this to human readers.

Grahame Grieve (May 21 2020 at 11:49):

no. though in FHIR, you're talking about Quantity where we wouldn't use the display anyway

Last updated: Apr 12 2022 at 19:14 UTC