SNOMED CT Languages Project Group

Space shortcuts

Page tree

Date & Time

20:00 to 21:00 UTC Thursday 25th March 2021

Location

Zoom meeting link (password: 764978)

Goals

  • Consider the processes required for data entry, display, query and exchange of a postcoordinated expression

Attendees 

Apologies

Agenda and Meeting Notes

Description

Owner

Notes

Welcome and agenda

Linda Bird


Postcoordination Expression ProcessesAll

Postcoordinated expression processes

  • Generic
  • Use case specific
    • Mapping (from an interface term)
    • Terminology binding (using an expression template)
    • Natural Language processing
Postcoordination Use Case ExamplesAll

Example 1 - Dentistry / Odontogram

  • Requires an expression template to create expressions.
  • Resulting expression still requires a transformation to make it classifiable

Example 2 - Terminology binding

  • Uses a fixed expression template to combine codes entered into separate fields
  • The procedure+laterality example still requires a transformation to make it classifiable

Example 3 - Mapping

  • Design-time activity
  • Map targets may not be able to be fully represented using concept model attributes
  • In many cases, an extension (with primitive concepts) should be recommended where there are gaps in the mapping
  • There may be some cases in which postcoordination is helpful (e.g. LOINC to SNOMED CT map)

Example 4 - Natural Language Processing

  • Usually run-time activity.
  • May require manual confirmation of coding suggestions (unless low clinical risk, eg for suggesting relevant patient records for manual review)
Postcoordination Guidance

Linda Bird , Anne Randorff Højen , Kai Kewley

