Collection: Implementation Strategy

Summary: A National Terminology Server is both a technical tool and a strategic asset. It should be the single source of truth for terminologies, support direct use by simple apps, and allow larger systems to host local copies for better performance. This allows for keeping national and local content separated, provides a public sandbox to support learning and testing, and follows a regular release schedule, ensuring everyone stays aligned.

Implementation dilemma

Facilitating access to the terminology is a key element of any implementation strategy. A National Terminology Server (NTS) is a centrally operated standards-based service that houses authoritative, version-controlled copies of SNOMED CT and other code systems, such as ICD-10 or drug dictionaries. It fulfils three complementary roles:

1. Distribution – publishes every official release, reference set, and map through an automated syndication feed, providing a better alternative to manual downloads and ensuring all stakeholders consume identical content.

2. Real-time terminology services – the NTS exposes a standard API, usually based on HL7 FHIR, using the $expand, $lookup, $validate-code, $translate and $subsumes operations so that client systems can resolve codes, value sets, and cross-maps on demand.

3. Capacity-building – provides an open sandbox, training guides, and connectathon environments that lower the barrier to entry for implementers.

Because network latency and high query volumes can affect clinical performance, most production EHRs cache the national content in a local Terminology Server instance while still subscribing to the NTS feed for incremental updates.

It is essential to consider all of these functions and requirements when defining a comprehensive National Terminology Server (NTS) strategy.

Secure terminology distribution portals, such as SNOMED International's MLDS (Member Licensing and Distribution System), play a key role in managing the licensing submission and approval process.

However, the functions of manually downloading RF2 zip files on secure portals can be significantly improved by implementing an NTS, streamlining terminology server setup, facilitating updates, and preventing version mismatches. This is why, since 2023, MLDS has incorporated terminology syndication features.

Other modern NTS platforms (e.g., NHS England’s Terminology Server, the Australian National Clinical Terminology Service, and Canada Health Infoway’s new FHIR server) also publish machine-readable releases via REST APIs or syndicated S3 buckets, enabling vendors to script and automate the ingestion process.

Additionally, an NTS can serve as a lightweight or early-stage clinical application that requires access to the terminology. For example, a public vaccination portal might validate incoming SNOMED CT codes directly against the national endpoint without hosting its own server. Meanwhile, large hospital networks typically mirror the content locally, deploying a very fast local Terminology Server that synchronizes content from the National Terminology Server.

To learn more, please reach out to implementation@snomed.org.

Collection: Technology adoption

Summary: Yes, SMART Apps are an effective way to add SNOMED CT support to an EHR, offering flexible, user-friendly interfaces for data entry and clinical decision support. They leverage FHIR APIs and can integrate with FHIR-based terminology services to fetch SNOMED CT codes dynamically, enabling seamless and standardized data capture without requiring major changes to the EHR's core system.

Technology use case

Adding SNOMED CT support for data capture in existing medical record systems can be challenging, primarily due to limitations such as rigid data models, lack of interoperability features, and inflexible user interfaces imposed by the original system design.

The best practice for implementing SNOMED CT is to use FHIR-based terminology servers, which offer greater flexibility for designing user interfaces that utilize specific, dynamic value sets of SNOMED CT. However, adding support for terminology servers may require significant changes to a clinical application's terminology capabilities. As a result, developers may seek alternative solutions that provide the flexibility needed to create customized user interfaces.

SMART on FHIR (Substitutable Medical Applications, Reusable Technologies) is a standard developed by the SMART Health IT project. This standard provides an easier way to connect third-party apps to existing electronic health records (EHRs). SMART apps are web or mobile applications that use the SMART on FHIR standard to integrate with EHR systems seamlessly. These apps can be used for various purposes, such as data entry, clinical decision support, or patient engagement. For example, a SMART app could help clinicians easily document allergies by providing an intuitive interface that contains the necessary fields to describe all the allergy details precisely and pulls relevant SNOMED CT codes to enable a quick selection, ensuring accurate and standardized data capture.

