SNOMED CT Languages Project Group

Space shortcuts

Page tree

Date & Time

20:00 UTC Wednesday 17 August 2016 

GoToMeeting Details

Click here to see GoToMeeting joining information

Goals

  • Discuss potential URI pattern for computable languages
  • Discuss publication of ECL v1.1 with decomposition syntax
  • Discuss proposed scope and syntax for v1.0 Template Syntax

Attendees 

Apologies

Agenda and Meeting Notes

Description
Owner
Notes

Welcome, introductions and apologies

Linda Bird
 
Agenda review
Linda Bird
Review agenda for today's meeting
URI Pattern for Languages

Harold Solbrig

Expression Constraint Language v1.1
Linda Bird
  • Discuss publication of ECL v1.1 to Confluence
  • Consider adding decomposition syntax in this version
    • 57617002 |Urine specimen collection (procedure)| . 363701004 |Direct substance| . 1234 |Other attribute|
    • The above is meant to refer to the direct substance of this procedure (i.e. 78014005 |Urine|) - that is the 'targetConcept' of the |Direct substance| relationship, where the sourceConcept is |Urine specimen collection|. This can also be represented as: 
      • < *: { R 363701004 |Direct substance| = 57617002 |Urine specimen collection (procedure)| }
    • Add example where direct substance is one thing and action is another.
Template Syntax v1.0

Linda Bird

  • Discuss proposed scope and syntax for v1.0 Template Syntax

Proposed use cases for v1.0

  • Urgent:
    • MRCM general domain templates
    • International SNOMED CT concept authoring tooling
  • Priority:
    • Mapping from HL7 FHIR resource to a SNOMED CT expression

Proposal is to keep the scope of v1.0 as tight as possible (to deliver this year), and look at possible extended functionality in future versions

OPTION 1

  • All template information is contained inside a slot (i.e. in square brackets - '[[ ... ]]')
  • Slots to be removed are indicated using a '~' as the first non-space character in the slot
  • Slots to be replaced are indicated using a '+cpt', '+exp', '+ecl' (depending on whether it may be replaced by a concept, expression or constraint), followed by an expression constraint in round brackets. Default is 'exp' (least restrictive) - e.g. '+(< 1234 |concept|)'
[[~ @expressionName]] 
[[+cpt(<<  413350009 |Finding with explicit context| ) @findingWithExplicitContext $fwecRef 1..1]]:
    [[~ @groupA 1..2]] {[[~ @associatedFindingAVP 0..1]]  246090004 |Associated finding|  = 
        ([[+cpt(<<  404684003 |Clinical finding| ) @associatedFindingValue $afRef 1..1]]:
            [[~ @groupB 0..1]] 
                { [[~ @severityAVP 0..1]]  246112005 |Severity|  = [[+cpt(< 272141005 |Severities| ) @severityValue $sevRef]],
                    [[~ @findingSiteAVP 0..1]]  363698007 |Finding site|  = [[+cpt(<  91723000 |Anatomical structure| ) @findingSiteValue $fsRef]] }),
    [[~ @subjectRelAVP 1..1]]  408732007 |Subject relationship context|  = [[+cpt(< 444148008 |Person in family of subject| ) @subjectRelValue $srRef]],
    [[~ @temporalContextAVP 1..1]]  408731000 |Temporal context|  = [[+cpt(<  410510008 |Temporal context value| ) @temporalContextValue $tcRef]],
    [[~ @findingContextAVP 1..1]]  408729009 |Finding context|  = [[+cpt(<  410514004 |Finding context value| ) @findingContextValue $fcRef]] }

OPTION 2

  • The '[[ ... ]]' slot syntax is only used where a 'slot' exists (in the 'traditional' sense of being a placeholder for a value that needs to be filled in later)
  • Slots are removed and replaced with a concept, expression or expression constraint during processing (+cpt,+exp,+ecl)
  • Cardinalities preceded by '~' are removed from the template during processing
  • Names preceded by '@' are removed from the template during processing
