SNOMED International specifies and distributes a range of different reference set types as part of the International release of SNOMED CT. These types of reference sets have been specified to provide a foundation for the more general requirements that may arise when implementing/enabling SNOMED CT in clinical information systems.

Each reference set type is described in a machine-readable form that follows a specific reference set pattern. An overview of the different types of reference sets is provided in Appendix A: Overview of Reference Set Types and the technical specification for each of these types can be found in the Release File Specification Guide, section.

This guide will provide guidance to the usage of a selected set of reference set types. These reference set types are included in this guide, as they relate to the practical use of SNOMED CT content in clinical information systems. This includes:

• Simple Reference Set

• Query Specification Reference Set

• Ordered Component Reference Set

• Association Reference Set

• Ordered Association Reference Set

• Component Annotation Reference Set

• Member Annotation Reference Set

• Attribute Value Reference Set

• Language Reference Set

• Human-Readable Reference Set

For details about the general functionality of each of the reference set types included in this guide, please see the section related to each these reference sets.

Other types of reference sets, such as the and the set are important for the co-existence of SNOMED CT and other code systems, but are addressed in other guides. Some reference sets are used to hold metadata, which is used for management or maintenance purposes, such as the and the . These reference set types will not be covered in this guide.

The Simple reference set type represents an extensional definition of a subset of components. The components can be concepts, descriptions, relationships and reference sets. Therefore, the reference set contains a list of references to one or more components.

The components can be specified for inclusion or exclusion for a specified purpose. For example, the 450970008 | General Practice / Family Practice reference set| contains the concepts that are important for general practice and family practice medicine. In this section we will introduce the Simple type reference set format, the techniques for creation of simple reference sets and provide some examples of Simple reference sets and their usage.

Simple reference sets contain only the basic information needed to define a subset. As presented in the section about the , each member in a reference set has a referencedComponentId attribute, which is used to refer to the component that is a member of the reference set. Within the instances of this attribute, the individual references to components are stored. The diagram below illustrates an example of a simple reference set, and illustrates how the subset members are referenced in the referencedComponentId attribute.

The query specification type reference set is used to hold a series of queries used to represent the membership of a subset of SNOMED CT components.

A query contained in the reference set is run against the content of SNOMED CT (the substrate) to produce a subset of concepts, descriptions or relationships (the expansion). The query is referred to as an definition of the subset. It can be run against new releases of SNOMED CT to generate an updated set of subset members. Additionally, the members of the expansion may also be represented in an enumerated form as a . An enumerated representation of a subset is referred to as an definition of a subset. The diagram below illustrates the relation between the query specification reference set and the simple reference set. The intensional definition is represented in the 'query' attribute, and the identifier for the expansion's simple reference set is represented by the concept referenced in the 'referencedComponentId' attribute.

The two tables below illustrate the relationship between the query specification type reference set and the simple reference set. The referencedComponentId in the query specification type reference set references a concept which represent the simple type reference set, which is used to hold the expansion of the intensional definition.

The is the recommended language for specifying queries over SNOMED CT content. This language allows for a consistent and machine-readable representation of sets of clinical meanings. This means that a set of expression constraints can be used to specify the intensional definition of a range of subsets used in a particular context. The use cases for the subset generated from the queries within a query specification reference set are similar to the use cases for . However, the query specification reference set type can be used anywhere a set of queries needs to be managed.

The design of the ordered reference set supports two overall purposes:

1. Specifying a sequential order of a subset of components

2. Specifying prioritized groups within a subset of components

Ordered component reference set can be used to create a simple ordered list of components, i.e. a list that do not include any nesting, or groups. It can for example be used to prioritize the sort order of the descriptions with identical terms when they are displayed. It can also be used to specify the order of descriptions displayed in a simple pick list.

Prioritization is similar to order but multiple components may have the same rank. In this case the value of the order attribute specify a priority order for a group of components.

Specific reference set attributes used to build an alternative hierarchical view of SNOMED CT

The Association type reference set represents a set of unordered associations of a particular type between components, i.e. concepts, descriptions and relationships. The referencedComponentId references the source component of the association, whereas the reference set specific attribute, the targetComponentId, references the target component of the association.

Associations between components can be used to form groups of components, as illustrated in the diagram below. When using an association reference set to specify group, the sort order of the group members is not specified, as when using the Ordered type reference set.

Some situations may require components to be rendered in an alternative hierarchy than the polyhierarchy specified by the | is a | relationships in SNOMED CT. The diagram below Illustrates how the three attributes referencedComponentId, targetComponentId and order are used to create an alternative hierarchical order of some of the concepts from the subtype hierarchy.

Specific reference set attributes used to build an alternative hierarchical view of SNOMED CT

The Component Annotation Type Reference Set is dedicated to providing additional contextual information related to specific SNOMED CT components. This reference set type allows users to annotate SNOMED CT components such as concepts, descriptions, and relationships with supplementary details. Where the 900000000000521006 | Association type reference set| linked a SNOMED CT component to another SNOMED CT component, the Component Annotation Type Reference Set allows a SNOMED CT component to be associated with a wide variety of information.

The primary objective of Component Annotation Type Reference Sets is to offer insights that aid in the evaluation of changes made to SNOMED CT components. These annotations serve as valuable metadata, assisting in the understanding, implementation, and management of SNOMED CT content without impacting the classification of concepts. For instance, they can include details about the rationale behind a modification, usage guidance, or any other relevant information that enriches the understanding of the component's purpose and intended use.

One important use case for the SNOMED CT Component Annotation Type reference set, particularly regarding annotations to concepts, involves the application of attribution annotations, i.e. explaining where certain content comes from. This is helpful when different groups or organizations collaborate on the creation and maintenance of SNOMED CT content.

These annotations can include different types of information, such as hyperlinks or text in different languages. This variety of information helps to keep track of who contributed what and why. For example, web links can directly link to outside sources or contributor profiles, making things transparent and easy to follow. Supporting text in different languages helps people understand content better in different languages. These annotations are like a record book that helps keep track of contributions, encourages teamwork, and explains important details about SNOMED CT content. providing essential context for the content within SNOMED CT.

Besides from the identification and versioning attributes, the component annotation reference set type has following attributes.

The Member Annotation Type Reference Set provides the ability to supplement SNOMED CT reference set members with additional informative details. This reference set type enables the association of non-defining annotations with reference set members, providing valuable contextual information about each member's significance or usage.

