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

Examples:

• 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

Examples:

ICD -10

• B01.9 Varicella without complication

• K80.2 Calculus of gallbladder without cholecystitis

• J85.2 Abscess of lung without pneumonia

ICD-11

• 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)"

Questions:

• 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)?

Discussion:

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.

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.

Question:

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.

Discussion:

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.  

Pathologic fractures

Questions:

• 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?

Discussion:

Next meetings will be during the October Business meeting:

October 6 1600- 1800 UTC

October 7 1600- 1800 UTC

Zoom details to follow

Discussion:

Ask EAG members to submit agenda topics.

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