Another example of how SMART apps can enhance clinical workflows is summarizing clinical information based on SNOMED CT codes. For instance, a SMART app could analyze a patient's medical records, extract key SNOMED CT-coded data, and present a summary of relevant clinical details, such as current conditions, previous diagnoses, and ongoing treatments. This summary can help clinicians quickly review essential patient information at the point of care, improving efficiency and supporting better decision-making.

SMART on FHIR apps communicate with EHR systems using the FHIR (Fast Healthcare Interoperability Resources) API. When a user interacts with a SMART app to capture SNOMED CT data, the app sends the data back to the EHR through the FHIR interface. This allows the captured information to be securely stored alongside the rest of the patient's medical records. The FHIR API supports various resource types, such as Observations, Conditions, and MedicationStatements, enabling the SMART app to structure and transmit the data in a standardized way. This ensures that data captured via the SMART app is properly integrated and accessible within the patient's overall health record. Using SMART apps, developers can overcome many challenges associated with modifying legacy systems and create customized user interfaces for data entry.

One key advantage of SMART on FHIR is the ability to share and reuse apps across different EHR systems. This reduces development time and simplifies the creation of user interfaces for SNOMED CT data entry, as developers can leverage existing solutions rather than building custom tools from scratch. Reusing SMART apps ensures consistency, improves interoperability, and allows healthcare organizations to benefit from a growing ecosystem of proven applications.

It is important to differentiate data entry linked to basic building blocks of the clinical information model and data entry intended to collect detailed clinical information about a particular event or situation.

SMART Apps are a great solution for customized data entry interfaces if your system already supports SMART on FHIR.

Basic data entry user interfaces for diagnosis, problems, or procedures are usually better served by a native solution of the EHR system, preferably relying on a FHIR terminology service.

A good example is the previously mentioned Allergy recording SMART App. If a system does not have a dedicated UI for capturing allergy details, deploying the SMART App provides a very simple and fast solution that ensures the use of a validated and standardized model. Some development effort is necessary to integrate the data returned by the SMART App with the EHR information, and this is simplified by the use of standard data structures, like FHIR resources.

There is a list of EHR providers that already include support for SMART Apps and other SMART standards out of the box. For compatible EHRs, using SMART Apps can provide significant advantages in integrating SNOMED CT data entry seamlessly.

However, adding SMART on FHIR support to an EHR that currently lacks it can be complex, akin to incorporating native SNOMED terminology services. This process often involves substantial changes to the system's architecture, such as updating APIs, integrating FHIR capabilities, and ensuring compliance with data standards. Organizations considering this approach should carefully evaluate the benefits of improved interoperability and flexibility against the resources required for implementation.

• Leverage SMART on FHIR Apps: SMART on FHIR can provide a practical solution for integrating SNOMED CT. By creating a standalone SMART app that connects to the EHR, you can design a user-friendly, flexible data entry interface without directly modifying the core EHR system. This approach allows you to use SNOMED CT for clinical data capture in a way that is decoupled from the limitations of the original system.

• Use FHIR Terminology Services: For optimal use of SNOMED CT, consider combining SMART apps with FHIR-based terminology services. These servers can dynamically provide value sets that align with specific clinical workflows, which means that your SMART app can fetch relevant SNOMED CT codes in real-time. This allows you to enhance data quality and accuracy in a flexible manner dn without the need to modify the native EHR architecture.

• Differentiate UI Designs for Specific Use Cases: When implementing SNOMED CT data entry through SMART apps, consider the different types of user interfaces needed for various clinical contexts. For example, generic clinical coding in progress notes or problem lists may benefit from a streamlined interface that allows for rapid data entry, or it may even be better served by a native SNOMED lookup function based on a database search. On the other hand, specialized UIs are often required for areas like allergy documentation, cancer reporting, or other specific clinical domains where tailored data capture is necessary. Designing UIs that fit the unique requirements of these specialized workflows will improve usability and data quality.

1. SMART Standards and Specs:

2. Example: Allergy FHIR Resource:

3. Who is using SMART?

To learn more, please reach out to implementation@snomed.org.

Collection: Implementation dilemmas

Summary: No, the best practice recommendation is to avoid depending on priority subsets for user data entry. Concept selection should ideally be restricted only by domain, and all the SNOMED concepts within the acceptable range for the field should be available to the clinical users. This approach provides greater detail and benefits from frequent updates in SNOMED content.

