Terminology Service Categories
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?
Access Requirements
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.
Terminology Access Requirements
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.
The image below illustrates the association between the different types of terminology services and record services.
User Interface Requirements
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 Terminology Service Use Cases notes the need for combinations of the terminology services identified in Terminology Service Types 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.
User Interface Inclusion
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
Terminology Service Category Examples
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 Access
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.
Add-Update Access
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.
Last updated