| | |
|---|
Welcome and agenda | All | |
ECL 2.2
Implementation Progress | @Kai Kewley | |
ECL 2.3 development Behaviour refinement for concrete string matching | @michael lawley | Proposal: Simplify concrete string matching. Use exact string match rather than prefix matching. Justification: The specification is a little vague in this area. The project group agreed that exact string matching seems most appropriate for concrete strings. The known terminology servers have already implemented exact string matching. Review change: |
ECL 2.3 development Ensuring consistency | All | Updates following Jeremy Roger's Terminology Terver ECL consistency analysis the following changes were recommended by the group: |
ECL Lite - Expanding the use of the ECL standard | All | Previous discussion: How to make it easier to add an ECL capability to more tooling?
"ECL Lite" is a simpler version of Expression Constraint Language including only the most useful features. ECL Lite will be a true subset of ECL so will be forward compatible. Feedback from previous meeting: Concrete string matching simplification (resolved above)
Not including description-filters limits the ability to define a set of concepts by language and dialect Add "Included In ECL Lite" Labels throughout the examples section - Use positive labels rather than exclusions Appendix - make explicit that ECL Lite syntax must work with servers with full - intention is true subset.
Other draft specification updates:
ECL Lite - MVP Scope: *, <, <<, >, >>, <!, !>, :, ^, AND, OR, MINUS, (), {{ +HISTORY-(MIN,MOD,MAX) }}, <!!, !!>, {{ C active }} Dot Not included: other filters cardinality groups
Declare profile using block/set of language capabilities Survey capabilities in existing implementations - any existing capability groups? There are parallels in ECL builder and education scopes
|
ECL Capability statement in FHIR | | Chat with @Peter Williams |
ECL Test Harness | | @Kai Kewley @Márk Czotter (Unlicensed) Next steps: |
FHIR TX - Searching with a specific dialect | | @Kai Kewley Try this in Snowstorm: When expanding a ValueSet with text filtering it is recommended to use the "Content-Language" header, to constrain the language and dialect of matched terms, in addition to informing the selection of display terms. This behaviour is owned by HL7. |
ECL Lite naming | | Not everyone happy with the name. Alternatives: ECL Core ECL Essential ECL Focus ECL Base ECL Basic ECL-- My First ECL
|
Substrate discussion | | Add appendix to describe the potential differences between terminology servers given what content is loaded/filtered out. |
ECL Enhancement Request: Set of reference sets containing a concept | @michael lawley | Enhancement for ECL 2.3 See comment here: Re: Discussions (2) Use cases: Syntax options: ^[refsetId] * {{ M referencedComponentId = 404684003 }} Syntax sugar: ^? 404684003
^[refsetId] < 123000 {{ M referencedComponentId = 404684003 }} Syntax sugar: ^? 404684003 AND < 123000
^[refsetId] * {{ M referencedComponentId = << 404684003 }} Syntax sugar: ^? << 404684003
Agreed. @Kai Kewley draft ECL guide changes for review next time. @404684003 ? 404684003 ^? 404684003 ^R 404684003
|
MRCM on FHIR | All | There is a growing desire to enable access to the SNOMED CT Machine Readable Concept Model via FHIR Terminology Servers. Use cases: How could this work? Current experiment: Other options was considered but rejected because of demand of TS implementation complexity: 1. Focus concept(s) -> MRCM Domain → set of domain - attributes 2. Attribute → Search within attribute range New implicit URIs? Consider supporting a reverse lookup - given a focus concept, which attributes can this be used within.
|
2.3 ECL Enhancement | @michael lawley | I want to fetch the set of attribute names used by a concept or set of concepts. Use case: Syntax options: 12334000 . ? 12334000 = R? 12334000 : ? 12334000 [ type ] 12334000.type 12334000 ...
|
ECL History Supplements with no association | @Anne Randorff Højen | Potential issue: Concepts made inactive with inactivation reason "Non conformance to editorial policy" currently have no historical association. Use Cases Should ECL be able to retrieve these concepts Options: Requested discussion with MAG and Editorial Group |
ECL Maintenance Recommendations | All | We plan to add a "Maintenance Recommendations" page to the ECL guide. Suggested sections: What does best practice ECL look like - what are the benefits ECL comments to record intent Existing tooling and features
@Jeremy Rogers (Unlicensed) has drafted some content on this topic. Group have reviewed the word document @Kai Kewley to Migrate to ECL Guide Appendix for final review. |
ECL Results - TS consistency | @Jeremy Rogers (Unlicensed) | 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) - done
Snow Owl searches active and inactive descriptions by default - needs to be realigned?
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. |
Postcoordination Guide + Reference Implementation Feedback | @Alejandro Lopez Osornio | Very little feedback received so far. An education module could be a way to expose more people to the caveats and best practises. |
Expression Repository Maintenance | All | - Aim to round off the guidance - make expression repositories feasible - An expression repository uses a specific edition and version of SNOMED CT - how can expressions be migrated to a new version? Use cases of expressions: Classifying expressions to discover closest existing precoordinated concept - no requirement for maintenance because expression not recorded in patient record Expression is recorded in patient record - need the ability to find relevant patients. This may not work well over time as SNOMED changes.
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: Capture user input (close to user form or template slot inputs) so that templates or transformations can be reapplied. Transform input again against the new substrate: 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
@Kai Kewley What techniques from precoordinated authoring could be reused? How do 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:
|