Implementation dilemma

One of the first use cases in clinical implementations of SNOMED CT is to record clinical problems, diagnoses, or reasons for encounters. When defining the rules for which SNOMED concepts can be used in these use cases, some implementers face the question of whether it is better to define wide terminology bindings, including all SNOMED options for these domains, or to create a "priority subset", a smaller selection of relevant concepts according to some criteria or previous experience. The benefits pursued by creating a subset may include a simpler integration of smaller lists in legacy systems or facilitating user entry by offering a smaller set of terms.

Advice

As a general approach, it is preferable to avoid depending on manually enumerating a subset for user data entry. Concept selection should ideally be restricted only by domain, and all the SNOMED concepts within the acceptable range for the field should be available to the clinical users. The Expressions Constraint Language (ECL) provides functions for implementers to restrict data entry domains to relevant content.

Restricting the list of relevant concepts by frequency of use or priority is not recommended, as it limits clinical users' expressivity and prevents them from taking advantage of the constant content updates in the terminology. Also, current trends like precision medicine and genomics require a high level of detail in data capture, recording very specific clinical assertions and rare diseases.

Instead, it is recommended that best practice search features applied by the systems support rapid searching across all available concepts within a predefined domain. Terminology servers and search engines can use frequency of use or priority in their sorting algorithms to boost the visibility of certain concepts while maintaining full access to the complete set of concepts relevant to the field.

There are some situations where SNOMED needs to be incorporated into an application that is not compatible with the complete SNOMED CT Edition content. The application may only support importing code systems as plain lists of concepts with a code and a term and uses limited search capabilities. In these situations, extracting a subset of SNOMED CT as a plain list is acceptable. However, using a subset restricts the expressivity of clinical users when selecting SNOMED concepts; therefore, in the long term, it is advisable to upgrade the application to support FHIR terminology services or any other technologies to provide access to the complete SNOMED CT content. Some commonly used sources for frequency-based concept selections are usually derived from the original work in the NLM CORE Subset in the US, resulting from the contribution of frequency of use in seven big healthcare institutions. This resource was used for the initial selection of concepts for the SNOMED IPS Refset and the IPS Terminology; these are also relevant sources of subset selections.

• Focus on creating the best possible terminology bindings: use value sets or ECL (the Expressions Constraint Language)1 to ensure that only acceptable concepts are available for data entry.

• Use a terminology server for out-of-the-box best-practice text-matching algorithms or implement these algorithms locally

• Train clinical users on how the multiple prefixes, no order, string matching technique works.

1. Expression Constraints Language Guide:

2. NLM Core Subset:

3. International Patient Summary Terminology User Guide:

To learn more, please reach out to implementation@snomed.org.

A SNOMED CT Fact Sheet is a short, focused document that addresses a specific implementation challenge or use case. It outlines the core problem and presents a clear, actionable solution, making it easier for implementers to understand and apply best practices in real-world settings.

Each fact sheet is designed to:

• Identify a particular implementation issue or decision point

• Present a concise, best-practice solution

• Be quick to read, easy to reference, and practical to apply

Collection: Technology adoption

Summary: Yes, multiple SNOMED APIs are available to provide access to terminology services for health information systems. These local or hosted APIs enable developers to integrate SNOMED CT into their applications, ensuring consistent and standardized use of medical terminology.

Technology use case

An API (Application Programming Interface) is a set of rules and protocols that allows different software applications to communicate with each other. In the context of a terminology service, an API acts as the interface through which developers can access and use the features of the terminology service, such as searching for medical terms, retrieving definitions, or managing subsets of terminology data. This interface allows external systems to interact seamlessly with the terminology service without needing to understand its internal workings, thereby enabling integration and interoperability.

Using terminology services¹ is essential for health information systems because it enables standardized communication between different systems and applications. Modern terminologies are updated frequently, utilize complex data representations, and require advanced indexing mechanisms to support real-time responses.

Utilizing terminology services represents a good separation of concerns, allowing the terminology server to handle terminology management while enabling other components of an application to focus on their core responsibilities, such as recording and displaying clinical data and supporting clinical workflows. This makes systems more modular, flexible, and maintainable.

