• Reference Set Descriptor

• Module Dependency Reference Set

• Description Format Reference Set

• MRCM Domain Reference Set

Purpose

A Member Annotation Refset will be created to support annotations on members of any reference set(s).

The SNOMED CT International Release contains Annotations content in two reference sets:

• The Member Annotation String Value reference set, in which annotations are held on members of any reference set(s).

• The Component Annotation String Value reference set, in which annotations are assigned to any SNOMED CT component.

Data Structure

A Member Annotation String Value reference set is structured as shown in the following table:

A Component Annotation String Value reference set should be named along the lines of the following convention:

• der2_sscsRefset_MemberAnnotationStringValueSnapshot__[Product]_ __[date]_.txt

For example, for an International Release on 1st December 2023:

• der2_sscsRefset_MemberAnnotationStringValueSnapshot_INT_20231201.txt

The reference set example tables on this page have been revised as follows to aid clarity and understanding:

• The first four columns which are present in all release files are not shown. The omitted columns ( id, effectiveTime, active) are used in the same way in all referenced sets to support identification, versioning and packaging. They do not directly affect the specific features of a particular reference set or reference set type.

• Reference set columns that contain SNOMED CT identifiers are expanded to show details of the concept or description referenced by that identifier. In some cases, the term is shown in the same column using the expression syntax, in other cases an additional column with a name suffix '_term' has been added. In the standard reference set files only the identifier is present in the column and there is no added column for the term. When using reference sets, the term and other details of the component are looked up from the relevant component release files.

The table below shows the descriptors that define the structure of the 1292995002 |Member annotation with string value reference set (foundation metadata concept) | pattern and examples of the descriptors for specific reference sets that follow this pattern.

Descriptor templates for Member Annotation String Value reference sets

The same value of the referencedComponentId from an annotated refset is assigned in the annotation refset. For example, this OWL axiom has a referencedComponentId 91302008 |Sepsis (disorder)| in the OWL expression refset. The annotated text could indicate the intended annotation target is the OWL axiom though it is not referenced in referencedComponentId. This simplifies the query of annotations by referencedComponent.

The specifies the text format and maximum length of each supported description type. This permits additional description types to be specified in future in addition to the three existing description types ( synonym, fully specified name and textual definition).

The is a C-I ( component- Integer) reference set which is used to specify the length and format of the terms in descriptions of this description type. Its structure is shown in the following table.

Description format reference set - Data structure

An specifies the set of MRCM reference sets that should be applied to the content in each module. Within a SNOMED CT Edition, the MRCM rules applied to the included modules must be consistent, to ensure data integrity within an edition is maintained.

An is structured as shown in the following table.

Purpose

A Component Annotation Refset will be created to support annotations on components (concepts, descriptions, relationships, etc) of SNOMED CT.

The SNOMED CT International Release contains Annotations content in two reference sets:

• The Member Annotation String Value reference set, in which annotations are held on members of any reference set(s).

• The Component Annotation String Value reference set, in which annotations are assigned to any SNOMED CT component.

Data Structure

A Component Annotation String Value reference set is structured as shown in the following table:

A Component Annotation String Value reference set should be named along the lines of the following convention:

• der2_scsRefset_ComponentAnnotationStringValueSnapshot__[Product]_ __[date]_.txt

For example, for an International Release on 1st December 2023:

• der2_scsRefset_ComponentAnnotationStringValueSnapshot_INT_20231201.txt

The reference set example tables on this page have been revised as follows to aid clarity and understanding:

• The first four columns which are present in all release files are not shown. The omitted columns ( id, effectiveTime, active) are used in the same way in all referenced sets to support identification, versioning and packaging. They do not directly affect the specific features of a particular reference set or reference set type.

• Reference set columns that contain SNOMED CT identifiers are expanded to show details of the concept or description referenced by that identifier. In some cases, the term is shown in the same column using the expression syntax, in other cases an additional column with a name suffix '_term' has been added. In the standard reference set files only the identifier is present in the column and there is no added column for the term. When using reference sets, the term and other details of the component are looked up from the relevant component release files.

The table below shows the descriptors that define the structure of the 1292992004 |Component annotation with string value reference set (foundation metadata concept)| pattern and examples of the descriptors for specific reference sets that follow this pattern.

Descriptor templates for Component Annotation String Value reference sets

The is a reference set that is used to specify the format of all reference sets included in a release. The data type and meaning of the referenced component and each additional field within each reference set is described by this reference set .

Reference set descriptor can be used to define

• The order of appearance of additional attributes (other than those mandatory for all reference sets);

• The name and purpose of the additional attributes;

Purpose

The |Module dependency reference set| represents dependencies between different SNOMED CT release modules. In each case, the dependency indicates which targetEffectiveTime of each particular module a given sourceEffectiveTime of the dependent module requires.

Data structure