Practical Guide to Postcoordination

  • Proposal - Use syntax (i.e. braces) to distinguish refinement vs new role group
  • Proposal: Expression forms needed for this (see 3.4 Transforming Expressions)
    • Close to user form - e.g. 83152002 |Oophorectomy| :  405815000 |Procedure device|  =  122456005 |Laser device|
    • Canonical close to user form - e.g. 83152002:405815000=122456005
    • Classifiable form (SCG) - e.g. 83152002:{260686004=129304002,405813007=15497006,405815000=122456005}
      • PLUS Classifiable form (OWL) - e.g.  
        • EquivalentClasses(:123063
             ObjectIntersectionOf (:71388002
                 ObjectSomeValuesFrom(:609096000 ObjectIntersectionOf( ObjectSomeValuesFrom(:260686004 :129304002)
                 ObjectSomeValuesFrom(:405813007 :15497006))))
    • Necessary normal form - e.g. 83152002+416376001:{260686004=129304002,405813007=15497006,405815000=122456005}
      • PLUS Necessary normal form (tables)
        • Relationships:
          • (123063 116680003 83152002) - 0
          • (123063 260686004 129304002) - 0 
          • (123063 405813007 15497006) - 1
          • (123063 405815000 122456005) - 1
    • Primitive expressions - "<<<" (only useful in a mapping context) → .... relies on the assigned identifier (which are necessarily semantically unique).
The items below are currently on hold
Other Options for Future Progress
  1. URIs for draft editions
  2. ECL extensions
    1. Primitive/Defined filters → concept filter
    2. Concept+Description filters (e.g. effectiveTime, module, active)
    3. Accessing Refset attributes → (e.g. historical association refsets) → historical ECL
    4. OR use full syntax to be able to query any table (e.g. Relationship table) - ie expand ECL into something more verbose (e.g. SNOMED query language)
  3. Template extensions
URIs for Extended Editions

ON HOLD - How to refer to an 'extended edition' using a URI - e.g. "International Edition plus the following 2 nursing modules: 733983009  |IHTSDO Nursing Health Issues module|and 733984003 |IHTSDO Nursing Activities module|

Use Case - Need to execute an ECL, that refers to "^ 733991000 | Nursing Health Issues Reference Set (foundation metadata concept) |" and/or "^ 733990004 | Nursing Activities Reference Set (foundation metadata concept) |", where the substrate includes the international edition, plus the modules that include these reference sets

July 2020 International Edition URI: http://snomed.info/sct/900000000000207008/version/20200731

July 2020 International Edition + nursing modules URI ?? - For example:

Querying Refset AttributesLinda Bird

ON HOLD - Proposed syntax to support querying and return of alternative refset attributes (To be included in the SNOMED Query Language)

  • Example use cases
    • Execution of maps from international substance concepts to AMT substance concepts
    • Find the anatomical parts of a given anatomy structure concept (in |Anatomy structure and part association reference set)
    • Find potential replacement concepts for an inactive concept in record
    • Find the order of a given concept in an Ordered component reference set
    • Find a concept with a given order in an Ordered component reference set
  • Potential syntax to consider (brainstorming ideas)
    • SELECT ??
      • SELECT 123 |referenced component|, 456 |target component|
        FROM 799 |Anatomy structure and part association refset|
        WHERE 123 |referenced component| = (< 888 |Upper abdomen structure| {{ term = "*heart*" }} )
      • SELECT id, moduleId
        FROM concept
        WHERE id IN (< |Clinical finding|)
        AND definitionStatus = |primitive|
      • SELECT id, moduleId
        FROM concept, ECL("< |Clinical finding") CF
        WHERE concept.id = CF.sctid
        AND definitionStatus = |primitive|
      • SELECT ??? |id|, ??? |moduleId|
        FROM concept ( < |Clinical finding| {{ term = "*heart*" }} {{ definitionStatus = |primitive| }} )
      • Question - Can we assume some table joins - e.g. Concept.id = Description.conceptId etc ??
      • Examples
        • Try to recast relationships table as a Refset table → + graph-based extension
        • Find primitive concepts in a hierarchy
    • ROW ... ?
      • ROWOF (|Anatomy structure and part association refset|) ? (|referenced component| , |target component|)
        • same as: ^ |Anatomy structure and part association refset|
      • ROWOF (|Anatomy structure and part association refset|) . |referenced component|
        • same as: ^ |Anatomy structure and part association refset|
      • ROWOF (|Anatomy structure and part association refset|) {{ |referenced component| = << |Upper abdomen structure|}} ? |targetComponentId|
      • ROWOF (< 900000000000496009|Simple map type reference set| {{ term = "*My hospital*"}}) {{ 449608002|Referenced component| = 80581009 |Upper abdomen structure|}} ? 900000000000505001 |Map target|
        • (ROW (< 900000000000496009|Simple map type reference set| {{ term = "*My hospital*"}}) : 449608002|Referenced component| = 80581009 |Upper abdomen structure| ).900000000000505001 |Map target|
    • # ... ?
      • # |Anatomy structure and part association refset| ? |referenced component\
      • # (|Anatomy struture and part association refset| {{|referenced component| = << |Upper abdomen structure|) ? |targetComponentid|
    • ? notation + Filter refinement
      • |Anatomy structure and part association refset| ? |targetComponentId|
      • |Anatomy structure and part association refset| ? |referencedComponent| (Same as ^ |Anatomy structure and part association refset|)
        (|Anatomy structure and part association refset| {{ |referencedComponent| = << |Upper abdomen structure}} )? |targetComponentId|
      • ( |Anatomy structure and part association refset| {{ |targetComponentId| = << |Upper abdomen structure}} ) ? |referencedComponent|
      • ( |My ordered component refset|: |Referenced component| = |Upper abdomen structure ) ? |priority order|
      • ? |My ordered component refset| {{ |Referenced component| = |Upper abdomen structure| }} . |priority order|
      • ? |My ordered component refset| . |referenced component|
        • equivalent to ^ |My ordered component refset|
      • ? (<|My ordered component refset|) {{ |Referenced component| = |Upper abdomen structure| }} . |priority order|
      • ? (<|My ordered component refset| {{ term = "*map"}} ) {{ |Referenced component| = |Upper abdomen structure| }} . |priority order|
      • REFSETROWS (<|My ordered component refset| {{ term = "*map"}} ) {{ |Referenced component| = |Upper abdomen structure| }} SELECT |priority order|
    • Specify value to be returned
      • ? 449608002 |Referenced component|?
        734139008 |Anatomy structure and part association refset|
      • ^ 734139008 |Anatomy structure and part association refset| (Same as previous)
      • ? 900000000000533001 |Association target component|?
        734139008 |Anatomy structure and part association refset|
      • ? 900000000000533001 |Association target component|?
        734139008 |Anatomy structure and part association refset| :
        449608002 |ReferencedComponent| = << |Upper abdomen structure|
      • ? 900000000000533001 |Association target component|?
        734139008 |Anatomy structure and part association refset|
        {{ 449608002 |referencedComponent| = << |Upper abdomen structure| }}
      • (? 900000000000533001 |Association target component|?
        734139008 |Anatomy structure and part association refset| :
        449608002 |ReferencedComponent| = (<< |Upper abdomen structure|) : |Finding site| = *)
Returning AttributesMichael Lawley

ON HOLD - Proposal (by Michael) for discussion

  • Currently ECL expressions can match (return) concepts that are either the source or the target of a relationship triple (target is accessed via the 'reverse' notation or 'dot notation', but not the relationship type (ie attribute name) itself. 

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| 

    • Perhaps something like:
      • ? R.type ? (<< 404684003 |Clinical finding|)
    • This could be extended to, for example, return different values - e.g.
      • ? |Simple map refset|.|maptarget| ? (^|Simple map refset| AND < |Fracture|)
Reverse Member OfMichael Lawley

ON HOLD - Proposal for discussion

What refsets is a given concept (e.g. 421235005 |Structure of femur|) a member of?

  • Possible new notation for this:
    • ^ . 421235005 |Structure of femur|
    • ? X ? 421235005 |Structure of femur| = ^ X

Expression Templates

Peter G. Williams

  • ON HOLD WAITING FROM IMPLEMENTATION FEEDBACK FROM INTERNAL TECH TEAM
  • WIP version - https://confluence.ihtsdotools.org/display/WIPSTS/Template+Syntax+Specification
      • Added a 'default' constraint to each replacement slot - e.g. default (72673000 |Bone structure (body structure)|)
      • Enabling 'slot references' to be used within the value constraint of a replacement slot - e.g. [[ +id (<< 123037004 |Body structure| MINUS << $findingSite2) @findingSite1]]
      • Allowing repeating role groups to be referenced using an array - e.g. $rolegroup[1] or $rolegroup[!=SELF]
      • Allow reference to 'SELF' in role group arrays
      • Adding 'sameValue' and 'allOrNone' constraints to information slots - e.g. sameValue ($site), allOrNone ($occurrence)
      • See changes in red here: 5.1. Normative Specification

Examples:

[[+id]]: [[1..*] @my_group sameValue(morphology)] { |Finding site| = [[ +id (<<123037004 |Body structure (body structure)| MINUS << $site[! SELF ] ) @site ]] , |Associated morphology| = [[ +id @my_morphology ]] }

  • Implementation feedback on draft updates to Expression Template Language syntax
    • Use cases from the Quality Improvement Project:
      • Multiple instances of the same role group, with some attributes the same and others different. Eg same morphology, potentially different finding sites.

Note that QI Project is coming from a radically different use case. Instead of filling template slots, we're looking at existing content and asking "exactly how does this concept fail to comply to this template?"

For discussion:

 [[0..1]] { [[0..1]]   246075003 |Causative agent|  = [[+id (<   410607006 |Organism| ) @Organism]] }

Is it correct to say either one of the cardinality blocks is redundant? What are the implications of 1..1 on either side? This is less obvious for the self grouped case.

Road Forward for SI

  1. Generate the parser from the ABNF and implement in the Template Service
  2. User Interface to a) allow users to specify template at runtime b) tabular (auto-completion) lookup → STL
  3. Template Service to allow multiple templates to be specified for alignment check (aligns to none-off)
  4. Output must clearly indicate exactly what feature of concept caused misalignment, and what condition was not met.

