Page tree

Date: 2020-09-09


1600- 1800 UTC

0900-1100 PDT

Zoom Meeting Details

Topic: SNOMED Editorial Advisory Group Conference Call

Time: Sep 9, 2020 09:00 AM Pacific Time (US and Canada)

Join from PC, Mac, Linux, iOS or Android:
Password: 674115

Meeting ID: 952 6688 8875

Password: 674115
International numbers available:

Or Skype for Business (Lync):

Meeting Files:

Meeting minutes:

The call recording is located here.


  • Obtain consensus on agenda items

Discussion items

1Call to order and role call

Start recording!

2Conflicts of interest and agenda reviewNo conflicts noted

Spinal cord injuries vs. spinal cord syndromesJim Case

SNOMED CT contains a large number of concepts that were initially obtained from ICD-9 related to spinal fractures and dislocation with associated spinal cord "lesions". After discussion with the Medical and Scientific Advisory Committee of WHO, it was agreed that in the case of spinal cord injuries, the term "lesion" was used synonymously with "damage". This has prompted a review of the use of "lesion" in ICD-11, which is acknowledged to be a supertype of "damage". However, there was also a discussion on the appropriate use of "incomplete spinal cord syndromes" in conjunction with spinal cord injuries. The syndromes represent the clinical manifestations of the injuries. It was stated on the MSAC call on May 7, 2020, that the presence of the damage does not always equate to the presence of the clinical syndrome.

Remodeling of "spinal fractures with incomplete spinal cord lesion" has recently been undertaken and has been assigned a parent of the syndrome related to damage of the spinal cord.

Question: Given the MSAC discussion, should SNOMED CT not make any assumptions of the presence of the clinical syndrome in the presence of spinal lesions/damage? E.G.


We had recently inactivated the HAS DEFINITIONAL MANIFESTATION as an attribute.  It is probably safer to not assume that the syndrome is associated. The assumption of the presence of the clinical syndrome in the presence of the pathology may be overstepping. 

Recommendation that the syndromes be removed from the model of these spinal cord injuries.

  • Jim Case Implement modeling decision regarding assignment of syndromes to lesions. Remove Incomplete cord syndrome relationships where not specifically stated.

Disposition of "X without Y" conceptsJim Case

SNOMED CT contains a large number of Clinical finding concepts (>1200) that were initially obtained from ICD-9 having the format "X without Y".


  • X without infection - 153 concepts
  • X without complication - 121 concepts
  • X without obstruction - 81 concepts

In most cases, these are paired with "X with Y" concepts. Both ICD-10 and ICD-11 have retained a small subset of this type of term, although many are index terms


ICD -10

  • B01.9 Varicella without complication
  • K80.2 Calculus of gallbladder without cholecystitis

  • J85.2 Abscess of lung without pneumonia


  • 1E90.0 Varicella without complication
  • 8A80.0 Migraine without aura
  • 9A04.0 Trichiasis without entropion

Prior discussion with the EAG about a limited set of this type of term involving <<"Brain injury without open intracranial wound" found very limited use of this type of concept and a recommendation to inactivate them as AMBIGUOUS, pointing to the immediate parent.

Issue: Every "X without Y" concept requires an intermediate primitive parent to aggregate them or they are primitive and just appear as a subtype of "X (disorder)"


  • Can we consider these terms functionally equivalent to their immediate parent? i.e. "X without Y" = "X"?
  • Should they be inactivated as the top level concepts in a subhierarchy cannot be defined and leads to a number of intermediate primitives (e.g. 400081000 |Blister without infection (disorder)|)?
  • If so, should we follow the prior pattern of inactivation reason = AMBIGUOUS or consider another inactivation reason (e.g. DUPLICATE)?


Does this only include the terms with ICD-9 terms?   They are not equivalent (i.e. X without Y <> X).  Need to develop a policy for the acceptable patterns of use. Some of these could be modeled as situations.  However, the situation hierarchy does not support logical negation properly. This is more a statement than a clinical entity.  (ref: Analysis normal form -  KCA).  There are ways to represent this with the current DL, but would require additional work. 

May be some of these that are clinically useful and these should be retained.

Agreement that the inactivation reason should not be DUPLICATE. Probably should not be AMBIGUOUS.  All terms would be reviewed for clinical usefulness prior to inactivation.  It refers to ONLY terms with the word "without".  Suggested that those that are currently used in the ICD-10 map should be retained as they do provide some usefulness.

It was re-emphasized that we do not have a way to represent clinical statements and we should reinvigorate an effort to do this type of representation in SNOMED.  It is recognized that the types of changes implied by this project would result in result in substantial changes to the overall structure of the terminology.  It should focus on the reusability of SNOMED by users.  In the process of development of such a model, need to involve both internal and external experts and implementers. 

Is there a call from users to have the type of representation proposed by a "clinical statement" model?  Need to evaluate the impact, in light of the increased expressivity it would provide to SNOMED.

Would need a prioritized list of requirements that this project should address.  It should also be harmonized with the current structure of SNOMED and as much as possible with other models. The current Situation model is a "mini" statement model that is incomplete.  Should make an effort to maintain the current structure of SNOMED and add another layer that allows for the creation of statements, in order to prevent user resistance.

Modeling philosophy for devices

Background: Initial evaluation of modeling approaches for devices found that there is no single modeling pattern that universally applies to all devices. In an effort to constrain the number of defining attributes that would be required to describe all of the different characteristics that differentiate classes of devices, the Devices Project Group determined that a single general attribute, "HAS_DEVICE_CHARACTERISTIC" could be used to describe any of the various characteristics or qualities of devices, with the primary differentia being captured in the associated values of the relationship. This is contrary to the approach that was taken in the creation of the drug and vaccine models, where very specific attributes were created to support the unique characteristics.

