Welcome and agenda

All

ECL 2.3 - Published

All

Sparql

Brian

Review https://docs.google.com/document/d/1KIN18NHPP52CYDrkUt29afF9nb7LoSY1jsFCNTPdQs8/edit?tab=t.0

Created “ECL Core”

Meeting schedule change

Continue meeting at twice year Business Meetings. Pause monthly meetings until we have a big item to work on.

“Codeagogo” Mac Utility Demo

@Dion McMurtrie

ECL version in FHIR TX capability statement

How to express what version and what ECL features you support.

What should we express?

• ECL version number

• ECL feature list that are supported

• (ECL features that are not supported are not listed)

Which endpoint should return the metadata?

ECL Test Harness

All

To ensure consistency across terminology servers we want to create an accessible ECL Test suite.

The FHIR API will be used as the standardised interface for these tests. There is already an established test suite for FHIR Terminology Servers, let’s add to that.

• Substrate

  • Candidate substrate - Subontology Browser Select the “FHIR TX Test Subontology”

  •  

• Establish test cases

• Establish test harness approach based on fhir-tests / tx / simple approach

  • Kai’s fork https://github.com/kaicode/fhir-tx-ecosystem-ig

  •  

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?

VCL vs ECL Core

User guidance needed when each is applicable or necessary:

• VCL / ECL Core / ECL

VCL has the syntax-version number as part of the FHIR parameter.

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: 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 (Didn’t make it in ECL 2.3)

Dot notation for concrete values

@Alejandro Lopez Osornio 

Use case:

• Get the strength value from a drug

• Get the range of values from a set of concepts

  • User interface to pick substance and then select one of the available strengths.

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

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.

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.

  • TODO: Could Jeremy provide more information on this?

ECL Maintenance Recommendations

All

We plan to add a "Maintenance Recommendations" page to the ECL guide.

Suggested sections:

• What does best practice ECL look like - what are the benefits

• ECL comments to record intent

• Existing tooling and features

@Jeremy Rogers (Unlicensed) has drafted some content on this topic.

Group have reviewed the word document @Kai Kewley  to Migrate to ECL Guide Appendix for final review. 

ECL Results - TS consistency

@Jeremy Rogers (Unlicensed) 

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

    • (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?