Additional note: QI project is no longer working in subhierarchies. Every 'set' of concepts is selected via ECL. In fact most reports should now move to this way of working since a subhierarchy is the trivial case. For a given template, we additionally specify the "domain" to which it should be applied via ECL. This is much more specific than using the focus concept which is usually the PPP eg Disease.

FYI Michael Chu

Description TemplatesKai Kewley
  • ON HOLD
  • Previous discussion (in Malaysia)
      • Overview of current use
      • Review of General rules for generating descriptions
        • Removing tags, words
        • Conditional removal of words
        • Automatic case significance
        • Generating PTs from target PTs
        • Reordering terms
      • Mechanism for sharing general rules - inheritance? include?
      • Description Templates for translation
      • Status of planned specification
Query Language
- Summary from previous meetings




Linda Bird

FUTURE WORK

Examples: version and dialect

Notes

    • Allow nested where, version, language
    • Scope of variables is inner query

  File Modified
File pyelo.svg 2021-Mar-26 by Ed Cheetham
JPEG File pyelo.jpg 2021-Mar-26 by Ed Cheetham
JPEG File nephritis.jpg 2021-Mar-26 by Ed Cheetham
PNG File koilo.png 2021-Mar-26 by Ed Cheetham
JPEG File koilo.jpg 2021-Mar-26 by Ed Cheetham
JPEG File CTHip.jpg 2021-Mar-27 by Ed Cheetham


  • No labels

