| | |
|---|
Welcome and apologies | @Former user (Deleted) |
|
Actions from last week | @Former user (Deleted) | |
Executing maps | @Former user (Deleted) | Proposed extension to ECL to support the execution of maps (focusing on the resolution of historical refsets) The specific use-case here comes initially from Jeremy and relates to being able to work with inactive concepts via the historical association maps. For example, given an ECL expression that identifies a set of concepts 'c' to be used for retrieving patient records, you probably also want to retrieve records for sameAs (c) and replacedWith (c) Example: (< 72704001 |Fracture| AND ^ 900000000000527005 |SAME AS association reference set|) . 900000000000533001 |Association target component| (900000000000527005 |SAME AS association reference set| . 900000000000533001 |Association target component| ): |Referenced component| = < |Fracture|
Michael's existing approach: mapsTo(|SAME AS|, < |Fracture|)
Or mappedTo(…)
mappedFrom(|SAME AS|, |inactive concept|)
mappedFrom(|REPLACED BY|, |inactive concept|)
Alternative suggestion: Use the substrate to include historical snapshots. E.g. Historical and current concepts that are fractures and have an associated morphology, but not historical morphologies ( < |Fracture of bone| {{ substrate >= http://snomed.info/sct/900000000000207008/version/20140131 }}) AND (* : |Associated morphology| = *)
Alternative use case - Substance (int) to substance (AMT) map (SNOMED-to-SNOMED)
|
Returning attributes | @michael lawley | Proposal from Michael: 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| |
Template Syntax | @Former user (Deleted) | New requirements 2 replacement slots must have the same/different or subsumed/not-subsumed values - for example, same morphology, finding sites not subsume each other (within a row of input data): [[ +id ]]: { 116676008 |Associated morphology| = [[ +id @morphology ]], 363698007 |finding site| = [[ +id @findingSite1
constraint ( != << $findingSite2) ]]},
{ 116676008 |Associated morphology| = [[ +id @morphology ]], 363698007 |finding site| = [[ +id @findingSite2
constraint (!= << $findingSite1) ]]} [[+id]]: [[1..*]]{ |Associated morphology| = [[ +id @morphology ]], |Finding site| = [[ +id @site constraint ($site[n] != <<$site[!n] ]]} Example - 208510002 |Multiple fracture of clavicle, scapula and humerus (disorder)|
Default value for slots - for example: Specifying the definition status of a slot - for example (proximal primitive modelling): Specifying the definition status of an expression - for example [[ +tok ]][[ +id ]]: { |Finding site| = [[+id]]} [[ +tok ("===" "<<<") ]][[ +id ]]: { |Finding site| = [[+id]]} [[ +tok (< |Definition status|) ]][[ +id ]]: { |Finding site| = [[+id]]}
Repeating role groups must have the same set of attributes (with respect to optional attributes) - for example (using #same or #allOrNone):
[[+id]]: [[1..* @group1]]
{ [[0..1 #same in group1]]|finding site| = [[+id]],
[[0..1 #same in group1]]|associated morphology| = [[+id]],
[[0..1]]|pathological process| = [[+id]]} [[+id]]: [[1..* @group1]]
{ [[1..1]]|Associated morphology| = [[ +id @morphology ]],
[[0..1 #allOrNone in group1]]|Finding site| = [[ +id @site]],
[[0..1 #allOrNone in gropu1]]|Occurrence| = [[ +id @occurrence ]]} Instance 1: Injury of head, neck and chest [[ |Disease| ]]:
[ @rolegroup[1] ] { |Associated morphology| = |Injury|, |Finding site| = |Head structure| }
[ @rolegroup[2] ] { |Associated morphology| = |Injury|, |Finding site| = |Neck structure| }
[ @rolegroup[3] ]{ |Associated morphology| = |Injury|, |Finding site| = |Chest structure| }
Instance 2: Congenital malformation of head and neck
[[ |Disease| ]]:
[ @rolegroup[1] ] { |Associated morphology| = |malformation|, |Finding site| = |Head structure|, |Occurrence| = |Gongenital| }
[ @rolegroup[2] ] { |Associated morphology| = |malformation|, |Finding site| = |Neck structure|, |Occurrence| = |Gongenital| }
|
URI Standard | @Former user (Deleted) | |
Query Language
- Summary from previous meetings
| @Former user (Deleted) | 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
|
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
|
Language preferences using multiple language reference sets LRSs that use the same Language tend to use 'Addition' - i.e. child LRS only includes additional acceptable terms, but can override the preferred term E.g. Regional LRS that adds local dialect to a National LRS E.g. Specialty-specific LRS E.g. Irish LRS that adds local preferences to the en-GB LRS
LRSs that define a translation to a different language tend to use 'Replacement' - i.e. child LRS replaces set of acceptable and preferred terms for any associated concept
|
Other topics | @Former user (Deleted) | |
Confirm next meeting date/time | @Former user (Deleted) | The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 6th February. |