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.

Filtering a search by using subsumption checking is an effective technique to enhance the display of search results. It reduces the list of search results by nesting the subsumed Concepts under the general Concept. If the user wishes to select a narrower Concept, they can expand the node to select the nested subtype.

An Example Illustrating Rationalization by Subsumption Cross-Checking

Unconstrained search for descriptions that begin with "hernia" returns a total of 49 Concepts which belong to many subtype hierarchies such as | Clinical Finding | and | Morphologic abnormalities |.

Constraining a search for "hernia" by the "clinical findings" supertype returns 35 matches which is still considered to be a long list, many of which are subsumed by the general Concept "hernia". [see Constrain searches by supertype ancestors]

Rationalisation by subsumption cross-checking can further reduce the matches by nesting the subsumed Concepts such as | perineal hernia | under | hernia |. If the user wishes to select a narrower Concept, they can expand the node to select the nested subtype.

Groups of people, such as practitioners of a discipline or specialty, frequently use similar sets of Descriptions and Concepts. Lists of widely understood (or easily learned) abbreviations or mnemonics that allow rapid entry of these commonly used Concepts are recommended as a way of accelerating repetitive recording.

A similar facility may also be useful for individual users or organizations that have sets of Descriptions and Concepts that they use frequently. Providing an easy way for users to store personal favorites following a search and recall these favorites with user-defined abbreviated access terms will enhance usability and significantly increase the speed of data entry.

User guidance may be necessary to minimize the risk of overusing the shortcuts. Unless the general search facilities are also easy to use, it is likely that users will favor the shortcuts even when it would be more appropriate to use a more accurate but less accessible Concept. An unchecked bias toward easy to record Concepts may lead to deterioration in data quality, statistical anomalies, and in the worst case, inappropriate treatment.

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.

A search for a term (e.g. "fundus") may return multiple identical matches. Fully specified name Descriptions are always unique at a specific release. However, the preferred terms or synonyms may not always be unique, as illustrated in the image below.

Identical terms of different Concepts can be distinguished by displaying the search results under different headings according to which supertype ancestors they belong to. This technique is particularly useful for searching large unconstrained subsets that belong to more than one supertype ancestors.

In many instances, several synonyms associated with the same Concept contain the same keyword . For example, | herniated structure |, | hernia |, | herniated tissue |, | herniated structure | and | herniation | all begin with "hernia". A search for the target Concept "hernia" would return the first phrase found during the search. Designing a filter that gives the user the option of filtering the results by description type such as the Preferred Term or the Fully Specified Name can significantly reduce the results, as illustrated in the image below.

Avoid Multiple Hits on the Same Concept by Filtering the Search by Description Type

Filtering search results to show only the Fully Specified Name (search also constrained by supertype ancestor)

Designing a filter gives the user the option of filtering the results to show only the Description associated with the Concept that is the closest match to the search term, as illustrated in the image below.

Filtering search results to show only the closest match to the search term, hernia (search also constrained by supertype ancestor)

This section concerns the rational ordering of search results. When developing browsers and search embedded functionality within clinical applications, careful consideration must be taken in specifying the prioritization of search results, as adopting many of the recommended techniques below may compromise the speed of search.

Order Shortest Matching Terms First

Ordering the shortest matching term first is a common display requirement for search browsers and search functionalities in clinical applications. This applies text search techniques previously in the Guide (e.g. searching for descriptions that contain the search text). [see Search by text] Many users can expect this technique to exist in all use cases concerning searches that return large result sets. It is intuitive to display the shortest term that is also the closest lexical match first. If the shortest matching term is not in the first set of visible matches, a user is likely to assume that there are no relevant candidate matches or use the wrong concept or description.

A common mistake is to implement a search functionality that is configured to sort search results alphabetically in a clinical setting. The result list, when Concepts like hernia is searched, starts as shown below and the term "hernia" itself would be more than 130 items down a list of over 700 matches.

Position of term 'hernia' in an alphabetic and shortest terms ordered search 'hernia':

It is recommended to order preferred term matches before synonyms, particularly in clinical settings, as the Preferred Term is a common word or phrase used by clinicians to name that Concept. This technique will enhance usability and significantly increase the speed of data entry. It may be helpful to the user whether the candidate match is a Preferred Term or synonym.

For a country or region that has more than one official language (e.g. Belgium), it would be useful to have a user configurable option that enables results to display matches in a preferred language first in applications that support more than one language. This can be done using combinations of Language Reference Sets.

Search results may need to be configured in a specified order using one or more active Ordered Reference Sets. The way in which access to search results is prioritized depends on the nature of the application and its operating environment. Examples of prioritization include:

• Showing Descriptions associated with high priority Concepts before those with lower priority.

• Showing Concepts with high priority before their less highly prioritized siblings in hierarchical display results. [see ]

• Initially listing Concepts and associated Descriptions with priority above a specified threshold and requiring additional step to access those assigned lower priority.

This option will require the application to track the frequency of term selection so that search results can show the most frequently selected terms near the top of the results or displayed separately in the results. If this technique is chosen, user guidance may be necessary to minimize the risk of overusing the frequently used Descriptions as they would be easier to find. An alternative way of browsing through frequently used terms is to give the user the option to store the frequently selected terms as personal favorites and recall with user-defined abbreviated access term following a search. [see ]

As noted in the section, alphabetical ordering of search results should NOT be used for general purpose searches of SNOMED CT. Instead the shortest matches, best matches or most commonly used matches should be shown first. However, there may be some specific situations in which it may be useful to alphabetically order a short list of matches. For example short pick-lists may be alphabetically ordered in a data entry form. [see ]

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

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.

This section describes how search results can be ordered rationally. When developing browsers and search functionality within clinical applications, careful consideration must be taken when specifying the prioritization of search results as adopting many of the techniques below may compromise the speed of search. The benefits of presenting the results in the best manner should therefore be evaluated against the speed of the search.

• Order Search Results Rationally

• Distinguish Identical Terms of Different Concepts

• Avoid Multiple Hits on the Same Concept