Welcome and agenda

All

ECL Design:
Enable support for LOINC codes and other alternate identifiers in ECL

All

• We have been asked to consider how LOINC codes (and other alternate identifiers) could be used in ECL to support the Regenstrief collaboration.

• How can LOINC codes be used in the SNOMED ECL language to select these concepts?
  
  
  

• LOINC concepts with LOINC codes are being created in a new LOINC SNOMED-CT extension.
  The LOINC codes will be stored in the redesigned Alternate Identifier file. The concepts will also have a SNOMED CT concept identifier.

• Example LOINC codes are available in the LOINC FHIR concept map - https://fhir.loinc.org/ConceptMap/?url=http://loinc.org/cm/loinc-parts-to-snomed-ct

  • LOINC code "LP14536-4" 
    
    

• Discuss: 

  • Example Identifier Scheme:

    • Concept Id: 705114005 |LOINC Code System (qualifier value)|

    • URI: "http://loinc.org/"

      • Second URI annotation with a resolvable URL?

    • Alias: "LOINC"

      • Whatever alias is used it should included as an annotation on the concept that represents the code system 

      • Considering seeding aliases with existing UMLS short codes

        • ML: May not be unambiguous 

        • US based system.

  • Possible examples:

    • A. LOINC:"LP14536-4" |Glucose level|

      • Example use: < LOINC:"LP14536-4"

    • B. "LOINC:LP14536-4" |Glucose level|

    • C. "LOINC#LP838383" |Glucose level|

  • Chosen syntax is C: 

    • "LOINC#LP838383" |Glucose level|

    • C1: "LOINC#*"

      • This could match anything in the substrate that has an identifier in the LOINC scheme.

    • Aliases can not have spaces. This seems okay, use a dash instead where needed. 

    • Allow these alternate identifiers in any place that a concept id can be used

    • Examples:

      •  

        • << "LOINC#LP838383" |Glucose level|

    • Could quoting be optional? Only when necessary?

    • Should we be able to request a preference for the identifier scheme used in the response?

ECL v2.2 Proposal

Support translation of data into a subset like GPS

All

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

• Syntax Options:

  • 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 we can think of

    • Examples needed

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

The items below are currently on hold

URIs for language instances

ON HOLD

ECL v2.1 - Requirement proposals (to be archived)

All

ON HOLD -

Potential requirements for ECL v2.1 - Discussion and brainstorming

• Daniel's comments

  • An explanation of the results of this ECL: <<385540001 |Olmesartan containing drug| MINUS (<<763158003 |Medicinal product (product)|: { <<127489000 |Active ingredient| = <<412259001 |Olmesartan| })

  • 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 }} – This syntax is too general, as there is a risk of including absent finding, not-done procedure and family history

  • << 56265001 |Heart disease| {{ + CONTEXT-DEFAULT }} ? – What would this mean?

  •  

    • Brief form:

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

    • Expanded form:

      • [[ @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

ON HOLD -

• 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

ON HOLD -

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

Dynamic Templates

• ON HOLD -

• 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

URIs for Extended Editions

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)