Welcome and agenda

All

Resolvable URIs for ECL

@Anne Randorff Højen 

This topic is important for the implementation guides and other documentation.

Options:

• FHIR URI: http://snomed.info/sct/xxxxx/version/xxxxx?fhir_vs=ecl/<40541001

• SNOMED URI: http://snomed.info/sct/xxxxx/version/xxxxx/ecl/<40541001

• Other SNOMED options: http://snomed.info/sct/xxxxx/version/xxxxx?ecl=<40541001

The group would like to use the existing FHIR ValueSet URI, rather than adding to the SNOMED URI standard.
These can be made to resolve. They can already optionally contain an edition and optionally an edition version.

ECL 2.2
Implementation Progress

@Kai Kewley 

• "Top" and "Bottom" operators

  • Ontoserver and Snow Owl have implemented this

  • Scheduled for development in Snowstorm TODO@Kai Kewley 

• Alternate Identifiers

  • Implementations coming in Onto and Snow Owl.

  • The LOINC SNOMED Extension has just been published in March 2025

  • Scheduled for development in Snowstorm TODO @Kai Kewley 

ECL 2.3 development

Behaviour refinement for concrete string matching

Ready for RC

@michael lawley 

Proposal: Simplify concrete string matching. Use exact string match rather than prefix matching.

Justification: The specification is a little vague in this area. The project group agreed that exact string matching seems most appropriate for concrete strings. The known terminology servers have already implemented exact string matching. 

• DONE: Group agreed to keep set of exact match strings.
  
  

  • Example:  <  373873005 |Pharmaceutical / biologic product| : 3460481009 |Has product name|  = ( "PANADOL"  "TYLENOL" )

  • Alternative: <  373873005 |Pharmaceutical / biologic product| : ( 3460481009 |Has product name|  = "PANADOL"  OR 3460481009 |Has product name|  = "TYLENOL" )

  •  

• For Review: Change syntax again to make concrete string named as a unique syntax element.

- Group already reviewed documentation changes -

