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, 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? The reason that LOINC takes this approach is to support the various types of implementations based on what is reported by IVD devices. It has been argued that in almost all cases Ordinal observables are actually quantitative, but the actual value is hidden from the end user. In HL7, this is handled by having both an observation value and an observation interpretation.

In defining observable observables in SNOMED should we use the scale type? This is a potential Yes/No Answer

Can an observable with a scale type of QN be used to define a finding that has a HAS INTERPRETATION relationship? DKA thinks so. It is different than the interpretation of the value.

Should we consider the scale type of the observable when defining Clinical findings? Does it matter in answering this question? A: Interpretation is a different "act"

If we view the HAS INTERPRETATION as a nominal or ordinal summary assessment of the observation value, which we do not support, it means that we can essentially ignore the scale type when using observables to define clinical findings. However, this will require editorial guidance on which "type" of observable should be used when modeling clinical findings.

There were arguments presented that we should not be using SCALE TYPE attribute when modeling observable entities. It would be used only to map equivalencies to LOINC if htere is a need to do that. However, it would not be used to model international content.

Q: Is there an analytical impact in having a single observable that supports multiple scale types? A: There would be no obstacle for extensions or additional modules to create observables that had an assigned scale type if needed for a particular purpose; however, it might be more practical to allow the information model to define the scale separately from the definition of the observation.

At this point, since most observables are not defined, this is not an immediate issue. It will become an issue if, when we begin to define observables there is a "requirement" to have two observables representing either a quantitative or qualitative (i.e. ORD, NOM, NAR) result.

Proposal:

• When defining observable entities for the international release, the SCALE TYPE attribute will not be used. If extensions would like to add specific subtypes of observable entities that include the SCALE TYPE, they are free to do so.
• When using observable entities to define clinical findings, international concepts that do not include a SCALE TYPE relationship would be used a values for the INTERPRETS relationship. The exception to this guidance are existing "vital sign" observable entities that have been defined with the SCALE TYPE of "Quantitiative".

If approved, this guidance to be added to the SNOMED CT Editorial Guide.

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