The objective of Member Annotation Type Reference Sets is to enhance comprehension and implementation by offering supplementary information that aids in the interpretation and utilization of reference set members. These annotations are optional but highly beneficial, offering insights into the purpose, relevance, or specific usage scenarios of individual reference set members. For instance, these annotations might include notes about how a particular member should be used, clarifications on its scope, or any other pertinent details that facilitate effective utilization within diverse healthcare settings.

One significant use case for the Member Annotation Type Reference Set pertains to the representation and management of change notes related to content changes.

In SNOMED CT, a single concept might possess multiple axioms, which represent logical statements defining relationships between concepts. These axioms are represented as members of the OWL Axiom reference set.

By using change notes, content authors can add comments or explanations to each axiom, helping to explain why changes were made or providing additional context about the relationships defined by these axioms. This annotation method assists in keeping track of modifications, offering insights into the reasons behind changes, and aiding in understanding the logical structure of SNOMED CT concepts.

Besides from the identification and versioning attributes, the annotation reference set type has following attributes.

An attribute value reference set is a component reference set used to apply a tagged value to a SNOMED CT component. The pattern of the attribute value reference set is similar to that of the , despite the fact that the components referenced in the valueId attribute must be a subtype of the concept 900000000000491004 | Attribute value|, which include the concepts shown in the images below.

An 900000000000480006 | Attribute value type reference set| allows a value from a specified range to be associated with a component. This type of reference set can be use for a range of purposes where there is a requirement to provide additional information about particular concepts, descriptions or relationships. In the International Edition of SNOMED CT an 900000000000480006 | Attribute value type reference set| is for example used to indicate the reason why components have been inactivated.

• 900000000000489007 | Concept inactivation indicator attribute value reference set (foundation metadata concept)|

• 900000000000490003 | Description inactivation indicator attribute value reference set (foundation metadata concept)|

Language reference sets are used to specify the acceptability and preference for using a particular description in a specific language, dialect or clinical context. To understand the importance of Language reference sets it is necessary to be aware of the characteristics of SNOMED CT Descriptions and their representation.

SNOMED CT contains descriptions and each description contains both a human-readable term and some information about the term. A description is used to give meaning to a concept and provide well-understood and standard ways of referring to a concept. So, each description is associated with a specific concept, but each concept is associated to several descriptions. Additionally, the descriptions are specific to a language or dialect.

All Descriptions are of a specific type and the most common description types are the Fully Specified Name and Synonym. The Description file holds descriptions that describe SNOMED CT concepts. The description file is released with the International Edition of SNOMED CT. National or Affiliate Editions may develop their own description file, e.g. to represent description in their own language and/or dialects.

The Language reference set is essential to enable the preferred terms to be identified for each concept. Language reference sets refers to Descriptions that is used in a particular language or dialect. For each Description referenced in the language reference set a value for the acceptability of the term associated with that Description is assigned. The values for the Acceptability attribute is represented by descendants of the concept 900000000000511003 | Acceptability|, which is placed in the foundation metadata subhierarchy of SNOMED CT.

The following diagram shows an example of the description file included in the International Release and the US Language reference set, which is also distributed with the International Release of SNOMED CT. The language reference set states the acceptability of the descriptions, i.e. whether they are preferred or synonym. For each concept there may be any number of acceptable descriptions of each description type in each language reference set. The diagram below shows how the description file holds information about the description type, and the language reference set specify the acceptability of the descriptions.

Even though a concept has several descriptions of the type 900000000000013009 | Synonym (core metadata concept)| related to it, the language reference set allows automatic identification of the preferred term. The language reference set does not contain any terms, as these are represented in the description file. Hence, it refers to descriptions by referencing the descriptionId, and the description release file is therefore a prerequisite for retrieving the actual term when applying the language reference set .

When SNOMED CT is translated into other languages, it requires the Extension to include a description release file containing the new descriptions with the translated and approved terms. It also requires a language reference set, which specifies the acceptability of these new descriptions. The language reference set necessary to distinguish the preferred synonym (preferred term) from the acceptable synonyms, and it is required for specifying the preferred Fully Specified Name (FSN) within that language. A concept may have more than one FSN, but only one of these may be marked as 'preferred' in a given language. A Language Reference Set is therefore used to specify which FSN description is preferred in each language or dialect.

Even when SNOMED CT is not translated into other languages, a Language Reference Set can be used within an Extension to specify which of the existing descriptions from the International Edition are preferred and accepted within the particular context where the Extension is applied. The table below illustrates that within a single SNOMED CT Edition, multiple language reference sets can be created.

It is acknowledged that members and affiliates developing reference sets need to create human-readable versions of the reference sets. Human readable reference sets are used to allow reference sets to be inspected without requiring a software service to resolve the id's referenced in the reference set.

Supporting the readability of reference sets is particularly important for:

• Review

  • I.e. Subject matter experts who are involved with reviewing the content of reference sets

• Educational and dissemination

SNOMED International specifies a recommended format for human-readable reference sets to

• Avoid people reinventing and coming out with different solutions

• Allow a standard representation of reference sets shared as part of agreements with other standards bodies

• Allow tooling support (whether internally or externally developed)

A column is added for the human-readable version of an attribute, with the addition of '_term' to the attribute name.

Examples of this include

• The corresponding human-readable column for the attribute refsetId is refsetId_term

• The corresponding human-readable column for the attribute referencedComponentId id referencedComponentId_term.

• The corresponding human-readable column for the attribute acceptabilityId is acceptabilityId_term

When creating a human-readable refset it should be considered which term to include for each of the human-readable attributes. It is often preferable to include the preferred term from an appropriate dialect within the expressions to improve the human-readability of the attribute value. However, if it is required to disambiguate which hierarchy the concepts come from then the FSN can be used.

Sometimes it may be relevant to add one or more columns to function as a placeholder for comments related to either specific attributes, or for the reference set member (row) as a whole. To enable that these columns can be automatically identified as non-standard specific, we recommend to use following naming convention for these columns.

The '_'-symbol is used to represent that this column represent comments, or information, which shouldn't be included when the reference set is used as part of a SNOMED CT implementation.

It is therefore important that fields holding comments are not used for purposes important for use of the reference set. If the column is central for the machine-processable version of the reference set, then the column should be specified as a reference-specific attribute in a customized reference set () and identified in the reference set descriptor ( ).

The '_'-symbol is used as a prefix in front of a self-determined string. I.e the string can be any term which make sense for the actual situation, e.g. '_comment' can be used to allow reviewers to provide a comment to the specific attribute, or '_alternatives' may be used to suggest alternative members or member values, which can be used for proposals as part of a review process while the refset is under development.

