Stream: implementers
Topic: SNOMED display name
Krishna Moorthi (Dec 01 2021 at 10:24):
Hello all,
Hope all is well. I have a question related to conditions used in client application. we agree to use the standard SNOMED names e.g., "Heart failure (disorder)" as per SNOMED.
From a medical perspective this is not good, since it adds a lot of clutter for the HCP to read. Medical would prefer to have a cleaner naming e.g., "Heart failure" only without the brackets.
Does it ok our valueset display can have Designated preferred name (PT)? for ex...
{
"code": "84114007",
"display": "Heart failure"
}
Thanks
Grahame Grieve (Dec 01 2021 at 12:12):
yes
Krishna Moorthi (Dec 01 2021 at 12:54):
Thanks ! another question is :
How do we get clean / clutter-free condition names for all SNOMED codes without manually translating all 350k SNOMED codes?
David Pyke (Dec 01 2021 at 14:35):
You'd be better off using a UI filter that removes the bracketed text, rather than changing the display name. That way you don't have to worry that your display names aren't compatible with someone else's system
Donna Pertel (Dec 01 2021 at 19:02):
Some SNOMED CT display names (without the bracketed text) are longer (>70 characters). I'm curious how these are handled?
David Pyke (Dec 01 2021 at 19:18):
Handled in what way?
Jim Steel (Dec 01 2021 at 23:35):
Actually, the spec (https://hl7.org/fhir/snomedct.html) explicitly says that the best choice for the display term for a SNOMED CT concept is the preferred term in the relevant language, not the fully specified name (which is the one with the parentheses).
Peter Jordan (Dec 02 2021 at 01:24):
David Pyke said:
You'd be better off using a UI filter that removes the bracketed text, rather than changing the display name. That way you don't have to worry that your display names aren't compatible with someone else's system
Whatever is selected by a user needs to be persisted and therefore should be a valid description (preferably the preferred term, but any acceptable synonym within the context of use, or the FSN). Removing the Semantic Tag from the FSN and presenting that will not necessarily provide a valid description.
Arianne van de Wetering (Jan 18 2022 at 14:03):
In The Netherlands our health professionals frequently give feedback they don't like the SNOMED preferred term. Usually this is caused by too much context in the term which is really not necessary in the context of the system. So SNOMED preferred terms are often too elaborate to be user friendly display in GUI's. Out of curiosity: what is the experience in other countries?
Peter Jordan (Jan 18 2022 at 17:56):
That could be a UI issue - i.e. the concepts that they are being presented with are too detailed. Otherwise, this should probably be fed back to whoever is responsible for your National Edition to see if alternative synonyms might be selected as preferred terms, or additional synonyms might be created that are better suited for national use.
Grahame Grieve (Jan 18 2022 at 19:25):
@Arianne van de Wetering I explored this a little here: http://www.healthintersections.com.au/?p=1716
The problem is that the display for a concept isn't related to a particular concept - it's a general description of the concept that uniquely differentiates it from any other concept.
But almost always, when a concept is used, it's used in a context where certain things are known about it in advance e.g. what goes in this field is a body structure. Given that, the description will (should!) contain extraneous words that are a cognitive drag on the user. Ignoring this fact is an insult to the user (and the kind of thing that drives users to dislike information systems).
So what a concept really needs is a general display that properly describes it in any context at all, and then context specific displays that concentrate on efficiently differentiating the concept from the other applicable concepts in a particular context. Terminologists tend to freak out about this, concerned at the danger of losing information or misusing concepts this way, and I've absolutely seen this. But it's easy for us to overlook the problem that's trying to be solved. Which is neatly illustrated by the Synthamine example in my blog post
Grahame Grieve (Jan 18 2022 at 19:27):
that's why you can and should specify displays for concepts in value sets, and then, if a field is associated with a value set, use the display found in the value set, which is contextualised. Though in an ideal system, I might use a different colour or something for the display if the concept was in the expected value set vs not one that was expected
Last updated: Apr 12 2022 at 19:14 UTC
