Terminology Services Guide

Search

SNOMED CT Document Library

    Loading...
  

Terminology Service Requirements

Terminology service providers should refer to the following sections of this guide for statements of requirements that their services should meet when accessing SNOMED CT:

  • 2.3.1 Terminology Service Users
    • Outlines user requirements for high-performance services that provide appropriate access to SNOMED CT.
  • 2.3.2 Healthcare Application Providers
    • Outlines requirements from the perspective of healthcare applications that consume terminology services.
  • 3 Terminology Service Use Cases
    • Provides examples of practical use cases involving access to SNOMED CT that an application may need to complete. For each of these use cases, it identifies one or more of the required terminology services that can be used to complete the required activity. 
  • 4 Terminology Service Types
    • Describes specific terminology services or functions that are required to enable effective use of SNOMED CT.

Support for Different Terminologies and Interfaces

Clinical systems can be effectively implemented using a service oriented architecture, in which the terminology services are designed as an independent software component, accessible via an API (Application Programming Interface) gateway. This enables the other system components to access the key services without being affected by changes to the way these services are implemented. 

When designing terminology services for SNOMED CT, it is important to utilize the sophisticated design features of the terminology, as this will support its effective use. When designing terminology services to support a range of different terminologies, it is important to consider the commonality between these terminologies.  Table 2.3.3-1 summarizes some of the advantages and disadvantages of designing terminology services that only work with SNOMED CT, compared with designing services that can also enable access to terminologies or code systems. It also identifies advantages and disadvantages of supporting one or more interfaces through which applications can access SNOMED CT and/or other terminologies.

Table 2.3.3-1: Terminology Service Design Options

OptionsNotes
Terminologies SupportedSNOMED CT only

A terminology service provider may develop and deliver services that are specific to SNOMED CT.

  • The advantage of this approach is that it allows services to be tailored to the structure of and features of SNOMED CT.
  • The disadvantage is that it may make the services less attractive to organizations looking for a more general terminology services solution.
SNOMED CT and other code systems

A terminology service provider may develop and deliver services that support access to SNOMED CT and other terminologies, code systems, or classifications.

  • The advantage of this approach is that it provides a single solution for customers that require access to a range of different terminologies.
  • The disadvantage is that there is a risk that the services offered may not make full use of features that are specific to SNOMED CT and the other code systems.
Terminology Service Interfaces SupportedProprietary interface

A terminology service provider may specify their own interface through which client applications access SNOMED CT and/or other terminologies.

  • The advantage of this approach is that the interface can be designed to take account of special features that the developer has included. 
  • The major disadvantages of a proprietary interface is that
    • application providers may not be willing to invest effort in supporting different proprietary interfaces
    • consumers get tied-in to a specific provider, because migration to a different, and potentially better, provider is too complicated 
SNOMED CT specific interface

A terminology service provider may support an interface that is specifically designed to work with SNOMED CT. For example, SNOMED International's own terminology server Snowstorm provides an interface that is specifically designed to work with SNOMED CT.

  • The advantage of this approach is that it allows optimization of services that are specific to the design and features of SNOMED CT.
  • The disadvantage is that it requires application providers to use a specific interface for accessing SNOMED CT while they need to use other interfaces to access other code systems.
A general-purpose terminology service interface

A terminology service provider may support a general-purpose interface that can be used to access a wide range of different terminologies, code systems, and classifications. For example, the FHIR Terminology Service (part of the HL7® FHIR® Specification1) defines a general-purpose terminology interface applicable to a wide range of healthcare terminologies and code systems.

  • One advantage of this approach is that it allows an application provider to use the same terminology service interface to access SNOMED CT and other code systems to which they require access. Another advantage is that an application provider can switch between different implementations of terminology services that support the same interface.
  • The disadvantage of a general-purpose interface is that it may not facilitate optimized access to some of the specific features of SNOMED CT.
Multiple terminology service interfaces

A terminology service provider may support several terminology service interfaces. For example, SNOMED International's Snowstorm server supports both the Snowstorm REST API and the FHIR Terminology Services API.

  • The main advantage of this approach is that it combines the advantages of a SNOMED CT specific interface and the advantages of a general-purpose interface. It allows a general-purpose interface to be used to access other code systems, while also supporting the optimization of services that address SNOMED CT specific requirements.
  • The main disadvantage of this approach is that it requires the service provider to maintain alternative ways to access similar services. If a terminology service supports more than one interface specification, it is important to document any differences in results or performance. A service that optimizes access through a proprietary interface may not deliver the same performance when accessed through a more general interface. In some cases, the output of similar services may differ due to differences in the specifications or due to limitations of a particular implementation.

Footnotes
HL7® and FHIR® are both registered trademarks of HL7 (www.hl7.org).

Feedback
  • No labels