| | |
---|
Welcome and agenda | All |
|
ECL 2.2 Publication | @Kai Kewley | ECL 2.2 has been published |
LOINC related things | All | Latest: Terminology Management Group on Saturday (pre-expo) - SNOMED International agreed to publish a URI to access alternate identifier maps via the FHIR API. Update on our suggestion "that a Map should be included in the LOINC extension, in addition to alt identifiers. This will enable terminology servers to translate back and forth between LOINC and SNOMED CT codes in the existing standard way." Previously we added the following warning in the ECL guide in the alternate identifiers section: |
Meds ECL Requirement | @michael lawley | Requirement to select a substance or a modification of that substance .... use case: during authoring to prompt the user with all the active ingredient options. Clinician chooses a drug and wants to refine the selection using modification-of substances. Although modification-of is a transitive property in OWL, and used during subsumption, the NNF rules state that X relationships are redundant and must not be part of the output. Options: ECL: << 372687004 |Amoxicillin (substance)| OR ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = << 372687004 |Amoxicillin (substance)| ) OR ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = << 372687004 |Amoxicillin (substance)| ) ) OR ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = ( << 105590001 |Substance (substance)| : << 738774007 |Is modification of (attribute)| = << 372687004 |Amoxicillin (substance)| ) ) ) ) Pros: Already works, if you know the maximum number of transitive hops Cons: It's not pretty. It may work for modification-of but may not work for longer transitive chains like part-of (body structures)
NNF change: Keep the modification-of relationships using a new characteristic type to support querying.
ECL Engine and language change: Build a transitive closure for each transitive property, in the same way that we do for the is-a relationship. We would also need special ECL syntax for this.
Pros: No content change. No classification change. Cons: Slightly more work in ECL engines. Example: @Kai Kewley pseudo-code needed
Content change: Create a grouper substance to include that substance and all single and multi-hop the modification substances. Pros: Would work without other changes. This technique has precedent in the body structure hierarchy. Cons: Approx. three times the number of substance concepts. May be hard for implementers who want a clean list. Because of the high number (around 2K) of substances with a modification relationship these groups would need to be generated.
|
Expression Repository Maintenance | All | Potential issues when upgrading the substrate of an expression repository Inactive concepts within the expression (focus concept, or attribute name or value) Concepts changing hierarchies (semantic tag) - e.g. procedure → observation Changes to concept model Will need to classify again to infer different ancestors and attributes MC: This has a lot of overlap with ECL maintenance
General approaches for identifying issues: FHIR interface could validate the expression again to identify inactive concepts Expand existing value sets to see if there is a radical change in size Content unit tests - needs
Strategies to avoid these issues: Types of template based authoring / transformation Use the close to user form, level 1 transformations Create expressions using a proximal parent with minimal modeling, lean on Level 1 transformations (see guide) Expression repository should retransform existing close to user form expressions to classifiable expressions
What techniques from precoordinated authoring could be reused? How to international authors update PPP concepts, what automations? Should expression repository be versioned before being upgraded, or should the repository be recreated against the new substrate.
Strategies to fix content issues:
|
|
|
|
ECL EOF marker | Kai | Suggestion from Martin Gall (EMIS Health) https://github.com/IHTSDO/snomed-expression-constraint-language/issues/6 Answer - all known TS implementations call Antlr in a way that doesn't require EOF. |
ECL Results - TS consistency | @Jeremy Rogers | Testing consistency between Snowray (Snow Owl), Ontoserver, Snowstorm. Also using custom made NHS Subset maintenance tool, would like to migrate to a standardised solution. Questions: Should inactive concepts be routinely suppressed from all results? Answer: Inactive concepts should not be included when using hierarchy constraints, because they are not part of the hierarchy. They should be included when using wildcard. The default substrate includes inactive. Same in FHIR. All agree. Action: Check the spec makes this clear. "Default substrate". Known tooling issues: Snowstorm is not behaving well. e.g. ^ xxx AND YYY (where YYY is inactive). Check both native and FHIR API.
Should inactive concepts be returned as active members of a simple refset? Are text definitions and FSNs routinely in scope of any description filters? Do description filters run by default over inactive descriptions? Inactive are excluded by default in the spec, however there is no way to search active and inactive at once Action: Update ECL Spec to allow searching over active and inactive (apply everywhere, concept, description, members)
Snow Owl searches active and inactive descriptions by default
Is a “pending move (concept)” description active or inactive? Are the match and wild description filters case sensitive or not (or, in the case of Ontoserver, do they even work at all?) Group recommends case insensitive matching for "match" Action: Update the ECL guide with this recommendation. Group does not agree about "wild" case sensitivity. Action: Consider adding ECL regex filter.
There are also some interesting edge case differences in the ability of each server to process ECL match description filters if they contain various symbol characters, such as *^% and so on. Action: Discuss updating the ECL spec to add escape character for matching double quotes. MC: Implementation Note - ECL filters commonly include double quotes - when including these in FHIR ValueSet requests make sure they are escaped. Action: Add to ECL Guide and any Snomed FHIR IG. Other characters are perhaps an edge case. More testing needed against know TS.
ML: Some observations: it is interesting to see the number of examples that are querying against terms – the results are not surprising since 1., this is a relatively new part of the spec, and 2., it steps outside the original conception of ECL as a query language that only used defining aspects of concepts as supported by the Concept and Relationship tables. |
Expanding the use of the ECL standard | All | Discussion: How to make it easier to add an ECL capability to more tooling? ECL Lite - MVP Scope: *, <, <<, >, >>, <!, !>, ^, AND, OR, MINUS, (), {{ +HISTORY-(MIN,MOD,MAX) }} Maybe? {{ C active }}
|
Other Topics | All | |
The items below are currently on hold |
|
|
|