•  

  • 6.2 Refinements

  • Removed “Concrete values of type string are case sensitive and compared using the Unicode Collation Algorithm (http://www.unicode.org/reports/tr10/).”

  • Updated PANADOL example

Ready for RC

ECL 2.3

Dot notation for concrete values

@Alejandro Lopez Osornio 

Use case: Get the strength value from a drug

Example: 318420003 |Product containing precisely atenolol 50 milligram/1 each conventional release oral tablet (clinical drug)| . 1142135004 |Has presentation strength numerator value (attribute)|

Would return "50".

Could also be used in a user interface to filter by the available options. For example listing available drug pack sizes.

Example: (<< 781405001 |Medicinal product package (product)| : 774160008 |Contains clinical drug (attribute)| = << 318420003 |Product containing precisely atenolol 50 milligram/1 each conventional release oral tablet (clinical drug)|) . 1142142004 |Has pack size (attribute)|

TODO: Document in behaviour spec + examples @Kai Kewley 

ECL 2.3

Non Code FHIR Examples

Create notes for ECL implementors to draw attention to the fact that some ECL results are not concepts/codes.

Link to the SNOMED on FHIR documentation for this.

Consider adding an appendix for FHIR specific considerations.

TODO: Keep an eye on progress of the SNOMED on FHIR doc.

ECL 2.4 development

@Márk Czotter (Unlicensed) 

Proposal. "exact:" case-sensitive string matching prefix.

Examples from B2i where this is more useful than wild..

Use case:

• Identifying duplicates during upgrade of dependencies.

  • Supporting UK upgrade process, finding promotions from other NRCs 

  • Case sensitive match

  • Drug flavour codes in DM+D, e.g. "Almond"

Current term matching options:

• {{ D term = "asth" }} equivalent to {{ D term = match:"asth" }}

• Should we add wild - {{ D term = exact:"asthma" }}

  • Same as {{ D term = wild:"asthma" }} ?

  • No, wild is now case insensitive. Exact is case sensitive.

TODO: (2.4) Make syntax changes to add this @Kai Kewley 

ECL 2.3
term filter wild case sensitivity 

Group agreed to make this case insensitive.

Some users on the call expect this to be case insensitive: Feikje, Andrew Perry

Techies comparing to wildcard searching on other platforms..

TODO: Update docs to state the filter is case insensitive. Check/add examples.

TODO: Add examples of wild conversion to regex: ^ast.*ma$ - to help ECL engine creators understand.

TODO: Add a developer note with a deep link to the Snowstorm code. Maybe it's this: ast*hma → ^[aA][sS][tT].*[hH][mM][aA]$

ECL 2.3 

Add docs example with star at both ends to allow partial string matching.

DONE

ECL 2.3

Enhancement Request: Set of reference sets containing a concept

@michael lawley 

Enhancement for ECL 2.3

See comment here: Re: Discussions (2)

Use cases:

• Exploration for data analytics

  • What subsets ~ what domains - how is this code used

• System design - finding existing relevant sets

  • Would require a set of concepts that are all included within a refset

• Browsing

  • Like the SI Browser "Refsets" tab

Two behaviours:

Find refsets containing this concept or any of these concepts

Syntax options:

• ^[refsetId] * {{ M referencedComponentId = 404684003 }}

• Syntax sugar: ^R 404684003

• ^[refsetId] < 123000 {{ M referencedComponentId = 404684003 }}

• Syntax sugar: ^R ( 404684003 )
  
  
  

• ^[refsetId] * {{ M referencedComponentId = << 404684003 }}

• Syntax sugar: ^R (<< 404684003) 

• Syntax sugar: ^R-ANY (<< 404684003)

  • Equivalent to previous

Find refsets containing this concept or all of these concepts

Syntax options:

• ^[refsetId] * {{ M referencedComponentId = 1000 }} AND ^[refsetId] * {{ M referencedComponentId = 2000 }} AND ^[refsetId] * {{ M referencedComponentId = 3000 }}

• Syntax sugar: ^R-ALL (1000 OR 2000 OR 3000)

• New syntax: ^R-ALL (<< 404684003)

TODO: Create syntax and guide.

2.4 ECL Enhancement

(On Hold)

@michael lawley 

I want to fetch the set of attribute names used by a concept or set of concepts.

Use case: 

• Authoring ECL

• Authoring template generation

Syntax options:

• 12334000 . ?

• 12334000 = R?

• 12334000 : ?

• 12334000 : ? = *

• 12334000 : * = ?

• 12334000 [ typeId ] (2 votes)

  • Disadvantage of this - starts to imply any column is selectable.

  • Although the behaviour is about expressions (original purpose of ECL).. the syntax starts to look like a RF2 query language.

• 12334000.typeId

• 12334000 ...

• 12334000.A (1 vote)

• 12334000.T (1 vote)

• ( << 318420003 |Product| ).R

• 12334000 {{ R }}

Behaviour - implied "distinct" .

ECL 2.3 development

Ensuring consistency

All

Updates following Jeremy Roger's Terminology Terver ECL consistency analysis the following changes were recommended by the group:

• Filter changes

  • Update ECL Spec to allow searching over active and inactive (apply everywhere, concept, description, members)

  • Concept change not needed because active and inactive are included by default. Spec already states this.

  • For review 5.1 Brief Syntax (Normative)

  • Done: Review second version of syntax change:

    • https://github.com/IHTSDO/snomed-expression-constraint-language/commit/789b823fe9d7e52800f3e4172ac1f9f93283c67d

• Description filter changes

  • Change ECL specification to exclude TextDefinitions by default

  • Make string “match” case insensitive

    • Done: Group agreed to exclude TextDefinitions by default.

      • TODO: Update specification for review @Kai Kewley 

  • For review 6.8 Description Filters

• Should FSN be excluded by default from Description filters?

  • Pros:

    • A lot of results when search term includes semantic tag word, e.g. disorder

      • Workaround: engines could use ranking to reduce the score of concepts matching by semantic tag

  • Cons:

    • Not all concepts have a synonym exactly matching the FSN minus its semantic tag .. .but the huge majority do. Only 14.6% do not, but even most of these have at least one vanilla synonym that is incredibly similar to the FSN (at least, for the language=en presentation of SNOMED). For this reason, adding the words of "FSN minus semantic tag" into the lexical search space by default almost never materially alters the lexical retrieval result, because there are enough words in the vanilla Synonyms. But adding the semantic tag itself in as well is at best redundant and at worst a source of false positive search results. If the rules and therefore benefits of including the FSN are different for searches over other languages then fine...but if that is the case then we must consider whether imposing language-blind rules and defaults on Terminology Server behaviours is a good idea. It appears to be adversely impacting anglophone search.
      
      Consider Rogers' Conjecture:
      If semantic tags had not been encoded within SNOMED CT in the way that they are, embedded within the string of FSNs, but had instead been encoded as either a standalone description type, or by the membership of a crefset, then we wouldn’t be dreaming of including them by default within the scope of lexical searches.
      
      If the words in the rest of the FSN, without the semantic tag, are presented in other synonyms anyway then, outside of very specialist terminologist use cases, there is virtually no reason to ever perform a lexical search on the FSN whether by default or for fun. If you want to constrain a search both semantically and lexically, use the taxonomy not the semantic tags for the semantic constraint element. If you just want to include the words in the FSN other than the semantic tag in your lexical search, then you've already got them in the synonyms. And if you haven't then there is probably a modelling/naming error that would be better fixed in the source data rather than compensated for post hoc by always including the FSN in searches even where it isn't needed and does more harm than good.

ECL gramma feedback

• ECL gramma feedback from mkorvas
  https://github.com/IHTSDO/snomed-expression-constraint-language/issues

Compound word search

@michael lawley 

@Kai Kewley 

@Feikje Hielkema (Unlicensed) 

Each language would need a list of words to find within compound words. Where could these lists come from?

• Use words from snomed that are longer than 3 characters?

• Allow extensions to produce list of terms

• Add hidden unicode character in compound words to mark the word boundaries

• How to solve for other terminologies?

DONE: Establish a test set of terms for compound word processing. List of concept terms and desirable search terms. @Feikje Hielkema (Unlicensed) 

TODO: Trial compound word splitting, preprocess using a hyphenation algo?

ECL Lite - Expanding the use of the ECL standard

All

Previous discussion:

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

• SI already has open source implementations for reference

• 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" is a simpler version of Expression Constraint Language including only the most useful features. ECL Lite will be a true subset of ECL so will be forward compatible. 

Feedback from previous meeting:

• Concrete string matching simplification (resolved above)
  
  
  

• Not including description-filters limits the ability to define a set of concepts by language and dialect

  • Consider publishing a recommendation to workaround this in FHIR Terminology servers.

  • Review: Added scope info box: 6.8 Description Filters
    
    
    

• Add "Included In ECL Lite" Labels throughout the examples section - Use positive labels rather than exclusions

  • Review: Added throughout - 
    
    
    

• Appendix - make explicit that ECL Lite syntax must work with servers with full - intention is true subset.

  • Review: Added info box Appendix F - ECL Core, Quick Reference 

Other draft specification updates:

• Mentioned in 1. Introduction

• Reduced scope of concept filter to just active-filter.

  • 5.1.1 ECL Core - Brief Syntax

ECL Lite - MVP Scope:

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

• Dot

• Not included:

  • other filters

  • cardinality

  • groups

• Declare profile using block/set of language capabilities

• Survey capabilities in existing implementations - any existing capability groups?

• There are parallels in ECL builder and education scopes

ECL Capability statement in FHIR

Chat with @Peter Williams 

ECL Test Harness

@Kai Kewley @Márk Czotter (Unlicensed) 

Next steps:

• Establish test cases

• Agree harness approach - consider the fhir-tests / tx / simple approach https://github.com/FHIR/fhir-test-cases/tree/master/tx/simple

TODO: B2i have test cases that check ECL to Elasticsearch query conversion. Does the group want more integration style tests that specify a substrate and expected set of concept results?

FHIR TX - Searching with a specific dialect

@Kai Kewley  Try this in Snowstorm:

When expanding a ValueSet with text filtering it is recommended to use the "Content-Language" header, to constrain the language and dialect of matched terms, in addition to informing the selection of display terms.

This behaviour is owned by HL7.

ECL Lite naming

Not everyone happy with the name.

TODO: Choose from alternatives:

• ECL Core

• ECL Essential

• ECL Focus

• ECL Base

• ECL Basic

• ECL--

• My First ECL

Substrate discussion

Add appendix to describe the potential differences between terminology servers given what content is loaded/filtered out.

MRCM on FHIR

All

There is a growing desire to enable access to the SNOMED CT Machine Readable Concept Model via FHIR Terminology Servers.

Use cases:

• To support the creation and validation of Expression Constraint Language queries

• Creation and validation of Postcoordinated expressions using Compositional Grammar

How could this work?