All pages
Powered by GitBook
1 of 3

Loading...

Loading...

Loading...

Display Navigation Results Effectively

Results navigation is a useful feature for search browsers to have in addition to the conventional display of search results (see and ). The decision to design navigation results in a browser may depend on space availability in the application's user interface. This sub-section describes two different types of hierarchies for browsing search results.

Order Search Results Rationally
Rationalize Search Results by Subsumption Checking
Using the Subtype Hierarchy
Using the Navigation Hierarchy
Provide Feedback

Using the Subtype Hierarchy

The most visible hierarchical construct in SNOMED CT is the subtype hierarchy. This is constructed using a set of logical rules.

Matches shown in the subtype hierarchy

The primary use of the SNOMED CT subtype hierarchy is to support effective retrieval and aggregation of data.

Example:

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

Enhanced Hierarchical Displays

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.

Examples:

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.

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.

The same hierarchy can be used for data entry navigation following search 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 | 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 poly-hierarchical structure allowing for a concept to have more than a single parent concept means that there may be many routes from a given Concept to its more general ancestors. 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.

2. Checking subtypes:

The Challenge of Subtype Navigation

Provide Feedback

Using the Navigation Hierarchy

SNOMED CT subtype Relationships provide a logical semantic hierarchy. Often it is possible to view parts of the terminology and select particular Concepts by navigating through this subtype hierarchy. However, there are many situations in which the pure subtype hierarchy does not provide an ideal route for navigating the hierarchy (see Using the Subtype Hierarchy).

Navigation hierarchies can be used to drive some types of structured data entry. Navigation hierarchies can order data in sensible ways by priority, or by some readily understood convention (e.g. "cranial nerve order" or "pharmacy products in the order of strength"). Navigation hierarchies can be used for diverse purposes (e.g. "topics related to diabetes").

Navigation links are used to provide an alternative route through parts of the terminology. A navigation link can link any two Concepts together to identify a useful route for navigation. Each of the navigation links is directional, linking a navigational parent Concept to a more refined navigational child Concept. However, unlike the subtype relationship the presence or absence of a navigation link neither adds to nor subtracts from the definition of either of the Concepts that it links.

Some Concepts may exist only to provide nodes in a navigation hierarchy. These Concepts are subtypes of | Navigational Concept | and play no part in the semantic definitions of any other Concept.

Navigational hierarchies are represented as Reference Sets, which are available in the International Release of SNOMED CT or they can be created from scratch to meet specific user needs. Navigational hierarchies created from scratch do not have to represent subtypes or logical relationships unless it is required.

Provide Feedback
An example of a handcrafted navigation hierarchy showing a list of common viral diseases