| Template Syntax | Linda Bird | 2 new proposals to meet SNOMED International's use cases - Require slotnames to be unique
- Why? To avoid having 2 ways to do the same thing, and to clarify the meaning through value restrictions.
- Template
[[ +id ]]:
{ 116676008 |Associated morphology| = [[ +id @morphology ]],
363698007 |finding site| = [[ +id @findingSite ]] },
{ 116676008 |Associated morphology| = [[ +id ($morphology) ]],
363698007 |finding site| = [[ +id (* MINUS << $findingSite) ]] }
- Valid Expression (Definition of 16027391000119109 |Bone cyst of bilateral tibias (disorder)|)
- 64572001 |Disease| :
{ 116676008 |Associated morphology| = 66954000 |Bone cyst|,
363698007 |Finding site| = 719491009 |Bone structure of right tibia| }
{ 116676008 |Associated morphology| = 66954000 |Bone cyst|,
363698007 |Finding site| = 719492002 |Bone structure of left tibia| }
- Introduce a sameValue constraint (similar to the allOrNone constraint)
- Template
- [[+id]]: [[1..* @group sameValue ($morphology)]]
{ |Finding site| = [[ +id ]] ,
|Associated morphology| = [[ +id @morphology ]] }
- Valid Expression (Definition of 31580001000004106 |Bilateral sacral insufficiency fracture (disorder)| )
- 702561005 |Insufficiency fracture (disorder)|:
{ 363698007 |Finding site (attribute)| = 736830008 |Bone structure of left half of sacrum (body structure)|,
116676008 |Associated morphology (attribute)| = 22640007 |Pathologic fracture (morphologic abnormality)| }
{ 363698007 |Finding site (attribute)| = 736831007 |Bone structure of right half of sacrum (body structure)|,
116676008 |Associated morphology (attribute)| = 22640007 |Pathologic fracture (morphologic abnormality)| }
Use cases: New concept development, querying based on template matching, and template-based modeling transformation Other requirements - Constrain values across 2 or more replacement slots
- 2 replacement slots must have the same value, different values, subsumed values, or not subsumed values.
- Example A - A clinical finding, with 2 role groups with the same morphology, and finding sites that not subsume each other
Template
[[ +id ]]:
{ 116676008 |Associated morphology| = [[ +id @morphology ]],
363698007 |finding site| = [[ +id (<< |Body structure| MINUS << $findingSite2 ) @findingSite1 ]] },
{ 116676008 |Associated morphology| = [[ +id @morphology ]],
363698007 |finding site| = [[ +id (* MINUS << $findingSite1) @findingSite2 ]] }
Valid Expression (Definition of 16027391000119109 |Bone cyst of bilateral tibias (disorder)|)64572001 |Disease| :
{ 116676008 |Associated morphology| = 66954000 |Bone cyst|,
363698007 |Finding site| = 719491009 |Bone structure of right tibia| }
{ 116676008 |Associated morphology| = 66954000 |Bone cyst|,
363698007 |Finding site| = 719492002 |Bone structure of left tibia| }
- Example B - A clinical finding, with one or more role groups in which the morphology is always the same, and no 2 finding sites subsume each other.
Template - 3 role groups with 3 sites: site[1], site[2], site [3] /// site [1,2]
[[+id]]:
[[1..* @group1]] { |Finding site| = [[ +id (* MINUS << $site[!= SELF ] ) @site ]] ,
|Associated morphology| = [[ +id ($morphology [!= SELF] ) @morphology ]] }
Valid Expression (Definition of 31580001000004106 |Bilateral sacral insufficiency fracture (disorder)| )702561005 |Insufficiency fracture (disorder)|:
{ 363698007 |Finding site (attribute)| = 736830008 |Bone structure of left half of sacrum (body structure)|,
116676008 |Associated morphology (attribute)| = 22640007 |Pathologic fracture (morphologic abnormality)| }
{ 363698007 |Finding site (attribute)| = 736831007 |Bone structure of right half of sacrum (body structure)|,
116676008 |Associated morphology (attribute)| = 22640007 |Pathologic fracture (morphologic abnormality)| }
- Default value for replacement slot
- Default value for authoring and template-driven modelling transformations
- Example A - Default finding site of 72673000 |Bone structure|
- Template
- [[ + id ]] :
{ |Finding site| = [[ +id (<< 72673000|Bone structure|) @site default (72673000 |Bone structure (body structure)|) ]]
- Definition status of a replacement slot
- Specifying whether the value used in a replacement slot must be primitive or defined
- Example A - When proximal primitive modelling, the focus concept must be a primitive concept
- Template - Requires use of more expressive query language with filters
- [[ + id (<< 64572001 |Disease| {{ c.definitionStatus = primitive }}) ]]
- Valid Expression
- 195967001 |Asthma (disorder)|
- Definition status of a templated expression
- Specifying the definition status of a templated expression
- Template
- [[ +tok ("===" "<<<") ]] [[ +id ]] : { |Finding site| = [[+id]] }
- Valid Expression
- === 128272009 |Disorder of lower respiratory system| : 363698007 |Finding site| = 39607008 |Lung structure|
- <<< 128272009 |Disorder of lower respiratory system| : 363698007 |Finding site| = 39607008 |Lung structure|
- Attributes used in repeating role groups
- Constraining the set of attributes that appear in a repeating role group
- Example 1 - In a given matching expression, either all the role groups include the attribute |site|, or none of the role groups include the attribute |site|. Similarly, either all role groups include |Occurrence|, or none of the role groups do.
- Template - using allOrNone
- [[+id]]: [[1..* @group1 allOrNone ($site), allOrNone($occurrence)]]
{ [[1..1]] |Associated morphology| = [[ +id @morphology ]],
[[0..1 @site]] |Finding site| = [[ +id ]],
[[0..1 @occurrence]] |Occurrence| = [[ +id ]] } - Valid Expression - Injury of head, neck and chest
- [[ |Disease| ]]:
{ |Associated morphology| = |Injury|, |Finding site| = |Head structure| }
{ |Associated morphology| = |Injury|, |Finding site| = |Neck structure| }
{ |Associated morphology| = |Injury|, |Finding site| = |Chest structure| }
- Valid Expression - Congenital malformation of head and neck
- [[ |Disease| ]]:
{ |Associated morphology| = |malformation|, |Finding site| = |Head structure|, |Occurrence| = |Congenital| }
{ |Associated morphology| = |malformation|, |Finding site| = |Neck structure|, |Occurrence| = |Congenital| }
- Example 2 - Some of the optional attributes must either always or never appear in each instance of a repeating role group
- [[+id]]: [[1..* allOrNone($morph) ]]
{ [[ 1..1 ]] |Method| = [[+id]],
[[ 0..1 @morph ]] |Direct morphology| = [[+id ]],
[[ 0..1 ]] |Procedure site - Direct| = [[+id]],
[[ 0..1]] |Using device| = [[+id]] ,
[[ 0..1]] |Has intent| = [[+id]] }
- Valid Expression - Closure of skin by suture
- |Procedure|:
{ |Method| = |Closure - action|, |Procedure site - Direct| = |Skin structure| , |Using device| = |Surgical suture, device|}
- Valid Expression - Core needle biopsy of skin using ultasonographic guidance
- |Procedure|:
{ |Method| = |Ultrasound imaging - action|, |Procedure site - Direct| = |Skin structure| , |Has intent| = |Guidance intent|}
{ |Method| = |Biopsy - action|, |Procedure site - Direct| = |Skin structure| , |Using device| = |Core biopsy needle, device|}
- Valid Expression - Toilet and suture of wound
- |Procedure|:
{ |Method| = |Surgical toilet - action|, |Direct morphology| = |Wound| }
{ |Method| = |Closure - action|, |Direct morphology| = |Wound|,
|Procedure site - Direct| = |Skin structure|, |Using device| = |Surgical suture, device| }
- Example 3 - Some of the optional attributes must either always or never appear in each instance of an inner-nested, repeating role group
- |Finding with explicit context|: [[1..2]]
{ [[ 1..1 ]] |Finding context| = [[+id]],
[[ 1..1 ]] |Temporal context| = [[+id ]],
[[ 1..1 ]] |Subject relationship context| = [[+id]],
[[ 1..1]] |Associated finding| = ( [[+id]] : [[1..* allOrNone($site) allOrNone($Occurrence) ]]
{ [[1..1]] |Associated morphology| = [[ +id @morphology ]],
[[0..1 @site]] |Finding site| = [[ +id ]],
[[0..1 @occurrence]] |Occurrence| = [[ +id ]] } ) }
- Valid Expression - History of Injury of head, neck and chest, and of congenital malformation of head and neck
- |Finding with explicit context|:
{ |Finding context| = |Done|,
|Temporal context| = |In the past|
|Associated finding| = ( |Disease| :
{ |Associated morphology| = |Injury|, |Finding site| = |Head structure| }
{ |Associated morphology| = |Injury|, |Finding site| = |Neck structure| }
{ |Associated morphology| = |Injury|, |Finding site| = |Chest structure| } ) }
{ |Finding context| = |Done|,
|Temporal context| = |In the past|,
|Associated finding| = ( |Disease| :
{ |Associated morphology| = |malformation|, |Finding site| = |Head structure|, |Occurrence| = |Gongenital| }
{ |Associated morphology| = |malformation|, |Finding site| = |Neck structure|, |Occurrence| = |Gongenital| } ) }
- Example 4 - Some of the optional attributes must either always or never appear in each instance of an outer-nested, repeating role group
- |Finding with explicit context|: [[1..2 allOrNone ($site), allOrNone($occurrence), allOrNone($relationship) ]]
{ [[ 1..1 ]] |Finding context| = [[+id]],
[[ 1..1 ]] |Temporal context| = [[+id ]],
[[ 0..1 @relationship]] |Subject relationship context| = [[+id ]],
[[ 1..1]] |Associated finding| = ( [[+id]] : [[1..* ]]
{ [[1..1]] |Associated morphology| = [[ +id ]],
[[0..1 @site]] |Finding site| = [[ +id ]],
[[0..1 @occurrence]] |Occurrence| = [[ +id ]] }
- Valid Expression - History of Injury of head, neck and chest, and of malformation of head and neck
- |Finding with explicit context|:
{ |Finding context| = |Done|,
|Temporal context| = |In the past|,
|Subject relationship context| = |Subject of record|,
|Associated finding| = ( |Disease| :
{ |Associated morphology| = |Injury|, |Finding site| = |Head structure| }
{ |Associated morphology| = |Injury|, |Finding site| = |Neck structure| }
{ |Associated morphology| = |Injury|, |Finding site| = |Chest structure| } ) }
{ |Finding context| = |Done|,
|Temporal context| = |In the past|,
|Subject relationship context| = |Subject of record|,
|Associated finding| = ( |Disease| :
{ |Associated morphology| = |malformation|, |Finding site| = |Head structure| }
{ |Associated morphology| = |malformation|, |Finding site| = |Neck structure| }
|
| Introducing term searching to ECL | Linda Bird | Syntax term = [lexicalSearchType ":"] String Lexical Search Type - Wild Card Match (collation) - e.g.
- {{ term = wild:"*heart*“ }}
- {{ term = wild (sv):"*hjärta*“ }}
- ??? Perl Regex - e.g.
- {{ term = regex:".*heart.*” }}
- Question: Does the query suddenly become order dependent? Yes
- *** Word Prefix Any Order - e.g.
- {{ term = match:“hear att” }}
- Default (word prefix any order) - e.g.
- {{ term = "hear att" }}
- {{ term = "*heart*“ }}
Potential Examples - << 64572001 |Disease| {{ term = “*heart*”}}
- << 64572001 |Disease| {{ term = “*heart*”, languageCode = "en"}}
- << 64572001 |Disease| {{ term = “*heart*”, languageCode = "en"}} AND << 64572001 |Disease| {{ term = “*heart*”, languageCode = "sv"}}
- (<< 64572001 |Disease| {{ term = “*cardio*” }}) MINUS (<< 64572001 |Disease| {{ term != “*heart*” }})
- ?? << 64572001 |Disease| {{ term = “*cardio*” }} MINUS << 64572001 |Disease| {{ term != “*heart*” }}
Use Cases - Intentionally define a reference set for chronic disease. Starting point was ECL with modelling; This misses concepts modelled using the pattern you would expect. So important in building out that reference set.
- Authors quality assuring names of concepts
- Checking translations, retranslating. Queries for a concept that has one word in Swedish, another word in English
- AU use case would have at most 3 or 4 words in match
- Consistency of implementation in different terminology services
- Authoring use cases currently supported by description templates
- A set of the "*ectomy"s and "*itis"s
Questions - Do we include 'typeId' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, typeId = 900000000000013009 |Synonym| }}
- Do we include 'type' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, D.type = synonym }}
- Do we include 'languageCode' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, D.type = synonym, D.languageCode = “en” }}
- Do we include 'caseSignificanceId' - e.g. << 64572001 |Disease| {{ D.term = “*Heart*”, D.caseSignificanceId = 900000000000017005 |case sensitive|}}
- Do we include 'caseSignificance' - e.g. << 64572001 |Disease| {{ D.term = “*Heart*”, D.caseSignificance = sensitive }}
- Do we include 'language' and 'version' - e.g. << 64572001 |Disease| {{ term = “*heart*” }} VERSION = http://…, LANGUAGE = (999001881000000108|Gastro LRS|, |GB English|)
- Do we include syntactic sugar - e.g.
- << 64572001 |Disease| {{ preferredTerm = “*heart*”, languageRefSet = en-gb}}
- << 64572001 |Disease| {{ fullySpecifiedTerm = “*heart*”, languageRefSet=en-gb}}
- << 64572001 |Disease| {{ acceptableTerm = “*heart*”, languageRefSet = en-gb}}
- << 64572001 |Disease| {{ preferredTerm = “*heart*”}} FROM version = X, language = Y
- Do we use/require the "D" at the start of "term"?
- How does this relate to description templates? How does this relate to SNOSTORM implementation.
- Packaging - Do we (over time) extend ECL with all the new Query Language features, and define a set of example ECL profiles - e.g. "Basic ECL", "ECL with basic term searching", "ECL with filters".
|
Keywords for Term-based searching: - 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 = "fullySpecifiedName"
- D.type = "synonym"
- D.type = "textDefinition"
- D.acceptabilityId
- D.acceptabilityId = 900000000000549004 |acceptable|
- D.acceptabilityId = 900000000000548007 |preferred|
- D.acceptability
- D.acceptability = "acceptable"
- D.acceptability = "preferred"
Additional Syntactic Sugar - FSN
- FSN = "*heart"
- D.term = "*heart", D.type = "FSN"
- D.term = "*heart", D.typeId = 900000000000003001 |fully specified name|
- FSN = "*heart" LANGUAGE X
- D.term = "*heart", D.type = "FSN", D.acceptability = * LANGUAGE X
- D.term = "*heart", D.typeId = 900000000000003001 |fully specified name|, acceptabilityId = * LANGUAGE X
- synonym
- synonym = "*heart"
- D.term = "*heart", D.type = "synonym"
- D.term = "*heart", D.typeId = 900000000000013009 |synonym|
- synonym = "*heart" LANGUAGE X
- D.term = "*heart", D.type = "synonym", D.acceptability = * LANGUAGE X
- D.term = "*heart", D.typeId = 900000000000013009 |synonym|, (D.acceptabilityId = 900000000000549004 |acceptable| OR D.acceptabilityId = 900000000000548007 |preferred|) LANGUAGE X
- synonymOrFSN
- synonymOrFSN = "*heart"
- synonym = "*heart" OR FSN = "*heart"
- D.term = "*heart", (D.type = "synonym" OR D.type = "fullySpecifiedName")
- synonymOrFSN = "*heart" LANGUAGE X
- synonym = "*heart" OR FSN = "*heart" LANGUAGE X
- D.term = "*heart", (D.type = "synonym" OR D.type = "fullySpecifiedName"), D.acceptability = * LANGUAGE X
- textDefinition
- textDefinition = "*heart"
- D.term = "*heart", D.type = "definition"
- D.term = "*heart", D.typeId = 900000000000550004 |definition|
- textDefinition = "*heart" LANGUAGE X
- D.term = "*heart", D.type = "definition", D.acceptability = * LANGUAGE X
- D.term = "*heart", D.typeId = 900000000000550004 |definition|, D.acceptabilityId = * LANGUAGE X
- Unacceptable Terms
- (D.term = "*heart") MINUS (D.term = "*heart", D.acceptability = * LANGUAGE X)
|
2 Comments
Ed Cheetham
Following on from the discussion about order-independent regex searching being verbose, I've posted here a spreadsheet that I put together for one of our clinicians a couple of years ago to take advantage of the regex feature of the SI browser. It allows you to enter up to three different synonyms for up to three different tokens (in the green matrix) and generates a working (I think!) regex search expression, either in the blue cells if you only have one token, or in the yellow box for multiple tokens. The example (copied from the yellow F4 cell) allows a search of "(renal* OR kidney*) AND (failure* OR failed*) AND transplant*" - given time it returns 6 matches in the January 2019 international data. You have to remember to delete the ^ caret character.
Ed
Linda Bird
Thanks Ed!
Linda.