SNOMED CT Languages Project Group

Space shortcuts

Page tree

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

Date & Time

20:00 UTC Wednesday 28th March 2018

Teleconference Details

To join the meeting please go to https://snomed.zoom.us/j/471420169. 

Further information can be found at SLPG meeting information

Goals

  • Clarify execution semantics of reverse cardinality in ECL
  • Progress SNOMED Query language

Attendees 

Apologies


Agenda and Meeting Notes

Description
Owner
Notes

Welcome and apologies

Linda Bird


ECL reverse cardinality

Linda Bird

Question

I have a doubt in expression constraints with reverse cardinalities: only non-redundant attributes have to be included in the cardinality count?

For example, the following EC:

<< 105590001 |substance|: [3..3] R 246075003 |causative agent| = << 404684003 |clinical finding|

returns this concept (among others): 72551001 |Metal fumes (substance)|. This substance is the causative agent of three clinical findings: 74800004 |Brass-founders' fever|, 72163003 |Metal fever| and 308905009 |Welders ague|. Both concepts, 74800004 |Brass-founders' fever| and 308905009 |Welders ague| are a type of 72163003 |Metal fever|. So the question is: does the EC above has to return 72551001 |Metal fumes (substance)|? Or this substance should be matched with [2..x] cardinality? (Please note that x corresponds to 2, 3...*).

Proposed Answer (for discussion)

At the moment, existing implementations (that I know of) seem to return 72551001 |Meta fumes (substance)|; and the SNOMED International Browser shows the 3 concepts that you mention in the list of causative agent "References" for the concept 72163003 |Meta fever|.

However, whether or not this is the correct semantics for ECL comes down to how we interpret "redundant relationships". I think this may require a further discussion with the implementation community (which I can start through the SNOMED Languages Project Group). However, these are my current thoughts on how redundancy should be treated.... Given concepts X and Y, and attribute R:

    1. IF relationship (X R Y) (i.e. "All X have an R relationship with some Y") THEN relationship (X R supertype(Y)) (i.e. "All X have an R relationship with some supertype of Y)
    2. IF relationship (X R Y) (i.e. "All X have an R relationship with some Y") THEN relationship (subtype(X) R Y) (i.e. "All subtypes of X have an R relationships with some Y")

An example of the first inference is:

    • IF relationship (|Copper fever|,|Causative agent|, |Copper fumes|) THEN relationship (|Copper fever|, |Causative agent|, |Metal fumes|)
    • Therefore if both these relationships are true, then relationship (|Copper fever|, |Causative agent|, |Metal fumes|) is redundant

An example of the second inference is:

    • IF relationship (|Metal fever|,|Causative agent|, |Metal fumes|) THEN relationship (|Brass-founders' fever|, |Causative agent|, |Metal fumes|)
    • Therefore if both these relationships are true, then relationship (|Brass-founders' fever|, |Causative agent|, |Metal fumes|) is redundant

If this logic above is correct, then the only non-redundant relationship involving a |Causative agent| of |Metal fumes| is the relationship (|Metal fever|, |Causative agent|, |Metal fumes|) ... in which case the concept |Metal fumes| should only be returned when the cardinality include [1]. For example:

        << 105590001 |substance|: [1..1] R 246075003 |causative agent| = << 404684003 |clinical finding|

However, I would like to discuss this further with the implementation community, given this is not the way current implementation are working.

Query Language - Recap from last week

Linda Bird

Examples: version and language

Notes

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


Examples: where

Notes

      • Allow nested variable definitions, but recommend that people don't due to readability
      • Scope of variables is the inner query
      • No recursion e.g X WHERE X = 1234 MINUS X
        • ie can't use a variable in its own definition
        • ie X is only known on the left of the corresponding WHERE, and not on the right of the WHERE
Query Language - Combining language reference sets

Linda Bird

How do we support language preferences, which are defined over multiple language reference sets? For example:

  • Assume: No concept has descriptions in 2 listed language refsets ...

  • But if they do: do they override or are they additive?

  • Option 1: PTs override (so order is important), and acceptable terms are additive. If there are 2 PTs, then the second PT is acceptable.

    • See, for example 999001891000000105 |Paediatric neurodisability outpatient diagnosis language reference set|

  • Option 2: Use '+' to indicate additive, and ',' to indicate priority order (with override). For example:

    • LANGUAGE 999001891000000105 |Paediatric neurodisability outpatient diagnosis language reference set| , 900000000000508004 |GB English|

      • Priority order: This means that if a concept has descriptions in the Paediatric LRS, then this LRS is used. But if a concept has no descriptions in the Paediatric LRS, then GB English is used

    • LANGUAGE 999001881000000108|GB clinical extension LRS| + 900000000000508004 |GB English|
      • Additive: This means that if a concept has a PT in both LRSs, then the PTs in the Paediatric LRS take priority, and the PT in the GB English LRS becomes acceptable. Other terms are acceptable if they are acceptable in either LRS.
    • LANGUAGE 999001891000000105 |Paediatric neurodisability outpatient diagnosis language reference set| ,
      999001881000000108|GB clinical extension LRS| + 900000000000508004 |GB English|
      • Priority order and Additive: This means that if a concept has a PT in both LRSs, then the PTs in the Paediatric LRS take priority, and the PT in the GB English LRS becomes acceptable. Other terms are acceptable if they are acceptable in either LRS.
Filters for Lexical Searching


Linda Bird

What filter keywords will we introduce for Term-based searching, and what are their exact meanings?

  • D.term
    • D.term = "*heart*"
    • D.term = wild:"*heart*"
    • D.term = regex:".*heart.*"
    • D.term = match:"hear att"
    • D.term = (sv) wild: "*heart*"
  • D.languageCode
    • D.languageCode = "en"
    • D.languageCode = "es"
  • D.caseSignificanceId
    • D.caseSignificanceId = 900000000000448009 |entire term case insensitive|
    • D.caseSignificanceId = 900000000000017005 |entire term case sensitive|
    • D.caseSignificanceId = 900000000000020002 |only initial character case insensitive|
  • D.caseSignificance
    • D.caseSignificance = "insensitive"
    • D.caseSignificance = "sensitive"
    • D.caseSignificance = "initialCharInsensitive"
  • D.typeId
    • D.typeId = 900000000000003001 |fully specified name|
    • D.typeId = 900000000000013009 |synonym|
    • D.typeId = 900000000000550004 |definition|
  • D.type
    • D.type = "FSN"
    • D.type = "synonym"
    • D.type = "definition"
  • D.acceptabilityId
    • D.acceptabilityId = 900000000000549004 |acceptable|
    • D.acceptabilityId = 900000000000548007 |preferred|
  • D.acceptability
    • D.acceptability = "acceptable"
    • D.acceptability = "preferred"
    • ? D.acceptability = "unacceptable"
  • FSN
    • FSN = "*heart*"
  • synonym
    • synonym = "*heart*"
  • definition
    • definition "*heart*"
  • preferredTerm
    • preferredTerm = "*heart*"
  • preferredFSN
    • preferredFSN = "*heart*"
  • acceptableTerm (literal)
    • acceptableTerm = "*heart*"
  • acceptableFSN
    • acceptableFSN = "*heart*"
Confirm next meeting date/time
Linda Bird

Due to the April SNOMED business meeting in London, the next SLPG meeting will be held in 4 weeks at 20:00 UTC on Wednesday 25th April 2018.

  File Modified
No files shared here yet.


  • No labels