8 Comments

  1. Ed Cheetham

    Linda, all

    You asked for a few examples of inter-attribute dependencies:

    The one I originally mentioned is acute/chronic and inflammation:

    Addition of 263502005 | Clinical course | = 424124008 | Sudden onset AND/OR short duration | or 263502005 | Clinical course | = 90734009 | Chronic | seems to be accompanied by specialisation of neighbouring 116676008 | Associated morphology | = 409774005 | Inflammatory morphology | role(s):

    (In the combined focus diagrams I'm use a private convention that's omitting extraneous supertypes (for ease of reading) and colouring the equivalent/subset of character blue to indicate that something's missing from each definition). The aim is to show how refinement of the 'pyelonephritis' focus requires >1 change to its role definition).

    Anyway, the implication here is that clinical course refinement of '-itis' to 'acute -itis' or 'chronic -itis' requires changes to associated morphology values too during transformation.

    A couple of other examples - after a quick squint at the editorial guide are:

    Addition of infectious causative agents:

    Superficially it would seem reasonable to refine 'nephritis' to 'bacterial nephritis' but just adding 246075003 | Causative agent | = 409822003 | Domain Bacteria | as a refinement. However, this isn't sufficient; a 370135005 | Pathological process | = 441862004 | Infectious process | role needs adding too:

    Specifying congenital and acquired variants:

    Superficially it would seem reasonable to specify these variants with 246454002 | Occurrence | = 255399007 | Congenital | or 246454002 | Occurrence | = 767023003 | Period of life between birth and death |. In the case of 'congenital' more is needed, as congenital variants also carry a 370135005 | Pathological process | = 308490002 | Pathological developmental process | role:



    There are no doubt many similar rules (and other patterns) that would need to be included in the transformation, but perhaps this is a useful taster.

    In addition, and picking up on Anna's point about the importance of terms, term preservation and term generation, two of these examples have significant differences between the terms for 'selection' and those that would really be thought or intended:

    • There is no term to say simply, 'acute' (instead we have 'Sudden onset AND/OR short duration' - or 'plötslig debut och/eller kort duration' or 'pludseligt udbrud OG/ELLER kort varighed')
    • There is no term to say, simply, 'acquired' (instead we have 'Period of life between birth and death' - or 'period i livet mellan födelse och död')

    Neither of these are unreasonable conceptual variants to want to produce, but it would currently appear to be impossible to produce idiomatic clinical terms based on the available SNOMED CT term 'ingredients'.

    Ed





  2. Ed Cheetham

    Another thought...

    For the 'lateralisation use case', if the laterality value 51440002 |Right and left (qualifier value)| is available for selection then there is a need to ensure that the stored/CTU form is eventually expanded to be comparable with the reference data (where separate 'right' and 'left' groups are used). I'll leave it to Kai's expertise as to how this is achieved, but suspect that the process would be helped by making 51440002 |Right and left (qualifier value)| sufficiently defined to allow the classifier to take on some of the work.

    For example, at some point the single RG of CT Hip would need to become two when transforming a CTU of 241571002 | CT of hip |: 272741003 | Laterality | = 51440002 |Right and left |:


  3. Ronald Cornet

    Hi Ed Cheetham, all,

    Being a lurker on SLPG, I do enjoy discussions like these.

    Please ignore if my comment is off-topic given the context in which this discussion is held.

    Ed states rightfully that: "clinical course refinement of '-itis' to 'acute -itis' or 'chronic -itis' requires changes to associated morphology values"

    Shouldn't this be addressed by an OWL-expression? I was trying to find it, but didn't.

    I would expect a GCI stating (sorry for sloppy formulation)

    SubClassOf(  (SOME Associated Morphology . Inflammatory morphology AND SOME Clinical Course . Chronic)    (SOME Associated Morphology . Chronic Inflammation)  )

    And similar for acute. Happy to hear thoughts on this.

    Ronald

  4. Ed Cheetham

    Thanks Ronald.

    I'll leave it to others to decide how/where the business rules are represented - my motivation was to point out that there are plenty of rules that currently sit in the narrative of the editorial guide that will need to be machine-processable before many, if not all, post-coordination use cases are to be supported. A DL representation of a modelling/DL-relevant rule certainly seems attractive. The Galen work identified several varieties of transformation rule to get from their 'intermediate representation' (sort of 'close-to-user') to a classifiable form, and SI seems to be tackling something very similar now. Some rules will be best represented in OWL, others will, I imagine, benefit from other formalisms. Whatever's used will need to satisfy a bunch of desirable characteristics such as maintainability, availability and explainability, as well as traceability back to the original editorial guide text they represent.

    Ed 

    1. Ronald Cornet

      Ed, I fully agree that "rules that currently sit in the narrative of the editorial guide ... will need to be machine-processable before many, if not all, post-coordination use cases are to be supported. "

      This is what Daniel and I addressed in 2013 in:

      Cornet R, Nyström M, Karlsson D. User-Directed Coordination in SNOMED CT. In: Proceedings of Medinfo 2013, Copenhagen (2013), Studies in Health Technology & Informatics; 2013;192:72-6. doi

      It is important, though, to realize that being machine-processable is only relevant if machine processing is actually done:

      Machine-processing does need to be done, by EHR/terminology services, to establish / realize the inferences.

      Machine-processing will likely need to be performed not only at concept-level, but also at instance-level. This is something that seems to be challenging now. SnoRocket doesn't support instance reasoning. It might be that RDFox can do this, I know it has been used on previous versions of SNOMED CT, but I'm not sure if all "new" features in SNOMED CT, including concrete domains / numbers, are addressed. And it strikes me that there is currently seemingly little activity in further development of reasoners. I hope I'm wrong, as it is crucial that there is sufficient reasoning support provided for SNOMED CT, and the more expressive direction in which it is developing.


      1. Ed Cheetham

        Thanks Ronald - this is really useful.

        Things are unarguably moving in the directions your paper proposes (not least the stabilisation of the MRCM and emergence of an ECL/template formalism in recent years), but there's still a lot to do. This quote stands out to me:

        "...The 2010 release of the GALEN meta-model consists of about 280 grammatical sanctions and about 23,000 sensible sanctions..."

        To my maths the current set of MRCM Domain-Attribute-Range constraints resolve to the roughly same order of magnitude as GALEN's grammatical sanctions (and as your paper says, they essentially perform the same function). The scale and challenge of sensible sanctioning (as a prerequisite for workable post-coordination) should therefore not be underestimated...

        Ed


  5. Ed Cheetham

    A quick, peripherally-related question...

    I'm curious about the attribute 762951001 |Has ingredient |. It is the only attribute with a contentType setting in the 723604009 |MRCM attribute domain reference set| of 723595009 |All postcoordinated SNOMED CT content|. There is little documented about it - I can find mention of it being a 'grouper', and here I am told it is "...not used in the international edition...". Its entry here confirms the contentType setting. I'm sure there used to be a section in the pharmacy editorial guidance, but I cannot find that today.

    Whatever, here are my questions:

    1. If it is not used in the international data, and if it is an ancestor of the attributes that are used, how would expressions in which it was used it be classified and included in relevant analyses?
    2. If it is not used in the international data, what does it mean where it show up in the 'Author View of Attributes and Ranges' table here?

    Thanks. Ed

  6. Linda Bird

    Thanks very much Ed and Ronald for the very interesting discussion.

    Ed - I really appreciate the examples of inter-attribute dependencies and the subsequent discussion. Let's talk this through at this week's SLPG meeting.

    Ronald - Thanks for the paper reference and discussion. We tried the GCI that you suggested, but it didn't quite have the desired effect (ie it grouped the example under |Chronic inflammatory disease|, but because it didn't specialise the morphology of the existing role groups, it still didn't classify the example in the right spot). We're currently wondering whether before+after expression templates may work ... but are very open to suggestions.

    Thank you both! Kind regards, Linda.