2023-10-24/25 Full MAG Atlanta Hybrid Meeting

Meeting Introduction

@Peter Williams

5

Start recording

Summary of previous meeting : 2023-04-05 Full MAG London Hybrid Meeting

Discussion on Membership

Annotations Update

@Yongsheng Gao 

@Peter Williams 

30

This topic will focus on the annotation refsets and implementation. The related topics, process, editorial guide, validation and QA will be discussed internally and shared with the group.

Open

The "content model" for utilizing the non-defining characteristic would be the follow-up for specification and impact. 

Format clarification (straw man):

1. We will use the @en "your annotation here" format so as to avoid having to use a null value or not-relevant value for non-language items such as URLs

2. We will support annotations that are strings, but not annotations that point from SNOMED CT Components back to other SNOMED CT Components.   Once the business case for this has been established, this functionality will mostly be handled by the use of Additional Relationships. 

3. There is a legacy "Annotation" refset which did not include a column for the annotation type (ie we'd need a new Refset for each new Annotation).   This group recommends that we mark 5.2.1.6 DEPRECATED: Annotation Reference Set as DEPRECATED and create new pages for the two new refsets (Annotations on Components and Annotations on Refset Members).

@Feikje Hielkema (Unlicensed) would like to add annotation types to an extension and have that appear in the dropdown in Managed Server

@Stuart Abbott (Unlicensed) @Mikael Nyström (Unlicensed) notes the lack of ability to tie translations of a single annotation together, or indicate which one is the original.

Garbor makes analogy of sticky notes, that we aren't too concerned 

@Brian Carlsen @Former user (Deleted) suggest that the language could be removed.  Group consensus on this approach FYI @Chris Swires @Andrew Atkinson .

----------------------------------------------

Questions received from the TRAG:

• to articulate use cases we’re trying to enable, the value they deliver, and who the target audience is for that value (probably use case specific) - copy bullet points, indicate who will consume this data and what will they do with it.

• to draw the distinction between data and metadata.  Yes , done.

• when to use additional relationships/concrete values versus annotations (answered above - when it's Metadata it's an annotation, and when it's data it's an Additional Relationship?) Done.

• how to split the distribution of these additional properties to protect implementations that can’t handle them - i.e. parallel files Yes.  And watch that this will mean additional files for Relationships and Concrete Values.

• how the MRCM could be used for additional relationships/concrete values.

• revisit the diagramming standard to articulate how these additional properties and annotations are shown.   Could we re-use Cappuccino as per original suggested specification. 

• *  Adding a section on use cases to the proposal doc, with the value and intended audience, and at least one example for each use case would be invaluable.

• *  This could then help to address the question of using existing capabilities of the standard where suitable first, before adding new structures or changing the standard.

Discussion in Saturday's Terminology Management Working Group proposed:

• That we use the identification of data vs metadata as the selection criteria for whether a piece of information should appear as an annotation or an additional (non-defining) relationship, and that we use this as Editorial Guidance to prevent various parties from adopting different solutions to the same problem eg URI identifiers for Code Systems / Schema.

• The use of additional relationships is already permitted and has precedence in the International Edition

• That said, having them in a separate file avoids any potential confusion with defining relationships

Update on LOINC & Alternate Identifiers 

Community Content

@Peter Williams 

10

Alternate Identifier File Consultation 

Deprecation of CNC Indicators

Increasing the character count on Descriptions

@Peter Williams 

@Jim Case 

@Andrew Atkinson 

30

There is a requirement to increase the size limit of Descriptions from 255 characters, coming from the need to create FSNs for vaccine products that contain a large number of ingredients.   512 characters would be the next obvious jump, although 1024 would be the usual engineering approach.

RF2 Spec says : "to an overall maximum length of 32Kb"

Unless there are any unexpected objections, this would mainly be a question of vendor consultation and ensuring a sufficient lead time before the changes are made - like > 6 months after the completion of a consultation exercise anyway, possible longer.   The notice period required would be a question in the consultation. 

@Stuart Abbott (Unlicensed) suggests lead time on this should be 18 months to give implementers time to adjust.  Agreed that this should apply to both FSNs and Synonyms

@Brian Carlsen @Guillermo Reynoso suggests 32Kb limit.   Notes that multi-byte characters will reduce the character count since our limit is given in bytes.

@Dion McMurtrie notes that the FHIR spec has a better definition of what all characters are allowed.   (+ @Brian Carlsen ) Further discussion needed on question of what all characters should be allowed eg double dash, non-breaking space.  The validation for exotic quote characters for example is not in teh spec.

Meeting Introduction

@Peter Williams

5

Start recording

Annotations Redux

@Peter Williams 

10

The TRAG objected to the removal of the language indicator and voted 8 - 5 to switch to a language code column.   With it being understood that there is no way to link annotations together to indicate translation.

The priority of resurrecting Additional Relationships was stressed.

LOINC Extension

@Peter Williams 

5

http://loincsnomed.org

Role Grouping and impact on Observables Model

@Yongsheng Gao 

@Jim Case 

@Andrew Perry (Unlicensed) 

@Daniel Karlsson (Unlicensed) 

30

@Yongsheng Gao please insert presentation.

GR: National extensions can start grouping concepts now, which will have no effect and then when International makes a move, they will already be aligned.

What's next for SNOMED CT and MAG work plan?

@Peter Williams 

@Yongsheng Gao 

40

• Change from "Concept model" to "Content model" by using "Additional relationship" as non-defining characteristic. Related topics: MRCM, Diagram, release file structure (ie separate file - TRAG opted for same file), and documentation changes.   Note that in the conversion to OWL, Additional Relationships would also be expressed as Annotations.

• Potential to simplify the MRCM by dropping the  template field.  It is a calculated field which is causing problems for downstream implementations rather than making their lives easier (tagging @Chris Swires )

• Morphology Model

• Role group white paper (Can we link here?  No, is proposal that we should write this, and publish as SI). GR would like to consider better solutions.

• Conflicts of same effectiveTime of same component (@Peter Williams create Confluence page for discussion)

• Refset metadata via annotations (yes, agreed, let's do it)

• Publication of templates (insert link to existing proposal here.  404)

Alternate Identifiers

ML Alternate Identifiers come as a pair (code + scheme).  Needs further work.

Some members of the MAG expected alternate identifiers to show up as a property on a concept which could then be worked with in the alternate CodeSystem

RH Alternate identifiers DO actually exist in the host CodeSystem.

GR Extensions will bundle LOINC content, so they become part of the SNOMED CodeSystem at that point.

MRCM

Inheritance doesn't work when MRCM changes are made by INT.  GR would like to see a persistent addition of extension modifications, rather than having to detect an re-override every time.

A set of MRCM reference sets would provide this mechanism.  Tag @Chris Swires 

AOB

@Peter Williams 

10

Other topics :   Release date changes

TRAG agenda items of interest to the MAG @Andrew Atkinson 

• Reference set metadata - expected to be satisfied using annotations.  Will need to have discussion about what all metadata we want to express, but language alias is an early use case.

• Versioning Templates - yes, we have a proposal for this that was developed internally.  

• Modularisation of SNOMED CT 

• "Negative Delta" file approach 

• Potential for adding a "withdrawn" reason for inactivated content 

@stefan.schulz (Unlicensed) Applied Ontology paper on Clinical Findings and BFO finally published. Thanks for all who contributed as well as those who enabled the open access option! 
See: https://bit.ly/499wUpU

Break Time - 10:30 - 11:00 EDT 

@Peter Williams Switch to LOINC meeting Muse 1

SI internal discussion about process,  editorial guide, validation and quality assurance for annotations

90

1

Module Dependency Refset

@Peter Williams

@Andrew Atkinson

2

Refset Descriptor Refset - Mandatory / Optional / Transitvity

@Peter Williams

5.2.4.1 Reference Set Descriptor

(Generate page for discussion)

3

Draft Design for Template Publication

@Peter Williams

Work in progress:  https://docs.google.com/spreadsheets/d/1hOKOu9kxTFvqlgY_Gzc3T-sn8Z-b-d1bH5-Ocn9Sz90/edit?usp=sharing

Production templates here:  https://github.com/IHTSDO/snomed-templates

GR Major Use cases: 

• MRCM refsets causing issues in computed templates.  Is considered redundant and is heavy overhead for extension.

• UUID for each logical template (Done!)

• Description templates also expected to be used and extended (for each language) by Termmed

• Critical to move forward with this work

DK Points out complexity of generating terms in non-English languages.  We agreed to look at additional use cases although existing design allows for use of RegEx and even small chunks of JScript so already quite flexible.

GR Description rules are most useful when used with sufficiently defined content.  Templated descriptions used with existing International Content could pick up elements from other languages eg use template to help parse the English term parts and translate those in context.  

GR Would like to see refset sample based on current production templates as per GitHub repo.   To be discussed internally @Rory Davidson @Andrew Atkinson

AOB / Items outstanding

@Peter Williams

5

Concept model for a condition without condition (@Jim Case and @Yongsheng Gao)

------------------------------------------

Role Grouping (in the context of BFO harmonization), see Reubmitted Manuscript

Post Coordination (impact of DL changes),   further ECL filtering.

Concept model for conditions caused by substances or products - to be circulated before January @Yongsheng Gao (incl. other AGs and Member Forum)

Yong's further items to discuss (quick chat if time allow, or create page to continue)

• Qualifying Attributes - we've called them that, but they're being used as defining attributes (this is more about documentation clarity)

Future enhancements to the logic profile

Negation

Disjunction

Calculation not currently faster under M1 chip architecture.  Note that most of the time taken up by the classification service end-to-end process goes into generating the NNF, which is single threaded.

Refset Metadata

This topic comes from SNOMED on FHIR

Also TRAG item: Reference set metadata See Agenda item 17 and consider in wider context of machine readable metadata item 11

In fact, this metadata may be more widely useful when applied to a module.

Suggestion that we could use the FHIR standard which already defines metadata. DM suggests a JSON format which would be extensible unlike a column based solution.

Where are we at with this? Checking with @Andrew Atkinson

Revisit "Negative Delta"

@Peter Williams

At request of EAG - need to revoke/delete a published component. Comments added to Negative Delta.

See TRAG agenda item #

Notify @Andrew Atkinson

Use cases:

Two groups: where audit is desired (eg technical issue) and where it is not (IP, un-processable characters)

1. Removing IP - suggestion to blank out particular field ("~") while leaving row.

2. Conflicting Rows ie no clear state (technical issue, not content) - suggestion to subsequent delta clarifying row.

3. Clinically dangerous historical error in before-previous release.