All

Update on our suggestion "that a Map should be included in the LOINC extension, in addition to alt identifiers. This will enable terminology servers to translate back and forth between LOINC and SNOMED CT codes in the existing standard way."

Previously we added the following warning in the ECL guide in the alternate identifiers section:

• ECL is always evaluated against SNOMED CT concepts. When you run a query using alternate identifiers from another code system only concepts that are in the SNOMED CT representation of that other code system will be returned. For example the descendants of a concept in the SNOMED CT version of a code system is likely to be different from the code system of the alternate identifier.

Kai

Suggestion from Martin Gall (EMIS Health) https://github.com/IHTSDO/snomed-expression-constraint-language/issues/6

Answer - all known TS implementations call Antlr in a way that doesn't require EOF.

Jeremy Rogers 

Testing consistency between Snowray (Snow Owl), Ontoserver, Snowstorm. Also using custom made NHS Subset maintenance tool, would like to migrate to a standardised solution.

Questions:

• Should inactive concepts be routinely suppressed from all results?
  • Answer: Inactive concepts should not be included when using hierarchy constraints, because they are not part of the hierarchy. They should be included when using wildcard. The default substrate includes inactive. Same in FHIR. All agree.
  • Action: Check the spec makes this clear. "Default substrate".
  • Known tooling issues: Snowstorm is not behaving well. e.g. ^ xxx AND YYY (where YYY is inactive). Check both native and FHIR API.
    
    
• Should inactive concepts be returned as active members of a simple refset?
  • Yes - they are active members - all agree
  • Snowstorm issues - seek example
    
    
• Are text definitions and FSNs routinely in scope of any description filters?
  • Text definitions should be left out?
    • Action: check the specification to exclude them by default
    • (FHIR should also exclude these when using "filter" parameter)
  • FSN 
    • KK: The FSN can be unique and help find relevant concepts, the PT should be presented
    • JR: The semantic tag can get in the way - 
    • We don't agree on this
    • Action: Let's add more examples around this.
      
      
• Do description filters run by default over inactive descriptions?
  • Inactive are excluded by default in the spec, however there is no way to search active and inactive at once
    • Action: Update ECL Spec to allow searching over active and inactive (apply everywhere, concept, description, members)
  • Snow Owl searches active and inactive descriptions by default
    
    
• Is a “pending move (concept)” description active or inactive?
  • JR: Let's skip this for today. It means the concept is about to be moved to another Edition.
    
    
• Are the match and wild description filters case sensitive or not (or, in the case of Ontoserver, do they even work at all?)
  • Group recommends case insensitive matching for "match"
  • Action: Update the ECL guide with this recommendation.
  • Group does not agree about "wild" case sensitivity.
    • Action: Discuss option of adding a modifier to specify case sensitivity - make sure we include Daniel
      
  • Action: Consider adding ECL regex filter.
    
    

• There are also some interesting edge case differences in the ability of each server to process ECL match description filters if they contain various symbol characters, such as *^% and so on.

  • Action: Discuss updating the ECL spec to add escape character for matching double quotes.
  • MC: Implementation Note - ECL filters commonly include double quotes - when including these in FHIR ValueSet requests make sure they are escaped. Action: Add to ECL Guide and any Snomed FHIR IG.
  • Other characters are perhaps an edge case.
  • More testing needed against know TS.

ML: Some observations: it is interesting to see the number of examples that are querying against terms – the results are not surprising since 1., this is a relatively new part of the spec, and 2., it steps outside the original conception of ECL as a query language that only used defining aspects of concepts as supported by the Concept and Relationship tables.

All

Discussion:

How to make it easier to add an ECL capability to more tooling?

• SI already has open source implementations
• The specification is now very large. An ECL Lite profile would reduce the months of effort required to implement the whole specification when starting fresh.

ECL Lite - MVP Scope:

• *, <, <<, >, >>, <!, !>, ^, AND, OR, MINUS, (), {{ +HISTORY-(MIN,MOD,MAX) }}
• Maybe? {{ C active }}