Welcome and agenda

All

ECL 2.3

Enhancement Request: Set of reference sets containing any concept within a given set

@michael lawley 

Dev Test: @Márk Czotter (Unlicensed) 

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

Find refsets containing this concept or any of these concepts

• Constraint: Refset contains any of these concepts.

• Long Syntax:

  •  

    • refsetContainingAny 404684003

Short Syntax options:

• ^? 404684003 

• ^R 404684003 (Chosen)

• ?^ 404684003

Examples:

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

• Syntax sugar: ^R 404684003

  • This means find all reference sets containing the concept 404684003

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

• Syntax sugar: ^R ( 404684003 )
  
  
  

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

• Syntax sugar: ^R (<< 404684003)

• Alt: ^R (1000 OR 2000 OR 3000)

TODO: Review guide. Spec: Simple Expression Constraints

DONE: Changed syntax to ^R

ECL 2.3 development

Behaviour refinement for concrete string matching

Ready for RC

@michael lawley 

Already tested:
(Snow Owl & Snowstorm)

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 -

•  

  • Spec: 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: Someone try implementing this.

• Behaviour constraint - this should only be used in the top level expression - otherwise return an error

Then: Document in behaviour spec + examples @Kai Kewley 

Notes on implementation - use hierarchy to check attribute data types.

ECL 2.3
Term filter wild case sensitivity 

Already tested:
(Snow Owl & Snowstorm)

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..

• Updated docs to state the filter is case insensitive. Check/add examples.

• Link to Snowstorm code for example wildcard to regex conversion. e.g. ast*hma → ^[aA][sS][tT].*[hH][mM][aA]$
  https://github.com/IHTSDO/snowstorm/blob/10.9.1/src/main/java/org/snomed/snowstorm/core/util/DescriptionHelper.java#L102

DONE

ECL 2.3 

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

DONE

ECL Core

All

ECL Core (previously named ECL Lite)

Strategy Item: Expanding the use of the ECL standard

WIP ECL Guide updated with new name

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 Core profile would reduce the months of effort required to implement the whole specification when starting fresh.

"ECL Core" is a simpler version of Expression Constraint Language including only the most useful features. ECL Core 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 Core" Labels throughout the examples section - Use positive labels rather than exclusions

  • Review: Added throughout - 
    
    
    

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

  • Review: Added info box Appendix F - ECL Core, Quick Reference (Fix, Migration failed)

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 Core - MVP Scope:

• *, <, <<, >, >>, <!, !>, :, ^, ^R, 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 2.3

Non Code FHIR Examples

Create notes for ECL implementers 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.

@Kai Kewley to catch up with PGW on this

ECL Test Harness

@Kai Kewley @Márk Czotter (Unlicensed) 

August 2025 Update - Kai enhanced the SNOMED Subontology Extractor for Grahame Grieve. He is adding SCT some SCT specific test cases.
See https://github.com/HL7/fhir-tx-ecosystem-ig/tree/main/tx-source

---

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?

ECL: 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

  • TODO: Check the defaults are explicit in the guide.
    
    
    

• 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

  • TODO: Ensure all ECL 2.3 changes, both syntax and behaviour changes, are listed in the guide.

• Should FSN be excluded by default from Description filters?

  • Jeremy could retest to find any behaviour differences.

  • Discussion: 

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

Resolvable URIs for ECL

@Anne Randorff Højen 

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

The group chose 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.

From these 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

Action: Create implementation tickets @Kai Kewley 

----

ECL 2.4 development

(Later)

@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 Future

Enhancement Request: Set of reference sets containing all concepts in a set

Archived

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)

• Alt: ^R 1000 AND ^R 2000 AND ^R 3000

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 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 Capability statement in FHIR

Chat with @Peter Williams 

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.

Substrate discussion

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