2021-02-03 Full MAG Meeting (Conf call)

Meeting Introduction

@Peter Williams

5

Start recording

Summary of previous meeting : 2020-10-05 & 08 Full MAG Meeting (Conf call)

The cause of conditions - substance or product?

@Yongsheng Gao

40

See https://docs.google.com/document/d/1qphuHLBcQxmB8FsysZA_-F91_-guJfT8LKimbYaFVuU/edit#heading=h.192khe5lt5sf

Consultation on conditions caused by substance or product.pptx

Feedback received.

KWF - Pleased with feedback, agrees that caused by product should be used sparingly (eg multi ingredient product where actually problem substance cannot be determined).

DK - Similar question came up with FHIR Allergy Resources.   Current valueset binding allows for both substances and products and findings! (RH this was requested by implementers)

GR - Multi-ingred Products can lead to incorrect inferences but better that than missing something important.  Early days for drugs extensions.  Pharmacovigilance will be run on Real Products rather than CDs.  Implementations may not even be SNOMED CT-centric.  Supports proposal. 

FA - Using substances would not allow for use of Roles which are a Product attribute.

RH - Clinicians will want to record what they know which will be that they prescribed a Product.  Decision support software would then determine substance.

Concrete Domains Update

@Peter Williams

@Yongsheng Gao

35

Concrete Domains

SNOMED International Proposal for Representing Concrete Domains in RF2

Conversion Tool 

Concrete Domain Decimal Places and Rounding

Last Minute Addition @Yongsheng Gao: "Booleans aren't available in EL Profile"  affecting:   4.2.6 Concrete Value File Specification  and SNOMED International Proposal for Representing Concrete Domains in RF2 (section Type Indicator Symbols).

Demo - Browser https://uat-concrete-browser.ihtsdotools.org/

Date for technical preview TBC (next couple of weeks)

GR Suggests we document "best practice" for converting boolean values in OWL to SNOMED eg < 1119301001 |Boolean value (qualifier value)| (preferred to using concept-as-number 1s and 0s).    Expecting very significant impact for extension creators therefore keen to have early availability.   Expecting pushback from implementers who have yet to realise the implications of these changes.  Roadmap must be clear and delay will hurt early implementers.  Go/NoGo decision (Late April?).    Possibility of a compatibility package or round-trip conversion routine?  GR would prefer support be given to struggling implementers rather than delaying SI release implementations.   A compromise will be needed to avoid blockages.

ML suggested we could add an OWL axiom indicating that 31874001|True| and 64100000|False| are disjoint?

RC Any decision on multipliers eg 1000mg → 1g including splitting up "milli" so that it includes that 1000 multiplier?  YG: Medicinal Product model states rules about normalizing strengths so they remain in a predictable range.  GR:  National extensions may choose to implement additional axioms.    Cross-map to UCUM also discussed in the past, but no clear use case determined to date.  ML for this to be done in the classifier, we'd need a second concrete domain to bind numbers and units.  DM tried this using GCIs (didn't need very many and they were generated) alternatively (eg for UCUM) preprocessing required before classification.  DK Source representation should be consistent.   Conversions not always possible - statistical at best,

GR - Argentina has drug extension since 2 years, 20K RCDs.   Lack of reaction due to not using RF2 so much outside of Snowstorm so impact hopefully mitigated there.  However, JSON changes in Snowstorm API will affect their implementations more. (see https://github.com/IHTSDO/snowstorm/blob/master/CHANGELOG.md#601-release---jan-2021---support-for-concrete-domains-technical-preview)  KK: Implementers could provide a 2nd instance/endpoint (with generated old style content) for backwards compatibility.   ML: Confident for changes to Ontoserver.

Historic ECL

@Brandon Ulrich (Unlicensed)

@Daniel Karlsson (Unlicensed)

@michael lawley

@Former user (Deleted)

@Kin Wah Fung (Unlicensed)

10

Historical Analytics

KWH: Since this has been done in the UK, how successful was it and can it be shared?  Tagging @Jeremy Rogers (Unlicensed) for his interest.

AOB

0

Items for delivery at April Conference.  

Annotations - Next Time!   GR: Netherlands looking to add HTML content.  ML: HTML introduces safe tag, javascript and css complexities

Please contribute / continue discussion at Annotations for concepts or descriptions

SNOMED CT representation of annotation properties and values

@Yongsheng Gao

30

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.