Exclusion is supported in the SNOMED CT Expression Constraint Language by the binary operator 'MINUS'. Exclusion works in a similar manner to mathematical subtraction. For example, the following expression constraint returns the set of lung disorders which are not a descendant or self of edema of the trunk.

Logically, this expression constraint takes the set of descendants of 'disorder of lung' and subtracts the set of descendants of 'edema of trunk'. Please note that the keyword 'MINUS' is case insensitive.

Exclusion can also be applied to the membership of a reference set. For example, the following expression constraint returns the set of lung disorders which are not members of the cardiology reference set. That is, the set of descendants or self of 'disorder of lung' minus the set of members of the 'cardiology reference set'.

Please note that when more than one exclusion operator is used, or when an exclusion operator is used together with a conjunction or disjunction, round brackets must be used to disambiguate the intended meaning.

Attribute values, represented by compound expression constraints, may also contain exclusions. When this occurs, the expression constraint is satisfied by any concept or expression which has at least one attribute (of the given type) whose value is satisfied by the compound constraint defined in the attribute value. For example, the expression constraint below represents the set of clinical findings, which have an associated morphology that is a descendant or self of ulcer and a descendant or self of hemorrhage, but not a descendant or self of obstruction.

In this section, we illustrate how the set of matching concepts can be filtered using one or more simple attribute refinements. For more information on applying refinements to nested expression constraints, using nested attribute names and using nested attribute values, please refer to Nested Expression Constraints.

Attributes

Adding an attribute refinement to an expression constraint restricts the set of valid clinical meanings to only those whose defining attributes satisfy the given refinement condition. Similarly to the SNOMED CT Compositional Grammar, attribute refinements are placed after a 'colon' (i.e. ":") in the expression constraint.

The example below is satisfied only by the set of lung disorders, which have an associated morphology that is exactly equal to 79654002 | Edema| .

< 19829001 |Disorder of lung| :
116676008 |Associated morphology| = 79654002 |Edema|

descendantOf 19829001 |Disorder of lung| :
116676008 |Associated morphology| = 79654002 |Edema|

In many cases, however, the value of the matching attribute is allowed to be either the concept itself, or a descendant of that concept. In these cases, the descendantOrSelfOf operator is used prior to the concept representing the attribute value. For example, the expression constraint below (in brief and long syntaxes respectively) is satisfied only by the set of lung disorders, which have an associated morphology of 79654002 | Edema| or any descendant of 79654002 | Edema| .

When more than one attribute is defined in an expression constraint, the attributes are normally separated by a comma. A comma between two attributes indicates a conjunction and implies that both attribute conditions must be true. For example, the expression constraint below, written in brief syntax, is satisfied only by the set of clinical findings, which have both a finding site of 39057004 | Pulmonary valve structure| (or a subtype of 39057004 | Pulmonary valve structure| ) and an associated morphology of 'stenosis' (or a subtype of 'stenosis').

Please note that attribute refinements may also be used when the focus concept is '*' (or ANY). The following expression constraint represents any concept that has a 246075003 | Causative agent| attribute whose value is 387517004 | Paracetamol| .

Similarly to SNOMED CT compositional grammar, expression constraints use curly braces (i.e. "{..}") to indicate that a set of attributes should be grouped together in an attribute group. For example, the expression constraint below is satisfied only by the set of clinical findings with an associated morphology of 'stenosis' (or descendant) at the finding site 'pulmonary valve structure' (or descendant), and also with an associated morphology of 'hypertrophy' (or descendant) at the finding site 'right ventricular structure' (or descendant).

In some cases, an attribute concept has subtypes or supertypes in the hierarchy. Where this occurs, it is possible to indicate that an attribute condition may be satisfied by matching one of the subtypes or supertypes of the given attribute. This is done adding a constraint operator directly before the attribute name concept. For example, the expression constraint below will not only match clinical findings that are a type of , but also those that are , or the of a type of . This result occurs because the attribute concept has three subtypes: , and .

Similarly, the expression constraint below will not only match clinical findings that are |Due to| a type of |Edema| , but also those that have an |Associated with| relationship whose value is a type of |Edema| .

The SNOMED CT Compositional Grammar allows attributes to be given concrete values (e.g. Strings, Integers, Decimal, Boolean). The SNOMED CT Expression Constraint Language supports the ability to compare these attribute values with a given concrete value.

When numeric concrete values (i.e. Integers and Decimals) are compared, a set of standard mathematical operators may be used. These mathematical operators are:

Please note that the 'not equals' operator may alternatively be represented as "<>" and "not =" (case insensitive) in the long syntax.

The following expression constraint is satisfied by oral medicinal products, which contain amoxicillin and have a presentation strength greater than or equal to 250 mg.

Please note that, as per SNOMED CT Compositional Grammar, integer and decimal values are preceded by a hash character (e.g. "#500"), while string values are surrounded by double quotes (e.g. "PANADOL").

To find those oral amoxicillin products that have a strength between 250 and 800 mg (inclusive), the following expression constraint may be used:

Concrete values of type string and boolean may also be included in an expression constraint, and compared using an 'equal to' (i.e. "=") or 'not equal to' (i.e. "!=") operator. Concrete string values must match the string in the expression constraint exactly.

The following expression constraint is satisfied only by products with a product name exactly equal to "PANADOL" using a case sensitive match.

The following expression constraint is satisfied only by products that are in the national benefit scheme (of the given country) . Note

In most cases, an attribute refinement is satisfied by those concepts, which are the source concept of a defining relationship whose destination concept matches the attribute value. In some cases, however, it may be necessary to select the destination concept of a relationship and constrain the source concept to a given attribute value. To achieve this, an expression constraint indicates that an attribute is to be constrained in the reverse order using a 'reverse flag' . In the brief syntax, the reverse flag is represented by preceding the name of the attribute with a capital letter 'R'.

For example, the expression constraint below finds the set of anatomical structures, which are the finding site of a type of bone fracture (e.g. 85050009 |Humerus| , 71341001 |Femur| ).

An alternative way of representing 'reversed attributes' is by applying the dot notation to represented them as dotted attributes. Using this alternative notation, < 123456 123456 |X| .234567 234567 |Y| represents the set of attribute values (i.e. destination concepts) of the attribute "Y" for descendants or self of concept "X". This is therefore equivalent to * : R 234567 234567 |Y| = < 123456 123456 |X| using the reverse flag.

The previous expression constraint (which finds the set of body sites for any subtype of bone fracture) has an equivalent representation using the 'dot notation' of:

Because all values of 363698007 |Finding site| must be < 91723000 | Anatomical structure| (according to the ), this expression constraint can be further simplified to:

The next example finds the set of substances, which are an active ingredient in any product containing amoxicillin.

When more than one dot attribute is used in sequence, the dot notation is evaluated sequentially from left to right. For example, the following expression constraint represents the set of |Finding sites| of any concept that is |Associated with| a subtype of | Disorder of lung| .

This expression constraint is evaluated by first finding the descendants of |Disorder of lung| , then finding the set of attribute values for these concepts (with an attribute type that is any subtype of |Associated with| ), and then from these attribute value concepts, finding the value of any |Finding sites| attribute. Please note that the expression constraint above (with no brackets) is equivalent to the one below (with brackets added).

A single 'star' (i.e. "*") may be used in the place of an attribute name to represent any attribute in the substrate. The expression constraint below evaluates to the set of clinical findings which have any attribute with a value of 79654002 | Edema| .

The 'star' symbol (i.e. "*") may also be used to represent any attribute value (either with or without refinement). The following expression constraint evaluates to the set of clinical findings which have an associated morphology (with any value).

