Purpose

The

scg-expression

Concept

ShowParts

id+

term
t	900000000000534007\|Module

dependency

reference

set|

represents dependencies between different release . In each case

Gloss

PreSpace	false
t	SNOMED CT

release

Gloss

PreSpace	false
t	modules

. In each case, the dependency indicates which targetEffectiveTime

Specref

RefType	(field)
t	targetEffectiveTime

of each particular

Gloss

PreSpace	false
t	module

a given sourceEffectiveTime

Specref

RefType	(field)
t	sourceEffectiveTime

of the dependent

Gloss

PreSpace	false
t	module

requires.

...

Data structure

The

Concept

t	900000000000534007\|Module dependency reference set\|

is a

...

The is a String

Specref

RefType

(data type)

- String


t	String

-

Specref

RefType	(data type)

which


t	String

Gloss

PreSpace	false
t	reference set

which is used to represent dependencies between

Gloss

PreSpace	false
t	modules

, taking account of

Gloss

PreSpace	false
t	module

versioning. Its structure is shown in the following table.

...

Field

...

Data type

...

Purpose

...

id (field)

...

UUID (data type)

...

A 128 bit unsigned Integer (data type), uniquely identifying this .

Different versions of a reference set member share the same id (field) but have different effectiveTime (field). This allows a reference set member to be modified or made active (field) (i.e. removed from the active set) at a specified time.

...

effectiveTime (field)

...

Time (data type)

...

The inclusive date or time at which this version of the identified became the current version.

The current version of this at time T is the version with the most recent effectiveTime (field) prior to or equal to time T .

...

active (field)

...

Boolean (data type)

...

The state of the identified as at the specified effectiveTime (field) .

If active (field) = 1 (true) the is part of the current version of the set, if active (field) = 0 (false) the is not part of the current version of the set.

...

moduleId (field)

...

SCTID (data type)

...

Identifies the that contains this as at the specified effectiveTime (field) .

The value must be a of

Scg expression

ShowParts	id+term

900000000000443000|Module (core metadata concept)|

within the metadata .

In this , moduleId (field) also refers to the dependent source . Thus each contains the rows of the

Scg expression

ShowParts	id+term

900000000000534007|Module dependency reference set|

that represent its dependencies on other .

...

refsetId (field)

...

SCTID (data type)

...

Identifies the to which this belongs.

In this case, set to

Scg expression

ShowParts	id+term

900000000000534007|Module dependency reference set|

...

referencedComponentId (field)

...

SCTID (data type)

...

The identifier of a target on which the dependent (identified by moduleId (field)) depends. Thus must be a of

Scg expression

ShowParts	id+term

900000000000443000|Module (core metadata concept)|

.

...

sourceEffectiveTime (field)

...

Time (data type)

...

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

...

targetEffectiveTime (field)

...

Time (data type)

...

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

Refset spec table

Size	fs7
RefsetType	Module Dependency Reference Set

Rules and Guidance

Introduction to Modules

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

Specref

RefType	(field)
t	moduleId

. This refers to the

Gloss

PreSpace	false
t	module

that the component is maintained in. Each module is either part of the

Gloss

PreSpace	false
t	SNOMED International Release

or part of a single

Gloss

PreSpace	false
t	SNOMED CT Extension

. The

Specref

RefType	(field)
t	moduleId

has a

Gloss

PreSpace	false
t	partition-id

which indicates whether it is part of the

Gloss

PreSpace	false
t	SNOMED International Release

and, if not, its

Gloss

PreSpace	false
t	namespace identifier

indicates the

Gloss

PreSpace	false
t	SNOMED CT Extension

that it belongs to.

A module is simply a collection of

Gloss

PreSpace	false
t	SNOMED CT components

maintained as a unit by a single organization. It is the organization 's responsibility to organize the components in each

Gloss

PreSpace	false
t	extension

that it is responsible for into one or more modules, in a way that best fits its business needs.

A module is represented by a

Gloss

PreSpace	false
t	descendant

of

Concept

t	900000000000443000\|Module\|

in the metadata

Gloss

PreSpace	false
t	hierarchy

. The immediate subtype descendants of

Concept

t	900000000000443000\|Module\|

represent groups of modules maintained by an organization and subtypes of these can be used to arrange that organizations modules into a number of groups. For example, all modules maintained by

Gloss

PreSpace	false
t	SNOMED International

will be

Gloss

PreSpace	false
t	children

of

Concept

t	900000000000445007\|SNOMED International maintained module\|

.

At any point in time a

Gloss

