Page History

Welcome and agenda

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

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)

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

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

PLEASE REVIEW BEFORE NEXT MEETING!

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

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|
    • ? 900000000000533001 |Association target component|?
      734139008 |Anatomy structure and part association refset| :
      449608002 |ReferencedComponent| = << |Upper abdomen structure|
    • ? 900000000000533001 |Association target component|?
      734139008 |Anatomy structure and part association refset|
      {{ 449608002 |referencedComponent| = << |Upper abdomen structure| }}
    • (? 900000000000533001 |Association target component|?
      734139008 |Anatomy structure and part association refset| :
      449608002 |ReferencedComponent| = (<< |Upper abdomen structure|) : |Finding site| = *)

Proposal (by Michael) for discussion

• Currently ECL expressions can match (return) concepts that are either the source or the target of a relationship triple (target is accessed via the 'reverse' notation or 'dot notation', but not the relationship type (ie attribute name) itself. 

For example, I can write: 

<< 404684003|Clinical finding| : 363698007|Finding site| = <<66019005|Limb structure| 

<< 404684003|Clinical finding| . 363698007|Finding site| 

But I can't get all the attribute names that are used by << 404684003|Clinical finding| 

• • Perhaps something like:
    • ? R.type ? (<< 404684003 |Clinical finding|)
  • This could be extended to, for example, return different values - e.g.
    • ? |Simple map refset|.|maptarget| ? (^|Simple map refset| AND < |Fracture|)

Proposal for discussion

What refsets is a given concept (e.g. 421235005 |Structure of femur|) a member of?

• Possible new notation for this:
  • ^ . 421235005 |Structure of femur|
  • ? X ? 421235005 |Structure of femur| = ^ X

Expression Templates

• ON HOLD
• Previous discussion (in Malaysia)
  
  • • Overview of current use
    • Review of General rules for generating descriptions
      • Removing tags, words
      • Conditional removal of words
      • Automatic case significance
      • Generating PTs from target PTs
      • Reordering terms
    • Mechanism for sharing general rules - inheritance? include?
    • Description Templates for translation
    • Status of planned specification

FUTURE WORK

Examples: version and dialect

• • << 64572001 |Disease| {{ term = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131

  • << 64572001 |Disease| {{ synonym = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131

  • << 64572001 |Disease| {{ FSN = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131

  • << 64572001 |Disease| {{ FSN = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT W

  • << 64572001 |Disease| {{ preferredTerm = “*heart*”}}   VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT Y

  • << 64572001 |Disease| {{ acceptableTerm = “*heart*”}}   VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT Y

  • (* {{ term = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT Z) MINUS
    (* {{ term = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20170731, DIALECT W)

  • X MINUS Y WHERE X = * , Y = (* {{ term = "*heart*" }}) VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT W

Notes

• • Allow nested where, version, language
  • Scope of variables is inner query

Examples: where

• • X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547)

  • X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547) VERSION http://snomed.info/sct/900000000000207008/version/20180131

  • X MINUS >! Y WHERE X = (<< 1234 : 5678 = << 6547), Y = (<< 1456) VERSION http://snomed.info/sct/900000000000207008/version/20180131
  • X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547) VERSION http://snomed.info/sct/900000000000207008/version/20180131 , LANGUAGE 900000000000508004 |GB English|
  • X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547) VERSION http://snomed.info/sct/900000000000207008/version/20180131, LANGUAGE 999001881000000108|GB clinical extension LRS|, 900000000000508004 |GB English|
    
  • X minus >! X WHERE X = ( < M WHERE M = (< 1234))) VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT 999001881000000108|GB clinical extension LRS|, 900000000000508004 |GB English|

Notes

• • • Allow nested variable definitions, but recommend that people don't due to readability
    • Scope of variables is the inner query
    • No recursion e.g X WHERE X = 1234 MINUS X
      • ie can't use a variable in its own definition
      • ie X is only known on the left of the corresponding WHERE, and not on the right of the WHERE

Keywords for Term-based searching:

• D.term
  • D.term = "*heart*"
  • D.term = wild:"*heart*"
  • D.term = regex:".*heart.*"
  • D.term = match:"hear att"
  • D.term = (sv) wild: "*heart*"
• D.languageCode
  • D.languageCode = "en"
  • D.languageCode = "es"
• D.caseSignificanceId
  • D.caseSignificanceId = 900000000000448009 |entire term case insensitive|
  • D.caseSignificanceId = 900000000000017005 |entire term case sensitive|
  • D.caseSignificanceId = 900000000000020002 |only initial character case insensitive|
    
• D.caseSignificance
  • D.caseSignificance = "insensitive"
  • D.caseSignificance = "sensitive"
  • D.caseSignificance = "initialCharInsensitive"
• D.typeId
  • D.typeId = 900000000000003001 |fully specified name|
  • D.typeId = 900000000000013009 |synonym|
  • D.typeId = 900000000000550004 |definition|
• D.type
  • D.type = "FSN"
  • D.type = "fullySpecifiedName"
  • D.type = "synonym"
  • D.type = "textDefinition"
• D.acceptabilityId
  
  • D.acceptabilityId = 900000000000549004 |acceptable|
  • D.acceptabilityId = 900000000000548007 |preferred|
• D.acceptability
  
  • D.acceptability = "acceptable"
  • D.acceptability = "preferred"

Additional Syntactic Sugar

• FSN
  
  • FSN = "*heart"
    • D.term = "*heart", D.type = "FSN"
    • D.term = "*heart", D.typeId = 900000000000003001 |fully specified name|
  • FSN = "*heart" LANGUAGE X
    • D.term = "*heart", D.type = "FSN", D.acceptability = * LANGUAGE X
      
    • D.term = "*heart", D.typeId = 900000000000003001 |fully specified name|, acceptabilityId = * LANGUAGE X
• synonym
  
  • synonym = "*heart"
    • D.term = "*heart", D.type = "synonym"
      
    • D.term = "*heart", D.typeId = 900000000000013009 |synonym|
      
  • synonym = "*heart" LANGUAGE X
    • D.term = "*heart", D.type = "synonym", D.acceptability = * LANGUAGE X
      
    • D.term = "*heart", D.typeId = 900000000000013009 |synonym|, (D.acceptabilityId = 900000000000549004 |acceptable| OR D.acceptabilityId = 900000000000548007 |preferred|) LANGUAGE X
• synonymOrFSN
  • synonymOrFSN = "*heart"
    • synonym = "*heart" OR FSN = "*heart"
    • D.term = "*heart", (D.type = "synonym" OR D.type = "fullySpecifiedName")
  • synonymOrFSN = "*heart" LANGUAGE X
    • synonym = "*heart" OR FSN = "*heart" LANGUAGE X
    • D.term = "*heart", (D.type = "synonym" OR D.type = "fullySpecifiedName"), D.acceptability = * LANGUAGE X
      
• textDefinition
  
  • textDefinition = "*heart"
    • D.term = "*heart", D.type = "definition"
      
    • D.term = "*heart", D.typeId = 900000000000550004 |definition|
  • textDefinition = "*heart" LANGUAGE X
    • D.term = "*heart", D.type = "definition", D.acceptability = * LANGUAGE X
      
    • D.term = "*heart", D.typeId = 900000000000550004 |definition|, D.acceptabilityId = * LANGUAGE X
• Unacceptable Terms
  • (D.term = "*heart") MINUS (D.term = "*heart", D.acceptability = * LANGUAGE X)

Language preferences using multiple language reference sets

• LRSs that use the same Language tend to use 'Addition' - i.e. child LRS only includes additional acceptable terms, but can override the preferred term

  • E.g. Regional LRS that adds local dialect to a National LRS

  • E.g. Specialty-specific LRS

  • E.g. Irish LRS that adds local preferences to the en-GB LRS

    • 99999900 |Irish language reference set| PLUS |GB English reference set|

• LRSs that define a translation to a different language tend to use 'Replacement' - i.e. child LRS replaces set of acceptable and preferred terms for any associated concept

  • E.g. Danish LRS that does a partial translation of the International Release

    • 999999 |Danish language reference set| ELSE |GB English reference set|

Next meeting is scheduled for Wednesday 29th January 2020 at 20:00 UT. Please enjoy your holidays everyone!