SNOMED-specific terminology servers^, provide advanced functionalities for browsing, searching, and retrieving SNOMED CT concepts, ensuring compatibility with SNOMED query languages like ECL (Expression Constraint Language). These servers help systems take full advantage of the advanced features of SNOMED CT and provide tools for managing SNOMED extensions, subsets, and mappings.

Terminology servers with SNOMED-specific support may also be compatible with the SNOMED Syndication standard, allowing for automatically updating the terminology by subscribing to a content feed.

The FHIR Terminology Module provides a standardized way to access any terminology or classification, and includes all the necessary parameters to support SNOMED content. Systems integrating with a terminology server using a FHIR API can easily swap one terminology server for another, avoiding vendor lock-in.

Local APIs are typically hosted within an organization's infrastructure and provide quick, secure access to terminology services. They are well-suited for use cases where data privacy and low latency are priorities. Hosted APIs, on the other hand, are hosted by external providers and are useful for organizations without the resources to maintain their own terminology servers. Hosted APIs are provided as a service with various security characteristics and service-level agreements.

Using a terminology server is the recommended best practice as it centralizes terminology management and ensures consistent access across all systems.

Using the FHIR API provides significant flexibility by offering a standardized protocol for interacting with terminologies, making switching or upgrading terminology servers easier without requiring major changes to the existing system. This flexibility helps future-proof your application and allows for seamless integration of additional terminologies when needed.

If you have the resources and technical capability, hosting your own API is ideal, as it gives full control over configuration, security, and performance. However, for organizations without in-house expertise, partnering with a trusted vendor to host the SNOMED API can simplify implementation and maintenance. Vendors often provide additional support, regular updates, and service level guarantees that can be beneficial in clinical environments.

When choosing whether to use an open-source or commercial server solution to deploy a local API, weighing the pros and cons is important. Open-source solutions offer greater customization and cost-effectiveness, while commercial solutions provide dedicated support and stability. Organizations must consider their internal capabilities, the level of customization required, and the importance of vendor support to determine the best approach.

SNOMED International makes available a public training API:

This API is intended for testing purposes, providing access to SNOMED CT using the FHIR Terminology Module resources and operations. However, it should not be used in a production environment or for real clinical data entry. The server does not guarantee uptime or latency, may undergo maintenance without prior notice, and is actively monitored to limit usage to simple test requests. Users and IP addresses may be blocked to prevent abuse.

• Use a Terminology Server: Utilize a dedicated terminology server to centralize terminology management and ensure consistent access across all systems.

• Leverage FHIR API: Use the FHIR API to gain flexibility, making switching or upgrading terminology servers easier without major system changes.

• Host Your Own API if Possible: If resources allow, host your own API to gain full control over configuration, security, and performance.

1. Rector, Alan L., et al. "A terminology server for medical language and medical information systems." Methods of information in medicine 34.01/02 (1995): 147-157.

2. Snowstorm, an Open Source terminology server:

3. Metke-Jimenez, Alejandro, et al. "Ontoserver: a syndicated terminology server." Journal of Biomedical Semantics 9 (2018): 1-10.

To learn more, please reach out to implementation@snomed.org.

Collection: Technology adoption

Summary: Yes, SNOMED CT supports interoperable CDS systems by leveraging intensional Value Sets and ECL to dynamically define clinical criteria while using SMART Guidelines and CQL to translate clinical knowledge into actionable, machine-readable formats.

Technology use case

Developing effective Clinical Decision Support (CDS) systems requires rules that are reusable, shareable, and maintainable. Healthcare organizations often struggle to achieve consistency across multiple systems while ensuring that the CDS rules remain up-to-date with evolving clinical knowledge. Creating such rules manually is resource-intensive and risks inconsistency, making it challenging to achieve scalable, interoperable solutions.

What Is a CDS System and Why Is It Important?

A Clinical Decision Support (CDS) system is a health information technology system designed to assist healthcare providers in making informed clinical decisions. CDS systems provide clinicians with patient-specific assessments or recommendations based on clinical guidelines, evidence-based practices, or patient data. By integrating CDS systems into healthcare workflows, providers can enhance the quality of care, reduce errors, improve efficiency, and ensure adherence to clinical standards. CDS systems are crucial for supporting complex decision-making, reducing variability in care, and improving patient outcomes.

