Page History

We already have language reference sets, which is a powerful tool to specify description use contexts such as (potentially) patient friendly/common language terms, speciality terms. Linguistic variants (abbreviations, singular/plural forms, some derivations) we would (mostly) consider as acceptable synonyms. We are still in the process of finding out what constitutes over use of language reference sets.

"Search terms" we assume are generally not (true enough) synonyms and thus might require a new description type OR a new acceptability value and a slight(?) re-interpretation of what 900000000000013009 | Synonym (core metadata concept) | means.

Very similar approach to Sweden. Abbreviations are already supported and editorial guidance exists.

I could see a "patient friendly" synonym type being viable for when the same synonym will apply to a large number of specific concepts. And patient doesn't "need" to know that that much detail. "Patient-friendly" terms are inherently "lossy" - reduced detail. I'm not sure about the value of truncation? We create a lot of synonyms, specifically aimed at a consistent search experience.

As an aside, we've been informed by a clinician that we're in a (quote) "post mellitus" world, and "Diabetes" is an appropriate/preferrable synonym to "Diabetes mellitus". We're in looking into how we'll action this.

•UI terms should be kept in local extensions to meet the local requirements
•Keep it simple and use the existing language refset mechanism
•Use a description refset for searching (same as we did for Apelon additional synonyms)
•Currently when we include terms that may “deviate” from the approved editorial guidelines, the rationale and rules are documented in the national guidelines.

But we do have questions related to the SNOMED Edition(s) Future Strategy:

•How would the proposed changes impact the future of the SNOMED International Community Edition, SNOMED CT International Edition and Clinical Core Edition?
•If more than one country is using the same « patient-friendly » terms will they be included in the International Edition?
•Will these additions be documented in a specific « patient-friendly » guide?
•How important is it to have a descriptionType of Abbreviation when the term is obviously an abbreviation?
•Suggest that the patient-friendly terms be created outside of the core or community files, so organizations can decide if they want to use them or not.

 Sounds like we are moving away from reference terminology towards interface terminology. This is not necessarily a bad thing, but I think we should clearly acknowledge the move and possibly bound it. Otherwise, there is a significant risk for scope creep.

Regardless of the mechanism, what is important is to be able to capture the type of variant explicitly (e.g., to select/filter out such variants in specific contexts).