Welcome and agenda

ECL v2.2 Proposal

Support translation of data into a subset like GPS

• Support the conversion of codes between Full SNOMED and GPS (highest and lowest match). Syntactic sugar to make it easy?

Find the leaves of a set of concepts - example use case (find the proximal set in the international core / or in the IPS) - example:

• Example use cases
  • Proximal ancestors in a specific module: (  >> |concept| 

Find the leaves of a set of concepts - example use case (find the proximal set in the international core / or in the IPS) - example:

• Example use cases
  • Proximal ancestors in a specific module: (  > |concept|  {{ C moduleId = 1234 }} ) MINUS ( > (> |concept| {{ moduleId = 1234 }}) )
    • X =   "> |concept| {{ C moduleId = 1234 }}"
  • Leaf nodes:   < |concept| MINUS (> (< |concept|))
    • X =  " < |concept| "
  • Removing any redundant concepts (ie subsumes another concept) from a set of concepts
    • ^ |ref set| MINUS (> (^ |ref set|)
      • X = " ^ |ref set| "

Find the root concepts of a set of concepts - example use case (find the proximal set in the international core / or in the IPS) - example:

• • Example use cases for 
    • Root nodes of an extension module:   (< |concept| {{ module = X}}) MINUS (< (< |concept| {{ module = X}}))
      • X =  " < |concept| "
    • Only the 'root' concepts from a set of concepts
      • ^ |ref set| MINUS (< (^ |ref set|)
        • X = " ^ |ref set| "
• X MINUS (> X)
• HOMEWORK - Suggest some syntax for this.
  • leaves(X) - egleaves (> |concept| {{ C moduleId = 1234 }} ) leaves (< MINUS ( > (>> |concept| )
  • leaves (^ |refset|)
  • Pros: Easy to read
  • Cons: More consistent with the long form of ECL rather than the short form
  {{ moduleId = 1234 }}) )
  • X =   "
  L(X)    - eg
  • L (> |concept| {{ C moduleId = 1234 }} )L (< "
  • Leaf nodes:   < |concept| )L (^ |refsetMINUS (> (< |concept|)
  • Pros: Easy to type
  • Cons: L could mean anything? English specific.
  • _ (X)   - eg
    • _ (> |concept| {{ C moduleId = 1234 }} )
    • _ ( < |concept|)
    • _ (^ |refset|)
  • !_
    • Pros: Looks like lowest / floor
    • Cons: No equivalent highest / top symbol
  • !<
    • Pros: Easy to type. Familiar looking syntax.
    • Cons: May be too similar to children of - confusing?
  • !!< (bottom) !!> (top)
    • Pros: Easy to type. Familiar syntax. Different enough from <! and >!
    • Cons: None that I can think of
  • ⌊ X ⌋  (bottom),  ⌈ X ⌉  (top)
    • Pros: Matches existing mathematical syntax for the Floor and Ceiling functions, which have similar meaning.
    • Cons: Could be challenging for some people to type on the keyboard
  • <!!  (bottom),  >!!  (top)
    • Pros: Easy to type. Familiar looking syntax. Won't be mistaken for children of. Both top and bottom can be represented clearly.
    • Cons: Too long? (Makes operators three characters rather than two).
  • )
    • X =  " < |concept| "
  • Removing any redundant concepts (ie subsumes another concept) from a set of concepts
    • ^ |ref set| MINUS (> (^ |ref set|)
      • X = " ^ |ref set| "

Find the root concepts of a set of concepts - example use case (find the proximal set in the international core / or in the IPS) - example:

• • Example use cases for 
    • Root nodes of an extension module:   (< |concept| {{ module = X}}) MINUS (< (< |concept| {{ module = X}}))
      • X =  " < |concept| "
    • Only the 'root' concepts from a set of concepts
      • ^ |ref set| MINUS (< (^ |ref set|)
        • X = " ^ |ref set| "
• X MINUS (> X)
• HOMEWORK - Suggest some syntax for this.
  • leaves(X) - eg
    • leaves (> |concept| {{ C moduleId = 1234 }} )
    • leaves (< |concept|)
    • leaves (^ |refset|)
    • Pros: Easy to read
    • Cons: More consistent with the long form of ECL rather than the short form
  • L(X)    - eg
    • L (> |concept| {{ C moduleId = 1234 }} )
    • L (< |concept|)
    • L (^ |refset|)
    • Pros: Easy to type
    • Cons: L could mean anything? English specific.
  • _ (X)   - eg
    • _ (> |concept| {{ C moduleId = 1234 }} )
    • _ ( < |concept|)
    • _ (^ |refset|)
  • !_
    • Pros: Looks like lowest / floor
    • Cons: No equivalent highest / top symbol
  • !<
    • Pros: Easy to type. Familiar looking syntax.
    • Cons: May be too similar to children of - confusing?
  • Most preferred version at April Business Meeting:
  • !!< (bottom)
  • !!> (top)
    • Pros: Easy to type. Familiar syntax. Different enough from <! and >!
    • Cons: None that I can think of
    • Examples needed - show again next time
  • ⌊ X ⌋  (bottom),  ⌈ X ⌉  (top)
    • Pros: Matches existing mathematical syntax for the Floor and Ceiling functions, which have similar meaning.
    • Cons: Could be challenging for some people to type on the keyboard
  • <!!  (bottom),  >!!  (top)
    • Pros: Easy to type. Familiar looking syntax. Won't be mistaken for children of. Both top and bottom can be represented clearly.
    • Cons: Too long? (Makes operators three characters rather than two).

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

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

• Discuss feedback on transformation implementation
  • Resources
    • Expression transformation service generates the classifiable form and the necessary normal form from a close to user form expression
    • Contribute your expression examples and write your feedback for consideration and discussion
  • Recap of SNOMED on FHIR discussions
    • What is the functionality scope of a terminology server that supports postcoordination? For example, does it include:
      • Classifying multiple expressions in a single substrate? What are the use cases for this?
      • Assigning (local) identifiers to expressions? What are the use cases for this?
      • Autogenerating or assigning a term to an expression? What are the use cases for this?
    • Does a terminology server that supports postcoordination, include all the functions of an expression repository?
    • What is the relationship between a terminology server that supports postcoordination, and an expression repository?
  • Outstanding questions
    • What are the pros and cons of extending SCG to allow an expression as the focus of a postcoordinated expression?
      • Note: This was raised in context of a NNF generated over a postcoordinated substrate, where the proximal parent is an expression
  • • Example of using expressions in focus concept
      • ( 125605004 |Fracture of bone|:363698007 |finding site| = 84167007 |Foot bone| ) : 
        272741003 |Laterality| = 7771000 |Left|
      • 125605004 |Fracture of bone|:363698007 |finding site| = 84167007 |Foot bone| , 
        272741003 |Laterality| = 7771000 |Left|
    • What is the expected NNF when classifying an expression that is equivalent to a precoordinated concept? For example:
      • Expression that is equivalent to 111273006 |Acute respiratory disease|
      • 64572001 | Disease (disorder) | :
        {263502005 |Clinical course (attribute)| = 424124008 |Sudden onset AND/OR short duration (qualifier value)|}
        {363698007 |Finding site (attribute)| = 89187006 |Airway structure (body structure)|}
      • Options:
        1. 111273006 |Acute respiratory disease| :
           {263502005 |Clinical course| = 424124008 |Sudden onset AND/OR short duration|}
           {363698007 |Finding site| = 89187006 |Airway structure|}
        2. 50043002 |Disorder of respiratory system (disorder)| +
           2704003 |Acute disease (disorder)| :
           {263502005 |Clinical course| = 424124008 |Sudden onset AND/OR short duration|}
           {363698007 |Finding site| = 89187006 |Airway structure|}
        3. Other?
  • Recap of internal discussions with Content Team
    • Inter-attribute dependencies
    • Grouping rules

• Continue discussion on dynamic templates
• Inter-attribute dependencies
  
  • Acute/Chronic and Inflammation - Adding a clinical course requires specializing the inflammation morphology 
    • E.g. |Pyelonephritis| : |Clinical course| = |Chronic|
      should be
      |Pyelonephritis| : |Clinical course| = |Chronic|, |Associated morphology| = |Chronic inflammation|
    • E.g. |Pyelonephritis| : |Clinical course| = |Sudden onset AND/OR short duration|
      should be
      |Pyelonephritis| : {|Clinical course| = |Sudden onset AND/OR short duration||, |Associated morphology| = |Acute inflammation|
  • Infectious Causative Agents - Adding a |causative agent| = |Domain Bacteria| or |Virus| requires adding a |Pathological process| = |Infectious process|
    • E.g. |Nephritis|: |Causative agent| = |Domain bacteria|
      should be
      |Nephritis|: |Causative agent| = |Domain bacteria|, |Pathological process| = |Infectious process|
  • Congenital and Acquired - Adding an |Occurrence| of |Congenital| to a focus concept with an abnormal morphology, requires adding a |Pathological process| of |Pathological development process|
    • E.g. |Koilonychia|: |Occurrence| = |Congenital|
      should be
      |Koilonychia|: |Occurrence| = |Congenital|, |Pathological process| = |Pathological developmental process|
  • Situations with Explicit Context 
1. if the procedure context = |Planned|, then the temporal context should be << |Current of specified time|
   1. If the procedure context = |In progress|, then the temporal context should be << |Current|
   2. If the procedure context = |Performed| or |Done|, then the temporal context should be << |Current or past (actual)|
• Note: for this use case (of |Procedure with explicit context|) perhaps we just recommend (or require) that the full role group is spelled out.
• Next steps
  • Representation of the content rules
    • Who creates the complete list of rules and how?
      • What formalism?
      • Determine which are mandatory and which are optional
    • Implementation of content rules - e.g.
      • Guided data entry by pre-populating role groups in expression template based on definition of focus concepts (for design-time use, such as mapping)
      • Mandatory content rules could be added to transform process

Example 1 - Dentistry / Odontogram

• Requires an expression template to create expressions.
• Resulting expression still requires a transformation to make it classifiable

Example 2 - Terminology binding

• Uses a fixed expression template to combine codes entered into separate fields
• The procedure+laterality example still requires a transformation to make it classifiable

Example 3 - Mapping

• Design-time activity
• Map targets may not be able to be fully represented using concept model attributes
• In many cases, an extension (with primitive concepts) should be recommended where there are gaps in the mapping
• There may be some cases in which postcoordination is helpful (e.g. LOINC to SNOMED CT map)

Example 4 - Natural Language Processing

• Usually run-time activity.
• May require manual confirmation of coding suggestions (unless low clinical risk, eg for suggesting relevant patient records for manual review)

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

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

• Continue discussion on dynamic templates
• Inter-attribute dependencies
  
  • Acute/Chronic and Inflammation - Adding a clinical course requires specializing the inflammation morphology 
    • E.g. |Pyelonephritis| : |Clinical course| = |Chronic|
      should be
      |Pyelonephritis| : |Clinical course| = |Chronic|, |Associated morphology| = |Chronic inflammation|
    • E.g. |Pyelonephritis| : |Clinical course| = |Sudden onset AND/OR short duration|
      should be
      |Pyelonephritis| : {|Clinical course| = |Sudden onset AND/OR short duration||, |Associated morphology| = |Acute inflammation|
  • Infectious Causative Agents - Adding a |causative agent| = |Domain Bacteria| or |Virus| requires adding a |Pathological process| = |Infectious process|
    • E.g. |Nephritis|: |Causative agent| = |Domain bacteria|
      should be
      |Nephritis|: |Causative agent| = |Domain bacteria|, |Pathological process| = |Infectious process|
  • Congenital and Acquired - Adding an |Occurrence| of |Congenital| to a focus concept with an abnormal morphology, requires adding a |Pathological process| of |Pathological development process|
    • E.g. |Koilonychia|: |Occurrence| = |Congenital|
      should be
      |Koilonychia|: |Occurrence| = |Congenital|, |Pathological process| = |Pathological developmental process|
  • Situations with Explicit Context 
1. if the procedure context = |Planned|, then the temporal context should be << |Current of specified time|
   1. If the procedure context = |In progress|, then the temporal context should be << |Current|
   2. If the procedure context = |Performed| or |Done|, then the temporal context should be << |Current or past (actual)|
• Note: for this use case (of |Procedure with explicit context|) perhaps we just recommend (or require) that the full role group is spelled out.
• Next steps
  • Representation of the content rules
    • Who creates the complete list of rules and how?
      • What formalism?
      • Determine which are mandatory and which are optional
    • Implementation of content rules - e.g.
      • Guided data entry by pre-populating role groups in expression template based on definition of focus concepts (for design-time use, such as mapping)
      • Mandatory content rules could be added to transform process

ON HOLD - How to refer to an 'extended edition' using a URI - e.g. "International Edition plus the following 2 nursing modules: 733983009  |IHTSDO Nursing Health Issues module|and 733984003 |IHTSDO Nursing Activities module|

Use Case - Need to execute an ECL, that refers to "^ 733991000 | Nursing Health Issues Reference Set (foundation metadata concept) |" and/or "^ 733990004 | Nursing Activities Reference Set (foundation metadata concept) |", where the substrate includes the international edition, plus the modules that include these reference sets

July 2020 International Edition URI: http://snomed.info/sct/900000000000207008/version/20200731

July 2020 International Edition + nursing modules URI ?? - For example:

• http://snomed.info/sct/900000000000207008/version/20200731/module/733983009/time/20200131/module/733984003/time/20200131
  
• http://snomed.info/sct/900000000000207008/version/20200731/modules/733983009:733984003
  
• http://snomed.info/sct/900000000000207008:733983009:733984003/version/20200731:20190731:20200131
  
• Canonical order? Or order doesn't matter?
• Constraints on what can go in the additional packages (only refsets and their metadata)

ON HOLD - How to refer to an 'extended edition' using a URI - e.g. "International Edition plus the following 2 nursing modules: 733983009  |IHTSDO Nursing Health Issues module|and 733984003 |IHTSDO Nursing Activities module|

Use Case - Need to execute an ECL, that refers to "^ 733991000 | Nursing Health Issues Reference Set (foundation metadata concept) |" and/or "^ 733990004 | Nursing Activities Reference Set (foundation metadata concept) |", where the substrate includes the international edition, plus the modules that include these reference sets

July 2020 International Edition URI: http://snomed.info/sct/900000000000207008/version/20200731

July 2020 International Edition + nursing modules URI ?? - For example:

• http://snomed.info/sct/900000000000207008/version/20200731/module/733983009/time/20200131/module/733984003/time/20200131
  
• http://snomed.info/sct/900000000000207008/version/20200731/modules/733983009:733984003
  
• http://snomed.info/sct/900000000000207008:733983009:733984003/version/20200731:20190731:20200131
  
• Canonical order? Or order doesn't matter?
• Constraints on what can go in the additional packages (only refsets and their metadata)

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