Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Date & Time

20:00 UTC Wednesday 27th February 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 new ECL language features (including historical associations)
  • Proposed enhancements to template language

Attendees 

Apologies

  •  

Agenda and Meeting Notes

Description
Owner
Notes

Welcome and apologies


Actions from last week
ECL - Executing maps

Proposed extension to ECL to support the execution of maps (focusing on the resolution of historical refsets)

  • The specific use-case here comes initially from Jeremy and relates to being able to work with inactive concepts via the historical association maps. For example, given an ECL expression that identifies a set of concepts 'c' to be used for retrieving patient records, you probably also want to retrieve records for sameAs (c) and replacedWith (c)
    • Example:
      • (< 72704001 |Fracture| AND ^ 900000000000527005 |SAME AS association reference set|) . 900000000000533001 |Association target component|
      • (900000000000527005 |SAME AS association reference set| . 900000000000533001 |Association target component| ): |Referenced component| = < |Fracture|
      • Michael's existing approach: mapsTo(|SAME AS|, < |Fracture|)
Or mappedTo(…)
mappedFrom(|SAME AS|, |inactive concept|)
mappedFrom(|REPLACED BY|, |inactive concept|)

      • Alternative suggestion: Use the substrate to include historical snapshots.
        • E.g. Historical and current concepts that are fractures and have an associated morphology, but not historical morphologies
        • ( < |Fracture of bone| {{ substrate >= http://snomed.info/sct/900000000000207008/version/20140131 ) AND (* : |Associated morphology| = *)
ECL - 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|)
Template SyntaxLinda Bird

New requirements

  • 2 slots must have the same/different or subsumed/not-subsumed values - for example, same morphology, finding sites not subsume each other:
    •  [[ +id ]]: { 116676008 |Associated morphology| = [[ +id @morphology ]], 363698007 |finding site| = [[ +id @findingSite1 != << $findingSite2]] },
                       { 116676008 |Associated morphology| = [[ +id @morphology ]], 363698007 |finding site| = [[ +id @findingSite2 != << $findingSite1]] }

    •  [[+id]]: [[1..*]] { |Associated morphology| = [[ +id @morphology ]], |Finding site| = [[ +id @site[n] != <<$site[!n] ]] }
    • Example - 208510002 |Multiple fracture of clavicle, scapula and humerus (disorder)|
  • Default value for slots - for example:
    • [[ + id ]] : { |Finding site| = [[ +id @site default = 272673000 |Bone structure (body structure)| ]]
  • Specifying the definition status of a slot - for example (proximal primitive modelling):
    • [[ + << 64572001 |Disease| {{ c.definitionStatus = primitive }} ]]
  • Specifying the definition status of an expression - for example
    • [[ +tok ]] [[ +id ]] : { |Finding site| = [[+id]] }
    • [[ +tok ("===" "<<<") ]] [[ +id ]] : { |Finding site| = [[+id]] }
    • [[ +tok (< |Definition status|) ]] [[ +id ]] : { |Finding site| = [[+id]] }
  • Repeating role groups must have the same set of attributes (with respect to optional attributes) - for example:
    •   [[+id]]: [[1..* @rolegroup]] { [[1..1]] |Associated morphology| = [[ +id @morphology ]],
      [[0..1 @morph]] |Finding site| = [[ +id @site]],
      [[0..1]] |Occurrence| = [[ +id @occurrence ]] }

      Instance 1: Injury of head, neck and chest

      [[ |Disease| ]]: 
      [ @rolegroup[1] ] { |Associated morphology| = |Injury|, |Finding site| = |Head structure| } 
      [ @rolegroup[2] ] { |Associated morphology| = |Injury|,  |Finding site| = |Neck structure| }
      [ @rolegroup[3] ]{ |Associated morphology| = |Injury|,  |Finding site| = |Chest structure| }
        
      Instance 2: Congenital malformation of head and neck 
      [[ |Disease| ]]: 
      [ @rolegroup[1] ] { |Associated morphology| = |malformation|, |Finding site| = |Head structure|, |Occurrence| = |Gongenital| } 
      [ @rolegroup[2] ] { |Associated morphology| = |malformation|,  |Finding site| = |Neck structure|, |Occurrence| = |Gongenital| }

    • [[ +id ]]: [[1..* @rolegroup]]
      { [[0..1 #allOrNone in @rolegroup)]] |finding site| = [[ +id ]],
      [[0..1 #allOrNone in @rolegroup]] |associated morphology| = [[ +id ]],
      [[0..1 #allOrNone in @rolegroup]] |pathological process| = [[ +id ]] }

    • [[ +id ]]: [[1..1 @rolegroup1]]
      { [[0..1 @fs1 #allOrNone fs1+fs2]] |finding site| = [[ +id ]],
      [[0..1 @am1 #allOrNone am1+am2]] |associated morphology| = [[ +id ]],
      [[0..1 @pp1 #allOrNone pp1+pp2 ]] |pathological process| = [[ +id ]] }
      [[1..1 @rolegroup2]] { [[0..1 @fs2 #allOrNone fs1+fs2]] |finding site| = [[ +id ]],
      [[0..1 @am2 #allOrNone am1+am2]] |associated morphology| = [[ +id ]],
      [[0..1 @pp2 #allOrNone pp1+pp2]] |pathological process| = [[ +id ]] }
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

The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 6th February.

No files shared here yet.


  • No labels