...

Purpose

The

...

Data structure

The

...

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 

It is At 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 point of release, if any 

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 dependencies of an earlier version, a snapshot for an earlier time must be checked. 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

...

The following metadata in the "Foundation metadata

...

 for each dependency of that module. The 

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

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|

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|SNOMED CT model component|

  which has no dependencies;

...

...

• Concept
  t 900000000000534007|Module dependency|

Each component within a

A module is modeled by a

At the point of release, if any

Each

Each module will be in one and only one

There may be more than one module in an

...

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 id (field), effectiveTime (field), active (field), active (field). Additionally, to aid understanding, the table above also shows the

...

The table below holds example entries for the

This

...

...

...

...

...

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

...

...

• 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 practice all dependencies must be explicitly specified, not just immediate dependencies.

...

moduleId

...

refsetId

...

referencedComponentId (Dependency target)

...

sourceEffectiveTime (Source effective time)

...

targetEffectiveTime (Target effective time)

...

...

...

...

20140131

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

...

...

...

...

...

...

...