Content Dependencies

Content in one module may refer to content in another module. This is because components and derivatives in SNOMED CT will refer to other components which may be part of a separate module. Dependencies on other modules include references to:

• Concepts that are the destination of | Is a|  relationships
• Concepts that represent values of defining attribute relationships
• Concepts that represent the type of defining attribute relationships
• Concepts to which additional descriptions are applied
• Concepts, descriptions and relationships that are identified in any reference set member

Clarification of Terms

 aims to clarify the terms used when discussing dependencies in SNOMED CT. Note that the use of the word dependent in SNOMED CT is consistent with the meaning of the word in the English language.

When referring to dependencies in SNOMED CT, the dependencies work upward in a similar way that a child depends on its parents. In the diagram above, the grey arrows indicate that the local module depends on the national module which depends on the International module. In others words, the local module is dependent on the national module which is dependent on the International module. However, because the local and national module depend on other modules, we could also say that the local and national modules are dependents, as a child is dependent on their parent. A dependent is something that depends on something else and not the other way around. The only module in the diagram with no dependencies is the International module. Hence, it is not a dependent. The only module which is not depended on by other modules is the local module. Hence, it is not depended on.

Examples

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 SNOMED CT Release File Specifications.

Translation of Concepts

An extension which provides translations of concepts from the International edition will include descriptions with a conceptId that can only be resolved by looking at the International Edition. Therefore the content in this extension's module directly relies on a module in the International Edition.  depicts an example which necessitates a module dependency based on this content dependency.

Defining Subsets of Concepts

A local extension contains a simple refset representing a subset of concepts. If one or more of those concepts are in a National extension, the refset will contain one or more rows in which the referencedComponentId refers to a concept which belongs to a module in that national extension. Therefore content in this local extension's module relies on a module in a National extension.  depicts an example which necessitates a module dependency based on this content dependency.

Adding Concepts

An extension has a requirement to add new clinical content. Note that all active concepts in an extension must be subsumed by the root concept, |SNOMED CT Concept|. This means that at least one  | is a| relationship in the extension must have a destinationId which refers to a concept that is NOT in the extension. Therefore content in the extension's module relies on an International Edition module, either either directly or indirectly.  depicts an example which necessitates a module dependency based on this content dependency.

Module Dependencies

These content dependencies described above create a need to establish a formal linkage between modules. This linkage is established by specifying that one module is dependent on another. Dependencies in SNOMED CT are defined at the module level which is more specific than the extension level because an extension may contain more than one module. This allows extensions to be subdivided in to separate modules with different dependencies on another module in the same extension, in other extensions, or in the International Edition.

Note that module dependencies are version specific. Each module dependency specifies the date specific version of both the source and target modules. This is necessary because changes in a new version of the target module may not be compatible with the current version of the source module.

Specifying Module Dependencies

An organization maintaining an extension must include a formal representation of the module dependencies for every version of each module they release. Module dependencies are specified using rows in the | Module dependency reference set| . For more information on this refset structure, please refer to Module Dependency Reference Set.

Non-Transitivity of Module Dependencies

Note that the dependencies between modules are not transitive. All the dependencies of each module must be explicitly stated.

For example, in, Module C is dependent on both Module B and Module A because content in Module C references content in both modules. Even though Module B has a stated dependency on Module A, it is still necessary to explicitly state that Module C depends on Module A.