@expressionName [[+cpt(<< 413350009 |Finding with explicit context| ) @findingWithExplicitContext $fwecRef 1..1]]:
    ~[1..2] @groupA {~[0..1] @associatedFindingAVP  246090004 |Associated finding|  = 
        ([[+cpt(<<  404684003 |Clinical finding| ) @associatedFindingValue $afRef 1..1]]:
                ~[0..1] @groupB { ~[0..1] @severityAVP  246112005 |Severity|  = [[+cpt(< 272141005 |Severities| ) @severityValue $sevRef]],
                ~[0..1] @findingSiteAVP  363698007 |Finding site|  = [[+cpt(<  91723000 |Anatomical structure| ) @findingSiteValue $fsRef]] }),
    ~[1..1] @subjectRelationshipAVP  408732007 |Subject relationship context|  = [[+cpt(< 444148008 |Person in family of subject| ) @subjectRelValue $srRef]],
    ~[1..1] @temporalContextAVP  408731000 |Temporal context|  = [[+cpt(<  410510008 |Temporal context value| ) @temporalContextValue $tcRef]],
    ~[1..1] @findingContextAVP  408729009 |Finding context|  = [[+cpt(<  410514004 |Finding context value| ) @findingContextValue $fcRef]] }

OTHER POSSIBLE SYNTAX RULES

  • 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

Linda Bird

Next meeting to be held at 20:00 UTC on Wednesday 12 October (due to travel commitments and vacation)

Meeting Files

  File Modified
Microsoft Word Document re-submission2JMR_mie_2016.docx 2016-Sep-24 by Jean Marie Rodrigues

  • No labels