SNOMED International recommends two uses of the '_'-symbol:

• <attributename>_<string> is used to refer to a specific attribute value

• _<string> is used to refer to a whole reference set row, i.e a specific version of a reference set member.

For all uses of human-readable reference sets and use of additional annotations it is very important that users do not include information which affects the use of the reference set within the human-readable columns (columns with the '_' prefix). All information relevant for implementation, processing and processing of the reference set should be represented according to the standard, machine-processable format. Consequently, all columns with the '_'-prefix should be able to be ignored when the reference set is implemented.

The initial focus of the reference set development work is to establish a clear set of initial requirements, which may require further elaboration at a later date. The requirements should include an assessment of the release requirements for the reference set from a user perspective.

Defining the scope of the reference set involves answering a range of different questions related to each step of the development process. Following questions are relevant to consider when defining the scope of a reference set. Additional questions will probably be relevant for a specific development process.

• What is the main purpose of the reference set?

• Who are the users of the reference set?

• What is the scope of content of the reference set?

• Who is responsible for developing and maintaining the reference set?

• Should we develop a new reference set or does any existing reference set meet our requirements?

Once the scope of the reference set and the requirements has been identified, it is essential that an owner of the reference set is clearly identified (this may be an individual or a specific group). Furthermore, the requirements must be clearly documented, particularly the scope, purpose and use case(-s).

The owners of the reference set must then assess what content to be included in the reference set. This process may involve evaluating existing reference sets, or assessing what parts within the International Release of SNOMED CT (and potentially National and Affiliate Editions) will meet the stated requirements. At this stage the requirements for ensuring the content of the subset is quality assured should also be documented.

Background

SNOMED CT provides the core clinical terminology for the electronic health record (EHR) and contains more than 300,000 active concepts with unique meanings. These concepts are organized into hierarchies and have formal logic-based definitions. When implemented in software applications, SNOMED CT can be used to represent clinically relevant information consistently, reliably and comprehensively as an integral part of producing electronic health records. Due to the comprehensiveness and expressivity of SNOMED CT it is often useful to constrain its use to a subset of concepts, descriptions or relationships relevant to a particular use case. SNOMED CT reference sets provide a standard way to represent subsets of SNOMED CT components. Reference sets also provide an extensible mechanism to customize the terminology to meet a wide range of practical requirements.

Purpose

The aim of this document is to provide a high level introduction to SNOMED CT reference sets, and to explain the different types of reference sets and their usage. Furthermore, the document includes an introduction to the reference set format and provides guidance on the development and management of reference sets. Thus, the objective of this document is to support users of SNOMED CT in :

• Understanding the purpose of reference sets

• Knowing about the different types of reference sets and their characteristics

• Choosing the correct type of reference set for a specific purpose

• Creating, developing and maintaining reference sets

• Using reference sets together with other SNOMED CT resources (for entry and display, analytics, knowledge linkage, communication)

• Sharing reference sets

• Adopting or adapting existing reference sets

• Exploring and assessing the content of existing reference sets

The intended audiences for this guide are those involved in the creation, maintenance and usage of SNOMED CT reference sets. More specifically, this includes:

• SNOMED International Members who wish to learn about the practical uses of reference sets or who are involved with defining reference sets

• Clinicians, informatics specialists and technical staff involved in the planning, management, design or implementation of reference sets.

• Software vendors, data analysts, epidemiologists and others designing SNOMED CT based solutions.

This document assumes a basic level of understanding of SNOMED CT. For background information the reader should refer to the .

A reference set is defined as: a standard format for maintaining and distributing a set of references to SNOMED CT components.

Notes

• A reference set can be used to represent a subset of components (concepts, descriptions or relationships).

• A reference set may also associate referenced components with additional information such as:

  • Ordered lists of components

  • Sets of associations between components

  • Mapping between SNOMED CT concepts and other systems codes, classifications, or knowledge resources.

Hence, reference sets are a mechanism that can be used to represent subsets and value sets of SNOMED CT components. However, they can also be used for many other purposes, including those summarized in the section. The following table lists the attributes used in the standard reference set format, and their purpose.

Table: Standard reference set format

SNOMED CT is designed to allow the International Edition to be extended to meet national or local requirements. A SNOMED CT Extension may contain components of various types including concepts, descriptions, relationships and derivatives including reference sets. Since the International Release and extensions share a common structure, the same application software can be used to enter, store and process information from different extensions. Extensions can also be shared without requiring additional software procurement or development. Most Extensions are managed by Members or Affiliates of SNOMED International.

Reference sets authored in an extension use the same common format as those in the International Edition. This makes it easier to use the same software to create, maintain and share extension reference sets, as used by international reference sets. The reference set format can also be customized in an extension using a standardized customization approach, as explained in section .

Messages and communication services are a means of exchanging data and thus enable effective and efficient communication among healthcare professionals and between patients and providers. SNOMED CT is important for communication because it serves as a semantic foundation for the meaning expressed in a message. Hence, SNOMED CT can ensure consistent and accurate representation of the information communicated, and support correct interpretation of the clinical information within a message.

Communicating clinical data through messages support a range of purposes, including:

• Delivering accurate, accessible, and actionable health information that is targeted or tailored.

• Facilitating the meaningful use and exchange of health information among healthcare professionals.

• Supporting shared decision-making between patients and providers.

• Providing personalized self-management tools and resources.

• Building social support networks.

• Increasing health literacy skills.

Healthcare messages include fields that can be populated with codes from clinical coding schemes. SNOMED CT provides concept identifiers as a means of encoding concepts. These concept identifiers are suitable for use in appropriate fields of many clinical messages.

Implementations of clinical messaging typically constrain the range of values that can be applied to particular fields several reasons for this are listed in the following table.

Table: Reasons for constraining the content of fields in clinical messages

For a more detailed use case example, please refer to the following section:

Communication specifications define structures designed to meet particular requirements. For example, recording a decision to prescribe a particular pharmaceutical product or substance might trigger an electronic prescription sent to the pharmacy. Reference sets may also be used to specify the allowed values in messages and for constraining the codable elements in data entry models. For some bindings it may be relevant to apply certain conditions, to enable that one value set is displayed given a specified criteria, and another value set is displayed given another criteria (or set of criterions). An example of such conditional value set binding is illustrated below.

Table: Types of Reference Sets applicable for messages

