Purpose

The

...

The 900000000000534007 $$

...

Data structure

The

...

The

...

...

...

Field

...

Data type

...

Purpose

...

id

...

UUID

...

A 128 bit unsigned integer, uniquely identifying this reference set member .
Different versions of a reference set member share the same id but have different effectiveTimes. This allows a reference set member to be modified or made inactive (i.e. removed from the active set) at a specified time.

...

effectiveTime

...

Time

...

The inclusive date or time at which this version of the identified reference set member became the current version.
The current version of this reference set member at time T is the version with the most recent effectiveTime prior to or equal to time T .

...

active

...

Boolean

...

The state of the identified reference set member as at the specified effectiveTime .
If active = 1 (true) the reference set member is part of the current version of the set, if active = 0 (false) the reference set member is not part of the current version of the set.

...

moduleId

...

SCTID

...

Identifies the SNOMED CT module that contains this reference set member as at the specified effectiveTime .
The value must be a subtype of 900000000000443000 $$ Module (core metadata concept) $$ within the metadata hierarchy .
In this reference set, moduleId also refers to the dependent source module. Thus each module contains the rows of the 900000000000534007 $$ Module dependency reference set $$ that represent its dependencies on other modules .

...

refsetId

...

SCTID

...

Identifies the reference set to which this reference set member belongs.
In this case, set to 900000000000534007 $$ Module dependency reference set $$

...

referencedComponentId

...

SCTID

...

The identifier of a target module on which the dependent module (identified by moduleId) depends. Thus must be a subtype of 900000000000443000 $$ Module (core metadata concept) $$ .

...

sourceEffectiveTime

...

Time

...

The effective time of the dependent source module (identified by moduleId). This specifies a version of that module, consisting of all components that have the same moduleId as this refset member in their states as at the specified targetEffectiveTime .

...

targetEffectiveTime

...

Time

...

The effective time of the target module required to satisfy the dependency (identified by referencedComponentId). This specifies a version of that module, consisting of all components with the moduleId specified by referencedComponentId in their states as at the specified targetEffectiveTime .

Rules and Guidance

Introduction to Modules

Each row in the release files for components and reference set members has a 

A module is simply a collection of 

A module is represented by a 

At any point in time a 

Introduction to Module Dependencies

Each 

The 

At the point of release, if any 

Identifying and Versioning Module Dependencies

id

The recommended practice is for the refset.id column to contain the same identifier for all versions of the dependencies between the same pair of modules. This approach means that at any given time only one version of each module has effective dependencies. The dependencies of earlier versions can be reviewed by reviewing a snapshot for the effectiveTime of the earlier release.

effectiveTime

The effectiveTime of at least one row for each pair of modules should be the same as the sourceEffectiveTime. Otherwise, there will be a period of time when a snapshot view will not show the dependencies. However, it is theoretically possible for an additional row to be added with a later effectiveTime in cases where an otherwise unchanged release of an extension, declares itself to be compatible with an updated release of the target module (in this case the effectiveTime and targetEffectiveTime are changed but the sourceEffectiveTime remains unchanged.

active

A module dependency only needs to be inactivated if the dependency is found to be erroneous. This is because, the module dependency is specific to a particular version of the source and target module. Therefore, if that dependency was valid at the outset it remains valid indefinitely in respect of those specified module versions, even if the dependencies between subsequent versions differ.

refsetId

Module version dependencies are represented using a single

...

Module version dependencies are represented using a single 900000000000534007 $$ Module dependency reference set $$. Thus all module dependency rows have the same refsetId (

It is the responsibility of the organization owning and maintaining a dependent module to identify all modules on which it depends. They do this by adding rows to the

Module Identification

Source Module  (moduleId)

The 

Target Module (referencedComponentId)

The target module on which the source module depends is identified by the

A module version may depend on one or more other module versions, and many module versions may have a dependency on a single module version. Cyclic module version dependencies are not allowed. If module-A depends on module-B, then module-B cannot depend on module-A.

Dependencies are not transitive and this means that dependencies cannot be inferred from a chain of dependencies. If module-A depends on module-B and module-B depends on module-C, the dependency of module-A on module-C must still be stated explicitly.

Any release should consist of a set of module versions that are certified as being compatible. Each release should also identify other module versions that it is dependent on even when these are outside the scope of the release. For example, the dependencies of modules in an Extension on the International Release must be stated.

Dependencies are specified between module versions, not just dependencies between modules. Therefore, it is possible to specify a dependency from a module released on one date to an earlier version of another module. The version of the dependent module is specified by the

...

...

Metadata

The following metadata in the "Foundation metadata

...

  900000000000454005 |Foundation metadata concept|
		900000000000455006|Reference set|
				900000000000534007 |Module dependency|

...

• 900000000000534007 $$ Module dependency $$

Figure 17. Module Dependency Reference Set in the Metadata Hierarchy
Each component within a SNOMED CT release references a moduleId. This is the module that the component is currently mastered in (from the effectiveTime held on the component record). A module is simply a collection of SNOMED CT components that are maintained as a unit by a single organization. It is the organization 's responsibility to organize the components in each extension that it is responsible for into one or more modules, in a way that best fits its business needs.
A module is modeled by a descendant of 900000000000443000 $$ Module $$ in the metadata hierarchy. The 900000000000443000 $$ Module $$ sub - hierarchy is organized by a maintaining organization into a number of groups. For example, all modules maintained by IHTSDO will be children of 900000000000445007 $$ IHTSDO maintained module $$. The 900000000000443000 $$ Module $$ sub-hierarchy models modules maintained by each organization and does NOT model module dependencies. Instead, module dependencies are modeled using the 900000000000534007 $$ Module dependency reference set $$ .
At the point of release, if any component within a module has changed, then a new row will be added to 900000000000534007 $$ Module dependency reference set $$ for the module's concept, with the effectiveTime set to the date of the new release, irrespective of whether the other fields in the module concept record itself have changed. The updated |Module| concept record identifies that some components within the module have been updated in this release. Where no components within a module have been updated, then a new module record will not be added and the module's effectiveTime field will not change from the previous release.
Each component will be in one, and only one component. The module that a component is mastered in may change over time, and when this happens, the component's moduleId field will be updated (in the usual way by appending a row for the component).
Each module will be in one and only one extension. Modules will not straddle extensions. The extension that a module resides in is defined by the SCTID of the module. A module may not move from one extension to another over time. If the components within a module are to be moved to another extension, then a new module must be created within the destination extension to host the components that are to be transferred.
There may be more than one module in an extension .

...

Descriptor

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

Note: The table above omits the initial four columns of data present in the release file. These follow the standards versioning pattern

...

Example Data

Example

...

The table below holds example entries for the

This

• Concept
  t 900000000000012004|

  Anchor_6d6f9e33-8512-41ca-a84f-e1ce5e2d480b__u_6d6f9e33-8512-41ca-a84f-e1ce5e2d480b__u900000000000012004 $$

  SNOMED CT model component

  $$

  |

  which has no dependencies;

• Concept
  t 900000000000207008

  $$

  |SNOMED CT core

  $$

  |

  which depends on the

  Concept
  t 900000000000012004

  $$

  |SNOMED CT model component

  $$

  |

  ; and

• Concept
  t 449080006

  $$

  |SNOMED CT to ICD-10 rule-based mapping module

  $$

  |

  which depends on both the other modules.

In this case all the 2014-01-31 modules depend on 2014-01-31 versions of the other modules. However, in some case a module may depend on an earlier version of another model (e.g. an extension module may be releases after the

Dependencies are not transitive. The fact that

...

...