Stream: terminology
Topic: How to properly represent Synonyms
Joshua Bell (Jan 04 2018 at 15:50):
Starting a topic here as recommended from the implementers stream: https://chat.fhir.org/#narrow/stream/implementers/subject/ValueSet.20expansion.20including.20synonyms/near/116986
What I'd like to know is how to represent Display synonyms in a value set and have those be included in the expanded set. So for example, if I had a code system with male and female, I want to be able to make a value set that contains sys|Male, sys|Female, sys|Male|MaleDisplaySynonym. Then when it is expanded it would contain three concepts, two of which are the same, but they have different displays. This way we can have dropdowns that are easier for end users to find things rather than having to know exactly the display and wording of our system (which was one of the points @Michael Lawley brought up before I bumped the linked thread). [cc @Grahame Grieve ]
Grahame Grieve (Jan 04 2018 at 20:47):
well, this:
<ValueSet xmlns="http://hl7.org/fhir">
<url value="something"/>
<name value="ForJoshua"/>
<compose>
<include>
<system value="http://hl7.org/fhir/administrative-gender"/>
<concept>
<code value="male"/>
<display value="Male"/>
</concept>
<concept>
<code value="female"/>
<display value="Female"/>
</concept>
<concept>
<code value="male"/>
<display value="A *real* man"/>
</concept>
</include>
</compose>
</ValueSet>
Grahame Grieve (Jan 04 2018 at 20:48):
in this way, the value set just takes control completely
Joshua Bell (Jan 04 2018 at 22:20):
I've tried simply including a duplicate like that but the implementation I am using (hapi) does not include duplicate concepts in the expansion. Is this an implementation detail that is supposed to work in fhir, and is just incorrect in hapi? You can see this happen using this curl: curl -X GET \
'https://fhirtest.uhn.ca/baseDstu3/ValueSet/653997/$expand?includeDesignations=true'
I also tried your resource above: https://gist.github.com/RingOfStorms/521b676a713abd0bed845ec05f9f8797
Robert McClure (Jan 05 2018 at 20:41):
The expectation for a value set definition is that each concept representation (code) would only be included once. @Grahame Grieve , what you suggest should not be allowed. How to support more thatn one display for a single concept should be something we can support on the expansion side through the allowance of multiple displays for a single code. Not sure how we would do that, but perhaps through Expansion Profile?
Grahame Grieve (Jan 06 2018 at 04:18):
why is that something that should not be allowed? It's certainly not something we've talked about before
Joel Schneider (Jan 06 2018 at 19:52):
Screen-Shot-2018-01-06-at-1.51.44-PM.png
Grahame Grieve (Jan 06 2018 at 20:31):
y. but how is that relevant?
Joel Schneider (Jan 08 2018 at 03:41):
The example given earlier shows a code system with two concepts having the same code (but different display).
Grahame Grieve (Jan 08 2018 at 03:47):
it's the same concept with different displays.
Joel Schneider (Jan 08 2018 at 03:50):
Hmm, concept.display cardinality is 0..1. How can the same concept have different displays?
Grahame Grieve (Jan 08 2018 at 03:54):
designations. or assigned by value set as shown above
Joel Schneider (Jan 08 2018 at 04:23):
Ok, I see the comment under ValueSet.compose.include.concept.display about the value set's ability to specify an alternative display for a concept.
So the point under discussion is whether the value set should be able to include the same concept more than once, with alternative display values? But only for use in the UI, or CodeableConcept.text?
Grahame Grieve (Jan 08 2018 at 04:25):
yes at the UI level, and then reflected into CodeableConcept.text (but not Coding.display)
Rob Hausam (Jan 08 2018 at 15:51):
I don't think that there's anything wrong with what Grahame is suggesting. I don't think we really need to create rules to enforce doing this in ExpansionProfile, for example, and not in ValueSet.compose - and if we did the lines would be rather arbitrary. But the ValueSet.compose approach won't help (as far as I can see) when the value set definition is intensional. I think that will be a common usage, and likely a facility for including multiple display terms for the same code in expansions is going to be needed in ExpansionProfile.
Grahame Grieve (Jan 08 2018 at 19:56):
feels hard to get right in the intensional use case. there's so many options and axes to pin down
Joshua Bell (Jan 08 2018 at 22:33):
So what exactly is the use of the Synonym use in a designation? Is that saying that the concept itself as a whole is a synonym of another concept?
From the looks of it to me it seems as though pretty much all of the current implementations took the 'uniquely defines the concept within the code system' as only including it once in the expansion. I figure since this is the case, it would be a good idea to clarify this as the default behavior of the expansion operation (making it backward compatible with the ones that currently implement it this way). And then add in an expansion operation that would result in an expansion containing duplicate concept references defined in the valueset with different displays. Possibly displaySynonyms or something along those lines.
Michael Lawley (Jan 09 2018 at 03:41):
Our approach is that there is one display per code, and that everything else is some kind of synonym. Including a code in an expansion more than once is going to create confusion. In a data entry UI context, providing multiple different display text options for the same code gives the incorrect impression that choosing one over the other conveys some meaning. It might to a person, but it won't to the machines/algorithms that only look at the codes.
Just because you can, or someone else does, something, doesn't mean you should.
Peter Jordan (Jan 09 2018 at 04:03):
That begs the question - why does a Code System have synonyms? Maybe to allow an end user to find a concept using the term that's most familiar to them? The fact that this makes no difference to machine processing isn't relevant to that use case. I see the value in presenting preferred terms in context-sensitive dropdowns, but not for pure text searching; however, it might be interesting to show the results of our differing approaches to the later using Ontoserver's excellent ValueSet comparison tool to clinical users ('heart attack' is a good example).
Grahame Grieve (Jan 09 2018 at 04:05):
it's not true that including a code more than one will produce confusion. It's certainly true that you can create confusion - that's always possible. But you might do it because the users erroneously believe that 2 descriptions are different, but they aren't. or because your expansion is categorised into multiple different groups, to help users navigate, and one concept belongs in more than one place. Or because there are 2 different subgroups used to different terminology that is not ontologically significant (why there are synonyms in the first place). In practice, this is no different to having an interface terminology where 2 terms map to the one concept in a reference terminology.
Rob Hausam (Jan 09 2018 at 07:29):
Yes. I think there are use cases that will benefit from this and we need to be able to allow for it. Hopefully we can do things to minimize confusion, but we can't entirely eliminate the possibility of it.
Joshua Bell (Jan 09 2018 at 07:40):
@Michael Lawley Not having the synonyms has created confusion among our users. They see a document with medication A (which also has the made-up name Semoflouride in this example) but our list only has Semoflouride and they don't know off the top of their head that A is the same exact thing as Semoflouride. Now we are missing data and having users ask us to add medication A to our dropdowns because they couldn't find it.
This isn't a case of me doing something someone else is doing or just because I can or want to, my problem is stemming from a real business setting that has been stumbled upon on and I need to come up with a solution for it.
Now I think confusion can exist especially because there seem to be two different synonyms that can happen. There are two separate Concepts that could be synonyms or a concept that has multiple displays representing it (which we also identify as a synonym). In my use case, I am asked to do the latter and use one concept for something like a medication and just show different displays for that. That way when a user selects either A or Semoflouride it will be stored as the same expected concept for analytics later. And down later in the pipeline, it will show our preferred name of Semoflouride even if they selected A when displaying details about that field.
Maybe next steps would be to distinguish between a display synonym vs two concepts being synonyms (I'm not sure if this is a common thing within a single CodeSystem, there is already mapping for between different CodeSystems so maybe I made that scenario up completely. If that is the case then just need to clarify how display synonyms should be handled). And additionally, it would be useful to be able to flag one as the preferred name/or clarify that order matters and the first one is considered the preferred term, depending on how it is structured.
Grahame Grieve (Jan 09 2018 at 21:47):
there's confusion about the terminology here (yay!). Synonym may apply at the level of
- the concept (2 concepts that have the same meaning)
- the code (2 different character strings that refer to the same concept)
- the display (2 different displays for the same concept)
It depends on the definitional infrastructure for the code system as to which you can actually have (e.g. native FHIR code system can only have 1st and 3rd at present, where as MIF can have all 3)
Peter Jordan (Jan 10 2018 at 01:32):
My interpretation...
concept level = equivalence
code level = duplicate identifiers
description level = synonymous terms
Jay Lyle (Jan 11 2018 at 14:53):
Joshua's use case demonstrates a real requirement, but I'm not sure changing the value set membership is the way to support it. It's a "value set," not a "value bag," so I don't expect to see the same value twice.
If we support listing both "medication A" and "Semoflouride" for data capture, do we replicate the problem when someone else pulls up the record? Which label do they see?
One solution: support synonyms in the search/type-ahead UI functionality, but record the preferred term. E.g., user types "Medication A," systems offers "Semoflouride (aka Medication A)" among other options, user selects the option, system records the preferred term. I'd be more comfortable with expanding the functionality of "value set" (e.g., by adding search terms, synonyms, other kinds of display text) than with changing the underlying set assumption.
Rob Hausam (Jan 11 2018 at 15:56):
I doubt that when the phrase "value set" was decided on that anyone was actually thinking very much about the mathematical notion of a "set" (vs. a "bag"). So I don't know that we should press that too hard, because we have at least two situations that I can think of at the moment where the strict set interpretation doesn't hold - one is the case we have here with multiple descriptions for the same code, and the other is the case where we include representation of hierarchy in the value set expansions (i.e. nested 'contains') - as with the addition of hierarchy a single code can potentially show up multiple times (in different paths with a different parent). I think that if we try to take an approach with the ValueSet resource and its representation of value set expansions that doesn't allow for these situations then we'll end up needing yet another artifact to handle them - and I expect that would be an even less desirable outcome.
Grahame Grieve (Jan 11 2018 at 20:23):
specifically to Jay's question: that's why we have both text and display - text is what the user saw. For this kind of case
Grahame Grieve (Jan 11 2018 at 20:25):
agree that the bag vs set distinction is not something to be rigorous on. But also: expansions that contain the same code twice are generally for UI purposes, not other kinds of purposes (though the code generation case is a deferred purpose, so that's never clear)
Rob Hausam (Jan 11 2018 at 20:50):
Agree.
Grahame Grieve (Jan 12 2018 at 11:14):
I just fixed my server - I'll update test.fhir.org to behave properly in this regard soon. Here's the expansion I'm generating from the value set I posted above now:
Grahame Grieve (Jan 12 2018 at 11:14):
<?xml version="1.0" encoding="UTF-8"?> <ValueSet xmlns="http://hl7.org/fhir"> <meta> <versionId value="1"/> <lastUpdated value="2018-01-12T11:01:41Z"/> </meta> <url value="something"/> <name value="ForJoshua"/> <status value="draft"/> <expansion> <identifier value="urn:uuid:0b0ed260-4d38-4f57-a0a9-382a9daec538"/> <timestamp value="2018-01-12T11:13:22Z"/> <parameter> <name value="expansion-source"/> <valueString value="ValueSet/31"/> </parameter> <parameter> <name value="version"/> <valueUri value="http://hl7.org/fhir/administrative-gender?version=3.0.1"/> </parameter> <contains> <extension url="http://hl7.org/fhir/StructureDefinition/valueset-definition"> <valueString value="Male"/> </extension> <system value="http://hl7.org/fhir/administrative-gender"/> <code value="male"/> <display value="Male"/> </contains> <contains> <extension url="http://hl7.org/fhir/StructureDefinition/valueset-definition"> <valueString value="Female"/> </extension> <system value="http://hl7.org/fhir/administrative-gender"/> <code value="female"/> <display value="Female"/> </contains> <contains> <extension url="http://hl7.org/fhir/StructureDefinition/valueset-definition"> <valueString value="Male"/> </extension> <system value="http://hl7.org/fhir/administrative-gender"/> <code value="male"/> <display value="A *real* man"/> </contains> </expansion> </ValueSet>
Jay Lyle (Jan 12 2018 at 15:46):
Right: I didn't mean to imply an unbreakable rule; just that there's a decision to be made between increasing "rows" vs "columns" and we should not choose one without considering the other.
ValueSet already supports multiple columns (designations), so I'd expect the UI to be able to support the use case without having to add redundant values to the value set.
(When I say "redundant," I lean on a concept-oriented perspective, where the set cares about the semantics, not the lex.)
Regarding hierarchies, that's another requirement that could be supported with metadata rather than a re-definition of a set. I won't say it shouldn't be allowed, but let's consider how to support the interoperability specification requirement without building functional UI features into the foundational structure.
Robert McClure (Jan 15 2018 at 16:18):
We need to be cautious of always trying to jam all the terminology service functionality based on code system information into a value set. Just because you have a hammer, everything is not a nail. @Peter Jordan was absolutely correct in his distinctions:
concept level = equivalence
code level = duplicate identifiers
description level = synonymous terms
I strongly urge FHIR to only use the phrase "synonym" to mean multiple concept descriptions associated with a single code system concept. Yes, we humans smudge that around a bit when we talk to each other, but in this context, for FHIR encodings, we can and MUST be more rigid.
Also, the VSD clarifies that a value set definition is expected to identify member concept only once. To my mind that means that each member concept shows up once in the expansion. BUT, we also support including additional information, drawn from the code system or code system supplements, as part of the expansion. I think this would include an expansion that had a single concept (one concept identifier) included with multiple synonymous descriptions. (Let's set aside duplicate concept identifiers for a different discussion.) How this is displayed by an application is not, IMHO, an expansion profile issue, but the expansion would have that member ONCE with multiple synonymous descriptions. As for including a hierarchy that could result in a display that shows the concept in more than one place - again, that display is up to the implementation, but the expansion would include relationship information. the expansion should not, in my opinion, be a tab-indented pdf-y interpretation of the code system information necessary to construct the display.
Rob Hausam (Jan 16 2018 at 18:16):
I agree entirely with Rob M. about reserving the term "synonym" for multiple concept descriptions that are associated with a single code system concept. That fits with both the normal usage in the terminology community as well as the normal English understanding of the word, whereas I believe the other cases do not. I know I've said something about this before, but probably not frequently or strongly enough.
For the other point, given the current structure of ValueSet.expansion, I'm pretty sure that there isn't any way to do it in the base resource so that "the expansion would have that member ONCE with multiple synonymous descriptions" or so that "the expansion would include relationship information". And I don't think that our current extensions help with that, either. If we think we need to do it in extension space, likely we can figure out how to do that. But maybe we don't need to do it. We could allow (which we don't prohibit now) the multiple instances of a concept/code in the expansion for situations like these, where it might make sense.
Grahame Grieve (Jan 19 2018 at 10:36):
if we're going to reserve synonym for display/designation - something I could live with - then we need to document that clearly, and we need to be clear about the words for the others, and document them clearly.
Grahame Grieve (Jan 19 2018 at 10:37):
I'm very much opposed to making a rule that concepts must be unique in an expansion all the time. It overloads a simple structure with all sorts of additional things, and why? If there's cases where that's a problem - what are they? - then we can create a profile for that
Robert McClure (Jan 19 2018 at 16:56):
Let's make sure what we are counting as "unique." Can we agree that the VS CLD should generate a list of unique members? I'd say that is always step 1 of the expansion process. Then a profile can be applied, or perhaps additional expand operation parameters that do not directly effect the unique member list, and this second step in creating the final expansion adds additional information to the members. If that results in a single member having multiple descriptions, fine. If you choose to output that as multiple instances of the orginal CLD-generated member, each with different attributes, in the file I'm also fine with that. Can we agree on that?
Grahame Grieve (Jan 20 2018 at 05:13):
I'm not sure what all that means.
Grahame Grieve (Jan 20 2018 at 05:15):
I think I agree, though. Because I think you're making some theoretical argument about what some inner aspect of an expansion means, but I'm just focusing on the end-state
Robert McClure (Jan 21 2018 at 16:55):
You should not focus on the end state only as the ends rarely justify the means. This is not some unimportant "theoretical argument" (Graham - why so much demeaning rhetoric, you looking for a green card or something?) The CLD is defining the unique list of members of the value set expansion. The inclusion of other information during the expansion process that results in multiple unique instances of FHIR xml objects when the combination of all attributes of those instances is considered is acceptable and useful. But users of those instances need realize that they are simply being given multiple instances of the same concept, not multiple concepts.
Grahame Grieve (Jan 21 2018 at 20:49):
ok sorry. I'm not here to justify any means. and I agree that repeating the same concept with different descriptions does not change the membership of the value set.
Rob Hausam (Jan 22 2018 at 12:50):
Unless I'm missing something, it seems to me that we're at least close to agreement here. I'm not hearing in this discussion anything that clearly needs to be changed in the FHIR specification regarding the definition of value sets and the generation of value set expansions - other than better documentation for some aspects. Also, although it may be useful for thinking about it in an abstract way, we can't and don't need to require that servers follow an actual "step 1, step 2, ..." approach to generating a value set expansion, as that is going too far into prescribing implementation details. Also, the CLD (assuming it is represented in FHIR as ValueSet.compose, as we've stated) actually is not always sufficient by itself to determine the "unique list of members" of the value set expansion (consider the effect of the $expand operation 'date' and ExpansionProfile.fixedVersion parameters). All of the inputs to the expansion process (the code system or systems and versions as implemented in the server, the value set CLD in its specified version and the additional expansion parameters that are supplied) taken together determine both the list of unique concepts (with either single or multiple instances of a particular concept) and all of the additional details that are returned in an instance of a value set expansion. Do we agree on that?
Grahame Grieve (Jan 22 2018 at 13:04):
I think I do
Jay Lyle (Jan 22 2018 at 19:47):
I still think it means people will be maintaining their semantic and UI requirements in the same widget, and this is unnecessary as it's already supported by valueset designation, and expansion profile, and CodeSystem$lookup. But no, I can't think of a use case where it creates a problem other than maintenance headaches.
Robert McClure (Jan 22 2018 at 21:42):
Here is my summary: The $expand operation may result in more than one /contains for each unique concept representation as identified via the ValueSet.compose (CLD) combined with deterministic parameters provided to the $expand operation, such as date and certain ExpansionProfile elements.
Grahame Grieve (Jan 22 2018 at 22:43):
or as specified in the valueset
Joshua Bell (Jan 24 2018 at 22:05):
So what is left to in order to iron out these issues? It seems like most people have a good idea of the direction but the conversation keeps dying down.
Grahame Grieve (Jan 24 2018 at 22:30):
I think it's a face to face discussion next week
Joshua Bell (Jan 24 2018 at 22:37):
Great, looking forward to hearing the results.
Russ Hamm (Jan 25 2018 at 19:33):
I'm keen to participate.
Joshua Bell (Feb 02 2018 at 18:25):
How'd the talks go, was there a consensus on how the different kinds of synonyms at the different levels should be done?
Grahame Grieve (Feb 02 2018 at 19:41):
sigh. I don't think we got to this, sorry. :-(. I think that we would go with the conensus here; I'll draft something for discussion next week
Joshua Bell (Apr 25 2018 at 15:30):
Has this ever been circled back to?
Grahame Grieve (Apr 25 2018 at 21:32):
yes, we defined this extension: http://build.fhir.org/extension-codesystem-alternate.html
Joshua Bell (Apr 27 2018 at 18:15):
That looks like a solution to code synonyms, but what about having multiple displays for the same code in a single valueset. That was what I had asked in the very original OP and I think it diverged to many different topics, code synonyms being one of them. I think you've posted some other threads about what happens when you expand a valueset that has two of the same concept with different display overrides, have those discussions been resolved?
Right now to use valuesets I first expand it from the fhir server, then go back and loop through all of the original inclusion statements and create a new expansion that will include multiple concepts with all the listed display overrides (in our UI we want users to be able to select either 'Male' or 'MaleOtherWording' for the same concept).
Grahame Grieve (Apr 27 2018 at 23:55):
a display is just a preselected designation. you can control which additional designations are returned in an expansion using an expansion profile
Last updated: Apr 12 2022 at 19:14 UTC
