Unknown User (mgall) from EMIS is seeking guidance on best practises for ECL maintenance.

Jeremy Rogers generously volunteered to draft some broad points for a new section of the ECL guide on this topic.

Kai Kewley 

ECL 2.2 has been published

• In the ECL Guide: http://snomed.org/ecl
• and official GitHub repository: https://github.com/IHTSDO/snomed-expression-constraint-language

All

Latest: Terminology Management Group on Saturday (pre-expo) - SNOMED International agreed to publish a URI to access alternate identifier maps via the FHIR API. 

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.

Michael Lawley 

Requirement

Requirement to select a substance or a modification of that substance .... use case: during authoring to prompt the user with all the active ingredient options. Clinician chooses a drug and wants to refine the selection using modification-of substances. 

Background

The modification-of attribute is a transitive property in OWL. Transitive properties have a similar characteristic to an is-a relationships but without stating a subtype relationship.

In SNOMED CT an OWL property chains are used to help organise the hierarchy, allowing products with modified substance to be subsumed into concept groupers defined using the base substance. However in this case the base substance should not be inherited into the product with the modified substance. The base (not modified) version of the substance is found as redundant and removed during NNF calculation. See OWL Guide: 2.5. Generating Necessary Normal Form Relationships from the OWL Refsets

Example property chain: "|Has active ingredient| o |Is modification of|" is a sub-property of  "|Has active ingredient|".

Example hierarchy:

Parent

Child

Because

And Property Chain:

SubObjectPropertyOf(
	ObjectPropertyChain(
		:127489000 |Has active ingredient (attribute)|
		:738774007 |Is modification of (attribute)|
	)
	:127489000 |Has active ingredient (attribute)|
)

.. which results in OWL seeing the non modified ingredient as a property of the concept for the purpose of subsumption.

Finally

TransitiveObjectProperty(:738774007 |Is modification of (attribute)|)

This could be used by the ECL engines.

Solution Options:

• ECL Solution: << 372687004 |Amoxicillin (substance)| 
    OR ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = << 372687004 |Amoxicillin (substance)| )
    OR ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = << 372687004 |Amoxicillin (substance)| ) )
    OR ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = << 372687004 |Amoxicillin (substance)| ) ) )
    )
  • Pros: Already works, if you know the maximum number of transitive hops
  • Cons: It's not pretty. It may work for modification-of but may not work for longer transitive chains like part-of (body structures)

• NNF Change Solution: Keep the modification-of relationships using a new characteristic type to support querying.
  
  • Pros: Do not need to increase number of concepts or complexity of ECL engines. 
  • Cons: Big change in the spec? Could be misinterpreted. Seems risky.

• ECL Engine and Language Change Solution: Build a transitive closure for each transitive property, in the same way that we do for the is-a relationship. We would also need special ECL syntax for this.
  
  • Pros: No content change. No classification change.
  • Cons: Slightly more work in ECL engines.
  • Pseudo-code: Kai Kewley 
    • In an ECL engine, when building the ECL index:
       
      • Identify which properties are transitive: 

        Set<String> transitiveProperties = owlOntology.getAxioms(AxiomType.TRANSITIVE_OBJECT_PROPERTY).stream()
               .map(axiom -> axiom.getProperty().getNamedProperty().getIRI().getShortForm())
               .collect(Collectors.toSet());

      • Build up a set of transitive property ancestors:
      • Concept:

        Map<String, Set<String>> transitiveTypeParentMap;
        addRelationship(source, destination, type) {
          if (transitiveProperties.contains(type)) {
            transitiveTypeAncestorMap.get(type).add(destination);
          }
        }
        

