2020-02-12 - SLPG Meeting

Welcome and agenda

@Former user (Deleted)

Please note that the SLPG will be meeting in London on Sunday 4th April (9am to 12:30pm) - see schedule

Concrete values

@Former user (Deleted)

Boolean added to draft SCG, ECL, STS and ETL specifications

PLEASE REVIEW BEFORE NEXT MEETING!

• Draft SCG (v2.4) - Compositional Grammar - Specification and Guide

  •  

    • 1. Introduction → History

    • 3.2 Representation of clinical Meanings → Requirement M4

    • 4. Logical Model

    • 4.1 Details

    • 5.1 Normative Specification

    • 5.2 Informative Comments

    • 6.6 Examples → Expressions with Concrete Values

• Draft ECL (v1.4) - Expression Constraint Language - Specification and Guide

  •  

    • 1. Introduction → History

    • 3.2 Expression Constraint and Query Requirements

    • 3.3 Concept Model Requirements

    • 4. Logical Model

    • 4.1 Details

    • 5.1 Brief Syntax (Normative)

    • 5.2 Long Syntax (Informative)

    • 5.3 Informative Comments

    • 6.2 Refinements

• Draft STS/ETL (v1.1) - Template Syntax Specification

  •  

    • 1. Introduction → History

    • 4. Logical Model

    • 4.1 UML Class Diagram

    • 5.1 Normative Specification (boolean changes in blue / other proposed changes in red)

    • 5.2 Informative Comments (only boolean changes made)

    • 6.1 Expression Template Language

    • 8.2 Typed Replacement Slots → Concrete Values

    • 8.3 Constrained Replacement Slots → Value List Constraints? (currently unchanged)

URIs

@Peter Williams & @Former user (Deleted)

Discussions at FHIR Connectathon

• URIs for Language Syntax

  • Alternatives

    • Include a SNOMED CT concept for each language syntax, and use the standard http://snomed.info/id/<sctid> format to refer to these

    • Use http://snomed.info/syntax/<syntaxAbbrev>/version/<timestamp>

• URIs for Language Instances

  • Alternatives

    • Extend the http://snomed.info/id/<sctid> format to allow postcoordinated expressions to be represented

    • Use the language instance format - e.g. http://snomed.info/scg/<expression>

      • Enables versioning of syntax

      • Enables other syntax instances (e.g. ECL URIs)

• URIs for Modelling Resources

  • Global modelling resources will use the http://snomed.info/id/<sctid> format

    • Value sets will use their simple refset id

    • Concept maps will use their map refset id

  • Standard-specific modelling resources will be identified using a format agreed with the relevant standards organisation - i.e.

    • http://snomed.info/<standard>/<standard-specific-format>

    • For the FHIR standard, this will be:

      • http://snomed.info/fhir/{resourceType}/{resourceName} - e.g.:

        • http://snomed.info/fhir/implementationGuide/snomedIG

PREVIOUS UPDATES

Draft URI standard for review - URI Standard

• 2.1 URIs for Editions and Versions (formatting and examples only)

• 2.2 URIs for Components and Reference Set Members (formatting and examples only)

• 2.3 Version-Relative Component URIs (formatting and examples only)

• 2.4 URIs for Modules (formatting and examples only)

• 2.5 URIs for Properties (formatting and examples only)

• 2.6 URIs for Language Syntaxes

• 2.7 URIs for Language Instances

• 2.8 URIs for Modelling Resources

• 3.1 Resolving SNOMED CT URIs

Expression Constraint Language

@Former user (Deleted)

NEXT STEP FOR ECL:

• Agreement in Malaysia - ECL will add the following term searching syntax (no regex - just wild card and word prefix any order):

{{ term  =  [ termSearchType : ] "String", language = [langCode] }}

• Question - Do we want to reconsider including optional parameters for 'type', 'dialect' and 'acceptability'

Term Search Type

1.  

   1. Wild Card Match (collation) - e.g.

