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
Table 2.2-1 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. Figure 2.2-1 illustrates the association between the different types of terminology services and record services.
Table 2.2-1: Terminology Access Requirements
| Characteristic | Description | Additional Notes |
| 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. |
Figure 2.2-1: Examples of Terminology services and Record services and their associations.
User Interface Requirements
Table 2.2-2 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 Table 2.2-2. Section 3 Terminology Service Use Cases notes the need for combinations of the terminology services identified in 4 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 guide1.
Table 2.2-2: User Interface Inclusion
| Characteristic | Description | Additional Notes |
| 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 user interface. They limit dependency on a specific terminology service provider as services without a user interface have less variability and are more likely to share include 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 user interface controls to fully functioning tools that enable viewing or editing the terminology. User interface controls included as part of terminology service may facilitate more rapid development. They may be particularly useful in cases where a client application has limited requirements for searching and displaying SNOMED CT content. Examples:
|
Examples
Table 2.2-3 provides examples of services in each of the four categories defined by applying the terminology access and user interface criteria identified in 104497357.
Table 2.2-3: Terminology Service Category Examples
| Terminology Access | User Interface | Examples |
Read-Only | No UI | Get details of a concept with a specified concept id. |
| Get sets of concepts that match term search criteria and/or expression constraints. | ||
| Get reference set data related to a concept or description. Including, subset membership, description acceptability in a specified language, maps to other terminologies, and access to terminology history data. | ||
| Test which of a set of concepts and/or expressions is subsumed by a specified concept or expression constraint. | ||
| UI | A SNOMED CT browser that enables exploration of the terminology and provides an API through which an application may set or read the results of user actions in the user interface. | |
a terminology bound user interface control is a list control that can be populated with a list of SNOMED CT concepts specified by membership of a reference set or conformance with an expression constraint. The API enables the list content criteria to be set and also allow user selections to be read. | ||
| Software tools that provide a user interface through which to analyze records that include SNOMED CT coded data. | ||
Add-Update | No UI | Create a new concept. |
| Add or modify axioms to enhance the definition of the concept. | ||
| Classify SNOMED CT content to add inferences based on stated defining axioms. | ||
| Add descriptions to a concept. | ||
| Inactivate a concept or description. | ||
| Create a new reference set of a particular type. | ||
| Add members to a reference set. | ||
| UI | SNOMED CT authoring tools that support the creation of concepts with appropriate sets of descriptions and formal axiom-based definitions. | |
| Tools that support the development and maintenance of subsets of concepts represented as simple reference sets. | ||
| Tools that support the creation and maintenance of SNOMED CT language translations, by enabling descriptions to be added and assigned acceptability settings in a language reference set. | ||
| Tools that support the development of maps between SNOMED CT and other terminologies, classifications, or code systems by enabling creation and maintenance of mapping reference sets. |
Footnotes
Many of the general use cases identified in 3 Terminology Service Use Cases can be met in different ways by different combinations of the terminology services detailed in 4 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.
Feedback
Overview
Content Tools
Apps