Page tree


Date: 2021-05-26

Time:

1730- 1900 UTC

1030-1200 PDT

Zoom Meeting Details

Topic: SNOMED Editorial Advisory Group Conference Call

Join from PC, Mac, Linux, iOS or Android:

https://snomed.zoom.us/j/99997961770?pwd=TWRiclpVeTU3RG1kUE1lTWNkVFBCZz09
Password: 287392

Meeting ID: 999 9796 1770

International numbers available: https://snomed.zoom.us/u/abTbQn2e26

Or Skype for Business (Lync):
https://snomed.zoom.us/skype/99997961770

Meeting Files:

Meeting minutes:

The call recording is located here.


Objectives

  • Obtain consensus on agenda items

Discussion items

ItemDescriptionOwnerNotesAction
1Call to order and role call

Start recording!


2

Conflicts of interest and agenda review

No conflicts noted


3Editorial guidance for acronyms in descriptionsJim Case

Distilled background from below:

Per Ed:  I see a lot of ‘mRNA’ [in new COVID-related codes].  Outside the realm of clinical imaging and organisms, does SI publish a list of acronyms and abbreviations that do not need to be accompanied by expansions in synonyms?  If not, what is your process for approving internationally distributed exceptions to the published editorial rules?

Per Jim:  We currently only have exceptions for the addition of acronyms for a few items and do not have a comprehensive list.  For descriptions, in this case we are following the guidance related to the use of acronyms in FSNs, which is "An acronym is allowed in a [description] when it has become a word in its own right, i.e., included in dictionaries; understood without expansion to its original full form." A search on Google as well as searches in various dictionaries does not provide an alternative meaning for mRNA other than "messenger ribonucleic acid". It would be useful for us to create a section where approved abbreviations and acronyms are listed.  

Per Ed:  My query relates to the presence of mRNA (without accompanying expansion) in the synonyms listed in the briefing note. It’s confusing if the approach taken is justified by reference to the FSN guidance. Substituting ‘…a [description]…’ in place of ‘…an FSN…’ (in the current editorial guide) is unhelpful. Is the member community free (or indeed expected) to make this substitution anywhere in SNOMED CT’s documentation? 

The Acronyms subsection ‘Preferred terms and synonyms’ guidance begins “…Acronyms are allowed in a Preferred Term or Synonym when followed by the expanded term’ which seems pretty clear to me (and our authoring team, who have spent hundreds of person hours defending this approach to customers). __ However, the international content added here (and plenty elsewhere – both old and new) is in conflict with this clause. Hence my question.

 Deep down I share the view that ‘mRNA’ is only likely have one interpretation in a health record setting (and I’m comfortable, for example, that the SARS-CoV-2 /COVID-19 train left a long time ago), but that is not the point.

A stated editorial stance creates expectations, and exceptions need to be explicit, justified and risk-managed. The current international documentation only gives us imaging modalities (acronyms) and organism names (abbreviations) as exceptions, but the data is full of them. Bafflingly, the second ‘organism abbreviation’ example is illustrated by an unexpanded acronym (‘CRM’) that is used in SNOMED CT to mean both ‘circumferential resection margin’ and ‘cross-reacting material’ and I would wager is NOT ‘understood without expansion to its original full form’ by the majority of readers.

Both these quotes are served by the spirit of the international editorial rules, but sadly not by the data.


From the current Editorial guide:

"Acronyms

Acronyms are easily misinterpreted. For this reason, all acronyms are unacceptable in FSNs.

For example, the FSN should be the expanded form, Computed tomography of chest (procedure), however as a preferred term, CT of chest (procedure) is acceptable.

If there is an acronym in an existing FSN, the FSN DescriptionId is inactivated and a new FSN is created (regardless of whether or not the acronym was in parentheses with the expanded form). The replacement FSN concept has the expanded description with the acronym entirely removed. Inactivating the ConceptId is not necessarily required, unless the FSN had significant ambiguity before changing it to its expanded form."

Discussion:

Briefing note regarding acronyms in SNOMED CT

Does the current editorial guidance need to be updated/expanded to represent exceptions in synonyms?

What should be the rules for exceptions?

Discussion revolved around the use of acronyms with regards to gene names and strains of organisms.  Suggested that we need a process to allow for a more lenient use of acronyms with reference to what an acronym might mean in other contexts. There was consensus that for gene names, it would be acceptable.  This has been discussed for many years and there are always issues that come up that have prevented final resolution.  There are issues with choosing the wrong concept by only using an acronym for searching.  The actual number of acronyms that would not require expansion would be a relative small set.

Suggested that having different semantic tags for areas of the temrinology that allow for the use of acronyms (e.g. genes)

Acronyms may be allowed if there is enough surrounding context to eliminate ambiguity.  

This is similar to the existence of the same description of multiple concepts

Decision:

SI staff will craft updated editorial policy to reflect when and where an acronym may be used without expansion

4"CHARACTERISTIC" attributes for drug model

Background:

