Date & Time
20:00 UTC Wednesday 13th March 2019
Teleconference Details
To join the meeting please go to https://snomed.zoom.us/j/471420169.
Further information can be found at SLPG meeting information
Goals
- Review actions from last meeting
- Proposed enhancements to template language
- Proposed new language features for mapping
Attendees
- Chair: Linda Bird
- Project Group: Daniel Karlsson, Michael Lawley, Yongsheng Gao, Anne Randorff Højen, Ed Cheetham, Rob Hausam
Apologies
Agenda and Meeting Notes
Welcome and apologies Use cases: New concept development, querying based on template matching, and template-based modeling transformation New requirements Template [[ +id ]]: Proposed extension to ECL to support the execution of maps Proposal from Michael: 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| Examples: version and language << 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, LANGUAGE Y << 64572001 |Disease| {{ acceptableTerm = “*heart*”}} VERSION http://snomed.info/sct/900000000000207008/version/20180131, LANGUAGE Y (* {{ term = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20180131, LANGUAGE Z) MINUS Notes Examples: where X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547) X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547) VERSION http://snomed.info/sct/900000000000207008/version/20180131 Notes Keywords for Term-based searching: Additional Syntactic Sugar Language preferences using multiple language reference sets LRSs that use the same Language tend to use 'Addition' - i.e. child LRS only includes additional acceptable terms, but can override the preferred term E.g. Regional LRS that adds local dialect to a National LRS E.g. Specialty-specific LRS E.g. Irish LRS that adds local preferences to the en-GB LRS 99999900 |Irish language reference set| PLUS |GB English reference set| LRSs that define a translation to a different language tend to use 'Replacement' - i.e. child LRS replaces set of acceptable and preferred terms for any associated concept E.g. Danish LRS that does a partial translation of the International Release 999999 |Danish language reference set| ELSE |GB English reference set| The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 27th March.Actions from last week Template Syntax Linda Bird
{ 116676008 |Associated morphology| = [[ +id @morphology ]],
363698007 |finding site| = [[ +id (<< |Body structurel MINUS << $findingSite2 ) @findingSite1 ]] },
{ 116676008 |Associated morphology| = [[ +id @morphology ]],
363698007 |finding site| = [[ +id (* MINUS << $findingSite1) @findingSite2 ]] }
{ 116676008 |Associated morphology| = 66954000 |Bone cyst|,
363698007 |Finding site| = 719491009 |Bone structure of right tibia| }
{ 116676008 |Associated morphology| = 66954000 |Bone cyst|,
363698007 |Finding site| = 719492002 |Bone structure of left tibia| }
[[1..*] @group1] { |Finding site| = [[ +id (* MINUS $site[! SELF ] ) @site constraint ( [n] != << $site [!n] ]] ,
|Associated morphology| = [[ +id ($morphology [! SELF] ) @morphology constraint ( [n] = $morphology [!n] ]] }
{ 363698007 |Finding site| = 85050009 |Bone structure of humerus|,
116676008 |Associated morphology| = 5468008 |Fracture of multiple sites of bone| }
{ 363698007 |Finding site| = 51299004 |Bone structure of clavicle|,
116676008 |Associated morphology| = 5468008 |Fracture of multiple sites of bone| }
{ 363698007 |Finding site| = 79601000 |Bone structure of scapula|,
116676008 |Associated morphology| = 5468008 |Fracture of multiple sites of bone| }
{ 363698007 |Finding site| = 773134001 |Bone structure of multiple body regions|,
116676008 |Associated morphology| = 771485007 |Fracture of multiple bones| }
{ |Finding site| = [[ +id (<< 72673000|Bone structure|) @site default (72673000 |Bone structure (body structure)|) ]]
{ [[1..1]] |Associated morphology| = [[ +id @morphology ]],
[[0..1 ]] |Finding site| = [[ +id @site]],
[[0..1 ]] |Occurrence| = [[ +id @occurrence ]] }
{ |Associated morphology| = |Injury|, |Finding site| = |Head structure| }
{ |Associated morphology| = |Injury|, |Finding site| = |Neck structure| }
{ |Associated morphology| = |Injury|, |Finding site| = |Chest structure| }
{ |Associated morphology| = |malformation|, |Finding site| = |Head structure|, |Occurrence| = |Gongenital| }
{ |Associated morphology| = |malformation|, |Finding site| = |Neck structure|, |Occurrence| = |Gongenital| }
{ [[ 1..1 ]] |Method| = [[+id]],
[[ 0..1 ]] |Direct morphology| = [[+id @morph]],
[[ 0..1 ]] |Procedure site - Direct| = [[+id]],
[[ 0..1]] |Using device| = [[+id]] ,
[[ 0..1]] |Has intent| = [[+id]] ,
{ |Method| = |Closure - action|, |Procedure site - Direct| = |Skin structure| , |Using device| = |Surgical suture, device|}
{ |Method| = |Ultrasound imaging - action|, |Procedure site - Direct| = |Skin structure| , |Has intent| = |Guidance intent|}
{ |Method| = |Biopsy - action|, |Procedure site - Direct| = |Skin structure| , |Using device| = |Core biopsy needle, device|}
{ |Method| = |Surgical toilet - action|, |Direct morphology| = |Wound| }
{ |Method| = |Closure - action|, |Direct morphology| = |Wound|,
|Procedure site - Direct| = |Skin structure|, |Using device| = |Surgical suture, device| }Executing maps Returning attributes Michael Lawley URI Standard Query Language
- Summary from previous meetings
(* {{ term = "*heart*" }} VERSION http://snomed.info/sct/900000000000207008/version/20170731, LANGUAGE W)Other topics Confirm next meeting date/time
14 Comments
Ed Cheetham
Following on from the call discussion regarding the ambitions and use cases of the template language..
I confess that I had missed the refocusing in emphasis of the template syntax. Looking back over the minutes of 2016 calls considerable effort was expended trying to meet the FHIR extraction/population use cases. What happened to this work? Is the 2017 STS material capable of meeting the original FHIR requirements, or (as seemed to be said on the call) was this deemed too hard?
Returning then to the 'authoring of pre-coordinated content' use case, I again want to ask what is the expectation regarding the capabilities of the template syntax? I'm strongly in favour of automating as many rules as possible, but am not convinced that the declarative 'paradigm' of the template syntax is the right place to do anything more than - well - 'template' stuff (useful, but basically rigid guides that say 'put this sort of thing here, and get it from over there'). If the desire is to do more sophisticated things than this (notably condition testing and flow control) then I'd prefer it if there was a really clear debate now as to how this will be achieved before the STS is extended.
Looking within the current 'specific disorder modelling' guidance, and picking out a few clauses that reference 'occurrence' (because that's close to an example already under discussion) we have:
At the moment the discussion has focused on the third one (plus its unstated allOrNone enhancement), but it seems to me that there are many more aspects of these 'rules' which could be automated. If there is wider appetite to do so, then simply folding more and more if the condition testing into each template slot doesn't feel like the right way to go.
Ed
Michael Lawley
I am struggling with similar concerns Ed.
Originally I had understood the templating language as a way to construct expressions (eventually any of PCG, ECL, SQG) from some kind of input data model, although it was never quite clear whether the output was a single thing or multiple things, and we've never really documented an input model (AFAICR).
In this scenario, you have some input and you apply a template and you get (or not) an output.
However, we seem to be straying into a lot of other territory. For example, validating that the input / output matches a whole lot of other constraints, that really appear more like MRCM issues. i.e., having generated an expression from a template, does it satisfy some other constraints.
I'm also wondering about the use-case of an interactive author filling out a template. That is, where the template (and constraints) are somehow used to provide an intelligent UI for authoring.
All of these uses have an impact on the kinds of design tradeoffs we need to make. Furthermore, unlike with the others languages where I'm implementing them, we don't have anyone consistently on the call who is implementing the templating language and is thus able to provide input on what is / is not possible / better from that perspective.
Ed Cheetham
Thanks Michael
It's reassuring to hear that I'm not completely alone with these (and similar) concerns.
Whilst addressing them now may slow down pragmatic/tactical efforts to meet immediate requirements, I'd hope that in the long term it would result in a more tractable approach.
Just a thought (which probably others have had): perhaps there is mileage in looking again at the Galen work. The GRAIL language [1] supported the distinction between 'grammatical' sanctioning (personal opinion - more like much of the MRCM) and 'sensible' sanctioning (presumably including intelligent UI features and related rules), and the Galen development workflow included an 'intermediate representation' [2] to hide some of the internal complexity of the required description logic (personal opinion - not unlike the 'grouped/ungrouped' feature of the MRCM as well as the 'allOrNone' idea from the meeting). If these are valid distinctions then there is a risk that they are being mixed up in SNOMED CT's approach.
Clearly Jeremy has lots of first-hand experience of this work; maybe if we asked nicely he could be persuaded to give us a primer?
Ed
[1] non-searchable document here, summary in Ian's thesis here.
[2] "Having our cake..."
Linda Bird
Hi Ed,
If Jeremy is able to give us a digestible primer to the Galen work and/or GRAIL language, that would be great.
Happy to include this in a future languages meeting, if you think this might be directly relevant to this work.
Thank you!
Kind regards,
Linda.
Ed Cheetham
Thanks Linda
I've raised the question with Jeremy - I'll see what he says.
Ed
Ed Cheetham
Doesn't look as though Jeremy will have the time to do a personal presentation on this work in the near future, but in the meantime he shared a few documents...
"...For digestible primers, there’s the original 1997 paper to MIE (1997 Rogers - (MIE) Rubrics to Dissections.doc) and then a slightly different perspective on the same work that was presented at AMIA in 2000 (conference slides here 2000 Rogers (AMIA) - Intermediate Representation.ppt, original paper at https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2244105/)...".
Kind regards
Ed
Linda Bird
Thanks Ed! Would you be able to give us a summary at this week's meeting (or a future one)?
Kind regards,
Linda.
Linda Bird
Hi Michael,
Just to refresh your memory ... we did document an input model, as suggested and reviewed by you previously. See 7.1. Preparing Input Data and 7. Processing Expression Templates.
Also, while I agree that we don't have anyone regularly on the call who is implementing these templates, Yong and I are working closely with Peter Williams, who is implementing these templates internally within SNOMED International. This implementation work is driving these requirements - so any new features that are added to the syntax will be implemented and testing through Peter's work.
Kind regards,
Linda.
Michael Lawley
Now I'm glad I included that AFAICR - I clearly didn't recall
michael
Linda Bird
Hi Ed,
Thank you for sharing your concerns.
With respect to the FHIR use case, I believe the 2017 STS material is capable of meeting the original FHIR requirements - however the SNOMED on FHIR group hasn't been focusing on using templates recently. I'm not sure if they are still planning to define templates for each clinical resource. Daniel may be able to add a comment here (as a co-chair of the clinical binding stream).
With respect to the authoring of precoordinated content use case, I completely agree that we should not be attempting to add full condition testing and flow control to the syntax language. I think we're all in agreement there. So then, the question is where is the boundary between what is in scope, and what is out of scope. We had previously agreed that conditional statements such as IF ... THEN .. ELSE were out of scope, as we do not want to introduce a conditional sublanguage into the syntax. Some of the examples that you've included refer to checking if a specific word is in the FSN (e.g. "congenital", "acquired"), which includes both lexical string comparison and conditionality - I would strongly suggest that these are out of scope (for multiple reasons).
However, (referring to your third example) defining which attributes should be used in each role group is clearly in scope, and as per the current syntax (as long as conditional constraints are not required). Similarly, specifying the cardinality of each attribute in a role group is also in scope (as per the current syntax). Specifying that an attribute must either be used in all instances of a repeated role group or none of them (ie allOrNone), is an extension to these requirements that I agree could be seen as a "conditional cardinality" (i.e. If the attribute is in one instance of the role group, then it's in all instances of the role group). However, this is a very specific use case that is very commonly used in SNOMED CT by our authors, and which does not require any generalised support of full conditionality. Given its frequent usage, and the benefits of being able to share this information in templates published by SNOMED International, I personally think the benefits of including an allOrNone function in the syntax outweigh the disadvantages.
Happy to continue this discussion, as I agree that the scope of the syntax is an important topic. Thanks for raising this Ed!
Kind regards,
Linda.
Ed Cheetham
Thanks Linda
You may well be right about the allOrNone use case (a sort of 'inline if' ternary function). I deliberately included the surface property/term clauses as being 'in scope' for formalising authoring business rules; I agree that they would not be sensibly handled in templates, but their consideration highlights the need for a rule language that is able to pull together fragments of ECL, query and template language.
Ed
Linda Bird
Interesting idea Ed! (i.e. the rule language that pulls together the other syntaxes)
... but not for 2019.
Kind regards,
Linda.
Ed Cheetham
A couple of cautious corrections or queries on the 'minutes' above (template syntax section):
In part 1, example B, in order to satisfy "...and no 2 finding sites subsume each other...", I think the value constraint should read [[ +id (* MINUS << $site[! SELF ] ) @site]], not [[ +id (* MINUS $site[! SELF ] ) @site]].
Also, the supposed valid example of the definition for 208510002 |Multiple fracture of clavicle, scapula and humerus (disorder)| isn't actually valid against the intent of the [[ +id ($morphology [! SELF] ) @morphology ]] constraint ("... in which the morphology is always the same..."). The fourth group has a different morphology value (771485007 |Fracture of multiple bones|) to the preceding three groups (5468008 |Fracture of multiple sites of bone|).
Ed
Linda Bird
Hi Ed,
You are absolutely correct on both of these issues. Thank you for spotting these. I believe I have corrected both issues in the 2019-03-27 meeting agenda.
Kind regards,
Linda.