Skip to end of metadata
Go to start of metadata

Current Version - Under Revision

Using the subtype hierarchy for data entry

The most visible hierarchical construct in SNOMED CT is the subtype hierarchy. This is constructed using a set of logical rules. The purpose of this hierarchy is to support data retrieval and aggregation by addressing the question "is concept -A a subtype of concept -B."

The same hierarchy can be used for data entry navigation but it is not designed for this purpose. Its depth and breadth are determined by logical rules of subsumption rather than by usability. As a result:

  • There is no upper limit on the number of subtypes a Concept may have. This is true because there is no rule that determines the number of subtypes that a real world concept may have. However, long lists of options are not conducive to effective data entry.
  • There is no fixed limit to the number of hierarchical steps between a generalized Concept and its most refined subtype. This is true since there is no preordained limit on the extent of possible refinement of a real world concept . However, data entry procedures that involve stepping through several levels of choices before reaching the required selection impair usability.
  • The subtypes of a Concept do not have any particular order. The 116680003 |is a| Relationship is primarily a property of the subtype Concept and does not express an ordinal position. This is true because logical subtypes are inherently an unordered set. However, a user is likely to find it easier to locate their required selection if members of hierarchical lists are displayed in some recognizable order .
  • The issues of depth, length and order noted above are also subject to change between releases. The addition of an intermediate Concept or reclassification after the addition of new defining characteristics will introduce new layers in the hierarchy. Some Concepts will then move from the list of immediate subtypes of a Concept to become subtypes of a more refined Concept. Hierarchical changes may sometimes simplify navigation by reducing the number of choices at a given hierarchical level. However, the general effect of improvements in the subtype hierarchy will be to increase its depth and thus to increase the number of steps from a particular general Concept to its most refined subtypes .
  • The nature of a subtype hierarchy means that there may be many routes from a given Concept to its more general descendants. This means that some of the choices presented for user selection are redundant since they simply offer alternative routes to the same Concept .

Routine use of subtype hierarchy navigation is not recommended for data entry. However, despite the drawbacks listed above, the subtype hierarchy may be useful for undertaking an exhaustive search for a particular refined Concept .

Example:

The Concept "Laparoscopic emergency appendectomy" can be reliably located by subtype navigation from any of its supertypes: "appendectomy," "laparoscopic appendectomy" or "emergency appendectomy."

Using Ordered Reference Sets to support data entry

Ordered Reference Sets provide alternative hierarchical representations of SNOMED CT. They are intended to support data entry by addressing the limitations of the subtype hierarchy discussed in the previous section.

  • Usability constraints can be placed on the number of levels in the hierarchy and the number of options displayed at each level in the navigational hierarchy:
    • If there are relatively few options and many layers, the most common options can be brought to a higher level.
    • If there are long lists of options, these may be subdivided with less frequent options moved to lower levels.
    • Options that are rarely or never used by a particular user community can be excluded from a navigational hierarchy to limit the range of choices. According to requirements, these options may remain accessible by switching to a subtype view.
  • Options at each hierarchical level can be ordered to meet the expectations of users and/or to facilitate rapid access to commonly used options.
  • The available options at a particular level can be kept stable across releases without affecting the accuracy of the subtype hierarchy .

An Ordered Reference Set may be based on the foundation of the SNOMED CT subtype hierarchy. This can then be modified to add ordering and other features discussed above. An alternative starting point is a hierarchy of classification derived from another coding scheme or classification.

Note:

An Ordered Reference Set derived from the Clinical Terms Version 3 hierarchy is provided with the SNOMED CT Developer Toolkit as an example.

Alternative Ordered Reference Set can be created from scratch (or as variants of a common source hierarchy) to provide views to support users with different requirements. Since Navigational Hierarchies do not affect interpretation, retrieval and aggregation, data entered in using different views can be analyzed consistently.


Feedback