Welcome and apologies | |
|
| URI Specification | | - Review use cases for computable language instance URI
- Review language instance URIs
|
| Proposed Language Features | | Other topics for discussion. For example: - ECL suggestions
- Transitive relationships and role chaining in ECL (to align with new enhanced DL axioms)
- Example 1:
- Direct relationship < 404684003 |Clinical finding|: << 246075003 |Causative agent| = << 58800005 |Streptococcus (organism)|
- Transitive relationship < 404684003 |Clinical finding|: << 246075003 |Causative agent|* = << 58800005 |Streptococcus (organism)|
- Example 2:
- Direct relationship < 71388002 ||: 363701004 |Direct substance| = 372687004 |Amoxicillin|
- Role chained relationship (via 738774007 |is modification of|) < 71388002 ||: 363701004 |Direct substance|* = 372687004 |Amoxicillin|
- 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, e, that identifies a set of concepts to be used for retrieving patient records, you probably also want to retrieve records for sameAs(e) and replacedWith(e)
- Example 1:
- ??? (< 72704001 |Fracture| AND ^ 900000000000527005 |SAME AS association reference set|) . 900000000000533001 |Association target component|
- Query language - Can we de-scope relationship filters?
|
Query Language
- Summary from previous meetings
| | 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.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)
|
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 | |
|
| Confirm next meeting date/time | | The next SLPG meeting will be held in 4 weeks at 20:00 UTC on Wednesday 12th September (to avoid the MAG meeting in 2 weeks). |
1 Comment
Ed Cheetham
With the talk yesterday of historical relationships (recognising the interplay between inactive identifiers and their active counterparts), I'm wondering about the expression representation (and thus the SCG implications) for ambiguous identifiers in situations where active substitutions have been made as part of (normalisation) preparations for analysis.
This may already be addressed in training materials, but put simply, is there an anticipated need for the SCG - when used to serialise the result of a historical substitution (and any subsequent normalisation of those substitute codes) - to include an 'OR' operator?
Say, for example, I encounter the (recently-inactivated) 193515006 | Exudative cyst of iris or anterior chamber (disorder) in a record. Tracing this into the active data (which I may wish to do for analysis purposes) I find it could now be:
82167006 | Exudative cyst of anterior chamber (disorder)
OR
53866004 | Exudative cyst of iris (disorder)
Now I may have access to description information that allows me to resolve this to a single identifier, but if I don't (and in many circumstances I won't) then I'm stuck with the disjunction 82167006 OR 53866004 (and whatever this becomes through normalisation) as my new 'expression', and potentially need to hold/communicate this in a single field/element/whatever.
The SCG's '+' operator handles the multiple concept references that can be generated by normalisation, but there's nothing to support disjunction generated by historical substitution.
As I say, apols if this is already covered somewhere. If so, please point me there, if not - thoughts?
Thanks
Ed