2021-07-21 Full MAG Meeting (Conf call)

Meeting Introduction

@Peter Williams

5

Start recording

Summary of previous meeting : 2021-04-19 Full MAG Meeting (Conf call)

MAG Membership update

Concrete Domains Update

@Peter Williams

@Yongsheng Gao

10

Member release now available with concrete values.

See deprecation plan for number concepts

US Edition upgrade

• "Operator" column did not make it into the final cut.  Was intended to future proof ( eg Drug contains > 50mg of X ) but classifier does not current support this.

• ECL spec makes distinction of decimals as having decimal points ie 50.0  but this is in contradiction to the requirement (mostly coming from Pharmacology) that we store and display whatever was originally input so 50mg should never be displayed as 50.0mg.  To be discussed in SNOMED Languages Project Group (SLPG).

ML Query on use case being about "display" and being about what appears in the description rather than process.   Question of precision.   Michael would not expect 50 to match 50.0 in ECL. 

Current approach takes numeric equivalence ie 50.0 = 50 but lexical distinction.

HS RDF community have long discussion about 50.0 and 50 being same/different - they've come down on the side of .   PH In programming languages these would be different datatypes.

Projects In Flight

@Peter Williams

@Rory Davidson

@Kai Kewley

15

This release adds new features for the Frequent Release Implementation (FRI) project to introduce Service Acceptance Criteria (SAC) visibility into projects and tasks, providing a baseline for later elaboration and role-based access to task and project promotion workflow controls. For this release the features are not fully activated, so do not affect the existing task and project authoring flow, but are presented to allow familiarity to be gained prior to full role-based access and workflows in subsequent Authoring Platform releases. 

Alignment with BFO

@stefan.schulz (Unlicensed)

@Former user (Deleted)

15

See update of article and recent discussion.  Most of the discussion needs to be done offline. Please contribute to article and discussion directly by editing the Google document. 

PH Determining a continuant has nothing to do with how long they last.   Think instead about volume and mass, even if they have a short existence.   Clinical finding is not a thing in the real world, it's the clinician's assertion. So has no mass and is therefore an occurrent.

Proposal: findings should be interpreted as occurrents as an alignment to a top level ontology. HS "description of occurrents"

Next Steps - small group to complete document, towards the end of the year with a view to progressing towards publication.

Historic ECL

@Brandon Ulrich (Unlicensed)

@Daniel Karlsson (Unlicensed)

@michael lawley

@Former user (Deleted)

@Kin Wah Fung (Unlicensed)

15

Historical Analytics

Also requested by EAG and Implementation Support team.

Next steps: solicit current implementations (@Jeremy Rogers (Unlicensed)(augmented transitive closure table), BPAC (reverse use of historical associations), others?) with a view to internal solution.

From @Former user (Deleted):  I agree that the next step is to (a) implement the different approaches to show how each of these would work in practice (b) implement an approach that is 'recommended as best practice' (for a common, specified use case), and (c) document the best practice approach, and variations that can be used in different scenarios. I don't have too much to add, other than I assume that the 'best practice' approach will look something like:

•  

  1. Run the query against the latest edition

  2. Follow the historical associations in the reverse direction, to augment the query expansion with inactive concepts connected to the active concepts in the expansion (Question: Which types of historical associations can be used for this process?)

  3. To find inactive concepts that do not have historical associations, augment the latest edition by re-activating the relationships that form the "last known pre-inactivation state" of each inactive concept without (usable) historical associations, and run the query on the augmented substrate.

ML - different use cases warrant different implementations.   Post coordination also needs to be considered.   Still need to consider gaps in ECL (eg automatic hist assoc, inactive rels, other maps to follow).   A prime candidate for discussion by Languages Group!  

KF - Problem tackled in many times and places.  Could existing implementations be shared?  Health data analytics 

JR - the deployable "Augmented Transitive Closure Table" approach aka "Query Table" is available from our TRUD portal. Alternatively, you can experiment with a pre-built working proof-of-concept implementation and some dummy EPR data using the NHS Data Migration Workbench (for which MS Access is required). Page 12 of the bundled Installation Instructions details how to locally autogenerate Dummy EPR data and some example queries. Pages 39 onward of the User Guide give an overview of the UI for firing the autogenerated example Queries at the autogenerated Dummy EPR data. Both the queries and the data deliberately include inactive codes that expose the problem, and demonstrate how a Query Table solution can mitigate it. However, as Michael points out, this solution doesn't obviously extend to the scenario where either the query specification itself and/or the data also include postcoordinated expressions involving inactive components as part of those expressions. Its likely that the solution to that more general problem may require augmentation of the classifier logic itself so that it applies something similar to the Substitutions Table (also found within the deployable TRUD bundle) in order to expand its identifier equivalences. Incorporating the semantics of SAME_AS into a DL classifier, for example, ought to be relatively trivial. The contingent nature of POSSIBLY_EQUIAVLENT_TO however is rather more challenging!

Reasons for lack of explicit value for "Not Acceptable" in Language reference sets

