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 . 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.
The includes two modules. The core clinical components of SNOMED CT belong to the. Metadata components, which support the specification of the terminology, belong to the . 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 theand the.
Components and reference sets maintained by and 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 module concept may, alternatively, belong to a different module maintained by the same organization. When this is the case, the module will necessarily depend upon the module that contains its identifying concept. It is therefore usually simpler to keep the module concept within the module it identifies. |
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.
Examples of modules |
|
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.
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.