2017-08-16 - SLPG Meeting

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

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:

• 414531002 | Intoxication with Clostridium botulinum toxin (disorder)
• 398565003 | Infection caused by Clostridium botulinum (disorder)

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

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?