PreSpace	false
t	component

must be in one, and only one module. It is possible for components and reference set members to be moved between modules (subject to constraints explained elsewhere). In this case, a new row is added to the release file with the same

Specref

t	id

but with a new

Specref

RefType	(field)
t	effectiveTime

and a new

Specref

RefType	(field)
t	moduleId

.

Introduction to Module Dependencies

Each

Gloss

PreSpace	false
t	extension

must include one or more modules. Each module must be part of either the

Gloss

PreSpace	false
t	SNOMED International Release

or one and only one

Gloss

PreSpace	false
t	extension

. A module may not move from one

Gloss

PreSpace	false
t	extension

to another over time. If components or reference set members in a module are to be moved from an

Gloss

PreSpace	false
t	extension

to the

Gloss

PreSpace	false
t	SNOMED International Release

or to another

Gloss

PreSpace	false
t	extension

, they must either be added to an existing or newly created module maintained by the destination organization.

The

Concept

t	900000000000443000\|Module\|
ShowFormat	inline

Gloss

PreSpace	false
t	sub-hierarchy

does NOT represent dependencies between module. Instead, module dependencies are modeled using the

Concept

t	900000000000534007\|Module dependency reference set\|

.

At the point of release, if any

Gloss

PreSpace	false
t	component

within a module has changed, then a new row must be added to the

Concept

ShowParts	term
t	900000000000534007\|Module dependency reference set\|

for each dependency of that module. The

Specref

RefType	(field)
t	effectiveTime

of the added rows must set to the date of the new release. The updated

Concept

ShowParts	term
t	900000000000534007\|Module dependency reference set\|

records indicate that some components within the module have been updated in this release. If there have been no additions, updates or inactivations of components or reference set members within a module, then a new

Concept

ShowParts	term
t	900000000000534007\|Module dependency reference set\|

records need not be added unless there is a requirement to declare that the unchanged module is compatible with a later release of the module(s) on which it dependents.

Identifying and Versioning Module Dependencies

id

The recommended practice is for the refset.id column to contain

...

Module version dependencies are represented using a single

Scg expression

ShowParts	id+term

900000000000534007|Module dependency reference set|

. Thus all module dependency rows have the same refsetId (

Scg expression

ShowParts	id

900000000000534007|Module dependency reference set (foundation metadata concept)|

).

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

Scg expression

ShowParts	id+term

900000000000534007|Module dependency reference set|

within the dependent module. Because these added member must be in the dependent module, the moduleId (field) of the member record is also the identifier of the dependent (source) module. The target module on which the source module depends is identified by the referencedComponentId (field) .

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 sourceEffectiveTime (field) and the version of the module on which it depends is specified by the targetEffectiveTime (field).

Note: Current practice assumes the refset.id column contains 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. Therefore, to review the The dependencies of an earlier version, earlier versions can be reviewed by reviewing a snapshot for an earlier time must be checked. the effectiveTime of the earlier release.

Info

title	Value of the id column

An alternative approach has been suggested by some people in which a new identifier is allocated to each dependency of each module. This would then mean that all past dependencies would be visible in a snapshot view. It would also mean that it would be possible release updated dependencies for an existing module version while also releasing more up-to-date versions of the same module with different dependencies. This added flexibility comes at the price of additional complexity and for the time-being

...

the International Release modules continue to use the simpler approach in which each new version of a dependency supersedes the dependency between earlier versions of the same pair of modules.

...

The following metadata in the "Foundation metadata " supports this :

...

Scg expression

ShowParts	id+term

900000000000454005|Foundation metadata concept|

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

Concept

t	900000000000534007\|Module dependency reference set\|

. Thus all module dependency rows have the same refsetId (

Concept

t	900000000000534007\|Module dependency reference set (foundation metadata concept)\|

).

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

Concept

t	900000000000534007\|Module dependency reference set\|

within the dependent module. Because these added member must be in the dependent module, the

Specref

RefType	(field)
t	moduleId

of the

Gloss

PreSpace	false
t	reference set

member record is also the identifier of the dependent (source) module.

Module Identification

Source Module (moduleId)

The

Specref

t	moduleId

column not only indicates that this reference set member is in the specified module, it also indicates that this is the module that is the source of the dependency. As a result, in this reference set the

Specref

t	moduleId

column is immutable (i.e Mutable=NO). This is an exception to the usual rule and implies that a member of this reference set cannot move from one module to another.

Target Module (referencedComponentId)

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

Specref

RefType	(field)
t	referencedComponentId