When a reference set has been developed and tested it should be prepared for use by implementing it in the environment where it is going to function. I.e. the implementation process and the tasks involved will vary dependent on the setting.

Often, implementation of a reference set will mean integration with one or more software artefacts, to enable data capture, represented by appropriate reference set members.

An important part of this process is proper binding between the information model and the reference set to ensure effective integration with data entry and storage functions. Many situations will also involve implementation of two or more interdependent reference sets, which require their dependencies to be considered to reach the most optimal implementation.

In this guide we highlight two aspects that are important when implementing SNOMED CT reference sets, i.e. supporting implementation with proper implementation guidance and considerations related to optimizing the reference set for a particular implementation.

Implementation Guidance

The tasks involved with implementing a reference set will depend on the situation and the technical setting where the reference set is going to function. To support successful implementation, and to ensure that the reference set is used as intended it is important with precise and clear instructions for the people responsible for implementing the reference set, i.e. the people preparing the reference set for routine use within a particular setting.

Implementation guidance should, as a minimum, include instructions on:

• The overall purpose and intended use of the reference set

• The reference set design, i.e. attributes and data types

• Dependencies to terminology artifacts, such as

Additionally, it is valuable to include instructions on how to test the implementation, i.e. exemplar test cases with information on expected outcome given a specific action.

As part of an implementation process it is relevant to consider any optimization that could be done to meet requirements for implementation or result in a more effective and/or efficient use at runtime. Because, even though reference sets are distributed in separate files and represented according to the reference set file format, it may be useful to transform these reference sets files into another structure that is more appropriate for the specific use case.

Optimizations that could be considered include:

• Controlled redundancy. For some matters it may be useful to introduce some level of redundancy, e.g. by joining reference sets or release files together so that the data is more efficient to access at runtime

  • e.g. combining a simple reference set of concepts with the description file, so that the term preferred for display can be retrieved directly from the subset file.

  • e.g. combining the description file with a language refset, so that the term is in the same row as the acceptability of the description, and the concept id that it describes.

Reference sets are useful for a range of purposes, and different types of reference sets have been defined to meet various requirements. It is therefore important to understand the requirements for reference set usage in order to be able to select the appropriate reference set design.

Reference sets are useful for including, excluding and prioritizing content or managing the use of codes for data entry, communication or analysis purposes. Reference sets are important when customizing the use of SNOMED CT to meet specific requirements. For example, to meet national, jurisdictional or organizational requirements for recording clinical information, or to assess regional variations in disease prevalence or health delivery.

Practical use cases for SNOMED CT span the entire clinical information lifecycle from data entry, through to storage, display, communication, retrieval, analysis and reuse. Reference sets support effective and efficient use of SNOMED CT for a range of purposes at different stages in that lifecycle. For example, reference sets can assist with user interface customization, specification of reporting criteria, mapping to statistical classifications and representation of links to knowledge resources. They can also be used to represent terminology bindings and to validate the content of both inbound and outbound communications.

The subsequent sections will introduce some of the typical requirements and use cases for reference sets and the different types of reference sets which support these use cases.

With time, the set of concepts, or other components, referenced in a reference set will need to change, either because of changes in SNOMED CT, changes in clinical knowledge, or changes dictated by errors or omissions in the original reference set. The original reference set will have been given an identifier that is used to reference the reference set in models or other entities that use that particular reference set. When a change is required that maintains the original intent but updates the content, the change is considered a new version of the reference set. Versioning maintains the reference set identifier and additional reference set attributes.

Following topics will be presented in relation to reference set maintenance:

• Reference Set Management Considerations

When developing or evaluating a change management process it is important to take different factors into account. Some of these factors are introduced in the table below.

Table: Change management considerations

Maintaining reference sets starts as soon as the reference set is specified. The maintenance process involves ensuring that the content of the reference set refers to active concepts in the release upon which the reference set depends. It also involves adding new content to the reference set, for example when additions to the dependee Release fall within the scope of the reference set specification. The alignment of a reference set with the International Release will be undertaken during the international release process, at which time a change report will be created for circulation, providing details of the changes made, in a format that can be circulated virtually to subject matter experts.

The tasks related to reference set changes will typically involve substituting a prior version of a reference set with the more recent version. For example, if a reference set represents a value set which is used in a data entry interface, the reference set may simply be replaced by the updated version of that reference set. On the other hand, if the reference set is of a more complex nature, for example, if it represents a map between SNOMED CT and a classification, and is used for quality monitoring, research, reimbursement etc., it might be necessary to go into more detail about the implications of the change. Regardless of the type of reference set change (addition, inactivation or change) it will always have implications.

If a reference set is added data entry protocols should be updated to link to this reference set where this is found appropriate. For example, if a reference set has been developed to function as a value set for cardiovascular diseases, data entry protocols should link to the reference set in the data entry protocols used to capture cardiovascular diseases. The nature of the binding depends on the underlying information model of the protocol. Additionally, it is important to update the storage models appropriately. See, to learn about this topic. It may also be necessary to develop queries to generate reports or views based on the new reference set data. Alternatively, an added reference set may include rules to enable decision support, which must be integrated. It may also be necessary to create or update links between reference set members and communication protocols.

A reference set may be inactivated in situations where an organization is no longer able or prepared to maintain it.

Inactivation of an entire reference set is done by inactivating the concept that identifies the reference set, and inactivating the relationship used to place the reference set in the subtype hierarchy.

Reference sets that are being actively used should not be inactivated without giving prior notice to the users of the reference set, to allow remedial steps to be taken.

Any function using a reference set that is no longer maintained will need updating. For example, if a reference set is inactivated, which is used for data entry, it is important to determine how the inactivation is managed in the system. Thus, it should be clarified whether a new reference set should be defined or whether the inactivated reference set should be added in a local extension. It may also be that a replacement reference set has already been defined.

The types of changes that can occur in a reference set include:

• Changes to reference set members

• Addition of reference set members

• Inactivation of reference set members

The effect of changes to reference set members depends on the type of reference set and the way the reference set is used. Generally, it is important to assess the extent to which the reference set changes affect the situation in which the reference set is used, such as:

• Data entry. Changes to reference set members may require changing existing data entry protocols.

• Data storage. Changes to reference set members may require migrating or processing pre-existing data in a particular way to ensure consistency.

• Data retrieval. Changes to reference set members may require revising existing queries to take account of the changes.

One way of determining the changes to a reference set is by creating and comparing the following two views of the reference set:

