2019-05-08 - SLPG Meeting

2019-05-08 - SLPG Meeting

Date & Time

20:00 UTC Wednesday 8th May 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

  • Make a decision on meeting at October business meeting

  • Review actions from last meeting

  • Proposed enhancements to template language

  • Proposed enhancements to expression constraint language

    • Term searching

  • Proposed new language features for mapping

Attendees 

  • Chair: @Former user (Deleted)

  • Project Group: @Ed Cheetham@michael lawley@Anne Randorff Højen@Daniel Karlsson

Apologies

  •  

Agenda and Meeting Notes

Description

Owner

Notes

Description

Owner

Notes

Welcome and apologies

@Former user (Deleted)

  • Question - Should we hold a SLPG meeting in October (in Malaysia)?

Actions from last week

@Former user (Deleted)

  • Actions from last week:

    • Update template syntax with new features

    • Consider new syntax to support proposed map use case

Template Syntax

@Former user (Deleted)

2 new proposals to meet SNOMED International's use cases

  1. Require slotnames to be unique

    • Why? To avoid having 2 ways to do the same thing, and to clarify the meaning through value restrictions.

    • Template

      • [[ +id ]]:
        { 116676008 |Associated morphology| = [[ +id @morphology ]],
        363698007 |finding site| = [[ +id @findingSite ]] },
                { 116676008 |Associated morphology| = [[ +id ($morphology) ]],
        363698007 |finding site| = [[ +id (* MINUS << $findingSite) ]] }

    • Valid Expression (Definition of 16027391000119109 |Bone cyst of bilateral tibias (disorder)|)

      • 64572001 |Disease| :
                    { 116676008 |Associated morphology| = 66954000 |Bone cyst|,
                      363698007 |Finding site| = 719491009 |Bone structure of right tibia| }
                    { 116676008 |Associated morphology| = 66954000 |Bone cyst|,
                      363698007 |Finding site| = 719492002 |Bone structure of left tibia| }


  2. Introduce a sameValue constraint (similar to the allOrNone constraint)

    • Template

      •  [[+id]]: [[1..* @group sameValue ($morphology)]]
        { |Finding site| = [[ +id ]] ,
        |Associated morphology| = [[ +id @morphology ]]}

    • Valid Expression (Definition of 31580001000004106 |Bilateral sacral insufficiency fracture (disorder)| )

        • 702561005 |Insufficiency fracture (disorder)|:
                     { 363698007 |Finding site (attribute)| = 736830008 |Bone structure of left half of sacrum (body structure)|,
                        116676008 |Associated morphology (attribute)| = 22640007 |Pathologic fracture (morphologic abnormality)| }
                      { 363698007 |Finding site (attribute)| = 736831007 |Bone structure of right half of sacrum (body structure)|,
                        116676008 |Associated morphology (attribute)| = 22640007 |Pathologic fracture (morphologic abnormality)| }

Use cases: New concept development, querying based on template matching, and template-based modeling transformation