. Like the source module this is also immutable and this implies that if a module ceases to be dependent on another module, a new row inactivating the dependency can be added but the same member cannot be used to represent a different dependency (even if that dependency is a direct replacement of the inactivated dependency). However as noted above,

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

Specref

RefType	(field)
t	sourceEffectiveTime

and the version of the module on which it depends is specified by the

Specref

RefType	(field)
t	targetEffectiveTime

.

Metadata

The following metadata in the "Foundation metadata

Gloss

PreSpace	false
t	concept

"

Gloss

PreSpace	false
t	hierarchy

supports this

Gloss

PreSpace	false
t	reference set

:

Scg expression

Border	ridge

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

Excerpt Include

	REUSE:Notes on Reference Set Example Tables
	REUSE:Notes on Reference Set Example Tables
nopanel	true

Descriptor

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

Concept

t	900000000000534007\|Module dependency reference set\|

.

...

Scg expression

ShowParts	id+term

900000000000455006|Reference set|

...

Scg expression
ShowParts id+term
900000000000534007|Module dependency|

Figure 17. Module Dependency Reference Set in the Metadata Hierarchy

Each component within a references a moduleId (field). This is the that the component is currently mastered in (from the effectiveTime (field) held on the component record). A module is simply a collection of that are maintained as a unit by a single organization. It is the organization 's responsibility to organize the components in each 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 of

Scg expression

ShowParts	id+term

900000000000443000|Module|

in the metadata . The

Scg expression

ShowParts	id+term

900000000000443000|Module|

sub - is organized by a maintaining organization into a number of groups. For example, all modules maintained by will be of

Scg expression

ShowParts	id+term

900000000000445007|IHTSDO maintained module|

. The

Scg expression

ShowParts	id+term

900000000000443000|Module|

models modules maintained by each organization and does NOT model module dependencies. Instead, module dependencies are modeled using the

Scg expression

ShowParts	id+term

900000000000534007|Module dependency reference set|

.

At the point of release, if any within a module has changed, then a new row will be added to

Scg expression

ShowParts	id+term

900000000000534007|Module dependency reference set|

for the module's , with the effectiveTime (field) set to the date of the new release, irrespective of whether the other fields in the module record itself have changed. The updated |Module| 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) field will not change from the previous release.

Each will be in one, and only one . The module that a component is mastered in may change over time, and when this happens, the component's moduleId (field) field will be updated (in the usual way by appending a row for the component).

Each module will be in one and only one . Modules will not straddle . The that a module resides in is defined by the SCTID (data type) of the module. A module may not move from one to another over time. If the components within a module are to be moved to another , then a new module must be created within the destination to host the components that are to be transferred.

There may be more than one module in an .

...

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

Scg expression

ShowParts	id+term

900000000000534007|Module dependency reference set|

.

...

Scg expression

ShowParts	id+term

900000000000534007|Module dependency|

...

refsetId	referencedComponentId (Referenced component)	attributeDescription (Attribute description)	attributeType (Attribute type)	attributeOrder (Attribute order)

Scg expressionShowPartsid+term

Concept

t	900000000000456007\|Reference

set

descriptor|

scg-expression

Concept

ShowParts

t

id+term

900000000000534007|Module

dependency|

Scg expressionShowPartsid+term

Concept

t	900000000000535008\|Dependency

target|

scg-expression

Concept

ShowParts

t

id+term

900000000000461009|Concept

type

component|

0

Scg expression

ShowParts	id+term

Concept

t	900000000000456007\|Reference

set

descriptor|

Scg expressionShowPartsid+term

Concept

t	900000000000534007\|Module

dependency|

Scg expression

Concept

t

ShowPartsid+term

	900000000000536009\|Source

effective

time|

scg-expression

Concept

ShowParts

t

id+term

900000000000475002|Time|

1

Concept

Scg expression

ShowParts	id+term

900000000000456007

t	900000000000456007\|Reference

set

descriptor|

Scg expressionShowPartsid+term

Concept

t	900000000000534007\|Module

dependency|

Scg expression

Concept

t

ShowPartsid+term

	900000000000537000\|Target

effective

time|

scg-expression

Concept

ShowParts

t

id+term

900000000000475002|Time|

2

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

Specref

RefType	(field)

, effectiveTime


t	id

,

Specref

RefType	(field)

, active


t	effectiveTime

,

Specref

RefType	(field)

, active


t	active

,

Specref

RefType	(field)
t	active

. Additionally, to aid understanding, the table above also shows the

Gloss

PreSpace	false
t	term

from one of the

Gloss

