Summary
The CMAG is being asked to contribute to the discussion on additional description types, in particular what additional description types would be required by extensions. Links on the discussions to date and the planned discussion at the next Editorial Advisory Group meeting are provided below.
Examples of potential extension use cases may include:
- Search terms - colloquial terms
- "Patient-friendly" or consumer terminology
- Abbreviations/truncation
Current description types:
- Fully Specified Name
- Synonym (includes the preferred term)
- Definition
Would you please add your comments below in the discussion section as well as the particular requirements for your country in the country response section.
Relevant documents
Links:
2019-10-28 Editorial Advisory Group Face-to-face Meeting - Kuala Lumpur -see item 9. Use of hypernyms as descriptions
2020-04-06 Editorial Advisory Group Conference call
Actions:
Date | Requested action | Requester(s) | Response required by: | Comments |
---|---|---|---|---|
19 March 2020 | Input on additional description types |
| Please post your final responses in the Country response table below. Discussion comments can be made as comments below. |
Country response
Country | Date | Response |
---|---|---|
Sweden | 2020-03-23 | 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. |
Australia | 2020-03-24 | 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. |
Norway | 2020-03-27 2020- | We have had input that there is a need for Patient-friendly terms. Personally, I am not sure of the consequences. It is important such at term is semantically equivalent to the FSN, so in cases where this cannot be achieved, a patient-friendly term cannot be assigned (at least not within the Scope of SNOMED CT). It is really up to SNOMED to define what a patient-friendly term should be defined as. Search terms / abbriviations are Language spesifici and should be solved outside of SNOMED CT. Search term lists are also shared With other terminologies, e.g. ICD. WW |
Canada | 2020-04-07 | For the time being we suggest: •UI terms should be kept in local extensions to meet the local requirements 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? |
US | 2020-04-08 | 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). |
Member countries without a CMAG rep |
CMAG response
Date | CMAG Response | Next steps |
---|---|---|
Final outcome:
Date: