1. SNOMED CT Computable Languages Project Group
Wednesday 26th April 2017
Room: Trafalgar
Linda Bird
Head of Product Support

2. Agenda Background Computable languages overview
Compositional grammar (SCG)
Expression constraint language (ECL)
Query language (QRL)
Template syntax (STS)
URI standard language extensions
SNOMED CT template syntax - review
Use cases
Expression templates
Expression constraint templates
SNOMED CT Computable Languages Project Group

3. Background – Motivation
We needed a consistent family of computable languages to support SNOMED CT related activities, including:
Defining postcoordinated clinical meanings
Authoring precoordinated clinical meanings
Representing the SNOMED CT concept model
Binding SNOMED CT to information models
Linking other code systems to SNOMED CT
Defining intensional reference set
Querying SNOMED CT
Querying SNOMED CT encoded health record data

4. Background – Computable Languages
SNOMED CT Compositional Grammar (SCG)
Defining postcoordinated clinical meanings
Linking other code systems to SNOMED CT
SNOMED CT Expression Constraint Language (ECL)
Representing the SNOMED CT concept model
Binding SNOMED CT to information models
Defining intensional reference set
Querying SNOMED CT and encoded health record data
SNOMED CT Query Language (QRL)
As per ECL – advanced uses
SNOMED CT Template Syntax (STS)
Authoring precoordinated clinical meanings

5. Background – Computable Languages
SNOMED CT Compositional Grammar (SCG)
Define a clinical meaning using a SNOMED CT expression
SNOMED CT Expression Constraint Language (ECL)
Constrain the set of possible concepts or expressions
SNOMED CT Query Language (QRL)
Query over SNOMED CT RF2 content
SNOMED CT Template Syntax (STS)
Incorporate slots to be filled at a later time
Expression, constraint or query template