• SNAPSHOT view of the previous reference set release. This view contains one version of every member released up to the time of the snapshot. The version of each member contained in a snapshot is the most recent version of that member at the time of the snapshot.

• DELTA view of the new reference set release. This view contains only reference set member versions created since the previous reference set release. Each reference set member version in the DELTA view represents either a new reference set member or a change to an existing member.

These two views make it possible to automatically identify whether a reference set member has been created, changed, reactivated or inactivated. The table below illustrates how to interpret the 'active' attribute, when comparing the delta view of the new release of the reference set with the snapshot view of the previous release of the reference set.

As clinical practice evolves and adapts to meet the needs of healthcare advances, SNOMED CT content is updated to address these changes. Reference sets may also need to be updated to reflect content changes and to enable clinicians to adequately represent new and emerging techniques and practices. It is therefore important to establish processes for end users and other stakeholders to submit requests for changes. Related to reference sets the types of changes that may be required include:

• Addition of new reference set members

• Removal of reference set members

• Changes to existing reference set members

When new members are requested for inclusion in a reference set, it should be determined whether any existing components in SNOMED CT are sufficient, or whether it requires a new component to be added - either in the International Edition or as part of an Extension.

To remove a referenced component from a reference set, the relevant reference set member is inactivated. This is done by adding a new row to the reference set in which the value of the active column is set to false. The SNOMED CT versioning mechanism tracks the full history of additions, changes and inactivations because each row in the reference set contains a effective time column indicating when the change became effective. This is the same versioning mechanism with is used to track addition, inactivation and modification of SNOMED CT components.

Changes to reference set members can vary, dependent on the refset type and the situation. Examples of changes include:

• Changing the order assigned to a member of an ordered reference set

• Changing the annotation associated to a member of an annotation reference set

• Changing a description from being acceptable to preferred in a language reference set

The type of service implemented to support change requests will depend on the amount of reference sets, the number of users, the organisation etc.. Smaller organisations with relatively a few end-users may apply a simple email service for proposing any changes to the refset. Other institutions may implement dedicated systems that track each change request and support proper management of those.

Authoring and managing reference sets require some level of tooling support. Broadly speaking, two types of tooling support exists:

1. Combination of browsing functionality and simple spreadsheets or database system

2. Dedicated reference set management tools with extended features

The extend of sophistication of the tool required depends on various factors, and the combination of those factors:

• Type and size of reference set

  • Simple reference sets with few members

  • Large reference sets of various types

Relevant functionalities for reference set creation and management include:

• Creation of both extensional and intensional reference sets

  • Services for browsing and displaying SNOMED CT content for manually selecting reference set members

  • Services for manual and intensional expansion of reference set (inclusion of reference set members)

Generally, it is not recommended to use a spreadsheet approach for managing reference sets, because there is a dependency between the reference set and the core content of SNOMED CT. The SNOMED CT release files are important for interpreting the components referenced by the reference set, for example:

• Description file: Access to the descriptions are required to display the terms of the components referenced by the reference set.

• Concept file: Access to the concept file is required to assess whether the components referenced by the reference set are active or inactive

However, in some situations spreadsheets (supported by a browsing facility) may be feasible, for example,

• If the reference set only consists of a few members

• If the reference set is only used locally

• If only one person is responsible for managing the reference set

If a spreadsheet approach is chosen it is recommended to create a of that reference set to support interpretation of the identifiers used in the reference set.

The main benefits of using an EHR accrue with the implementation of effective retrieval, analysis and reuse of clinical information. Analysis of health record data may cover:

• Individual patient records to search for significant patterns that may prompt interventions

• Patient groups or cohorts, based on demographics, diagnoses, treatments or interventions

• Enterprise groups, based on teams, wards, clinics, institutions or providers

• Geographical groups, based on a local area, town, region or country

SNOMED CT has a number of unique features, which makes it capable of supporting a range of retrieval and analytics functions, which use reference sets. Examples include, but are not limited to:

• Simple reference sets can be used to represent subsets of SNOMED CT concepts which can be used in queries to identify clinical records

• Simple reference sets can be used to represent non-standard aggregations of concepts for specific use cases

• Simple map reference sets, complex and extended map reference sets can be used to define maps from other code systems to SNOMED CT so that clinical data can be prepared for analytics, and then performed using SNOMED CT

The document provides detailed information about how SNOMED CT can be used for analytics.

For more detailed use cases, please refer to the following examples:

Clinical information recorded using SNOMED CT may include data that is relevant to reports, statistical returns, billing claims, etc. that need to be encoded using a specific code system or a statistical classification such as ICD-10. Mapping allows relevant information to be used for those purposes, minimizing the requirement for additional manual data entry.

Maps are represented as reference sets, which are either of type simple, complex and extended map reference sets. Special cases may also occur, which require a customized reference set to represent the map. An example of this is the 705110001 | LOINC Term to Expression reference set| , which is used to link LOINC Terms to SNOMED CT expressions. The standard reference set format do not support maps to SNOMED CT expressions. Hence, the type of map reference set to use depends on the features that need to be supported by the map.

Simple map reference sets support mapping SNOMED CT codes to a single code or a combination of codes in a target code system. However simple maps are usually only appropriate where there is an equivalent map between SNOMED CT and the values in the other code system.

Complex and extended map reference sets enable the representation of:

• Maps from a single SNOMED CT concept to a combination of codes (rather than a single code) in the target scheme

• Maps from a single SNOMED CT concept to choice of codes in the target scheme. In this case, the resolution of the choices may involve:

  • Manual selection supported by advisory notes

The completeness of mapping between two code systems depends on the scope, level of detail provided by the two code systems and the precision of mapping required to safely meet the intended mapping use case.

The figure below shows an except of some of the reference sets for maps between SNOMED CT and other code systems, which are available with the International Edition of SNOMED CT. However, local maps may also be developed and applied as part of an Extension to SNOMED CT.

Both extensionally and intensionally defined subsets of SNOMED CT components are useful for specifying clinical queries. For example, subsets of SNOMED CT concepts can be used to categorize patient data by testing for membership in a predefined subset, which is represented as a reference set.

The (ECL) enables simple queries over SNOMED CT content to be expressed. While the language itself does not support querying over the full EHR content, the ECL could be embedded within record-based query languages (such as SQL) to represent the terminological aspects of these queries.

Related to reference sets, the ECL includes the ability to refer to a set of concepts that are referenced by members of a reference set. Additionally, it includes a range of features, such as refinements, disjunction, and conjunction, which support specialized queries. The memberOf function evaluates to the set of concepts that are referenced by the given reference set. For example, the following expression constraint is satisfied by the set of concepts which are members of 649999999104 | Example problem list simple reference set| :

