Page tree

Date & Time

20:00 UTC Wednesday 12 October 2016 

GoToMeeting Details

Click here to see GoToMeeting joining information


  • Briefly mention relevant IHTSDO business meetings in Wellington
  • Discuss updates to ECL in v1.1 
    • Decomposition syntax
    • Nesting/subexpressions
  • Discuss proposed v1.0 Template Syntax



Agenda and Meeting Notes


Welcome, introductions and apologies

Agenda reviewReview agenda for today's meeting
IHTSDO Business Meetings in Wellington

Relevant Modelling Advisory Group (MAG) meeting topics -

Expression Constraint Language v1.1
  • Discuss new updates to ECL in v1.1
    • Decomposition syntax - for example:
        • 57617002 |Urine specimen collection (procedure)| . 363701004 |Direct substance|
            • ... equivalent to ... < *: { R 363701004 |Direct substance| = 57617002 |Urine specimen collection (procedure)| }
        • ( << 17636008 | specimen collection| : 260686004 | method | = 129314006 | Biopsy - action | ) . 363701004 | direct substance|
            • ... equivalent to .... << 105590001|substance| : R 363701004 | direct substance| = ( << 17636008 | specimen collection| : 260686004 | method | = 129314006 | Biopsy - action | )
        • (X . |associated with| AND < |organism|) . |cb|
    • Subexpression requirements
Template Syntax v1.0
  • Discuss draft Template Syntax v0.1

Example 1: CT of X

71388002 |Procedure| : [[~1..1 @roleGroup1]]

{ 260686004 |Method| = 312251004 |Computed tomography imaging action|,

  405813007 |Procedure site - Direct| = [[+id (<<442083009 |Anatomical or acquired body structure|)] @site] }

Example 2: Family history of disease X in family member Y

413350009 |Finding with explicit context| : [[~1..1]]

{ 246090004 |Associated finding| = [[+id (< 404684003 |Clinical finding)]],

  408732007 |Subject relationship context| = [[+id (<< 125676002 |Person (person)|)]],

  408729009 |Finding context| = 410515003 |Known present|,

  408731000 |Temporal context| = 410511007 |Current or past (actual)| }

  • Topics raised by Ed
      • Preference for option 1 syntax. That is, with 'remove slots' e.g.[[ ~ 0..1 @slot1]] and 'replace slots' e.g. [[ + id (< 12345 |term|) @slot2 ]]
        • Note: Rather than '+ cpt' for a concept replacement, I now prefer '+ id' (for consistency with the URI standard which uses "" for the concept 267038008 |Edema|)
      • The fact that the "~" may not be necessary in a 'remove slot', as the absence of a "+" may be sufficient (for discussion with the SLPG)
      • The requirement to be able to replace other characters in an expression constraint template (such as comparison operators "=" and "!=")
      • If we all agree on this requirement, then we just need to select an appropriate abbreviation. I see in your example you've used "+char". Perhaps we could also consider "+str"?
      • The fact that a template processor would need to 'clean-up' any left over characters, such as ":". I suggest that we try to document the steps that a template processor should follow to turn a template into an expression, constraint etc.

Proposed Syntax Rules and Questions

  • Constraints and names appearing before a brace apply to the whole relationship group
  • Constraints and names appearing before an attribute apply to the whole Attribute Value pair
  • A cardinality constraint:
    • Preceding a brace indicates the number of times the following relationship group is allowed in the final expression (default separator between repetitions is ",")
    • Preceding an attribute within a relationship group indicates the number of times the following attribute may appear with a distinct (non-redundant) value in each instance of the given relationship group (default separator between repetitions is ",")
    • Preceding an attribute that is not in a relationship group indicates the number of times the following attribute may appear with a distinct (non-redundant) value in the relevant expression (or subexpression) (default separator between repetitions is ",")
    • Within a slot that is a focus concept of an expression (or subexpression) indicates the number of times the slot can be filled in the focus (default separator between repetitions is "+")
    • Within a slot that is the attribute in an Attribute-Value pair indicates the number of distinct attribute concepts that can be used in this position in the expression (default separator between repetitions is ",")
    • Within a slot that is the value of an Attribute-Value pair (but which is NOT the focus concept of a subexpression) is not allowed ???
  • Question 1 - How do we represent the cardinality of how many non-redundant values may appear in a given Attribute-Value pair across any relationship group. While this is currently always [0..*] in the MRCM, this may be more relevant in specialized authoring templates.
  • Question 2 - Do we need to provide support to vary the default connector between repetitions. Note, I think this is probably more important for Expression Constraint Templates, as there are more options (e.g. ANDs and ORs)
  • Question 3 - Do we introduce the ability for expression constraints in a slot to be replaced by a variable name (assigned using a SET-IN construct)? For example:
    • SET (severity_range = < |Severities|) IN [[ @finding ]]: |Severity| = [[+ecl ([[$severity_range]]) ]]
Confirm next meeting date/time

Next meeting to be held at 20:00 UTC on Wednesday 9 November (due to SNOMED Expo in New Zealand)

Meeting Files

  File Modified
Microsoft Word Document Expression Template Syntax v0.2.docx 2016-Oct-13 by Linda Bird

  • No labels


  1. Thanks to all members of the SLPG who were able to attend today's SNOMED Languages Project Group meeting.

    As discussed, I have given all members of the SLPG view and comment access to the ECL v1.1 Work-In-Progress document ( This is where I have added the 'dot notation' text and ABNF rules that I showed you today. In particular, please look at the new words in the 'Reverse attributes' section of 6.2 Refinements, and the introduction of the 'dottedExpressionConstraint' rule in the syntax specification (e.g. 5.1 Brief Syntax (Normative)).

    Also, here is the early draft ABNF syntax for the 'Expression Template Language' - Expression Template Syntax v0.2.docx. Please note that this syntax combines the 'Template syntax' for slots (which can be reused in different languages) with both 'Compositional Grammar' (to define the expression syntax), and the 'Expression Constraint Language' (to define the valid values for a slot). Also note that this is a simple baseline syntax, which can be enhanced and improved as we further discuss this within the group. I know that it does not include all of the features that we have been (and will be) discussing.

    Lastly, please take a look at the discussions that have been posted, and if you have any comments to add please do so.

    Kind regards,


  2. (sad) 

    Error: You are trying to view a page which does not yet have a published version available and you do not have permission to view draft versions.

  3. Thanks for pointing this out Michael. As you know, we managed to get the permissions fixed on Friday.

    I have now made all the changes to the ECL v1.1 that were discussed in the meeting. Could anyone in the SLPG who has time to review the WIPECL ( prior to publication, please confirm with me how much time you will need to do so. 

    I was hoping to publish this week ... however, if anyone needs more time to review, then please let me know.

    Kind regards,