Current Version - Under Revision
The " SNOMED CT hierarchy" refers to the organization of concepts in SNOMED CT from the general, at the top of the hierarchy, to the more specific or "granular" at the bottom. The concepts that make up the very top level of the hierarchy are shown in . All other SNOMED CT concepts fall under one or more of these categories.
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
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 Concept Identifier. 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.
Table 6.2.2-2: Subtype Relationship Example
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 CT hierarchy.
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.
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.
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 ). 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.