As discussed in KL. Need a list of proposed description types to send to tech services for implementation. Guidance on use will need to be developed. Current use cases to consider are:

Implemented and populated in the International release:

• near synonym - these can be either "broader than" terms or non-semantically equivalent but related terms (e.g. vaccination (procedure) vs. immunization (a process following vaccination or administration of immunoglobulin)
• hypernyms - are these different than "near synonyms"

Implemented but NOT populated in the International release (i.e., for use in extensions)

• search terms - colloquial terms - provided as an option for extensions, not populated in the international release
• "Patient-friendly" or consumer terminology
• abbreviations/truncation/acronym - abbreviated form

Issues within our current synonyms was identified in an AMIA paper in 2003:

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC1480077/pdf/amia2003_0949.pdf

Discussion:

GRE: Not necessary to distinguish hypernyms and near synonyms. Consider a separate extension for "patient-friendly" terms. Need a separate language refset.

How to identify near synonyms? GRE: Had done some work 10 years ago. May be useful to get an idea of scope.

Want to avoid contaminating the terminology with non-synonymous descriptions. Do these need another description type or just a mechanism to segregate the descriptions from the main branch? Adding to another language refset would require modifications of the AP UI.

There is a risk in adding near synonyms if those descriptions are used in the EHR UI. Suggestion that we need to distinguish the near synonymy, e.g. broader than or narrower than. Narrower than are not synonymous at all as they are specializations of the parent.

Use the definition from ISO 25964-1:2011 as a guidance for defining near synonymy.

Discussion continued to next call without resolution

Summary of chat from 4/2/2020:

Q: For hypernyms, why wouldn’t you have a parent concept that has the meaning of the hypernym?

A: You very likely WOULD have a more abstract concept that [represents] the hypernym, often as its PT. The problem is that clinicians ALSO want the hypernym term to be attached to some more specific descendant concept, as a term that returns it as a search match candidate. That in itself is a problem, if you support attaching an explicit hypernym to a given concept, searching using the hypernym you will get back both the abstract superclass and its more detailed descendant that the clinician "normatively" expects and is looking for.

Q: WRT patient-friendly terms, isn’t a problem that you can’t distinguish a true description from a patient-friendly term without reviewing the language reference set?

A: It is true that you can not tell just by looking at a [description] whether it is a clinical or patient friendly term without consulting the relevant Language Refset. But that's arguably a feature not a problem!

Comment: [Hypernyms] introduce a risk of inproper use of a concept. Systems will need to adapt to the use of different language reference sets for different purposes - it seems straight forward - but not sure it is in practice. Having a distinct description type seems safer  - i.e. systems exclude descriptions of a particular type for the purpose of data entry.

Comment: Combining lexical lookup with the transitive closure table (and modelled relationships) is indeed the other way to get a detailed concept returned in response to search on one of its hypernyms, and without having to have that hypernym term directly added as a description on the magic concept. Can produce a lot of noise for the clinician if they are accustomed to using a hypernym to find a particular concept, but the concept that properly represents the hypernym term has many descendants.

NEW

Summary of comments from CMAG:

In general, most extensions are already using a mechanism to manage patient-friendly terms within their extension and do not have an immediate need for a specific description type to be created. They did not address the issue of the value of near-synonymy and did not specify any other description types that might be useful. They also did not feel it was necessary to specifically call out abbreviations or truncations.

Questionable synonym review - termMED 2009

Proposal from Head of Terminology:

Add a single new description type representing "near synonymy" (name to be decided). Restrict its use to "broader than" concepts where the specificity is implied in clinical settings, or non-semantically equivalent but related terms, such as the outcome of a process.

Alternatively, add single new description type of "Hypernym" which expressly represents the broader than notion.

Both of these alternatives would require some detailed editorial guidance on when to allow the addition of these types of descriptions.

Determine whether it would be beneficial to repeat the work done by Guillermo and his group to reflect the extensive changes that have occurred in the terminology since the initial effort in 2009.

04/29/2020 Discussion:

For translations, having the designation of near synonymy is of benefit so that they can be ignored. This may be a patient safety issue. There must be a way to identify non-synonymous descriptions. GRE recommends that addition of two description types: Near synonym for use within the international release and "entry-type" description for use within extensions. The number of issues WRT near synonymy is related to the number of descriptions associated with a concept.

JRE: Favors hypernym. There are all types of non-synonymous acceptable descriptions.

KCA: Prefer accepted language for describing these. Hypernym , i.e.. hypernym and hyponym, but use should be discouraged. Provide a path to create new concepts from these descriptions.

GRE: Near synonym is the term that is described by the ISO standard. We need to enforce that superclasses and subclasses should not have the same description.

DKA: Synonymy is continuous as opposed to discrete, and is context dependent. There is a mechanism to handle this in language refsets rather than trying to create a new description type. Another issue, getting inter-rater agreement as to what does or does not qualify as a true synonym would be difficult.

AHO: We should not encourage the creation of these near synonyms. By creating new description types we might be creating a mechanism for users to request or create these.

GRE: The MAG/EAG discussion expressed a preference for a new description type over using language refsets. The International edition could adopt a policy of not accepting new near synonyms.

PAM: Concern is how this would be used by the editors. The distinction of whether to include a description as a true or near synonym is context dependent.

The question is what to do with the existing descriptions that we have that are non-synonymous. We need a pragmatic approach to determine whether a description represents the meaning by the FSN. A prior definition from ISO stated the issue of synonymy as being context dependent and continuous. There is a use case for near synonym in searching.

YGA: If searching is the primary use case, then we should mark descriptions in this way. We should get rid of non-synonyms, but keep search terms available because of their utility.

No resolution: discussion continued....

Summary of chat comments:

Two terms are considered synonyms if:

• they represent a single concept, within a specific semantic category as the only additional context.
• the concept represented by one of them in a statement does not vary if the terms are interchanged (i.e. the first term is replaced by the second one).
• they share the same level of granularity for a concept.
• they represent the same concept in all or most contexts.

ISO 1087 (1990:5), “terms which are interchangeable in all contexts of a subject field"

Does the HAS INTERPRETATION range need to match the SCALE of the Observable used as a value for INTERPRETS?

https://docs.google.com/presentation/d/143fQMaHsV9NTwK0ZdEpNLE2fsgefU6-vKANl7hT7ptY/edit?usp=sharing

Discussion:

While Observable entities have multiple scale types including ordinal, nominal, qualitative, quantitative, etc., the HAS INTERPRETATION attribute is limited in its range to << 260245000 |Finding values (qualifier value)| .

Can an Observable with a SCALE TYPE of quantitative be used to define a clinical finding that uses an INTERPRETS/HAS INTERPRETATION relationship group? The definition of HAS INTERPRETATION is "This attribute refers to and designates the judgment aspect being evaluated or interpreted (e.g. presence, absence, degree, normality, abnormality, etc.)." Since the Clinical finding concept model does not have the actual value of a quantitative observable, how should the scale type of observables be defined?

While LOINC tries to resolve the issue by creating terms that represent quantitative and ordinal scales, it may not be desirable for SNOMED to go down the same path. The distinction is that LOINC tries to go the the path of highly detailed observables without a taxonomy while SNOMED is focused on building relationships among terms. Since HAS INTERPRETATION is a judgement about the value associated with an Observable entity, what role does specifying SCALE TYPE play in the definition of a clinical finding?

In defining observable in SNOMED should we use the scale type?

Should we consider the scale type of the observable when defining Clinical findings?

Doodle poll to be sent out for meeting in May

Discussion:

Potential agenda items:

• Update from concept inactivation group
• Update from source of truth project