This section identifies three roles with an interest in SNOMED CT terminology services. The perspective of each of these roles is summarized with notes on general issues that those in particular roles should consider and references to relevant sections in the guide. The roles considered are as follows:
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:
Outlines user requirements for high-performance services that provide appropriate access to SNOMED CT.
Outlines requirements from the perspective of healthcare applications that consume terminology services.
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.
Describes specific terminology services or functions that are required to enable effective use of SNOMED CT.
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. The table below 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.
The following tables outline key design choices for terminology services, focusing on the types of terminologies supported and the interfaces provided. Each option includes potential advantages and disadvantages from the perspective of service design, helping organizations assess trade-offs between specialization, interoperability, and maintainability. These options can inform procurement decisions, integration strategies, and long-term terminology management planning.
SNOMED CT only
A terminology service provider may develop and deliver services that are specific to SNOMED CT. ✅ Advantage: Services can be tailored to the structure and features of SNOMED CT. ❌ Disadvantage: May be less attractive to organizations seeking broader terminology support.
SNOMED CT and other code systems
A provider may support access to SNOMED CT along with other terminologies, code systems, or classifications. ✅ Advantage: Single solution for customers needing access to multiple terminologies. ❌ Disadvantage: Risk of underutilizing SNOMED CT-specific features.
Proprietary interface
A provider may define a custom interface to access SNOMED CT and/or other terminologies. ✅ Advantage: Interface can be optimized for specific service features. ❌ Disadvantages: • Application providers may resist supporting multiple proprietary interfaces. • Vendor lock-in risk makes switching providers difficult.
SNOMED CT-specific interface
Example: SNOMED International's Snowstorm API. ✅ Advantage: Allows services optimized for SNOMED CT features. ❌ Disadvantage: Requires app providers to use separate interfaces for other code systems.
General-purpose interface
Example: FHIR Terminology Service API. ✅ Advantages: • Uniform interface for accessing multiple code systems. • Easier to switch between service implementations. ❌ Disadvantage: May not support full optimization for SNOMED CT features.
Multiple interfaces
Example: Snowstorm supports both its native REST API and FHIR API. ✅ Advantage: Combines benefits of SNOMED-specific and general-purpose interfaces. ❌ Disadvantage: Increased maintenance burden; differences in behavior, performance, or output may exist between interfaces.
SNOMED CT terminology services can be subdivided into categories based on the following two defining characteristics:
Access requirements : Does the service need to update the terminology?
User interface requirements : Does the service include its own user interface controls?
The following table describes the distinction between terminology services that provide read-only access to the terminology and those that also allow the terminology to be updated. Practical requirements for using SNOMED CT to enter, display, and report clinical data can be met by read-only terminology services. Services that are able to update the terminology are only required by those involved in the development, maintenance, or customization of the terminology.
The image below illustrates the association between the different types of terminology services and record services.
The table below differentiates between services based on whether the service includes user interface components, in addition to its application programming interface. Terminology services that do not include user interface components are capable of delivering a full range of essential terminology services but they require the client application to provide the user interface components to interact with those services. Terminology services that include user interface components have the potential to simplify client application development and configuration. Some examples of potentially beneficial terminology services with user interfaces are noted in the table below.
Section notes the need for combinations of the terminology services identified in to address each use case. Most of these use cases also need interfaces to allow users to interact and access the results of those services. However, the detailed specification of the user interface functionality of these combined services is beyond the scope of the current version of this guide.
The following tables provide examples of services in each of the four categories defined by applying the terminology access and user interface criteria.
Read-Only
Read-only terminology services enable access to SNOMED CT content and features.
These services meet requirements for practical use of SNOMED CT including collecting, displaying, communicating, and analyzing SNOMED CT coded data.
Add-Update
Add-update terminology services can add, modify, or inactivate SNOMED CT components and/or reference set members.
These services include functions that support terminology authoring, maintenance, and distribution. A full suite of development services meets the requirements of organizations responsible for creating and maintaining a SNOMED CT edition, or a SNOMED CT extension containing additional clinical concepts. Limited sets of development services can meet the requirements of organizations responsible for a SNOMED CT extension that consists only of reference sets representing subsets, maps, or data that is used to customize the terminology to meet specific purposes.
No UI
Terminology services that only provide access to SNOMED CT through an API.
Client applications using these services are responsible for providing any user interfaces required to enable practical use of these services. Client-developed user interfaces can be closely integrated with the look and feel of the client application UI. They limit dependency on a specific terminology service provider, as services without a UI have less variability and are more likely to include shared, common features.
UI
Terminology services that, in addition to an API, also provide a user interface through which users can interact with the terminology.
Services in this category range from individual terminology-bound UI controls to fully functioning tools that enable viewing or editing the terminology. User interface controls included as part of the terminology service may facilitate more rapid development and can be useful when client applications have limited requirements for SNOMED CT searching and display. Examples: • Terminology search control (Use Case 3.2 – Support EHR Data Entry):
– Text search with constraints set by data entry – Display results to support selection of appropriate concepts – Option to add postcoordinated refinements • Report and analysis query development tool (Use Case 3.4 – EHR Reporting and Analytics): – Enables creation of valid expression constraints or SNOMED CT queries
No UI
• Get details of a concept using its concept ID. • Search for concepts based on term search criteria or expression constraints. • Retrieve reference set data (e.g., subset membership, language acceptability, maps, history). • Test if a set of concepts or expressions is subsumed by a specified concept or expression constraint.
UI
• SNOMED CT browser that allows exploration and supports API-based integration with applications. • Terminology-bound UI controls (e.g., dropdown lists populated via reference sets or constraints). • Tools to analyze records containing SNOMED CT-coded data.
No UI
• Create new SNOMED CT concepts. • Add or modify axioms for defining concepts. • Classify SNOMED CT content to infer relationships. • Add descriptions to concepts. • Inactivate concepts or descriptions. • Create new reference sets of specific types. • Add members to reference sets.
UI
• SNOMED CT authoring tools for creating concepts with full descriptions and axioms. • Tools for maintaining subsets as reference sets. • Translation tools to manage language-specific descriptions and acceptability settings. • Mapping tools to develop and maintain crosswalks to other terminologies or code systems.
Many of the general use cases identified in Terminology Service Use Cases can be met in different ways by different combinations of the terminology services detailed in Terminology Service Types with user interface components or forms. Therefore, detailed specifications of the specific functionality of combined terminology services would inevitably be either incomplete or overly restrictive.
Furthermore, user interfaces presented by a combined terminology service will typically need to be integrated with client applications. Client applications may adopt different user interface styles and these styles may evolve overtime. Therefore, flexibility in the design of the user interface through which a service is accessed may be preferable to a rigid detailed specification of each type of service.
Depending on feedback from readers, consideration will be given to providing more guidance on combined terminology services in future versions of this guide.
End-Users
People involved in procurement
The end users of SNOMED CT terminology services include healthcare professionals and other people who enter, view, report, and analyze healthcare data coded using SNOMED CT. Terminology services may sound like a technical matter of little interest to users but the quality and performance of these services can make a big difference to the usability of a healthcare application. Poorly implemented terminology services can make it hard to locate appropriate concepts, distracting, and frustrating health professionals as they struggle to enter notes. The end result is likely to be incomplete records or inaccurate recording due to the inability to find the correct concept. In contrast, well-designed terminology services used effectively by healthcare applications facilitate rapid and accurate entry of clinical data. This not only assists the delivery of patient care but also provides a valuable source of information for communication, reporting, and valuable analysis.
Terminology services that enable rapid searches for concepts in relevant areas of the SNOMED CT hierarchy are a key factor in facilitating accurate data entry and minimizing the risk of errors. When creating task-oriented forms or templates for data entry it is even more important to use search techniques that pinpoint the correct concepts, because any errors in a template will inevitably be duplicated by records created using that template.
Terminology services also need to support data retrieval for retrieval, analysis, and decision support. This requires terminology services that can examine the definition of a concept and determine if it meets the criteria specified in a query or expression constraint. A terminology service that supports rapid evaluation of these types of queries can be a key factor in facilitating the delivery of essential reports and valuable analytics.
Most end-users are unlikely to have a direct role in the development or selection of terminology services. However, those who are involved in designing, procuring, and implementing these services should recognize the importance of ensuring a positive end-user experience for people whose day-to-day work requires frequent access to SNOMED CT.
Organizations procuring applications that require access to SNOMED CT should carefully evaluate the way that the application provides access to terminology content and features. This evaluation should consider practical usability and also the flexibility of the underlying design. It should also consider the context of the existing technical architecture, as this will drive the type of service being procured.
To facilitate the assessment of the way an application interacts with SNOMED CT, the following steps are recommended:
Identify user activities that involve interaction with the terminology
It may be helpful to refer to the list of use cases in to assist the identification of specific activities that are relevant to the application being procured
Identify groups of users that regularly undertake each of the identified activities
Another important point to consider when procuring a solution that requires access to SNOMED CT. is the way (or ways) in which the solution provides access to the terminology. A solution may include built-in terminology services, it may provide an interface to terminology services from a specific provider, or it may offer options to use terminology services from different providers who support a common interface. The table below outlines the advantages and disadvantages of each of these options from the perspective of a procuring organization.
Request representatives of the affected groups of users to assist with the evaluation of those activities
Those involved in this evaluation may find it useful to refer to the use cases in and the specific service requirements which may suggest a particular factor underlying any issues they experience
Application includes built-in functions for the terminology services it requires
Integrated solution without external dependencies
Potential for optimization of specific terminology services needed by the application
Single source for support
Dependent on the quality of the application provider's solution and its future maintenance
No option to select an enhanced set of terminology services from a specialist provider
Risk of non-alignment between SNOMED CT editions/versions in terminology services used by different applications
Application uses terminology services provided by the same organization but independent from the application
Purpose-built solution matched to the application
Single source for support
Potential for reuse of terminology services by other applications
Dependent on the quality of the application provider's terminology services and its future maintenance
No option to select an enhanced set of terminology services from a specialist provider
Option for other applications to use the services is limited to those able to use the interface provided by the application vendor
Risk of non-alignment between SNOMED CT editions/versions in terminology services used by different applications
Application uses terminology services provided by a specified third party
Application provider is responsible for maintaining compatibility of their application with the chosen terminology services interface
Potential for reuse of terminology services by other applications
Dependent on the quality of the specified terminology services and its future maintenance
Option for other applications to use the services is limited to those able to use the interface provided by the chosen terminology services
Risk of non-alignment between SNOMED CT editions/versions in terminology services used by different applications
Application supports use of terminology services that offer an interface that conforms to a published specification
Application provider is responsible for maintaining compatibility of their application with the chosen terminology services interface
Choice of terminology services may allow reuse of terminology services already used in the organization
Choice of terminology services may allow migration to enhanced terminology services offered by a different provider
Future options for reuse of terminology services by other applications that support the same published interface specification
Future options to switch to another provider of terminology services that conform to the same published interface specification
Possible differences in performance, functionality, and results between different implementations of a chosen terminology services interface
Separate support arrangement for terminology services may make responsibility for errors or performance issues less clear
Option for other applications to use the services may be limited by the chosen interface specification
Application configurable to support use of a specified range of terminology services
Application provider is responsible for maintaining compatibility of their application with the chosen terminology services interfaces
Choice of terminology services may allow the reuse of terminology services already used in the organization
Choice of terminology services may allow migration to enhanced terminology services offered by a different provider
Future options for the reuse of terminology services by other applications that support the same published interface specification
Future options to switch to another provider of terminology services that conform to the same published interface specification
Separate support arrangement for terminology services may make responsibility for errors or performance issues less clear
Option for other applications to use the services may be limited by the chosen interface specification
Application providers should refer to the following sections of this guide for statements of terminology service requirements that need to be met for effective access to SNOMED CT.
Which notes user requirements for high performance services that provide appropriate access to SNOMED CT.
Which describes specific terminology services or functions that are required to enable effective use of SNOMED CT
Which 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.
As noted in the following section, these requirements can be met either directly by the application or by use of SNOMED CT terminology services accessed through an API.
Applications that require access to SNOMED CT are direct users of SNOMED CT terminology services. Organizations that design, develop, supply and support those applications can enable access to SNOMED CT in several different ways. The main options are identified in the table below with notes on the advantages and disadvantages of each option from the perspective of the application provider.
The first two options shown in the table require the application provider to also develop and maintain terminology services. Application providers considering those options should also take a look at the notes on the Terminology Services Provider Role.
Application uses terminology services provided by a specified third party
No need to build or maintain terminology services.
Less burden to track SNOMED CT developments (managed by server).
Less responsibility for managing edition/version access.
Must support application integration with chosen third-party terminology services.
External dependency on the third-party provider.
Risk of support conflicts between application and terminology server.
Application supports use of terminology services that offer an interface that conforms to a published specification
No need to build or maintain terminology services.
Less responsibility for SNOMED CT updates or edition/version management.
May appeal to organizations using that interface.
Must support interface integration with third-party services.
Performance or result variability across implementations using the same interface.
External dependency for support.
Application configurable to support use of a specified range of terminology services
No need to build or maintain terminology services.
Less burden to follow SNOMED CT changes (server responsibility).
May appeal to organizations already using supported terminology services.
Must support multiple interfaces to third-party services.
Result inconsistency across supported terminology services.
External dependency on terminology service providers.
Application includes built-in functions for the terminology services it requires
Integrated approach may simplify installation.
No external dependency on third parties for supply or support of terminology service.
Application provider must create, maintain, and support terminology services.
Must keep pace with changes to SNOMED CT that affect user requirements.
Must enable access to appropriate SNOMED CT edition versions for each customer.
May be less attractive to organizations already using a terminology server.
Application uses a defined interface to terminology services provided by the same organization
Purpose-built terminology server matched to application requirements.
No external dependency on third parties.
Potential to license terminology services for use with other applications.
Must create, maintain, and support terminology services.
Must keep up with terminology changes affecting user requirements.
Must ensure customer access to correct SNOMED CT editions.
May be less attractive to organizations using a different terminology server.
Risk of stagnation if the server doesn't evolve to meet application needs.
Development may be limited by server responsiveness to SNOMED CT changes.
This chapter defines SNOMED CT terminology services, and it describes the general terminology service categories. Furthermore, it presents three key roles with an interest in SNOMED CT terminology services including end-users and those involved in the procurement of healthcare applications.
SNOMED CT terminology services are defined as a set of software functions that interface with and provide effective access to the content and features of one or more SNOMED CT editions.
Each terminology service is a software function that interfaces with and provides access to information from one or more representations of a terminology.
The software application that provides SNOMED CT terminology services is known as a SNOMED CT terminology server.
While terminology services may be applicable to several different terminologies, applications that provide SNOMED CT terminology services, should support access to the specific design features of SNOMED CT. These include the subtype hierarchy, description logic concept definitions, reference sets and expression constraints.
Find a concept based on a set of search criteria. The criteria may include text to be matched against terms associated with the concept and constraints requiring a concept to be a subtype of an identified concept or a member of an identified reference set.
Show the preferred term associated with an identified concept.