This section summarizes the ways in which SNOMED CT concept definitions are represented. It outlines the rationale for changes to the way in which the stated view of concept definitions is represented. The changes are occurring during a transitional period that started in July 2018 and is due to be completed in 2019.

This section outlines some of the features of concept definitions and the impact of different ways of representing concept definitions on the precision and completeness of those definitions. This section has been kept as brief as possible and is only intended to raise awareness of the changes. For those interested in understanding more about each of the topics mentioned, a more detailed appendix is provided which illustrates each of the points made in this section.

This section briefly outlines two distinct types of views of SNOMED CT concept definitions. More detailed illustrations of some of the points on this page are provided in .

SNOMED CT concepts are defined by assertions made by SNOMED CT authors. The concept definitions asserted by SNOMED CT authors are known as the stated view.

The stated view is a representation of concept definitions consisting only of assertions made or revised by SNOMED CT authors.

A description logic classifier can apply logical rules to the stated view to create inferences. The end result of this process is an inferred view of concept definitions.

The inferred view is a representation of concept definitions that is logically derived by applying a description logic classifier to the stated view.

The decision on whether you need access to the stated view and/or inferred view depends on your answers to the following questions.

This section outlines the rationale for distributing an OWL representation of the stated view of concept definitions and provides an overview of the way OWL axioms are represented in SNOMED CT release files. More detailed information is published separately in the SNOMED CT OWL Guide and the SNOMED CT Logic Profile Specification.

Rationale for Using OWL

The mismatch between the requirements for representing enhanced concept definitions and the capabilities of the current stated relationship file might in theory be addressed by addition of columns to the file or adding additional information in reference sets. However, in practice this would create a more complex solution able to support a specific set of enhanced features.

Adopting the well-established OWL standards formats offers a more flexible solution that can represent the full range of description logic features. This approach enables SNOMED Internation to specify a particular logic profile to be applied to current releases of SNOMED CT, with the option to extend that profile in the future. Future revisions of the logic profile would not require a change in the distribution file structure provided these were supported by an OWL syntax.

OWL Axioms

OWL axioms can be represented using several different syntaxes. SNOMED International has chose the OWL Functional Syntax as its standard representation.

The OWL Functional Syntax is a formal representation of the web ontology language (OWL) as a simple text base syntax that is used as a bridge between the structural specification and various concrete syntaxes.

Related Links

OWL axioms are distributed in a reference set that follows the specification. The axiom itself is contained in a string field and the concept whose definition it contributes to is referenced by the the referencedComponentId. Although a single row in the reference set can provide a sufficient definition, the definition of a single concept can also include several axioms each represented by a row in the reference set.

Figure 2.3.4.2-1 shows the diagrammatic representation of the stated view of the definition of . Table 2.3.4.2-1 shows the same definition as represented by three rows in the stated relationship file together with the definitionStatusId in the concept file.

Stated relationships and definition status for the sufficiently defined concept

Example of OWL axiom refset representation of the definition of |Excision of appendix|.

The above table shows a row in the OWL axiom reference set file representing the same definition. As shown by this example, a single sufficient definition is represented by a single row in the reference set. However, some concept definitions may require multiple rows in the reference set. Situations in which multiple row are required include:

• Concepts with multiple sufficient definitions, each of which requires a separate row in the reference set.

• Concepts with additional necessary conditions that are not part of a sufficient definition, each of which requires a separate row in the reference set.

Several description logic features, which would improve the completeness and precision of classification, cannot be represented in individual concept definitions.

Property Characteristics

If particular characteristics of the attributes used to define concepts are identified, this can enhance classification. For example, knowing that an attribute like 123005000 |Part of| is transitive would allow the classifier to make infer that an entire finger is part of the entire upper limb.

Property Chains

Property chains are in some ways similar to transitivity but involve more than one attribute. For example, 127489000 |Has active ingredient| can be declared to chain with 738774007 |Is modification of|. In that case, suppose the definition of 387307005 |Calcium carbonate| includes 738774007 |Is modification of| of 5540006 |Calcium|, a DL classifier can determine that a tablet that 127489000 |Has active ingredient| = 387307005 |Calcium carbonate| by definition has a modification of 5540006 |Calcium| as its active ingredient. Thus in the example shown the classifier can determine that |calcium carbonate tablet| is a subtype of |calcium tablet|.

This section briefly outlines different aspects of assertions made about concepts and the extent to which they are necessarily true or form part of a sufficient definition of the concept. More detailed illustrations of some of the points on this page are provided in Necessary and Sufficient - Examples.

Assertions

The stated view of concept definition consists of one or more assertions made by SNOMED CT authors.

Necessary Conditions

Each time an assertion is made about a concept, an author must decide if that assertion is a necessary condition. If the assertion is always true for that concept and its subtypes, it is a necessary condition.

• This implies that for all instances of that concept or its subtypes, the assertion must be true, even if it has not been explicitly stated.

A necessary condition is defined as a characteristic that is always true of a concept.

Example

• If you have a , the morphological abnormality 72704001 |fracture| must be present. Therefore, 116676008 |morphology| = 72704001 |fracture| is a necessary condition of |fracture of femur|.