• • • • Include transitive property ancestors in ECL index:
        • conceptId: 351000220100 |Minocycline hydrochloride dihydrate (substance)|
        • ancestors: (usual is-a ancestors)
        • 738774007_ancestors: (52886009 |Minocycline hydrochloride (substance)|, 372653009 |Minocycline (substance)|)
        • 738774007_parents: (52886009)

        • 733930001_ancestors: ()
          

        • further fields generated depending on the substrate.
          
          
    • ECL Language could allow something like: 
      • << [+738774007 |Is modification of|] meaning use modification of transitive hierarchy in addition to is-a hierarchy.
      • or << [+*] meaning use all available transitive hierarchies
      • Examples:
        • < |Product| : << |Has active ingredient| = << [+738774007 |Is modification of|] |Amoxicillin|
        • < |Product| : << |Has active ingredient| = << [+*] |Amoxicillin|
          
          
    • JR: At what point do we stop keeping everything stateless and use a reasoner. Should we check our approach / policy?
    • ML: We need a solution that works with all property chains, not just transitive properties... we have that during NNF calculation, we are currently removing it. Perhaps those could be put into the NNF or another file to enable ECL implementations.
    • Kai Kewley and Ale to catchup with Jim and Yong on this.
    • DK: concerned that complexity of ECL would increase and usefulness may decrease? Maybe other architectures are needed to support another way to run snomed queries?
    • JR: Suggests a hybrid ECL engine that can use a reasoner when needed, if the user needs to run a query that requires one and needs the complete answer.
      
    • ALO: Perhaps SI could pre-compute the ECL index in a standard format for use in any ECL engine. A way to reduce the complexity for implementers and also standardise the solution. This could be a file in the release and also an open source tool.
      
  • Hybrid ECL Engine with Reasoner
    • To avoid complexity in pre-computing the ECL index?? An ECL engine could detect when OWL reasoning is required and then use OWL to execute specific types of query.. for example queries involving property chains where the NNF is not sufficient.

• Content Change Solution: Create a grouper substance to include that substance and all single and multi-hop the modification substances.
  • Pros: Would work without other changes. This technique has precedent in the body structure hierarchy.
  • Cons: Approx. three times the number of substance concepts. May be hard for implementers who want a clean list. Because of the high number (around 2K) of substances with a modification relationship these groups would need to be generated.
    
    
  • Current content in numbers:
    • 2,297 Substances have the modification-of attribute
      • Two hop Example: 351000220100 |Minocycline hydrochloride dihydrate (substance)|
    • 89 Substance groupers exist with naming: "Substance-X and/or substance-X derivative"
      • Example: 412053006 |Urea and/or urea derivative (substance)|
    • 37 Product groupers exist with naming: "Product containing substance-X and/or substance-X derivative"

All

Potential issues when upgrading the substrate of an expression repository

• Inactive concepts within the expression (focus concept, or attribute name or value)
• Concepts changing hierarchies (semantic tag) - e.g. procedure → observation
  • The has happened for promoted concepts
  • Is this a corner case / rare? Needs analysis. Kai Kewley 
• Changes to concept model
  • MRCM Changes / Editorial Guide
  • Other modeling changes, perhaps driven by QI consistency efforts
• Will need to classify again to infer different ancestors and attributes
  • Maybe new equivalents 
• MC: This has a lot of overlap with ECL maintenance

• General approaches for identifying issues:
  • FHIR interface could validate the expression again to identify inactive concepts
  • Expand existing value sets to see if there is a radical change in size
  • Content unit tests - needs 
• Strategies to avoid these issues:
  • Types of template based authoring / transformation
    • Precoordinated template pairs - used by International Authoring teams
    • Level 1 postcoordinated transformations. 
  • Use the close to user form, level 1 transformations
    • Create expressions using a proximal parent with minimal modeling, lean on Level 1 transformations (see guide)
    • Expression repository should retransform existing close to user form expressions to classifiable expressions
  • What techniques from precoordinated authoring could be reused? How to international authors update PPP concepts, what automations?
  • Should expression repository be versioned before being upgraded, or should the repository be recreated against the new substrate.
• Strategies to fix content issues:
  • Use historical associations to replace inactive concepts used with an expression
    • What historical association types work, which do not?
    • Same As - Switch concept to target
    • Maybe (possibly equivalent to, possibly replaced by)
      • probably can't use both in an expression
      • need a strategy - may not be able to automate, need an author choice?

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: change 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)
      • Suggested syntax update ECL 2.3: 

        ^  816080008 |International Patient Summary|  {{ D active = (true false) }}

      • .. TS should return error if no inactive descriptions loaded
  • 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 }}