SNOMED CT Languages Project Group

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

 

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

Observers

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

  • Discuss potential URI patterns for computable languages
Expression Constraint Language v1.1
Linda Bird
  • Discuss publication of ECL v1.1 to Confluence
  • Consider adding decomposition syntax in this version
Template Syntax v1.0

Linda Bird

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

Proposed use cases for v1.0

  • MRCM general domain templates
  • International SNOMED CT concept authoring tooling
  • 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
No files shared here yet.

  • No labels