Attribute cardinality

To support use cases such as the SNOMED CT concept model and terminology binding, expression constraints may constrain the number of times an attribute can be included in an expression or concept definition represented in the SNOMED CT distribution view. This is done using a cardinality constraint, which consists of a minimum cardinality and a maximum cardinality (written "[X..Y]"). A minimum cardinality of X constrains the valid clinical meanings to those which have at least (i.e. >=) X non-redundant attributes that match the given attribute criteria. A maximum cardinality of Y constrains the valid clinical meanings to those which have at most (i.e. <=) Y non-redundant attributes that match the given attribute criteria. For example, a cardinality of "[1..5]" indicates that all clinical meanings that satisfy the given expression constraint must have at least one and at most five attributes that match the given attribute criteria.

The expression constraint below is satisfied only by products with one, two or three active ingredients.

< 373873005 |Pharmaceutical / biologic product| :
  [1..3] 127489000 |Has active ingredient| = < 105590001 |Substance|

descendantOf 373873005 |Pharmaceutical / biologic product| :
  [1 to 3] 127489000 |Has active ingredient| = descendantOf 105590001 |Substance|

The following expression constraint is satisfied only by products which have exactly one active ingredient:

A minimum cardinality of '0' indicates that there is no constraint on the minimum number of attributes that may match the given attribute criteria. For example, the following expression constraint is satisfied only by products with at most one active ingredient (i.e. the maximum cardinality is '1' and the minimum cardinality is unconstrained).

A maximum cardinality of '*' (or 'many') indicates that there is no constraint on the maximum number of attributes that may match the given attribute criteria. For example, the following expression constraint is satisfied only by products that have at least one active ingredient (i.e. the minimum cardinality is '1' and the maximum cardinality is unconstrained).

A cardinality of [0..*] should therefore never be used as this indicates that the given attribute is not being constrained in any way, and is therefore a redundant part of the expression constraint.

The default cardinality of each attribute, where not explicitly stated, is [1..*]. Therefore, the following two expression constraints are equivalent.

As mentioned above, only non-redundant defining attributes are included in the cardinality count. Therefore, the following postcoordinated expression:

will successfully satisfy the expression constraint:

This is because 299701004 | Bone of forearm| is a supertype of 62413002 | Bone structure of radius| and therefore the attribute 363698007 |Finding site| = 299701004 |Bone of forearm| is redundant.

When the attributes to which cardinality are applied can be grouped, but braces are not used in the expression constraint, the cardinality constrains the number of times the attribute may be included in any attribute group. For example, the following expression constraint is satisfied by any clinical finding whose definition has two or more non-redundant finding sites, irrespective of which attribute group they are contained in.

In contrast, when braces are placed around an attribute with a given cardinality, there must exist at least one attribute group for which the given cardinality is satisfied by attributes in that group. For example, the following expression constraint is satisfied by any clinical finding whose definition contains an attribute group with two or more non-redundant finding sites.

Minimum and maximum cardinalities may also be applied to attribute groups. A minimum attribute group cardinality of X constrains the valid clinical meanings to those which have at least (i.e. >=) X non-redundant attribute groups that match the given attribute group criteria. A maximum cardinality of Y constrains the valid clinical meanings to those which have at most (i.e. <=) Y non-redundant attribute groups that match the given attribute group criteria. For example, a cardinality of "[1..2]" indicates that all clinical meanings that satisfy the given expression constraint must have at least one and at most two attribute groups that match the given attribute group criteria.

The expression constraint below is satisfied only by products with one, two or three attribute groups, which each contain at least one active ingredient relationship.

Please note that the above expression constraint is equivalent to:

As with attribute cardinalities, a minimum cardinality of '0' indicates that there is no constraint on the minimum number of attribute groups that may match the given attribute group criteria. For example, the following expression constraint is satisfied only by products with at most one attribute group containing an active ingredient relationship (i.e. the maximum attribute group cardinality is '1' and the minimum attribute group cardinality is unconstrained).

A maximum cardinality of '*' (or 'many') indicates that there is no constraint on the maximum number of attribute groups that may match the given attribute group criteria. For example, the following expression constraint is satisfied only by products that have at least one attribute group containing an active ingredient relationship (i.e. the minimum attribute group cardinality is '1' and the maximum attribute group cardinality is unconstrained).

A cardinality of [0..*] should therefore never be used as this indicates that the given attribute group is not being constrained in any way, and is therefore a redundant part of the expression constraint.

As with attribute cardinality, the default attribute group cardinality, where not explicitly stated, is [1..*]. Therefore, the following four expression constraints are equivalent.

As mentioned above, only non-redundant defining attributes are included in the cardinality count. Therefore, the following postcoordinated expression:

will successfully satisfy the expression constraint:

This is because 299701004 | Bone of forearm| is a supertype of 62413002 | Bone structure of radius| and therefore the attribute group { 363698007 |Finding site| = 299701004 |Bone of forearm| } is redundant.

Attribute cardinalities and attribute group cardinalities can be used together to achieve a combined effect. For example, to represent the set of clinical findings which have no attribute groups that contain two or more finding site attributes (in the same attribute group), the following expression constraint can be used:

When a cardinality constraint is applied to a reversed refinement, it constrains the number of source concepts (matching the given criteria) for which each destination concept may be relevant attribute value.

For example, the following expression constraint represents the substances, which are the active ingredient of exactly three products.

If this expression constraint was executed against a simplified substrate containing the following seven relationships:

then the result would include only the concept .

Authoring SNOMED CT Expression Constraints can be performed using two main techniques:

1. Language-based authoring : This technique involves the author constructing a SNOMED CT Expression Constraint using one of the syntaxes defined in Chapter 5.

2. Form-based authoring : This technique involves the author entering values into separate fields of a form, and the clinical system automatically composing the values together into a syntactically correct SNOMED CT Expression Constraint.

Language-based authoring is useful for situations in which ad hoc expression constraints must be defined which don't necessarily conform to a consistent structure. For example, some expression constraints (e.g. those that define terminology bindings or predefined queries) may be authored by software developers during the design, development or customization of a clinical application. Other expression constraints (e.g. those used to define intentional reference sets or validation queries) may be defined by terminologists during the process of developing a SNOMED CT extension. Expression constraints may also be authored by users who wish to retrieve or analyse information stored in patient records using SNOMED CT (e.g. for clinical, epidemiological or research queries).

Storing SNOMED CT Expression Constraints in an expression constraint library may be done for a variety of purposes, including:

• To enable expression constraints to be re-executed (without re-authoring) after updates are made to the SNOMED CT substrate or the expression constraint itself;

• To provide a library of terminology binding constraints against which record instances will be validated;

This appendix provides examples of expressions (both precoordinated and postcoordinated) which satisfy each of the expression constraints that were introduced in https://github.com/SNOMED-Documents/snomed-expression-language/blob/main/appendix-a-examples-of-valid-expressions/broken-reference/README.md. This list of examples is not intended to be exhaustive, but rather to provide a representative sample to help clarify the meaning of each constraint. It is assumed that each particular usage of an expression constraint will clearly identify whether or not postcoordinated expressions are part of the valid substrate. Please refer to the SNOMED CT Languages Github repository for a set of text files containing each of these examples.

Provide Feedback

SNOMED CT Expression Constraints may also include comments inline within the constraint string to explain, describe or document different aspects of the expression constraints. Each comment begins with a forward slash directly followed by a star (i.e. "/") and ends with a star directly followed by a forward slash (i.e. "/"). Comments may be placed anywhere in an expression constraint where whitespace (i.e. "ws") or mandatory whitespace (i.e. "mws") is allowed.

