The SNOMED CT Expression Constraint Language is a formal language for defining bounded sets of clinical meanings represented by either precoordinated or postcoordinated expressions.

Status

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

Implementations

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

• SNQuery - http://snquery.veratech.es/
• CSIRO Ontoserver Expression Constraints – https://ontoserver.csiro.au/shrimp%F0%9F%94%A5/ecl.html
• termMed’s termSpace - http://demo.termspace.com/ and https://termmed.atlassian.net/wiki/display/TSD/Creating+queries
• SNOMED International Terminology Server (via REST API) - https://github.com/IHTSDO/snow-owl
• SNOMED CT Query Service - https://github.com/IHTSDO/snomed-query-service
• Snow Owl MQ (form-based interface) -  https://mq.b2i.sg/snow-owl/
• SNOMED CT Language Syntax Parsers - http://apg.ihtsdotools.org/
• ECL Syntax Parser - https://github.com/hsolbrig/SNOMEDCTParser
• SnoLyze - https://github.com/slaverman/SnoLyze

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 1.3 of the SNOMED CT expression constraint language.

In the following sections, we describe some of the proposed requirements, which are under consideration for ECL version 1.3.

Using Expression Constraints for Attribute Names

The value of an attribute name in a refinement should be able to be represented as an expression constraint. For example:

<< 125605004 |Fracture of bone| :
363698007 |Finding site| = 23416004 |Structure of ulna|,
116676008 |Associated morphology| = 72704001 |Fracture|,
[0..0] (<<410662002 |Concept model attribute| MINUS 363698007 |Finding site| MINUS 16676008 |Associated morphology|) = *

Given knowledge of the concept model, this is equivalent to the following (v1.2) expression constraint:

<< 125605004 |Fracture of bone| :
     363698007 |Finding site| = 23416004 |Structure of ulna|,
     116676008 |Associated morphology| = 72704001 |Fracture|,
     [0..0] << 47429007 |Associated with| = *,
     [0..0] 263502005 |Clinical course| = *,
     [0..0] 246456000 |Episodicity| = *,
     [0..0] 419066007 |Finding informer| = *,
     [0..0] 418775008 |Finding method| = *,
     [0..0] 363713009 |Has interpretation| = *,
     [0..0] 363714003 |Interprets| = *,
     [0..0] 246454002 |Occurrence| = *,
     [0..0] 370135005 |Pathological process| = *,
     [0..0] 246112005 |Severity| = *,
     [0..0] 363705008 |Has definitional manifestation| = * 

It has been agreed that this is a useful feature that should be added to a future version of the ECL.

Add childOf to Attribute Operators

It has been proposed, for orthogonality, that childOf is added to the list of possible attributeOperators. Currently attributeOperator only includes descendantOf and descendantOrSelfOf.

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
• A set of invalid expression constraints that should fail in testing an expression constraint parser
• A set of valid results for each example expression constraint, executed against a specific version of the SNOMED international edition
• 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.

Parsing Dotted Expressions

While the ABNF is completely correct as it stands, an ANTLR grammar parser has some implementation difficulties with it. In particular, when parsing the attribute operator in the dottedExpressionConstraint rule is optional, which means that when you parse this rule in ANTLR, you get an array of attributeOperator and an array of eclAttributeName items.

That is - parsing "1.<2.3" will yield an attributeOperator array of length 1 {‘<’] , and an eclAttributeName array of length 2 {‘2’,’3’}

It is not possible in the ANTLR visitor class to tell which eclAttributeName the ‘<’ should be applied to. The changes required to fix this are:

Old ABNF:

dottedExpressionConstraint = simpleExpressionConstraint 1*(ws dot ws [attributeOperator ws] eclAttributeName)

New ABNF:

dottedExpressionConstraint = simpleExpressionConstraint 1*(ws  dottedExpressionAttribute ws )

dottedExpressionAttribute = dot ws [attributeOperator ws] eclAttributeName

Now when you parse it , you get an array of dottedExpressionAttribute items, each of which may or may not have an attribute operator.

Parsing subRefinements

The normative grammar is ambiguous with respect to the eclRefinement rule. Suppose we are trying to parse the following constraint:

   < 404684003 |Clinical finding| : 

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|