Stream: implementers
Topic: ValueSet expansion including synonyms
Heath Frankel (May 02 2016 at 00:22):
The ValueSet resource expansion/contains only has code and display elements. Can I represent synonyms using the contains element by having multiple elements with the same code and the synonym term in display or is display reserved for preferred terms only?
Grahame Grieve (May 02 2016 at 02:26):
you could have multiple elements with the same code, yes. that's certainly the intent
Heath Frankel (May 02 2016 at 03:34):
OK, great. However, there is no means to determine if this ValueSet.expansion.contains.display value is a synonym or preferred term in which case it is not possible to determine if the display value can be used in the Coding.display element or if it should be provided in the Codable.text.
Peter Jordan (May 02 2016 at 03:55):
@Heath Frankel ValueSet.compose.include.concept.designation.use enables you to indicate whether a concept contains a fully specified name, preferred term or synonym... http://hl7.org/fhir/2016May/valueset-designation-use.html. However, there does not appear to be an equivalent property in ValueSet.expansion.contains...but, of course, I may be missing something.
Lloyd McKenzie (May 02 2016 at 04:01):
I don't think there's any rule about what display label has to appear in Coding.display. It isn't required to be the preferred term, though it might often be.
Heath Frankel (May 02 2016 at 05:11):
@Grahame Grieve , the rules in the NEHTA CDA Validator Rules regarding the mandatory use of Preferred terms in CD displayName is a localised rule rather than something recommended/enforced by HL7?
Grahame Grieve (May 02 2016 at 06:39):
yes it is. specifically, HL7 says you can use any valid display there
Grahame Grieve (May 02 2016 at 06:39):
there's the $lookup operation to get it if you need it.
Grahame Grieve (May 02 2016 at 06:40):
Doesn't NEHTA have a partner rule that you must show the preferred term in an expansion?
Aleksandra Pavlyshina (Nov 02 2016 at 13:28):
Please advise what are the best practices for presenting SNOMED terms?
For example, Pulmonologist is listed in SNOMED as Respiratory disease specialist (occupation):
41672002 | Respiratory disease specialist (occupation) |
Respiratory disease specialist
Respiratory disease specialist (occupation)
Respiratory physician
Pulmonologist
Which display value we are allowed to use in a drop down list in an application?
Can we have several values (synonyms) displayed in the drop down list e.g. both Pulmonologist and Respiratory disease specialist?
Or can we edit the display value to be Respiratory disease specialist (Pulmonologist) in our drop down?
Grahame Grieve (Nov 02 2016 at 18:46):
From a FHIR point of view, you can use any of the SNOMED CT displays. You can specify your own display too, using ValueSet.compose.include.concept.display.
Grahame Grieve (Nov 02 2016 at 18:46):
I'm not sure about including the same concept twice with different displays. Moved to the terminology stream for discussion
Michael Lawley (Nov 18 2016 at 01:43):
@Aleksandra Pavlyshina The IHTSDO provides guidance on this. There best practice is to use the synonym defined as the "preferred term" - there is a Language Reference Set that does this in thr RF2 release data. You should not use the "Fully Specified Name" (the one with '(occupation)' on the end) in most cases.
Furthermore, you shoud normally only ever display a concept once in a selection list since displaying it several times with different labels can suggest (incorrectly) that they mean different things.
Note, technically, it is also allowed to display any of the synonyms that are tagged as "Acceptable", but better to avoid doing this unless you have very good reasons and understand the implications.
Grahame Grieve (Nov 18 2016 at 06:18):
it's kind of weird advice to say "you shoud normally only ever display a concept once in a selection list since displaying it several times with different labels can suggest (incorrectly) that they mean different things" - if the different labels aren't actually different, why are they present? if they are actually different, why would a user not need to have them as an option?
Michael Lawley (Nov 18 2016 at 06:36):
There are multiple synonyms for a range of reasons including:
- aids in searching
- different spellings
- different preferences in different contexts
- historical reasons
- other
Ultimately, it's a reference terminology, so the base content includes multiple ways to say the same thing. But depending on how the content is displayed in a UI (and whether that UI is for data capture or back-office analytics or ...), it may/may not be appropriate to expose all the associated labels.
Best practice for a data capture/entry scenario (ie where you need an interface terminology) is to only display a concept once, major EMR vendors notwithstanding.
IHTSDO guidance on this is here https://confluence.ihtsdotools.org/display/DOCSEARCH/5.1.3+Avoid+Multiple+Hits+on+the+Same+Concept although I think they could/should say this a lot more strongly.
Joshua Bell (Jan 03 2018 at 16:57):
Are synonyms a thing that works now? Based on the Fhir spec it seems like I should be able to add designations and use includeDesignations=trueon a ValueSet expand to include synonyms. But I think I may be confused by that param, is it supposed to override or add in copies of the same concept but with a different display in the expanded set. I want something like $expand?includeDesignations=true -> [ sex|male, sex|maleSynonym, sex|female ]
Regardless of what I try it always just returns [ sex|male, sex|female ] with no synonyms
Grahame Grieve (Jan 03 2018 at 21:17):
it's not clear what you mean my synonyms - alternate displays, or alternative codes.
Joshua Bell (Jan 03 2018 at 22:56):
@Grahame Grieve Alternate displays. I'd like to be able to have an expanded list for a dropdown that has multiple displays that map to the same concept.
Grahame Grieve (Jan 04 2018 at 09:43):
great - so there's a question here. I think that include designations means to add additional designations on the contains in the expansions, not to add additional contains. But that's purely arbitrary - suggest we take this up on the terminology stream
Last updated: Apr 12 2022 at 19:14 UTC