6. Compositional Grammar (SCG)
Defines clinical meanings in a way that is both computer processable and human readable (
History
2010: Adopted as an IHTSDO standard (v1.0)
2015: Revised to allow concrete values & definition status (v2.3.1)

7. Compositional Grammar (SCG)
Spray suspension
|Spray dose form| |Drug suspension|
Right hip
|Hip joint| : |Laterality| = |Right|
Appendectomy
|Procedure| : |Method| = |Excision - action|, |Procedure site| = |Appendix structure| }
Amoxycillin 500 mg capsule (20 capsules)
|Amoxycillin 500mg capsule| : { |Has pack size magnitude| = #20, |Has pack size units| = |Capsule| }

8. Expression Constraint Language (ECL)
Specifies computable rules that define bounded sets of clinical meanings (
History
Designed to be consistent with Compositional Grammar
2013/2014: Drafts developed
2015: First version published (v1.0)
2016: Revised to incorporate implementation feedback (v1.2)

9. Expression Constraint Language (ECL)
Example: Lung disorders with morphology a type of edema
< |disorder of lung| :
|associated morphology| = << |edema|
Valid Concepts:
Concept Id
Term
Toxic pulmonary edema
Postoperative pulmonary edema
Pulmonary edema
Silo-fillers’ disease
Acute pulmonary edema
Postimmersion-submersion syndrome
Adult respiratory distress syndrome
SNOMED CT Expression Constraints, on the other hand, are computable rules that can be used to define a bounded set of clinical meanings.
#click
So, for example, to represent the set of lung disorders where the associated morphology is a type of edema, you can write “Descendant of Disorder of lung, with an associated morphology which is a descendant or self of edema.” The single less than sign indicates that matching concepts must be a 'descendant' of disorder of lung, and the double less than sign indicates that matching attributes values can either be a descendant of edema or the concept 'edema' itself.
So when applying this constraint to a substrate of precoordinated concepts, we may find these concepts (from Toxic pulmonary edema to Adult respiratory distress syndrome) are valid with respect to this constraint. All of these concepts are descendants of disorder of lung, and they also have an associated morphology which is either 'edema' or a descendant of edema.

10. Expression Constraint Language (ECL)
Example: Lung disorders with morphology a type of edema
< |disorder of lung| :
|associated morphology| = << |edema|
Valid Expressions:
Expression
|disorder of lung|:
|associated morphology|
= |edema|
= |acute edema|
|lung cyst|:
= |inflammatory edema|
When this expression constraint is applied to a substrate that includes postcoordinated expressions, we may find some additional clinical meanings that are valid against this constraint. For example, the expressions “Disorder of lung, with an associated morphology of edema”, “Disorder of lung with an associated morphology of acute edema” and “Lung cyst with an associated morphology of inflammatory edema” all represent clinical meanings which are a descendants of disorder of lung, and also have an associated morphology of either ‘edema’ or a descendant of edema.

11. Expression Constraint Language (ECL)
Products with 1 to 3 active ingredients
< |Pharmaceutical / biologic product| :
[1..3] |Has active ingredient|
= < |Substance|
Findings with a morphology of ulcer or hemorrhage
< |Clinical finding|: |Associated morphology| =
(<< |Ulcer| OR << |Hemorrhage|)
Lung disorders that are not in the cardiology refset
< |Disorder of lung| MINUS
^ |Cardiology reference set|

12. Expression Constraint Language (ECL)
Features added between ECL v1.0 and v1.2
childOf and parentOf to select immediate children/parents
dotNotation to refer to the attribute value of a concept/expression
constraintOperator can apply to nested expression constraint
memberOf can apply to nested expression constraint
comments within an expression constraint
Optional brackets around subexpressions
Examples
<! |Clinical finding|
< |Fracture of bone| |Finding site|
^ ( < |GP/FP health issue reference| )
/* Disorders of lung with edema */ < |Disorder of lung|:
|Associated morphology|= << |Edema|

13. Expression Constraint Language (ECL)
Implementations
SNQuery
CSIRO Ontoserver Expression Constraints
termMed’s termSpace
SNOMED International Terminology Server (via REST API)
SNOMED CT Query Service
Snow Owl MQ (form-based interface)
SNOMED CT Language Syntax Parsers
ECL Syntax Parser
Proposed future features
Using expression constraints for attribute names
Add childOf to attribute operators
Updated rule for dotted expressions
Selecting concepts recorded in additional refset attributes
Expression constraint implementation and testing artifacts

14. Query Language (QRL) Specifies queries over SNOMED CT content
(planned for 2018 –
History
: Proposed examples and requirements developed
: Specification to be written and published
Proposed Features
ECL functionality plus filters
Define query substrate
Filter over RF2 component fields
E.g. active, effectiveTime, moduleId, definitionStatus, term
Filter over reference set fields
E.g. acceptability, mapTargetId
Other keywords to simplify common queries
preferredTerm, fullySpecifiedName, acceptableTerm

15. Query Language (QRL) – Keywords
Filter Operators Valid Values
substrate = URI
id = sctId
active = “0”, “1”, “any”, “yes”, “no”
effectiveTime =, <, >, <=, >= ISO-8601 date (YYYYMMDD)
moduleId = conceptReference
module = {“core”, “modelComponent”, “preview”}
Concept
definitionStatusId = conceptReference
definitionStatus = “defined”, “primitive”
Relationship
characteristicTypeId = conceptReference
characteristicType = {“inferred”, “stated”, “additional”}

16. Query Language (QRL) – Keywords
Filter Operators Valid Values
Description
languageCode = 2 char (ISO lang code)
typeId = conceptReference
type = {“synonym”, “fullySpecifiedName”, “definition”}
term = [lexicalSearchType ":"] String
preferredTerm = [lexicalSearchType ":"] String
fullySpecifiedName = [lexicalSearchType ":"] String
acceptableTerm = [lexicalSearchType ":"] String
caseSignificanceId = conceptReference
caseSignificance = {“sensitive”, “insensitive”,
“initialCharInsensitive”}
languageRefSetId = conceptReference
languageRefSet = {“en-gb”, “en-us”, “es”}

17. Query Language (QRL) – Examples
Substrate * {{ substrate = }} Id * {{ id = }} EffectiveTime * {{ effectiveTime = }} Active ^ |Example problem list subset| {{active = 1}} ^ |Example problem list subset| {{active = any}} Module * {{ moduleId = }} * {{ module = core }}

18. Query Language (QRL) – Examples
Definition Status (concept) << |Clinical finding| {{ definitionStatusId = |Primitive|}} << |Clinical finding| {{ definitionStatus = primitive}} << |Clinical finding| {{ definitionStatus = defined}} : |Finding site| = << |Heart structure| << |Clinical finding|: |Finding site| = (<< |Heart structure| {{ definitionStatus = defined}}) Characteristic Type (relationship) * {{ characteristicTypeId = |Additional relationship| }} << |Clinical finding|: ( |Finding site| = |Heart structure| {{ characteristicType = stated }})
Let’s look at some examples. The first query returns those diseases that have a term with the string “heart” somewhere inside. Notice that the filter condition is placed inside double braces and that the value uses a Regex expression. The second query returns only those diseases whose preferred term contains the string “heart”. In this case, the language reference set which the preferred term belongs to is assumed. If we want to make it explicit as to which language reference set we’re using, then we can use the ‘languageRefSet’ filter. In this case we have selected the Great Britain English language reference set – however we could have selected the Singapore language reference set, the Spanish language reference set, the Danish language reference set, or any other language reference set. In the next query, we actually define the substrate of the query – that is, the specific SNOMED CT edition over which the query should be executed. Often the substrate is assumed by using whichever edition is currently loaded in the tool. However, in some cases (for example, where there is more than one Edition that is available in a given country) it is important to be specific about which Edition is intended to be used. The value for version uses the SNOMED CT URI standard, in which the Edition is identified using the most dependent module and the effective time of the specific version of that edition. In the last example, the query uses a customized reference set called ‘procedure frequency refset’ which has an additional attribute column added called ‘frequency’. The query then selects those members of the reference set with a ‘frequency’ greater than 100.

19. Query Language (QRL) – Lexical Search
Wild Card Match
term = wild:"*heart*“
Perl Regex
term = regex:".*heart.*"
Word Prefix Any Order
term = match:“hear att"
Default (wild card match)
term = "*heart*“
The SNOMED CT Query Language, is a superset of the expression constraint language, which will also be available for comment shortly. The query language is used for quering SNOMED CT content, defining intensional reference sets, querying patient data and binding SNOMED CT to ICD-11 linearizations. The main difference between the expression constraint language and the query language is the introduction of filters, which allow the results to be further constrained based on various SNOMED CT specific characteristics. In the query language, you can filter on a specific version of SNOMED CT, restrict lexical searches to a specific language reference set, the preferred terms, the fully specified names, or the acceptable terms. You can filter on the effective time, the active status, or the module id. You can filter descriptions on their language, type, case significance, or the term itself. You can filter relationships on their characteristic type, and you can filter the members of a reference set based on specific reference set attribute values.

20. Query Language (QRL) – Examples
Term (description) << |Disease| {{ term = “*heart*” }} Type (description) << |Disease| {{ term = “*heart*”, typeId = |Synonym| }} << |Disease| {{ term = “*heart*”, typeId = synonym }} Language Code (description) type = synonym, languageCode = “en” }} Case Significance (description) << |Disease| {{ term = “*Heart*”, caseSignificanceId = |case sensitive|}} << |Disease| {{ term = “*Heart*”, caseSignificance = sensitive }}
Let’s look at some examples. The first query returns those diseases that have a term with the string “heart” somewhere inside. Notice that the filter condition is placed inside double braces and that the value uses a Regex expression. The second query returns only those diseases whose preferred term contains the string “heart”. In this case, the language reference set which the preferred term belongs to is assumed. If we want to make it explicit as to which language reference set we’re using, then we can use the ‘languageRefSet’ filter. In this case we have selected the Great Britain English language reference set – however we could have selected the Singapore language reference set, the Spanish language reference set, the Danish language reference set, or any other language reference set. In the next query, we actually define the substrate of the query – that is, the specific SNOMED CT edition over which the query should be executed. Often the substrate is assumed by using whichever edition is currently loaded in the tool. However, in some cases (for example, where there is more than one Edition that is available in a given country) it is important to be specific about which Edition is intended to be used. The value for version uses the SNOMED CT URI standard, in which the Edition is identified using the most dependent module and the effective time of the specific version of that edition. In the last example, the query uses a customized reference set called ‘procedure frequency refset’ which has an additional attribute column added called ‘frequency’. The query then selects those members of the reference set with a ‘frequency’ greater than 100.

21. Query Language (QRL) – Examples
Language Reference Set (reference set) << |Disease| {{ term = “*heart*”, languageRefSetId = |GB English| }} languageRefSet = en-gb }} Preferred Term (language reference set) << |Disease| {{ preferredTerm = “*heart*”, languageRefSet = en-gb}} Fully Specified Term (language reference set) << |Disease| {{ fullySpecifiedTerm = “*heart*”, languageRefSet=en-gb}} Acceptable Term (language reference set) << |Disease| {{ acceptableTerm = “*heart*”, languageRefSet = en-gb}} Reference Set Attribute (reference set) ^ |ICNP diagnoses simple map reference set| {{ member.mapTarget = “R-FF2E9” }}
Let’s look at some examples. The first query returns those diseases that have a term with the string “heart” somewhere inside. Notice that the filter condition is placed inside double braces and that the value uses a Regex expression. The second query returns only those diseases whose preferred term contains the string “heart”. In this case, the language reference set which the preferred term belongs to is assumed. If we want to make it explicit as to which language reference set we’re using, then we can use the ‘languageRefSet’ filter. In this case we have selected the Great Britain English language reference set – however we could have selected the Singapore language reference set, the Spanish language reference set, the Danish language reference set, or any other language reference set. In the next query, we actually define the substrate of the query – that is, the specific SNOMED CT edition over which the query should be executed. Often the substrate is assumed by using whichever edition is currently loaded in the tool. However, in some cases (for example, where there is more than one Edition that is available in a given country) it is important to be specific about which Edition is intended to be used. The value for version uses the SNOMED CT URI standard, in which the Edition is identified using the most dependent module and the effective time of the specific version of that edition. In the last example, the query uses a customized reference set called ‘procedure frequency refset’ which has an additional attribute column added called ‘frequency’. The query then selects those members of the reference set with a ‘frequency’ greater than 100.