Discussed at the 2020-09-09 EAG:

For the vaccine model we used a HAS PRODUCT CHARACTERISTIC to cover about 5 attributes.  In the MRCM, the range is bound to the attribute and so the ranges for these general attributes are difficult to manage and use.  Many of these characteristics are required by extensions and not the core.  The question is whether these should instantiated within the International release or allow extension more freedom to create new attributes.  

The group recommended that we create specific attributes rather than use the generic attribute relationships. Modeling within the international release would not use the generic attributes.  It is important to align new attributes to a specific subdomain so that the use of the attribute is clearer.  

The group did not make a recommendation on the retention of inactivation of the generic "characteristic" attributes; however,it was decided that these generic attributes would not be used to model content  in the International release. SNOMED International had originally determined that we would move towards creating ONLY specific attributes and eventually inactivate the generic attributes after giving extensions that may have used them in their local models to either adopt the more specific international attributes or create their own specific attributes. 

We have received concerns from a number of NRCs that have adopted the use of the generic attributes that inactivation would result in substantial problems. 

Usage:

Feedback from Canada: In Canada, we have a vaccine extension and we are happy to see that new attributes like “Has target population (attribute)” and the “Has ingredient qualitative strength (attribute)”, will be created to better support the vaccine (extensions) model. Where I am not in agreement, is for the “Has product characteristic (attribute)”. That is an Attribute we use to define different things like unadjuvanted vaccine product, adjuvanted vaccine product, the thimerosal free products and we were thinking to use it for seasonal information. I think that it will be very important to consult with member countries that maintain extensions before removing key concepts we use frequently. (n≈100 concepts affected)

Also used for modeling in Argentina's and Uruguay's national extension (n≈30 concepts affected)

Discussion:

Are there problems with adopting cardinality constraints with the use of these generic attributes?  The real challenge is when a specific attribute is created and concepts had been modeled using the generic  attribute.  This would result in two ways to model the same value. It would be the responsibility of the extensions to maintain and remodel to represent the new attributes.  This was considered to be the normal responsibiltiy of extensions anyway.  Documentation of how the generic atributes are used within an extension would also be required.  

Concern that there is not much difference between these generic attributes and the most generic "Attribute (attribute)" concept. 

Currently the range of the HAS_X_CHARACTERISTIC is <<Qualifier value (qualifier value)

It should be the responsibiltiy of extension to us this correclty.  Does it mean that it needs to be in the International release?  The extensions can agree on a common identifier rather than keeping it in the international release.  Suggestion to move it to the community content area raised concerns about managing the MRCM impacts. 

Decision

discssion on whether to move these to the community content area will be brought back to the drugs working group

  • Toni Morrison to bring discussion about moving generic attributes to the community content area back to the drugss working group.
5Concept inactivation workgroup update

Inactivation of Ambiguous Concepts - examples and updated proposal

Document attached to the agenda Meeting Files above.

Discussion:

Jeremy Rogersdiscussed his paper on the issues with the inappropriate use of ambiguous (see attached file).

Jim Case noted that internal policy WRT the use of AMBIGUOUS inactivation reason now requires that at least two POSSIBLY_EQUIVALENT_TO relationships be added as historical relationships, and that all possible historical relationships resulting from a decomposition of the meaning of a term are represented (i.e. AND/OR relationships).  This may mean that new concepts must be created to support the historical relationships.

One part of the discussion paper suggests that in a small number of circumstances, new concepts that would never be approved for inclusion in the international release, would be created and immediately inactivated in order to provide traceability.   

Also suggested that changes to the historical assoications that have been agreed be implemented in advance of the resolution of this issue. 

Decision:

 Input on the docuemnt were welcomed by the Concept inactivation workgroup.  Would like any comments to be received as soon as possible to begin needed tooling changes.   A document will be presented that summarizes the proposal for the next EAG call.

  • EAG members to review document related to AMBIGUOUS issues 
  • Paul Amosto present summary document at the EAG meeting 20210630
6Specimen hierarchy term change proposalJim Case

Inquiries from Germany outlined inconsistencies in terming in the Specimen hierarchy.  A background document with proposed changes is available for review and comment by the EAG prior to broader circulation: 

Specimen term change proposal

Discussion:

Group generally felt that historically and clinically, specimen and sample were used interchangeably.  There was unanimous agreeemnt on the changing of FSNs and PTs to use the term "specimen". James R. Campbellobjected to the universal addition of "sample" descriptions to terms that already had "Specimen" in their FSNs

Decision

EAG consensus was that changes to FSNs may be made without inactivation and replacement of concepts.

7ECE TopicsBruce Goldberg

Pressure injury, con't

Due to lack of time, this topic was deferred to the next call.


8Next meetingEAG

Jim Casewill be away on leave during the normal meeting time.  Options to have the meeting one week later, one week earlier or skip June and meet in July.

June 30 was agreed as the next meeting date.

  • Jim Caseto schedule next meeting for June 30, 2021