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 

Agenda and Meeting Notes

Description
Owner
Notes

Welcome, introductions and apologies

 
Agenda reviewReview agenda for today's meeting
URI Pattern for Languages
Expression Constraint Language v1.1
  • 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
  • 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/timeNext meeting to be held at 20:00 UTC on Wednesday 12 October (due to travel commitments and vacation)

Meeting Files