Relationship File Specification

The Relationship file holds one relationship per row. Each relationship is of a particular type, and has a source concept and a destination concept. An example of a relationship is given below:
$$ Outpatient procedure $$ $$ Is a $$ $$ Procedure $$ where:

• $$ Outpatient procedure $$ is the source concept ;
• $$ Is a $$ is the relationship type concept ; and;
• $$ Procedure $$ is the destination concept .

  Table 11. Relationship file - Detailed Specification
  Field	Data type	Immutable	Purpose
  id	SCTID	Y	Uniquely identifies the relationship .
  effectiveTime	Time	N	Specifies the inclusive date at which the component version's state became the then current valid state of the component
  active	Boolean	N	Specifies whether the relationship 's state was active or inactive from the nominal release date specified by the effectiveTime field.
  moduleId	SCTID	N	Identifies the relationship version's module. Set to a child of 900000000000443000 $$ Module $$ within the metadata hierarchy .
  sourceId	SCTID	Y	Identifies the source concept of the relationship version, i.e., the concept the relationship version emanates from. Set to an Identifier of a concept in the Concept file.
  destinationId	SCTID	Y	Identifies the concept that is the destination of the relationship version. Set to an Identifier of a concept in the Concept file.
  relationshipGroup	Integer	N	Groups together relationship versions that are part of a logically associated relationship group. All active Relationship records with the same relationshipGroup number and sourceId are grouped in this way.
  typeId	SCTID	Y	A concept enumeration value from the metadata hierarchy that identifies the semantic type of the relationship version. 116680003 $$ Is a $$ or a subtype of 410662002 $$ Concept model attribute $$ . For example $$ Is a $$, or $$ associated morphology $$ .
  characteristicTypeId	SCTID	N	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 .
  modifierId	SCTID	N	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 .

  Only one relationship record with the same id field will be current at any point in time. The current record will be the one with the most recent effectiveTimebefore or equal to the point in time under consideration.
  If the active field of this record is false ('0'), then the relationship is inactive at that point in time. If the active field is true ('1'), then there is a relationship between the SNOMED CT concepts identified by sourceId and destinationId .
  The sourceId, destinationId, relationshipGroup, typeId, characteristicTypeIdand modifierId will not change between two rows with the same id, in other words they are immutable. Where a change is required to one of these fields, then the current row will be de-activated (by appending a row with the same id and the active field set to false) and a new row with a new id will be appended.
  The relationshipGroup field is used to group relationships with the same sourceId field into one or more logical sets. A relationship with a relationshipGroup field value of '0' is considered not to be grouped. All relationships with the same sourceId and non-zero relationshipGroup are considered to be logically grouped.
  The relationshipGroup field will be an unsigned integer, and will not be limited to a single digit value. There is no guarantee that they will be assigned sequentially, and the values will not be unique across concepts .
  The modifierId field will initially be set to 900000000000451002 $$ Some $$ to keep compatibility with the RF1 release. Widening the range of this field to include other values (such as |All|) will in future increase the expressive power of SNOMED CT . However, this is likely to come at the cost of an increase in reasoning complexity, leading to potential issues for classification tooling.
  Notes:

1. The modiferId field has been included at this stage as the RF2 format is likely to be stable for at least a five year period, without addition or deletion of fields. Within that period it is anticipated that other modifierId values will be added. Therefore, although not fully implemented at this stage, this field has been included in the initial RF2 specification as it represents an integral part of the Description Logic used by SNOMED CT .
2. Any expansion of SNOMED CT to include relationships with a modifierId set to a value other than 900000000000451002 $$ Some $$ will be discussed with Members first and approved by the Technical Committee.
3. Changes have been made to the "Immutability" values shown in the above table in the 2014-07-31 version. These changes reflect the fact that the values in the following columns of a uniquely identified relationship have occurred in historical data and in these cases tracking the history of these changes is of greater value that insisting on immutability.
   • relationshipGroup: The number can change though the logical content of the group represented should not change. Additionally no significance should be read into the relationshipGroup value of an inactive relationship ;
   • characteristicType: This has changed in historical data but should not change in future;
   • modifierId: Since there is currently only one value for this no changes are possible but if the permitted values are extended as suggested above then it is likely that changes would be required.

Related Links

• Attributes Used in SNOMED CT
• 6.2.3. Hierarchies
• A
• Relationships
• Unicode UTF-8 encoding
• Relationship