What Are SMART Guidelines?

SMART Guidelines is a set of best practices and standards that help translate clinical guidelines into machine-readable formats that can be easily implemented in electronic health records (EHRs) or other digital systems. SMART Guidelines enable the integration of clinical evidence into workflows, making it easier to apply standardized healthcare practices across different environments.

The concept of SMART Guidelines was introduced by the World Health Organization (WHO) as part of their effort to transform traditional, text-based guidelines into digital, actionable tools that can be integrated into health information systems. The goal was to create a more efficient way for healthcare providers to access and use clinical guidance at the point of care, leading to improved health outcomes. SMART Guidelines have gained traction as the need for interoperable, standards-based health IT solutions has become increasingly important in global health settings.

Clinical Quality Language (CQL) is a high-level language designed to express clinical knowledge in a way that is human-readable and executable by machines. CQL is often used to write CDS rules and clinical quality measures, enabling consistent and scalable decision-making across health systems. By using a standardized language like CQL, clinicians and developers can ensure that their CDS rules are interoperable, more easily maintained, and adaptable to changes.

CQL was developed by the Health Level Seven International (HL7) organization as a part of their Clinical Quality Framework initiative. The need for CQL arose from the desire to create a unified language that could express clinical quality measures and decision-support logic in a standardized format. Since its introduction, CQL has become a widely adopted language for expressing computable clinical knowledge, making it easier to share, reuse, and implement clinical decision support across different health IT systems.

CQL is also closely related to SMART Guidelines, as it provides the machine-readable language needed to encode the clinical decision logic derived from these guidelines. By using CQL in conjunction with SMART Guidelines, healthcare organizations can create adaptive and automated decision support that aligns with standardized, evidence-based practices. This synergy ensures that clinical guidelines are consistently translated into actionable decision-support rules, enhancing the quality and efficiency of care.

SNOMED CT plays a fundamental role in providing the terminology underpinnings of reusable and maintainable CDS rules, ensuring that clinical concepts are represented consistently and accurately. Value sets are collections of SNOMED CT concepts used to define clinical criteria, and their use enhances the maintainability of CDS rules by standardizing the clinical data used in decision-making. By utilizing SNOMED CT, CDS rules are grounded in a globally recognized terminology system, which supports interoperability and ensures that clinical logic can be shared across different systems.

Intensional value sets that are automatically updated can take full advantage of SNOMED CT's hierarchies, reference sets, and attributes, ensuring that Clinical Decision Support Systems (CDSS) stay up-to-date as clinical standards change. SNOMED CT hierarchies allow for the efficient selection of all descendants of a concept, enabling flexible yet precise definitions of clinical criteria. Reference sets (refsets) provide pre-curated collections of SNOMED CT concepts that can be reused across various clinical scenarios. At the same time, attributes allow for detailed refinement of these concepts, increasing the specificity of value sets. The Expression Constraint Language (ECL) provides a structured syntax to define these dynamic value sets, leveraging SNOMED CT's rich structure for creating, maintaining, and updating clinical decision support in a scalable and efficient manner. SNOMED CT hierarchies allow for the selection of all descendants of a concept, enabling broad yet precise definitions of clinical criteria. Reference sets (refsets) provide curated collections of SNOMED CT concepts that can be reused across different use cases, while attributes allow for more detailed refinement of concepts, enhancing the specificity of value sets. This approach helps ensure that CDSS are always aligned with the most current clinical knowledge and standards.

Many FHIR servers support the execution of CQL-based CDS rules, providing a standardized platform for implementing clinical decision support logic. HAPI FHIR server is one such example that supports these capabilities. By integrating a HAPI FHIR server into the workflow, organizations can automate the retrieval of SNOMED CT concepts using dynamic value sets, ensuring that the CQL-based logic references the most current clinical knowledge. This approach significantly reduces the burden of manual updates and enhances the scalability of clinical decision-making processes, leading to consistent and reliable care.