Comments have no effect on the machine processable interpretation of an expression constraint, as they should be ignored during evaluation. For example, the following two expression constraints (the first with comments, and the second without), will evaluate to exactly the same set of concepts:

A comment may include both stars and forward slashes. However a star may never be directly followed by a forward slash within the middle of a comment, as this combination denotes the end of the comment.

This appendix provides a list of example aliases that may be used to specify a particular dialect in an ECL filter constraint. Please refer to the 'Dialect Filter' section on 6.8 Description Filters for more information on how these dialect aliases are used in ECL.

All dialect aliases should follow the ABNF syntax shown below. This format is designed to be compatible with BCP-47 (Internet Best Current Practice Specification), which ensures alignment with a range of other specifications - e.g. HTTP "accept-language" headers, and the HL7 FHIR "designation.language" data element.

dialectAlias = ( language [ "-" script ] [ "-" region ] [ "-" privateuse ] ) / privateuse

language = alpha alpha ; ISO 639-1 code (List of codes)

script = alpha alpha alpha alpha ; ISO 15924 code (List of codes)

region = alpha alpha ; ISO 3166-1 code ()

privateuse = "x" 1*("-" 1*8(alpha / digit) ) ; the clinical scope or context of use

The table below lists the valid 'dialect' filter values and their equivalent 'dialectId' filter values, for a selection of known language reference sets. To request the addition of a new dialect alias, please use the 'Feedback' button on the bottom of this page.

In this section we illustrate how a set of concepts can be filtered, using the top or bottom operators, to find the concepts that are the highest or lowest in the hierarchy within the set.

Two consecutive exclamation marks followed by a 'greater than' sign (i.e. "!!>") indicates that the expression constraint is satisfied by the concepts from the results of the subexpression that have the highest position in the hierarchy, relative to one another. In other words the set of concepts, that is the result of the subexpression, will be filtered by concepts that have no ancestors within that set.

For example the following expression constraint represents the highest, or most general, concepts in the hierarchy within the set of 363698007 |Finding sites| from the subtypes of 386617003 | Digestive system finding| .

The SNOMED CT Expression Constraint Language enables the intensional definition of a bounded set of clinical meanings. This is important for a number of use cases, including those described in this page.

Terminology Binding

Most Electronic Health Records (EHRs) are designed and developed using one or more information models, which describe the information that is collected, stored, communicated and displayed. Some information models are designed for a specific proprietary system, while others are based on a common health information standard (e.g. HL7 FHIR resource, HL7 CDA template, ISO 13606 archetype). Information models may also be defined using a wide variety of representations (e.g. UML class diagram, database table design, Archetype Definition Language, or XML Schema). Irrespective of the purpose, design and representation of the information models, however, the use of clinical terminology is an important part of making the models complete and useful.

Terminology binding provides the links between the information model and the terminology. These links may be used to constrain the set of possible values which can populate a given coded data element in the information model, or they may define the meaning of an information model artefact using the terminology. Terminology binding is an important part of supporting the following clinical information system functions:

• Data capture;

• Retrieval and querying;

• Information model library management; and

• Semantic interoperability.

To enable terminology binding to be defined using intensional rules, a formal language must be used. The SNOMED CT Expression Constraint Language can be used in this way to define terminology bindings which constrain the set of possible coded values within an information model.

Reference sets are a flexible, extensible SNOMED CT file structure used to support a variety of requirements for the customization and enhancement of SNOMED CT content. These include the representation of subsets, language preferences, or maps to/from other code systems.

Some reference sets (using the Query Specification type) allow a serialised query to represent the membership of a subset of SNOMED CT components. A query contained in this reference set is executed against the content of SNOMED CT to produce a subset of concepts, descriptions or relationships. This query is referred to as an intensional definition of the subset. It can be run against future releases of SNOMED CT to generate a potentially different set of subset members. The members of the resulting subset may also be represented in an enumerated form as a Simple Reference Set. An enumerated representation of a subset is referred to as an extensional definition.

The SNOMED CT Expression Constraint Language can be used in this way to represent the intensional definition of a subset of SNOMED CT concepts that can be enumerated as a Simple Reference Set.

SNOMED CT provides both hierarchies and formal concept definitions to allow a range of advanced query techniques. SNOMED CT queries can be performed over different sets of terminology artefacts (known as the substrate of the query), including:

• The precoordinated components distributed as part of the SNOMED CT international edition;

• The precoordinated components distributed by a local release centre as part of a national or local SNOMED CT edition;

• The postcoordinated expressions stored within an expression repository; or

The SNOMED CT Expression Constraint Language enables queries over SNOMED CT content to be expressed. These queries may be performed for a range of purposes, including the authoring and quality assurance of new SNOMED CT content, the design and development of extensional reference sets, and the design and display of SNOMED CT subsets in clinical user interfaces. While the language itself does not support querying over the full EHR content, the SNOMED CT Expression Constraint Language could be embedded within record-based query languages (such as SQL) to represent the terminological aspects of these queries.

The SNOMED CT Concept Model is the set of rules that determines the permitted sets of attributes and values that may be applied to particular types of concepts. There are also additional rules on the cardinality and grouping of each type of attribute. The SNOMED CT Concept Model includes the definition of the domain and range of each attribute. The domain is the set of concepts which are permitted to be used as the source of the attribute, while the range is the set of concepts which are permitted to be used as the target of the attribute. For example, the domain of the attribute is the descendants and self of , while the range is the descendants and self of The SNOMED CT Concept Model rules are represented in a computable form in the

SNOMED CT Expression Constraints can be automatically validated to ensure that they conform to a variety of rules, including:

• Expression constraints must conform to one of the syntaxes defined in Syntax Specification. Syntactic validation can be performed using an expression parser, as described in Parsing

• Expression constraints must conform to the concept model. This validation can be performed by comparing the parsed expression constraint against the rules defined in the SNOMED CT concept model

• All concept references included in the expression constraint must be valid. In most cases this means that the concept references must refer to active concepts in the given version and edition of SNOMED CT

• All concept references used to refer to attribute names must be a descendant of

• All concept references to which a memberOf function is applied must be a descendant of

Please note that some of these rules may not apply in all environments.

SNOMED CT is a clinical terminology with global scope covering a wide range of clinical specialties and requirements. The use of SNOMED CT expressions in Electronic Health Records (EHRs) provides a standardized way to represent clinical meanings captured by clinicians and enables the automatic interpretation of these meanings. SNOMED CT expressions are a structured combination of one or more concept identifiers used to represent a clinical idea in a logical manner. The provides a lightweight syntax for the representation of SNOMED CT expressions.

In contrast, a SNOMED CT Expression Constraint is a computable rule that can be used to define a bounded set of clinical meanings represented by either precoordinated or postcoordinated expressions. Expression constraints can be used as formal constraints on the content of a particular data element in an EHR, as the intensional definition of a concept-based reference set, as a machine processable query that identifies a set of matching precoordinated or postcoordinated expressions, or as a constraint that restricts the range of an attribute defined in the SNOMED CT concept model.

The purpose of this document is to define and describe a formal language for representing SNOMED CT Expression Constraints. A SNOMED CT Expression Constraint is a computable rule that defines a bounded set of clinical meanings represented by either precoordinated or postcoordinated expressions.

Two equivalent syntaxes are presented – a brief syntax, which is designed to be as compact as possible for interoperable communication between systems, and a long syntax, which introduces textual alternatives to the symbols from the brief syntax. There is also an ECL Core profile, which is a subset of the Expression Constraint Language, intended to reduce tooling requirements.

