SNOMED Documentation Search


Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

No mat

Anchor
_GoBack
_GoBack
ter 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 Technical Implementation Guide (http://snomed.org/tig) and the Search and Data Entry Guide (http://snomed.org/search).

...

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.

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

...

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).

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

...

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.

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

...

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.

...