For each concept an author must decide if there are one or more sets of assertions that form a sufficient definition of that concept. A set of assertions is a sufficient definition if it distinguishes a concept and its subtypes from other concepts.

• This implies that if all assertions in the set are true for a concept, it must be an instance of the defined concept or a subtype of that concept.

A sufficient definition is a set of characteristics which distinguish a concept and its subtypes from all other concepts.

Examples

• The following set of assertions is a sufficient definition for because any concept for which this set of assertions is true must either be the disorder appendicitis or a subtype of appendicitis.

• Both the following sets of assertions are sufficient definitions for the concept

While each of the assertions |Causative agent| = |Substance| and |Due to| = |Disease| form part of a sufficient definition, neither of these assertions are necessary conditions because only one of them needs to be true. This illustrates that an assertion that is part of a sufficient definition need not be a necessary condition.

A concept that has no sufficient definitions is a primitive concept.

Because primitive concepts have no sufficient definitions it is not possible for a description logic classifier to determine if other concepts are subtypes of this concept. Similarly, it is not possible to automatically determine whether an expression is a subtype of a primitive concept. Therefore, only concepts or expressions that explicitly state they are subtypes of primitive concepts will be treated as subtypes when applying expression constraints or undertaking analysis.

However, note that this does not prevent a primitive concept being classified as a subtype of a sufficiently defined concept.

A concept that has at least one sufficient definition is a sufficiently defined concept.

A description logic classifier can determine whether the stated definitions of other concepts meet at least one of the sufficient definitions and if so will classify these concepts as its subtypes. Similarly, it is possible to determine whether an expression is equivalent to or a subtype of a sufficiently defined concept. Therefore, where expression constraints or queries refer to sufficiently defined concepts the results will include the inferred subtypes of these concepts.

If a sufficiently defined concept has one or more additional necessary conditions then any concept or expression that satisfies one of its sufficient definitions will also inherit any necessary conditions.

For example one sufficient definition of is an ulcer in a stomach structure:

However, another definition could be created with a more specific site gastric mucosa:

In both cases these definition are equivalent to |Gastric ulcer (disorder)|. The more general definition is flexible when it comes to allowing refinement to a specific location of the ulcer within the stomach, which is actually useful information. It also avoids requiring an expression to refer specifically to the mucosa (stomach lining), which is where all gastric ulcers occur.

For example, an expression including the specific location could look like this

This satisfies the sufficient definition because the finding site is a subtype of stomach structure. This will therefore classify as a type of |Gastric ulcer (disorder)| located in the anterior wall of the gastric fundus. The problem is that a query for disorders of the gastric mucosa will not find this expression.

However, adding the definition that refers to the gastric mucosa as an additional necessary condition can solve this problem. The expression satisfies the sufficient definition implying this is a type of |Gastric ulcer (disorder)|. The fact that it is a type of gastric ulcer causes it to inherit |finding site| = |gastric mucosa| so it will now be included in the query for disease in the gastric mucosa.

As illustrated in Figure 2.3.4.1-1, each defining relationship is represented by a row in the relationship file. The concept being defined is referenced by the sourceId, the concept that represents the type of relationship (attribute) is referenced by the typeId and the destinationId refers to the concept that represents the value of that attribute.

The relationship file also has a relationshipGroup which allows two or more defining relationships to be grouped together.

The definitionStatusId of the source concept, indicates whether the combination of defining relationships provide provides sufficient definition of that concept.

Example of stated view of |Excision of stomach structure| represented by stated relationships

Section , illustrated the following three points, which are not supported by the current use of relationships to represent concept definitions:

1. A concept may have more than one sufficient definition.

   • Use of relationships only supports representation of a single sufficient definition for each concept. If a concept is marked as sufficiently defined, all it relationships are considered to be part of its sufficient definition.

2. A concept may have a sufficient definition that includes some assertions that are not necessary conditions

Section , identifies other useful features that are supported by description logic tools but cannot be represented using only SNOMED CT.

Relationships can be distributed in an easy to understand relational file structure. The relationship file has been an established part of the standard set of SNOMED CT release files since the first release in 2002, with a revision in 2011-2012 to use RF2 to enhance versioning capabilities. Relationships can be retrieved, displayed and processed using widely understood techniques such as SQL making it easy to join the relationships to the concepts to which they relate.

The stated view of concept definitions needed to be enhanced to allow more flexible and expressive use of description logic. The structure of the relationship file was not suitable for this and a decision was made to adopt the OWL Functional Syntax so that new DL features could be added over time. As a result, the stated relationship file was deprecated.

Information about the new representation for the stated view is included in section .

The current relationship file continues to be released containing the inferred view. Due to limitations of the relationship file format, the inferred definitions do not contain the more sophisticated DL features. The relationship file:

• only contains necessary conditions

• does not distinguish between multiple sufficient definitions, regardless of whether each necessary condition is part of any of the sufficient definitions.

Nevertheless, the end result is still more complete and precise than the previous content of this file. The reason for this is that the inferred relationships in the file is generated by processing the enhanced stated view. Details of the way the inferred relationships are generated from the stated view are documented in .