Page tree

Date & Time

20:00 UTC Wednesday 16th August 2017

Teleconference Details

To join the meeting please go to

Further information can be found at SLPG meeting information


  • Discuss next priorities
  • Review proposed updates to URI standard
  • Review proposed Query language examples
  • Explore additional questions posed by Daniel

Agenda and Meeting Notes


Welcome and apologies

  • Review proposed Query language examples
  • Explore additional questions posed by Daniel
Next priorities

Recent publication of:

Outstanding work items:

  • Updates to SNOMED CT URI standard
  • Development of SNOMED CT Query Language
  • SNOMED CT Expression Constraint Template Language
  • Addition of new features to the SNOMED CT Template Syntax
  • Repository of normative expression constraint results / Failing cases
    • Implementers to generate EOL delimited format
    • File naming of examples and the corresponding results
    • Sorted alphabetically
    • Substrate - 20170731 international edition
    • Compare implementation outputs
  • Others?
Proposed updates to URI standard

Updates to SNOMED CT URI standard

Query Language
  • Review proposed Query Language examples
  • Additional requirements from SLPG members?
Questions from Daniel

Discuss questions from Daniel (if time permits)

  1. to support expression repositories (i.e. where the substrate is dynamic in that expressions could be added), do we need to add the ability to use the ECL to apply constraint operators to post-coordinated expressions, i.e. where a piece of the ECL string is to be interpreted as a SCG expression, e.g. << [ 404684003 | Clinical finding (finding) |: 363698007 |Finding site (attribute)| = 10200004 | Liver structure (body structure) | ]? This would correspond to a DL query.
  2. to support potential expansion of the SNOMED CT logic profile, do we need to extend SCG to support axioms as opposed to only expressions, for example to allow (non-hidden) GCAs to be stated in SCG?
  3. we need an SNOMED CT OWL specification, i.e. how is SNOMED CT (concepts and descriptions) represented in OWL. Is this within the scope of this group?
Confirm next meeting date/time

Next meeting to be held at 20:00 UTC on Wednesday 30th August 2017

Meeting Files

  File Modified
Microsoft Excel Spreadsheet tags201708_EC.xlsx 2017-Aug-24 by Ed Cheetham

  • No labels


  1. 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

  2. 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{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



    1. 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.

    2.  'Botulism' is the preferred term for two different disorders

      That sounds to me like a bug!  Preferred terms should be unique, at least within a hierarchy.

  3. 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?

    1. 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.