Purpose

The 705111002 |Map to SNOMED CT with correlation and origin type reference set| is used to meet the requirements for representation of maps from codes in another code system (other-codes) to a SNOMED CT concept, where the following requirements apply.

1. A requirement to indicate the degree of correlation between the SNOMED CT concept and the other-codes.

2. A requirement to indicate whether a concept or code was added to either code system as a result of the mapping process and, in this case, to indicate in which code system the concept or code originated.

3. A requirement to represent the SNOMED CT attribute to which the other-code should be applied in order to capture the full specificity of the value represented by the other-code.

4. No requirements for mapping rules or advice to be included with each map.

Map to SNOMED CT with Correlation and Origin Reference Set - Data structure

The following metadata hierarchy supports this reference set:

Map to SNOMED CT with correlation and origin type reference set in the Metadata Hierarchy

The tables below show the descriptors that define examples of reference sets that follow the pattern.

Refset Descriptor rows for Map to SNOMED CT with correlation and origin type reference set

Sample Content from a Map to SNOMED CT with correlation and origin type reference set

To check the validity of a SNOMED CT Identifier, please visit the SNOMED International Component Identifier Service, which can do this check for you - https://cis.ihtsdotools.org/info

Provide Feedback

This section describes SNOMED CT Release Format 2 (RF2), to be used for official production releases of SNOMED CT. This format is not mandated for internal terminology development usage or as an interchange mechanism between terminology development systems. RF2 provides a format that is flexible, unambiguous and useful. It was designed to strengthen SNOMED CT by providing a simple and stable format that enables innovation through adaptations to cater for changing requirements.

The component release files are defined in the following sections:

• Associations Between Release Files

This subsection provides illustrated notes on the contents of the SNOMED CT International release package used to distribute the SNOMED International Edition. Similar folder structures should be present in other release packages. However, the files included may be limited to those required to represent the components and/or reference set members in that particular release package.

This Figure shows the overall structure of a release package. The top level folder is named according to the Release Package Naming Conventions. It contains one subfolder for each of the Release Types (Delta, Full and Snapshot). Each release type folder contains a Terminology folder and a Refset folder. The Refset folders contains separate folders for different groups of reference sets (Content, Language, Map and Metadata).

This Figure shows the contents of the Terminology folder. In this case, the files shown are those for the Full release type. Details of most of these files are shown in section Component Release Files Specification, while the OWL refsets follow the specification of the OWL Expression Reference Set.

This Figure shows the contents of the Refset subfolders. In this case, the files shown are those for the Full release type. The names of the reference set files correspond the reference set types and the structure of each reference set type is specified in section .

This section outlines the logical model at the heart of the design of SNOMED CT. It then provides a summary of the ways in which different elements of this logical model are represented in release files. Finally, it provides an overview of the concept definitions that provide the semantic foundation for meaningful processing of clinical information.

This Figure provides a high-level view that illustrates the concept-centric design of SNOMED CT. The subsections below describe the different elements illustrated here.

A concept is defined as a clinical idea to which a unique concept identifier has been assigned.

• SNOMED CT concepts are distributed in the concept file.

SNOMED CT is the most comprehensive and precise clinical health terminology product in the world. It has been developed collaboratively to ensure it meets the diverse needs and expectations of clinicians worldwide and is accepted as a common global language for health terms. SNOMED CT enables meaning-based retrieval and processing of clinical data because it applies description logic techniques to represent the meaning of clinical concepts. As a result, patients and healthcare professionals benefit from improved health records, clinical decisions and analysis, leading to higher quality, consistency and safety in healthcare delivery.

SNOMED International distributes SNOMED CT to its licensees as a package of release files that can be loaded into software applications that enable and optimize access to the terminology.

This document provides the formal specification of the file structures in which SNOMED CT is distributed. The specified file structures apply to the releases of the SNOMED CT International Edition, and to SNOMED CT extensions distributed by Members and Affiliates .

The intended audiences for this guide are those involved in the creating or consuming SNOMED CT release files. This includes:

• SNOMED International staff involved in creating or quality assuring SNOMED CT release files.

A Boolean field that specifies whether an identified component or is an active from the point in time specified by the effectiveTime .

Note: Field name in SNOMED CT Release Format 2.

A field in a 900000000000506000 |Language type reference set| that indicates the acceptability of a Description in the language or dialect specified by that Reference Set . Values include "preferred" and "acceptable".

Note: Field name in a 900000000000506000 |Language type reference set|

Provide Feedback

