SNOMED CT Editorial Advisory Group

Page tree


Date: 2019-10-24

09:00-17:00 MYT (Malaysia time)

01:00-09:00 2019-10-28 UTC

18:00 2019-10-27 to 02:00 2019-10-28 PDT

Zoom Meeting Details:

Topic: SNOMED CT Editorial Advisory Group Face-to-face Meeting

Time: Oct 27, 2019 06:00 PM Pacific Time (US and Canada)

Join from PC, Mac, Linux, iOS or Android:
https://snomed.zoom.us/j/345971258

Meeting ID: 345 971 258

International numbers available: https://zoom.us/u/aNKqXbcBe



Attendees

Chair:

AG Members

AG Subgroup chairs






Observers:

Peter G. Williams

Kerli Linna

Monica Harry

Toni Morrison

Brian Carlsen

Patrick Granvold

James R. Campbell

Yongsheng Gao

Kin-Wah Fung

Cathy Richardson

Ian Spiers

Maria Braithwaite

Rob Hausam

Olivier Bodenreider

Geraldine Wade

Vicky Fung

Ines Otegui

Corey Smith


Apologies

Keith Campbell

Meeting Files

Meeting recording

The folder containing the meeting recordings is located here.

Edited transcripts are located here


Discussion items

ItemDescriptionTimeOwnerNotes and DiscussionAction

April 8, 2019

1

Call to order and role call

Notice of recording

Conflicts of Interest

0900-0905 h

Jim Case



2Agenda review and approval0905-0910 hJim Case
  • 2019-10 Agenda approved
3SNOMED CT alignment with upper level ontologies0910-1030 hJim Case

Following a panel discussion at the ICBO conference in Buffalo Aug 1-2, an agreement in principle for SNOMED to collaborate with the OBO community was reached. Much of the discussion revolved around the current SNOMED CT representation of diseases as subtypes of clinical findings.

There is a clear, mutually exclusive separation in BFO and other disease ontologies based on BFO between "diseases", which are specifically dependent continuents and clinical observations (i.e. findings), which are considered occurrents. The challenges in implementing this notion in SNOMED is explained in:

 https://www.academia.edu/26897896/Scalable_representations_of_diseases_in_biomedical_ontologies.

