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.
  • Chosen syntax: 
    • "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?

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?