| | | | |
---|
1 | Welcome, introductions and apologies | @Former user (Deleted) | SLPG meetings will be recorded and recordings will be accessible to SLPG members | |
2 | Agenda review | @Former user (Deleted) | Review proposed agenda for today's meeting Introducing the SLPG Confluence Space Discuss recent feedback about the Expression Constraint Language Review template syntax discussion Scope and purpose of syntax Simplifications to Finding context example Cardinality in templates Populating a template from a data structure
| |
3 | SPLG Confluence Space | @Former user (Deleted) | Make sure everyone has access to Confluence and the SPLG space | |
4 | SNOMED CT Expression Constraint Language | @Former user (Deleted) | Discuss recent feedback about the ECL Immediate children/parents FHIR Community have use case for these operators (user interface display) Are these just 'syntactic sugar' for What syntax would we use - for example:
Comments If we introduce comments into the ECL, should we also be introducing them into CG? Should comments be part of the normative (brief) syntax included in interoperable sharing of ECs? Or should comments be included in the non-normative (full) syntax? If we introduce comments, what syntax should we use? For example:
OUTCOMES The group agreed to add new operators to the ECL specification to support the FHIR community's use case for immediate children/parents. The preferred syntax was "<!" and ">!" . The group decided that comments should be added to the the brief syntax of the ECL using the "/*... */" syntax.
| |
5 | SNOMED CT Template Syntax | @Former user (Deleted) | Review discussion on optionality and populating attribute groups: Scope and purpose of syntax Extract/disentangle SNOMED CT (and SNOMED CT-relevant) content from a FHIR Condition resource (i) into a free-standing and ‘recognisable’ SNOMED CT expression, whilst (ii) ‘leaving nothing behind’ which may be of relevance to further processing Specify mappings from FHIR value sets (e.g. Condition.clinicalStatus) into SNOMED CT Transform the extracted expression into an ‘optimally-processable’ SNOMED CT expression (in particular grouping body site values with morphology) Specify constraints on what the extracted/disentangled SNOMED CT expression could or couldn’t contain (by e.g. cardinality instructions).
NOTE - The rest of this discussion will be carried over until the next meeting. (From a(ii) and b above) Simplify |finding context| refinement to either: 408729009 |finding context| = [[ @findingContext ]] 408729009 |finding context| = [[ findingContextTable ($clinicalStatus, $verificationStatus) ]]
(From d above) How to specify cardinality in terminology binding when restricting valid values in an information model data element: 62014003 |Adverse reaction to drug (disorder)|: 246075003 |Causative agent| = [[ [0..1] ^ 111115 | AMP reference set | ]] 62014003 |Adverse reaction to drug (disorder)|: !! [0..1] !! 246075003 |Causative agent| = [[ ^ 111115 | AMP reference set | ]]
(From c above) To indicate how the following data structure can be used to populate a template: Data Structure A Possible template syntax examples: [[ $code ]]: { 363698007 |finding site| = [[ $BodySite ]], 116676008 |associated morphology| = [[ $Morphology ]] } [[ $code ]]: { 363698007 |finding site| = [[ $MorphologyBS.BodySite ]], 116676008 |associated morphology| = [[ $MorphologyBS.Morphology ]] } [[ $code ]]: !! For each M = $MorphologyBS !! { 363698007 |finding site| = [[ M.BodySite ]], 116676008 |associated morphology| = [[ M.Morphology ]] }
Data Structure B Condition Code: CodeableConcept [0..1] BodySite: CodeableConcept [0..*] Morphology: CodeableConcept [0..1]
Possible template syntax examples: Other examples discussed by email (double scope):
| |
6 | Confirm next meeting date/time | @Former user (Deleted)
| Confirm date and time of next SLPG meeting - Wednesday 27th April | |