Most extensions include additional concepts, descriptions and/or relationships. It is therefore important for extension producers to understand the logical design of these components, and any extension-specific rule related to these components.

The following subsections present logical design rules and considerations for components in an extension:

• Common Attributes

• Concepts

• Descriptions

• Relationships

For information about the process of authoring extension components, please refer to . For a full list of RF2 component tables and their attributes, please refer to the SNOMED CT Release File Specifications.

Provide Feedback

Overview

Concepts can be added to an extension, either to address content gaps or to expand the scope of SNOMED CT to include concepts that are used locally. Extension concepts are distributed in a , which follows the standard RF2 release file format. For more details on the principles and processes for authoring concepts in an extension, please refer to Authoring Concepts.

Attributes

In addition to the four common attributes, extension concepts also have a definitionStatusId.

definitionStatusId

The definitionStatusId attribute specifies whether the concept is primitive or fully defined. If defining relationships are added, which sufficiently define the concept, then the definitionStatusId should be set to | Defined| . Otherwise, the extension concept is | Primative| .

Example

In the image below, a row from the concept table of the 20170901 US edition is shown, which represents the concept 5281000124103 | Persistent asthma| .

Note that the attribute values in this row have been set according to the rules previously described.

Please note the following:

• The concept id uses a namespace identifier allocated to the National Library of Medicine (NLM). This indicates that this concept was originally created by the NLM.

• The concept id uses a partition identifier of “10”. This indicates that the concept was created in an extension.

• The moduleId indicates that this concept is included in the , which is a module in the US Edition.

• The definitionStatusId states that this concept is .

Relationships

Overview

Relationships are added in an extension to link a new concept to one of its supertypes, or to specify defining attribute relationships. Note that at least one hierarchical ( | Is a| ) relationship is required for each new extension concept. Extension relationships are distributed in a , which follows the standard RF2 release file format. For more details on the principles and processes for authoring relationships in an extension, please refer to Authoring Relationships.

Attributes

In addition to the four common attributes, relationships also have a sourceId, destinationId, relationshipGroup, typeId, characteristicTypeId and modifierId.

sourceId

The sourceId identifies the concept being defined by the relationship. In the case of a hierarchical ( | Is a| ) relationship, the sourceId refers to the subtype/child concept.

destinationId

The destinationId represents the value of the defining relationship. In the case of a hierarchical ( | Is a| ) relationship, the destinationId refers to the supertype/parent concept. The destinationId may refer to a concept in the same extension module as the source concept, or any module on which this extension module depends.

relationshipGroup

The relationshipGroup is an integer that indicates whether or not the relationship is grouped together with other relationships associated with the same source concept. Any relationships with the same sourceId and relationshipGroup integer (other than zero) are considered to belong to the same relationship group. A relationshipGroup of zero (i.e. "0") indicates that the relationship was not grouped with other relationships by the terminology author. For more information on relationship groups, please refer to Relationship groups in SNOMED CT.

The typeId is a SCTID that specifies the attribute type of the relationship. In the case of a hierarchical relationship, the value of this attribute is . Attribute relationships use a typeId value that refers to a subtype of . Common examples of attribute types include and .

In most cases, the typeId will refer to an international concept. However, additional attribute concepts may be added in an extension if there is a legitimate clinical need, and clear rules and guidance is provided. For more information, please refer to .

The characteristicTypeId is a SCTID, which specifies whether this relationship was stated by an author or was inferred by a description logic classifier. For more information, please refer to .

The modifierId attribute is a SCTID which specifies the type of description logic that applies to the given relationship - existential restriction (i.e. 'there exists some') or universal restriction (i.e. 'there exists only'). All relationships in the International Edition use the value . This value is also recommended for extension relationships, as the value can significantly affect the speed of classification.

In the image below two rows from the relationship table of the 20170901 US edition are shown. Note that these relationships are used to define the extension concept from the earlier .

Please note the following:

• The relationship ids use a namespace identifier allocated to the National Library of Medicine (NLM). This indicates that these relationships were originally created by the NLM.

• The relationship ids use a partition identifier of “12”. This indicates that the relationships were created in an extension.

• The moduleId indicates that these relationships are included in the . This is the same module as the source concept belongs to.