The 900000000000534007 |Module dependency reference set| is a String - String reference set which is used to represent dependencies between modules, taking account of module versioning. Its structure is shown in the following table.

Each row in the release files for components and reference set members has a . This refers to the module that the component is maintained in. Each module is either part of the SNOMED International Release or part of a single SNOMED CT Extension. The has a partition-id which indicates whether it is part of the SNOMED International Release and, if not, its namespace identifier indicates the SNOMED CT Extension that it belongs to.

A module is simply a collection of SNOMED CT components 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 represented by a descendant of in the metadata hierarchy. The immediate subtype descendants of 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 SNOMED International will be children of .

At any point in time a 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 but with a new and a new .

Each extension must include one or more modules. Each module must be part of either the SNOMED International Release or one and only one extension. A module may not move from one extension to another over time. If components or reference set members in a module are to be moved from an extension to the SNOMED International Release or to another extension, they must either be added to an existing or newly created module maintained by the destination organization.

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

At the point of release, if any component within a module has changed, then a new row must be added to the for each dependency of that module. The of the added rows must set to the date of the new release. The updated 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 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.

The recommended practice is for the 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.

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.

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.

Module version dependencies are represented using a single . 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 within the dependent module. Because these added member must be in the dependent module, the moduleId of the reference set member record is also the identifier of the dependent (source) module.

The 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 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.

The target module on which the source module depends is identified by the . 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 and the version of the module on which it depends is specified by the .

The following metadata in the "Foundation metadata concept " hierarchy supports this reference set

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

Example : The table below holds example entries for the in a snapshot view of the January 2014 SNOMED CT International Release .

This SNOMED CT International Release contains three modules:

• which has no dependencies;

• which depends on the ; and

• 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 SNOMED CT International Release to which it applies).

Dependencies are not transitive. The fact that is dependent on may seem to imply a dependency on . However, in practice all dependencies must be explicitly specified, not just immediate dependencies.

Purpose

An 723604009 |MRCM attribute domain reference set| allows attributes to be associated with the domains in which they may be applied. It also allows grouping and cardinality constraints to be specified for each attribute and domain combination. For each attribute-domain rule, the strength of the rule (e.g. 723597001 |Mandatory concept model rule| or 723598006 |Optional concept model rule| ) and the content type over which this rule applies (e.g. 723596005 |All SNOMED CT content| , 723594008 |All precoordinated SNOMED CT content| ) is also specified.

Each attribute is identified by its concept id, while each domain is identified by the same concept id used in the referencedComponentId of the 723589008 |MRCM domain reference set|

Data Structure

An 723604009 |MRCM attribute domain reference set| is structured as shown in the following table.

The following metadata hierarchy supports this reference set:

The table below shows the reference set descriptor for a reference set that follows the pattern.

The table below shows some example rows from a reference set that follows the format of the .

An allows attributes to be associated with a valid value range for a given SNOMED CT content type and rule strength. The range of each attribute is defined using an Expression Constraint. This expression constraint represents the set of concepts, expressions, or concrete values that may be used as the value of the given attribute. The also provides a summary of the concept model rule associated with each attribute (including all valid domains and the given range) using an Expression Constraint representation. This attribute rule can be completely auto-generated by combining information from the and the .

An is structured as shown in the following table.

Purpose

An 723589008 |MRCM domain reference set| enumerates the concept domains to which SNOMED CT attributes may be applied, and provides additional information to support these concept domains.

Each concept domain is uniquely identified by a SNOMED CT concept. When the scope of a domain covers the concepts in a particular hierarchy (or subhierarchy), the supertype concept of this hierarchy (or subhierarchy) is used to identify the domain. When a domain is defined based on membership in a reference set, the associated reference set concept is used to identify the domain. In some situations, a query may be required to define a complex domain. In these cases, the query's expansion reference set (referred to by the 'referencedComponent' of the relevant Query reference set) is used to identify the domain.

For each domain in the SNOMED CT concept model, the 723589008 |MRCM domain reference set| will contain exactly one member. This reference set member will include an Expression Constraint that defines the concepts in the domain, the identifier of the immediate parent domain (or domains), the domain constraint defined in terms of its proximal primitive concepts and associated mandatory refinements, a generic Domain Expression Template for both precoordinated and postcoordinated content, and a reference to the associated guidance that provides additional human-readable text describing this domain. Please note that it is anticipated that the generic Domain Expression Templates will be specialized further for authoring of specific subdomains using specializations stored in a Template Library.

Data Structure

An 723589008 |MRCM domain reference set| is structured as shown in the following table.

The following metadata hierarchy supports this reference set:

The table below shows the reference set descriptor for a reference set that follows the pattern.

The table below shows some example rows from a reference set that uses the format of the .

Please note that the generic domain templates defined for the SNOMED CT International Edition are designed to support a proximal primitive parent authoring approach. However, domain templates included in an extension's may be designed to support a proximal parent authoring approach if required.