• memberOf 649999999104 | Example problem list simple reference set|

The diagram below illustrates how reference sets can be for specifying queries.

Subsets of SNOMED CT concepts can be used to categorize patient data by testing for membership in a predefined subset. The diagram below illustrates the use of a simple reference set which includes references to rare disease concepts. SNOMED CT does not currently have a defined mechanism to distinguish rare diseases, so this simple reference set is defined extensionally (i.e. by enumeration). This simple reference set is used to create a cohort, by categorizing patients according to their SNOMED CT encoded records, and specific values of contextual metadata. By comparing the patient diagnosis with the concepts included in the reference set it is possible to count the total number of patients who suffer from rare diseases.

A combination of reference sets and subsumption testing can be used to enable a simple, yet sophisticated, analytics feature. For example, you may want to include all of the descendants of reference set members in a particular analysis.

The diagram below illustrate the difference of categorizing patients using two approaches:

1. A subset of components.

   • Two patients are included in a query which analyzes encoded health records and checks for membership in the appropriate subset. E.g. patients with a finding included in the rare diseases reference set.

2. A subset of components and subsumption testing.

General Development Process

The lifecycle of reference set work spans from the point where there is an initial idea related to a specific clinical information requirement based on SNOMED CT through reference set development to long term maintenance. At each stage it is essential that a defined process is followed which ensures the quality and validity of the product is maintained. The following figure provides an overview of the steps that are relevant to any project that either builds its own reference set, or adapts reference sets authored from elsewhere. The general process is similar to the process used when developing other information artefacts, and as for many development processes it is essential to be clear and specific about the requirements to be met, and to ensure that these requirements drive the design and implementation of the artefact. Related to reference set development this means that the process is not just about creating a reference set, but more about how to address the requirements, and this will often mean a combination of development of different reference sets.

The overview provided in following diagram is not intended to imply that a waterfall methodology should be used to develop a reference set. It may be delivered using agile or iterative project methodologies, with the reference set and supporting project documentation evolving as the project develops.

Provide Feedback

Managing the components used to represent the large number of clinical data entries in EHRs is an important part of the work related to maintaining the integrity and accessibility of health information. Like SNOMED CT components, reference sets are supported by a robust versioning mechanism that allows historically consistent views of SNOMED CT components and derivatives. This allows reference sets to be used to specify changes in use of concepts and descriptions in different parts of an EHR.

For more detailed use cases, please refer to the following examples:

Constrain Value Sets

Most health records are designed and developed using one or more information models, which describe the information that is collected, stored, communicated and displayed. Some information models are designed for a specific proprietary system, while others are based on a common health information standard. Irrespective of the purpose, design and representation of the information models, the use of clinical terminology is an important part of making the models complete, meaningful and useful. Hence, a consistent approach to the interface between structural elements and terminological representations of information is required to support reliable interpretation of the meaning. Subsets of SNOMED CT components can function as value sets for any health-related information model to enable well-defined, unambiguous models of meaning.

As shown in the diagram below simple reference sets can be used to represent the subsets of SNOMED CT components to be populated as value sets within the relevant information models.

EHR systems will typically utilize a range of different value sets to be used in different places of the system. Representing these value sets using the same terminology will support the comparison of data captured in different contexts. Additionally, using SNOMED CT to represent items value sets instead of locally defined terms enables effective management and overview of information, and helps to mitigate challenges related to redundancy and ambiguity.

Simple reference sets can be used to represent extensionally defined subsets of SNOMED CT components, whereas the query specification reference set are useful for representing the intensional definition of SNOMED CT subsets. In the query specification reference set, the expression constraints can be used to represent the query used for defining the set. This means that the query specification reference set can be used to manage the intensional definition of SNOMED CT subsets that function as value sets, which is illustrated below.

When a component that is a member of a reference set is inactivated, the person maintaining the reference set needs to decide whether a change is required. This depends on the intended use of the reference set being maintained. In the case of a reference set that is being used to constrain data entry, inactive concepts need to be removed from the reference set or replaced by an appropriate active concept. In other reference sets it may be permissible, or even required, to retain an inactive concept in a reference set (for example if a reference set is used in the criteria for a report which may be applied to historical data).

The following figure and subsequent description introduce the overall process for identifying inactive components and using released reference sets to determine reasons for inactivation and potential replacements.

1. One approach to identify the components that have been inactivated since the last release, is to compare snapshot of previous release with current delta release.

2. The reasons for inactivation can be looked up in the 900000000000480006 | Attribute value type reference set| for the particular component type, for example the 900000000000489007 | Concept inactivation indicator attribute value reference set| . The reason is represented by the value of the valueId attribute. For further information, see .

In the International Edition of SNOMED CT three reference sets of the type 900000000000480006 | Attribute value type reference set| are used to indicate the reason why components have been inactivated. These are:

• 900000000000489007 | Concept inactivation indicator attribute value reference set (foundation metadata concept)|

• 900000000000490003 | Description inactivation indicator attribute value reference set (foundation metadata concept)|

• 900000000000547002 | Relationship inactivation indicator attribute value reference set (foundation metadata concept)|

For example, if the inactivated component is marked as 900000000000484002 | Ambiguous| , this will typically mean that there will be more than one component replacing the inactivated component. The possible replacements will be available in the 900000000000523009 | POSSIBLY EQUIVALENT TO association reference set (foundation metadata concept)| .

Another example is concepts that are inactivated because they were 900000000000482003 | Duplicate| . This is used if two concepts represent the same meaning, because then one of those concepts must be inactivated. The equivalent concept will be represented in the 900000000000527005 | SAME AS association reference set (foundation metadata concept)| . Please refer to to see which reference sets relate to the various reasons for inactivation.

When a new version of SNOMED CT is released this may include changes to the content of the terminology. Components may have been added, inactivated or changed as described in . As part of the terminology maintenance process, it may be appropriate to evaluate both the and to determine appropriate alternatives.

The International Edition of SNOMED CT distributes a set of reference sets that record the reason that each inactive component was inactivated. These are referred to as "historical association" reference sets. There is one historical association reference set for each type of historical association as shown in the table below.

Table: Association reference set types in the International Release of SNOMED CT