• Leverage Intensional Value Sets: Use intensional value sets to define clinical criteria dynamically. This allows you to take advantage of SNOMED CT's hierarchies, attributes, and reference sets, enabling automated updates and minimizing manual maintenance.

• Utilize Expression Constraint Language (ECL): Use ECL to define value sets in a flexible and structured manner. This ensures that the defined sets are consistent and precise, supporting effective and reliable clinical decision-making.

• Integrate with FHIR Servers: Deploy a FHIR server, such as HAPI FHIR, to facilitate the execution of CQL-based logic. This will help automate the retrieval and application of SNOMED CT concepts, ensuring your clinical decision support system remains up-to-date.

1. Smart Guidelines:

2. WHO SMART guidelines: optimizing country-level use of guideline recommendations in the digital age. Mehl, Garrett, et al. The Lancet Digital Health, Volume 3, Issue 4, e213 - e216

3. HL7 - CQL Language:

To learn more, please reach out to implementation@snomed.org.

Collection: Implementation dilemma

Summary: No, as general advice, excluding groupers from clinical data entry is not necessary. The effort of manually identifying groupers and maintaining the list updated over time is considerable, and a best practice search and data entry implementation effectively prevents the selection of general clinical terms. \

Implementation dilemma

SNOMED hierarchies include grouper concepts that support the aggregation of clinical concepts in multiple ways, including analytics, reporting, and clinical decision-support use cases. At the moment of clinical data entry, some implementers wonder if these concepts should be excluded from the options that the clinician can select.

When creating small, manually curated sets of concepts for options in clinical data entry, implementers will always exclude any unnecessary concepts, and non-clinical groupers will never be selected to be included. However, the dilemma appears when the implementer designs a data entry set for a field with a large set of values, for example, "all clinical findings". In these cases, the identification of the non-clinical groupers to exclude becomes a challenge.

Advice

The first challenge for removing grouper from the search is identifying which concepts represent groupers with less clinical value. This will depend on the context and the clinical user. In some contexts, it is appropriate to record clinical content using more general concepts, like when recording old events where the patient does not have an exact recollection of the clinical details ("I had surgery for an abdominal infection") or when the final diagnosis is not yet confirmed. Still, the clinician wants to record a general idea of the probable one("metabolic disorder"). Also, the level of detail required will differ depending on the specialty; a nurse, a family physician, a surgeon, or an endocrinologist may have different views of the same clinical entities. The specialist requires very detailed concepts inside their specialty but very little detail for anything else outside it.

The lack of a universal definition of what a grouper is has resulted in the fact that groupers are not identified in SNOMED CT, so any effort to remove them from the search will require a manual curation of the concepts to create exclusions refsets or value sets (Figure 1). These exclusion lists would need to be constantly updated with new SNOMED releases.

Figure 1: Example of possible grouper concepts, depending on the context

The concern about the groupers is based on the idea that the clinician may have detailed clinical information that is not recorded because a more general grouper concept appears first in the search results. This highlights the importance of implementing effective search and sorting algorithms. Best practice recommendations, implemented in most common terminology servers, provide mechanisms to prevent that. The most relevant one may be the multi-prefix search strategy ("ac myo inf"), which facilitates the inclusion of multiple words in the search string with only a few keystrokes. This refines the search, including detailed concepts in the results, when most groupers fail to match the search string.

As general advice, excluding groupers from clinical data entry is not necessary when using large search sets. The effort of manually identifying groupers and maintaining the list updated over time is considerable, and a best practice search and data entry implementation effectively prevents the selection of general clinical terms.

• Focus on creating the best possible terminology bindings: use value sets or ECL (the Expressions Constraint Language) to ensure that only acceptable concepts are available for data entry.

• Use a terminology server for out-of-the-box best-practice text-matching algorithms or implement these algorithms locally.^,

• Train clinical users on how the multiple prefixes, no order, string matching technique works.

1. Search and Data Entry Guide: Optimizing searches:

2. Expression Constraints Language Guide:

3. SNOMED Terminology Services:

To learn more, please reach out to implementation@snomed.org.

Collection: Implementation dilemmas