In this chapter, we state the requirements of the SNOMED CT Expression Constraint Language. These requirements are grouped into General SNOMED CT Language Requirements (which are shared by all SNOMED CT computable languages), Expression Constraint and Query Requirements, and Concept Model Requirements.

The general SNOMED CT language requirements include:

Requirement G.1 : Backward compatibility

The language must be backwardly compatible with any version of the language that has previously been adopted as an SNOMED International standard.

Requirement G.2 : Consistency

Each logical feature of the language should have a single, consistent meaning across all the languages in the SNOMED CT family of languages. Each logical feature should also have a consistent set of syntax representations.

A SNOMED CT Expression Constraint contains either a single focus concept, or a series of focus concepts joined by either conjunction, disjunction or exclusion. Each focus concept in an Expression Constraint is either a concept reference or a wildcard, and is normally preceded by either a constraint operator or a memberOf function. An Expression Constraint may also contain a refinement, which consists of grouped or ungrouped attributes (or both). Each attribute consists of the attribute name (optionally preceded by a cardinality, reverse flag and/or attribute operator) together with the value of the attribute. The attribute name is either a concept reference or a wild card. The attribute value is either an expression constraint or a concrete value (i.e. string, integer, decimal or boolean). Conjunction or disjunction can be applied at a variety of levels, including between expression constraints, refinements, attribute groups, and attributes. An expression constraint can also be followed by a dot and attribute name pair. One or more description filters may be applied to an expression constraint, which can include description identifier, module, effective time, active status, term, language, type, dialect and acceptability criteria. Similarly, one or more concept filters may be applied to an expression constraint, which can include definition status, module, effective time and active status criteria. Member filters may be applied to results of the memberOf function, and may include module, effective time, active status and specific refset field criteria. Finally, history supplements may be applied, which include an ECL query to specify the set of historical association reference sets to be used.

Figure 1 below illustrates the overall structure of an expression constraint using an abstract representation. Those parts of an expression constraint, which are in common with expressions, are shown with dotted lines to emphasise the new features (using solid lines) in the Expression Constraint Language. Please note that no specific semantics should be attributed to each arrow in this abstract diagram.

The simplest type of expression constraint contains a single concept optionally preceded by an expression constraint operator and/or membership function. Expression constraint operators (e.g. descendant of) traverse the hierarchical relationships in SNOMED CT to return the set of concepts that are directly or transitively connected to the focus concept. Membership functions return the set of concepts referenced by a reference set.

In this section we consider some of these simple examples.

Self

If no expression constraint operator or membership function is applied, the expression constraint is satisfied only by the specified concept. For example, the expression constraint below is satisfied only by the concept 404684003 | Clinical finding| .

404684003 |Clinical finding|

Please note that this expression constraint is equivalent to an expression that looks the same but is written in SNOMED CT Compositional Grammar.

Descendant of

A single 'less than' sign (i.e. "<") indicates that the expression constraint is satisfied by all descendants of the specified concept. The expression constraint below evaluates to the set of all subtypes (both direct children and transitive subtypes) of 404684003 | Clinical finding| .

The descendantOf function is primarily used on concepts, which serve as the 'grouper' of a set of values (e.g. | Clinical finding (finding)| , | Severities (qualifier value)| , | Unit (qualifier value)| ). The descendantOf function may also be applied to other concepts, or to nested expression constraints (as discussed in ).

Two consecutive 'less than' signs (i.e. "<<") indicates that the expression constraint is satisfied by all descendants of the specified concept plus the specified concept itself. The expression constraint below evaluates to the set of descendants of 73211009 | Diabetes mellitus| , plus the concept 73211009 | Diabetes mellitus| itself.

The descendantOrSelfOf function is primarily used for attribute values, which refer to a specific clinical value (e.g. 73211009 | Diabetes mellitus| , 73761001 | Colonoscopy| , 385055001 | Tablet dose form| ), but any specialization of this value is also acceptable. The descendantOrSelfOf function may also be applied to other concepts, or to nested expression constraints (as discussed in ).

A 'less than' sign directly followed by an exclamation mark (i.e. "<!") indicates that the expression constraint is satisfied by the set of proximal children of the specified concept. The children of a concept are those concepts that are the source of a non-redundant 116680003 | is a| relationship whose target is the given concept. The expression constraint below, represented using the brief syntax, evaluates to the set of immediate children of the concept 404684003 | Clinical finding| .

Please note that the childOf function may only be executed against a finite and pre-classified substrate, and that the results of this function are specific to the substrate used. The childOf function may also be applied to nested expression constraints (as discussed in ).

Two consecutive 'less than' signs directly followed by an exclamation mark (i.e. "<<!") indicates that the expression constraint is satisfied by the set of proximal children of the specified concept plus the specified concept itself. The children of a concept are those concepts that are the source of a non-redundant 116680003 | is a| relationship whose target is the given concept. The expression constraint below, represented using the brief syntax, evaluates to the set of immediate children of the concept 404684003 | Clinical finding| , plus the concept 404684003 | Clinical finding| itself.

Please note that the childOrSelfOf function may only be executed against a finite and pre-classified substrate, and that the results of this function are specific to the substrate used. The childOrSelfOf function may also be applied to nested expression constraints (as discussed in ).

A single 'greater than' sign (i.e. ">") indicates that the expression constraint is satisfied by all ancestors of the specified concept. The expression constraint below, using the brief syntax, evaluates to the set of all supertypes (both direct parents and transitive supertypes) of

Please note that the ancestorOf function may also be applied to nested expression constraints (as discussed in ).

Two consecutive 'greater than' signs (i.e. ">>") indicates that the expression constraint is satisfied by all ancestors of the specified concept plus the specified concept itself. The expression constraint below evaluates to the set of ancestors of 40541001 | Acute pulmonary edema| , plus the concept 40541001 | Acute pulmonary edema| .

Please note that the ancestorOrSelfOf function may also be applied to nested expression constraints (as discussed in ).

A 'greater than' sign directly followed by an exclamation mark (i.e. ">!") indicates that the expression constraint is satisfied by the set of proximal parents of the specified concept. The parents of a concept are those concepts that are the target of a non-redundant |is a| relationship whose source is the given concept. The expression constraint below, represented using the brief syntax, evaluates to the set of immediate parents of the concept 40541001 | Acute pulmonary edema| .

Please note that the parentOf function should only be executed against a finite and pre-classified substrate, and that the results of this function are specific to the substrate used. The parentOf function may also be applied to nested expression constraints (as discussed in ).

Two consecutive 'greater than' signs directly followed by an exclamation mark (i.e. ">>!") indicates that the expression constraint is satisfied by the set of proximal parents of the specified concept plus the specified concept itself. The parents of a concept are those concepts that are the target of a non-redundant |is a| relationship whose source is the given concept. The expression constraint below, represented using the brief syntax, evaluates to the set of immediate parents of the concept 40541001 | Acute pulmonary edema| , plus the concept 40541001 | Acute pulmonary edema| itself.

Please note that the parentOrSelfOf function should only be executed against a finite and pre-classified substrate, and that the results of this function are specific to the substrate used. The parentOrSelfOf function may also be applied to nested expression constraints (as discussed in ).

In it's basic form the memberOf function evaluates to the set of concepts that are referenced by the given reference set. The concepts from the referencedComponentId field of active reference set members are returned. The concept themselves may be active or inactive.

Please note that this function may be applied only to reference sets whose referenced components are concepts. The SNOMED CT Expression Constraint Language does not support use of the memberOf function on reference sets whose referencedComponents are not concepts (i.e. descriptions or relationships).