• The sourceId indicates that the relationship defines the concept

Once a concept exists, which identifies the reference set being populated, the individual reference set members can be added as rows to the associated reference set file.

In this section, we discuss an example reference set, and explain how its members are represented in an extension.

The table below shows a set of rows from a in the 20170430 Canadian extension.

Table 4.3.2.3-1: Simple reference set example

Module Dependency Reference Set

Every extension must contain at least one module, which is used to organize the extension content. The dependencies that the extension modules have on other modules (including on the | SNOMED CT core module| and the | SNOMED CT model component module| ) must be specified in the extension. This is done by adding new members to the | Module dependency reference set| . Each new versioned release of the extension requires a new version to be created for each extension member of the | Module dependency reference set| .

Attributes

As previously mentioned, all reference sets use six common attributes. In addition to these, a | Module dependency reference set| also includes a sourceEffectiveTime and targetEffectiveTime. The table below explains how each of these attributes is populated in a | Module dependency reference set| .

Table: Summary of module dependency reference set attributes

The table below shows three rows from the in the 20170301 US Edition of SNOMED CT. Please note that the SCTIDs in the moduleId and referenceComponentId columns have been replaced with their preferred terms for improved readability.

Table: Module dependency reference set rows

Please note the following:

• The first row states that the 20170731 version of the source module is dependant on the 20170731 version of the target module .

• The second row states that the 20170901 version of the source module is dependant on the 20170731 version of the target module .

• The third row states that the 20170901 version of the source module is dependant on the 20170731 version of the target module . Note that this is an example of a transitive dependency that must be explicitly stated.

Descriptions

Overview

A description may be created in an extension as part of the process of adding a new concept, or adding a translation or alternative synonyms to an existing concept. Extension descriptions are distributed in a which follows the standard RF2 release file format. For more details on the principles and processes for authoring descriptions in an extension, please refer to Authoring Descriptions.

Attributes

In addition to the four common attributes, descriptions also have a conceptId, languageCode, typeId, term and caseSignificanceId.

conceptId

The conceptId attribute links the description to the concept that it describes. The conceptId may refer to a concept in the same extension module or to a concept in a module on which the extension module depends.

languageCode

The languageCode is a two-character string, which specifies the language of the description using the ISO 639-1 standard (e.g. 'EN', 'ES'). Please note that the languageCode specifies only the language of the description (e.g. English or Spanish) and does not indicate the dialect (e.g. US English or GB English). Dialect preferences are represented by language reference sets. Extensions may use a languageCode not used by the International Edition.

typeId

The typeId is a SCTID that specifies the type of the description. The value of this attribute must be a descendant of | Description type| . Possible values include | Fully specified name| , | Synonym| , and | Definition| . Note that | Definition| is used for text definitions, which are not included in the main description distribution files. Instead, descriptions of type | Definition| are distributed in a separate text definitions file.

The term attribute is a text string that describes the given concept. The term is represented using UTF-8, which allows non-English character sets to be used, such as the accented characters used in Nordic languages, Hindi characters and Chinese characters. The maximum length of a fully specified name or synonym is defined in the as 255 characters. Longer terms can be used for text definitions, which may be up to 4096 characters in length.

The caseSignificanceId attribute is a SCTID which specifies how the case of the characters in the term may be changed when using the term. The values of this attribute always refer to descendants of the concept , and at the time of this publication, the three possible values are , ,or .

In the image below a row is presented from the descriptions table of the 20170901 US edition. Note that this description is associated with the extension concept from the previous example.

Please note the following:

• The description id uses a namespace identifier allocated to the National Library of Medicine (NLM). This indicates that this description was created by the NLM.

• The description id uses a partition identifier of “11”. This indicates that the description was created in an extension.

• The moduleId indicates that this description is included in the , which is the same module that the associated concept (from the previous example) is included in.

• The description id and the conceptId both use a namespace identifier owned by the NLM. This indicates that this description is associated with a concept created by the same extension producer.

In the image below a row is presented from the descriptions table of the 20170430 Canadian edition. Note that this description is associated with a concept from the International Edition.

Please note the following:

• The description id uses a namespace identifier allocated to Canada Health Infoway (CHI). This indicates that this description was created by the CHI.

