Template Syntax | @Former user (Deleted) | 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)
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 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]
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
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
Definition status of a templated expression 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.
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 | @Former user (Deleted) | Syntax term = [lexicalSearchType ":"] String Lexical Search Type Wild Card Match (collation) - e.g. ??? Perl Regex - e.g. *** Word Prefix Any Order - e.g. 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.acceptabilityId D.acceptability
Additional Syntactic Sugar FSN synonym synonymOrFSN textDefinition Unacceptable Terms
|
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