Page tree

Date & Time

20:00 UTC Wednesday 5th June 2019

Teleconference Details

To join the meeting please go to https://snomed.zoom.us/j/471420169

Further information can be found at SLPG meeting information

Goals

  • Review actions from last meeting
  • Proposed enhancements to expression constraint language
    • Term searching
  • Proposed new language features for mapping

Apologies

  •  

Agenda and Meeting Notes

Description
Owner
Notes

Welcome and apologies


Actions from last week
  • Actions from last week:
    • Language features required in ECL?
Introducing term searching to ECLLinda Bird

Syntax

{{ term  =  [ termSearchType : ] "String"  }}

Term Search Type

  1. Wild Card Match (collation) - e.g.
    • {{  term = wild:"*heart*“ }}
    • {{  term = wild (sv):"*hjärta*“ }}
  2. Perl Regex - e.g.
    • {{ term = regex:".*heart.*” }}
  3. Word Prefix Any Order - e.g.
    • {{ term = match:“hear att” }}
  4. Default (word prefix any order) - e.g.
    • {{ term = "hear att" }}
    • {{ term = "*heart*“ }}

Potential Examples

  • << 64572001 |Disease| {{ term = “heart”}}
  • << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}}
  • << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}} AND << 64572001 |Disease| {{ term = “hjärta”, languageCode = "sv"}}
  • << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}} {{ term = “hjärta”, languageCode = "sv"}}
  • << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}} OR << 64572001 |Disease| {{ term = “hjärta", languageCode = "sv"}}
  • << 64572001 |Disease| {{ (term = “heart”, languageCode = "en") OR (term = “hjärta", languageCode = "sv")}}
  • (<< 64572001 |Disease|: |Associated morphology| = *) {{ term = “heart”, languageCode = "en", }} {{ term = “hjärta", languageCode = "sv"}}
  • (<< 64572001 |Disease| {{ term = “*cardio*” }}) MINUS (<< 64572001 |Disease| {{ term != “*heart*” }})
  • Recommendation to be made on (based on investigation of grammar):
    • << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}} AND {{ term = “hjärta”, languageCode = "sv"}}
    • << 64572001 |Disease| ( {{ term = “heart”, languageCode = "en"}} OR {{ term = “hjärta”, languageCode = "sv"}} )
    • << 64572001 |Disease| ( {{ term = “heart”, languageCode = "en"}} MINUS {{ term = “hjärta”, languageCode = "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 - e.g. 2.0 (or 1.4?) → same specification document
    • An optional extension to ECL for SNOMED authors/content developers - e.g. ECL++ / ECLv1.3++ → An appendix on the ECL document? (with Filter Language)
    • A subset/profile of the Query Language → A separate document that defines SNOMED filters, which can be added to any version of ECL
    • Filter Language
Executing maps

Reverse memberOf function

  • What refsets is a concept a member of?

Proposed extension to ECL (same packaging questions as above) to support the execution of maps

  • Example use cases
    • Mapping from international substance concepts to AMT substance concepts
    • Anatomy structure and part association reference set - e.g. find the anatomical parts of a given structure
  • Potential syntax to consider
    • Functional
      • mapTarget (|Anatomy structure and part association refset|, << |Upper abdomen structure|)
        • Return the map targets from the given map refset. where the referencedComponent matches the condition
      • mapSource (|Anatomy structure and part association refset|, << |Liver part|)
        • Return the referencedComponent from the given map refset, where the targetId matches the condition.
    • Dot notation + Attribute refinement
      • |Anatomy structure and part association refset| . |mapTarget|
      • |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 ) . |mapTarget|
      • ( |Anatomy structure and part association refset|: |mapTarget| = << |Upper abdomen structure ) . |referencedComponent|
    • Dot notation + Filters
      • ( |Anatomy structure and part association refset| {{ |referencedComponent| = << |Upper abdomen structure| }} ). |mapTarget|
      • ( |Anatomy structure and part association refset| {{ mapTarget = << |Upper abdomen structure| }} ) . |referencedComponent|
        • ^ ( |Anatomy structure and part association refset| {{ mapTarget = << |Upper abdomen structure| }} )
    • Specify value to be returned
      • ?|mapTarget|? |Anatomy structure and part association refset|
      • ?|mapTarget|? |Anatomy structure and part association refset| {{ |referencedComponent| = << |Upper abdomen structure| }}
      • ?|mapTarget|? |Anatomy structure and part association refset| : |referencedComponent| = << |Upper abdomen structure|
Returning attributesMichael Lawley

Proposal from Michael:

  • 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|)
URI Standard
  • Finalize and publish language and language instance URIs
Query Language
- Summary from previous meetings




Examples: version and language

Notes

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





Examples: where

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|

Other topics
  • Any other topics?
Confirm next meeting date/time

SLPG meeting will be suspended until September, due to a series of travel, holiday and work commitments.

  File Modified
Microsoft Excel Spreadsheet RegexCheat.xlsx 2019-Jun-04 by Linda Bird


  • No labels