The string of digits to the left of the partition-identifier (in a short format SCTID) or to the left of the namespace-identifier (in a long format SCTID) is referred to as the item-identifier.

These values are available to uniquely identify an individual entity within the specified partition or namespace. The same item-identifier can be allocated in each partition of each namespace as the SCTID is rendered unique by the partition-identifier and the namespace-identifier. For components in the International Release of SNOMED CT, item-identifiers will usually be issued in the arbitrary order in which components are added to SNOMED Clinical Terms. However, due to management of the editing process the sequence of issued item-identifiers may be discontinuous.

Provide Feedback

The SCTID data type is a 64-bit positive integer.

When rendered as a string an SCTID must always be represented using decimal digits and when rendered as a string has a maximum permitted length of 18 digits and a minimum length of 6 digits.

Note : Leading zeros are always omitted from the string rendering of an SCTID. For example the value "101291009" must not be rendered as "0101291009".

Provide Feedback

"release-package-information.json" file

These files are located in the top-level directory of the SNOMED CT Release packages, and contain various information related to the specific Release package in which they reside.

release-package-information-.json file - Detailed Specification

National Release Centres and others may create additional reference sets. A namespace is required to create a new reference set, as each reference set is defined by a concept. The concept's FSN and a synonym are used to name the reference set. Where a new reference set is created against an existing pattern, then the following naming convention should be used (where the text "Specific name " is to be replaced by the specific name of the reference set).

• FSN = Specific name attribute value reference set (foundation metadata concept )

• PT = Specific name attribute value map

For a Language:

• FSN = Language name [International Organization for Standardization 639-1 code Language code] language reference set (foundation metadata concept )

  • Example: English [International Organization for Standardization 639-1 code en] language reference set (foundation metadata concept)

• PT = Language name

  • Example: English

For a Dialect:

• FSN = Dialect name Language name language reference set (foundation metadata concept )

  • Example: Great Britain English language reference set (foundation metadata concept)

• PT = Dialect code Language name

• FSN = Specific name annotation reference set (foundation metadata concept )

• PT = Specific name annotation reference set

• FSN = Specific name association reference set (foundation metadata concept )

• PT = Specific name association reference set

The active field of each component version indicates whether a component is active or inactive. However, it does not provide any information about why a concept or description has been inactivated. The reason why a concept or description has been inactivated is indicated by a row in a component Inactivation reference set. The reason for inactivation may determine the appropriate way to deal with data in existing records, protocols or queries that use a concept or description after it has been inactivated.

The two component inactivation Reference Sets are shown in the table below.

Component Inactivation Reference Sets

The reason for inactivation is specified by a concept enumeration.

The permitted values for this enumeration for a concept are documented in the Editorial Guide pages on Concept Inactivation, and the type of historical association that should be applied is also provided.

Additionally, the inactivation reasons that may be stated for description inactivation are documented in this page: Description Inactivation

Related Links

• See also the formal specification of .

This section covers several general topics related to SNOMED CT release packages and release files including:

• Release Types

The following two sections provide detailed specifications of the release files.

• Section contains details of release files that represent the main SNOMED CT components:

  • Concepts

  • Descriptions

  • Relationships

Several description logic features, which would improve the completeness and precision of classification, cannot be represented in individual concept definitions.

Property Characteristics

If particular characteristics of the attributes used to define concepts are identified, this can enhance classification. For example, knowing that an attribute like 123005000 |Part of| is transitive would allow the classifier to make infer that an entire finger is part of the entire upper limb.

Property Chains

Property chains are in some ways similar to transitivity but involve more than one attribute. For example, 127489000 |Has active ingredient| can be declared to chain with 738774007 |Is modification of|. In that case, suppose the definition of 387307005 |Calcium carbonate| includes 738774007 |Is modification of| of 5540006 |Calcium|, a DL classifier can determine that a tablet that 127489000 |Has active ingredient| = 387307005 |Calcium carbonate| by definition has a modification of 5540006 |Calcium| as its active ingredient. Thus in the example shown the classifier can determine that |calcium carbonate tablet| is a subtype of |calcium tablet|.

Each SNOMED CT component is managed and maintained in a module identified by its moduleId field.

A SNOMED CT module is defined as a group of SNOMED CT components and/or reference set members managed, maintained, and distributed as a unit.

• Components and reference set members that are part of the same module share the same moduleId value.

• All modules , except the , have dependencies on other modules specified by the .

This section summarizes the ways in which SNOMED CT concept definitions are represented. It outlines the rationale for changes to the way in which the stated view of concept definitions is represented. The changes are occurring during a transitional period that started in July 2018 and is due to be completed in 2019.

