2022-07-05 Full MAG Meeting (Conf Call)

Meeting Introduction

@Peter Williams

5

Start recording

Thanks to @Karim Nashar - rolling on to observers.

Summary of previous meeting : 2022-04-04 Full MAG Meeting (Hybrid Meeting)

SNOMED CT representation of annotation properties and values

@Yongsheng Gao

45

Please add comments to SNOMED CT Annotations  

Implementation scheduled for 2023

Focus on datatype representation and language.

Options:

New refset per annotation vs column specifying annotation type 

Language code using @ symbol vs separate column

Separate file for each datatype vs "it's all string, only some strings are more easily converted to numbers ie where a # is present)

How to specify specific column  - semantics just understood from context vs re-use of referencedComponentId with a column attribute (ie that which is used in the descriptor refset)

Feedback

GR (21:38) Language should be another column, to make searching easier without parsing.  Is also consistent with description file.   (alternatively put tag at the beginning to make easier to find).  PWI notes that language column doesn't address dialect.  Is concerned about being unable to group annotations together if they are split between many files.  PWI If we use the column for annotation type solution, then we still have the option to create additional refsets for grouping

GR was expecting to annotate a row, did not expect to need granularity of per-column identification.

BC URIs should of course be URL encoded.   Clarified that these annotations will exist in their own refset file(s) and could potentially reference any other component.

GR Can we use HTML? Would need to either be subset of HTML or Markdown.  Needs to be compatible with RF2 distribution format.   Secondly would we use this facility or new description types for near synonyms / patient friendly terms?   PWI - Discussion planned for September Joint AG session

DK Supports proposal.  Annotating changes has been needed for some time - don't get bogged down with patient friendly terms!

URIs for Editions plus Derivatives

(21:52)

@Former user (Deleted) 

35

2.5 URIs for Editions plus Derivatives

This is specific to including derivative works, but we also have a topic out there for specifying which modules are included in an Edition (with a JSON solution) where the Module that is publicised is not the lowest.  CC @Andrew Atkinson 

Discuss needing clarity around which version of dependencies should be used when multiple derivatives have dependencies with different versions (eg because derivatives are published less frequently than the International Edition)   

Additional URI considerations:

• URIs for Descriptions and Relationships should resolve as per the concept that they are associated with.

• SCTIDs that do not exist in the specified module & version should return a 404, but with the potential to additionally return more information.

• URIs resolvable for ECL is highly desirable.

Discussion

DK clarifying that inclusion of derivatives that do not contain concept model attributes - what happens if we did want to eg putting two extensions together to give broader content.   LB suggests classifying such editions together and resolving the issues that arise. 

GR Wishes to clarify the scope of the proposal (which is sensible).   Suggests that this mechanism not be abused and that for a more complete solution an Edition should be formed (eg where there are multiple dependencies).  Would like documentation to specify when NOT to use this facility.

Metadata

@Guillermo Reynoso

@Ronald Cornet (Unlicensed)

@Karim Nashar

@stefan.schulz (Unlicensed)

5

Metadata (including specifying aliases for langrefsets and some overload with Annotations in OWL): Capture, Interrogation and Publish.  CC @Andrew Atkinson we also have the JSON file which PWI sees as a bootstrap information file before RF2 files are imported into the datastore.

Was there a proposal for language refset aliases?    New proposal is to use an annotation on the refset concept.

GR Agrees overlap between metadata and annotations work.   In most cases metadata can be covered by annotation.   Internal comments could also be used (although perhaps not published).   Other uses include capturing which template was used, or whether a plural form has been used.    Because uses are so heterogenous, grouping is essential eg to indicate which annotations should be published.   Non-defining relationships in drug models might need their own refset.

YG We will consider grouping further - suggests separate refset for internal use (have also considered separate column for "don't publish" flag but this was rejected)

KK Would be good to identify metadata that would have substantial reuse and specify standards for that.

AOB

0

Next meeting - SNOMED International Business meeting & Expo 24 - 30 September 2022.

September Expo 2022 Lisbon - Registration now open!

Additional Description Types - (eg near synonyms, patient friendly terms) planned as topic for joint AG meeting in September.

GG Would like to see discussion around refsets and specifically multiple languages which are managed by exception eg Common French then specialised by Swiss and Canadian French.  "Scope" refsets may be useful in this area.

1

Module Dependency Refset

@Peter Williams

@Andrew Atkinson

Metadata working group proposed - volunteers? @michael lawley @Guillermo Reynoso @Peter Williams

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, 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.