Page tree

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

Compare with Current View Page History

« Previous Version 4 Current »

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
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| = *)
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 (using #same or #allOrNone):
    • [[+id]]: [[1..* @group1]]
      { [[0..1 #same in group1]] |finding site| = [[+id]],
      [[0..1 #same in group1]] |associated morphology| = [[+id]],
      [[0..1]] |pathological process| = [[+id]] }

    •   [[+id]]: [[1..* @group1]]
      { [[1..1]] |Associated morphology| = [[ +id @morphology ]],
      [[0..1 #allOrNone in group1]] |Finding site| = [[ +id @site]],
      [[0..1 #allOrNone in gropu1]] |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| }

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