Overview

Content in one module may refer to content in another module. For example, a concept in an extension module may by the source of an | is a| relationship, whose destination is a concept in the international core module. Content dependencies may include:

• Extension concepts with an | Is a| relationship whose destination is in another module

• Extension concepts with a defining attribute relationship whose destination is in another module

• Extension concepts with a defining relationship whose type belongs to another module

• Extension descriptions which are associated with a concept from another module

• Extension reference set members that reference components from another module

• Extension components with properties (e.g. definitionStatusId) that belong to the international

The image below illustrates a local extension module that references content in a national extension, and is therefore dependent on the national extension module; and similarly a national extension module that references content in the International Edition, and is therefore dependent on the international modules.

In this situation, we refer to the local extension as being a 'child' of the national extension 'parent', because the local extension contains a module that is dependent on a module in the national extension. Similarly, the national extension is a 'child' of the International Edition 'parent', because the national extension contains a module that is dependent on a module from the International Edition.

The practical examples below demonstrate how content within a module can rely on another module, either directly or indirectly. As these examples also reference the logical design, the applicable SNOMED CT attributes have been bolded. For more detailed information on these attributes please refer to the

An extension, which includes translations of concepts from the International Edition, will include extension descriptions whose conceptId belongs to the International Edition. Therefore the content in this extension module directly relies on content in a module from the International Edition. As shown in the image below, this content dependency results in a module dependency.

In this example, a local extension contains a simple reference set that represents a subset of concepts. If one or more of the concepts in this subset belong to the National Extension, the extension reference set will contain rows in which the referencedComponentId refers to concepts from a module in the national extension. In this way, content from the local extension module relies on a module from the National Extension. The image below illustrates another example in which a content dependency results in a module dependency.

In this example, the extension includes new clinical content. Because all active concepts in an extension must be subsumed by the root concept, , there must exist at least one relationship in the extension with a destinationId that refers to a concept in another module. Clinical content in the extension module must depend on the international core module either directly or indirectly. The image below illustrates another example in which a content dependency results in a module dependency.

The content dependencies described above create a need to establish a formal link between the dependent module and the modules on which it depends. These dependencies are defined in SNOMED CT at the module level, rather than being defined based on an entire extension. This allows extensions to be subdivided into separate modules, with different dependencies on modules in the same extension, in other extensions, or in the International Edition.

It is important to note that module dependencies are version specific. This means that each module dependency specifies the specific version of the source (child) module that is dependent on a specific version of the target (parent) module. This approach is important as new versions of either the source or target modules may affect the required dependencies.

The extension producer is responsible for specifying the module dependencies for every version of each extension module. Module dependencies are specified by adding rows in the . For more information on this reference set format, please refer to the Module Dependency Reference Set.

It is important to note that all dependencies for each module (including transitive dependencies) must be explicitly stated. For example, the image below illustrates an example in which all 3 dependencies must be explicitly stated: Module C is dependent on Module B, Module B is dependent on Module A and Module C is dependent on Module A.

The first concept to be created in any extension is a module concept. The identifier of this module concept becomes the moduleId to which all extension content is assigned. The moduleId uses the namespace identifier allocated to the extension producer. Additional modules can be created within the same extension, if there is a requirement to maintain or publish sets of components separately. Module concepts must be created as a descendant of 900000000000443000 | Module (core metadata concept)| in a subhierarchy that is dedicated to the given extension provider. For more details about creating new concepts in an extension, please refer to Add Concept in an Extension.

The first module concept in an extension, and its associated descriptions, relationships and language reference set members, must all belong to the given module. This means that the id of the new module concept will match the value assigned to moduleId for that row. Subsequent module concepts can either belong to its own module, or to another module owned by the same extension producer on which the given module depends. The module concept must have the definition status | Primitive| as the | SNOMED CT Model Component (metadata)| hierarchy has no concept model attributes. Please see the following page for information about Module Naming Conventions.

Example

The following example uses the module concept 45991000052106 | SNOMED CT Sweden NRC maintained module| from the Swedish extension. Note that this concept uses the namespace identifier assigned to the Swedish NRC - 1000052. As we can see in the table below, the module identifier appears in the id column and in the moduleId column of the concept table. A value of | Primitive| is used for the definitionStatusId. *1

Table: Module concept in concept table

The table below shows the two necessary descriptions for the module concept in the description table. Note that the same namespace identifier is used as part of the description identifiers.

Table: Module descriptions in description table

The table below shows the required relationship for the module concept in the relationship table. Note that the same namespace identifier is used as part of the relationship identifier.

Table: Module relationship in relationship table

Note that a reference set is also used to specify the language preferences for the module concept. For additional details please refer to

In SNOMED CT, modules are used to organize content for maintenance and publication purposes. All concepts, descriptions, relationships, and reference set members must belong to a module. When a module is published, as part of a release package, all concepts, descriptions, relationships and reference sets that belong to that module must be published together. According to the logical design, this association between a component or reference set member and its associated module is made using the moduleId attribute. The moduleId attribute refers to a concept that represents and names the module in which a component or reference set is currently maintained. All components and reference set members within a module are maintained by a single organization.

SNOMED International Modules

The International Edition includes two modules. The core clinical components of SNOMED CT belong to the | SNOMED CT core module| . Metadata components, which support the specification of the terminology, belong to the | SNOMED CT model component module| . Both these modules are maintained by SNOMED International.

SNOMED International also maintains several other modules that supplement, rather that being part of, the International Edition. These include the | SNOMED CT to ICD-10 rule-based mapping module| and the | LOINC - SNOMED CT Cooperation Project module| .

Member and Affiliate Modules

Components and reference sets maintained by Members and Affiliate licensees are also organized into one or more modules. The module concepts used for this purpose must be created and maintained by the same organization. In most cases, the module concept and its associated descriptions and relationships will belong to the same module to which its identifier refers.

The table below lists some examples of modules, together with the organization responsible for maintaining and distributing the contents of the module. Note that the namespace identifier (highlighted in red) used in the module identifier refers to the organization who is responsible for that module. ^*1

Table: Examples of modules

The table below includes a subset of columns and rows from the description file in the 20170301 US Edition. Note that the preferred term of the moduleId is included in the table for readability.

Table: Descriptions assigned to different modules in the US Edition

The example above reinforces some key points. Firstly, all components belong to exactly one module, as identified by the moduleId. Secondly, an edition may include components that belong to modules maintained by different organizations.