2019-03-13 - SLPG Meeting
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: @Former user (Deleted)
Project Group: @Daniel Karlsson, @michael lawley, @Yongsheng Gao, @Anne Randorff Højen, @Ed Cheetham, @Rob Hausam
Apologies
Agenda and Meeting Notes
Description | Owner | Notes |
|---|---|---|
Welcome and apologies | @Former user (Deleted) |
|
Actions from last week | @Former user (Deleted) |
|
Template Syntax | @Former user (Deleted) | Use cases: New concept development, querying based on template matching, and template-based modeling transformation New requirements
|
Executing maps | @Former user (Deleted) | Proposed extension to ECL to support the execution of maps
|
Returning attributes | @michael lawley | 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|
|
URI Standard | @Former user (Deleted) |
|
Query Language
| @Former user (Deleted) | Examples: version and language
Notes
|
| Examples: where
Notes
| |
Keywords for Term-based searching:
Additional Syntactic Sugar
| ||
Language preferences using multiple language reference sets
| ||
Other topics | @Former user (Deleted) |
|
Confirm next meeting date/time | @Former user (Deleted) | The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 27th March. |
Comments
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.
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.
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.
Thanks Linda
I've raised the question with Jeremy - I'll see what he says.
Ed
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 () and then a slightly different perspective on the same work that was presented at AMIA in 2000 (conference slides here , original paper at https://www.ncbi.nlm.nih.gov/pmc/articles/PMC2244105/)...".
Kind regards
Ed
Thanks Ed! Would you be able to give us a summary at this week's meeting (or a future one)?
Kind regards,
Linda.
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.
Now I'm glad I included that AFAICR - I clearly didn't recall
michael
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.
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
Interesting idea Ed! (i.e. the rule language that pulls together the other syntaxes)
... but not for 2019.
Kind regards,
Linda.
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
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.
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:
"...Disorders with the word congenital in their FSNs should be classified under 66091009 |Congenital disease (disorder)|.
Do not make a direct stated assertion that the parent is 66091009 |Congenital disease (disorder)|; instead allow the classifier to infer this relationship.
Occurrence should be in the same relationship group as Associated morphology and Finding site because the morphology is located at the site and the occurrence applies to the combined morphology-site pair.
...
Congenital disorders are modeled using Occurrence = 255399007 | Congenital (qualifier value) |. If the FSN does not include congenital, it should not be modeled as congenital. The precise meaning of the FSN should be followed (e.g. many hereditary disorders have congenital appearances).
...
All concepts that explicitly state acquired in their FSNs or in a synonym should be modeled with Occurrence = 767023003 | Period of life beginning after birth and ending before death (qualifier value) |; that is if an Occurrence relationship does not already exist, i.e. there is not already another period of life that is a value for Occurrence, which would infer the parent..."
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