Date & Time
20:00 to 21:00 UTC Wednesday 2nd December 2020
Location
Zoom meeting link (password: 764978)
Goals
- Discuss a few ECL questions
- Consider postcoordination use cases
Attendees
- Chair: Linda Bird
- Project Group: Anne Randorff Højen, Peter Jordan, Daniel Karlsson, Michael Lawley, Rob Hausam, Darryn McGaw
Apologies
Agenda and Meeting Notes
Description Owner Notes Welcome and agenda NOTE On request, we have developed an ECL Quick Reference page with a summary of the ECL syntax and examples. Could the SLPG please review this page, and provide feedback. We plan to publish this as soon as possible. For discussion: Example 1 - Mapping Example 2 - Terminology binding Example 3 - Dentistry / Odontogram Example 4 - Natural Language Processing Practical Guide to Postcoordination Proposed Transformation Rules - Refinements (NOT in valid domain of focus concepts) 363443007 |Malignant tumor of ovary|: 272741003 |Laterality| = 24028007 |Right| ON HOLD - How to refer to an 'extended edition' using a URI - e.g. "International Edition plus the following 2 nursing modules: 733983009 |IHTSDO Nursing Health Issues module|and 733984003 |IHTSDO Nursing Activities module| Use Case - Need to execute an ECL, that refers to "^ 733991000 | Nursing Health Issues Reference Set (foundation metadata concept) |" and/or "^ 733990004 | Nursing Activities Reference Set (foundation metadata concept) |", where the substrate includes the international edition, plus the modules that include these reference sets July 2020 International Edition URI: http://snomed.info/sct/900000000000207008/version/20200731 July 2020 International Edition + nursing modules URI ?? - For example: ON HOLD - Proposed syntax to support querying and return of alternative refset attributes (To be included in the SNOMED Query Language) ON HOLD - Proposal (by Michael) for discussion For example, I can write: << 404684003|Clinical finding| : 363698007|Finding site| = <<66019005|Limb structure| << 404684003|Clinical finding| . 363698007|Finding site| But I can't get all the attribute names that are used by << 404684003|Clinical finding| ON HOLD - Proposal for discussion What refsets is a given concept (e.g. 421235005 |Structure of femur|) a member of? Expression Templates Examples: [[+id]]: [[1..*] @my_group sameValue(morphology)] { |Finding site| = [[ +id (<<123037004 |Body structure (body structure)| MINUS << $site[! SELF ] ) @site ]] , |Associated morphology| = [[ +id @my_morphology ]] } Note that QI Project is coming from a radically different use case. Instead of filling template slots, we're looking at existing content and asking "exactly how does this concept fail to comply to this template?" For discussion: Is it correct to say either one of the cardinality blocks is redundant? What are the implications of 1..1 on either side? This is less obvious for the self grouped case. Additional note: QI project is no longer working in subhierarchies. Every 'set' of concepts is selected via ECL. In fact most reports should now move to this way of working since a subhierarchy is the trivial case. For a given template, we additionally specify the "domain" to which it should be applied via ECL. This is much more specific than using the focus concept which is usually the PPP eg Disease. FYI Michael Chu FUTURE WORK Examples: version and dialect << 64572001 |Disease| {{ term = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131 << 64572001 |Disease| {{ synonym = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131 << 64572001 |Disease| {{ FSN = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131 << 64572001 |Disease| {{ preferredTerm = “*heart*”}} VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT Y << 64572001 |Disease| {{ acceptableTerm = “*heart*”}} VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT Y (* {{ term = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131, DIALECT Z) MINUS NotesECL Quick Reference ECL and Concrete Values Postcoordination Use Case Examples All Postcoordination Guidance
{ 260686004 |Method| = 129304002 |Excision - action|,
405813007 |Procedure site - Direct| = 15497006 |Ovarian structure|,
405815000 |Procedure device| = 122456005 |Laser device| }
{ 260686004 |Method| = 129304002 |Excision - action|,
405813007 |Procedure site - Direct| = 15497006 |Ovarian structure|},
{ 405815000 |Procedure device| = 122456005 |Laser device| }
{ 363698007 |Finding site| = 272673000 |Bone structure|,
116676008 |Associated morphology | = 72704001 |Fracture| }
{ 42752001 | Due to (attribute) | = 1912002 | Fall | }
ObjectIntersectionOf (:71388002
ObjectSomeValuesFrom(:609096000 ObjectIntersectionOf( ObjectSomeValuesFrom(:260686004 :129304002)
ObjectSomeValuesFrom(:405813007 :15497006))))
Close-to-user-form - IF the grouping of the refinement is not concept model valid THEN
If there is a single (non-self-grouped) role group in the definition of the focus concept, then any ungrouped (but groupable) refinements are merged with this role group
If there is more than one (non-self-grouped) role group in the definition then flag as ambiguous and require refinement
NEED TO FIND a realistic clinical example where this may occur // Prevent failing cases from coming up // use template
ALTERNATIVE: Refinement is applied to all (non-self-grouped) role groups in the definition
Self-grouped attributes in the refinement are grouped on their own - i.e. Priority, Due to, After, Before, During, Clinical course, Temporally related to, and all Observable entity attributes (see Relationship Group)
Self-grouped attributes in the definition of the focus concept(s) are left unchanged
83152002 |Oophorectomy| : 405815000 |Procedure device| = 122456005 |Laser device|
83152002 |Oophorectomy| : 405815000 |Procedure device| = 122456005 |Laser device|, 363700003 |Direct morphology| = 367643001 |Cyst |
405813007 |Procedure site - direct| = 15497006 |Ovarian structure|,
405815000 |Procedure device| = 122456005 |Laser device| ,
363700003 |Direct morphology| = 367643001 |Cyst | }
83152002 |Oophorectomy| : 405815000 |Procedure device| = 122456005 |Laser device|, 260870009 |Priority| = 394849002 |High priority|
405813007 |Procedure site - direct| = 15497006 |Ovarian structure|,
405815000 |Procedure device| = 122456005 |Laser device| }
{ 260870009 |Priority (attribute)| = 394849002 |High priority| }
83152002 |Oophorectomy| : 260686004 |Method| = 277261002 |Excision biopsy (qualifier value)|
83152002 |Oophorectomy| : { 260686004 |Method| = 281615006 | Exploration - action | , 405813007 |Procedure site - direct| = 367643001 |Cyst | }
405813007 |Procedure site - direct| = 15497006 |Ovarian structure| },
{ 260686004 |Method| = 281615006 | Exploration - action | ,
405813007 |Procedure site - direct| = 367643001 |Cyst |}
Close-to-user-form - IF the refinement's attribute is not valid for the domain of the focus concept THEN
If there is a single role group in the definition of the focus concept, which has an attribute value in the domain of the refinement's attribute THEN nest the relevant attribute value with the refinement added to the attribute value
(Note: It doesn't matter if the role group is self-grouped or not (see example 1 below)
If there is more than one role group in the definition of the focus concept, which has an attribute value in the domain of the refinement's attribute THEN (non-self-grouped) role group in the definition then flag as ambiguous and require refinement
363698007 |Finding site| = ( 15497008 |Ovarian structure| : 272741003 |Laterality| = 24028007 |Right| ) }
260870009 |Priority| = 25876001 |Emergency|
363698007 |finding site| = 84167007 |Foot bone| }
363698007 |finding site| = 84167007 |Foot bone| }The items below are currently on hold Other Options for Future Progress URIs for Extended Editions Querying Refset Attributes Linda Bird
FROM 799 |Anatomy structure and part association refset|
WHERE 123 |referenced component| = (< 888 |Upper abdomen structure| {{ term = "*heart*" }} )
FROM concept
WHERE id IN (< |Clinical finding|)
AND definitionStatus = |primitive|
FROM concept, ECL("< |Clinical finding") CF
WHERE concept.id = CF.sctid
AND definitionStatus = |primitive|
FROM concept ( < |Clinical finding| {{ term = "*heart*" }} {{ definitionStatus = |primitive| }} )
(|Anatomy structure and part association refset| {{ |referencedComponent| = << |Upper abdomen structure}} )? |targetComponentId|
734139008 |Anatomy structure and part association refset|
734139008 |Anatomy structure and part association refset|
734139008 |Anatomy structure and part association refset| :
449608002 |ReferencedComponent| = << |Upper abdomen structure|
734139008 |Anatomy structure and part association refset|
{{ 449608002 |referencedComponent| = << |Upper abdomen structure| }}
734139008 |Anatomy structure and part association refset| :
449608002 |ReferencedComponent| = (<< |Upper abdomen structure|) : |Finding site| = *)Returning Attributes Michael Lawley Reverse Member Of Michael Lawley Road Forward for SI
Description Templates Kai Kewley Query Language
- Summary from previous meetings
(* {{ term = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20170731, DIALECT W)
5 Comments
Ed Cheetham
Happy new year.
Is there any chance someone could post a snapshot copy of the draft 'Postcoordination use cases' document? For whatever reason I'm unable to access the copy on Google docs. I know this means that I'll miss out on the 'live document' experience, but the alternative is that I can't see anything!
Kind regards
Ed
Kai Kewley
Hi Ed Cheetham, I've just updated the permissions so that no sign in is required to view the draft 'Postcoordination use cases' document.
Ed Cheetham
Thanks Kai. Ed
Ed Cheetham
A few thoughts on the Post-coordination use cases document:
This is a fair start, but as raised back in October, ‘post-coordination’ consists of several related activities and challenges including, at least:
The ongoing ‘close-to-user’ and ‘expression transformation’ debates indicate that the SI community appreciate this complexity, but the current document focuses largely on the first one. Until the ‘use cases’ actively consider the additional steps and activities, there remains a perception (with all attendant risks) that the ‘challenge’ of post-coordination is limited to the ‘compositional expression creation’ recording’ step.
The mapping and terminology binding use cases, in particular, are framed in terms of compositional expression creation goals, but are (except for the ‘classifiable form’ column) silent on other stages.
Introducing a use case worded as ‘as a clinician, I want the procedure I record in my operating theatre system to be available on the national summary record and used in the letter I send to the GP and patient’ might draw attention to communication and interoperability challenges, not least ‘what will the human-readable display name of the procedure be?’. In the ‘mapping’ example this could well be the interface term of the local coding scheme (so no problem), but if the procedure record has been constructed from components selected from several fields (as in the binding case), then although the dispersed form may be perfectly understandable when re-displayed in the creating system, no single serializable term is available for display in alternative contexts.
Introducing a use case of ‘as a clinician, when recording a disorder or procedure, I only want to be offered the right and left variants of bilaterally symmetrical body structures where these exist (and have not been already selected)’ seems reasonable too. If SNOMED CT is expected drive this sort of interface behaviour, this use case shines a light on the reference data itself: although, I’m sure, almost perfect in its membership, there are still errors in the lateralisable body structure refset (e.g. 727986007 |Entire optic chiasma (body structure)| and 59011009 |Structure of basilar artery (body structure)| - both midline structures - are in the set, whilst 787050004 |Structure of joint region of lower extremity (body structure)| is not), but even if the refset were perfect, ideal interface behaviour depends upon the disorders and findings themselves being correctly modelled.
I am pleased to see an early attempt to represent IF/THEN logic for the @temporalContext slot in the odontogram example. I expect that, for all but the simplest expression composition templates there will be plenty of boilerplate and authoring business rules that will need to be captured and distributed this way in order to create analysable data. I also note the notion of a ‘hidden’ slot in the data entry form selection – this is understandable to me, but all these extra layers of necessary complexity need to be available and understandable to implementers before ‘post-coordination’ can proceed in a risk managed way.
We could introduce the use case of ‘as an analyst, I want to be able to retrieve compositional expressions alongside pre-coordinated content in a predictable way’. Just looking at the handful of examples in this document I can see trouble here:
Based on their experience of working elsewhere in the terminology, an analyst may well base their query predicates on existing reference concepts and modelling. Let’s say they are interested in identifying all records containing ‘enthesopathy of foot’. They see that SNOMED CT already has 240028007 |Enthesopathy of foot region (disorder)| and base their retrieval predicate on the PPS and role modelling of this concept. They will not be able to retrieve the suggested expressions associated with the interface term ‘Enthesopathy of lower limb, foot’ in the mapping example, and would not know if they were missing them. How are they to know when to base their queries on the reference data and when to use alternative approaches?
They will also say ‘as an analyst, I would like to retrieve compositional expressions that were recorded any time over the last ten years’. We are well aware that the reference data changes between releases, but compositional expressions – especially the ‘close-to-user’ ones will be fixed with the modelling that applied at the time of their creation (even if extraneous noise is limited by a close-to-user approach, the attribute=value pairs used may change). Should analysts construct families of queries based upon evolving reference definitions as attribute names, attribute values, role grouping and other modelling conventions change over time, or will these design variants be somehow tracked in the reference product?
I appreciate these comments look very critical, but I hope they are taken in the constructive spirit with which they are intended.
Ed
Michael Lawley
I agree with Ed here. As I see it the issue we're wrestling with is not "do we support compositional expressions", it is about how we support it, and more specifically, whether one of those ways is view a close-to-user form.
To that end, the use cases need to include sufficient detail that we understand whether or how a close-to-user form would be used.
Taking the second case above "as a clinician, when recording a disorder or procedure, I only want to be offered the right and left variants of bilaterally symmetrical body structures where these exist (and have not been already selected)", I can see (e.g., as demonstrated in http://snomed.org/ui) that this is possible without the clinician being exposed to any compositional expression. However, that opens a different use case "as a developer, when a disorder or procedure is selected along with an appropriate laterality, I need to be able to record this information in a single field". This use case is clearly different in nature to a clinician composing an expression because now the expression will be assembled by software, and that software can reasonably be assumed to have full access to (at least) the inferred form of the disorder or procedure being refined.