SNOMED Documentation Search

 Other Documents
Skip to end of metadata
Go to start of metadata

Current Version - Under Revision

The SNOMED CT hierarchy

The SNOMED CT  subtype hierarchy refers to the organization of concepts in SNOMED CT from the most general concepts, at the top of the hierarchy, to the more specific concepts at the bottom. The concepts that make up the top level of the hierarchy are shown in  Table 6.2.2-1 . All other  active concepts are subtypes of at least one of these concepts.

Table 6.2.2-1: Top Level

Several levels of increasingly fine categorization may exist between the top level of the hierarchy and concepts that have sufficient detail to be recorded in a patient's medical record. shows the levels of hierarchy that exist between the top-level Concept 404684003 |Clinical finding|and the finding "Catatonic reaction."

Figure 6.2.2-1: Hierarchy example: Catatonic Reaction

Hierarchy Representation in the relationships table

The SNOMED CT Relationship table represents relationships between one SNOMED CT concept and another by including a row in the table for each such relationship. The columns sourceId, typeId and destinationId define the source of the relationship, the kind of relationship that exists and the target of the relationship respectively. Each of these fields, contains a SNOMED CT ConceptIdentifier. Hierarchical relationships are expressed by linking the source concept to its "parents" (i.e. the concept or concepts immediately above it in the hierarchy). The typeId used to represent the subtype hierarchy is the 116680003 |is a|relationship.

For example, the fact that  |catatonic reaction| is a subtype of  |psychological finding| is expressed in the Relationship Table as shown in  Table 6.2.2-2:

Table 6.2.2-2: Subtype Relationship Example

Where the identifiers shown above represent the following concepts:

Following these relationships in the opposite direction (i.e. from destinationId to sourceId) we can find all the subtype children of a concept.

Using "is a" Relationships to enhance search capabilities

This section is concerned with the ways in which the hierarchy can be used to help a SNOMED CT user when they are searching or browsing the terminology.

Note: The primary use of the SNOMED CTsubtypehierarchy is to support effective retrieval and aggregation of data. This is discussed in Testing and traversing subtype relationships.

It is possible to start at the top of hierarchy and navigate from parent to child in order to find a Concept or term in SNOMED CT. A more efficient approach, however, is to use the hierarchy to supplement a Keyword search by enabling the user to look at related Concepts in order to consider them as alternative matches, or to check the context of a search result. The following examples illustrate these two uses of the SNOMED CThierarchy.


  1. Checking supertypes
    • A user wishes to find a description that relates to the condition of a patient who is hypersensitive to an allergen. The user performs a search on the Keyword "Hypersensitivity" and finds an exact match. Before the user selects the description for inclusion in the patient record, they check the Fully Specified Name, which is "Sensitivity (finding)." The user then checks the hierarchy and discovers that the selected Concept has "Psychological finding" as an ancestor, which indicates that this is not the correct description to use in this context.

  2. Checkingsubtypes:

    • A user wishes to find a description that relates to the condition of a patient who is hypersensitive to an allergen. The user searches for the Keyword "allergy," and finds one Concept having a description that is an exact match. The user then looks at the children of the Concept(i.e. those concepts immediately below it in the hierarchy). One of the children has the preferred description"Contact Hypersensitivity" which matches the user's intended meaning. The user selects this Concept for inclusion in the patient record.

Using "is a" Relationships to display hierarchical information in applications

Most visual application development tools contain a component designed to display hierarchical information as a tree in which branches can be expanded or collapsed. Tree views are well-suited to displaying SNOMED CT hierarchical Relationships(see Error: Referenced caption id not found!

Captions on current page:
- Table: with ID: top-level
- Table: with ID: subtype-relationship
- Figure: with ID: hierarchy-example-catatonic-reaction
- Figure: with ID: hierarchy-as-tree
). These views are used in many different user-interfaces where information needs to be represented as a hierarchy (e.g. displaying a file-system as a hierarchy of folders or providing a collapsable outline of a document or help file). Therefore, most users will already be familiar this paradigm.

Figure 6.2.2-2: SNOMED CT hierarchy represented in a tree view

The process of creating a tree view from the SNOMED CT Relationship table is straightforward as long as a few simple ideas are mastered:

  • Most standard tree-views controls start from a single root and require that higher level branches must be added before sub-branches. This means that when viewing part of the hierarchy from the bottom up, the tree must be compiled in temporary form before it can be displayed.

  • Since the depth of the hierarchy is not known in any particular case, operations that iterate up or down the depth of the hierarchy must be done using a recursive algorithm. However, this recursion must usually be limited since placing the entirety of the SNOMED CT hierarchy in a single tree control is likely to create performance issues and may exceed physical limits on the capacity of the control.

  • Standard tree view controls are not good at displaying the multiple parent nodes that occur in a polyhierarchy like SNOMED CT. Therefore, some compromises need to be made to present options for navigation up the hierarchy.

  • Effective use of some tree controls requires unique keys for each node. Multiple parents and multiple roots through the hierarchy mean that the same Concepts will appear in multiple places in the hierarchy. Therefore, the concept identifier cannot be used to provide a key that is globally unique within the hierarchy.