Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date: 2019-04-08

1600

1330-

1730

1700 UTC

0900-1030 PDT

1200-1330 EDT

1300-1430 Argentina time

Date: 2019-04-09

0900-1230 UTC

Zoom Meeting Details:

Topic: SNOMED

Int'l

Editorial Advisory

group  

Group Zoom Meetings

Time: April 8, 2019 1330 UTC

https://snomed.zoom.us/j/3306923098

Time: April 9, 2019 0900

Please join my meeting from your computer, tablet or smartphone:

Topic: SNOMED Editorial Advisory Group Conference Call

Time: Sep 19, 2018 1600 UTC

https://snomed.zoom.us/j/853419613958363815


Obtain consensus on agenda items

Meeting Files

View file
nameSNOMED - source of truth document 2-27-19.docx
height250
View file
nameSNOMED grid Sources of Info 4-2019.xlsx
height250
View file
nameSNOMED CT content references and resources - Powerpoint - April 2019.pptx
height250

View file
name2019-April-EAG-Product-Roles.pdf
height250
View file
name2019-April-EAG-Device-Update.pdf
height250

Meeting Files

Meeting recording

The folder containing the meeting recordings is located here.

The recording for this meeting is located here.

Objectives

Edited transcripts are located here


Discussion items

Conflicts of interest

JCASummary of discussion from F2F meeting
1. The distinction between Finding and Disease has been and is a cause of confusion for modelers and implementers.
2. The use of implied context for the Clinical findings/Disease hierarchy causes issues for implementers in that other context-types are located in a separate top-level hierarchy.
3. We are currently using the Clinical findings hierarchy as both “Clinical entities” and “Assertions”.
4. It is desirable to have a “pure” clinical entities hierarchy that can be used to populate assertions (clinical statements). Potential names proposed:
a. “Findables”
b. Phenomena
c. Clinical entity
5. A number of the attributes of the Clinical findings concept model are context-type relationships.
6. It was generally agreed that SNOMED should evolve to include a “context-less” set of defined clinical entities that would support the population of a more robust and comprehensive “clinical statement” model.
7. A review of the various extant (and useful) clinical statement models should be undertaken to inform the structure of a SNOMED CT clinical statement model.
8. The current Situation with explicit context model is viewed as a starting point for the development of the SNOMED Clinical statement model.
9. A clear statement regarding the removal of support for the “Soft context” for Clinical findings and Procedures must be communicated to the implementation community.
a. Removal references to soft context from the Editorial guide.
b. Recommended that clinical entities would not be used directly, but only as a component of a clinical statement.
10. Post-coordinated expressions have a number of issues related to construction, determination of equivalence and reusability that make them less appealing as a solution to context.
a. Most large EHR systems implementations do not support post-coordination.
11. The current Situation model simply provided a way to move concepts that were context-laden, out of the ostensibly context-free Clinical findings hierarchy.
12. Logical negation is out of scope.
a. Does not conform with non-binary representations of presence or absence.
13. Any solution should be developed in conjunction with information model developers.
14. We need to develop an incremental approach to this change as it may be viewed as to dramatic for some users.

Potential Actions

  •  Write a project charter. Should outline what the end goal of the project is and what the perceived benefits and potential detriments there might be.
  •  Propose the creation of a formal project group (Clinical statement project?). The initial though is to create two types of groups, a small, formal work group and a larger project group. These would be modeled after the groups in the drugs project.
  •  Write the Terms of Reference for the Project Work Group and the overall Project Group
  •  Identify potential members. What is the proposed size of the group. The bigger the group, the more difficult it will be to get consensus. However, without adequate representation, the more chance we will have of getting pushback.
  •  Develop a draft strategy and the critical path for addressing the issues that we identify

a. Identification of the specific issues.
b. Predict the potential impact of the terminology
c. Outline that potential issues that might impact users and implementers
d. Develop mitigating strategies for minimizing impact.

  •  Notify the Community of practice about the project group and its objectives

a. Solicit feedback from the CoP. That will be our consultation process.
b. Change or revise the terms of reference as needed from input.

  •  Begin environmental scan for clinical statement models that can be used as starting points for comparison. Candidates include:

