User Tools

Site Tools


documentation:cdm:cdm:relationship

This is an old revision of the document!


RELATIONSHIP table

The RELATIONSHIP table provides a reference list of all types of relationships that can be used to associate any two concepts in the CONCEPT_RELATIONSHP table. Relationships are classified as hierarchical (parent-child) or non-hierarchical (lateral), and are used to determine which concept relationship records should be included in the computation of the CONCEPT_ANCESTOR table.

FieldRequiredTypeDescription
relationship_idYesvarchar(20) The type of relationship captured by the relationship record.
relationship_nameYesvarchar(255) The text that describes the relationship type.
is_hierarchicalYesvarchar(1)Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not.
defines_ancestryYesvarchar(1)Defines whether a hierarchical relationship contributes to the concept_ancestor table. These are subsets of the hierarchical relationships. Valid values are 1 or 0.
reverse_relationship_idYesvarchar(20)The identifier for the relationship used to define the reverse relationship between two concepts.
relationship_concept_idYesintegerA foreign key that refers to an identifier in the CONCEPT table for the unique relationship concept.

Conventions

  • Hierarchical Relationships are used to define a hierarchical tree between Concepts. For example, “has_ingredient” is a Relationship between Concepst of the Concept Class 'Clinical Drug' and those of 'Ingredient', and all Ingredients can be classified as the “parental” hierarchical Concepts for the Drugs they are part of. All 'Is a' Relationships are hierarchical. Relationships, also hierarchical, can be between Concepts within the same Vocabulary or those adopted from different Vocabulary sources.
  • Non-hierarchical Relationships are all remaining non-inclusive relationships, for example between Clinical Drugs and Branded Drugs. These Relationships are not utilized to create Ancestor relationships.

There is one record for each Concept Class. Concept Classes are used to create additional structure to the Concepts within each Vocabulary. Some Concept Classes are unique to a Vocabulary (for example “Clinical Finding” in SNOMED), but others can be used across different Vocabularies. The separation of Concepts through Concept Classes can be semantically horizontal (each Class subsumes Concepts of the same hierarchical level, akin to sub-Vocabularies within a Vocabulary) or vertical (each Class subsumes Concepts of a certain kind, going across hierarchical levels). For example, Concept Classes in SNOMED are vertical: The classes “Procedure” and “Clinical Finding” define very granular to very generic Concepts. On the other hand, “Clinical Drug” and “Ingredient” Concept Classes define horizontal layers or strata in the RxNorm vocabulary, which all belong to the same concept of a Drug.

  The concept_class_id field contains an alphanumerical identifier, that can also be used as the abbreviation of the Concept Class.
  The concept_class_name field contains the unabbreviated names of the Concept Class.
  Each Concept Class also has an entry in the Concept table, which is recorded in the concept_class_concept_id field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by unique Concepts.
  Past versions of the OMOP CDM did not have a separate reference table for all Concept Classes. Also, the content of the old concept_class and the new concept_class_id fields are not always identical. A conversion talbe can be found here:
documentation/cdm/cdm/relationship.1415985199.txt.gz · Last modified: 2014/11/14 17:13 by cgreich