@Peter Williams

@John Snyder (Unlicensed)

5

Arguments For & Against explicit Language Refset Not Acceptable values

SS - Austrian German have terms that have completely different meaning in German German.

ML - an explicit "unacceptable" value could be used to draw particular attention to eg dangerous cases.   DK - Danger in that case of such a description exisitng at all eg reading the description file and failing to also take in the langreset file.

AOB

0

Topics for October.

SNOMED CT representation of annotation properties and values

@Yongsheng Gao

30

Development will be 2022 at least.

SNOMED CT representation of annotation properties and values .pptx

Proposal for a new extended cS refset to capture a range of annotation properties with the concept field taking an attribute SCTID.

GR: Welcome and not before time. Original semantics captured mostly in the refset name.   Suggests we go further to address a number of issues eg flags for medicinal products.  Very much agree with the need to have enhanced annotation features, and provide alternatives to current refsets where semantics are lost in the refset name, like association refsets, and attribute value refsets. Terrible bad decisions in the past that really complicated maintenance and usability

RC: I like the approach, offers many possibilities and doesn't seem to break anything. The challenge will be maintenance, ensuring that what goes into annotation attributes are indeed annotation attributes, and that the types are well-understood and agreed upon.

DK: Agree with the direction, guidance for how to use annotations need to be developed for several specific areas, can be done over time, so allowing annotations seems obvious

BU: Current annotation refsets - semantics are not clear (says GR)

ML: Main concern is potential for becoming dumping ground (lack of reuse of existing mechanisms eg non-defining relationships).   Overlap with metadata eg for copyright.  Concern about 'releasable' flag not necessary to expose tooling data.

KN: Considering what this means on the authoring side with the grouping of similar content and commentary/references retrieval of info. Does this replace or complement it? If it replaces it then will the grouping mechanism be for annotation access?

KWF: In favour.

Further feedback:  Please add comments to SNOMED CT Annotations  

BFO (cf. paper draft)

@stefan.schulz (Unlicensed)

@Former user (Deleted)

20

Sub group members from July:  @Former user (Deleted), @stefan.schulz (Unlicensed) , @Daniel Karlsson (Unlicensed) , @michael lawley , @Yongsheng Gao

Suggestion that Findings Hierarchy could be re-interpreted as "clinical process or state" to make it compatible.  Morphologic abnormalities re-interpreted as continuants.

Further comments to Google doc:  https://docs.google.com/document/d/1HcBj5bVIg8lB_uyORZU9A_FWKFsw0sxmB6Xg4UYKygk/edit

Next steps:   Conf call for paper authors, then share with BFO community, publication followed by any changes to SNOMED CT

DK: concern around the solution of putting a process wrapper around current SNOMED.  There are still processes with dispositions subsuming processes with occurrents

@stefan.schulz (Unlicensed): Example? Wouldn't this be a bigger problem without the mapper?

DOODLE for sub group call: https://doodle.com/poll/5qkffyswsg5gnmmc?utm_source=poll&utm_medium=link 

AOB / Items for April Business Meeting

@Peter Williams

5

Concept model for a condition without condition (@Jim Case and @Yongsheng Gao)

------------------------------------------

Role Grouping, Post Coordination (impact of DL changes),   further ECL filtering.

Concept model for conditions caused by substances or products - to be circulated before January @Yongsheng Gao (incl. other AGs and Member Forum)

Yong's further items to discuss (quick chat if time allow, or create page to continue)

• Qualifying Attributes - we've called them that, but they're being used as defining attributes

Metadata & Annotations

@Guillermo Reynoso

@Ronald Cornet (Unlicensed)

@Karim Nashar

@stefan.schulz (Unlicensed)

Metadata (including specifying aliases for langrefsets and some overload with Annotations in OWL): Capture, Interrogation and Publish

Refset Metadata

This topic comes from SNOMED on FHIR

Also TRAG item: Reference set metadata See Agenda item 17 and consider in wider context of machine readable metadata item 11

In fact, this metadata may be more widely useful when applied to a module.

Suggestion that we could use the FHIR standard which already defines metadata. DM suggests a JSON format which would be extensible unlike a column based solution.

Where are we at with this? Checking with @Andrew Atkinson ...

Relationship Grouping

Google Document, editable

Presentation

OWL file with RGs interpreted as includes

Role group issues

Revisit "Negative Delta"

@Peter Williams

At request of EAG - need to revoke/delete a published component. Comments added to Negative Delta.

See TRAG agenda item #

Notify @Andrew Atkinson

Use cases:

Two groups: where audit is desired (eg technical issue) and where it is not (IP, un-processable characters)

1. Removing IP - suggestion to blank out particular field ("~") while leaving row.

2. Conflicting Rows ie no clear state (technical issue, not content) - suggestion to subsequent delta clarifying row.

3. Clinically dangerous historical error in before-previous release.

Review the representation for product role

2019-April-EAG-Product-Roles.pdf

Discussion of options eg move role concepts into a separate module.

General requirement for flexible composition.