The following table holds example entries for the 900000000000526001 | Replaced by| reference set. With this reference set is possible to automatically identify that the inactive concept 696005 | Chronobiologic disorder| should be replaced with the concept 387605007 | Abnormal chronobiologic state| . This type of reference set is particularly useful for ensuring consistent use of SNOMED CT over time. The reference set mechanism here provides an easy and standardized way of managing changes to coding or documentation practice over time.

Table: Sample content from 900000000000526001 | REPLACED BY association reference set |

To decide if a reference set is needed, successful implementers of SNOMED CT must clearly understand their requirements.

The table below shows some typical requirements that may be met using SNOMED CT reference sets. The examples in this table are not exhaustive, but instead illustrate common use cases in which the category of requirement is needed. The table also shows the type (or types) of reference set that best meets each requirement. For more information on each requirement category, please click on the diagram to visit the relevant section.

Table: Requirements met by reference sets

The SNOMED CT Practical Guide to Reference Sets starts by identifying practical use cases and the requirements that must be met to address them. It then explains how different types of reference sets can be used to meet those requirements. It also provides advice on different approaches to creating, editing, maintaining and using reference sets to support effective localization and customization of SNOMED CT.

Provide Feedback

In this section, we define some important terms that are used throughout this guide. In particular, subset, value set and reference set.

Subset and value set are general terms that are not specific to SNOMED CT. However, it is important to understand what they mean, and how they relate to SNOMED CT reference sets.

In summary:

• A subset is a set of members all of which are members of another set (from set theory in mathematics).

Reference Sets can be distributed as part of the International Release, as part of a National Edition or as part of an Affiliate Edition, and the way the reference set is distributed will typically depend on how the Edition is distributed. However, in some situations, reference sets may be distributed independently.

Distributing reference sets usually involves performing any additional quality checks required to ensure that the data can be exported correctly, and then exporting the reference set from the terminology management tool. Finally, the reference set is distributed to the users, for example as release files accessed from an online library using a terminology server API.

Distribution Format

The standard format for distributing SNOMED CT reference sets are the reference set format, as described in Common Reference Set Format. For example, an extensional definition of a subsets of components is represented as a simple reference set, and the standard format for distributing intensional definitions of concept subsets is as a query specification reference set. As part of the SNOMED CT release format, reference sets support unique identification, versioning and recognition of dependencies.

Using the reference set format for distributing SNOMED CT derivatives is beneficial from the view of maintenance, because the versioning attributes is identical to the versioning attributes used for SNOMED CT components. This means that the checks that need to be done as part of a regular release cycle is easier to manage compared to having a range of different versioning mechanisms to adjust to.

Other distribution formats may be used where necessary. For example to comply with requirements for representation of value sets including codes from other code systems. However, care should be taken to ensure that distributed subsets are uniquely identified and versioned. Subsets need to be accessed, selected and where appropriate bound to information models using standard approaches.

Some subsets will be distributed biannually as part of the International Release. However, some others may not require this release schedule. Release processes must include a period of time dedicated to subset manipulation, following the 'freezing' of SNOMED CT itself. This is the period where all the changes has been made to the core components of SNOMED CT. Timing of release and distribution of specific subsets will be dictated by individual use case-specific requirements. These should be identified and documented initially as part of the subset development process. These may change over time based on user feedback.

A value set is a uniquely identifiable set of valid concept representations, where any concept representation can be tested to determine whether or not it is a member of the value set.

A value set is typically used to represent the possible values of a coded data element in an information model. The members of a value set may represent concepts using either simple codes or postcoordinated expressions.

There are a number of use cases for value sets, including constraining the permitted values for elements in a communication specification, specifying the values in a pick list on a user interface and defining the required values to use for reporting. Value sets may range from a simple flat list of codes from a single code system, to an unbounded hierarchical set of post-coordinated expressions drawn from multiple code systems. Value sets containing only SNOMED CT components may be represented as SNOMED CT reference sets.

For example, a message or reporting specification might define a single value set for a problem list, which includes:

• SNOMED CT 64572001 | Disorder| concepts

• SNOMED CT expressions that are subtypes of 64572001 | Disorder|

• ICD-10 classification codes representing diseases

The diagram below illustrates an example of an Observation model, which may be used to support diagnosis, monitor progress, determine patterns in clinical data, etc. Each data element in the information model is linked to a value set, which represents the value values for that element. As shown below, the value sets used in this information model may be selected from different code systems. In some cases, a single value set may also include concepts from different code systems.

This playlist brings together all videos on SNOMED CT subsets, value sets and reference sets from the SNOMED International Implementation Course. The videos introduce key concepts, practical implementation considerations, and real-world examples to help you understand how SNOMED CT subsets, value sets and reference sets can be applied in SNOMED CT implementations.

Open playlist on YouTube:

👉 Click here to view the full playlist on YouTube

How to navigate the playlist in GitBook

When a YouTube playlist is embedded in GitBook, only one video is shown on the page at a time, but all playlist videos are still available.

• Use the forward () and back () arrows on the video player to move between videos in the playlist

This section contains information about reference set types that are now deprecated and replaced by enhanced reference set. The fact that a referenced set type is deprecated does not imply that reference sets of that type cannot be used. However, it does indicate that there is another reference set type that more effectively meets the use case(s) for which these reference sets were originally designed.

Ordered Reference Set

The design of the ordered reference set supports three overall purposes:

1. To specify a sequential order of a subset of components

2. To specify prioritized groups within a subset of components

3. To define alternative hierarchies of components

Ordered reference set can also be used to create a simple ordered list of components, i.e. a list that do not include any nesting, or groups. For ordered lists that do not require grouping or hierarchical arrangement the value of linkedToId should be the digit zero (0), as this attribute becomes irrelevant.

This type of ordered reference set can for example be used to prioritize the sort order of the descriptions with identical terms when they are displayed. It can also be used to specify the order of descriptions displayed in a simple pick list.

Prioritization is similar to order but multiple components may have the same rank. In this case the value of the order attribute specify a priority order for a group of components.

The diagram below Illustrates how the three attributes referencedComponentId, order and linkedToId are used to create an alternative hierarchical order of some of the concepts from the subtype hierarchy.

Specific reference set attributes used to build an alternative hierarchical view of SNOMED CT

900000000000516008 | Annotation type reference set| allows String to be associated with components for any specified purpose. So, where the 900000000000521006 | Association type reference set| linked a SNOMED CT component to another SNOMED CT components, the 900000000000516008 | Annotation type reference set| allow a SNOMED CT component to be linked to a non-standardized string annotation.

\