Other requirements

  1. Constrain values across 2 or more replacement slots

    • 2 replacement slots must have the same value, different values, subsumed values, or not subsumed values.

    • Example A - A clinical finding, with 2 role groups with the same morphology, and finding sites that not subsume each other

      • Template

        • [[ +id ]]:
          { 116676008 |Associated morphology| = [[ +id @morphology ]],
          363698007 |finding site| = [[ +id (<< |Body structure| MINUS << $findingSite2 ) @findingSite1 ]] },
                  { 116676008 |Associated morphology| = [[ +id @morphology ]],
          363698007 |finding site| = [[ +id (* MINUS << $findingSite1) @findingSite2 ]] }

      • Valid Expression (Definition of 16027391000119109 |Bone cyst of bilateral tibias (disorder)|)

        • 64572001 |Disease| :
                      { 116676008 |Associated morphology| = 66954000 |Bone cyst|,
                        363698007 |Finding site| = 719491009 |Bone structure of right tibia| }
                      { 116676008 |Associated morphology| = 66954000 |Bone cyst|,
                        363698007 |Finding site| = 719492002 |Bone structure of left tibia| }

    • Example B - A clinical finding, with one or more role groups in which the morphology is always the same, and no 2 finding sites subsume each other.

      • Template - 3 role groups with 3 sites: site[1], site[2], site [3] /// site [1,2]

        •  [[+id]]:
          [[1..* @group1]] { |Finding site| = [[ +id (* MINUS << $site[!= SELF ] ) @site ]] ,
          |Associated morphology| = [[ +id ($morphology [!= SELF] ) @morphology ]]}

      • Valid Expression (Definition of 31580001000004106 |Bilateral sacral insufficiency fracture (disorder)| )

          • 702561005 |Insufficiency fracture (disorder)|:
                       { 363698007 |Finding site (attribute)| = 736830008 |Bone structure of left half of sacrum (body structure)|,
                          116676008 |Associated morphology (attribute)| = 22640007 |Pathologic fracture (morphologic abnormality)| }
                        { 363698007 |Finding site (attribute)| = 736831007 |Bone structure of right half of sacrum (body structure)|,
                          116676008 |Associated morphology (attribute)| = 22640007 |Pathologic fracture (morphologic abnormality)| }

  2. Default value for replacement slot

    • Default value for authoring and template-driven modelling transformations

    • Example A - Default finding site of 72673000 |Bone structure|

      • Template

        • [[ + id ]] :
          { |Finding site| = [[ +id (<< 72673000|Bone structure|) @site default (72673000 |Bone structure (body structure)|) ]]

  3. Definition status of a replacement slot

    • Specifying whether the value used in a replacement slot must be primitive or defined

    • Example A - When proximal primitive modelling, the focus concept must be a primitive concept

      • Template - Requires use of more expressive query language with filters

        • [[ + id (<< 64572001 |Disease| {{ c.definitionStatus = primitive }}) ]]

      • Valid Expression

        • 195967001 |Asthma (disorder)|

  4. Definition status of a templated expression

    • Specifying the definition status of a templated expression

    • Template

      • [[ +tok ("===" "<<<") ]][[ +id ]] : { |Finding site| = [[+id]] }

      • Valid Expression

        • === 128272009 |Disorder of lower respiratory system| : 363698007 |Finding site| = 39607008 |Lung structure|

        • <<< 128272009 |Disorder of lower respiratory system| : 363698007 |Finding site| = 39607008 |Lung structure|

  5. Attributes used in repeating role groups

    • Constraining the set of attributes that appear in a repeating role group

    • Example 1 - In a given matching expression, either all the role groups include the attribute |site|, or none of the role groups include the attribute |site|. Similarly, either all role groups include |Occurrence|, or none of the role groups do.

      • Template - using allOrNone

        • [[+id]]: [[1..* @group1 allOrNone ($site), allOrNone($occurrence)]]
          { [[1..1]] |Associated morphology| = [[ +id @morphology ]],
          [[0..1 @site]] |Finding site| = [[ +id ]],
          [[0..1 @occurrence]] |Occurrence| = [[ +id ]] }

        • Valid Expression - Injury of head, neck and chest

          • [[ |Disease| ]]: 
            { |Associated morphology| = |Injury|, |Finding site| = |Head structure| } 
            { |Associated morphology| = |Injury|,  |Finding site| = |Neck structure| }
            { |Associated morphology| = |Injury|,  |Finding site| = |Chest structure| }

        • Valid Expression - Congenital malformation of head and neck 

          • [[ |Disease| ]]: 
            { |Associated morphology| = |malformation|, |Finding site| = |Head structure|, |Occurrence| = |Congenital| } 
            { |Associated morphology| = |malformation|,  |Finding site| = |Neck structure|, |Occurrence| = |Congenital| }

    • Example 2 - Some of the optional attributes must either always or never appear in each instance of a repeating role group

        • [[+id]]: [[1..* allOrNone($morph) ]]
          { [[ 1..1 ]] |Method| = [[+id]],
          [[ 0..1 @morph ]] |Direct morphology| = [[+id ]],
          [[ 0..1 ]] |Procedure site - Direct| = [[+id]],
          [[ 0..1]] |Using device| = [[+id]] ,
          [[ 0..1]] |Has intent| = [[+id]] }

        • Valid Expression - Closure of skin by suture

          • |Procedure|: 
            { |Method| = |Closure - action|, |Procedure site - Direct| = |Skin structure| , |Using device| = |Surgical suture, device|} 

        • Valid Expression - Core needle biopsy of skin using ultasonographic guidance

          • |Procedure|: 
            { |Method| = |Ultrasound imaging - action|, |Procedure site - Direct| = |Skin structure| , |Has intent| = |Guidance intent|} 
            { |Method| = |Biopsy - action|, |Procedure site - Direct| = |Skin structure| , |Using device| = |Core biopsy needle, device|} 

        • Valid Expression - Toilet and suture of wound

          • |Procedure|: 
            { |Method| = |Surgical toilet - action|, |Direct morphology| = |Wound| } 
            { |Method| = |Closure - action|,  |Direct morphology| = |Wound|,
            |Procedure site - Direct| = |Skin structure|, |Using device| = |Surgical suture, device| }

      • Example 3 - Some of the optional attributes must either always or never appear in each instance of an inner-nested, repeating role group

          • |Finding with explicit context|: [[1..2]]
            { [[ 1..1 ]] |Finding context| = [[+id]],
            [[ 1..1 ]] |Temporal context| = [[+id ]],
            [[ 1..1 ]] |Subject relationship context| = [[+id]],
            [[ 1..1]] |Associated finding| = ( [[+id]] : [[1..* allOrNone($site) allOrNone($Occurrence) ]]
            { [[1..1]] |Associated morphology| = [[ +id @morphology ]],
            [[0..1 @site]] |Finding site| = [[ +id ]],
            [[0..1 @occurrence]] |Occurrence| = [[ +id ]] } ) }

          • Valid Expression - History of Injury of head, neck and chest, and of congenital malformation of head and neck

            • |Finding with explicit context|:
              { |Finding context| = |Done|,
              |Temporal context| = |In the past|
              |Associated finding| = ( |Disease| : 
              { |Associated morphology| = |Injury|, |Finding site| = |Head structure| } 
              { |Associated morphology| = |Injury|,  |Finding site| = |Neck structure| }
              { |Associated morphology| = |Injury|,  |Finding site| = |Chest structure| } ) }
              { |Finding context| = |Done|,
              |Temporal context| = |In the past|,
              |Associated finding| = ( |Disease| :
              { |Associated morphology| = |malformation|, |Finding site| = |Head structure|, |Occurrence| = |Gongenital| } 
              { |Associated morphology| = |malformation|,  |Finding site| = |Neck structure|, |Occurrence| = |Gongenital| } ) }

      • Example 4 - Some of the optional attributes must either always or never appear in each instance of an outer-nested, repeating role group

          • |Finding with explicit context|: [[1..2 allOrNone ($site), allOrNone($occurrence), allOrNone($relationship) ]]
            { [[ 1..1 ]] |Finding context| = [[+id]],
            [[ 1..1 ]] |Temporal context| = [[+id ]],
            [[ 0..1 @relationship]] |Subject relationship context| = [[+id ]],
            [[ 1..1]] |Associated finding| = ( [[+id]] : [[1..* ]]
            { [[1..1]] |Associated morphology| = [[ +id ]],
            [[0..1 @site]] |Finding site| = [[ +id ]],
            [[0..1 @occurrence]] |Occurrence| = [[ +id ]] }

          • Valid Expression - History of Injury of head, neck and chest, and of malformation of head and neck

            • |Finding with explicit context|:
              { |Finding context| = |Done|,
              |Temporal context| = |In the past|,
              |Subject relationship context| = |Subject of record|,
              |Associated finding| = ( |Disease| : 
              { |Associated morphology| = |Injury|, |Finding site| = |Head structure| } 
              { |Associated morphology| = |Injury|,  |Finding site| = |Neck structure| }
              { |Associated morphology| = |Injury|,  |Finding site| = |Chest structure| } ) }
              { |Finding context| = |Done|,
              |Temporal context| = |In the past|,
              |Subject relationship context| = |Subject of record|,
              |Associated finding| = ( |Disease| :
              { |Associated morphology| = |malformation|, |Finding site| = |Head structure| } 
              { |Associated morphology| = |malformation|,  |Finding site| = |Neck structure| }

Introducing term searching to ECL

@Former user (Deleted)

Syntax

term  =  [lexicalSearchType ":"] String 

Lexical 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.*” }}

    • Question: Does the query suddenly become order dependent? Yes

  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 = “*heart*”, languageCode = "sv"}}

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

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

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| }}

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

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

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

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

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

  • 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

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

  • How does this relate to description templates? How does this relate to SNOSTORM implementation.

  • Packaging - Do we (over time) extend ECL with all the new Query Language features, and define a set of example ECL profiles - e.g. "Basic ECL", "ECL with basic term searching", "ECL with filters".

Executing maps

@Former user (Deleted)

Proposed extension to ECL 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|)

      • mapSource (|Anatomy structure and part association refset|, << |Liver part|)

    • 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 attributes

@michael 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

@Former user (Deleted)

  • Finalize and publish language and language instance URIs

Query Language
- Summary from previous meetings

 

 

 

@Former user (Deleted)

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

@Former user (Deleted)

  • Any other topics?

Confirm next meeting date/time

@Former user (Deleted)

The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 22nd May.

 

Comments

Copyright © 2026, SNOMED International