SNOMED Documentation Search

 Other Documents
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Current Version - Under Revision

itself is only a part of the solution to addressing the requirements for effective electronic clinical records. A terminology on its own "does" nothing unless it is implemented as part of an application and used. Implementation of requires software applications that exploit its features to meet the real and perceived needs of users.
The "users" of include:

  • Those who specify, commission and configure software for use in a particular clinical environment;
  • End-users who enter or retrieve clinical information.

As illustrated by , users experience through application software which delivers services to access and apply . The ways in which applications apply the features of to address user requirements determine the extent to which the potential benefits are realized .
The following sections summarize some of the types of implementation that may be needed to meet different requirements. Some types of application do not need to support or use all features. However, there are some overarching requirements for consistency between implementation used within a given organization, country or region. Even where requirements are limited, care should be taken to ensure that are aligned with good practice and with agreed policies applicable to the situations in which they are used.

Figure 1. Relationship between users application software and SNOMED CT

Implementation Types - Clinical records

A enabled clinical record application uses to represent clinical information in the records of individual patients.
Clinical record applications include specialized departmental systems, organization -wide systems and systems that integrate multiple systems to deliver a distributed or a collection of widely accessible summary records.
A enabled clinical record application needs to provide including entry, storage, retrieval and communication of . These depend on including the ability to search for and to interpret stored .
A wide range of types of information can be represented at different levels of detail using . The types of information and level of detail that are used may vary depending on user requirement or may be limited by the design of the application. Differences in the required level of expressivity influence the range of that need to be supported.
The way that are represented within a record structure affects the range of services that are required to deliver the potential benefits of implementation. The value of the rich expressivity of may be enhanced or diminished by the way the record structure relates to surrounding contextual information. For example, if a record structure permits similar or related information to be recorded in several ways a query to retrieve that information will need to consider all these possibilities. Retrieval is simpler if similar information is recorded in a consistent way - irrespective of the way it was entered. This issues are discussed in detail in the Record Services Guide .

Implementation Types - Knowledge representation

A enabled knowledge representation uses to represent or tag resources that represent clinical knowledge. Examples of resources that can be enabled include electronic reference books, clinical guidelines, care pathways, decision support protocols and requirements for analysis and audit.
There are various ways in which can be used in a knowledge resource. These can be divided into two broad categories:

  • Use of

    as an integral part of a structured representation of knowledge:
    • For example, a decision support rule that tests for the existence of a record of a particular type of finding represented using a

  • Use of

    to tag or index a knowledge resource:
    • For example, a reference book in which textual

      of indications, contraindications and side effects of particular treatments are tagged with

      that can be used to allow context-sensitive retrieval of relevant information.

There are two distinct but interrelated aspects to knowledge representation.

  • Applying

    to the resource:
    • The form of representation to be used must be specified in a way that takes account of the ways in which the resource is to be used and accessed.
    • The knowledge authoring environment must allow the specified representation to be applied consistently. This requires use of

      that allow searching and selection of

      . Depending on the level of detail required, there may also be a requirement to support the construction of

  • Enabling appropriate access to and use of the resource:
    • The types of access required depend on the intended functionality.
    • The most basic level of functionality involves using

      as a

      -based index. By taking account of the

      and defining

      , a

      -based index can provide more relevant results than a simple term based search.
    • More sophisticated uses such as clinical decision support require

      in the knowledge resource to be used to generate queries that can be applied to information stored in an

    • The provider of a

      enabled knowledge resource may provide a specification that allows software developed by other organizations to interrogate it and provide the required level of functionality. Alternatively, the knowledge authoring organization may also develop and provide software that delivers the intended functionality.

Implementation Types - Aggregation and analysis

enabled aggregation and analysis systems use to enable effective aggregation and analysis of information derived from clinical record systems.
enables consistent processable representation of clinical information. As well as presenting opportunities for analysis of information within an individual clinical record system, this can be used to support analysis of a broader substrate of aggregated data.
There are two types of approach that be employed to enable analysis of aggregate data.

  • A

    enabled data warehouse:
    • The content and structure of data required from individual

      is specified. The specified structure must include details of the required representation of data including

    • The required data is extracted and uploaded to a database designed for the purpose of large scale analysis. Usually the extract and upload will need to be repeated or updated at specified intervals.
    • The central database is structured to optimize common types of queries taking account of the

      and the

      between referenced

      asserted in

    • A query interface is provided to allow common types of question to be expressed against the central database.
    • Queries are run taking account of the


      to provide comprehensive and accurate results ( minimizing the risks of false negatives or false positives).
    • The results of queries are presented where relevant using

      as processable labels to enable further analysis.
  • A common query specification supported by clinical record systems:
    • A common


      is specified. This is used as a common

      against which queries are evaluated.
    • Each clinical record system provider implements this common

      as a view of the information stored in their

    • A query interface is provided to allow common types of question to be expressed against the common

    • Queries are distributed and run on individual systems and the results are returned to a central system for aggregate reporting.
    • The results of queries are presented where relevant using

      as processable labels to enable further analysis.

In practice, there is significant overlap between these two approaches. A data warehouse approach can benefit from a common approach to specifying the information extraction requirements. This allows changes to the specification without re-engineering the contributing clinical record systems. A common query specification approach requires a central element to manage distribution of queries and aggregation of results.
Irrespective of the approach taken, enabled aggregation and analysis is most effective where the representation of information in the contributing clinical record systems is consistent with a common view. However, it is possible to aggregate information from diverse systems if the limits imposed by differences are understood. It is even possible for a aggregation and analysis system to be applied information that was not originally encoded using . An extraction and aggregation interface that includes mapping from another coding system may produce information of adequate quality and consistency for many purposes. Data derived by tagging textual records using may also meet requirements that are not safety-critical.

Terminology tools

enabled terminology tools provide access to content. On their own they are not practical end-user implementations but they enable the development and review of . They may also deliver services that can be used by end-user implementations.

Implementation Types - Terminology browser

A enabled allows the content and structure of to be explored and reviewed.
A typical enabled can locate and by and by searching the text of terms. Various views of located may be displayed including the set of related , the hierarchical and other defining .
A terminology may be:

  • A stand-alone tool.
  • Part of a more extensive implementation.
  • Accessible via an


    • This may allow the

      to be used by client applications to select

    • It may be part of a

      which provides a wider range of


Implementation Types - Terminology server

A is a software application that provides programmatic access to . These services are made available through a documented ( ) which can be used by many different client applications.
A must be able to import SNOMED CT release files and provide some or all of the services described in the Terminology Services Guide. All must support a basic minimum set of functions including Foundation Terminology Services and access to Reference sets and other metadata .
A may provide services, such as a set of screen controls to support term selection. Alternatively, while the should support searches, the representation of the results of a search may be left to client applications. Where controls are provided by the server, these controls may also be packaged in an integrated form as a .
A may also provide services that support the use of other terminologies. In this case, it may conform to a standard specification such as ( ).

Implementation Types - Terminology development and maintenance tools

development and maintenance requires tools which are able to create and update content.
Development and maintenance tools may either be general purpose or may focus on specific requirements (e.g. to support , or development of ).
The process of maintenance needs to track changes and manage conflicts between edits made by different authors. In the case of content development, the tools must also ensure that definitions conform to the . At regular intervals the tools need to generate a consistent set of quality assured .
The is a set of software tools designed to support the development, maintenance, and use of . Its key role is to facilitate the maintenance of the and the National developed by . However, the future scope of use may extend to other organizations and to health information systems around the world. The is owned by the and is available under an Open Source license agreement.

  • No labels