Stream: terminology
Topic: Multiple Codes for Concepts
Grahame Grieve (Oct 24 2017 at 03:57):
I missed the phone call this morning - too many calls....
Grahame Grieve (Oct 24 2017 at 03:58):
was this discussed? where are we?
Joel Schneider (Oct 24 2017 at 04:57):
Seems like the next step is to evaluate the tradeoffs among the various unpleasant options.
Grahame Grieve (Oct 24 2017 at 06:04):
connectathon here we come...
Rob Hausam (Oct 24 2017 at 06:19):
We proposed to do 'alternate' in the extension space, rather than in core as at present (if we can get you to agree with that!). And add a topic specifically for it for the Connectathon terminology track, to try that out vs. the ConceptMap solution. The other alternative, of course, is to expand the cardinality on 'code' to 1..*, but I think the sense was not to do that (at least not yet). Anyone want to add anything else?
Grahame Grieve (Oct 24 2017 at 06:21):
I can agree to do it in extension space. With the same design as currently in the resource?
Rob Hausam (Oct 24 2017 at 06:25):
Yes, but with an additional 'alternate.display' element. Ted thought there were some uses in V3 that would need that. I'm not recalling any, but we can look.
Joel Schneider (Oct 24 2017 at 13:56):
I for one would be interested in gaining a better understanding of the implications of changing the concept.code cardinality to 1..*, and possibly documenting that.
Grahame Grieve (Oct 24 2017 at 21:23):
what would alternate.display do?
Rob Hausam (Oct 24 2017 at 22:51):
It would provide an alternate display term that is associated with that particular alternate code. I'm not thinking of any cases at the moment where we need that, but Ted thinks that there are some. It probably makes sense to provide it in case we do need it, particulary since it will be in extension space and we can work with it and determine what we actually do need.
Grahame Grieve (Oct 25 2017 at 01:58):
hmm. scary idea
Rob Hausam (Oct 25 2017 at 07:18):
As I said, I don't see where it would be needed (or desirable, as you say). If the display is different then that would (most likely) indicate a different meaning, which should be a separate concept. I'm fine with sticking with the current structure in the extension and then we can see how that plays out in the Connectathon and otherwise and if anything else surfaces.
Eric Haas (Oct 25 2017 at 15:43):
why introduce this if is a "just in case" let the implementers create an extension. Making more work for yourself for an outside edge case.
Rob Hausam (Oct 26 2017 at 06:06):
I'm not quite sure which part are you suggesting is "just in case", Eric? There is clearly a need (I think well within the 80%) to be able to handle code systems that do define multiple codes per concept - the question is how. Adding the 'alternate' complex element is certainly one way to do that, but we haven't reached a consensus as to whether it's the "best" way, so it makes sense to do it in extension space and test it in the Connectathon(s). Probably you are referring to the addition of 'alternate.display' as "just in case", and there I agree. I think leaving that off and only adding it if a clear need for it surfaces in the Connectathon(s) or otherwise makes the most sense.
Eric Haas (Oct 26 2017 at 16:28):
I was talking about the alternate.display bit
Michael Lawley (Nov 24 2017 at 03:45):
I'm still not entirely following this - we have code systems, not concept systems. SNOMED has multiple codes per concept purely because of post coordination. I'd like to understand why each of the codes for the same concept cannot exist independently. To represent these codes in a FHIR CodeSystem would probably require not much more than identifying a well-known property ("equivalentTo"?) that is symmetric and implies these semantics (for $subsumes / $closure support)
.
Grahame Grieve (Nov 24 2017 at 06:18):
a code system defines a set of concepts, and assigns codes to them
Jeremy Rogers (Dec 11 2017 at 14:57):
I'm also struggling a bit to determine what problem this discussion relates to. There are many real-world situations where a single idea in a clinician's head can only be represented using a single, indefeasible, structured expression comprising more than one code from the same code system, and this representation as a single expression is different from the concurrent capture (or messaging) of the same underlying codes but as discrete single coded items that happen to be all recorded on the same day. SNOMED CT postcoordinated expressions are an obvious example of such code expressions, but dagger-asterisk codings and other multi-code expressions under rather older compositional schemes may also be in scope, like e.g. ICD9/10, ICD-O or the UK' OPCS.
Take how 'Intentional paracetamol and dextropropoxyphene poisoning' should be coded under ICD-10, as a single expression formed of several codes :
T391|X609|T404|X629
or...
T39.1 4-Aminophenol derivatives |
X60.9 Intentional self-poisoning by and exposure to nonopioid analgesics, antipyretics and antirheumatics |
T40.4 Other synthetic narcotics (unspecified place) |
X62.9 Intentional self-poisoning by and exposure to narcotics and psychodysleptics [hallucinogens], not elsewhere classified (unspecified place)
Or was that not the issue here?
Grahame Grieve (Dec 11 2017 at 19:38):
no that wasn't the issue here. That's just a code from FHIR's point of view. The issue was that a few code systems deliberately define more than one code for the same expression, and documents them as synonyms.
Jay Lyle (Apr 02 2021 at 22:23):
In our legacy Coverage file, there are 4 different fields for subscriber relationship to patient (original, hipaa, ncpdp (2)). I think we can call these different representations of a single relationship, so we can populate the 0..1 CodeableConcept with 4 Codings with different systems. Right?
Lin Zhang (Apr 03 2021 at 02:26):
@Grahame Grieve UCUM is such a CodeSystem. UCUM codes for unit of measurements include case-sensitive and case-insensitive ones.
Colin E. (Jun 06 2021 at 22:02):
UCUM allows for annotations, which are semantically irrelevant but part of the code. On that basis I think you can argue that UCUM has an infinite number of codes (expressions) for any particular unit concept. That is in addition to the possibility of taking any existing unit concept expressed in UCUM, and multiplying and dividing it by the same value (either a constant or a unit expression). The result is a new valid UCUM expression for the same (equal mathematically) concept.
Robert McClure (Jun 06 2021 at 23:08):
@Colin E. I don't agree that changing the "annotation" results in another code for the same concept. I agree with your statement that such a change results in a mathmatically equivalent for UCUM expression, but this is a side-effect and the two annotation-based expressions for "the same unit" result in different concepts in UCUM. At least we treat them as different.
Grahame Grieve (Jun 07 2021 at 00:36):
I think that's semantics. these are definitely different codes:
mg/mL{water}
mg/mL{saline}
But they're totally equivalent concepts in the right context. So I agree with @Colin E.
Colin E. (Jun 07 2021 at 17:47):
Perhaps more exciting / worrying is that in UCUM (and I suspect most other systems based on understanding units, and maybe even those that can do dimensional analysis based on symbolic maths) mg/g == mL/L == ms/s == 10^-3
These are all versions of "one thousandth" (or 0.1%) at one level, but whether a (say) mass fraction can safely be considered the "same concept" as a volume fraction, or even a ratio between two elapsed times, is beyond my knowledge of maths and metrology to answer.
As to whether the annotated units I used as examples are treated as different concepts or not, people with a lot more experience that I in these areas have commented that best practice when receiving unit in UCUM in a FHIR message is to strip off the annotations before they are stored or processed, so that would indicate they would be treated as the same.
Grahame Grieve (Jun 07 2021 at 18:16):
whether a (say) mass fraction can safely be considered the "same concept" as a volume fraction, or even a ratio between two elapsed times, is beyond my knowledge
The answer is contextual. To mw knowledge, there is not ontology that even aims to provide a framework for answering that question
that best practice when receiving unit in UCUM in a FHIR message is to strip off the annotations before they are stored or processed
I disagree. I would never strip off annotations before storage, but I would not consider them for comparison purposes. What exactly 'processing' means... that depends then
Michael Lawley (Jun 08 2021 at 05:16):
What would you expect if both mg/mL{water} and mg/mL{saline} were passed to $closure?
What about the expansion of a ValueSet if both were included in the ValueSet definition?
Grahame Grieve (Jun 08 2021 at 06:28):
What would you expect if both mg/mL{water} and mg/mL{saline} were passed to $closure?
"Annotations do not contribute to the semantics of the unit but are meaningless by definition"
so that is a clear answer, then?
What about the expansion of a ValueSet if both were included in the ValueSet definition?
they'd be both be in it as defined
Michael Lawley (Jun 08 2021 at 06:37):
for $closure, would you expect to get an equivalence map back between the two codes? Or, would you expect them to be treated as a single concept, and thus no map.
Grahame Grieve (Jun 08 2021 at 07:30):
equivalence map. They are not the same codes, they are the same concept
Robert McClure (Jun 13 2021 at 23:12):
@Grahame Grieve You complain that the difference is semantics yet rely upon nuanced distinctions between code and concept to justify your point. By what FHIR rule are you sayig that two strings in the same code system, that you say have the same meaning, should be in a value set expansion? What use are they if they have the same meaning? How is that computable? The problem with all that is you are incorrect, they actually have different meanings in UCUM, they just can not be converted.
A code system concept is a bounded idea that has meaning persistance as represented by codes in the code system. UCUM honestly has some very confusing statements, and they are all focused on supporting unit conversion but confusion reigns when thinking about unique idea representation. UCUM, in the official code system, has many concepts with only annotaion respresentations: {binding_index}, {CAG_repeats}, {cells}, {activity}, {absorbance}, and I can go on. If we treat UCUM such that all those represent the same concept (apprently NULL??), then at a minimum all UCUM concepts that are only annotations can not be reliably used in FHIR systems. But that is foolish and in fact, Graham, you don't have this one correct.
Grahame Grieve (Jun 14 2021 at 02:46):
you are incorrect, they actually have different meanings in UCUM, they just can not be converted
I think you are referring to the text where I was quoting from UCUM
Grahame Grieve (Jun 14 2021 at 02:47):
at a minimum all UCUM concepts that are only annotations can not be reliably used in FHIR systems
I certainly agree with that statement. In general I agree that annotations can't be used reliably, but people certainly do use them
Robert McClure (Jun 14 2021 at 14:47):
@Grahame Grieve Here is the thing, as I have said, the guidance in UCUM docs is not as helpful as I would like to see regarding practical use. I suppose that is yet another task I need to add to my list - talk to LOINC about clarifying UCUM. My point is this, we - those of us interested in data communication - are not as interested in the use of UCUM to convert between different equivalent units as we are in using it to identify a specific, focused, unit of measure. That unit may be only of use in one place and have no coversions to anything. But accurate understanding of meaning and high fidelity of understanding is the goal. Therefore I suggest that we come to an agreement that for our use UCUM annotations provide unique information and that we consider the entire exchanged expression as a complete unique concept represented as a unique code. We can tackle unit conversion equivalenace as a separate issue that follows defined UCUM governance. I would like to point out that the perspective I am promoting is not in direct contradiction with the UCUM documents. In particular section 3.2 "ARBITRARY UNITS" states "Arbitrary or procedure defined units are units whose meaning entirely depends on the measurement procedure (assay)." therefore they have meaning, just not in relation to other units. It also states that they realized (starting with 1.6) that these units are indeed "commensurable." Unfortunately the text consistantly uses phrases like "...an arbitrary unit and is not comparable with any other arbitrary unit or term" when the comparison under question is one of unit mathematics comparison but not unit meaning.
I will work to clarify this interpretation with LOINC but if we do not follow this guidance and consider all UCUM expressions as unique ideas, different concepts represented by different codes, we must toss out all the arbitrary annotations. I understand this means we must consider unit mathematics (conversion) equivalency as a separate task, but I suggest that is reassonable and possible.
Thoughts? @Michael Lawley , @Colin E. , @Rob Hausam , @Ted Klein , @Carol Macumber
Robert McClure (Jun 14 2021 at 14:58):
I also understand that for my approach to be acceptable, we have to get UCUM to modify the statements in the Example section "Symbols commonly used as units that are no real units of measurements are not defined by The Unified Code for Units of Measure. ■2 Users are free to use curly braces expressions (§12) if they think it is important to use symbols rather than the default unit 1. ■3 Curly braces expressions are equivalent to the unit 1. The details of the annotations in the curly braces have no defined meaning in The Unified Code for Units of Measure." I'd rather it say that these curley brace expressions have no defined conversion meaining and are arbitrary in value but actually do have meaning for exchange and should be considered units, they just have a conversion meaning = 1.
Grahame Grieve (Jun 14 2021 at 16:51):
sounds like UCUM needs an additional way to differentiate between explanatory and definitional annotations. In the mean time, we could add a note to the UCUM page explaining the issue and noting that the use of annotations introduces uncertainty that has to be somewhere
Ted Klein (Jun 14 2021 at 19:12):
Sorry just seeing this now...there are two sets of things here IMHO - the specific multiple codes issue is something in several systems of codes where there are multiple concept representations and some of them are identifying representations ie they are associated only with one concept in the system and can be used as a primary key for that concept. Some code systems, such as SNOMED CT, explicitly label one of those as 'THE CODE
Ted Klein (Jun 14 2021 at 19:12):
'
Ted Klein (Jun 14 2021 at 19:12):
whereas the others are unique but should not be used as primary keys for a variety of reasons.
Ted Klein (Jun 14 2021 at 19:14):
Other systems, such as ISO 3166-1, have multiple sets of codes where no single set is considered primary or solely the unique identifier, but have various labels ie two character alpha, three character alpha, numeric; other systems have different approaches.
Ted Klein (Jun 14 2021 at 19:16):
We have two code systems in HL7 where there are more than one identifying representation for a particular concepts, and we have adopted in THO (UTG) the convention to use the property 'SYNONYM' to indicate that more than one code in the system are representations of a particular concept; this enables the machinery of specific display strings for the different codes without having to get all fancy with extensions.
Ted Klein (Jun 14 2021 at 19:18):
A system such as UCUM which is inherently a post coordination grammar based system has by definition more than one way to represent concepts, although it is my understanding that in UCUM the atom concepts have unique single identifying representations. Folks who persist precoordinated sets of complex grammar expressions for SNOMED CT, IANA media types, some AJCC terminologies, and some others, often find the multiple representation problem rearing its ugly head.
Ted Klein (Jun 14 2021 at 19:23):
There are several approaches to deal with this; none are simple pretty and elegant (of course). Fortunately, it is not widespread. Unfortunately, in the case of UCUM, it is extremely ubiquitous. We perhaps should consider some elegant specific solution for UCUM only, with guidance for those struggling with it for other systems. I have long been concerned with 3166-1 for related reasons. I am unconvinced that we need a complex general solution to the problem however, as the juice is likely not worth the squeeze.
Grahame Grieve (Jun 14 2021 at 19:56):
what's an equivalent problem in 3166?
Ted Klein (Jun 14 2021 at 20:27):
Some systems communicate the 2 character code, others the 3 character code, etc. Most now because of this can process either one, most systems I am familiar with treat it as a code systems with 1000 or so coded concepts and it just so happens that the same display name (which does not have to be unique in a code system) is used for triplets of codes, LOL. So they game it since there is not a general solution.
Michael Lawley (Jun 14 2021 at 22:33):
From a practical "data use" perspective that flows from the agenda of pushing terminology semantics out of a client/data processing system and into a terminology server, it would seem that codes need to be preserved syntactically (else the client system needs to know when and how to do something other than string matching when correlating terminology server responses with the actual codes stored in a record), but the terminology server handles the concept-ness. There, the semantics are those of subsumption which includes equivalence.
@Ted Klein I'm not sure what you're doing in THO, but I would hope that when there are multiple codes for the same concept, then their FHIR CodeSystem representation captures that as multiple codes that are equivalent (i.e., have each other as both parent and child properties).
Ted Klein (Jun 15 2021 at 12:40):
Four years ago at a WGM face-to-face there was a long discussion on this topic in a joint Vocab/FHIR quarter. At that time it was decided to use a new property "synonymCode" to have different codes that identify the same underlying concept in a single code system to essentially 'point' to each other. This was implemented for the two places in HL7 terminology where they occur two years ago when it was implemented in THO. This can be revisited in light of updated experience and opinions but this is what we are using today. I know off the top of my head without searching it is used in V3 ActCode; the property declaration is: <property>
<code value="synonymCode"/>
<uri value="http://hl7.org/fhir/concept-properties#synonym"/>
<description value="An additional concept code that was also attributed to a concept"/>
<type value="code"/>
</property>
Ted Klein (Jun 15 2021 at 12:42):
http://build.fhir.org/codesystem-concept-properties.html
Grahame Grieve (Jun 15 2021 at 13:56):
I certainly don't support that in tx.fhir.org right now. a todo for me, I guess
Rob Hausam (Jun 15 2021 at 17:14):
No, we don't. But there are ways to logically support the equivalent of this in the current infrastructure (as has been proposed - but still has not yet been implemented - for NDC).
Rob Hausam (Jun 15 2021 at 17:19):
Having first class support in the CodeSystem resource for multiple codes for a concept would obviously be a substantive change (at least if all of the codes are to be treated "equally"). We should decide if that is something that we believe needs to be supported.
Grahame Grieve (Jun 15 2021 at 21:08):
I don't think we want to make it first class. I just have to implement what we agreed. But I thought I had done it for NDC? what's not done?
Michael Lawley (Jun 15 2021 at 23:46):
okay, that's great! (I almost suggested a new property equivalent that would play the same role).
One thing though, the code is defined as synonym but above you're renaming it as synonymCode -- is there a good reason for doing that? (other than forcing terminology server implementers to be disciplined about the distinction between the CodeSystem-local property name and it's formal identity via the URI.
Michael Lawley (Jun 16 2021 at 00:05):
Having first class support in the CodeSystem resource for multiple codes for a concept would obviously be a substantive change
I don't follow this claim. SNOMED CT already has this (post coordination), as has UCUM. Indeed its support is also implied by the $subsumes operation being able to return equivalent. To a lesser extent, it is also the semantics you get with case-insensitive code systems.
Grahame Grieve (Jun 16 2021 at 00:06):
@Rob Hausam was talking about the CodeSystem resource itself, where concept.code is 0..1 not 0..*
Michael Lawley (Jun 16 2021 at 00:06):
ah, I missed that. thx for the clarification
Rob Hausam (Jun 16 2021 at 00:09):
Yes, that's it.
Rob Hausam (Jun 16 2021 at 00:42):
For the NDC 10 and 11 digit code issue, Vocab and HTA agreed that it is a single code system, with 2 codes for each concept. In order to represent that currently in FHIR (with concept.code 0..1), we have to treat each code as if it is a separate concept (in the CodeSystem resource and terminology service API), but then you can declare that the two concepts are in fact equivalent with a ConceptMap. It's a bit of a pain and slightly complicated, but I think it provides logically correct behavior and is a workable way forward with the current specification and infrastructure. I worked up a solution for this for NDC, which Vocab WG approved (see 2020-08-20 minutes item #7). I'm intending to post the example resources (including value set expansions) separately here again (shortly).
It looks like Grahame has partly implemented this on tx.fhir.org, as it appears on a $lookup to be responding to both the 10 digit (e.g., 0409-3718-01) and 11 digit (e.g., 00409371801) codes (at least on a quick spot check). But in order to create a means to define 10-digit-only and 11-digit-only value sets, which are a requirement, I think the additional code-type property (or equivalent) also needs to be there - and that doesn't appear to be the case (I don't see anything like that showing up in $lookup).
Rob Hausam (Jun 16 2021 at 00:51):
(deleted)
Rob Hausam (Jun 16 2021 at 00:52):
I'll post the value set and concept map examples in a bit.
Grahame Grieve (Jun 16 2021 at 00:54):
make a task for me to fix $lookup on ndc. I agree I missed that.
Rob Hausam (Jun 16 2021 at 03:30):
@Grahame Grieve Issue #119 created. I included the additional bits for 'code-type' and 'synonym' properties and 'code-type' filter and $translate support.
Rob Hausam (Jun 16 2021 at 03:31):
Here is the full set of the NDC 10 and 11 digit examples:
CodeSystem_NDC_1011digit.json
ConceptMap_NDC_translate_10to11digit_response.json
ConceptMap_NDC_translate_11to10digit_response.json
ConceptMap_NDC_10to11digit.json
ConceptMap_NDC_11to10digit.json
ValueSet_NDC_10digit_expansion.json
ValueSet_NDC_10digit.json
ValueSet_NDC_11digit_expansion.json
ValueSet_NDC_11digit.json
Grahame Grieve (Jun 16 2021 at 08:08):
At that time it was decided to use a new property "synonymCode" to have different codes that identify the same underlying concept in a single code system to essentially 'point' to each other.
Does this mean a supplement can define additional synonyms?
Michael Lawley (Jun 16 2021 at 10:25):
Why is the ConceptMap needed to declare equivalence (given the existence of "synonymCode")?
Grahame Grieve (Jun 16 2021 at 10:29):
I would think it declares equivalence between separate concepts, not synonymy which is something different
Rob Hausam (Jun 16 2021 at 10:47):
Strictly speaking, by specifying the 'synonym' (or 'synonymCode') property I think the ConceptMap may not be required. But at least an implicit concept map is required if you want to support translating between the "synonym codes" using $translate. So to show how that works with existing servers I made explicit ConceptMap examples.
Rob Hausam (Jun 16 2021 at 11:09):
As far as using 'synonymCode' goes, I don't think it is something that actually "exists" (i.e. has been defined and is available for use/reuse). I think 'synonym' does exist, because it is defined in the concept-properties code system. If you want to use 'synonymCode' now, as far as I can see you have declare it for each CodeSystem instance where you want to use it. Correct? If for some reason you wanted to, I think for use in your code system you could just as well declare the property code value associated with the uri 'http://hl7.org/fhir/concept-properties#synonym' to be 'xyz123' - 'synonymCode' isn't special. This seems a little weird, but I guess the spec allows it. If we want to actually define this property to be 'synonymCode', rather than 'synonym', then I think we would need to actually change that in the concept-properties code system. I do agree that 'synonymCode' is more explicit and probably less confusing (as it is not the same as a "synonym" description/designation). But at this point I don't know if we want to change that?
Grahame Grieve (Jun 16 2021 at 11:14):
well, the standard specifies the URI as the definition. A propety 'synonymCode' not anchored on the URI has no meaning, and my server will be ignoring it; I won't be paying any attention to the actual code, only the URI. But it's useful for us to be consistent in the code we use in the THO
Rob Hausam (Jun 16 2021 at 11:27):
Right. The particular value that is used in concept.property.code is scoped only for that CodeSystem instance (and is defined in property.code in association with the value of property.uri).
Michael Lawley (Jun 16 2021 at 11:37):
Should a server ignore all properties that are not also explicitly declared in the CodeSystem? Even including "well-known" ones like inactive, parent and child?
Grahame Grieve (Jun 16 2021 at 11:56):
well, that's a little uncertain. THO assumes that we're not, and I'm not, but the spec doesn't make it clear why we're doing that
Robert McClure (Jun 16 2021 at 15:52):
@Michael Lawley @Grahame Grieve I'd assume that parent/child (are there others?) must not be ignored because we allow those creating code system resources to include hierarchies simply through resource concept structure. So we explicitly do not require those two as defined properties. As for status, I'd say we also presume all servers support this because we already assume, if nothing else is stated, that any concept in the resource "is active" and we also have the core element of ValueSet.compose.inactive that presumes this information is available.
Grahame Grieve (Jun 16 2021 at 19:55):
well, you're talking about the concepts there, rather than by what means servers identify the actual properties in the syntax.
Grahame Grieve (Jun 19 2021 at 22:03):
back to NDC:
Grahame Grieve (Jun 21 2021 at 04:40):
is the a property / filter for product codes (code9?)
Grahame Grieve (Jun 21 2021 at 04:40):
what other filters would people want?
Rob Hausam (Jun 21 2021 at 05:36):
I suppose you certainly could define a 9-digit "normalized" NDC product code format. But I've only seen that distributed in the 8-digit with dash format. Until and unless we have examples where it's needed and requested to have the 9-digit format, I think I wouldn't include that.
Grahame Grieve (Jun 21 2021 at 05:44):
but how would you include/exclude those codes from a vlaue set (the 8 digits ones with a dash, which is what I meant by code9)
Rob Hausam (Jun 21 2021 at 06:10):
I agree that if we are going to include them as an additional code, then you would need a property and filter for them. In that case I think I would make the 'code-type' value either 8-digit or, maybe better, product. But we would also need to consider whether we should include hierarchy, so that all of the full "package" level codes are grouped under the corresponding "product" level code. It seems that where the "product" level codes are used is SPL (I'm not aware at the moment of anywhere else)?
Grahame Grieve (Jun 21 2021 at 06:17):
we'd have to invent codes for heirarchy, and that generally ends badly. So I prefer the property approach
Rob Hausam (Jun 21 2021 at 06:18):
Sure. I agree with using the property approach.
Grahame Grieve (Jun 21 2021 at 06:18):
code-type = product then
Colin E. (Jun 21 2021 at 16:30):
Robert McClure said:
Grahame Grieve Here is the thing, as I have said, the guidance in UCUM docs is not as helpful as I would like to see regarding practical use. I suppose that is yet another task I need to add to my list - talk to LOINC about clarifying UCUM. My point is this, we - those of us interested in data communication - are not as interested in the use of UCUM to convert between different equivalent units as we are in using it to identify a specific, focused, unit of measure. That unit may be only of use in one place and have no coversions to anything. But accurate understanding of meaning and high fidelity of understanding is the goal. Therefore I suggest that we come to an agreement that for our use UCUM annotations provide unique information and that we consider the entire exchanged expression as a complete unique concept represented as a unique code. We can tackle unit conversion equivalenace as a separate issue that follows defined UCUM governance. I would like to point out that the perspective I am promoting is not in direct contradiction with the UCUM documents. In particular section 3.2 "ARBITRARY UNITS" states "Arbitrary or procedure defined units are units whose meaning entirely depends on the measurement procedure (assay)." therefore they have meaning, just not in relation to other units. It also states that they realized (starting with 1.6) that these units are indeed "commensurable." Unfortunately the text consistantly uses phrases like "...an arbitrary unit and is not comparable with any other arbitrary unit or term" when the comparison under question is one of unit mathematics comparison but not unit meaning.
I will work to clarify this interpretation with LOINC but if we do not follow this guidance and consider all UCUM expressions as unique ideas, different concepts represented by different codes, we must toss out all the arbitrary annotations. I understand this means we must consider unit mathematics (conversion) equivalency as a separate task, but I suggest that is reassonable and possible.
Thoughts? Michael Lawley , Colin E. , Rob Hausam , Ted Klein , Carol Macumber
I've been off for a week's holiday and it looks as if this subject has had a fair bit of traffic and maybe moved on beyond the point where i can keep up, but i'll comment where I think can ;-)
AFAIK UCUM is designed to provide 2 main things- simple (verifiable) syntax, and semantics for "unit-aware" comparison and conversion of Quantities . Both of those are extremely useful, but they both have their limitations.
-
The syntax leans emphasises simplicity and lack of ambiguity for machine-compatibility. It's not designed to optimise human readability.
-
The semantics deals with mathematical equality as the key (almost the only) semantic relationship. Two expressions are equal if you can divide one by the other and get the result value of 1, or 1.0. That's it, UCUM doesn't deal with other relationship like synonyms. Even the two variants of Litre (capital "L" and lower case "l") are dealt with by just defining two separate concepts with the same value.
More tricky questions exist-ike for example: "uL/L" = "nL/mL", but are they true synonyms? I.e. can you exchange one for the other without loss of information, and if you can why do so many UCUM lists cointain both?
- The concepts are modelled in a "concept space" of base units and powers of those units.
I think it is asking too much of the inner workings and intent of UCUM to say, for example that there is an issue with "the comparison under question is one of unit mathematics comparison but not unit meaning". As far as UCUM is concerned the unit mathematics comparison IS the unit meaning. That's the power (you can convert 1m/s to 1000mm/s) but also the limitation ( 1g/g == 1L/L because the dimensionality of both is "1").
IMHO the issue of human readability is significant, but only sometimes. In the short term the answer for us is almost certainly a curated list of UCUM codes aligned to human-readable equivalents. This feels like "unfinished business" in UCUM because they have the "printSymbol" text already for each unit atom, what's missing are the syntactic rules for assembling those into expressions that remain readable. That seems like a solvable problem.
The harder problems are the ones that the over-use of annotations (again IMHO) hint at-
1) Countable items.
The unit of a countable thing is "1", by definition according to SI. The authors of UCUM seem to have stepped on the precipice of a slippery slope by starting to define "real" units for countable entities (e.g. Colony Forming Units- [CFU]) and then maybe realised they could be signing themselves up to defining every countable thing/concept in human experience as a separate concept and stopped.
Personally I would argue that the Si view is correct. If countable items are distinct that should be identified in the concept for the Term, not the unit. The unit might not necessarily be "1" (to distinguish countables from other dimensionless measurements) but all countables are the same.
2) Unit hierarchies
Colleagues working on prescribing tend to insist they need complex named countable units like "packs of 30 tablets of 30mg per tablet active ingredient". I think this is a general problem of hierarchical "Quantities of Quantities" that we don't have a good solution for at the moment, so we are shoehorning a hierarchical problem into a flat text field.
3) Dimensionless values
This is the issue that the unit-based model hits a "singularity" when units cancel out. So for example in UCUM, and presumably in any other units-based system, 1mg/g == 1mmol/mol (==1/1000) when in fact a mass concentration is not in general the same as a molar concentration of the same substances (it depends on the molecular masses of the components).
I think to deal with this you would need a solution that handles Quantity dealing with the dimensionality in both the Unit space, and in terms of a more generalised mathematical representation, so that (for example) molar concentrations and mass concentrations are kept distinct.
I don't know of any off the shelf / FOSS solution that works at that level.
Lloyd McKenzie (Jun 24 2021 at 18:00):
Grahame Grieve said:
Does this mean a supplement can define additional synonyms?
A supplement can assert additional relationships, but can't change the meaning of existing concepts or introduce new codes. So, for example, if someone had published a code system where multiple codes meant the same thing but hadn't declared that, a supplement could make the declaration. (Similarly, a supplement could in principle assert subsumption relationships that were implicit in concept definitions but not made explicit.) At least that's my opinion/understanding of what supplements can/should be able to do.
Grahame Grieve (Jun 24 2021 at 18:22):
it can introduce new properties. So it can define synonyms.
Lloyd McKenzie (Jun 24 2021 at 20:34):
It can't introduce new codes. The synonym code would need to already exist.
Lloyd McKenzie (Jun 24 2021 at 20:35):
It must always be possible to tell if a code is valid within a code system without access to any supplements.
Grahame Grieve (Jun 24 2021 at 20:41):
It can't introduce new codes. The synonym code would need to already exist.
I think this is wishful thinking. I'd like that this is the case, for sure, but I don't think we actually say that or have that written down anywhere
Lloyd McKenzie (Jun 24 2021 at 20:44):
It was a fundamental premise on which we allowed code system supplements to exist at all. Supplements cannot define new codes. End stop. If you want to define new codes, you must use a new code system. Supplements let you define new properties and relationships. That's all they can do.
Lloyd McKenzie (Jun 24 2021 at 20:44):
Allowing supplements to define codes would be a disaster...
Rob Hausam (Jun 24 2021 at 20:45):
I believe that Lloyd is correct - and that we have made that explicit.
Grahame Grieve (Jun 24 2021 at 20:49):
did we? because what we actually said is:
A codesystem supplement cannot define any new CodeSystem.concept.code. i.e.: all CodeSystem.concept.code in the supplement must be a code from the "supplemented" code system
Grahame Grieve (Jun 24 2021 at 20:49):
when we define synonyms using properties, then we're in an undocumented area
Grahame Grieve (Jun 24 2021 at 20:51):
if you think I've missed something actually documented, I'm all ears
Rob Hausam (Jun 24 2021 at 21:48):
I don't think we have additional documentation (at least not anything that is "official"), but the issue is more about how we consistently interpret the documentation that we do have - as you have just shown. I don't think that what we actually do or are proposing to do is "define synonyms using properties". Instead what we are doing is "declare that codes are synonyms using properties". You can't use a code as the value of the 'synonym' property (for example) that doesn't already exist in the code system. If the content of that code system is defined in a CodeSystem resource instance (which is not required and may often not be the case), then that "synonym" code must be one of the CodeSystem.concept.code instances declared for that code system (not declared somehow in a supplement). I think the next sentence in the documentation further supports this interpretation:
If a supplement needs to define new concepts/codes to use as property values, it can be paired with a new (possibly contained) Code System and use the Coding type for the property values.
I actually think that what is documented here should be pretty clear (but I'll acknowlege that this could in some degree be specific to my own interpretation). So if someone has a clearly different interpretation of this same documentation, I am interested in hearing how you think it works.
I will throw one more thing out here. I think what really is still left essentially undocumented about the use of code system properties is how to define new properties (not property values) that are not already defined in the code system itself or in an existing "standard" place like the ConceptProperties code system. To add one (or maybe two or three) new codes for properties that the code system itself doesn't explicitly define, do you have to create another new code system (again, it seems that it can't be a supplement) in order to define them? This is what I have struggled with a bit.
Lloyd McKenzie (Jun 24 2021 at 23:31):
I'm pretty sure the intention is that supplements can define additional properties and relationships. The ones we used as examples (e.g. pCLOCD) absolutely define net new properties. One thing I don't think we've talked about is how to manage multiple supplements that define colliding properties. (I think the default answer has been "don't define value sets that rely on supplements that conflict".)
Rob Hausam (Jun 24 2021 at 23:42):
Yes, I agree with you on that. The slightly weird thing is that we don't mention that in the Code System Supplements section. But we do say it in the CodeSystem.supplements definition: The canonical URL of the code system that this code system supplement is adding designations and properties to.
Robert McClure (Jun 25 2021 at 14:53):
@Grahame Grieve Your use of "synonym" here (if I understand you) to mean "synonym code" is an edge case when considering typical code systems and I question if it is at all valid. Synonym everywere else (show me other examples?) has always been used to provide additional descriptions that may have nuanced differences in meaning (hopefully not, but it's human discourse) that are intended to be scoped as "the same for use" as the preferred description. The synonym idea is not intended to support "synonym codes." So let's consider SCT and the equivalent expressions issue. Those are not considered "synonyms," they are considered equivalent concept expressions and I believe would be considered equivalent codes. @Michael Lawley? I admit I don't understand the prior discussion on "codes are synonyms" or what the point of all that was. I hope you all are not confusing what a code is - codes are identifiers for concepts, nothing else.
Here is the thing, it seems that we painted ourselves into a corner that I'm not sure was useful by restricting concepts to only one code. Granted, that is a big change and honestly I think it would mean changing the datatype for codesystem.concept.code from code to identifier. Yes big change for edge cases, but we seem to have quite a few. Just putting it out there. Maybe we can try using some sort of extension?
Rob Hausam (Jun 25 2021 at 15:17):
I think that the approach that we worked out for "synonym codes" with the NDC 10 and 11 digit codes can work in general. It's taken a long time to get it implemented, because it required changes to the terminology server code (rather than a CodeSystem resource), but Grahame now has it implemented on tx.fhir.org. Here's an example: http://tx.fhir.org/r4/CodeSystem/$lookup?system=http://hl7.org/fhir/sid/ndc&code=00409371801. I completely agree that talking about multiple codes for a concept as "synonyms" can be extremely confusing and misleading. I think it would be best to change the synonym code in the concept-properties code system to something else (maybe at least to synonym-code?) to help lessen the confusion with the primary use of "synonym" to refer to alternate descriptions/designations, but that's what we have now.
Grahame Grieve (Jun 25 2021 at 20:59):
Ok so I did misunderstand one thing, which is that the intent is that the code has to be defined in it's own right, and all the synonym property is doing is claiming that it's a the same concept
Rob Hausam (Jun 25 2021 at 21:11):
Yes, that's right. But the $lookup for either the 10 or 11 digit codes is already working (at least it did for the ones that I checked), so I assumed that you had done the part about defining the code in its own right. What I haven't actually tried to do yet is define an NDC 10-digit or 11-digit only value set using the code-type property and see what the $expand results are for that.
Grahame Grieve (Jun 25 2021 at 21:13):
it was in general I missed that.
Michael Lawley (Jun 26 2021 at 07:00):
I have been trying to follow this conversation and struggling with the implications of what I think is being said. This partly turns on the constraint of one code per concept (or not) and the apparent/consequential distinction between equivalent concepts, and equivalent codes.
Michael Lawley (Jun 26 2021 at 07:00):
It now appears that with the statement "the code has to be defined in it's own right, and all the synonym property is doing is claiming that it's a the same concept", that really what's being said is that two concepts have to be defined and that the synonym poperty is stating equivalence of the concepts?
Rob Hausam (Jun 26 2021 at 12:13):
Yes. That's what I think. But I've also thought that (at least at present) we shouldn't rely on that alone for declaring the equivalence. There should also be a ConceptMap instance (explicit or implicit) that declares that and of course can be used to support $translate between the different "synonym codes".
Grahame Grieve (Jun 26 2021 at 13:28):
I think that a synonym code goes beyond saying the two concepts are equivalent. claiming two codes are synonyms means that they are equal in every way except the literal code. So other than the synonym property, all their properties are the same
Rob Hausam (Jun 26 2021 at 13:36):
Yes, I agree. But, as you know, we had the discussion before about the difficulty of making a reliable and reproducible distinction between 'equal' and 'equivalent', which led to removing 'equal' from the ConceptMap relationships in R5. Depending on how you would interpret 'equal', two concepts that were identical in everything except for having different codes wouldn't necessarily be considered 'equal'. So I stick with using 'equivalent'.
Lloyd McKenzie (Jun 26 2021 at 21:11):
Agree. Any property, relationship or designation that holds for any synonym should hold for all.
Grahame Grieve (Jun 26 2021 at 21:19):
except the synonym property ;-)
Robert McClure (Jun 28 2021 at 23:37):
I really am uncomfortable with this approach. You are making something that will be very simple to screw up. I suspect this is all some sort of hack to make a complex thing work within existing TS functionality. We should not be making mulltiple concept objects for something we KNOW is one thing, just so we can have multiple codes for it. Fix the damn requirement for one and only one code for a concept. And I think concet.code should use the datatype Identifier. Restrict out the things we don't need and make it 1..*
Rob Hausam (Jun 29 2021 at 02:31):
@Robert McClure I assume your comment is mostly directed at my comment on the approach that we worked out for "synonym codes". It's certainly OK to change your mind, but apparently you were comfortable with this approach when we reviewed and voted on it for NDC-11 on 8/20 (item #7) - you made the motion to approve it. The approach hasn't changed. Maybe it would be good and probably better to have true "first class" support for multiple codes per concept designed into the specification - but this approach can accomplish a very similar result. If there is a specific reason for changing your position I'm definitely interested in hearing what it is.
Lloyd McKenzie (Jun 29 2021 at 04:29):
Simple fact is we're past the point where we can change this. CodeSystem is normative. Changing Concept.code to repeat would be a breaking change. And it would break a lot of existing systems. The notion of synonym codes has long been agreed to be handled this way. It's relatively uncommon and the work-around defined functions just fine. Yes, it's a bit complex, but the systems that deal with it must deal with far greater complexities.
Rob Hausam (Jun 29 2021 at 04:30):
Yes, agree.
Robert McClure (Jun 30 2021 at 15:07):
Yes I've changed my mind. Yes, it's a breaking change. Yes, I think this approach is worth the break. Yes, I will accept that I'm likely in the minority and the hacked approach to deal with code systems with multiple codes can work BUT we need to bake into FHIR servers the understanding and tooling to use the hack we created.
Lloyd McKenzie (Jun 30 2021 at 15:10):
I don't know that it needs to be baked into all servers. It SHOULD be baked into terminology servers. There are lots of servers that won't recognize equivalence of pre-coordinated and post-coordinated expressions or equivalence of codes from different code systems. Synonym codes from the same system aren't really any different. It's not good when systems don't recognize those codes are equivalent, but systems function and life goes on when they don't.
Grahame Grieve (Jun 30 2021 at 19:26):
I assume Rob meant terminology servers
Grahame Grieve (Jun 30 2021 at 19:26):
I certainly agree that a good set of test cases is important
Peter Jordan (Jun 30 2021 at 23:13):
Two different identifiers are not equivalent. Whether the concepts that they identify are equivalent is a separate concern. As an R4 Terminology Server provider, I am not at liberty to change the cardinality of CodeSystem.concept.code, certainly not without hacking the C# reference library and risking breaking clients. The obvious answer to me is to use the codesystem-alternate extension to identity instances where there are multiple identifiers for the same concept within a single Code System - but maybe I'm missing something?
Lin Zhang (Aug 24 2021 at 09:22):
@Robert McClure Those UCUM codes with annotations only actually have a special/implicit unit "unity"(means "one").
Colin E. (Feb 21 2022 at 13:41):
Lin Zhang said:
Robert McClure Those UCUM codes with annotations only actually have a special/implicit unit "unity"(means "one").
It is more acurate to say that the an annotation in a UCUM code (text within {} braces) has the measning of Unity (==1). Annotations can be involved in complex expressions, the presence of an annotation doesn't reduce the whole expression to a value of "1".
So, 30mg{wet weight}/L is equal to 30mg/L The annotation resolves to 1, and disappears as it has no effect on the result, but the expression as a whole has a non-Unity value.
Colin E. (Feb 21 2022 at 13:57):
BTW- a (very late) comment on the above regarding synonyms and UCUM.
UCUM is solely concerned with matters of mathematical equality, not "synonymity" (if that's a word). UCUM has no concept of a synonym, as an example the UCUM atoms L and l (both meaning "Litre") are defined in the UCUM definition file as two separate items that happen to have the same value, they can't be designated as true synonyms.
In many cases this might not seem to matter. If 0.1 mmol/L is equal to 100 umol/L, many people might be happy to say they are synonymous.
However, if I say to users (Lab scientists and clinicians) that 10 umol/mL and 10 mmol/L are true synonyms, i.e. anything, including software is free to change one form to the other with NO loss or change of information, a significant proportion will tell me I'm wrong, because (a) one of the terms isn't exactly what the analyser or test kit produced, so it is verboten; and (b ) the denominator carries some hint of a "sane" sample size, and clinicians don't think of most lab samples in terms of litres.
A more extreme example- In UCUM 10mg/g == 10mL/L == 1%. I don't think most of us would accept those as being synonyms, converting between them involves loss of information.
So "equal to" means "dividing one by the other gives a reult of 1". That's not always a synonym. Not sure if theres' a separate word for it, "equinym" maybe?
Last updated: Apr 12 2022 at 19:14 UTC
