SNOMED CT Languages Project Group

Space shortcuts

Page tree

Date & Time

20:00 to 21:00 UTC Wednesday 21st October 2020

Location

Zoom meeting link (password: 764978)

Goals

  • Start development of postcoordination guidance

Attendees 

Apologies


Agenda and Meeting Notes

Description
Owner
Notes

Welcome and agenda

Linda Bird

NOTE: Next meeting to be held on Wednesday 4th November

Postcoordination GuidanceLinda Bird , Anne Randorff Højen , Kai Kewley

Practical Guide to Postcoordination

  • Agree on list of expression forms that need defining - 3.4 Transforming Expressions
  • Discuss different types of transformations required
  • Explain transformation steps



Other Options for Future Progress
  1. Postcoordination and close-to-user transformations
  2. URIs for draft editions
  3. 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)
  4. Template extensions
URIs for Extended Editions

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:

  • http://snomed.info/sct/900000000000207008/version/20200731/module/733983009/time/20200131/module/733984003/time/20200131
  • http://snomed.info/sct/900000000000207008/version/20200731/modules/733983009:733984003
  • http://snomed.info/sct/900000000000207008:733983009:733984003/version/20200731:20190731:20200131
  • Canonical order? Or order doesn't matter?
  • Constraints on what can go in the additional packages (only refsets and their metadata)
Querying Refset AttributesLinda Bird

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

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

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 odontogram refset members.svg 2020-Oct-26 by Ed Cheetham
File general dentistry diagnostic refset members.svg 2020-Oct-26 by Ed Cheetham


  • No labels

2 Comments

  1. Ed Cheetham

    Hi Linda, all


    Regrettably I shan’t be able to attend the next call, but in the meantime a couple of thoughts on where we might focus the post-coordination guidance work…


    I wonder if a useful focus for the guidance document, certainly for discussion, might be the two dental reference sets:

    721144007 | General dentistry diagnostic reference set

    721145008 | Odontogram reference set

    Both contain members from a mixture of SNOMED CT chapters (see the two svg’s linked below ([1] and [2]) for a structured/graphical display of membership), and both implicitly (and in the case of the odontgram set - explicitly) require a compositional approach to meet their stated requirements. These are therefore some of the few examples (? only examples) of SI-badged materials that require/expect users to venture into the world of compositional expression creation and post-coordinated classification and analysis.


    At present the documentation is fairly vague about how this is to be achieved [3], and really only presents the ECL documentation as further reading. This might help with syntactic aspects, but would be silent on many other things that are needed.


    It is perhaps also quite a well-bounded topic (<400 concepts across the two sets), but still manages to touch on a lot of topics which we’ve already identified as worthy of consideration in any implementation guidance:

    • Various forms of expression creation (site & morphology refinement, laterality issues, context value specification for procedure states, varying situation supertypes for finding context states)
    • Lack of display names for compositional expressions (including diagram-based data input)
    • Close-to-user vs. ‘full expression’ recording for refinement (e.g. should the site values in both RGs be specified when 235104008 | Impacted tooth is recorded, or is a close-to-user or ‘intermediate representation’ form preferable?)
    • Equivalence detection for analysis of merged pre- and post-coordinated data (such as counting up all the impacted and extracted wisdom teeth that are recorded using the odontogram approach or their existing pre-coordinated counterparts!).
    • Reconciling the use of ‘same-but-different’ morphologic abnormality ‘caries’ values between the two reference sets.
    • The challenges of composition that is unsupported by the current model: notably it’s a shame that all the tooth surfaces cannot be formally related to their corresponding teeth (how can this be further developed?) and also the inclusion of the qualifier value 63161005 | Principal which is not referenced in any current MRCM attribute range).
    • ? Other areas. Sadly I can’t detect any use of GCIs or other DL exotica, but perhaps others can find them!


    Even if it isn’t the primary focus of the work, I think it would be valuable to ensure that the implementation aspects of these reference sets are well supported by the post-coordination guidance as it evolves.


    Kind regards


    Ed


    [1] odontogram refset members.svg (right click and 'save as' if the links don't open)

    [2] general dentistry diagnostic refset members.svg

    [3] snip from the Odontogram refset release notes (here) - my emphasis:


    6.3 The use of expressions

    Not all findings/procedures can be represented by a single concept, and the implementation therefore is based on the use of expressions. At this time the aim has been to limit the need for expressions to the combination of two concepts. The introduction of expressions greatly reduces the amount of concepts needed, and in some cases it could ease the implementation, storage and exchange.

    The use of expressions relates to:

    Caries-finding

    Reason for tooth loss

    Procedures

    For more information on the use of expressions, please refer to the guide on Expression Constraint Language.


    6.4 Procedures and restorations present

    Procedures will probably benefit the most from use of expressions. A dentist will chart a procedure in several different states. As a finding of a past procedure - finding an "old" restoration, when planning a procedure, when performing a procedure etc. To avoid concept explosion, and to ease implementation, it is recommended that any dental procedure is represented by the use of the appropriate concept from the procedure hierarchy combined with a qualifier value.


  2. Linda Bird

    Thank you so much for taking the time to contribute to this discussion Ed! 

    I will take a look at the refsets you've suggested before the next meeting, so that we can discuss. 

    Sorry you can't make the meeting this week .... we will give you an update at the following one.

    Kind regards,
    Linda.