Summary: No, as a general approach, SNOMED CT does not require an external interface terminology to be implemented in clinical settings. SNOMED CT descriptions function as interface terminology, and clinical projects in member countries submit requirements and updates to improve this resource's quality continuously.

Implementation dilemma

Some SNOMED CT implementers consider whether it is necessary to use an external interface terminology, i.e., a list of clinical terms specially designed to facilitate data entry. Each term would be mapped to SNOMED CT. The goal of using custom interface terminology is to have more control over the terms presented to the user, intending to provide a better fit for the local context.

What's an external interface terminology?

Custom interface terminologies offer a separate set of terms that can match user search strings and are directly mapped to SNOMED concepts. These custom terminologies can include terms that do not adhere strictly to SNOMED naming conventions, such as local terms, jargon, typos, etc. Maintaining a custom interface terminology requires great effort and dedication to keep current and ensure the best quality.

To what extent is a custom interface terminology required when integrating SNOMED CT into clinical systems?

The recommended approach in modern SNOMED CT implementations is to use SNOMED descriptions as the interface terminology.

The separation of "interface" and "reference" terminology roles has been reviewed in many articles, where the interface terminology is used to collect information, and the Reference Terminology is used to represent the information with the greatest possible level of detail and its relationships to other concepts. An antecedent version of SNOMED from 1997 was denominated SNOMED RT (Reference Terminology), describing the intended role of that version of the terminology. However, the next generation of SNOMED terminologies, the one we use today, was released in 2001 and includes specially designed interface terminology functions.

Today, SNOMED CT is implemented worldwide using its native interface terminology features for data entry without requiring an external interface terminology. The June 2024 International Edition contains 1.6 million active descriptions for 368,000 active concepts, averaging 4.4 descriptions per concept. SNOMED terms have a clinical level of detail, including wording as submitted by clinicians in member countries. Members and affiliates can add additional terms as required in national or local extensions. Using best practice text matching algorithms supports partial matching and meaningful sorting, which facilitates clinicians' search by parts of clinical terms. The best matches are properly shown first in the results, facilitating identification and selection.

Clinicians can search for SNOMED CT concepts using text searches that match the descriptions provided in the International Edition or any SNOMED Extension.

Table 1: Example of native SNOMED CT interface terminology features

Custom interface terminologies are usually incomplete and map only to a part of SNOMED CT. They are challenging to maintain and keep up to date with new SNOMED versions, with risks of quality issues like duplication and ambiguity. Users who access SNOMED content through interface terminology will experience the continuous improvements and enhancements published monthly in SNOMED releases only when those are reflected in the custom terminology. The SNOMED release is prepared to be imported into standard terminology servers supporting effective search engines. Maintaining additional synonyms as part of an extension of SNOMED CT provides many benefits for seamless integration with SNOMED updates and integrations in clinical systems.

Local or custom interface terminologies can play a role in migrating systems to SNOMED CT. Some systems may need more flexibility to incorporate full use of standard terminology services, or the clinical user base could be inclined to continue coding with a local set of terms. However, it is recommended that this be an interim solution until the system is upgraded to support full access to SNOMED CT content directly, unlocking the complete breadth of content in SNOMED CT for data entry.

Modern SNOMED CT is a global collaborative terminology system with over 50 member countries actively contributing to its development. These countries prioritize development areas, submit new content, and shape a unified health language. Accessing SNOMED CT content solely through an external interface terminology will restrict access to continually updated content and ongoing improvements.

• Focus on creating the best possible terminology bindings: use value sets or ECL (the Expressions Constraint Language) to ensure that only the right concepts are available for data entry

• Use a terminology server for out-of-the-box best-practice text-matching algorithms or implement these algorithms locally

• Train clinical users on how the multiple prefixes, no order, string matching technique works.

1. Rosenbloom ST, Miller RA, Johnson KB, Elkin PL, Brown SH. Interface terminologies: facilitating direct entry of clinical data into electronic health record systems. J Am Med Inform Assoc. 2006 May-Jun;13(3):277-88. doi: 10.1197/jamia.M1957. Epub 2006 Feb 24. PMID: 16501181; PMCID: PMC1513664.

2. SNOMED Release Statistics:

To learn more, please reach out to implementation@snomed.org.