Requirements

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

A Subset of Components

When implementing SNOMED CT in a clinical software system, such as an EHR, the use of SNOMED CT will typically involve customization. For example, selecting a subset of SNOMED CT components to be used for a particular purpose is a typical way of customizing SNOMED CT for use. Subsets of SNOMED CT components can be used to constrain the use of SNOMED CT by either including, excluding or prioritizing specific components.

An extensionally defined subset of components, whether it is a subset of concepts, descriptions or relationships, can be represented as a simple reference set.

The definition of an intensionally defined subset of components can be represented using a query specification reference set, while its expansion can be represented using a simple reference set. A subset of components may be required to support a range of different uses, as illustrated in the table below.

Table: Requirements for subsets of components

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

• Constrain data entry

• Constrain searches

• Exclude content

• Categorising patients using subsets

• Constrain value sets

An Ordered List of Components

Organizing members of a subset into a specific order can be useful to meet certain implementation requirements, such as displaying drop down lists for data entry or search results. Members of a subset can be ordered in a variety of automated ways, including displaying the shortest term that matches the search term first, alphabetically, or randomly. However, when the required order cannot be automatically computed, it may be necessary to specify an order for each subset member. Ordered lists of SNOMED CT components (typically concepts or descriptions) can be represented using an Ordered Reference Set. For more information about ordering SNOMED CT components on a user interface, please refer to the SNOMED CT Search and Data Entry Guide.

Table: Requirements for an ordered list of components

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

• Order Items for Search and Data Entry

• Alternative Hierarchical View

A Set of Associations between Components

When SNOMED CT is implemented in electronic health records, there may be situations where explicitly stating associations between components can support effective and efficient use of SNOMED CT.

In some situations, a set of unordered associations between components may be required. In other situations, an ordered list of directed associations between components may be needed. As illustrated in the table below, unordered associations can be represented using an association reference set, while an ordered list of directed associations can be represented using an ordered reference set. Associations can be specified between components of any type. However, associations are typically used to link concepts and/or descriptions.

Table: Requirements for a set of associations between components

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

• Use Case Specific Associations

• Representing Historical Associations

• Alternative Hierarchical View

A Set of Components Annotated with Additional Information

In some cases, an implementer may need to add additional information about each member of a subset. This information may be additional textual information or additional coded values.

Annotating each member of a subset with additional information can facilitate the processing of subset members and assist in meeting the functional requirements of a system.

Table: Requirements for a set of components annotated with additional information

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

• Linking concepts to web resources

• Representing reasons for component inactivation

• Indications of acceptability of descriptions

A Set of Maps between SNOMED CT and Another Code System

A map is an association between codes from one code system and codes from another code system, that have the same (or similar) meaning. Mapping is the process of defining a set of maps. Maps are developed in accordance with a documented rationale, for a given purpose. As a result, there may be different maps between the same pair of concepts or terms to meet different use cases.

The purpose of mapping between SNOMED CT and another code system is to provide a link between the code systems, to obtain a number of benefits. These may include:

• Data reuse - for example, SNOMED CT based clinical data can be reused to report statistical and management information using an alternative classification system

• Retaining the value of existing data when migrating to newer database formats and code systems

• Avoiding the need to enter data multiple times and preventing the associated cost and potential errors

• Promoting interoperability between terminologies, classifications and code systems

Table: Requirements for a set of maps between SNOMED CT and another code system

A Set of Sets of Components

Some situations may require sets of components to be implemented and managed. For example, when implementing a package of subsets.

Table: Requirements for a set of sets of components

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

• Managing value sets

• Constraining the coded content of messages