A field in the Identifier file containing the representation of an Identifier in another code system that is irrevocably linked to a SNOMED CT identifier .

A SNOMED CT International Release includes three distinct release types. Table 3.2-1 describes the release types and the differences between them.

SNOMED CT Release Types

There are practical use cases for each Release Type.

• The full release allows access to all versions of the release. This is valuable for reviewing data entered using earlier versions and more generally supporting change management.

• The snapshot release only includes the latest version of each component. This can be useful to optimize access to the current version but does not provide access to earlier versions.

• The delta release only includes changes made between one version and the next. This provides a simple way to identify new and changed components to support change management and can also be used to update the previous version of the full release to the new version of the full release. However, the delta release cannot be used as a stand alone resource.

When considering which release type to use, it is worth noting that delta and snapshot views can be readily generated from the full release type. For this reason organizations that maintain SNOMED CT extensions are required to provide the full release type, while distribution of the other release types are optional.

The final digit of the SCTID is a check-digit.

Users should be required to type SCTID values but in some case during design and development it may be necessary to copy or paste identifiers. The objective of the check-digit is to detect the commonest types of error that may occur due to typographical errors on those situations or in other cases where transcription or communication mechanisms may introduce error. Examples may include high-level development such as creating or modifying protocols or pre-specified queries.

An SCTID is checked by using the Verhoeff check, which is a Dihedral D 5 Check. This detects a higher proportion of common typographical errors than either the IBM or Modulus 11 check. Unlike the Modulus 11 check it is effective on decimal strings longer than ten-digits. Furthermore its value can always be represented as a decimal digit without excluding any values.

Related Links

• See Check-Digit Computation for detailed information about the Verhoeff check-digit algorithm and links to sample program code.

• A live site to check a SNOMED CT Identifier can be found here -

This section outlines some of the features of concept definitions and the impact of different ways of representing concept definitions on the precision and completeness of those definitions. This section has been kept as brief as possible and is only intended to raise awareness of the changes. For those interested in understanding more about each of the topics mentioned, a more detailed appendix is provided which illustrates each of the points made in this section.

Provide Feedback

The first four columns in all release files are shown in Table 3.1.3-1. The next three sections of the specification explain the ways in which these fields are used to support identification, versioning and modularization.

Fields present in all release files

This Figure shows how SNOMED CT release files represent the logical model.

The following figure shows how SNOMED CT release files represent the logical model.

Release file representation of the logical model

The following examples conform to the SNOMED CT identifier specification and illustrate a range of possible Identifiers within different partitions and namespaces.

The release file naming convention specified in this section applies to all SNOMED International release files starting with the January 2010 International release. The release package naming convention specified was added subsequently to provide additional clarity through a structured name applied to the folder (and zip archive name) containing a set of release files. This package naming convention first applied to releases by SNOMED International during 2017.

These naming specifications provide the following benefits:

• A consistent naming convention across the International edition and each National edition.

• Predictable file naming, providing a stable structure for naming over time between releases.

An Annotation Reference Set field containing additional information linked to a SNOMED CT component .

Note: Field name in SNOMED CT Release Format 2.

Related Links

• Annotation Reference Set (Deprecated)

Provide Feedback

Provide Feedback

Representation of the Logical Model - Before July 2018

The Figure below shows how SNOMED CT release files prior to July 2018 represented the various elements in the logical model. The revised representation of these elements are shown on in Representation of the Logical Model.

Release file representation of the logical model (before update)

The , was used to represent the stated view of relationships prior to a transition process between July 2018 and July 2019. In July 2019 this file became obsolete and was completely replaced by two (the OWL axiom reference set file and the OWL ontology reference set file).

Figure 1 shows the associations between files that represent the stated and inferred views prior to the transition. It shows the associations between the release files that following these changes.

The stated relationship file is now obsolete as it has been completely replaced by two (the OWL axiom reference set file and the OWL ontology reference set file).

During the transitional period the stated relationship file continued to be distributed, but the OWL axiom reference set introduced advanced aspects to concept definitions which could not be represented in the stated relationship file.

In January 2012 the SNOMED International switched from the original Release Format (used for SNOMED CT distribution since 2002), to the more flexible and consistent Release Format 2 (RF2). This means that from that date onward the primary source data for the SNOMED CT International Release is maintained and distributed in the RF2 format.

The SNOMED International recognizes that, while implementers will which to benefit from the features of the new format, there is inevitably a transitional period during which both format are in use. Therefore, the SNOMED International provides the following resources to support users whose system do not yet support SNOMED CT Release Format 2:

