SNOMED CT Languages Project Group

Space shortcuts

Page tree

Date & Time

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

Location

Zoom meeting link (password: 764978)

Goals

  • Consider postcoordination use cases

Attendees 

Apologies


Agenda and Meeting Notes

Description

Owner

Notes

Welcome and agenda

user-ec161


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

user-ec161 , 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 Attributesuser-ec161

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




user-ec161

FUTURE WORK

Examples: version and dialect

Notes

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

  File Modified
File Laparosc_06.svg 2021-Mar-10 by Ed Cheetham
PNG File Laparosc_06.png 2021-Mar-10 by Ed Cheetham
PNG File Laparosc_07.png 2021-Mar-10 by Ed Cheetham
File Laparosc_07.svg 2021-Mar-10 by Ed Cheetham


  • No labels

3 Comments

  1. user-ec161

    That you very much Ed and Michael for your comments on this previous meeting page. I'm replying on this week's meeting page to keep this conversation current.

    Ed - I completely agree with the points that you've made. We should (and will) discuss the broader postcoordination 'journey' from creation to classification and querying, to exchange, storage and display etc.  And in doing this, we should consider how these activities should work for each use case (and what guidance to provide). This will be the focus of this week's meeting - however, it is likely to take several meetings to get through everything, so I appreciate your patience. WIth respect to the queries over 'historical expressions' - this is obviously a very important topic - however, this should probably wait until the MAG has provided some recommendations for querying historical precoordinated content first.

    Michael - In the scenario that you and Ed have referred to - in which the clinician records the disorder or procedure with a laterality (as per the UI) - I actually think it's more likely that the clinical system records the disorder/procedure and laterality in separate data elements within the health record (in line with the UI), and only composes these into an expression when they need to squeeze this data into a single field for exchange (e.g. as per FHIR spec). The big question that I think we then have is which form should the expression be put into for exchange - should it be the close-to-user form which is closest to how the data was collected (e.g. |appendectomy|: |laterality| = |left|), the classifiable form (e.g. |appendectomy|: {|Procedure site - Direct| = (Appendix structure|: |laterality| = |left|),|Method = |Excision||, or the NNF form (?). My first instinct would be to use the close-to-user form for exchange (which I consider to be the 'source of truth', with respect to what the user stated). However, I assume you're suggesting that the classifiable form should be used for exchange (i.e. it's created using a specific version of SNOMED, and used in the FHIR resource)? I think the related question is - which expression form is given a unique identifier in the expression repository? My thought is that each close-to-user form expression should be assigned a separate unique expression identifier.

    We can start to discuss these topics further at this week's meeting.

  2. Ed Cheetham

    Thanks Linda.

    Regarding the 'historical' point, maybe they've got this covered but I think my question refers to a challenge that is complementary to any work the MAG and others are doing on how to handle inactive concepts & descriptions. Whilst reference data modelling changes should generally be expected to result in improved data retrieval over time, some kinds of changes to formal definitions will result in discrepancies between compositional expressions created in the past and their future reference data counterparts.

    Using an old example (but I think the principle still holds for future changes), consider the concept 73632009 |Laparoscopy (procedure)|.

    Since 2007 it's been modeled in accordance with this guidance:

    Laparosc_07.svg

    In 2006 it was modeled like this:

    Laparosc_06.svg

    Anyone creating a 'laparoscopy' compositionally in 2006 might reasonably have assumed that an expression based on the 'method'/'access'/'site' role group shown (refining a 'procedure' focus) would meet their needs and would be detected with a corresponding query predicate. However, since 2007 the reference 'retrieval' definition (and thus query predicate) is significantly different. Leaving aside the procedure site attribute and value changes, the significant change is that |Access| = |Endoscopic approach| has been 'REPLACED_BY' |Using device| = |Laparoscope| - and this sort of historical tracking isn't explicitly supported for retrieval.

    I don't have a strong sense of how common 'retrieval-disrupting' model changes are, but if we agree that they are a thing then we can also assume that they will happen in the future. If post-coordination is going to be encouraged then there need to be processes either to predict, identify and mitigate against such changes when they happen, or consider mechanisms to limit post-coordination to more 'stable' areas of the data.

    Ed



  3. user-ec161

    Hi Ed! Really good point! And I think this will impact our guidance on which expression-form to use for each step in the journey... for further discussion in a few hours (after some sleep). Linda.