The approach being used in the Device Project has been questioned as inconsistent with the recent approaches to modeling primitive hierarchies and has multiple potential problems in retrieval and analysis.


Should the device project reconsider its approach to model development and create multiple attributes to support specific characteristics of each class of device (placing the burden of specificity in the attribute) or continue to pursue modeling using the general "HAS_DEVICE_CHARACTERISTIC" attribute (placing the burden of specificity on the value set).

NOTE: These two options are mutually exclusive as creating both general and specific attributes would result in a change of meaning of the general attribute (representing NEC) when a new specific attribute is created.


For the vaccine model we used a HAS PRODUCT CHARACTERISTIC to cover about 5 attributes.  In the MRCM, the range is bound to the attribute and so the ranges for these general attributes are difficult to manage and use.  Many of these characteristics are required by extensions and not the core.  The question is whether these should instantiated within the International release or allow extension more freedom to create new attributes.  

The group recommended that we create specific attributes rather than use the generic attribute relationships. Modeling within the international release would not use the generic attributes.  It is important to align new attributes to a specific subdomain so that the use of the attribute is clearer.  

  • Suzanne Santamaria to evaluate the attributes needed to replace the generic HAS_DEVICE_CHARACTERISTIC relationships

ECE Topics

Pathologic fractures


  • Should we consider ALL fractures as traumatic (e.g. pathological fractures are minor trauma to weakened bone)? [NOTE: This has been the historical representation in SNOMED CT]
  • Can we infer that all non-traumatic fractures are pathological fractures (i.e. requires some predisposing bone pathology)?
  • If the distinction between traumatic and pathological fractures needs to be made, how do we interpret the meaning of “Fracture of X”? Do we need specific “Traumatic fracture of X” concepts?


  • Jim Case to implemet modeling of Pathological fractures as traumatic fractures
  • Jim Case to re-evaluate the use of PATHOLOGICAL PROCESS for modeling underlying processes for Pathological processes and subtypes

Next meetingEAG

Next meetings will be during the October Business meeting:

October 6 1600- 1800 UTC

October 7 1600- 1800 UTC

Zoom details to follow


Ask EAG members to submit agenda topics.

Suggested topic: prioritization of domain areas for the QI project.


  1. By considering pathological fractures to be subtypes of (traumatic) fractures, I think we are confusing exposure to a physical force that can occur with normal activity but result in a fracture due to bone weakness with a traumatic injury due to excessive force that can fracture normal bones. I have found references on pathological fracture (due to e.g. bone metastases) that state e.g:

    "Normal activity, such as walking, rising from a chair, climbing stairs, or lifting the leg to get in or out of bed, applies forces exceeding 3 times a person's body weight to the hip and the proximal femur. Therefore, any underlying mechanical weakness due to metastatic disease can easily result in fracture".

    I would hardly consider walking, rising from a chair, climbing stairs, or lifting the leg to get in or out of bed to be trauma. I still think that pathological fractures need to be distingusihed from (traumatic) fractures.


  2. Bruce,

    Understand your concern.  In reading this article, it states "... pathologic fractures through malignant bone lesions are notorious for fracturing without significant trauma." (emphasis mine). I think we all agree that there is a quantitative difference between the external force placed on a normal bone from a weakened bone.  So the underlying questions that we need to answer in proposing a hierarchical separation between "traumatic" and "pathologic" fractures include:

    What are the benefits to the users in making this distinction?

    What are the impacts on CDS systems in making this distinction?

    How do we address the notion that pathologic fracture are still fractures without creating a large set of "unspecified fracture of X" concepts to group bones that commonly suffer from both traumatic and  non-traumatic fractures, and would that cause more confusion for the users than benefit?

  3. Jim,  I can't wrap my head around normal activities such as walking, standing, getting out of bed, etc. being considered as traumatic in nature  as they would never be expected to result in fracture of a normal bone. This is in contrast to other external forces such as blunt force that given a certain magnitude could fracture even normal bones. The question is how to model Fracture of X especially when there is Pathological fracture of X. As all fractures are currently modeled as traumatic if we add due to traumatic event to Fracture of X these would become siblings of Traumatic fracture of X as we have discussed. I don't see a problem with this. If we don't want to change the FSNs of Fracture of X to include Traumatic, I think a compromise would be to add an additional description of Traumatic fracture of X to all Fracture concepts except those that we want to specify as non-traumatic such as pathological, insufficiency, etc. I think this process could be automated.

  4. Bruce,

    One thing that we have no information about is the actual cause of the pathological fracture.  All we know is that morphologically the bone is compromised (for whatever reason) and the fracture occurs in the weakened region of bone.  We haave no information as to the inciting cause, such as walking, standing up or getting out of bed.  We cannot assume what the nature of the "trauma" causing the fracture is, nor can we assume that any pathologic fracture has resulted from a normal activity.  I am not sure I understand your comment "if we add due to traumatic event to Fracture of X these would become siblings of Traumatic fracture of X as we have discussed."  If we add the event as you describe, these will result in equivalencies.

  5. Jim, what I am saying is that regardless of the actual cause, one cannot assert that a pathological fracture is necessarily due to a traumatic event if standing, walking, etc. can potentially be causes.

    The model I favor is:

    Fracture of bone (disorder): no due to event relationship

    Fracture of Ulna (disorder) : due to Traumatic event w synonym=Traumatic fracture of ulna

    Pathologic fracture of ulna (disorder): no due to event relationship