Description Logic Enhancements - Briefing Paper

Description Logic Enhancements - Briefing Paper

Description Logic Enhancements - Community of Practice Consultation

Introduction

This briefing paper details changes proposed by SNOMED International's Modeling Advisory Group to enhance SNOMED CT's Description Logic capabilities.   The proposal has been accepted by SNOMED International's Management Team to be put forward for consultation with the wider Community of Practice - including Member Countries, Vendors and adopters of SNOMED CT.  This document is intended to be read by technical staff in organisations who produce SNOMED CT content as an extension to the SNOMED CT International Edition.   It should be read in conjunction with the attached Executive Summary which gives an overview of the background and drivers for proposing enhancements to SNOMED CT at this time.   

On completion, readers are invited to submit questions and comments via this form before the cut off on 28 February 2018.   Responses to this feedback will be posted on this confluence page.

Rationale

The motivation for introducing these enhancements to SNOMED CT's Description Logic capabilities is to enable improvements to the quality and analytics capabilities of SNOMED CT.

The use of Description Logic together with a computer program that performs Logic Reasoning (referred to as a "classifier") allows concept hierarchies to be automatically created and maintained based on the logical definition of each concept.  This automation improves the quality of the clinical information represented by SNOMED CT as well as reducing the maintenance burden inherent in modifying an increasing volume of content.  With accurate logical definitions for each concept, authors can take advantage of the classifier's ability to infer new parent/child relationships automatically, rather than being required to state every valid relationship explicitly - a task which is both immensely time consuming and error-prone.

The proposed changes will benefit:

  • Content authors, who will be able to achieve greater productivity and reach a higher quality at a lower cost

  • Implementers (e.g. vendors), who will receive a more consistent product

  • End users (e.g. clinicians, researchers), who will use a more complete and consistent product which ultimately provides them with better tools

  • SNOMED International and members, who will be better able to achieve their objectives, such as improving the quality of the product, aiding adoption and attracting new members

Example of new modeling capabilities

An example of concept modeling that will become available with the new description logic capabilities is shown in the diagram below.  It will become possible to declare that a concept can be either one thing or another and have each type of concept classify correct.   In the example of

{"timestamp":1762323203847,"msg":"A unknown Exception Occurred","errorMsg":"The provided AtlassianHostUser did not specify a user to act as.","code":"500"}

, any concept which IS A 

{"timestamp":1762323203858,"msg":"A unknown Exception Occurred","errorMsg":"The provided AtlassianHostUser did not specify a user to act as.","code":"500"}

and is either  

{"timestamp":1762323203877,"msg":"A unknown Exception Occurred","errorMsg":"The provided AtlassianHostUser did not specify a user to act as.","code":"500"}

a type of

{"timestamp":1762323203860,"msg":"A unknown Exception Occurred","errorMsg":"The provided AtlassianHostUser did not specify a user to act as.","code":"500"}

or has a 

{"timestamp":1762323203869,"msg":"A unknown Exception Occurred","errorMsg":"The provided AtlassianHostUser did not specify a user to act as.","code":"500"}

which is a type of 

{"timestamp":1762323203845,"msg":"A unknown Exception Occurred","errorMsg":"The provided AtlassianHostUser did not specify a user to act as.","code":"500"}

will be classified as a type of 

{"timestamp":1762323203865,"msg":"A unknown Exception Occurred","errorMsg":"The provided AtlassianHostUser did not specify a user to act as.","code":"500"}

automatically, rather than requiring this hierarchy to be manually maintained.

 

Proposed Changes

The proposal is to make more types of information available to the classifier than can currently be expressed within the limitations of the RF2 Stated Relationship file format. In the current classification process, the Stated Relationship file is used as input to the classifier to enable it to calculate an inferred hierarchy. The output of this process is converted into Distribution Normal Form (DNF)1 and represented using the RF2 Relationship File. In the proposed classification process, logical definitions utilizing a wider range of Description Logic features will be available to the classifier, which will allow more accurate automatic inferences to be performed.

One of the principle considerations in designing this proposal is to minimize the negative impact for organisations who do not wish to (or are not in a position to) take full advantage of the new capabilities.  The use of reference sets to replace the stated relationship file, while preserving the format of the more commonly used (inferred) RF2 Relationship File, will allow most users to benefit from the improvements in classification, without requiring changes to existing systems.

 

New Reference Sets

A new RF2 reference set file containing OWL Statements in Functional-Style syntax will initially augment, and subsequently replace the existing Stated Relationship file. The name of the new reference set file is expected to follow the format "der2_sRefset_StatedOWLFull_INT_YYYYMMDD.txt", and be published as part of the SNOMED CT International Edition. The OWL statements will be organised into two refsets as follows:

Refset

Usage

Refset

Usage

 

 

Contains the 'setup' information for the ontology, static 'headers' that aren't expected to change from one release to another.

 

 

Contains information relating to the definition of individual concepts

The header information in the OWL ontology reference set as well as some of the attribute logical properties (such as the fact that the 

attribute is transitive in nature) will now make explicit behaviour that has previously been somewhat hidden in existing software tools.

New Logic Features

Allowing SNOMED CT to use the full range of logical expression that is possible with Description Logic would cause a dramatic increase in classification times1. It would also increase the complexity for content authors in their mission to correctly define the meaning of clinical concepts. As such, the Modeling Advisory Group has recommended the addition of only those Description Logic features that are essential to support the proposed modeling of new content in specific priority hierarchies. This aims to successfully strike the balance of being able to express essential meaning, while not introducing unnecessary complexity.

The proposed new logic features are explained in the table below:

New Feature

Explanation

Use Case example

New Feature

Explanation

Use Case example

Property Characteristics

Allows SNOMED CT to specify which attributes should have transitive and reflexive properties.

In the Body Structure hierarchy, there is a requirement to make the

attribute transitive. So if 

 is

 and 

is

, then we want the classifier to be able to infer that

 is

Property Chains

Allows attributes to be linked together such that additional logical inferences can be made where both attributes are used in combination.

This logic feature would allow

to be linked with

such that a medicinal product that has an active ingredient which is the modification of another substance, could classify as a child of a product containing the less modified substance.

This behaviour is critical to controlling the effect of changes to the 

 hierarchy on other hierarchies.

Additional Axioms including General Concept Inclusion

 

Currently all attributes stated for a concept must be present for another concept to be considered a descendent in the hierarchy. General concept inclusions with additional axioms provide authors with greater flexibility in how concepts are defined, and provide classifiers with a greater ability to make appropriate inferences. 

For example, these features can be used to state that a subset of attributes is sufficient to define a concept, and therefore that this sufficient set can be used to classify other concepts as descendants in the hierarchy.

 

In the

hierarchy, there is a requirement to define

such that it can either be due to

OR caused by a

. Current restrictions in logic capabilities prevent subtypes of |Diabetes mellitus| that are due to a

or caused by a

from being classified as a subtype of

.

Copyright © 2025, SNOMED International