No matter which EHR design is used for implementing SNOMED CT, they will each incorporate some form of interaction between the end users and SNOMED CT. The way that SNOMED CT is implemented makes a significant difference to the user experience. Various simple techniques can be used to seamlessly integrate SNOMED CT with user interfaces that match the needs of clinical users.

This section offers high-level guidance on ways to deliver a positive user experience of SNOMED CT as part of an EHR system. More details on topics discussed in this section can be found in the Documents in the SNOMED CT document library - https://confluence.ihtsdotools.org/display/DOC and the Search and Data Entry Guide (http://snomed.org/search).

SNOMED CT Concept Identifiers

Unlike some classification schemes in which the characters used in each code convey some meaning, SNOMED CT concept identifiers are a sequence of digits which in no way reflect the meaning of the concept. For this reason, there is usually no value gained by displaying the identifier to the user, and in most cases it should be hidden to simplify the user interface. Instead users should see and interact with the terms used to represent the concepts, and the SNOMED CT concept identifier should purely be used in the stored record.

Preferred Term and Synonyms

Where SNOMED CT is being used as an interface terminology, the preferred term for each concept should be used as the default for display on the user interface. Each concept may have a different preferred term in different languages, dialects, specialties or care settings, and so these can be configured to a specific clinical environment. To improve the ease for users in searching for a given concept, user interfaces may support searching over any acceptable synonym for each concept. Preferred terms and acceptable synonyms are defined in SNOMED CT using a Language reference set, which references the subset of descriptions used in a given language, dialect, specialty or care setting. SNOMED International distributes two language reference sets (for US-English and UK-English), and various member countries distribute their own national Language reference sets. Additional language reference sets may be created at the regional, specialty, institute or software product level to truly customize the local user's experience.

Where a separate interface terminology is being used, each term may be bound (or mapped) to an appropriate SNOMED CT concept. When the interface term is selected, the identifier of the bound SNOMED CT concept is stored in the record. It is important when an interface terminology is being used that the mapping to SNOMED CT is of sufficient quality (ideally equivalent) to support the use cases for which the data will be used. Using an interface terminology, for example, may be useful for structured data entry, where only part of the meaning is represented by the selected term, and the rest by the surrounding interface context. An example of this is illustrated in Figure 18. In this example, when the radio button next to the term 'Full' is selected (from the 'Mobility' section on the user interface), the concept 160680006 |fully mobile (finding)| is recorded in the health record to fully represent the meaning of the selection and make future queries on this data more reliable.

Figure 18. Example of interface terminology used as part of structured data entry

Fully Specified Name

Identical words or phrases may sometimes have multiple meanings. In these cases, it may be helpful to display the fully specified name (FSN) of a concept in order to disambiguate each identical term.

For example, Figure 19 illustrates three terms that match the search for "cold" which have very different meanings. In practice, such ambiguities can also be minimized by appropriate search constraints (e.g. only two of these results refer to disorders).

Figure 19. Search results matching "cold" with their FSNs displayed to the right

Constraining Search Results

SNOMED CT is a large terminology with broad coverage. Consequently, unconstrained searches can result in long and unhelpful lists of matching terms. Ideally, users should only be presented with content relevant to their task. There are several ways to constrain search results to deliver a shorter and more relevant list of search results, including constraining concepts:

• To a particular hierarchy
  • For example, only concepts from the procedure hierarchy
• To the subtypes of a given grouper concept
  • For example, only concepts that are subtypes of the |pharmaceutical dose form| concept
• Based on membership of a defined subset of concepts or descriptions
  • For example, only body structure concepts referenced by the |lateralizable body structure reference set| 
• Based on particular attributes of the concept
  • For example, only disorder concepts defined with an |associated morphology| of |inflammation|

If searches are not constrained, the result may include a long list of irrelevant concepts, from which it is difficult for a user to find the appropriate term. Unrestricted searches also lead to errors in coding where similar terms are associated with concepts from different hierarchies. For example the term "emphysema" can refer to a morphological abnormality in the lung or to the disease caused by this abnormality. While these concepts are related, using morphological abnormality as a patient diagnosis will lead to incorrect retrieval results.

An example of constraining to a particular hierarchy is shown in Figure 20. This example illustrates a search, which is performed with two different constraints. On the left the results are limited to the 'clinical finding' hierarchy, and on the right they are limited to the 'procedure' hierarchy.

It should be noted that some SNOMED CT hierarchies are never relevant for clinical data entry. In particular, concepts in the |SNOMED CT Model Component| hierarchy are technical artifacts that should be excluded from searches used for clinical data entry.

Figure 20. A search constrained to the procedure hierarchy (on the left) and the disorder hierarchy (on the right)

Ordering Search Results

For many purposes it is helpful to order search results by ascending term length. This ensures that the terms that match the search string without other additions are seen first. Other list sequences may have their own merits but alphabetical ordering is often unhelpful, except in a very short list of search results.

Tree Navigation

A user interface may include the use of tree navigation to allow the user to navigate up or down content arranged in a tree structure, expanding and collapsing nodes as required. A tree hierarchy may also be used to arrange search results into a nested list that displays the most general matches first, with more specific matching subtypes nested below them.

The SNOMED CT subtype hierarchy may, in some cases, be used for these purposes. Alternative navigation structures can also be developed using an ordered reference set, which is customized to a specific use case. For example, users may wish to navigate to diagnosis content using customized groupings relevant only to the local region.

Data Entry Forms

For structured types of data entry, templated forms are often used. In these cases, SNOMED CT concepts or expressions can be bound to each relevant field, option or list item. Preparing these bindings is part of the customization of an implementation to use SNOMED CT.

Encoding Free Text

Another type of interface that some tools provide enables free text to be coded using Natural Language Processing (NLP) enhanced by the semantics within SNOMED CT. This can provide an excellent user experience for typed or dictated data entry, but requires careful attention to quality to avoid inappropriate coding.