• The description id uses a partition identifier of “11”. This indicates that the description was created in an extension.

• The moduleId indicates that this description is included in the .

• The conceptId refers to the concept from the International Edition. This indicates that this term may have been created as a language specific term for an international concept.

Common Attributes

Reference sets use a range of different attributes depending on the reference set type. While a detailed discussion of all reference set attributes is outside the scope of this document, this section briefly reviews some of the key attributes. Please refer to in the Practical Guide to Reference Sets for more information on reference set types and their specific attributes. Please refer to 5.4.5 Authoring Reference Sets and Authoring Reference Set Members for more information on the principles and processes for authoring reference sets and their members.

All reference sets share six common attributes:

• id

• effectiveTime

• active

• moduleId

• refsetId

• referencedComponentId

The following subsections explain how these attributes are used in an extension.

The first attribute of every extension reference set member is 'id '. Unlike the id of a SNOMED CT component, the id of a reference set member is a UUID (Universally Unique Identifier). UUIDs are 128-bit unsigned integers, which are uniquely generated using widely available algorithms. This avoids the need to track the issuing of SCTIDs for thousands of reference set rows. When used in a reference set, the id identifies the reference set member or row.

Table: Example UUIDs

The second attribute of every extension reference set member is 'effectiveTime '. This attribute specifies the date on which the specific version of the reference set member was released, using the ISO 8601 YYYYMMDD format. When a reference set member is added or modified in an extension, the effectiveTime of the member version will match the version date of the release.

The third attribute of every extension reference set member is 'active '. This attribute specifies whether or not the specific version of the reference set member is active at the given effectiveTime. The data type of this attribute is Boolean, with a value of "1" indicating that the member is active at the given effective time and a value of "0" indicating that the member is inactive at the given effectiveTime. New reference set members in an extension will use an active value of "1".

The fourth attribute in every extension reference set member is 'moduleId '. This attribute specifies the module in which the member is being maintained at the given effective time. The value of this attribute is the SCTID of a module concept that is created and maintained by the extension producer. Please refer to for more information on this topic.

The fifth attribute in every extension reference set member is 'refsetId '. This attribute refers to the id of the reference set concept that is used to represent the meaning of the reference set to which the given member belongs. The reference set concept must be a subtype of . The descriptions associated with this concept help to name the reference set. For more information, please refer to .

The sixth attribute of every extension reference set member is 'referencedComponentId '. This attribute uses a SCTID to identify the component that is referenced by this member of the reference set. For example, the referencedComponentId may refer to a member of a subset represented by a , to the description whose acceptability is being defined in a , or to the source of map in a .

Reference Set Example

All reference sets require a concept to be created that represents the meaning of the reference set, provides the identification of the reference set, and names the reference set. These reference set concepts are created in the | Reference set (foundation metadata concept)| subhierarchy as subtypes of a reference set concept that represents the associated reference set pattern. For more information about creating a reference set concept in an extension, please refer to Create New Reference Set in an Extension.

In this section, we discuss an example reference set concept ( | Route of administration reference set| ) from the 20170430 Canadian extension, and explain how this concept and its associated descriptions, relationships and language preferences are represented.

Reference Set Concept

In the image below, a row from the concept table is shown for the concept | Route of administration reference set| .

Please note the following:

• The concept id uses a namespace identifier allocated to Canada Health Infoway.

• The concept id uses a partition identifier of “10” to indicate that this concept was create in an extension.

• The moduleId indicates that this concept belongs to the .

• The definitionStatusId indicates that this concept is . Please note that all metadata concepts in SNOMED CT are .

In the image below, a set of rows from the description table are shown. These descriptions provide terms that describe the concept .

Please note the following:

• The description id uses a namespace identifier allocated to Canada Health Infoway.

• The description id uses a partition identifier of “11” to indicate that these descriptions were created in an extension.

• The moduleId indicates that these descriptions belong to the .

• The conceptId links the descriptions to the reference set concept .

In the image below, a row from the relationship table is shown. This relationship defines the supertype concept of .

Please note the following:

• The relationship id uses a namespace identifier allocated to Canada Health Infoway.

• The relationship id uses a partition identifier of “12” to indicate that this relationship was originally created in an extension.

• The moduleId indicates that these relationships belong to the .

