Stream: terminology
Topic: RE UCUM Expansions
Eric Haas (Dec 06 2016 at 23:18):
A question arose in the Argonaut call regarding the UCUM expansion as implemented by the Core spec's terminology server which expands this value set. :
- Since UCUM is basically intensional and therfore infinite is this an algorithm that just spits out the first 1000 codes?
- How do the display names arise - is that algorithmic as well?
Grahame Grieve (Dec 06 2016 at 23:40):
carumba. I'll have to investigate. It's getting the common UCUM codes value set, but it shouldn't be.
Grahame Grieve (Dec 06 2016 at 23:40):
can you make a task?
Rob Hausam (Dec 06 2016 at 23:43):
So what's it supposed to be doing?
Grahame Grieve (Dec 06 2016 at 23:45):
refusing to expand UCUM because the expansion is infinite
Grahame Grieve (Dec 06 2016 at 23:45):
this is a problem in the spec itself.
Rob Hausam (Dec 06 2016 at 23:47):
OK - that makes sense
but I'm not sure if I follow how it's a problem with the spec?
Grahame Grieve (Dec 06 2016 at 23:48):
spec does the same thing
Rob Hausam (Dec 06 2016 at 23:48):
I see what you mean - sure
Eric Haas (Dec 06 2016 at 23:51):
[#12438]
Grahame Grieve (Dec 06 2016 at 23:51):
thx
Josh Mandel (Dec 07 2016 at 19:19):
It would be nice to link from http://hl7.org/fhir/us/core/ValueSet-us-core-ucum.html to the list of common values, though
Grahame Grieve (Dec 07 2016 at 19:22):
yes that's what should happen
nicola (RIO/SS) (Dec 08 2016 at 11:39):
May be UCUM is not terminology, but different service? How about specify unit service? :)
$convert $canonic etc
Grahame Grieve (Dec 08 2016 at 11:41):
there is a specific ucum service. I use it internally. We've not seen any interest until your note about this
Grahame Grieve (Dec 08 2016 at 11:41):
is anyone else interested in a FHIR rendition of the stnadard UCUM services?
Eric Haas (Dec 08 2016 at 18:38):
@Josh Mandel do you mean put a link in the description?
Robert McClure (Dec 09 2016 at 13:54):
@Grahame Grieve @nicola (RIO) @Josh Mandel While I would be cautious abiout saying that "UCUM" is not a terminology, because as we've currently defined things, it is, I've been thinking about this problem too. When a "terminology" essentialy is a grammar + tokens but the set of valid resulting concepts is difficult to draw a line around, what we really need is a service that can verify and create valid concepts. We already do this for value sets - define valid value set expansions via an "expression" and some do not store the resulting concept expansion set, they just test to find if the provided concept is in the proper expansion. Can we do the samer thing for an entire code system? Seems that we could. We've discussed this in very preliminary ways at NLM. Is this what you are suggesting?
Josh Mandel (Dec 09 2016 at 16:57):
@Eric Browne yes, a link in the description is what I meant.
Grahame Grieve (Dec 09 2016 at 18:47):
UCUM is a terminology, and we treat it accordingly. we already have a service that can validate ucum codes. I'm not sure what you mean by 'create valid concepts'. nor do I understand what you mean 'for an entire code system'; well, I guess I think I know what you mean, and we already do.
Grahame Grieve (Dec 09 2016 at 18:52):
what a UCUM specific service would look like is something that has the following services:
- validate that a unit has the same canonical unit as another unit
- get the canonical units for a unit
- given a unit and value, get the canonical unit and value
- given a value and a units, convert it to some other unit
- given two pairs of value/unit, multiple or divide them
Grahame Grieve (Dec 09 2016 at 18:52):
it's possible that the first 2 can be done by careful use of properties and valuesets and $lookup. but the latter 3, definitely not
Robert McClure (Dec 11 2016 at 01:01):
I think all are services and should not be value sets. If you wanted to be perverse, you could do latter 3 with mappings.. But please... As for my focus, aligns with yours (I understand why your transformations are a UCUM service) but mine is determining what the code system membership is, which is the operation needed when you want to validate and provide a list of available codes for use. UCUM doesn't work like other versioned code systems, it has a grammar for making valid codes and tolkens that are used in the grammar. The only list I know of valid codes is the lists of common ones, but there are many others. They just may not have the transformations you are focusing on in the service. I agree with what you are providing but it needs to also understand the grammar and the tolkens to return corrent validation responses.
In any case, I think all of this should be a set of services and no one should be expected to maintain a "static" list. Just identify valid service locations.
Grahame Grieve (Dec 11 2016 at 09:22):
I don't see how it's different to snomed ct - a list of defined tokens, and a composition grammar. We don't treat UCUM any differently from SNOMED in regards to it's behaviour except that we do publish an enumerated common units list
Michael Lawley (Dec 11 2016 at 23:33):
The main difference, as I see it, is that snomed comes with a whole pile of already constructed things and that it is usable as-is. Furthermore, there is a specific semantics one often needs from snomed which is subsumption testing; FHIR provides support for this (and it's also generally useful for other code systems).
From this perspective, one might consider including an enumeration of common units as part of the UCUM CodeSystem along with the defined tokens, but I don't see a real advantage of this over having a well-known ValueSet like http://hl7.org/fhir/us/core/ValueSet/us-core-ucum
Grahame Grieve (Dec 12 2016 at 06:06):
that value set is the enumeration of the common units
Michael Lawley (Dec 12 2016 at 06:42):
which is a useful subset of all possible units, somewhat like all the fully-defined SNOMED codes
Robert McClure (Dec 13 2016 at 18:19):
@Michael Lawley Has it right, there is a big difference in that SNOMED has a set of defined pre-coordinated concepts that have SCT identifiers, and it supports subsumption. UCUM, as a code system as provided by the authority, does neither, although it does provide tools to support validity checking. LOINC provides the "Common UCUM Units" set and while it has help from US organizations, I'm not sure that it's correct to call this a "US Core" set. Is there evidence tha the set available (https://loinc.org/usage/units) is US-specific?
In any case, that set can be considered as similar to the set of pre-coordinated SCT concepts published by IHTSDO. I've arguged that is what NLM VSAC should do. But I can see how it's easy to be confused by the similarity of SCT published content (one source) and UCUM + LOINC Core (two sources).
Grahame Grieve (Dec 13 2016 at 20:10):
so the confusion here is that US Ucum value set is badly described. But it should not even exist; the content of it is in the core specification. @Eric Haas @Brett Marquard is there any reason why the US UCUM value set exists?
Brett Marquard (Dec 13 2016 at 20:54):
great, let's get rid of the it...us-core version...
Brett Marquard (Dec 13 2016 at 20:56):
Rob Hausam (Dec 13 2016 at 20:56):
agree
Grahame Grieve (Dec 13 2016 at 20:57):
thx
Rob Hausam (Dec 13 2016 at 21:01):
the definition of ucum-units isn't exactly correct, as it states "... This value set includes all UCUM codes" - which isn't possible
Grahame Grieve (Dec 13 2016 at 21:02):
no, it's not wrong; the value set does include all the UCUM codes. Where it's wrong is that the tooling provides an expansion subset without indicating that the expansion is just a subset
Rob Hausam (Dec 13 2016 at 21:03):
ok - I agree with that
Rob Hausam (Dec 13 2016 at 21:18):
how would you prefer to indicate that the expansion is a subset?
Grahame Grieve (Dec 13 2016 at 21:20):
not sure. probably I will replace the expansion with something like 'UCUM can't be expanded. But you can see a list of common UCUM codes [[here]]'
Rob Hausam (Dec 13 2016 at 21:22):
that sounds good
Eric Haas (Dec 14 2016 at 16:41):
@GG because I looked for it but could not find it in the core. And I still can't. Where is it? (And I don't think its badly defined - but I don't intend to split hairs on that)
Grahame Grieve (Dec 14 2016 at 20:13):
build.fhir.org/valueset-ucum-common.html
Grahame Grieve (Dec 14 2016 at 20:13):
and it's badly defined because is says 'this is UCUM'. not 'this is some of UCUM'
Eric Haas (Dec 14 2016 at 21:22):
That was my intent. All of it not just the common units. Lab creates a of unique (proprietary) units that aren't in the common set. This is an overly long thread and I think that was my point in the first post.
Grahame Grieve (Dec 14 2016 at 21:23):
it's still not *all* of it. And you can't describe it that way
Grahame Grieve (Dec 14 2016 at 21:23):
how did you make it?
Eric Haas (Dec 14 2016 at 21:49):
Moving to Argonaut thread.
Eric Haas (Dec 14 2016 at 21:52):
https://chat.fhir.org/#narrow/stream/argonaut/topic/re.3A.20UCUM.20extension
Robert McClure (Dec 15 2016 at 18:56):
@Grahame Grieve I thought we had already crafted something to indicate when a particular expansion is not the full expansion as defined by the value set definition. Some sort of flag of some kind to indicate "this expansion is a subset". This came up before when folks wanted to use a subset based on post-exapnsion manipulation. Correct?
Grahame Grieve (Dec 15 2016 at 20:38):
ye. the problem is that I'm not using it here where I should be
Jay Lyle (Apr 17 2018 at 19:36):
UCUM specifies case-sensitive and case-insensitive variants: do we make any such distinction in the bindings?
Rob Hausam (Apr 17 2018 at 21:19):
So far we've said that UCUM in FHIR is case sensitive, in both the list of external terminologies and in the Using UCUM with FHIR page. If there truly is a need for using the case-insensitive codes, then I don't think we've addressed that anywhere. Just because it exists doesn't necessarily mean that we need to accommodate it in FHIR. But if there is a sufficient use case for it then we should look at it.
Grahame Grieve (Apr 17 2018 at 23:03):
y. we have ignored the existence of the case insensitive variant - it is not supported. For me, it would be a different code system URL if we did decide there was a use case
Last updated: Apr 12 2022 at 19:14 UTC