Besides from the 4 identification and versioning attributes, the annotation reference set type has following attributes.

A subset is defined as a set of members all of which are members of another set (from set theory in mathematics).

Notes

• In SNOMED CT, the definition of subset applies to SNOMED CT components as follows:

  • A subset of SNOMED CT concepts is a set of concepts taken from a wider set of concepts.

  • A subset of SNOMED CT descriptions is a set of descriptions taken from a wider set of descriptions.

• The members of a subset can be defined in one of two ways:

  • Extensionally, by enumeration, with a simple reference set as the standard distribution format.

  • Intensionally, using rules to determine inclusion, with a query reference set as the standard distribution format.

The diagram below shows an example of a subset. The English vowels are a subset of the set of alphabet characters included in the English alphabet

There are two distinct ways to define the membership of a subset. These are known as extensional and intensional subset definitions. These terms are defined and illustrated below.

A subset in which the members are represented by enumeration.

A subset definition in which the membership is represented by a set of rules specifying the conditions for inclusion.

Extensionally defined subsets of SNOMED CT components consist of a list of SNOMED CT component identifiers, which are typically either concept or description identifiers. Extensionally defined SNOMED CT subsets are formally represented using the simple reference set type.

The design of SNOMED CT lends itself to intensional subset definitions, because rules can be formulated to specify the conditions for member inclusion. The subtype hierarchy and formal definitions of SNOMED CT concepts enable constraints to be specified, such as:

• Concepts that are descendants of a particular concept.

  • For example: < 118794001 | Procedure on lung| (i.e. all descendants of the concept 118794001 | Procedure on lung| )

• Concepts that share a set of defining characteristics.

Intensionally defined SNOMED CT subsets are formally represented using a . The query string in this reference set represents the intensional definition of the subset. The standard way of representing the query is using the SNOMED CT (ECL).

The substrate is the superset of members to which an intensional subset definition is applied. Related to subsets of SNOMED CT components the 'Substrate' is the SNOMED CT content against which an intensional query is executed. Typically, the substrate is a specified version of a particular SNOMED CT Edition. Regardless of whether the subset members are intentionally defined or extensionally defined it is important to be specific about the substrate used to generate the subset, because the result of running a query, or manually selecting the subset members, may vary depending on the substrate used.

The expansion is the result of applying an intensional definition to a given substrate. The Expansion may differ depending on the substrate that the query is run against. The expansion that results from running the query against a specific SNOMED CT substrate can be represented extensionally as a simple reference set. Alternatively, the expansion may be computed dynamically or represented in an internal format within a software application.

For more information about the process and methods for developing subsets and reference sets, see the section about refset development.

Content Reference Sets

Table: Overview of reference set types and example use cases, as described in the international Release of SNOMED CT

Table: Overview of reference set types and example use cases, as described in the international Release of SNOMED CT

The reference set mechanism is developed to support a range of different purposes, and therefore it has a high degree of flexibility and extensibility. As evidence of the flexibility in the design, some reference set types use a unique set of attributes in addition to the common reference set attributes. The additional attributes have been specified to meet the requirements for use of that particular type of reference set. The extendibility of the design allows reference sets to be customized to suite specific or local requirements. However, to support distribution, sharing and use of a reference set, it is important that the specific reference set design is consistently specified and represented. Thus, all attributes specific for a particular reference set type must be represented in a form which allows consumers of a reference set to validate and interpret the reference set.

The figure below provides an overview of some of the terms that are central for understanding the reference set design and how reference sets are specified and represented . Each of these terms will be elaborated in the following pages.

SNOMED International specifies a set of reference set types, which describes its own specific properties. This means that reference sets that are developed to conform to a specified pattern will have the same release file format as other reference sets of the same type.

The pattern of a specific reference set type is described by a Descriptor Template. This means that the Descriptor Template is represented by a set of members of the 900000000000456007

SNOMED CT is a multinational, multilingual terminology which enables the link between concepts and different linguistic representations. Hence, SNOMED CT has a built-in framework to manage different languages and dialects. Each concept, representing a clinical meaning, can be linked to descriptions, which express that particular meaning using different terms, languages or dialects. This means that descriptions can be added to SNOMED CT concepts and expressed in other languages than what is included in the International Edition. Often these additional descriptions are used in a national Extension of SNOMED CT.

Consequently, one aspect of implementing and customizing SNOMED CT to meet specific user needs is to determine and specify preferences for the descriptions to be used, e.g. for display in an electronic health record or more generally, as preferences within a specific clinical domain or facility.

In the International Edition of SNOMED CT are included which specifies the preferred and acceptable synonyms for each concept in both US english and GB english. However, language reference sets can also be developed and applied locally to specify what descriptions are preferred and acceptable in a given context. This means, that even within a single country, or a single hospital, different descriptions can be applied to meet the user preferences, even without relaxing the need for consistency and unambiguous concept definitions.

For more detailed use case examples, please refer to the following sections:

The table below illustrates some of the use cases that SNOMED CT reference sets support. Furthermore, it includes some typical example uses for each use case, and presents the types of reference sets relevant to these example. You can click on the diagrams and the text to navigate to the subpage, which provides more information about each of the use cases, examples and reference sets. The examples shown in the table are not exhaustive. Instead, they illustrate some common scenarios for each type of reference set.

Table: Reference set use cases

Linking SNOMED CT components to knowledge resources (such as clinical guidelines or decision support systems) is a way of adding significant value to electronic health records.

The diagram below illustrates the range of use cases for knowledge linkage including presenting alerts to the user, displaying relevant clinical guidelines and treatment protocols, or automatically populating an order, message or report.

Reference sets can be used to enable knowledge linkage in different ways. Examples include but are not limited to:

• Annotation reference sets can be used to add a linkage between a referenced component and a string-representation of a specific knowledge resources.

• Association reference sets can be used to create associations between SNOMED CT components to enable documentation and/or decision support, using the associations as a simple rule-representation.

• Simple map reference sets, complex and extended map reference sets can be used to define maps from other code systems to SNOMED CT, and function as a linkage to sources of non SNOMED CT-encoded information

For a more detailed use case, please refer to the following example about linking concepts to web resources:

In the example below URLs are used to annotate two SNOMED CT concepts with images on the web. It is not recommended to use this approach to annotate concepts with text that may require translation to other languages. Instead, such text should be included under an appropriate description type within the Description file. However, in some cases this type of reference set can be useful to link concepts or descriptions to specific guidance documents or other types of knowledge resources.

Table: Example of an associated image annotation reference set