22. Query Language (QRL) – Compound Filters
Filter Conjuction
* {{active = 1, moduleId = }}
* {{active = 1 AND moduleId = }}
* {{term = "*heart*" AND caseSignificance = initalCharInsensitive }}
Filter Disjunction
* {{active = 1 OR moduleId = }}
* {{term = "*heart*" OR caseSignificance = initalCharInsensitive }}
* {{term = "*heart*" OR term = "*cardiac*"}}
Filter Exclusion
* {{active = 1, term != “*heart*” }}
No term on the concept = “*heart*” (i.e. Every term != …)
* {{term = "*heart*" MINUS term = "*cardiac*" }}

23. Template Syntax
Allows slots to be added to other languages whose values can be filled at a later time (2017 at
History
: Proposed examples and requirements developed
2017: Specification to be written and published
Use Cases
Binding SNOMED CT to information models
Defining postcoordinated clinical meanings
Authoring precoordinated clinical meanings
Template batch authoring tool and MRCM domain templates
Example (Expression Template)
|Procedure|: { |Method| =
|Computed tomography imaging action|,
|Procedure site - Direct| = [[+id (<< |Anatomical or acquired body ]] }

24. URI Standard URIs for language syntax
(… /version/2.1)
(… /version/1.2)
(… /version/1.0)
(… /version/1.0)
(… /version/1.0)
(… /version/1.0)
(… /version/1.0)
URIs for language syntax instances
(|Clinical finding|)
(|Clinical finding|: |Associated with| = |Edema|)
%3C%3C (< |Clinical finding|: <|Associated finding| = <|Edema|)

25. SNOMED CT Template Syntax Review