• Release Format 1 files will continue to be included in the International Release for a limited period

  • These files are not the authoritative version of SNOMED CT but are generated from the authoritative RF2 data using a software utility developed for this purpose.

  • The resulting RF1 data retains the functionality of the original release data but does not support any of the features of RF2. While all the clinically relevant SNOMED CT hierarchies are identical in both releases, the additional "Metadata Hierarchy" added as part of the RF2 upgrade is not included in the RF1 converted data. In addition there are some cases where Cross Maps

The "RF2 to RF1 Conversion Tool" and the "RF1 Compatibility Package" are available for Members and Affiliates to download in the same way as the SNOMED CT International Release.

SNOMED CT core release files include metadata concepts that represent each of the allocated namespace-identifiers.

A namespace concept has the following characteristics:

• It is a subtype child of 370136006 |Namespace concept|

• The fully specified name of the concept has the term

  • Extension Namespace {nnnnnnn}(namespace concept)

• A synonym associated with each concept has the term

  • Extension Namespace {nnnnnnn}

• Where appropriate further synonyms may be included to identify the nature of the responsible organization.

As the release file formats contain a number of concept enumerations, it is necessary to define sets of concepts that represent the allowed values. As well as the enumerated values, other metadata supporting the extensibility mechanism and the concept model is required.

The concept is a subtype of the root concept (138875005 |SNOMED CT Concept|), and contains the metadata, supporting the release.

The subtypes of |SNOMED CT Model Component (metadata)| are described in the following table and the top three levels of the hierarchy are shown in the figure below this.

SNOMED CT Model Component (metadata)

This section briefly outlines two distinct types of views of SNOMED CT concept definitions. More detailed illustrations of some of the points on this page are provided in .

SNOMED CT concepts are defined by assertions made by SNOMED CT authors. The concept definitions asserted by SNOMED CT authors are known as the stated view.

The stated view is a representation of concept definitions consisting only of assertions made or revised by SNOMED CT authors.

A description logic classifier can apply logical rules to the stated view to create inferences. The end result of this process is an inferred view of concept definitions.

The inferred view is a representation of concept definitions that is logically derived by applying a description logic classifier to the stated view.

The decision on whether you need access to the stated view and/or inferred view depends on your answers to the following questions.

Purpose

A 900000000000512005 | Query specification type reference set| allows a serialised query 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 to produce a subset of concepts, descriptions or relationships. The query is referred to an intensional definition of the subset. It can be run against future releases of SNOMED CT to generate an updated set of subset members.

The members of the resulting subset may also be represented in an enumerated form as a Simple reference set. An enumerated representation of a subset is referred to as an extensional definition.

Data structure

A Query Specification Reference Set is a String reference set containing query that represent intensional definitions of subsets of components. The result of running the query is an extensional representation of the subset of components which can be represented as a Simple Reference Set. Its structure is shown in the following table.

Query specification reference set - Data structure

The following metadata in the "Foundation metadata concept " hierarchy supports this reference set :

Hierarchy of Foundation metadata concept

The table below shows the descriptor that defines the structure of the pattern.

Descriptor Template for Query Specification Reference Sets

In the example below, "serialised query 1" is a text string that can be used to generate members for Reference set 1 , which is a simple member reference set (without any additional fields within its member records).

Example rows from Query Specification Reference Set

• See for details of the language used to specify intensional definitions of concept subsets.

A provides a standardized way to represent postcoordinated expressions. This representation is useful for the implementation of a postcoordinated expression repository.

A is a type of .

Postcoordinated expression type reference set reference set - Data structure

Associations between Component Files

The logical model of associations between the components in the release files is shown in the Figure below The component class represents columns present in all three component files. The individual classes (description, concept and relationship) only show the additional columns present in those files. The colored lines between descriptions and concepts and between relationships and concepts represent the link between the foreign keys (shown in bold) and the id of the concept. These provide the functional connections between components described in this document. The grey lines indicate additional links between columns that are populated with concept identifiers that provide enumerated values.

A More Complete View of Release File Associations

The below Figure provides an extended view of the associations between release files following changes complete in July 2019 release of SNOMED CT. These changes enable SNOMED CT to use enhanced description logic features and resulted in a significant change to the way in which the stated view of concept definitions are represented. However the changes did not significantly affect the structure and associations between the main component files shown in the Figure above.

