2016-08-17 - SLPG Meeting

Welcome, introductions and apologies

Former user (Deleted)

Agenda review

Former user (Deleted)

Review agenda for today's meeting

URI Pattern for Languages

Former user (Deleted)

• Discuss potential URI patterns for computable languages

  • http://snomed.info/id

  • http://snomed.info/ecl

  • http://snomed.info/scg

  • http://snomed.info/qry

  • http://snomed.info/etl

  • http://snomed.org/ect

  • http://snomed.org/qrt

• Bring this to the Modelling Advisory Group

Expression Constraint Language v1.1

Former user (Deleted)

• 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

Former user (Deleted)

• 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|)'

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

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

Former user (Deleted)

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