2.  

   •  

     • {{  term = wild:"*heart*“ }}

     • {{  term = wild (sv):"*hjärta*“ }}

   1. Word Prefix Any Order - e.g.

   •  

     • {{ term = match:“hear att” }}

   1. Default (word prefix any order) - e.g.

   •  

     • {{ term = "hear att" }}

     • {{ term = "*heart*“ }}

Potential Examples

•  

  • << 64572001 |Disease| {{ term = “heart”}}

  • << 64572001 |Disease| {{ term = “heart”, language = "en"}}

  • << 64572001 |Disease| {{ term = “heart”, language = "en"}} AND << 64572001 |Disease| {{ term = “hjärta”, language = "sv"}}

  • << 64572001 |Disease| {{ term = “heart”, language = "en"}} {{ term = “hjärta”, language = "sv"}}

  • << 64572001 |Disease| {{ term = “heart”, language = "en"}} OR << 64572001 |Disease| {{ term = “hjärta", language = "sv"}}

  • << 64572001 |Disease| {{ (term = “heart”, language = "en") OR (term = “hjärta", language = "sv")}}

  • (<< 64572001 |Disease|: |Associated morphology| = *) {{ term = “heart”, language = "en", }} {{ term = “hjärta", language = "sv"}}

  • (<< 64572001 |Disease| {{ term = “*cardio*” }}) MINUS (<< 64572001 |Disease| {{ term != “*heart*” }})

  • Recommendation to be made on (based on investigation of grammar):

    • << 64572001 |Disease| {{ term = “heart”, language = "en"}} AND {{ term = “hjärta”, language = "sv"}}

    • << 64572001 |Disease| ( {{ term = “heart”, language = "en"}} OR {{ term = “hjärta”, language = "sv"}} )

    • << 64572001 |Disease| ( {{ term = “heart”, language = "en"}} MINUS {{ term = “hjärta”, language = "sv"}} )

Use Cases

•  

  • Intentionally define a reference set for chronic disease. Starting point was ECL with modelling; This misses concepts modelled using the pattern you would expect. So important in building out that reference set.

  • Authors quality assuring names of concepts

  • Checking translations, retranslating. Queries for a concept that has one word in Swedish, another word in English

  • AU use case would have at most 3 or 4 words in match

  • Consistency of implementation in different terminology services

  • Authoring use cases currently supported by description templates

  • A set of the "*ectomy"s and "*itis"s

Questions

•  

  • Do we include 'typeId' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, typeId =  900000000000013009 |Synonym| }}

    • NO

  • Do we include 'type' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, D.type =  synonym }}

    • NO

  • Do we include 'languageCode' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, D.type =  synonym, D.languageCode = “en” }}

    • YES

  • Do we include 'caseSignificanceId' - e.g. << 64572001 |Disease| {{ D.term = “*Heart*”, D.caseSignificanceId = 900000000000017005 |case sensitive|}}

    • NO

  • Do we include 'caseSignificance' - e.g. << 64572001 |Disease| {{ D.term = “*Heart*”, D.caseSignificance = sensitive }}

    • NO

  • Do we include 'language' and 'version' - e.g. << 64572001 |Disease| {{ term = “*heart*” }} VERSION = http://…, LANGUAGE = (999001881000000108|Gastro LRS|, |GB English|)

    • NO

  • Do we include syntactic sugar - e.g.

    • << 64572001 |Disease| {{ preferredTerm = “*heart*”, languageRefSet = en-gb}}

    • << 64572001 |Disease| {{ fullySpecifiedTerm = “*heart*”, languageRefSet=en-gb}}

    • << 64572001 |Disease| {{ acceptableTerm = “*heart*”, languageRefSet = en-gb}}

    • << 64572001 |Disease| {{ preferredTerm = “*heart*”}} FROM  version = X, language = Y

    • NO

  • Do we use/require the "D" at the start of "term"?

    • NO

  • Packaging - How do we package this extension to ECL

    • A new version of ECL - version 1.5

Querying Refset Attributes

@Former user (Deleted)

Proposed syntax to support querying and return of alternative refset attributes (To be included in the SNOMED Query Language)

• Example use cases

  • Execution of maps from international substance concepts to AMT substance concepts

  • Find the anatomical parts of a given anatomy structure concept (in |Anatomy structure and part association reference set)

  • Find potential replacement concepts for an inactive concept in record

  • Find the order of a given concept in an Ordered component reference set

  • Find a concept with a given order in an Ordered component reference set

• Potential syntax to consider (brainstorming ideas)

  • SELECT ??

    • SELECT 123 |referenced component|, 456 |target component|
      FROM 799 |Anatomy structure and part association refset|
      WHERE 123 |referenced component| = (< 888 |Upper abdomen structure| {{ term = "*heart*" }} )

    • SELECT id, moduleId
      FROM concept
      WHERE id IN (< |Clinical finding|)
      AND definitionStatus = |primitive|

    • SELECT id, moduleId
      FROM concept, ECL("< |Clinical finding") CF
      WHERE concept.id = CF.sctid
      AND definitionStatus = |primitive|

    • SELECT ??? |id|, ??? |moduleId|
      FROM concept ( < |Clinical finding| {{ term = "*heart*" }} {{ definitionStatus = |primitive| }} )

    • Question - Can we assume some table joins - e.g. Concept.id = Description.conceptId etc ??

    • Examples

      • Try to recast relationships table as a Refset table → + graph-based extension

      • Find primitive concepts in a hierarchy

  • ROW ... ?

    • ROWOF (|Anatomy structure and part association refset|) ? (|referenced component| , |target component|)

      • same as: ^ |Anatomy structure and part association refset|

    • ROWOF (|Anatomy structure and part association refset|) . |referenced component|

      • same as: ^ |Anatomy structure and part association refset|

    • ROWOF (|Anatomy structure and part association refset|) {{ |referenced component| = << |Upper abdomen structure|}} ? |targetComponentId|

    • ROWOF (< 900000000000496009|Simple map type reference set| {{ term = "*My hospital*"}}) {{ 449608002|Referenced component| = 80581009 |Upper abdomen structure|}} ? 900000000000505001 |Map target|

      • (ROW (< 900000000000496009|Simple map type reference set| {{ term = "*My hospital*"}}) : 449608002|Referenced component| = 80581009 |Upper abdomen structure| ).900000000000505001 |Map target|

  • # ... ?

    • # |Anatomy structure and part association refset| ? |referenced component\

    • # (|Anatomy struture and part association refset| {{|referenced component| = << |Upper abdomen structure|) ? |targetComponentid|

  • ? notation + Filter refinement

    • |Anatomy structure and part association refset| ? |targetComponentId|

    • |Anatomy structure and part association refset| ? |referencedComponent| (Same as ^ |Anatomy structure and part association refset|)
      (|Anatomy structure and part association refset| {{ |referencedComponent| = << |Upper abdomen structure}} )? |targetComponentId|

    • ( |Anatomy structure and part association refset| {{ |targetComponentId| = << |Upper abdomen structure}} ) ? |referencedComponent|

    • ( |My ordered component refset|: |Referenced component| = |Upper abdomen structure ) ? |priority order|

  •  

    • ? |My ordered component refset| {{ |Referenced component| = |Upper abdomen structure| }} . |priority order|

    • ? |My ordered component refset| . |referenced component|

      • equivalent to ^ |My ordered component refset|

    • ? (<|My ordered component refset|) {{ |Referenced component| = |Upper abdomen structure| }} . |priority order|

    • ? (<|My ordered component refset| {{ term = "*map"}} ) {{ |Referenced component| = |Upper abdomen structure| }} . |priority order|

    • REFSETROWS (<|My ordered component refset| {{ term = "*map"}} ) {{ |Referenced component| = |Upper abdomen structure| }} SELECT |priority order|

  • Specify value to be returned

    • ? 449608002 |Referenced component|?
      734139008 |Anatomy structure and part association refset|

    • ^ 734139008 |Anatomy structure and part association refset| (Same as previous)

    • ? 900000000000533001 |Association target component|? 734139008 |Anatomy structure and part association refset|