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 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 customers already using a different terminology server.
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.
Development limitations if the terminology server doesn’t evolve with SNOMED CT.
May be less attractive to organizations using a different 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.
Enables migration to alternate providers if current service is discontinued or inadequate.
Must support interface integration with third-party services.
Performance or result variability across implementations using the same interface.
External dependency for support.
Support conflicts possible (origin of issue unclear).
Risk of stagnation if the server doesn't evolve to meet application needs.
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.
Enables migration to other services if current one is discontinued or underperforms.
Must support multiple interfaces to third-party services.
Result inconsistency across supported terminology services.
External dependency on terminology service providers.
Support conflicts possible.
Development may be limited by server responsiveness to SNOMED CT changes.
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.
Healthcare Application Providers
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.
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:
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.
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