Welcome and agenda

All

• Next meeting - 7th April 2022?? 

  • Meeting next week to finalize ECL 2.0?

  • Consider changing regular meeting time?

ECL v2.0 - Access to refsets and historical supplements

All

Expression Constraint Language 2.0 WIP

Finalize feedback - Michael, B2i, Jeremy, Daniel

• Field Name from File: ^  447562003 |ICD-10 complex map reference set|  {{ M mapGroup = #2, mapPriority = #1, mapTarget = "J45.9" }}

  • Field names come directly from the international RF2 specification (if they're there), else directly from the RF2 files 

Please review updates to the following pages:

• 1. Introduction (History)

• 3.2 Expression Constraint and Query Requirements

• 4. Logical Model

• 4.1 Details

• 5.1 Brief Syntax (Normative)

• 5.2 Long Syntax (Informative)

• 5.3 Informative Comments

• 5.4 Order of Operation

• 6.1 Simple Expression Constraints (Member Of) **

• 6.8 Description Filters (Module, Effective Time, Active Filters)

• 6.10 Member Filters **

• 6.11 History Supplements

• Appendix D - ECL Quick Reference

ECL v2.1 - Requirement proposals

All

Potential requirements for ECL v2.1 - Discussion and brainstorming

• Daniel's comments

  • An explanation of the results of this ECL: <<766918008 |Product containing microbial agent (product)| MINUS (763158003 |Medicinal product (product)| :
    { 127489000 |Has active ingredient (attribute)| = 412232009 |Microbial agent (substance)| }) (right identities vs. ECL, has been raised before)

  • Cardinality of focus concepts is not supported (Example use case: which concepts have 2 or more stated IsAs)

  • (Related) Using 116680003 |Is a (attribute)| in refinement/dotted expressions, e.g. 395026007.116680003, 395026007:[2..*]116680003=*
    Snowstorm and Ontoserver give different results for dotted expressions.
    https://snowstorm-alpha.ihtsdotools.org/snowstorm/snomed-ct/fhir/ValueSet/$expand?_format=json&count=10&url=http:%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Decl%2F395026007.116680003
    https://r4.ontoserver.csiro.au/fhir/ValueSet/$expand?_format=json&count=10&url=http:%2F%2Fsnomed.info%2Fsct%3Ffhir_vs%3Decl%2F395026007.116680003

  • We've done history for concepts but not for any other components...

    Realizing the information on inactive concepts is different and more extensive from other components, {{ + HISTORY... }} is (just) sugar and maybe just maybe there might be reasons to sprinkle other components with this sweetness (or not).

    Examples: previously active refset members (and their fields), previously active descriptions (e.g. Refers to association refset), ...

• Context supplements - e.g.

  • << 56265001 |Heart disease|  {{ + CONTEXT }} – probably exclude due to risk of absent finding, not-done procedure and family history

    • OR {{ + CONTEXT-DEFAULT }} ?

    • Expansion of [[@ecl_query]]{{ + Context (Temporal = [[ @temporal_value]]}}

      • [[ @ecl_query ]] OR  (< 243796009 |Situation with explicit context|:
                { ( 246090004 |Associated finding| = ( [[ @ecl_query ]] ) 
                       OR |Associated procedure| = ( [[ @ecl_query ]] )

      •             ( |Procedure context| = |Done| OR |Finding context| = |Known present|),
                    |Subject relationship context| = |Subject of record|,
                     |Temporal context| = [[ @temporal_value ]] } )

    • Example 1: << |Heart procedure| {{ + Context (Temporal = *) }}

      • <<  |Heart procedure| OR  (< 243796009 |Situation with explicit context|:
                { 246090004 |Associated finding| = << 56265001 |Heart disease|,
                    |Procedure context| = |Done|,
                    |Subject relationship context| = |Subject of record|,
                     |Temporal context| = * } )

      • Example 2: (<< |Heart disease| OR << |Heart procedure| ) {{ + Context (Temporal = *) }}

        • <<  |Heart procedure| OR  (< 243796009 |Situation with explicit context|:
                  { ( 246090004 |Associated finding| = (<< |Heart disease| OR << |Heart procedure| ) 
                         OR |Associated procedure| = ( << |Heart disease| OR << |Heart procedure| ) )
                      ( |Procedure context| = |Done| OR |Finding context| = |Known present|),
                      |Subject relationship context| = |Subject of record|,
                       |Temporal context| = * } )

    • << 56265001 |Heart disease| {{ + Context (Temporal = *, FindingContext=<<|Known present| }}

      • Will return all types of heart disease, plus concepts like 394886001 |Suspected heart disease (situation)|, and 429007001 |History of cardiac arrest (situation)|

      • Expands to: 

        • << 56265001 |Heart disease| OR
            (< 243796009 |Situation with explicit context|:
                  { 246090004 |Associated finding| = << 56265001 |Heart disease| } )

  • However, you may want to exclude (or include) specific contexts - for example:

    1. To ensure that the finding was about the subject of the record (and not a family history, e.g. to exclude 429959009 |Family history of heart failure (situation)|), you could say:

       • << 56265001 |Heart disease|  {{ + CONTEXT (relationship = 410604004 |Subject of record| }}

    2. To ensure that the finding was 'Known present' (e.g. to exclude 394926003 |Heart disease excluded (situation)|), you could say:

       • << 56265001 |Heart disease|  {{ + CONTEXT (finding_context = << 410515003 |Known present| }}

    3. To ensure that the finding was about the subject of the record AND known present, you could say:

       • << 56265001 |Heart disease|  {{ + CONTEXT (relationship = 410604004 |Subject of record|, 
                                                                                                   finding_context = << 410515003 |Known present| }}

    4. ?? Is there any use case for restricting adding temporal context? (e.g. temporal != << 410513005 |In the past|)

  • Is any more syntactic sugar required? E.g.

    • {{ + CONTEXT (relationship = self, finding context = present, temporal != past) }}

    • {{ + CONTEXT (self, present, ! past) }}

  • Other ideas? Common profiles?

• --------------------------

• Ability to return attribute types (see proposal below)

  • [ attributes ] << 125605004 |Fracture of bone (disorder)|

  • << 125605004 |Fracture of bone (disorder)| . Attributes

  • << 125605004 |Fracture of bone (disorder)| . (<< 125605004 |Fracture of bone (disorder)| . Attributes )

  • [ attribute, value] << 125605004 |Fracture of bone (disorder)|

• -------------------------

• Reverse membership (see below)

  • Which reference sets "contain" the given concept(s) - e.g. 421235005 |Structure of femur|?

    • 421235005 |Structure of femur| . Refsets

    • 421235005 |Structure of femur|. Refsets [ referencedComponentId ]

    • 421235005 |Structure of femur| . Refsets [ targetComponentId ]

• --------------------------

• Other?

Returning Attributes

@michael lawley

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

Reverse Member Of

@michael lawley

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

The items below are currently on hold

Postcoordination Topics

• 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

Dynamic Templates

• 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

Postcoordination Use Case Examples

All

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)

Postcoordination Guidance

@Former user (Deleted) , @Anne Randorff Højen , @Kai Kewley

Practical Guide to Postcoordination

• Proposal - Use syntax (i.e. braces) to distinguish refinement vs new role group

  • There should be a syntactic distinction between refinement and constructive addition (ie adding a new role group). That is:

    1. 83152002 |Oophorectomy| :  405815000 |Procedure device|  =  122456005 |Laser device|

       • is classified as (i.e. the refinement is added to the role groups in the definition of the focus concept(s)):

         • 83152002 |Oophorectomy| :  
           { 260686004 |Method| = 129304002 |Excision - action|,
              405813007 |Procedure site - Direct| = 15497006 |Ovarian structure|,
              405815000 |Procedure device|  =  122456005 |Laser device| }

    2. 83152002 |Oophorectomy| :  { 405815000 |Procedure device|  =  122456005 |Laser device| }

       • is classified as:

         • 83152002 |Oophorectomy| :  
           { 260686004 |Method| = 129304002 |Excision - action|,
              405813007 |Procedure site - Direct| = 15497006 |Ovarian structure|},
           {  405815000 |Procedure device|  =  122456005 |Laser device| }

  • However, for attributes which are always self-grouped - i.e. Priority, Due to, After, Before, During, Clinical course, Temporally related to, and all Observable entity attributes (see Relationship Group), these must always be put into their own role group:

    1. 125605004 | Fracture of bone |: 42752001 | Due to (attribute) | = 1912002 | Fall |

       •  is classified as:

         • 125605004 | Fracture of bone |: { 42752001 | Due to (attribute) | = 1912002 | Fall | }

         • or

         • 125605004 | Fracture of bone |: 
           { 363698007 |Finding site| = 272673000 |Bone structure|,
             116676008 |Associated morphology | = 72704001 |Fracture| }
           { 42752001 | Due to (attribute) | = 1912002 | Fall | }

• Proposal: Expression forms needed for this (see 3.4 Transforming Expressions)

  • Close to user form - e.g. 83152002 |Oophorectomy| :  405815000 |Procedure device|  =  122456005 |Laser device|