Date & Time
20:00 UTC Wednesday 16th August 2017
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
- Discuss next priorities
- Review proposed updates to URI standard
- Review proposed Query language examples
- Explore additional questions posed by Daniel
Attendees
- Chair: Linda Bird
- Project Group: Daniel Karlsson, Michael Lawley, Alejandro Lopez Osornio, Peris Brodsky, Anne Randorff Højen, Brian Carlsen, Ed Cheetham
Agenda and Meeting Notes
Description | Owner | Notes |
|---|---|---|
Welcome and apologies |
| |
| Next priorities | Recent publication of:
Outstanding work items:
| |
| Proposed updates to URI standard | Updates to SNOMED CT URI standard
| |
| Query Language |
| |
| Questions from Daniel | Discuss questions from Daniel (if time permits)
| |
| Confirm next meeting date/time | Next meeting to be held at 20:00 UTC on Wednesday 30th August 2017 |
Meeting Files
6 Comments
Ed Cheetham
Hi Linda
Apologies for my poor attendance recently. Tonight is a clash with ISO TC 215 WG 3 monthly call, but I plan to attend the second half of the SLPG call. Hope that's OK. Ed
Ed Cheetham
If I understood correctly, right at the end of last week's call Michael indicated a requirement to return (in settings where routinely only synonyms were displayed) the corresponding FSN tag or suffix for a concept of interest. This was raised in the context of a possible need to extend the URI specification, and we were asked to provide any thoughts we had.
Now both may be good ideas (returning tags and being able to do so using a URI representation), but I'm not totally convinced.
There may be an argument for handling part of a regularly-structured field value as a SNOMED CT component in its own right (e.g. an 'official' mechanism to return a check digit - actual or calculated), but officially supporting (via the URI spec) the communication of a term substring seems a bit too creative.
As poorly structured mixture of counter-argments and suggestions for alternatives:
(1) why not just return the whole FSN? This gives the tag plus a bit more information, and would already be supported by the http://snomed.info/id/{sctid} URI feature.
I accept that its length requirements are more demanding, but 'synonym' plus 'tag' isn't an assured SNOMED CT entity.
It's true that most polysemic synonyms/PTs can be resolved by just the tag (because of cross-kind notions such as morphology/disorder and product/substance, and less commonly procedure/disorder such as 122488002 & 262920002 both having a PT of 'Transection of vas deferens'), but there are occasions where tags are identical and it is the rest of the FSN that discriminates. For example 'Botulism' is the preferred term for two different disorders:
The former is a poisioning with the toxin (+/- infection), the latter is an infection. Just returning the tag would not discriminate.
(2) If, despite this, there is appetite to go down the tag route, then I would suggest that a more valuable approach would be to index content - according to its tags - but in terms of the concepts where that tag is 'introduced'. The editorial guide tells us that "...The semantic tag indicates the semantic category to which the concept belongs (e.g. clinical finding, disorder, procedure, organism, person, etc.)..."
If so it would be helpful to clarify what 'semantic categories' in SNOMED CT 'are'. Up to now they have (largely) functioned as least remote common ancestors of their corresponding tags. It is true that the data has some deviation from this (the January 2017 international data had about 90 infractions of my assumed 'category' concepts - mostly disorders, a few regime/therapy concepts, plus 109186003 | Sickle cell test kit (substance) and 440245005 | Dressing medicated with leptospermum honey (product) both published as 'physical objects'.
I'm also conscious that the design principles behind the 'new clinical drug / medicinal product / medicinal product form' tags may not be as explicitly 'subsumptive' as that applied to the 40+ previous 'semantic categories', but these 'exceptions' aren't necessarily a reason not to recast the question 'what is the semantic tag for this concept?' as 'what is the semantic category for this concept?'. The answer to the former question is a short word or phrase (not currently handled by the URI spec). The answer to the second question can be passed as a concept, a description or (if introduced to the data) a definition - all currently handled by the URI spec. As mentioned on the call, because categories subsume other categories, the most complete 'category'-based answer may include a set of subsuming categories (e.g. cell, cell structure, body structure).
I attach a spreadsheet showing my best guesses as to the concept 'introduction points' that correspond to each tag (excluding the new pharmacy ones). 3/4 of them have an exact match synonym already, and for the others I've included a Damerau–Levenshtein distance (DL).
Kind regards
Ed
tags201708_EC.xlsx
Daniel Karlsson
I did a quick test to see how many concept there were with intermediate deviating semantic tags, i.e. with one semantic tag where an ancestor and a descendant had the same but different one. Most of them were "medicinal product" or "medicinal product form" surrounded by "product". Found two "finding"s with a "disorder" ancestor: 677641000119104 | Subretinal neovascularization of bilateral eyes (finding) |, 722926003 | Transient neonatal neutropenia co-occurrent and due to neonatal bacterial sepsis (finding) |. So, semantic tag is fairly reliable outside the product hierarchy.
Michael Lawley
That sounds to me like a bug! Preferred terms should be unique, at least within a hierarchy.
Michael Lawley
Note, I don't particularly like the semantic tag stuff myself, but it does exist, and can be somewhat useful for UI purposes. Because it exists, it seems not unreasonable to have a way to 'address' it, and this was my intent in suggesting that a URI be defined so we can talk about them.
But it also raises the question of whether they should exist at all, and/or whether they should be manifest in some other way (e.g., as another descriptionType)
And related to this, there appears to be a convention that abbreviations are included as descriptions of the form:
[A-Z0-9]+ - .*
i.e., the abbreviation followed by space dash space followed by an expansion of the abbreviation. The problem with this approach is that when implementing search scoring algorithms that reduce the score based on the number of non-matched words, this causes very low scores for otherwise exact abbreviation matches (e.g. URTI). This is made worse when an abbreviation is also a valid word prefix.
So the question is, why are the abbreviations on their own included as valid synonyms?
Jeremy Rogers
I would agree that its useful to postprocess SNOMED content by stripping the semantic tag off FSNs and storing the result against each conceptId, and also that this is - perhaps surprisingly - not an entirely trivial operation to perform, so that it would seem convenient for it to be provided instead as either a new description type. Or, perhaps better, as series of 60-odd refsets (one per semantic type). I guess its a question of how much postprocessing of the content should everybody have to do before anybody actually has a usable implementation, and how much of that might as well be done once and at the centre.
WRT the abbreviations, the reason they never appear on their own as free-standing descriptions and without the full expansion of the abbreviation immediately following is that, given the parlous state of the huge majority of existing commercially available coding interfaces, it would be (has been) clinically very unsafe to do so : there are too many clinical TLAs and acronyms with more than one clinically entirely different meaning (MI and RTA to name but two) and too many coding interfaces that would not force (or enable) the clinician to tell the difference between which meaning they were actually selecting.