One differentiating feature discussed in April 2019 for what we call Clinical findings is the notion of temporality, i.e. a findings made at a point in time (an occurrence) whereas a disease is persistent. This is similar to the notions in BFO, but they (and all other disease ontologies) refer to diseases as dispositions (i.e. a realizable entity that is manifested as some abnormal process or structure. For terminologies like SNOMED that do not seek to define diseases, but to identify when a realization of the disease disposition occurs in a patient, this logical representation breaks down.

At the ICBO conference, a paper was presented in which an attempt was made to "BFOize" ICD-10. It was clear to the authors of that paper of the conundrum we face, i.e. that the use of the terms in ICD-10 as dispositions was not appropriate because they had been realized and so they modeled their ICD-10 ontology as processes (i.e. occurrents). This was criticized by a number of the ontologists, but no practical solution to the need for representation of realized dispositions in clinical recording were proposed.

A draft document is being developed by members of the MAG as a response to the issues surrounding the lack of alignment between SNOMED and BFO: 

https://docs.google.com/document/d/1HcBj5bVIg8lB_uyORZU9A_FWKFsw0sxmB6Xg4UYKygk/edit


Additional reference describing an approach to alignment with OGMS: Attached


OBO reference: https://bioportal.bioontology.org/ontologies/SCTO

Proposal:

In light of our desire to resolve the findings/disorders issue, to attempt to align as closely as possible with top level ontologies. One area where this would be of great use is the move by SNOMED to improve coverage of genomics. This would be greatly enhanced by an ability to integrate with the genome ontology.

Discussion:

Fundamental differences - OBO ontologies constructed top-down, whereas SNOMED is a terminology that is retrofitted to ontological structures.
Separating clinical findings and diseases within SNOMED will probably not resolve the issues that we have. Resistance to changing the underlying structure of SNOMED will result in considerable pushback.
What are the minimal changes that we can make to better align SNOMED CT with BFO? In the end we must keep it useable for our community. The main question is to differentiate clinical conditions from the realizations of those conditions.
How much of the GO is actually in scope for alignment with SNOMED?
If we want to leverage other terminologies, we need ways to reference external terminologies and to allow full usage, there must be an underlying common model.
Potential exercise is to do an analysis as to how BFO and SNOMED are different. From that, make a judgement on which differences can be reconciled. Can we limited the set of BFO properties that we need to align with external ontologies that are of interest?
There are more fundamental issues with findings/disorders that may not benefit from attempts to align with BFO. Need to focus on useability for members above all else. The focus should be interoperability with other ontologies in the research community over strict alignment with BFO for the benefit of users.
Efforts to collaboration with GO might be the best pragmatic solution. ANother ontology to look at would be the MONDO ontology. It would be of interest to see how MONDO models their diseases related to BFO.
How do we align the clinical use of terminology from the more strict research use of terminology in OBO based ontologies?
Research communities do not use clinical terminologies such as SNOMED due to licensing issues. This is why a number of them were initially created.
Bottom line is that a pragmatic approach to any sort of cooperation with OBO ontologies is the most beneficial way forward. SNOMED does not support the new genetic approach to defining diseases and we need to investigate whether we can represent both the classic view od disease and the newer genomics view.

Decision:

Potential actions:

Look at MONDO and HPO (and other clinical ontologies, such as OGMS) with regards to the commitment they have towards alignment with BFO.

Perform an analysis on the RO to see how they differ from SNOMED relations.

Identify the subset of GO that might be of interest to support genomics within SNOMED CT.



Break1030-1100 h


4Clinical content "Sources of truth"1100-1115 h

Bruce Goldberg

Jeff Pierson

  • Need to revisit the policy on adding text definitions from other sources
    • Do we need to reference them if we paraphrase?
  • Combined definitions from multiple sources may be required to fulfill the needs of SNOMED
  • SNOMED definitions are not normative, but used to define the meaning of a concept as represented in SNOMED CT.

Proposal:

Discussion:

Decisions:

5ECE Update1115-1200 hBruce Goldberg
  • Injuries - finalize model
  • Fractures - finalize models for traumatic and nontraumatic injuries
  • Use of multiple due to/causative agent relationships to represent a causal chain
  • Revisit model for complications
    • Achieving consistency of modeling with current definition of a complication is proving difficult

Proposal:

Approve recommendations from ECE

Discussion:

Decisions:


6Quality improvement issues1200-1215Guillermo Reynoso

Are these issues being addressed by the QI project?:

  • How to decreased the number of intermediate primitives?
  • How to increase the number of defined concepts in certain areas (findings/disorders)?
  • How to "normalize" the modeling pattern used in top level hierarchies (e.g. discuss whether to remodel asserted definitions to a canonical form using proximal primitives?
  • Discuss whether to turn some frequent units of meaning from primitive classes to defined grouper classes to facilitate grouping patterns.

Proposal:

Discussion:

Decisions:


6SNOMED CT Clinical core update1215-1230Jim Case

During the last discussion of this topic, a number of issues related to criteria for inclusion and exclusion were identified:

  • Need to specifically define what is meant by "clinically-oriented". Focus should relate directly to the "life phase" of the patient or procedures that address the "life-phase" of the patient.
  • How much of the foundation should be actively maintained as part of the clinical core?
  • Is the potential membership of the "problem list" a guiding principle for inclusion in the clinical core?
  • Should the focus primarily be on those concepts that can be sufficiently defined?

Proposal:

Discussion:

Decisions:



Lunch1230-1330 h


7Observables working group issues1330-1500 hDaniel Karlsson

Observables vs. Evaluation procedures: how to progress the shift.

Proposal:

Discussion:

Decisions:

When is a rate a rate and when is it a quantity. E.g. intake of X per day vs. excretion.

Proposal:

Discussion:

Decisions:



Break1500-1530 h


8Concept inactivation work group update1530-1540 h

Paul Amos

Jeff Pierson


This working group arose from an action at the last face to face meeting to address perceived inconsistencies in the allocation of inactivation values applied to inactivated concepts.

The group have drafted a set of potential use cases which we would like the EAG to review.

Work has begun on defining the current inactivation values and a template for the scenarios has been drafted.

Finally, Jeremy Rogers has done an initial analysis of the frequency of use of existing inactivation values.

Discussion:

Decisions:

9Use of hypernyms as descriptions1540-1630 hJeremy Rogers

Concern has been expressed about inactivation and replacement terms that from their modeling indicate that they are hypernyms to the replacement concept. The example given was the inactivation of 398042001|Accidental dural puncture (disorder)| as MAY BE 781129002|Accidental puncture of dura during anesthesia (disorder) | due to its positioning under 33211000|Complication of anesthesia (disorder)|, but without addition of the existing description "Accidental dural puncture".

Editorial guidelines from 2010 provided for hypernyms as long as they were noted in the language refset as "near synonymous (depending on context of use)"; however, the notion of near synonymy was not implemented in RF2 and thus there is currently no way to designate descriptions as broader than.

Current editorial policy states that broader descriptions should be inactivated as "not semantically equivalent" or added with the context of use specified.

Current editorial policy is supported by a position paper (SNOMED International Position on the addition of “Patient-friendly terms” (PFT) to the International release of SNOMED CT)

EAG Email thread

Proposal:

Prepare a whitepaper on SI policy related to degree of synonymy in the International release and extensions

Discussion:

1.  Do we want to reintroduce the notion of degree of synonymy to SNOMED CT?
2.  What is the scope of "allowable" degree of synonymy?
3. What types of synonymy should be supported in the "core" (by this we mean the clinical core and international edition content)?
4. What are the mechanisms, technical architectures that can be used to manage degrees of synonymy?

5. How should degree of synonymy (including non-synonymy) be handled by extensions?

Analysis by GRE identified approx 20% of descriptions in SNOMED are not strict synonyms. This is correlated with the number of synonyms attached to a concept. In 2010 the inactivation of concepts with non-synonyms was replaced by using the REFER-TO relationship. The degree of synonymy refset was "lost" with the move to new tooling.

From an editorial perspective, we need to answer the questions above and then send our decisions to the MAG to see what would be involved in implementing in tooling and release files.

There are around 20,000 concepts with multiple descriptions (over the matching description with the FSN). These would be the source of terms needed for evaluation of levels of synonymy that exists.

Should we resurrect the multiple language domain reference sets that could be context-based.

If we were to reinstitute the degree of synonymy capabilities, would this be something that would be implemented within the International release or restricted to a wrapper by other extensions?

Another alternative to separate refsets is the addition of another description type. Since description types are not "hard-coded", these would be less onerous to add. There are context dependent synonyms (hypernyms). There is also the notion of index terms that assist in the location of the proper concept. How many different description types would be needed?

Where the addition of new description might be amenable to new descriptions, current descriptions typeID are immutable and could only be inactivated if determined to be inappropriate descriptions for a concept. That would require substantial work by extensions or NRCs to manage. This will require another technical approach.

Decision: