Welcome and apologies | |
|
Query Language
- Recap from previous meetings | | Examples: version and language Notes
- Allow nested where, version, language
- Scope of variables is inner query
|
| Examples: where Notes - Allow nested variable definitions, but recommend that people don't due to readability
- Scope of variables is the inner query
- No recursion e.g X WHERE X = 1234 MINUS X
- ie can't use a variable in its own definition
- ie X is only known on the left of the corresponding WHERE, and not on the right of the WHERE
|
Query Language
- Recap from previous meetings | | What filter keywords will we introduce for Term-based searching, and what are their exact meanings? - D.term
- D.term = "*heart*"
- D.term = wild:"*heart*"
- D.term = regex:".*heart.*"
- D.term = match:"hear att"
- D.term = (sv) wild: "*heart*"
- D.languageCode
- D.languageCode = "en"
- D.languageCode = "es"
- D.caseSignificanceId
- D.caseSignificanceId = 900000000000448009 |entire term case insensitive|
- D.caseSignificanceId = 900000000000017005 |entire term case sensitive|
- D.caseSignificanceId = 900000000000020002 |only initial character case insensitive|
- D.caseSignificance
- D.caseSignificance = "insensitive"
- D.caseSignificance = "sensitive"
- D.caseSignificance = "initialCharInsensitive"
- D.typeId
- D.typeId = 900000000000003001 |fully specified name|
- D.typeId = 900000000000013009 |synonym|
- D.typeId = 900000000000550004 |definition|
- D.type
- D.type = "FSN"
- D.type = "fullySpecifiedName"
- D.type = "synonym"
- D.type = "textDefinition"
- D.acceptabilityId
- D.acceptabilityId = 900000000000549004 |acceptable|
- D.acceptabilityId = 900000000000548007 |preferred|
- D.acceptability
- D.acceptability = "acceptable"
- D.acceptability = "preferred"
Additional Syntactic Sugar - FSN
- FSN = "*heart"
- D.term = "*heart", D.type = "FSN"
- D.term = "*heart", D.typeId = 900000000000003001 |fully specified name|
- FSN = "*heart" LANGUAGE X
- D.term = "*heart", D.type = "FSN", D.acceptability = * LANGUAGE X
- D.term = "*heart", D.typeId = 900000000000003001 |fully specified name|, acceptabilityId = * LANGUAGE X
- synonym
- synonym = "*heart"
- D.term = "*heart", D.type = "synonym"
- D.term = "*heart", D.typeId = 900000000000013009 |synonym|
- synonym = "*heart" LANGUAGE X
- D.term = "*heart", D.type = "synonym", D.acceptability = * LANGUAGE X
- D.term = "*heart", D.typeId = 900000000000013009 |synonym|, (D.acceptabilityId = 900000000000549004 |acceptable| OR D.acceptabilityId = 900000000000548007 |preferred|) LANGUAGE X
- synonymOrFSN
- synonymOrFSN = "*heart"
- synonym = "*heart" OR FSN = "*heart"
- D.term = "*heart", (D.type = "synonym" OR D.type = "fullySpecifiedName")
- synonymOrFSN = "*heart" LANGUAGE X
- synonym = "*heart" OR FSN = "*heart" LANGUAGE X
- D.term = "*heart", (D.type = "synonym" OR D.type = "fullySpecifiedName"), D.acceptability = * LANGUAGE X
- textDefinition
- textDefinition = "*heart"
- D.term = "*heart", D.type = "definition"
- D.term = "*heart", D.typeId = 900000000000550004 |definition|
- textDefinition = "*heart" LANGUAGE X
- D.term = "*heart", D.type = "definition", D.acceptability = * LANGUAGE X
- D.term = "*heart", D.typeId = 900000000000550004 |definition|, D.acceptabilityId = * LANGUAGE X
- Unacceptable Terms
- (D.term = "*heart") MINUS (D.term = "*heart", (D.acceptability = "acceptable" OR D.acceptability = "preferred") LANGUAGE X)
|
| Query Language - Combining language reference sets | | How do we support language preferences, which are defined over multiple language reference sets? For example: 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
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
|
| URI Specification | | - Status update
- URLs for canonical necessary normal form and necessary (long/short) normal form
- Next Meeting:
- Recap on purpose of SNOMED CT computable language URIs?
- Recap on language instance URIs (e.g. URIs for expressions and expression constraints)
|
| Other topics | | Other topics for discussion. For example: - Query language - Can we de-scope relationship filters?
- ECL suggestions - Ability to execute maps in ECL
- The specific use-case here comes initially from Jeremy and relates to being able to work with inactive concepts via the historical association maps. For example, given an ECL expression, e, that identifies a set of concepts to be used for retrieving patient records, you probably also want to retrieve records for sameAs(e) and replacedWith(e)
|
| Confirm next meeting date/time | | The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 4th July. |
13 Comments
Michael Lawley
Also for 7 - Other topics:
Vicente Giménez Solano
Hi Michael,
I am not sure if I understand your question, but I will try to answer it using some examples.
For instance, the following expression constraint (EC) defines the subset of those subtypes of food that cause any subtype of allergic condition (note the use of the Reverse flag “R”):
If you want to define the subset of those concepts in SNOMED CT that cause any subtype of allergic condition, you need to define the following EC:
which is equivalent to (note the use of the dot notation)
On the other hand, If you want to retrieve the domain of a given attribute, you need to define an EC such as the following, which defines the subset of those concepts in SNOMED CT that have a 246075003 |Causative agent (attribute)| attribute:
If you want to retrieve the range of the above EC instead of the domain, you need to define it as follows:
which is equivalent to
Finally, please note that in the ECL specification, a 'concrete value' (e.g. integers, decimals and strings) are now permitted as attribute values. The range of an attribute whose value is concrete will be defined using the keyword "type". This keyword is not part of the core SNOMED CT Expression Constraint language, but instead will be defined as an extension to this language, which is used only for the SNOMED CT Concept Model use case, such as the following EC, which is satisfied only by products with a trade name equal to "PANADOL":
I hope I've helped.
Vicente Giménez
Ed Cheetham
Wrong place to raise this, but the 'starting a new discussion' wizard is baffling!
Neither is it really a language question - more MRCM, but it might be some light relief from the query language stuff...
In essence, how should the Lateralizable body structure domain constraint actually be used?
Its domain is given as << ^ 723264001 |Lateralizable body structure reference set (foundation metadata concept)| throughout the constraint, i.e. identify all the members of 723264001 (^), and then add in all the subtypes (<<)). So, whilst the refset distinguishes between 85562004 | Hand structure (genuninely lateralizable) and, for example, 78791008 | Structure of right hand (already lateralized and therefore no longer actually lateralizable), the domain template for post-coordination would suggest otherwise.
Surely this isn't the intent?
Thoughts welcome. Ed
Ronald Cornet
I agree, Ed.
Would this solve the problem?
<< ^ 723264001 : [0..0] 272741003 |Laterality (attribute)| = << 182353008 |Side (qualifier value)|
Alternatively, the refset should already include all lateralizable children, then "<<" isn't needed.
Best, Ronald
Michael Lawley
> Alternatively, the refset should already include all lateralizable children, then "<<" isn't needed.
This is what I would have expected (and no members that have been lateralised such as 78791008 | Structure of right hand|).
Linda Bird
Hi Ed,
I agree that the domainTemplateForPostcoordination doesn't capture the entire set of constraints - however the MRCM rules do. The range combined with the attributeCardinality of 0..1 ensure that at most 1 |laterality| attribute is applied to each concept.
You may also notice that the domain of "<< ^ 723264001 |Lateralizable body structure reference set|" is an optional domain (but clearly preferred). This therefore does not appear in the domainTemplateForPostcoordination, which instead uses the mandatory domain of "<< 91723000 |Anatomical structure (body structure)|"
So, the domainTemplateForPostcoordination currently reads:
[[+scg(<< 91723000 |Anatomical structure (body structure)|)]]: [[0..1]] 272741003 |Laterality| = [[+scg(<< 182353008 |Side (qualifier value)|)]]
I agree this could be made more specific, by using information about the attributeCardinality constraint in the focus concept slot as such:
[[+scg(<< 91723000 |Anatomical structure (body structure): [0..0] 272741003 |Laterality (attribute)| = *|)]]: [[0..1]] 272741003 |Laterality| = [[+scg(<< 182353008 |Side (qualifier value)|)]]
The same could also be done for other attributes where the attributeCardinality is 0..1, such as |Property|, |Scale type| and |Time aspect|. I can have a look at adding this for the 20190131 release.
Thanks for your comments Ed! And also your suggestion Ronald!
Kind regards,
Linda.
Ed Cheetham
Thanks all for your responses.
I'm not sure I fully understand Linda's '... information about the attributeCardinality constraint in the focus concept slot...' suggestion, but maybe I will in time.
I don't think it's really a cardinality concern either: 'lateralizable' in the name suggests optionality of the lateralizing act, and I'm content with that.
What I still don't get is:
(a) what SI really think the value of the 'Lateralizable body structure reference set' is, and
(b) whether references to this set in the MRCM are 'consistent' with its intended use.
The release notes (Jan 2017) state:
"...the Lateralizable Body Structure Reference Set...includes all body structures that can be lateralized..." & "...It can also be used for the MRCM specification for quality assurance. The post-coordination of laterality can be supported by the new refset. It can help with the identification of concepts in hierarchies, e.g. finding/disorder, procedure, situation, which are lateralizable based on their concept modelling."
This suggests that the set only includes midline symmetrical body structures, and does NOT include already lateralized structures.
Such a set would be useful: Should an interface offer a lateralisation control for a disorder of the pineal gland or a procedure on the pancreas? No; Should an interface offer a lateralisation control for an already lateralized procedure (e.g. 2411000087105 | MRI of right hip)? No. Basically Michael's 'expectation'.
Both of these design requirements seem to be directly addressed by the published membership of the Lateralizable Body Structure Reference Set. There are still a small number of published 'lateralizable' false positives (e.g. 8012006 | Structure of anterior communicating artery is a set member but is understood to be a midline structure that simply links left and right), and I expect there will be false negatives.
However, its use in MRCM constraints and templates - prefixed by "<< " - means that an implementer using the refset in the context of the 'Domain template for postcoordination' template from 723560006 | MRCM domain international reference set (id=eb0bebd1-991a-4f69-97ab-e1c5bf64dd27):
[[+scg(<< ^ 723264001 |Lateralizable body structure reference set (foundation metadata concept)|)]]: [[0..1]] 272741003 |Laterality| = [[+scg(<< 182353008 |Side (qualifier value)|)]]
...to inform their interface behaviour will falsely offer a lateralization control for lateralized procedures and disorders.
My contention is not the cardinality, its the "<<".
Kind regards
Ed
Linda Bird
Hi Ed,
I have discussed this with the Content Team, and they have confirmed that the |Lateralizable body structure refset| contains all body structures that can be lateralized, and that the "<<" is therefore not necessary in this domain.
I will see if this update can make it into the 20180731 MRCM ... but if not, then it will be changed in the 20190131 version.
Thanks for raising this Ed!
Kind regards,
Linda.
Ed Cheetham
Thanks Linda, all
If it's going to be revised, I'd suggest that the range for the post-coordination use case should be < 182353008 |Side (qualifier value)| rather than << 182353008 |Side (qualifier value)|
the |Side| value is useful (although under-applied) for the pre-coordinated data, but I can't see how it is 'sensible' for post-coordination.
Finally I'd strengthen my concerns about the actual membership quality of 723264001. Digging around this morning, it's not hard to find both false positive (727986007 | Entire optic chiasma (body structure), 731099006 | Entire body of sacral vertebra (body structure)) and false negative (10013000 | Lateral meniscus structure (body structure), 731649006 | Entire bone of first metacarpal (body structure)) members. I can and shall report what I find in a time-limited search, but if this is to be a useful product ("...The post-coordination of laterality can be supported by the new refset...") then it needs to be more reliable.
Kind regards
Ed
Peris Brodsky
Regarding |Side|, I agree with you Ed.
If I'm not mistaken, the same argument can be made about the range constraints for
and perhaps a few more of the |Clinical finding| attribute range constraint clauses, which all seem, rather reflexively, to be prefixed by the inclusive '<<'.
-Peris
Ed Cheetham
Thanks Peris.
Yes - good point.
The four you highlight plus some other suitable candidates can be found here (one of the MRCM precursor resources). Any A=V pair that ends with the arcane '(<=)(< Q)' notation in the third column (explanation at the bottom of the table) has previously been thought of in terms of "...use any descendant value (plus the supertype as a grouper) in the reference data definitions, but only use descendants for composing expressions ('qualification')..." so maybe should have this reflected in the MRCM files.
Kind regards
Ed
Linda Bird
Hi!
I have discussed this internally, and we should be able to change the domain constraint that Ed referred to above to "^ 723264001 |Lateralizable body structure reference set (foundation metadata concept)|" for the upcoming 20180731 release. However, it is too late in our release cycle to make the other suggested changes to the range constraints, as these will involve both internal agreement plus validation of the entire release against the stricter rules.
However, I have added these range constraints to the list of topics to be considered for the 20190131 MRCM release.
Thanks for your comments!
Kind regards,
Linda.
Ed Cheetham
Thanks Linda.
Ed