Date
2020-04-29
Time:
1800 - 1930 UTC
1100 - 1230 PDT
Zoom Meeting Details
Topic: SNOMED Editorial Advisory Group Conference Call
Time: Apr 29, 2020 11:00 AM Pacific Time (US and Canada)
Join from PC, Mac, Linux, iOS or Android:
https://snomed.zoom.us/j/96945174848?pwd=WDJlVEFYTmk1U3RkQmFGV1JONTRKZz09
Password: 030324
Meeting ID: 969 4517 4848
Password: 030324
International numbers available: https://snomed.zoom.us/u/aNKqXbcBe
Or Skype for Business (Lync):
https://snomed.zoom.us/skype/96945174848
Attendees
Chair:
AG Members
Invitees:
Apologies:
Meeting Files:
Objectives
- Obtain consensus on agenda items
Discussion items
Item | Description | Owner | Notes | Action | |||||||
---|---|---|---|---|---|---|---|---|---|---|---|
1 | Call to order and role call | Start recording! |
| ||||||||
2 | Conflicts of interest and agenda review | No conflicts noted | |||||||||
73 | Additional description types | Jim Case | 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:
Implemented but NOT populated in the International release (i.e., for use in extensions)
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:
ISO 1087 (1990:5), “terms which are interchangeable in all contexts of a subject field" |
| |||||||
4 | Scale types vs. HAS INTERPRETATION in modeling Findings using Observable entities | Daniel Karlsson | 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 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:
If approved, this guidance to be added to the SNOMED CT Editorial Guide. |
| |||||||
5 | ECE Update | Bruce Goldberg |
Discussion: Initial testing of the impact of inactivation of 362977000 |Sequela (disorder)| and replacement with 64572001 |Disease (disorder)| in concepts that had it assigned as the IS A parent results in a more complete set of subtypes classifying under 302049001 |Sequelae of disorders (disorder)| and 312087002 |Disorder following clinical procedure (disorder)|. The availability of ECL was purported to be a more effective mechanism in identifying concepts that would be considered sequela or late effects than the manual assignment of a intermediate primitive concept. Bruce Goldberg was asked to do more evaluation of the results of the inactivation of 362977000 |Sequela (disorder)|. If no issues remain, this concept will be inactivated in the Jan 2021 release. Time limitation. Remaining topics continued to a future call |
| |||||||
6 | 8 | ECE Update | Bruce Goldberg | 9 | Immunoglobulin vs. Antibody | Farzaneh Ashrafi | 10 | Morphology (disorder) concepts | Jim Case | SNOMED CT currently has a large number of disorder concepts that solely represent morphologies. E.g. 416462003 |Wound (disorder)|; 416439000 |Lipogranuloma (disorder)|). While all of these are SD by simply using DIsease + morphology, other than as grouping concepts, are these valuable clinical terms. With the advent of ECL it is a simple query to identify all concepts that fit into these morphologies. What should be the editorial guidance for the creation/maintenance of these terms? Additionally, there are of over 5400 "grouper" terms in SNOMED CT. Many of these are abstract and are useful for navigation, but should not be used in clinical recording. There has been some interest in providing these as an exclusion refset in order to prevent them from being selectable for clinical use. However, some of the terms do have limited clinical usefulness (i.e patient reported clinical findings). It has been suggested that a task for the EAG would be to identify: 1) which terms in the list have clinical usefulness, 2) which terms provide meaningful navigational usefulness and 3) which terms should be inactivated. File link: SNOMED CT Grouper sheet Discussion: Time limitation. Continued to a future call | |
711 | Next meeting | EAG | April business meeting has been canceled. Next call in late AprilDoodle poll to be sent out for meeting in May Discussion: Potential agenda items:
|