a. HL7 Clinical Statement model: (https://www.hl7.org/implement/standards/product_brief.cfm?product_id=40)
b. FHIR resources: (https://www.hl7.org/fhir/resourcelist.html)
c. CIMI?

Ran out of time, continued to Vancouver

ItemDescriptionTimeOwnerNotes and DiscussionAction

April 8, 2019

1

Call to order and role call

JCA2

Notice of recording

Conflicts of Interest

GRE - Contractor to SI, Principal in TermMedApproval of minutes fromJCAEdited transcripts of the discussion regarding the "Naked kernel" and the next generation of SNOMED are available here.
  •  Members to review edited transcripts and suggest changes.
ECE UpdateBGOAllergy and Intolerance updateBGOSubstance role groupsTMO1330 - 1332h




Agenda review and approval1332 - 1335hJim Case
  •  2019-04 Agenda approved

ECE Update1335 - 1420hBruce Goldberg
  • Follow-up discussion of injury, traumatic and non-traumatic

Injury_damage_traumatic_nontraumatic.pptx

EAG agreed that use of DUE TO Event was a preferred way to represent "Traumatic injury"

Additional discussion on approach to handle "non-traumatic injury" needed

  • Secondary disorders

Secondary disorders including gout caused by drug.pptx

Qry_Bruce usage report.xlsx

  •  BGO to write up proposal to use DUE TO Event to model "Traumatic injury"
  •  BGO to test use of GCIs to represent "Secondary disease"
  •  BGO to test alternative model for gout removing the relationship to hyperuricemia.

Clinical content "Sources of truth"1420 - 1500h
  • 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.

Break1500 - 1530h




Product role discussion1530 - 1600hToni Morrison
  • Recognized that some product roles are needed to define other procedures and clinical findings
  • Those needed existing roles can be temporarily modeled using additional axioms
  • Warning language that this is a temporary situation while a more permanent solution is devised will be communicated to the community of practice, MF, CMAG, User-support group and GA(?)
  •  Toni Morrison - to inactivate product roles that are not used to define other concepts.
  •  Toni Morrison to work with KKU to develop a communication plan for existing product roles

Device project introduction1600 - 1615hToni MorrisonSee slides attached

Historical association refset1615 - 1700h
  • Consideration of addition of "Withdrawn"
  • Concept Inactivation
  • From prior discussion, things you can say about an inactivated concept
    • 1..1 exact match - SAME AS
    • 1..X same as one or more concepts - MAY BE
    • Subtype of - WAS A
    • What is the use case for REPLACED BY? For erroneous concepts, out of date concepts? Does it provide additional value to make this distinction?
      • SAME AS: A = B, B = A
      • REPLACED BY: A <> B ?
    • Need to ensure that the semantic granularity is similar for "replacement" concepts.
    • How do we ensure consistent usage? Tooling currently constrains associations allowed for specific inactivation types
    • Do AMBIGUOUS concepts require 2..X MAY BE historical relationships?
    • MOVED TO and MOVED FROM needs to reflect RF2 structures (i.e. modules as opposed to namespaces)
    • WAS A relationships can be constructed from the release files
    • Are additional historical relationships needed to fill gaps in retrieval or analysis?
    • Concepts inactivated without a historical relationship (i.e. non-conformance to editorial policy) have an implied WAS A
  • Three aspects need to be considered:
    • Consistent historical relationship assignment by authors
    • Guidance for users to correctly use these relationship
    • From a QA perspective, cleanup of existing relationship to improve internal consistency
  • Should this be partially addressed by derivatives?

Discussion

  • Audiences that need to be supported by improved historical relationships:
    • Content editors - selection of proper historical associations when inactivating or moving concepts.

    • Data analysts who need a comprehensive history mechanism for traceability and data healing.

    • Implementors who need to know how to replace concepts that are either changed or moved or something else.

    • End user clinician who is trying to record something and all of a sudden his favorite concept has disappeared.
  •  Jim Case to work with SI tech team to inactivate existing WAS A relationships
  •  Jim Case to communicate to content team that WAS A relationships no longer have to be maintained
  •  Anne Randorff Højen, Jeff Pierson and Brian Carlsen to begin to develop use cases of concept life cycles and needed historical relationships
  •  Jeremy Rogers to provide examples of existing historical relationships of questionable correctness

Adjourn1700h



April 9, 2019


Call to order and role call

Notice of recording

Conflicts of Interest

0900 - 0905hJim Case


Resolving the finding/disorder conundrum0905 - 1030h

Background document:




Break1030 - 1100h



Proposed SNOMED CT Content Strategy1100 - 1230hJim CaseUpdate from TermMed: Naked kernel constructsGRE
  • Batch editing of the disorder/findings hierarchy to transform it into a representation with a "naked kernel" clinical entities hierarchy (no soft defaults)
  • Additional auxiliary hierarchies supporting better modeling patterns
  • An observation/statement/assertion/phenomena hierarchy that would explicitly represent context (e.g. presence/absence) while supporting correct aggregation of some absence patterns. 

GRE demonstrated a simple representation of the us eof Clinical entities and a resolution of the current Situation artifact of the inverted hierarchy when using "Known absent".

KCA reaffirmed his objection to the use of logical negation in the context of presence/absence findings and the use of a measurement approach that would represent presence/absence without the need for logical negation.

The current Situation model does not correctly represent absence in the hierarchy and this is the primary problem that needs to be resolved.

KCA proposes that the Situation with explicit context hierarchy would be the first subset of content to be placed into a module that is dependent on the Clinical entities (phenomenon) hierarchy. We need to support the need for absence content as used by most large scale EHR systems.

The current released content for absence findings in the Situation hierarchy is incorrect because of the inverted hierarchy.

Historical association refsetJRORan out of time, continued to VancouverSources of truthBGO, JPIFollowup on clinical statement model project groupJCAFuture meetingsJCAPending