The following diagram provides an extended view of the associations between release files following changes complete in July 2019 release of SNOMED CT . These changes enable SNOMED CT to use enhanced description logic features and resulted in a significant change to the way in which the stated view of concept definitions are represented. However, the changes did not significantly affect the structure and associations between the main component files shown in the diagram above.

Each concept is represented by a row in the Concept and the concept is identified by the id column in that row. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same concept. Thus each row represents a version of a clinical concept.

Each concept has two or more descriptions associated with it:

• At least one Fully Specified Name; and

• At least one synonym.

Each description is represented by a row in the description file and is identified by the id column in that row. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same description. Thus each row represents a version of a description. Each description applies to one concept to which it is linked by the conceptId. All versions of a description must relate to exactly the same identified concept (i.e. the conceptId must not change between versions).

Each relationship, from a source concept to a destination concept, is represented by a row in the relationship file. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same relationship. Thus each row represents a version of a relationship. The source, destination and type each relationship are identified respectively by the sourceId, destinationId and typeId columns. All versions of a relationship must have the same sourceId, destinationId and typeId. The typeId refers to concept, that is also held within the concept file. The only concepts that can be used as the relationship typeId are or concepts that are subtypes of .

The most basic form of relationship is the |is a| relationship. This relationship states that one concept is a subtype of another concept. Each subtype concept is connected to its parent subtype(s) by relationships with the typeId 116680003 |is a| and this form the main SNOMED CT hierarchy. In this hierarchy, a child concept may have more than one parent concept. The root of the hierarchy is , which has a set of top level children, each forming its own sub-hierarchy.Relationships with typeid values that are subtypes of |Concept model attribute| are referred to as attribute relationship and contribute to the formal definition of the source concept.

The includes a check-digit, which is generated using Verhoeff's dihedral check. This section explains the algorithm used and includes sample source code for generating and checking the check-digit in Java Script and Microsoft Visual Basic.

The mathematical description of this technique may appear complex but in practice it can be reduced to a pair of two-dimensional arrays, a single dimensional inverse array and a simple computational procedure. These three arrays are shown in the following tables.

• The first array contains the result of "Dihedral D5" multiplication;

• The second array consists of 8 rows of which two are defined while the rest are derived by applying the following formula: F(i, j) = F(i - 1, F(1, j)) ;

The Description holds descriptionsthat describe SNOMED CT concepts. A description is used to give meaning to a concept and provide well-understood and standard ways of referring to a concept.

Description file - Detailed Specification

The is a reference set that is used to specify the format of all reference sets included in a release. The data type and meaning of the referenced component and each additional field within each reference set is described by this reference set .

Reference set descriptor can be used to define

• The order of appearance of additional attributes (other than those mandatory for all reference sets);

• The name and purpose of the additional attributes;

An allows a value from a specified range to be associated with a component. This type of reference set can be used for a range of purposes where there is a requirement to provide additional information about particular concepts, descriptions or relationships. For example, an |Attribute value type reference set| is used to indicate the reason why a concept has been inactivated.

An Attribute value reference set is a component reference set used to apply a tagged value to a SNOMED CT component. Its structure is shown in the following table.

Attribute Value Reference Set - Data Structure

A supports the representation of language and dialects preferences for the use of particular descriptions. The most common use case for this type of reference set is to specify the acceptable and preferred terms for use within a particular country or region. However, the same type of reference set can also be used to represent preferences for use of descriptions in a more specific context such as a clinical specialty, organization or department.

A Language reference set is a Component reference set that is used to indicate which descriptions contain terms that are acceptable or preferred in a particular language or dialect. Its structure is shown in the following table.

Reference Set Types in the Metadata Hierarchy (2018-01-31)

A supports the representation of simple maps from values in other code systems to SNOMED CT concepts. No constraints are put on the number of SNOMED CT concepts mapping to by a particular code. However, this type of reference set is usually only appropriate where there is a close "one-to-one" mapping between the coded values in another code system and SNOMED CT concepts.

A is a String Reference Set used to represent maps from codes in another terminology, classification or code system to SNOMED CT concepts. Its structure is shown in the following table.

Simple map to SNOMED CT reference set - Data structure

An allows attributes to be associated with a valid value range for a given SNOMED CT content type and rule strength. The range of each attribute is defined using an Expression Constraint. This expression constraint represents the set of concepts, expressions, or concrete values that may be used as the value of the given attribute. The also provides a summary of the concept model rule associated with each attribute (including all valid domains and the given range) using an Expression Constraint representation. This attribute rule can be completely auto-generated by combining information from the and the .

An is structured as shown in the following table.