The memberOf function is represented in the brief syntax using a 'caret' character (i.e. "^") and is usually followed by a single concept id for a concept-based reference set. For example, the following expression constraint is satisfied by the set of concepts which are members of

The expression constraints above both return the values in the referencedComponentId field of the given reference sets. However, it is also possible to specify one or more fields, whose values will be returned, by including the relevant field names is square brackets after the memberOf operator ("^" or "memberOf"). For example, the following expression constraint is equivalent to the brief syntax example above.

The value of other fields can also be returned by an expression constraint . For example, the following expression constraint will return the targetComponentId values (i.e. the 'Entire' anatomy concepts) from the 734138000 | Anatomy structure and entire association reference set| .

It is also possible to return the values of more than one field in a reference set (

To return all the non-metadata fields of a referenceSet (i.e. the values of the referencedComponentId and additional fields), a wildcard (i.e. "" in the brief syntax, and "" or "Any" in the long syntax) can be used. For example, the following expression constraint will return the referencedComponentId, mapGroup, mapPriority, mapRule, mapAdvice, mapTarget and correlationId for each row of the 447562003 | ICD-10 complex map reference set| .

For more information on the use of reference set field names in ECL, please refer to .

Please note that it is also possible to apply the memberOf function to an expression constraint that returns a set of concept-based reference set concepts. For more information, please refer to .

And for information about applying filter constraints to reference set members, please refer to .

A single 'star' (i.e. "*") may be used in the place of a concept reference to represent any concept in the substrate. The expression constraint below evaluates to the set of all concepts in the given substrate.

This wildcard character (or 'ANY' keyword) may be used anywhere within an expression constraint that a concept reference may be used. In many situations, the wildcard is equivalent to the following expression constraint:

However, some situations exist in which the concept 138875005 | SNOMED CT concept| is not included in the substrate, and therefore cannot be used to determine the full set of concepts available. In other cases, the single character wildcard may serve as a convenient shortcut for the longer expression constraint above.

Please note that the following three expression constraints evaluate to the same set of concepts:

The two expression constraints below evaluate to all concepts in the substrate minus the root concept:

And the two expression constraints below evaluate to all non-leaf concepts in the substrate:

Finally, the expression constraint below evaluates to all concepts that are referenced by any reference set in the substrate:

The refsetContaining constraint includes a set of concepts. The constraint is satisfied the set of reference sets that contain at least one of the given concepts. Please note that this function may be applied only to reference sets whose referenced components are concepts. The SNOMED CT Expression Constraint Language does not support use of the refsetContaining function on reference sets whose referencedComponents are not concepts.

The refsetContaining function is represented in the brief syntax using a 'caret' character (i.e. "^") immediately followed by an uppercase 'R' and followed by either a single concept or a nested expression constraint.

For example, the following expression constraint is satisfied by the set of refset concepts that have an active member with a referenced component of the concept 73211009 |Diabetes mellitus|:

If an alternate identifier exists for a concept, in an identifier scheme other than SNOMED CT, then this can be used to refer to that concept (see ). For example there may be SNOMED CT concept for "Type of hemoglobin in blood at point in time" with an alternate identifier with the scheme alias "LOINC" and the code "54486-6":

The alternate identifier code can be surrounded by double quotes. Quoting may be necessary to ensure correct parsing of the constraint depending on the characters used in the code:

Please note: ECL is always evaluated against SNOMED CT concepts. When you run a query using alternate identifiers from another code system only concepts that are in the SNOMED CT representation of that other code system will be returned. For example the descendants of a concept in the SNOMED CT version of a code system is likely to be different from the code system of the alternate identifier.

Expression constraints can be nested in a variety of ways to form nested expression constraints. These nested expression constraints use subexpressions, enclosed in round brackets, in the place of a simple concept reference.

Nested expression constraints can be created by:

• Applying constraint operators to an expression constraint

• Applying the memberOf function to an expression constraint

• Combining expression constraints using binary operators

• Adding dotted attributes to expression constraints

• Adding refinements to expression constraints

• Using expression constraints to represent valid attribute names

• Using expression constraints to represent valid attribute values

In this section, we describe each of these approaches to creating nested expression constraints.

Nested expressions are supported in ECL Core. The examples that use attribute cardinality are not supported.

When a constraint operator is applied to an expression constraint, the resulting set of matching expressions is the union of applying the constraint operator to each of its members.

For example, the following expression constraint represents all the members of the 700043003| Example problem list concepts reference set| plus the union of the descendants of each of these members.

Please note that the brackets in the above expression constraint are optional. In this particular case, removing the brackets does not change the meaning of the constraint.

As another example, the following expression constraint represents the set of all descendants of the |Finding site| of |Fracture of bone| .

Because the 363698007| Finding site| of 125605004 | Fracture of bone| is 272673000 | Bone structure| , the above expression constraint is equivalent to:

Please note that this is not the same as the expression constraint:

which refers to the set of 363698007 | Finding site| values for any descendant of 125605004| Fracture of bone| , and is instead equivalent to:

See the subsection on dotted attributes for more information about expression constraints of this form.

The memberOf function may also be applied to an expression constraint that returns a set of concept-based reference set concepts. When this is done, the nested expression constraint (to which the memberOf function is applied) must always be enclosed in round brackets.

For example, the expression constraint below is satisfied by the set of concepts which are members of any subtype of 450973005 | GP/FP health issue reference set| . In other words, it represents the union of applying the memberOf function to each of the descendants of | GP/FP health issue reference set| .

The expression constraint above evaluates to the same set of concepts as applying the memberOf function to each individual subtype of 450973005 | GP/FP health issue reference set| and then taking the union of these sets. Therefore, when applied to the 20170131 international edition of SNOMED CT, the above expression constraint evaluates to the same set of concepts as the following expression constraint.

When conjunction (i.e. AND), disjunction (i.e. OR) or exclusion (i.e. MINUS) are applied to one or more complex subexpression constraints, brackets are usually required to nest the subexpression constraints.

For example, the following expression constraint uses brackets around the first complex operand ( < 404684003 |Clinical finding| : 363698007 |Finding site| = << 39057004 |Pulmonary valve structure| ) to apply the 'AND' operator to two expression constraints.

An equivalent expression constraint can be achieved by swapping the order of the operands, as shown below.

Similarly, if both sides of the compound expression are complex expression constraints, then brackets may be required on both sides. For example:

Dotted attributes can also be applied to a nested subexpression constraint. When this is done, the resulting subexpression represents the union of the values of the given dotted attribute for any expression that matches the given nested subexpression constraint.

For example, the following expression constraint represents the set of all substances that are the |Direct substance| of a |Specimen collection| procedure that is |Using device| equal to a subtype (or self) of |Catheter| .

When executed against the 20170131 international edition of SNOMED CT, the above expression constraint matches the following three concepts:

• 78014005 |Urine|

• 87612001 |Blood|

• 4635002 |Arterial blood|

As mentioned in , it is possible to apply refinements to nested expression constraints. When a refinement is applied to a complex subexpression constraint, the subexpression constraint must be enclosed in brackets.

For example, the expression constraint below represents the set of all clinical findings and events which occur after some procedure.

In some cases, the valid set of attribute names can be represented using an expression constraint. For example, the expression constraint below represents the set of bone fractures that have no additional defining attributes (besides |Finding site| and |Associated morphology| ).

Within this expression constraint, the subexpression:

-represents the set of attributes that must match the given refinement condition (in this case, these attributes must not appear in the concept definition of matching concepts due to the cardinality of [0..0]).

Similarly to the SNOMED CT Compositional Grammar, it is also possible to nest expression constraints within an attribute value. Please note that when the attribute value is a simple expression constraint (as per the above examples), brackets are not required around the value. However, when the attribute value is either an expression constraint with a refinement, or a compound expression constraint with a binary operator, then brackets must be placed around the attribute value. For example, the following expression constraint represents the set of clinical findings which are associated with another clinical finding that has an associated morphology of 'infarct' (or subtype).

In this example, brackets are required around the nested attribute value.

In this section, we illustrate how filters can be applied to a set of reference set members to restrict the matching values.

Overview

Member filters provide the ability to filter the rows of a reference set, based on the value of specific fields in the reference set. These filters are specified inside double curly braces, and begin with the letter "M".

Member Field Filters

To apply a member filter to one or more reference sets, the fields of those reference sets are matched against specified criteria. Only reference set members whose field values match the given criteria will be included in the results.

For example, the following expression constraint will match all referencedComponentIds (i.e. SNOMED CT concept id) from the active 447562003 | ICD-10 complex map reference set| rows, which map to the ICD-10 code "J45.9" (as a word prefix). When applied to the July 2021 international edition, this will match 59 concepts, including 195967001 | Asthma| , 707447008 | Exacerbation of severe persistent asthma (disorder)| and 401193004 | Asthma confirmed (situation)| .

Please note that by default, a word-prefix-any-order match is performed. Therefore the following expression constraint will match on rows that have a mapTarget of "J45.0", "J45.1",..., "J45.8", "J45.9" etc.

Alternatively, a wildcard search can be performed, to achieve similar results. For example, the expression constraint below will match on rows that have a mapTarget starting with "J45" followed by zero or more other characters (e.g. "J45.0", "J45.1",...,"J45.8", "J45.9")

To achieve an exact string match, a wildcard search (without an '*') can be used. For example, the expression constraint below will match only rows that have a mapTarget of "J45.9".

For more information on wildcard and word-prefix-any-order searching, please refer to .

Multiple field constraints can be applied within a reference set member filter. For example, the following expression constraint will return the referencedComponentId from the 447562003 | ICD-10 complex map reference set| rows, which have a mapGroup of "2", a mapPriority of "1" and a mapTarget of "J45.9".

Other comparison operators may also be used, when defining field criteria. The available operators depend on the field's datatype, as shown in the table below.

In addition, reference set fields of type 'string' may be filtered using the same word-prefix-any-order and wildcard techniques used by the description term filters. For example, the following expression constraint will match all referencedComponentId from the active 447562003 | ICD-10 complex map reference set| rows that have a mapGroup not equal to 2, a mapPriority less than 2, and a mapTarget that starts with the letter "J".

Member filters can also be used in combination with the memberOf function to support the selection of other fields of a reference set (see ). For example, the following expression constraint returns the active SNOMED CT concept that is considered to be the same as the inactive concept 67415000 | Hay asthma|

For more information on the use of reference set field names in ECL, please refer to .

For additional ways of specifying queries over the historical association reference sets, please refer to .

Module filters enable an expression constraint to match on only those rows of a reference set that belong to a specified module. Module filters use the keyword "moduleId" with a concept reference that is < 900000000000443000 |Module| .

For example, the expression constraint below matches all members of the 900000000000534007 | Module dependency reference set| that belong to an Australian maintained module.

Effective time filters enable an expression constraint to match on only those rows of a reference set with an effectiveTime that matches the specified criteria.

For example, the following expression constraint matches all rows of the 816080008 | International Patient Summary| which have been updated since 31st July 2021 (inclusive). Note that the referencedComponentId is the only field returned.

Active filters enable an expression constraint to match on only those members of a reference set with a matching active status. Reference set rows are either active (i.e. active = 1 or active = "true"), inactive (i.e. active = 0 or active = "false"), or either (i.e. active = "*"). By default, only active members of a reference set are included in the substrate.

For example, the following expression constraint returns the inactive members of the 816080008 | International Patient Summary| .

And the following expression constraint returns both the active and inactive members of the 816080008 | International Patient Summary| .

Please note that this filter uses the active status of the reference set member. It does not consider the active status of the component that the member references. For example an active reference set member may refer to an inactive concept.

SNOMED CT Expression Constraints can be shared between systems and users via a number of methods, including:

• Exchanging an expression constraint string which conforms to the Brief Syntax of the Expression Constraint Language

• Exchanging an expression constraint identifier, which can be unambiguously interpreted by the receiving system. If this approach is adopted it is recommended that an expression constraint repository is used to ensure that both the sending and receiving systems have a shared and consistent understanding of the meaning of each expression constraint.

Irrespective of the method used, it is recommended that the Brief Syntax of the SNOMED CT Expression Constraint Language be used as the normative syntax for the interoperable sharing of expression constraints.

In the SNOMED CT Release File Specification (http://snomed.org/rfs), SNOMED International specifies a set of reference set types with their own specific properties (e.g. an attribute value type reference set). Each reference set that is developed to conform to a specified type is defined as a subtype of the associated reference set type concept (e.g. 900000000000480006 | Attribute value type reference set| ). All reference sets of a given type are populated with members using the same data structure - with the same set of field names in the same order. SNOMED International uses these reference set type data structures (as defined in the ) as the release file format for all reference sets of that type.

All reference set type concepts are a subtype of , and have an associated set of reference set descriptors in the . Some reference set type concepts are organised under one or more reference set groups (e.g. ), which represent a group of reference set types (often with different data structures).

In the Expression Constraint Language (v2.0+) reference set field names are used to indicate which field values to return, and to filter reference set members based on specific field criteria. The first (non-metadata) field in every reference set (in order '0') must always be 'referencedComponentId'. For reference sets, which are a subtype of an international reference set type, the additional field names defined in the SNOMED CT Release File Specification must be used. In all other cases, the additional field names may use any latin-script alphabetic character (a-z or A-Z) defined by the owner of the corresponding reference set type concept. Owners of a reference set type are encouraged to explicitly document these field names, keep them unchanged and publish a machine readable representation of these (following the format used below). In the absence of this, the column name from the corresponding RF2 file (with all whitespace removed) will be used.

This appendix provides examples of expressions (both precoordinated and postcoordinated) which do not satisfy the given expression constraints from . This list of examples is not intended to be exhaustive, but rather to provide a useful sample to help clarify the meaning of these constraint. Please refer to the for a set of text files containing each of these examples.

Parsing is the process of analysing a string of characters according to the rules of a formal grammar. Parsing a SNOMED CT Expression Constraint involves processing the expression constraint string using one of the ABNF syntax specifications defined in Chapter 5, and breaking it into its constituent parts. This creates a representation of the expression constraint that can be further processed. Parsing an expression constraint is required to perform syntactic validation, concept model validation or execution. It should be noted, when parsing, that all keywords in the language are case insensitive.

A number of parser development tools are available which can generate a parser from a context-free grammar written in ABNF, such as the one defined in this document. These tools include:

• APG

• aParse

• abnfgen

Please note, the ABNF syntax defined in this specification was tested using the APG Parser Generator.

Other non-ABNF parser generators are also available which can be used with an alternate syntax representation – for example:

• ANTLR

• XText

• ACE

Some of these tools (e.g. XText and ACE) can also be used to generate authoring environments with features such as syntax highlighting and autocompletion.

Alternatively, an expression constraint parser can be created manually using a programming language such as Perl or C++.

The Expression Constraint Language is a formal syntax for representing SNOMED CT expression constraints. Expression constraints are computable rules used to define a bounded set of clinical meanings represented by either precoordinated or postcoordinated expressions. Expression constraints can be used to restrict the valid values for a data element in an EHR, as the intensional definition of a concept-based reference set, as a machine processable query that identifies a set of matching expressions, or as a constraint that restricts the range of an attribute defined in the SNOMED CT concept model.

This document defines and describes the current version of the Expression Constraint Language - ECL v2.3.

The following ABNF definition specifies the ECL Core Syntax, a subset of the SNOMED CT Expression Constraint Language. This ABNF syntax and the ANTLR syntax is maintained in the SNOMED Expression Constraint Language GitHub repository.

SNOMED CT Expression Constraints must be evaluated against a given SNOMED CT substrate in order to instantiate the matching set of concepts or expressions. There are a number of possible implementation strategies for the execution of SNOMED CT Expression Constraints, which depend in part on the storage format of the substrate. For example:

• Store SNOMED CT in a relational database, and translate each SNOMED CT Expression Constraint into one or more SQL statements;

• Store SNOMED CT in an RDF store, and translate each SNOMED CT Expression Constraint into a SPARQL query;

• Store SNOMED CT in an XML database, and translate each SNOMED CT Expression Constraint into one or more XQL statements;

• Write a bespoke query execution engine (e.g. in Java or C++) to return matching concepts or expressions.

Each of these strategies requires that the expression constraints are first parsed (and preferably validated) prior to execution.

ECL execution is usually delegated to a terminology server. There are many open source and commercial offerings available, see .

In this section, we illustrate how description filters can be applied to expression constraints to further restrict the matching concepts.

Overview

Description filter constraints provide the ability to limit the set of concepts, that satisfy a given expression constraint, based on the descriptions associated with each concept. Only concepts that have at least one matching description for each filter criteria will be included in the set of matching concepts. Descriptions can be filtered based on their term, type, language, dialect, acceptability in a given dialect, module, effectiveTime, active status and description identifier. Description filters are specified inside double curly braces, and optionally being with the letter "D". Any filter that does not specify its type is, by default, assumed to be a description filter.

In the following sections, we explain each type of description filter criteria.

Term Filter

Term filters enable an expression constraint to match on only those concepts with an associated description whose term matches the given search term. For example, the following expression constraint is satisfied by SNOMED CT concepts with a description matching the search terms "heart" and "att". This expression constraint works like a term search performed in a SNOMED CT browser. Please note that the "D" (either upper or lower case) at the start of the filter indicates that this is a description filter constraint, rather than a concept filter constraint (see Concept Filters). If the type of a filter constraint is not specified (as in most of the examples below), then it is assumed that the constraint is a description constraint.

By default, term filters match using a word-prefix-any-order match technique. This means that each string value in the search term must match the start of a word in the concept's description term, but that these words may appear in any order. This word-prefix-any-order match technique can be explicitly specified in the term filter, using the keyword "match:" before the search term. For example, the following four expression constraints are equivalent, and are each satisfied only by diseases with a description term that includes both a word starting with "heart" and a word starting with "att" (in any order).

To indicate that a matching description may match either one search term or another, a search term set may be used.

The example below matches only those diseases with a description term containing either a word starting with "heart" or a word starting with "card" (or both).

The other technique that may be used is a wildcard search. This technique is specified using the keyword "wild:" and matches the search term in the expression constraint against the entire candidate description term (rather than just individual words). An asterisk ('*') is used as a wildcard to indicate that any (zero to many) characters may appear in the given position. This filter is case-insensitive.

For example, the expression constraint below will match only diseases with a description term starting with "cardi" and ending with "opathy" with any number of characters between. This term filter would therefore match on terms such as "Cardiopathy", "cardiomyopathy" and "cardiac channelopathy", but would not match on terms like "atrial cardiopathy" or "Cardiomyopathy (disorder)".

Please note that to perform an exact string match on an entire term, a wildcard search without a wildcard can be used (e.g. term=wild:"cardiopathy"). For example, the following expression constraint will match only diseases with a description term that exactly matches the full string "cardiopathy". This expression constraint will therefore match the concept (with synonym "Cardiopathy"), but will not match the concept (with synonym "Atrial cardiopathy")

It is also possible to mix the match techniques in a search term set. For example, the expression constraint below will match those diseases with a description term that either contains a word starting with "gas", or ending with "itis" - e.g. "gastric flu", "gastritis", or "tonsillitis".

If more than one filter is applied, then all filters (surrounded in double braces) must match at least one description of a concept, for that concept to satisfy the constraint. The descriptions that match each of the filters can either be the same description, or different descriptions on the same concept.

The expression constraint below matches those diseases which have both a description that contains a word starting "eye" and a description that ends with "itis". For example, this constraint would match the concept 9826008 | Conjunctivitis (disorder)| (with synonyms "Pink eye disease" and "Conjunctivitis") and the concept 15680481000119104 | Viral conjunctivitis of bilateral eyes (disorder)| (with synonyms "Bilateral viral conjunctivitis" and "Viral conjunctivitis of both eyes"), but would not match the concept 45261009 | Viral conjunctivitis (disorder)| (which does not have a synonym matching the word prefix "eye").

Wildcard search can be used to find compound words, in English or germanic languages like Danish.

Or other partial string matching where perhaps a user doesn't recall the specific spelling of the whole word.

Language filters enable an expression constraint to match on only those concepts with a matching description in a specified language. Language filters use the keyword "language", followed by a comparison operator (e.g. "=" or "!="), and the ISO 639-1 two-character language code (in upper or lowercase).

The expression constraint below matches only those diseases with a Swedish description containing the word prefix "hjärt" - e.g. 41884003 | hjärtpolyp| from the Swedish Edition (20200531).

The expression constraint below matches only those diseases with a Swedish description containing the word prefix "hjärt" and an English description containing the word prefix "heart" - e.g. 84114007 | hjärtsvikt| (with English synonym "Heart failure") from the Swedish Edition (20200531).

Type filters enable an expression constraint to match on only those concepts with a matching description of a specified type. Type filters may either use the keyword "type" with the values "fsn", "syn" or "def", or may use the keyword "typeId" with a concept value that is < 900000000000446008 |Description type| .

The following table lists the valid description type keywords in both the brief and full syntax, and their equivalent concept reference alternatives. Please note that the full syntax accepts both the brief and full syntax keywords. If additional description types are required, these must be specified in a filter using the 'typeId' keyword with the corresponding concept reference.

For example, the expression constraint below matches all the subtypes of 56265001 | Heart disease| , that have a fully specified name containing the word prefix "heart".

The following two expression constraints are equivalent, and both match only the subtypes of 56265001 | Heart disease| , which have a Swedish synonym containing the word prefix "hjärt".

The two equivalent expression constraints below match the subtypes of 56265001 | Heart disease| , which either have a synonym containing the word prefix "heart", or a fully specified name containing the word prefix "heart".

Dialect filters enable an expression constraint to match on only those concepts with a matching description in a specified language reference set. Dialect filters may either use the keyword "dialect" with a value that represents a valid alias for a specific language reference set, or may use the keyword "dialectId" with a concept value that is < 900000000000506000 |Language type reference set| . Please refer to for a selection of valid dialect aliases for known language reference sets.

For example, the two equivalent expression constraints below will match all subtypes of 64572001 | Disease | that have a description in the Australian English language reference set.

The expression constraint below matches all diseases with a description in the New Zealand English language reference set that has a word starting with "cardio".

In some situations, multiple language reference sets need to be used together to identify an appropriate set of concepts. A filter constraint may include a list of dialects to specify that a matching description may belong to any of the given language reference sets.

For example, the following expression constraint matches all diseases that have a description in either the en-nhs-clinical or en-nhs-pharmacy language reference sets, where that description contains a word starting with the prefix "card".

Acceptability filters enable an expression constraint to match on only those concepts with a matching description that has the specified acceptability in the specified language reference set. Acceptability filters must always be applied to a specified dialect. As such, they are represented by placing the required acceptability in brackets after the value of the dialect filter. Acceptabilities can be indicated using either one of the keywords below, or using a concept value that is < 900000000000511003 |Acceptability| . The following table lists the valid acceptability keywords in both the brief and full syntax, and their equivalent concept reference alternatives. Please note that the full syntax accepts both the brief and full syntax keywords.

For example, the following two expression constraints both match all descendants of disease with a description that matches the word prefix 'box', has the type 'synonym', and has an acceptability of 'preferred' in the en-us language reference set. In other words, this expression constraint matches diseases with a US English preferred term that uses the word prefix 'box'.

Multiple dialect filters may be used with different acceptabilities applied to each. For example, the expression constraint below matches on diseases, which have a synonym with word prefix "box" that is preferred in the en-nhs-clinical language reference set and is acceptable in the en-gb language reference set.

To support alternative acceptabilities in more than one language reference set, a dialect set can be used. For example, the following two equivalent expression constraints match on diseases, which have a synonym with word prefix "box" that is either preferred in the en-gb language reference set or preferred in the en-nhs-clinical language reference set.

Filters can use negation in a number of ways. The simplest approach is to use the 'not equal to' comparison operator (e.g. "!=") before the value.

For example, the following expression constraint matches on subtypes of 125605004 | Fracture of bone| that do not use the word prefix "fracture" in their US English preferred term.

If we remove the type and acceptability filters, as shown below, the remaining expression constraint matches on those subtypes of 125605004 | Fracture of bone| which have any US English description that does not contain the word prefix "fracture". Concepts including 263171005 | Fractured nasal bones| (with synonym "Broken nose") will match the constraint below.

To find the set of concepts, for which all descriptions match some specified criteria, the expression constraint must use the MINUS operation to exclude concepts that have a non-matching description. For example, the expression constraint below matches all subtypes of 125605004| Fracture of bone| , for which every description contains the word prefix "fracture". Please note that the filter only applies to the descendants of 125605004 | Fracture of bone| (i.e. the subexpression directly proceeding the filter).

This expression constraint can be simplified to the equivalent one below, using the wildcard character '*' (which represents any concept in the substrate).

Using a similar principle, the expression constraint below matches all concepts that do not have a preferred term specified in the en-nz language reference set.

Description module filters enable an expression constraint to match on only those concepts with a matching description that belongs to a specified module. Module filters use the keyword "moduleId" with a concept reference that is < 900000000000443000 |Module| .

For example, the expression constraint below matches all subtypes of 195967001 | Asthma| with a description that belongs to the US National Library of Medicine maintained module.

And the expression constraint below matches all subtypes of 404684003 | Clinical finding| with a definition that belongs to the international core module.

Description effective time filters enable an expression constraint to match on only those concepts with a description that has an effectiveTime matching the specified criteria. Effective time filters may use any of the date comparison operators shown below:

Please note that the value of an effective time filter (if present) must be a 8 digit date, formatted according to ISO 8601's basic calendar date format (i.e. YYYYMMDD). If the effectiveTime of the description in the substrate includes a time and/or time zone designator, these should be ignored when performing the comparison.

For example, the following expression constraint matches all subtypes of 125605004 | Fracture of bone| with a description that has an effective time of 31st January 2021.

And the following expression constraint matches all subtypes of 125605004 | Fracture of bone| with a description that has any effective time that is not 31st January 2021.

Similarly, greater than, less than, greater than or equals and less than or equals operators may be used in an effectiveTime filter. For example, the following expression constraint matches all subtypes of 125605004 | Fracture of bone| with a description that has an effectiveTime of 31st July 2019 or later (i.e. more recent).

And the following expression constraint matches all subtypes of 125605004 | Fracture of bone| with a description that has an effective time of 31st July 2019 or earlier.

The effectiveTime filter can also use sets of effective times. For example, the following expression constraint matches all subtypes of 125605004 | Fracture of bone| with a description that has an effectiveTime of either 31st January 2019, 31st July 2019, 31st January 2020, or 31st July 2020.

And the expression constraint below matches all subtypes of 125605004 | Fracture of bone| with a description, which does not have any of the following effective times: 31st January 2019, 31st July 2019, 31st January 2020 or 31st July 2020.

To match concepts with unpublished descriptions, to which an effectiveTime has not been assigned, an effectiveTime value of "" can be used. For example, the following expression constraint matches all subtypes of 125605004 | Fracture of bone| with a description to which an effectiveTime has not yet been assigned.

Please note that description effectiveTime filters, which use the comparison operators "<" and ">", will not match any descriptions with an effectiveTime = "".

Description active filters enable an expression constraint to match on only those concepts with a description that has a matching active status. Descriptions are either active (i.e. active = 1 or active = "true"), inactive (i.e. active = 0 or active = "false") or either (i.e. active = "*"). By default, only active descriptions are included in the substrate.

For example, the following expression constraints return all concepts in the International Patient Summary reference set, which have an active description.

The following expression constraints return all concepts in the International Patient Summary reference set, which have an inactive description.

And the following expression constraint returns all concepts in the International Patient Summary reference set, which have either an active or an inactive description.

Description id filters enable an expression constraint to match on only those concepts with a description that has a matching description identifier. For example, the following expression constraint matches any concept, which has an associated description with the identifier "3032638017". The only concept that matches this expression constraint is 707444001 | Uncomplicated asthma (disorder)| .

Description id filters can also be applied to other expression constraints, to check whether the concept with the matching description id is in a given set of concepts. For example, the following expression constraint will match any descendant of 195967001 | Asthma (disorder)| , which has a description with identifier "3032638017". This can be used to check if the concept with the given description id is a descendant of 195967001 | Asthma (disorder)| .

Description id filters may also include a set of description identifiers. The following expression constraint will match any descendant of 195967001 | Asthma (disorder)| , with a description whose identifier is either "1208972017", "2674140012" or "3043971012".

Please note that inactive concepts can have active descriptions, so the description id filter can be applied after inactive concepts are added to the query results via a history supplement. For example, the following expression constraint matches any descendant of the concept 195967001 | Asthma (disorder)| , or any inactive concept that is associated with a descendant of 195967001 | Asthma (disorder)| via an historical association, as long as the concept has a description with the identifier "264553015". The only concept that matches this expression constraint is the inactive concept 170644007 | Mild asthma| .

For more information on history supplements, please refer to .

Concept filter constraints provide the ability to limit the set of concepts that satisfy a given expression constraint, based on the properties of each concept. Only concepts with properties that match the criteria specified in the concept filter constraint will be included in the set of matching concepts. Concepts can be filtered based on their definition status, module, effectiveTime, and active status. In the following sections we explain each of these concept filter criteria.

Definition status filters enable an expression constraint to match on only those concepts with a matching definition status. Definition status filters may either use the keyword 'definitionStatus' with the values "defined" or "primitive", or may use the keyword "definitionStatusId" with a concept value that is < 900000000000444006 |Definition status| .

The following table lists the valid definitionStatus tokens and their equivalent definitionStatusId concept reference alternatives. If additional definition statuses are required, these must be specified in a filter using the 'definitionStatusId' keyword with the corresponding concept reference.