Authoring relationships in an extension may involve creating new relationships, inactivating relationships or modifying existing relationships.
There are a number of reasons for modifying a relationship in an extension, including:
Changing the status of the relationship from active to inactive, or from inactive to active
Changing the relationship group of a specific relationship
Changing the characteristic type of a relationship
Relationships that are used to define extension concepts can be modified. However, please note that only the values of mutable attributes may be modified. As indicated in the table below, the six mutable attributes of a relationship are: effectiveTime, active, moduleId, relationshipGroup, characteristicTypeId, and modifierId. When a change is required to the source, destination or type of the relationship, the relationship must be inactivated and a new relationship created with the required values.
All modifications to a SNOMED CT relationship should also conform to the SNOMED CT concept model rules, including relationship group cardinality constraints. For more information please refer to the and the .
Relationships authored by SNOMED International, which define concepts in the International Edition, should not be modified. If an error is detected in the International Edition, which requires one or more relationships to be modified, the issue should be documented and reported to SNOMED International using the . In situations in which an extension producer needs to modify a relationship to temporarily fix an issue, this should be done in a module owned by the extension producer, and reported to SNOMED International It is recommended that extension producers try to avoid modifying international relationships, as such modifications may affect the results of subsumption testing and therefore may have an impact on cross-edition interoperability.
Table: Mutability of relationship attributes
The table below provides a summary of the process to follow when modifying a relationship in an extension.
id
SCTID
Uniquely identifies the relationship.
NO
Stated Axiom
Modifying a concept definition involves updating the defining properties of the concept, i.e. making changes to the axioms that represent necessary conditions for the meaning of the concept.
Once the update has been performed, the concept is classified together with the SNOMED CT content it belongs to, and a new set of relationships are inferred.
To prepare for publication, a new row representing the updated concept definition is added to the .
YES (Full/ Snapshot)
effectiveTime
Time
Specifies the inclusive date at which the component version's state became the then current valid state of the component.
Note : In distribution files the effectiveTime should follow the short ISO date format (YYYYMM DD) and should not include the hours, minutes, seconds or timezone indicator.
YES
YES (Full)Optional (Snapshot)
active
Boolean
Specifies whether the state of the relationship was active or inactive from the nominal release date specified by the effectiveTime field.
YES
NO
moduleId
SCTID
Identifies the relationship version's module. Set to a child of 900000000000443000 | Module| within the metadata hierarchy.
YES
NO
sourceId
SCTID
Identifies the source concept of the relationship version. That is the concept defined by this relationship. Set to the identifier of a concept.
NO
NO
destinationId
SCTID
Identifies the concept that is the destination of the relationship version.That is the concept representing the value of the attribute represented by the typeId column.Set to the identifier of a concept.Note that the values that can be applied to particular attributes are formally defined by the SNOMED CT Machine Readable Concept Model.
NO
NO
relationshipGroup
Integer
Groups together relationship versions that are part of a logically associated relationshipGroup. All activeRelationship records with the same relationshipGroup number and sourceId are grouped in this way.
YES
NO
typeId
SCTID
Identifies the concept that represent the defining attribute (or relationship type) represented by this relationship version.
That is the concept representing the value of the attribute represented by the typeId column.
Set to the identifier of a concept. The concept identified must be either 116680003 | Is a| or a subtype of 410662002 | Concept model attribute| . The concepts that can be used as in the typeId column are formally defined as follows: 116680003 |is a| OR < 410662002 |concept model attribute|. Note that the attributes that can be applied to particular concepts are formally defined by the SNOMED CT Machine Readable Concept Model.
NO
NO
characteristicTypeId
SCTID
A concept enumeration value that identifies the characteristic type of the relationship version (i.e. whether the relationship version is defining, qualifying, etc.) This field is set to a descendant of 900000000000449001 | Characteristic type| in the metadata hierarchy.
YES
NO
modifierId
SCTID
A concept enumeration value that identifies the type of Description Logic (DL) restriction (some, all, etc.). Set to a child of 900000000000450001 | Modifier| in the metadata hierarchy. Currently the only value used in this column is 900000000000451002 | Some| and thus in practical terms this column can be ignored. For further clarification please see .
YES
NO
The attributes of the reference set member representing the stated axiom are set as follows:
id is set to the UUID of the reference set member representing the definition of the concept being updated.
effectiveTime is set to the date the extension will be published
active is set to '1' to indicate that the new relationship will be active at the time of publication
moduleId is set to identify a module concept from the extension
referencedComponentId is set to the identifier of the concept being updated
owlExpression is set to the text of the OWL expression representing the updated defining properties of the new concept
Relationship
Depending on the nature of the change made, updates to the inferred relationship file will be made to reflect the changes. This may involve:
Inactivating relationships that are no longer valid for the concept
Adding new relationships that represent new defining relationships
see
Updating existing relationships, when the change made only impacts mutable attributes for existing relationships, see above
in this case, a new row which represents a new version of the modified relationship is added to the relationship file.
The attributes of the new version of the relationship are set as follows:
id is set to the relationshipId of the relationship being modified
effectiveTime is set to the date the extension will be published
active is set to '1' to indicate that the new version of the relationship will be active at the time of publication
moduleId is set to identify a module concept from the extension
sourceId is set to the same as the original version of the relationship
destinationId is set to the same as the original version of the relationship
relationshipGroup is set to the updated relationship group number (or the original number if no update is required)
typeId is set to the same as the original version of the relationship
characteristicTypeId is set to the updated value (or the original value if no update is required)
modifierId is set to the updated value (or the original value if no update is required)
There are a variety of reasons for inactivating a relationship in an extension, including:
An extension concept has been inactivated, which requires all relationships that it participates in to be inactivated
To correct errors in the definition of a concept
To remove any redundant | is a| relationships, generated when classifying the extension edition
To remove any 'temporary' relationships that were added to correct errors in the International Edition that have since been fixed in the International release
Relationships in an extension can be inactivated if required. This is done by creating a new version of the extension relationship with a more recent effectiveTime and the active attribute set to '0' (for 'inactive').
Relationships which belong to the International Edition (or to a module on which the extension depends) should not be inactivated in an extension. When relationships from the International Edition need to be excluded, this can be done by creating a simple reference set of either 'included' or 'excluded' relationships.
The only situations in which an extension producer may inactivate a relationship specified in the international edition (or a module on which the extension depends) are:
Where an international relationship becomes redundant after classification is performed. For more information, refer to and .
Where there exists an erroneous relationship in the International Edition (or in a module on which the extension depends), that may cause incorrect inferences in the extension edition. If this occurs, the error may need to be temporarily corrected in the extension edition. In addition, SNOMED International must be notified of the error so that it can be permanently corrected in the international edition.
In these situations, the relationship from the International Edition (or module on which the extension depends) is inactivated by creating a new version of the relationship in the extension module with a more recent effectiveTime and the active attribute set of '0' (for 'inactive').
The table below provides a summary of the process to follow when inactivating a relationship in an extension.
Relationships may be added in an extension for various reasons including:
Specifying the defining characteristics of new extension concepts
Improving the definition of an existing extension concept
In exceptional cases, it may be permissible to add defining relationships to
Relationship
A new row representing a new version of the relationship being inactivated is added to the file.
The attributes of the new relationship version are set as follows:
id is set to the same relationship identifier as the relationship being inactivated
effectiveTime is set to the date the extension will be published
active is set to 0 to indicate that the relationship will become inactive at the time of publication
moduleId is set to identify a module in the extension
sourceId, destinationId, typeId, characteristicTypeId, typeId are set as per the previous version of this relationship
Concepts which belong to the International Edition
Concepts which belong to another module on which the extension depends
A SNOMED CT relationship involves three main concepts - the source concept, the destination concept, and the relationship type concept (also known as the 'attribute'). Each of the concepts in an extension relationship may belong to either a module from the extension itself, or a module upon which the extension depends (e.g. an international module).
When adding new relationships in an extension, the following principles apply:
Source Concept : Except in exceptional cases (noted below), the relationship must represent a defining characteristic of a concept in a module for which the extension producer is responsible.
This means that the sourceId of the relationship should refer to a concept in the extension.
Attribute : The type of relationship should usually be represented by an attribute concept which is part of the SNOMED International Edition.
When using an attribute from the International Edition, concept model rules and editorial guidance should be followed. For example, relationships should comply with the rules stated in the .
In some cases, new attribute concepts may be added to an extension. While this is permitted, new attributes should be applied with caution, and concept model rules and editorial guidance should be clearly documented by the extension provider.
Destination Concept : The target of the relationship may belong to the extension module, or any module on which the extension module depends (including an international module). However, care should be taken to avoid intermediate concepts as described in Add Concept in an Extension). Additionally, it is important to ensure that the added relationships do not induce any cycles, i.e. it should be ensured that the added relationships retain the SNOMED CT hierarchy as a Directed Acyclic Graph.
NOT ALLOWED
ALLOWED
The table below provides a summary of the process to follow when adding a new relationship to an extension.
Stated Axiom
A prerequisite for generating the relationships in the relationship file is that concepts have been authored and the defining properties stated and classified together with the SNOMED CT content it belongs to. Please see .
Relationship
Once authoring is complete, the contents of the extension modules, together with every module on which these depend, are classified.The resulting set of inferred relationships (i.e. the output of the classification process) is added to the Relationship file.
A new row is added to the Relationship file for every inferred relationship that results from the classification process.
The attributes of the inferred relationships are set as follows:
id is set to a new relationship identifier allocated within the extension namespace.
effectiveTime is set to the date the extension will be published
active is set to '1' to indicate that the new relationship will be active at the time of publication
moduleId is set to identify a module concept from the extension
sourceId is set to the source concept in the relationship. This will usually belong to the extension module.
destinationId is set to the destination concept in the relationship
relationshipGroup is set to a number that indicates which relationships with the same sourceId are logically grouped together
typeId is set to an attribute concept that represents the type of the relationship
characteristicTypeId is usually set to
modifierId is usually set to