9 Comments

  1. Michael Lawley

    This is a more complex decomposition example:

    "substances of specimen collection where the method is biopsy"

    ECL:

    << 105590001|substance| : R 363701004 | direct substance| = ( << 17636008 | specimen collection| : 260686004 | method | = 129314006 | Biopsy - action | )

    Would become the following using "decomposition syntax"

    ( << 17636008 | specimen collection| : 260686004 | method | = 129314006 | Biopsy - action | ) . 363701004 | direct substance| 

     

  2. Linda Bird

    Nice example Michael! Thanks!

  3. Michael Lawley

    Challenge: "body structures for the procedure site (direct/indirect/unspecified) where the method is excision action" - hard because you need to decompose a constrained relationship group.

    It's not immediately obvious to me how to do it in either syntax.

     

    1. Linda Bird

      Hi Michael,

      Interesting problem. I agree that this can't be done in ECL.

      I think what you're trying to achieve would be like finding the set of matching @site values when comparing the following expression template to the set of concept definitions in your substrate:

      [[ + (< |Procedure|)]] : [[~ 1..*]] { |Method| = |Excision - action|, [[ + (<< |Procedure site|) ]] = [[ + @site ]], [[~ 0..*]] [[+ (*) ]] = [[+ (*) ]] },  [[~ 0..*]] { [[~ 0..*]] [[+ (*) ]] = [[+ (*) ]] }

      I think this would require internal correlation (like an SQL 'correlated subquery') to do this in ECL.

      Kind regards,
      Linda. 

       

  4. Ed Cheetham

    Dear all

    Sorry I missed the last meeting - thanks for the detailed  notes.

    I think I've stared at the two template options above for as long as is healthy, and haven't really come down firmly on one option or the other. However I am tending towards Option 1 (or perhaps a variant)...

    Whatever is decided, there is a need to distinguish between what shall be processed (replaced or removed) and what shall remain unchanged in the output. In both options this is largely handled; certainly if the output is an expression then I can see rules to determine what gets removed and what should always be 'literally' present in the output (although see below). By contrast if the output is to be an expression constraint there's currently a bit more guesswork involved (just because neither example illustrates the +ecl option), but it would appear that some features of constraint syntax (e.g. comparison operators such as =, !=, attribute operators) would not be mutable at the time of template processing whilst others (referenced components, constraint operators, cardinalities without '~') would (I accept I may have some flawed assumption here, but I don't think I'm completely wrong).

    To me Option 1 has a cleaner mechanism for indicating the difference - every time I encounter a [[...]] pair I know that it will contain some useful stuff (cardinality instruction, slot name, external reference name, all of which eventually get discarded) plus or minus some 'thing' in a (...) pair which I process and include in the output. This actually makes me wonder whether there is a need for the [[~...]] notation to indicate removable slots, since any slot without a +cpt() etc. segment leaves nothing behind.

    By contrast Option 2 has a number of different symbolic ways of saying 'remove me' or 'replace me'.

    Going back to an Option 1 variant idea (mixed in with the apparent arbitrariness of what can be 'slot substituted' in a constraint template) an extension to include any feature of the syntax in [[...]] would allow (perhaps desirable) flexibility. Say, for example, I wish to create a 'standardised pattern for a SNOMED CT query' (Linda's simplified description of a constraint template) where, for a refinement I could specify the whole of a role hierarchy or just the top concept ,that is, either:

    << 404684003 |clinical finding|: << 47429007 |associated with| = << 267038008 |edema|

    or

    << 404684003 |clinical finding|: 47429007 |associated with| = << 267038008 |edema|

    ...or wish to 'use my pattern' to toggle between creating an 'equals' and 'doesn't equal' constraints:

    << 404684003 |clinical finding|: << 47429007 |associated with| = << 267038008 |edema|

    or

    << 404684003 |clinical finding|: << 47429007 |associated with| != << 267038008 |edema|

    It looks to me as though (certainly the second example) could only be done by having multiple (two in this case) constraint templates (one with a literal '=' and one with '!= ') unless it was also possible to 'slot substitute' other features of the constraint syntax, e.g.:

    << 404684003 |clinical finding|: << 47429007 |associated with| [[@comparison1 +char('=' OR '!=') 1..1]]  << 267038008 |edema|

    The Option 1 approach would reuse the same [[...]] mechanism to signal that there is something to be substituted (resolving to an available option in '()'). Clearly there would be a design judgement as to when it would be better to create a family of templates and when to create single templates with multiple configurable fields, but at the moment there doesn't seem to be the choice.

    Finally, going back to 'stuff outside [[...]] being literally present in the output', I appreciate that with optional components this will result in some literal characters being left in the output ({} pairs where optional RGs are omitted, ':' characters where optional refinements are omitted) that are redundant or result in an invalid expression. I presume that this is a 'routine' problem and processors/generators need a clean-up step to wash such characters off?

    Ed

    1. Linda Bird

      Hi Ed,

      Thank you so much for your thoughtful comments! And apologies it has taken me a while to consider this fully.

      I think you raise some very good points - including:

      • Your preference for option 1. I also prefer option 1
        • Note: Rather than '+ cpt' for a concept replacement, I now prefer '+ id' (for consistency with the URI standard which uses "http://snomed.info/id/267038008" 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.

      Apologies if I've missed anything. I think this is a really good place to start back up our template discussions tomorrow.

      Thanks very much Ed!

      Kind regards,
      Linda. 

  5. Jean Marie Rodrigues

    Bonjour 

    I would like to submit the text of an oral presentation done in MIE 2016 in Munich  named Representing ICD11 JLMMS using IHTSDO representation formalism

     meaning compositional grammar and expression constraint language which was extracted from a master dissertation in Biomedical Engineering in Université Paris V Descartes.

    I am interested with my student M Mamou by your comments. We have done the work only on the Circulatory chapter of ICD 11 and i can send the full chapter representation

    Thank you

    I will be interested to participate to the gotomeeting but unfortunately for the 12 october 20 UTC i will be travelling and not available

     

    Jean marie Rodriguesre-submission2JMR_mie_2016.docx

  6. Ed Cheetham

    Hi Jean Marie

    I've only just seen this post. After a quick read of the paper I have a few comments:

    1. The example in the second bullet point of section 2 mixes up references to mitral valve stenosis and aortic valve stenosis.
    2. The paper mentions the generation of short normal forms. Section 7.8.2.4.3.4.2 of the Technical Implementation Guide states that the SNF includes computing the proximal primitive supertype(s) for fully defined concepts, but this does not appear to have been done for fully-defined example components.
    3. Throughout the document inclusions are met by the use of AND logic in the ECL. Surely these should use OR logic? Otherwise, using a specific example, an expression in a patient records would have to be both a coronary aneurysm AND a coronary AV fistula to satisfy the 'coronary artery aneurysm' ECL specification.

    I think this describes a useful analysis, but I'm not yet convinced that this represents a practical or maintainable way of characterising the relationship between SNOMED CT an ICD 11.

    Ed

  7. Jean Marie Rodrigues

    Bonjour Ed and thanks for the comment

    I must review your points for this was done by the master student and i must acknowledge that i have not reviewed every thing.

    This master dissertation should be followed by a PhD dissertation with another student.

    I understand you are interested to be a co tutor for the future work based on your initial comment

    the presentation (and the dissertation) were aimed to demonstrate the feasibility to represent coming ICD11 (unfortunately NOT YET stabilized to day after the WH0-FIC 2016 annual meeting in Tokyo!!!) with IHTSDO tools

    1 ok the student was not a physician

    2 SNF was used at the beginning of the work but we shifted to the browser expression afterwards

    3 your example is correct and it must be corrected

    I will be back to you