Welcome and agenda

All

ECL 2.2
Implementation Progress

@Kai Kewley 

• "Top" and "Bottom" operators

  • Ontoserver and Snow Owl have implemented this

  • Scheduled for development in Snowstorm @Kai Kewley 

• Alternate Identifiers

  • No implementations yet

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

  • Scheduled for development in Snowstorm @Kai Kewley 

ECL 2.3 development

Behaviour refinement for concrete string matching

@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

ECL 2.3 development

On Hold

Proposal. "exact:" string matching prefix.

TODO: Let's see some examples from B2i where this is more useful than wild.

Current term matching options:

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

• {{ D term = wild:"asthma" }}

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

ECL 2.3 case sensitivity 

TODO: Should wildcard search be case sensitive? Can we document the behaviour.

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

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

Techies comparing to wildcard searching on other platforms..

ECL 2.3 

TODO: Add docs example with star at both ends to allow partial string matching. @Kai Kewley 

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?

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

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

Resolvable URIs for ECL

@Anne Randorff Højen 

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

Dot notation for concrete values

@Alejandro Lopez Osornio 

For next time in Oslo.

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

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

ECL 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

Syntax options:

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

• Syntax sugar: ^? 404684003
  
  
  

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

• Syntax sugar: ^? 404684003 AND < 123000
  
  
  

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

• Syntax sugar: ^? << 404684003

Agreed. @Kai Kewley draft ECL guide changes for review next time (Not done yet)

• @404684003

  • Overlaps with template language

• ? 404684003

  • A bit vague? 

• ^? 404684003

  • Looks intuitive

  • Two Behaviours

  • refsets returned match ANY concepts in the nested expression.

    • ^? (<404684003)

    • ^? (404684003 OR 234234234002)

  • refsets returned match ALL concepts in the nested expression.

    • ^! (<404684003)

    • ^?MAX (<404684003)

• ^R 404684003

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?

Current experiment:

• An extension of the CodeSystem definition

  • @Kai Kewley  drafted a JSON format to represent the required parts of the MRCM to support this use case.

  • Review and discuss

  • FHIR format feedback:

    • Can we split the long string, maybe by domain?

    • Alternative StructureMap rendering?

  • JSON format feedback:

    • Need to represent each attribute-domain

  • @michael lawley next iteration of the format.

Other options was considered but rejected because of demand of TS implementation complexity:

• 1. Focus concept(s) -> MRCM Domain → set of domain - attributes

  • ConceptMap? - translate focus concept to set of attributes

    • A map would support returning additional information like grouping

• 2. Attribute → Search within attribute range

  • ValueSet - expand URI with attribute ID, filter using text?

  • ValueSet/$expand?url=http://snomed.info/mrcm-attribute/X&filter=append

• New implicit URIs?

• Consider supporting a reverse lookup - given a focus concept, which attributes can this be used within.

2.3 ECL Enhancement

@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 [ type ]

• 12334000.type

• 12334000 ...

ECL History Supplements with no association

@Anne Randorff Højen 

@Kai Kewley 

Potential issue: Concepts made inactive with inactivation reason "Non conformance to editorial policy" currently have no historical association.

Use Cases

• < 414408004 |Hispanic (racial group)| {{ +HISTORY }}

  • No historical associations found against the inactive children

Should ECL be able to retrieve these concepts

Options:

• Include some association type in RF2 - could be generated before release.

• Fix in ECL. Terminology server could link concepts without any association to their last active parents.

  • ECL engine could use the snapshot to find the last active parents

Discussed in Joint AG - 

• Most favoured solution is to add more associations in the RF2 where possible, probably using a scripted process.

  • UK already doing this.