...

SNOMED CT expression constraint language version 2.1 .6 has been published at at http://snomed.org/ecl. 

Implementations

SNOMED International is aware of the following implementations of the SNOMED CT Expression Constraint Language:

...

:

...

• termMed’s termSpace - http://demo.termspace.com/ and https://termmed.atlassian.net/wiki/display/TSD/Creating+queries
• Snowstorm - SNOMED International Terminology Server (via REST API) - https://github.com/IHTSDO/snowstorm
  • Provides API for the SNOMED International public browser (See "Expression Constraint Queries" tab) - https://browser.ihtsdotools.org/
• SNOMED International SNOMED CT Query Service - https://github.com/IHTSDO/snomed-query-serviceSnow
• OwlTerminology Server (via REST API) CSIRO Ontoserver Expression Constraints - https://github.com/IHTSDO/snow-owl
• Snow Owl MQ (form-based interface) -  https://mq.b2i.sg/snow-owl/
• ECL 1.4 - https://github.com/b2ihealthcare/snomed-ecl
• ECL 1.5 - https://github.com/b2ihealthcare/snomed-ecl/tree/upgrade/ecl-1.5
• QL 0.1 - https://github.com/b2ihealthcare/snomed-ql
• SNOMED CT Language Syntax Parsers - http://apg.ihtsdotools.org/
• ontoserver.csiro.au/shrimp/ecl.html (help)
• ECL Syntax Parser - https://github.com/hsolbrig/SNOMEDCTParserSnoLyze -
• Hermes:  https://githubGitHub.com/slaverman/SnoLyze (ECL v1.2)
• Terminz - https://terminz.azurewebsites.net/fhir
• wardle/hermes 

• PHAST's FHIR Terminology server STS -  https://topaze.phast.fr/resources-server/api/fhir

  • Available 24x7 for testing, through CSIRO's VS tool -  https://ontoserver.csiro.au/vstool/

• Slang - http://slang.snomedic.com:8080/yats/ 
• SnoLyze -Hermes:  https://GitHubgithub.com/wardle/hermes slaverman/SnoLyze (ECL v1.2)
• Snomedizer: https://github.com/ramses-antibiotics/snomedizer

If you know of additional ECL implementations, please contact eps@snomed.org with details.

Future Versions

Additional requirements are being collected for consideration in a future version of the SNOMED CT expression constraint language.

In the following sections, we describe some of the proposed requirements, which are under consideration:

Expression Constraint Implementation and Testing Artifacts

A number of artifacts have been proposed to assist with the implementation and testing of the Expression Constraint Language, including:

• An ANTLR grammar of the ECL syntaxes
• Track changes, change bars or similar to make it easier for implementers to identify the areas of change. In addition, changes should be localized and minimized.

Selecting Concepts Recorded in Additional Reference Set Attributes

We are going to develop the refsets for anatomy. The plan is to have two association refsets for Structure/Entire and Structure/Part. Please see more information at SEP maps and refset.

We need some way of selecting the 'targetComponentId' column of these reference sets. This column is represented by the refset attribute concept 900000000000533001 |Association target component|.

This may be needed, for example, to define a template slot rule that restricts possible values of the slot to only 'entire' concepts, or 'part concepts'.

Possible syntaxes:

• ^(1000005|Anatomy structure and entire association reference set|.900000000000533001 |Association target component|)
• ^1000005|Anatomy structure and entire association reference set|.900000000000533001 |Association target component|
• 1000005|Anatomy structure and entire association reference set|.900000000000533001 |Association target component|

Using Any for any Concrete Value

The Any wildcard (i.e. *) should be able to be used to represent any concrete value (i.e. number or string), rather than just for any concept. In doing so, consideration must be given to ensure that the grammar is able to be parsed unambiguously.

Matching Attribute Names

How can I write an ECL expression to match attribute names? Currently ECL expressions can match (return) concepts that are either the source or the target of a relationship triple (target is accessed via the 'reverse' notation or 'dot notation', but not the relationship type (ie attribute name) itself. For example, I can write: 

    << 404684003|Clinical finding| : 363698007|Finding site| = <<66019005|Limb structure| 

and

    << 404684003|Clinical finding| . 363698007|Finding site| 

But how to I get all the attribute names that are used by << 404684003|Clinical finding| ?

QL Feature Requests

• Snow Owl
  • Terminology Server (via REST API) - https://github.com/IHTSDO/snow-owl
  • ECL 1.4 -
• Support for moduleId and caseSignificantId
• Support for effectiveTime (exact and ranges), semanticTag (exact and regex), namespace and refset attributes.
• Regular expression and exact term matching
• Conjunction, disjunction and exclusion at all levels of the query, and multiple queries can be connected together
• Query nesting - Filters that accept concept SCTIDs, any ECL query, so more complex queries can be created and evaluated
• See  and 
  •  https://github.com/b2ihealthcare/snomed
  -ql
  • -ecl
  • ECL 1.5 - 
  • https://github.com/b2ihealthcare/snomed-
  ql#examplesAlso see 
  • ecl/tree/upgrade/ecl-1.5
  • QL 0.1 - https://github.com/b2ihealthcare/snomed-ql
  /blob/main/com.b2international.snomed.ql/src/com/b2international/snomed/ql/QL.xtext
• SNQuery - http://snquery.veratech.es/
• Terminz - https://terminz.azurewebsites.net/fhir
• termMed’s termSpace - http://demo.termspace.com/ and https://termmed.atlassian.net/wiki/display/TSD/Creating+queries
• West Coast Informatics (WCI) SNOMED Terminology Server - https://snomed.terminology.tools/terminology-ui/index.html

If you know of additional ECL implementations, please contact info@snomed.org with details.