• The sourceId indicates that the relationship applies to the concept .

In the image below, a set of rows from the are shown. These rows define the language preferences for the descriptions associated with the concept .

Please note the following:

• The id is a UUID that was generated for the corresponding refset member.

• The moduleId indicates that these refset members belong to the .

• The refsetId column indicates that these rows are members of the . Note, that if the relevant language reference set does not exist, this must be created using the same process.

• The referencedComponentId column refers to the descriptions for which the acceptability is being specified.

Extensions

A SNOMED CT extension is a set of components and reference set members that add to the SNOMED CT International Edition. An extension is created, structured, maintained and distributed in accordance with SNOMED CT specifications and guidelines. Unlike, the International Edition an extension is not a standalone terminology. The content in an extension depends on the SNOMED CT International Edition, and must be used together with the International Edition and any other extension module on which it depends.

Modules in an Extension

As explained in modules, every extension must contain at least one module, and all content in an extension must belong to one of its extension modules. More than one module can be created within the same extension, if there is a business requirement to maintain or publish sets of components separately. The set of module concepts that are maintained by the same extension producer are grouped together in a single module subhierarchy. The figure below shows the module subhierarchy for the UK's National Release Center from the 20170401 UK Edition.

Please note that some module concepts in the subhierarchy (e.g. | United Kingdom maintained clinical module (core metadata concept)| )serve as grouper concepts, which are never actually used as the moduleId of any content. The use of separate modules in the UK extension allow them to maintain and publish separate editions that include different content (e.g. with and without the drug extension). Using separate modules also allows module-based filters to be applied when searching content for a specific use case.

Extension Versions

A specific version of an extension can be referred to using the date on which the extension was published. Versioned extension modules can be identified using the SNOMED CT URI standard format: http://snomed.info/module/{sctid}/time/{timestamp}. For more information, please refer to 2.4 and

Language Reference Set

Whenever a new description is added in an extension, the language preferences associated with that description must be specified. This is done by adding rows to a language reference set to indicate whether each description is | acceptable| or | preferred| in the given language or dialect.

Attributes

As previously mentioned, all reference sets use six common attributes. In addition to these, a | Language type reference set| also includes an acceptabilityId. The table below explains how each of these attributes is populated in a | Language type reference set| .

Table: Summary of language reference set attributes

In the image below, two rows from the are shown. Note that these rows specify French Canadian language preferences for the concept .

Please note the following:

• The id column shows a UUID that has been uniquely generated for each refset member.

• The moduleId indicates that these refset members belong to the .

• The refsetId indicates that both members are part of the .

• The referencedComponentId indicates the description for which the acceptability is being specified.

Common Attributes

All components in an extension are represented using the same logical design as the International Edition. Concepts, descriptions and relationships all share four common attributes:

• id

• effectiveTime

• active

• moduleId

The following subsections explain how these attributes are used in an extension.

The first attribute of every extension component is 'id '. The id uniquely identifies the component across all extensions globally. It is therefore important that extension identifiers are structured according to agreed rules. The image below shows the four parts of an extension SNOMED CT identifier (SCTID) - item identifier, namespace identifier, partition identifier and check digit.

The table below explains the rules related to each of the four parts of a SNOMED CT identifier in an extension.

Table: Rules for each part of an extension SCTID

The second attribute of every extension component is 'effectiveTime'. This attribute specifies the date on which the specific version of the component was released, using the ISO 8601 YYYYMMDD format. When a component is added or modified in an extension, the effectiveTime of the component version will match the version date of the release.

The third attribute of every extension component is 'active '. This attribute specifies whether or not the specific version of the component is active at the given effectiveTime. The data type of this attribute is Boolean, with a value of "1" indicating that the component is active at the given effectiveTime and a value of "0" indicating that the component is inactive at the given effectiveTime. New components in an extension will use an active value of "1".

The fourth attribute in every extension component is 'moduleId '. This attribute specifies the module in which the component is being maintained at the given effective time. The value of this attribute is the SCTID of a module concept that is created and maintained by the extension producer. Please refer to for more information on this topic.

All extensions must specify their extension module dependencies and language preferences. In this section, we describe the essential reference sets that support this.

• Language Reference Set

• Module Dependency Reference Set