Associations between Component Files
The logical model of
| Gloss |
|---|
| PreSpace | false |
|---|
| t | associations |
|---|
|
between the components in the release files is shown in | Caption reference |
|---|
| CapRefId | logical-relationships |
|---|
| CapRefType | Figure |
|---|
|
. The component class represents columns present in all three component files. The individual classes (description, concept and relationship) only show the additional columns present in those files. The colored lines between descriptions and concepts and between relationships and concepts represent the link between the foreign keys (shown in bold) and the id of the concept. These provide the functional connections between components described in this document. The grey lines indicate additional links between columns that are populated with concept identifiers that provide enumerated values.
Image Added
| Caption label |
|---|
| CapId | logical-relationships |
|---|
| CapType | Figure |
|---|
|
Logical Relationships Between Component Files |
A More Complete View of Release File Associations
| Caption reference |
|---|
| CapRefId | assoc-2019 |
|---|
| CapRefType | Figure |
|---|
|
provides an extended view of the associations between release files following changes complete in July 2019 release of SNOMED CT| Footnote Macro |
|---|
The associations shown on the page are the results of changes that occured between July 2018 and July 2019. For documentation file associations before these changes please refer to Associations Between Release Files Prior to July 2018. |
. These changes enable SNOMED CT to use enhanced
| Gloss |
|---|
| PreSpace | false |
|---|
| t | description logic |
|---|
|
features and resulted in a significant change to the way in which the | Gloss |
|---|
| PreSpace | false |
|---|
| t | stated view |
|---|
|
of are represented. However the changes but did not significantly affect the structure and associations between the main component files shown in | Caption reference |
|---|
| CapRefId | logical-relationships |
|---|
| CapRefType | Figure |
|---|
|
Image Added
| Caption label |
|---|
| CapId | assoc-2019 |
|---|
| CapType | Figure |
|---|
|
Associations between SNOMED CT Release Files |
Detailed Notes of Release File Associations
Each
is represented by a row in the and the concept is identified by the id column in that row. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same concept. Thus each row represents a version of a clinical Each
has two or more | Gloss |
|---|
| PreSpace | false |
|---|
| t | descriptions |
|---|
|
associated with it:At least one
| Gloss |
|---|
| PreSpace | false |
|---|
| t | Fully Specified Name; |
|---|
|
andAt least one
Each
| Gloss |
|---|
| PreSpace | false |
|---|
| t | description |
|---|
|
is represented by a row in the | Specref |
|---|
| RefType | file |
|---|
| t | description file |
|---|
|
and is identified by the id column in that row. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same description. Thus each row represents a version of a description. Each description applies to one concept to which it is linked by the conceptId. All versions of a description must relate to exactly the same identified concept (i.e. the conceptId must not change between versions).Each
| Gloss |
|---|
| PreSpace | false |
|---|
| t | relationship, |
|---|
|
from a source to a destination is represented by a row in the | Specref |
|---|
| RefType | file |
|---|
| t | relationship file |
|---|
|
. There can be more than one row with the same id but with different effectiveTime values, in which case each of these rows represents a version of that same relationship. Thus each row represents a version of a relationship. The source, destination and type each relationship are identified respectively by the sourceId, destinationId and typeId columns. All versions of a relationship must have the same sourceId, destinationId and typeId. The typeId refers to that is also held within the . The only concepts that can be used as the relationship typeId are | Concept |
|---|
| t | 116680003|is a| |
|---|
| ShowFormat | inline |
|---|
|
or concepts that are subtypes of | Concept |
|---|
| t | 410662002 |Concept model attribute| |
|---|
|
.The most basic form of
| Gloss |
|---|
| PreSpace | false |
|---|
| t | relationship |
|---|
|
is the | Concept |
|---|
| t | 116680003|is a| |
|---|
| ShowFormat | inline |
|---|
|
relationship. This relationship states that one is a subtype of another . Each subtype concept is connected to its parent subtype(s) by relationships with the typeId | Concept |
|---|
| t | 116680003|is a| |
|---|
| ShowFormat | inline |
|---|
|
and this form the main SNOMED CT In this a may have more than one parent . The root of the is | Concept |
|---|
| t | 138875005 |SNOMED CT Concept| |
|---|
|
, which has a set of top level each forming its own | Gloss |
|---|
| PreSpace | false |
|---|
| t | sub-hierarchy. |
|---|
|
| Gloss |
|---|
| PreSpace | false |
|---|
| t | Relationships |
|---|
|
with typeid values that are subtypes of | Concept |
|---|
| t | 410662002 |Concept model attribute| |
|---|
| ShowFormat | inline |
|---|
|
are referred to as attribute relationship and contribute to the formal definition of the source concept....
The relationships between the records in the core files in the RF2 Release Format are depicted in the following diagram.| Anchor |
|---|
_62c25d20-b251-4965-a56b-8a6b1577acb1__0 | _62c25d20-b251-4965-a56b-8a6b1577acb1__0 | 
Image Removed Figure 1. Relationships between files Each SNOMED CT concept is held as a single row in the Concept file.Each row represents a clinical concept . Each concept has two or more descriptions associated with it (at least one synonym and at least one Fully Specified Name). Each description is held as a single row in the Description file, and may only refer to a single concept . Each relationship, from a source concept to a destination concept, is held as a single row in the Relationship file. The type of each relationship is defined by reference to a linkage concept, also held within the Concept file . The most basic form of relationship is the subsumption relationship, identifying that one concept is a kind of another concept. For example, an |Outpatient procedure| |Is a| |Procedure|. All the concepts in SNOMED CT form an |Is a| hierarchy, with a parent concept connected to each child concept by an |Is a| relationship. In this hierarchy, a child concept may have more than one parent concept. The root of the hierarchy is the | SNOMED CT Concept |, which has 19 top level children, each forming its own sub-hierarchy. There are no |Is a| relationships that cross from one of these sub-hierarchies to another (e.g. from a concept in the Procedures sub-hierarchy to a concept in the Substances hierarchy . In addition to the $$ is a $$ relationships, other relationship types are also held within the Relationship file, such as |Finding site| or |Laterality|. Relationships types are specified under the |Linkage| sub-hierarchy in the | SNOMED CT Model component | hierarchy .