2018-03-14 - SLPG Meeting

Welcome and apologies

Examples of using ... FROM ...

• • << 64572001 |Disease| {{ term = "*heart*" }} version = Y

  • << 64572001 |Disease| {{ synonym = "*heart*" }} version = Y

  • << 64572001 |Disease| {{ FSN = "*heart*" }} version = Y

  • << 64572001 |Disease| {{ FSN = "*heart*" }} version = Y, language = W

  • << 64572001 |Disease| {{ preferredTerm = “*heart*”}}   version = X, language = Y

  • << 64572001 |Disease| {{ acceptableTerm = “*heart*”}}   version = X, language = Y

  • (* FROM version = X, language = Z) MINUS (* {{ term = "*heart*" }} FROM version = Y, language = W)

  • X MINUS Y WHERE X = (* version = X, language = Z), Y = (* {{ term = "*heart*" }} version = Y, language = W)
  • Allow nested where, version, language
  • Scope of variables - inner query

Examples of using WHERE to set the value of variable:

• • X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547)

  • X MINUS >! X FROM version = Y WHERE X = (<< 1234 : 5678 = << 6547)

  • X MINUS >! Y FROM version = Y WHERE X = (<< 1234 : 5678 = << 6547), Y = (<< 1456)
  • X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547) FROM version Y, language X W
  • X MINUS >! X WHERE X = (<< 1234 : 5678 = << 6547) VERSION Y LANGUAGE X, W
    
  • X minus >! X where X = ( < M where M = (< 1234))) version Y language X, W
    • 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
  • (X version v201703) minus (X version v201703) where X = ( < 136467 ), v201708 = http://snomed.info/sct/1245, v201703 = http://snomed.info/sct/16444
    
  • (X language enus) minus (X language engb) where X = ( < 136467 {{ term = "*heart*" }} ),
    enus = 13535 |en-us Language Refset|, engb = 123435 | en-gb Language RefSset|

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?

• Tentative decision: Assume that they're additive, but if there is overlap (multiple PTs or different statuses for the same description for the same concept):

  • Order is important for resolving preferred terms. Acceptable terms are additive
  • See, for example “Paediatric neurodisability outpatient diagnosis language reference set”

    999001891000000105

• << 64572001 |Disease| {{ preferredTerm = “*heart*” }}

• version = http://snomed.info/sct/999000021000000109, language = (999001881000000108|GB clinical extension LRS|, 900000000000508004 |GB English|)

• << 64572001 |Disease| {{ term = “*heart*” }}

• FROM version = http://snomed.info/sct/999000021000000109, language = (Gastro, GBenglish)
  SET Gastro = 999001881000000108|Gastro LRS|, GBenglish = 900000000000508004 |GB English|)

• What are the rules of composition? For example:
  • Additive approach
    The preferred term and preferred FSN is based on the first language refset in the list to define this for the given concept.
    The acceptable terms is the union of acceptable and preferred terms in all mentioned language refsets
  • Replacement approach
    The preferred term and preferred FSN is based on the first language refset in the list to define this for the given concept.
    The acceptable terms are the ones defined in the first language refset in the list to include a description that refers to the given concept

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
  
  • preferredTerm = "*heart*"
    
• acceptableTerm
  • preferredTerm = "*heart*"
    
• acceptableOrPreferredTerm
  • preferredTerm = "*heart*"
    
• acceptableNotPreferredTerm
  • preferredTerm = "*heart*"

The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 28th March 2018.

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