PreSpace	false
t	descriptions

associated with each of the identified .

Gloss

PreSpace	false
t	concept

. The release file only contains the .

...

Gloss

PreSpace	false
t	identifier

.

Example Data

Example

...

The table below holds example entries for the

scg-expression

Concept

ShowParts	id+term

900000000000534007

t	900000000000534007\|Module

dependency

reference

set|

in a

Gloss

PreSpace	false
t	snapshot view

of the January 2014

Gloss

PreSpace	false
t	SNOMED CT International Release

.

This

Gloss

PreSpace	false
t	SNOMED CT International Release

contains three modules:

Concept
Anchor
_6d6f9e33-8512-41ca-a84f-e1ce5e2d480b__u _6d6f9e33-8512-41ca-a84f-e1ce5e2d480b__u
Scg expression
ShowParts id+term
t 900000000000012004|SNOMED CT model
900000000000012004|SNOMED CT model
component|
which has no dependencies; Scg expressionShowPartsid+term
Concept
t 900000000000207008|SNOMED

CT

core|
which depends on the scg-expression
Concept
ShowParts
t
id+term
900000000000012004|SNOMED

CT

model

component|
; and Scg expressionShowPartsid+term
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

Gloss

PreSpace	false
t	SNOMED CT International Release

to which it applies).

Dependencies are not transitive. The fact that

scg-expression

Concept

ShowParts

t

id+term

449080006|SNOMED

CT

to

ICD-10

rule-based

mapping

module|

is dependent on id+term

Scg expression
ShowParts

Concept

t	900000000000207008\|SNOMED

CT

core|

may seem to imply a dependency on scg-expression

Concept

ShowParts

t

id+term

900000000000012004|SNOMED

CT

model

component|

. However, in practice all dependencies must be explicitly specified, not just immediate dependencies.

moduleId

Anchor_6d6f9e33-8512-41ca-a84f-e1ce5e2d480b__1_6d6f9e33-8512-41ca-a84f-e1ce5e2d480b__1Table 56. Sample content from Scg expressionShowPartsid+term

refsetId

referencedComponentId (Dependency target)

sourceEffectiveTime (Source effective time)

targetEffectiveTime (Target effective time)

Concept

t	900000000000207008\|SNOMED CT core\|

Concept

t	900000000000534007\|Module

dependency|

.

Concept

moduleId

refsetId

referencedComponentId (Dependency target)

sourceEffectiveTime (Source effective time)

targetEffectiveTime (Target effective time)

Scg expression

ShowParts	id+term

900000000000207008|SNOMED CT core|

Scg expression

ShowParts	id+term

900000000000534007|Module dependency|

Scg expression

ShowParts	id+term

900000000000012004|SNOMED CT model

t	900000000000012004\|SNOMED CT model component\|

20140131

Concept

t	449080006\|SNOMED CT to ICD-10 rule-based mapping module\|

Concept

t	900000000000534007\|Module dependency\|

Concept

t	900000000000012004\|SNOMED CT model component\|

20140131

scg-expression

Concept

ShowParts

t

id+term

449080006|SNOMED

CT

to

ICD-10

rule-based

mapping

module|

Scg expressionShowPartsid+term

Concept

t	900000000000534007\|Module

dependency|

scg-expression

Concept

ShowParts	id+term

900000000000012004

t	900000000000207008\|SNOMED

CT

model component

core|

20140131

Scg expression

ShowParts	id+term

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

Scg expression

ShowParts	id+term

900000000000534007|Module dependency|

Scg expression

ShowParts	id+term

900000000000207008|SNOMED CT core|

20140131

...

Search

Versions Compared

Old Version 2

New Version Current

Key

Purpose

Data structure

Rules and Guidance

Introduction to Modules

Introduction to Module Dependencies

Identifying and Versioning Module Dependencies

id

effectiveTime

active

refsetId

Module Identification

Source Module (moduleId)

Target Module (referencedComponentId)

Metadata

Descriptor

Example Data

Concept
Anchor
_6d6f9e33-8512-41ca-a84f-e1ce5e2d480b__u	_6d6f9e33-8512-41ca-a84f-e1ce5e2d480b__u

Search

Page History

Versions Compared

Old Version 2

New Version Current

Key

Purpose

Data structure

Rules and Guidance

Introduction to Modules

Introduction to Module Dependencies

Identifying and Versioning Module Dependencies

id

effectiveTime

active

refsetId

Module Identification

Source Module (moduleId)

Target Module (referencedComponentId)

Metadata

Descriptor

Example Data