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

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 

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

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

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

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.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 : ? = *

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

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.

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?

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?

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

      • Suggested syntax update ECL 2.3: 

      • .. TS should return error if no inactive descriptions loaded

  • Snow Owl searches active and inactive descriptions by default - needs to be realigned?
    
    

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

Postcoordination Guide + Reference Implementation Feedback

Alejandro Lopez Osornio 

Very little feedback received so far.

An education module could be a way to expose more people to the caveats and best practises.

Expression Repository Maintenance

All

- Aim to round off the guidance - make expression repositories feasible -

An expression repository uses a specific edition and version of SNOMED CT - how can expressions be migrated to a new version?

Use cases of expressions:

• Classifying expressions to discover closest existing precoordinated concept - no requirement for maintenance because expression not recorded in patient record

• Expression is recorded in patient record - need the ability to find relevant patients. This may not work well over time as SNOMED changes.

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:

  • Capture user input (close to user form or template slot inputs) so that templates or transformations can be reapplied.

  • Transform input again against the new substrate:

    • Types of template based authoring / transformation

      • Level 1 postcoordinated transformations. 

      • Implementation defined template - input to template captured and stored outside for the terminology server.

      • Precoordinated template pairs - used by International Authoring teams

  • 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

  • Kai Kewley  What techniques from precoordinated authoring could be reused? How do 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?

Use cases for an expression repository, how are these impacted over time as the substrate changes.

• Postcoordination as a replacement for authoring

  • PPP modeling + attribute

  • Desirable check when upgrading the substrate: detect change in subsumption.

Other Topics

All

• DK: Discussion of postcoordination transformations for Level 1+ or Level 2

  • use of template language?

  • Transformation choice interactive?

• JR: History supplements - Deprecate the WAS-A historic association? Causes implementation issues.

  • Bring in other groups? Editorial EAG

The items below are currently on hold

Meds ECL Requirement

michael lawley 

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. Author/modeller chooses a drug and wants to refine the selection using modification-of substances. 

• Alternate use case: Clinician chooses a drug and wants to refine the selection using modification-of substances

  • The product may not exist - it could be made up.

  • B2i have solved this problem using a real-time recursive search

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

Open

Child

Open

Because

Open

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

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

SNOMED OWL Query Engine

Jeremy and all

• New Type of SNOMED Query Engine including an OWL Reasoner (an idea from Jeremy)

  • Alternative approach to pre-computing the ECL index. The engine would detect when OWL reasoning is required and use OWL to execute specific types of query.. for example queries involving property chains where the NNF is not sufficient.

  • How is this different from postcoordination.

  • What is the gap between ECL and Postcoordination:

    • ECL things not available in PCE engines:

      • ECL filters

      • Refset membership and other fields

      • Cardinality constraints

  • Use Cases:

    • Clinical use case: Refining the selection of a drug (using property chains)

    • Back office / QA use case: Find all concepts with only one parent.

      • B2i support this by extending the spec and allowing cardinality on the is-a relationship.

    • Maybe in the future other attributes will be transitive: caused-by, due-to.