Vocabulary documentation updates
This commit is contained in:
clairblacketer
parent
91d438af14
commit
0fe150e2ed
|
|
@ -1,14 +0,0 @@
|
||||||
The ATTRIBUTE_DEFINITION table contains records defining Attributes, or covariates, to members of a Cohort through an associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT_ATTRIBUTE table. Attributes are derived elements that can be selected or calculated for a subject in a Cohort. The ATTRIBUTE_DEFINITION table provides a standardized structure for maintaining the rules governing the calculation of covariates for a subject in a Cohort, and can store operational programming code to instantiate the Attributes for a given Cohort within the OMOP Common Data Model.
|
|
||||||
|
|
||||||
Field|Required|Type|Description
|
|
||||||
:-------------------------|:------|:--------------|:--------------------------------------
|
|
||||||
|attribute_definition_id|Yes|integer|A unique identifier for each Attribute.|
|
|
||||||
|attribute_name|Yes|varchar(255)|A short description of the Attribute.|
|
|
||||||
|attribute_description|No|varchar(MAX)|A complete description of the Attribute definition|
|
|
||||||
|attribute_type_concept_id|Yes|integer|Type defining what kind of Attribute Definition the record represents and how the syntax may be executed|
|
|
||||||
|attribute_syntax|No|varchar(MAX)|Syntax or code to operationalize the Attribute definition|
|
|
||||||
|
|
||||||
|
|
||||||
### Conventions
|
|
||||||
* Like the definition syntax field for the COHORT_DEFINITION table, the attribute_definition_syntax does not prescribe any specific syntax or programming language. Typically, it would be any flavor SQL, or a cohort definition language, or a free-text description of the algorithm.
|
|
||||||
* The Attribute Definition is generic and not necessarily related to a specific Cohort Definition, however the instantiated Attribute is linked to the Cohort records (see below the [COHORT](https://github.com/OHDSI/CommonDataModel/wiki/COHORT) table. For example, the Attribute "Age" can be defined as the amount of time between the cohort_start_date of the COHORT table and the year_of_birth, month_of_birth and day_of_birth of the PERSON table. Thus, such a Attribute Definition can be applied and instantiated with any Cohort, as long as it is applied to a Cohort of the same Domain (Person in this case), as it is defined in the subject_concept_id in the COHORT_DEFINITION table.
|
|
||||||
|
|
@ -20,19 +20,21 @@ Field|Required|Type|Description
|
||||||
### Conventions
|
### Conventions
|
||||||
Concepts in the Common Data Model are derived from a number of public or proprietary terminologies such as SNOMED-CT and RxNorm, or custom generated to standardize aspects of observational data. Both types of Concepts are integrated based on the following rules:
|
Concepts in the Common Data Model are derived from a number of public or proprietary terminologies such as SNOMED-CT and RxNorm, or custom generated to standardize aspects of observational data. Both types of Concepts are integrated based on the following rules:
|
||||||
|
|
||||||
* All Concepts are maintained centrally by the CDM and Vocabularies Working Group. Additional concepts can be added, as needed, upon request.
|
No.|Convention Description
|
||||||
* For all Concepts, whether they are custom generated or adopted from published terminologies, a unique numeric identifier concept_id is assigned and used as the key to link all observational data to the corresponding Concept reference data.
|
:--------|:------------------------------------
|
||||||
* The concept_id of a Concept is persistent, i.e. stays the same for the same Concept between releases of the Standardized Vocabularies.
|
| 1 | All Concepts are maintained centrally by the CDM and Vocabularies Working Group. Additional concepts can be added, as needed, upon request. |
|
||||||
* A descriptive name for each Concept is stored as the Concept Name as part of the CONCEPT table. Additional names and descriptions for the Concept are stored as Synonyms in the [CONCEPT_SYNONYM](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_SYNONYM) table.
|
| 2 | For all Concepts, whether they are custom generated or adopted from published terminologies, a unique numeric identifier concept_id is assigned and used as the key to link all observational data to the corresponding Concept reference data. |
|
||||||
* Each Concept is assigned to a Domain. For Standard Concepts, these is always a single Domain. Source Concepts can be composite or coordinated entities, and therefore can belong to more than one Domain. The domain_id field of the record contains the abbreviation of the Domain, or Domain combination. Please refer to the Standardized Vocabularies [specification](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary) for details of the Domain Assignment.
|
| 3 | The concept_id of a Concept is persistent, i.e. stays the same for the same Concept between releases of the Standardized Vocabularies. |
|
||||||
* For details of the Vocabularies adopted for use in the OMOP CDM refer to the Standardized Vocabularies specification.
|
| 4 | A descriptive name for each Concept is stored as the Concept Name as part of the CONCEPT table. Additional names and descriptions for the Concept are stored as Synonyms in the [CONCEPT_SYNONYM](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_SYNONYM) table. |
|
||||||
* Concept Class designation are attributes of Concepts. Each Vocabulary has its own set of permissible Concept Classes, although the same Concept Class can be used by more than one Vocabulary. Depending on the Vocabulary, the Concept Class may categorize Concepts vertically (parallel) or horizontally (hierarchically). See the specification of each vocabulary for details.
|
| 5 | Each Concept is assigned to a Domain. For Standard Concepts, these is always a single Domain. Source Concepts can be composite or coordinated entities, and therefore can belong to more than one Domain. The domain_id field of the record contains the abbreviation of the Domain, or Domain combination. Please refer to the Standardized Vocabularies [specification](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary) for details of the Domain Assignment. |
|
||||||
* Concept Class attributes should not be confused with Classification Concepts. These are separate Concepts that have a hierarchical relationship to Standard Concepts or each other, while Concept Classes are unique Vocabulary-specific attributes for each Concept.
|
| 6 | For details of the Vocabularies adopted for use in the OMOP CDM refer to the Standardized Vocabularies specification.
|
||||||
* For Concepts inherited from published terminologies, the source code is retained in the concept_code field and can be used to reference the source vocabulary.
|
| 7 | Concept Class designation are attributes of Concepts. Each Vocabulary has its own set of permissible Concept Classes, although the same Concept Class can be used by more than one Vocabulary. Depending on the Vocabulary, the Concept Class may categorize Concepts vertically (parallel) or horizontally (hierarchically). See the specification of each vocabulary for details. |
|
||||||
* Standard Concepts (designated as 'S' in the standard_concept field) may appear in CDM tables in all *_concept_id fields, whereas Classification Concepts ('C') should not appear in the CDM data, but participate in the construction of the [CONCEPT_ANCESTOR](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR) table and can be used to identify Descendants that may appear in the data. See [CONCEPT_ANCESTOR](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR) table. Non-standard Concepts can only appear in *_source_concept_id fields and are not used in CONCEPT_ANCESTOR table. Please refer to the Standardized Vocabularies [specifications](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:standard_classification_and_source_concepts) for details of the Standard Concept designation.
|
| 8 | Concept Class attributes should not be confused with Classification Concepts. These are separate Concepts that have a hierarchical relationship to Standard Concepts or each other, while Concept Classes are unique Vocabulary-specific attributes for each Concept. |
|
||||||
* All logical data elements associated with the various CDM tables (usually in the <domain>_type_concept_id field) are called Type Concepts, including defining characteristics, qualifying attributes etc. They are also stored as Concepts in the CONCEPT table. Since they are generated by OMOP, their is no meaningful concept_code.
|
| 9 | For Concepts inherited from published terminologies, the source code is retained in the concept_code field and can be used to reference the source vocabulary. |
|
||||||
* The lifespan of a Concept is recorded through its valid_start_date, valid_end_date and the invalid_reason fields. This allows Concepts to correctly reflect at which point in time were defined. Usually, Concepts get deprecated if their meaning was deemed ambiguous, a duplication of another Concept, or needed revision for scientific reason. For example, drug ingredients get updated when different salt or isomer variants enter the market. Usually, drugs taken off the market do not cause a deprecation by the terminology vendor. Since observational data are valid with respect to the time they are recorded, it is key for the Standardized Vocabularies to provide even obsolete codes and maintain their relationships to other current Concepts .
|
| 10 | Standard Concepts (designated as 'S' in the standard_concept field) may appear in CDM tables in all *_concept_id fields, whereas Classification Concepts ('C') should not appear in the CDM data, but participate in the construction of the [CONCEPT_ANCESTOR](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR) table and can be used to identify Descendants that may appear in the data. See [CONCEPT_ANCESTOR](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR) table. Non-standard Concepts can only appear in *_source_concept_id fields and are not used in CONCEPT_ANCESTOR table. Please refer to the Standardized Vocabularies [specifications](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:standard_classification_and_source_concepts) for details of the Standard Concept designation. |
|
||||||
* Concepts without a known instantiated date are assigned valid_start_date of '1-Jan-1970'.
|
| 11 | All logical data elements associated with the various CDM tables (usually in the <domain>_type_concept_id field) are called Type Concepts, including defining characteristics, qualifying attributes etc. They are also stored as Concepts in the CONCEPT table. Since they are generated by OMOP, their is no meaningful concept_code. |
|
||||||
* Concepts that are not invalid are assigned valid_end_date of '31-Dec-2099'.
|
| 12 | The lifespan of a Concept is recorded through its valid_start_date, valid_end_date and the invalid_reason fields. This allows Concepts to correctly reflect at which point in time were defined. Usually, Concepts get deprecated if their meaning was deemed ambiguous, a duplication of another Concept, or needed revision for scientific reason. For example, drug ingredients get updated when different salt or isomer variants enter the market. Usually, drugs taken off the market do not cause a deprecation by the terminology vendor. Since observational data are valid with respect to the time they are recorded, it is key for the Standardized Vocabularies to provide even obsolete codes and maintain their relationships to other current Concepts. |
|
||||||
* Deprecated Concepts (with a valid_end_date before the release date of the Standardized Vocabularies) will have a value of 'D' (deprecated without successor) or 'U' (updated). The updated Concepts have a record in the [CONCEPT_RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_RELATIONSHIP) table indicating their active replacement Concept.
|
| 13 | Concepts without a known instantiated date are assigned valid_start_date of '1-Jan-1970'. |
|
||||||
* Values for concept_ids generated as part of Standardized Vocabularies will be reserved from 0 to 2,000,000,000. Above this range, concept_ids are available for local use and are guaranteed not to clash with future releases of the Standardized Vocabularies.
|
| 14 | Concepts that are not invalid are assigned valid_end_date of '31-Dec-2099'. |
|
||||||
|
| 15 | Deprecated Concepts (with a valid_end_date before the release date of the Standardized Vocabularies) will have a value of 'D' (deprecated without successor) or 'U' (updated). The updated Concepts have a record in the [CONCEPT_RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_RELATIONSHIP) table indicating their active replacement Concept. |
|
||||||
|
| 16 | Values for CONCEPT_IDs generated as part of Standardized Vocabularies will be reserved from 0 to 2,000,000,000. Above this range, CONCEPT_IDs are available for local use and are guaranteed not to clash with future releases of the Standardized Vocabularies. |
|
||||||
|
|
|
||||||
|
|
@ -11,6 +11,8 @@ Field|Required|Type|Description
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
|
|
||||||
* Each concept is also recorded as an ancestor of itself.
|
No.|Convention Description
|
||||||
* Only valid and Standard Concepts participate in the CONCEPT_ANCESTOR table. It is not possible to find ancestors or descendants of deprecated or Source Concepts.
|
:--------|:------------------------------------
|
||||||
* Usually, only Concepts of the same Domain are connected through records of the CONCEPT_ANCESTOR table, but there might be exceptions.
|
| 1 | Each concept is also recorded as an ancestor of itself. |
|
||||||
|
| 2 | Only valid and Standard Concepts participate in the CONCEPT_ANCESTOR table. It is not possible to find ancestors or descendants of deprecated or Source Concepts. |
|
||||||
|
| 3 | Usually, only Concepts of the same Domain are connected through records of the CONCEPT_ANCESTOR table, but there might be exceptions. |
|
||||||
|
|
|
||||||
|
|
@ -8,118 +8,10 @@ Field|Required|Type|Description
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
|
|
||||||
* 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.
|
No.|Convention Description
|
||||||
* 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.
|
| 1 | 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. |
|
||||||
* 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.
|
| 2 | The CONCEPT_CLASS_ID field contains an alphanumerical identifier, that can also be used as the abbreviation of the Concept Class. |
|
||||||
* 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 table can be found here:
|
| 3 | The CONCEPT_CLASS_NAME field contains the unabbreviated names of the Concept Class. |
|
||||||
|
| 4 | 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. |
|
||||||
|
|
||||||
Previous CONCEPT_CLASS|Version 5 CONCEPT_CLASS_ID
|
|
||||||
:------------------------------|:----------------------------------------------
|
|
||||||
|Administrative concept|Admin Concept|
|
|
||||||
|Admitting Source|Admitting Source|
|
|
||||||
|Anatomical Therapeutic Chemical Classification|ATC|
|
|
||||||
|Anatomical Therapeutic Chemical Classification|ATC|
|
|
||||||
|APC|Procedure|
|
|
||||||
|Attribute|Attribute|
|
|
||||||
|Biobank Flag|Biobank Flag|
|
|
||||||
|Biological function|Biological Function|
|
|
||||||
|Body structure|Body Structure|
|
|
||||||
|Brand Name|Brand Name|
|
|
||||||
|Branded Drug|Branded Drug|
|
|
||||||
|Branded Drug Component|Branded Drug Comp|
|
|
||||||
|Branded Drug Form|Branded Drug Form|
|
|
||||||
|Branded Pack|Branded Pack|
|
|
||||||
|CCS_DIAGNOSIS|Condition|
|
|
||||||
|CCS_PROCEDURES|Procedure|
|
|
||||||
|Chart Availability|Chart Availability|
|
|
||||||
|Chemical Structure|Chemical Structure|
|
|
||||||
|Clinical Drug|Clinical Drug|
|
|
||||||
|Clinical Drug Component|Clinical Drug Comp|
|
|
||||||
|Clinical Drug Form|Clinical Drug Form|
|
|
||||||
|Clinical finding|Clinical Finding|
|
|
||||||
|Clinical Pack|Clinical Pack|
|
|
||||||
|Concept Relationship|Concept Relationship|
|
|
||||||
|Condition Occurrence Type|Condition Occur Type|
|
|
||||||
|Context-dependent category|Context-dependent|
|
|
||||||
|CPT-4|Procedure|
|
|
||||||
|Currency|Currency|
|
|
||||||
|Death Type|Death Type|
|
|
||||||
|Device Type|Device Type|
|
|
||||||
|Discharge Disposition|Discharge Dispo|
|
|
||||||
|Discharge Status|Discharge Status|
|
|
||||||
|Domain|Domain|
|
|
||||||
|Dose Form|Dose Form|
|
|
||||||
|DRG|Diagnostic Category|
|
|
||||||
|Drug Exposure Type|Drug Exposure Type|
|
|
||||||
|Drug Interaction|Drug Interaction|
|
|
||||||
|Encounter Type|Encounter Type|
|
|
||||||
|Enhanced Therapeutic Classification|ETC|
|
|
||||||
|Enrollment Basis|Enrollment Basis|
|
|
||||||
|Environment or geographical location|Location|
|
|
||||||
|Ethnicity|Ethnicity|
|
|
||||||
|Event|Event|
|
|
||||||
|Gender|Gender|
|
|
||||||
|HCPCS|Procedure|
|
|
||||||
|Health Care Provider Specialty|Provider Specialty|
|
|
||||||
|HES specialty|Provider Specialty|
|
|
||||||
|High Level Group Term|HLGT|
|
|
||||||
|High Level Term|HLT|
|
|
||||||
|Hispanic|Hispanic|
|
|
||||||
|ICD-9-Procedure|Procedure|
|
|
||||||
|Indication or Contra-indication|Ind / CI|
|
|
||||||
|Ingredient|Ingredient|
|
|
||||||
|LOINC Code|Measurement|
|
|
||||||
|LOINC Multidimensional Classification|Meas Class|
|
|
||||||
|Lowest Level Term|LLT|
|
|
||||||
|MDC|Diagnostic Category|
|
|
||||||
|Measurement Type|Meas Type|
|
|
||||||
|Mechanism of Action|Mechanism of Action|
|
|
||||||
|Model component|Model Comp|
|
|
||||||
|Morphologic abnormality|Morph Abnormality|
|
|
||||||
|MS-DRG|Diagnostic Category|
|
|
||||||
|Namespace concept|Namespace Concept|
|
|
||||||
|Note Type|Note Type|
|
|
||||||
|Observable entity|Observable Entity|
|
|
||||||
|Observation Period Type|Obs Period Type|
|
|
||||||
|Observation Type|Observation Type|
|
|
||||||
|OMOP DOI cohort|Drug Cohort|
|
|
||||||
|OMOP HOI cohort|Condition Cohort|
|
|
||||||
|OPCS-4|Procedure|
|
|
||||||
|Organism|Organism|
|
|
||||||
|Patient Status|Patient Status|
|
|
||||||
|Pharmaceutical / biologic product|Pharma/Biol Product|
|
|
||||||
|Pharmaceutical Preparations|Pharma Preparation|
|
|
||||||
|Pharmacokinetics|PK|
|
|
||||||
|Pharmacologic Class|Pharmacologic Class|
|
|
||||||
|Physical force|Physical Force|
|
|
||||||
|Physical object|Physical Object|
|
|
||||||
|Physiologic Effect|Physiologic Effect|
|
|
||||||
|Place of Service|Place of Service|
|
|
||||||
|Preferred Term|PT|
|
|
||||||
|Procedure|Procedure|
|
|
||||||
|Procedure Occurrence Type|Procedure Occur Type|
|
|
||||||
|Qualifier value|Qualifier Value|
|
|
||||||
|Race|Race|
|
|
||||||
|Record artifact|Record Artifact|
|
|
||||||
|Revenue Code|Revenue Code|
|
|
||||||
|Sex|Gender|
|
|
||||||
|Social context|Social Context|
|
|
||||||
|Special concept|Special Concept|
|
|
||||||
|Specimen|Specimen|
|
|
||||||
|Staging and scales|Staging / Scales|
|
|
||||||
|Standardized MedDRA Query|SMQ|
|
|
||||||
|Substance|Substance|
|
|
||||||
|System Organ Class|SOC|
|
|
||||||
|Therapeutic Class|Therapeutic Class|
|
|
||||||
|UCUM|Unit|
|
|
||||||
|UCUM Canonical|Canonical Unit|
|
|
||||||
|UCUM Custom|Unit|
|
|
||||||
|UCUM Standard|Unit|
|
|
||||||
|Undefined|Undefined|
|
|
||||||
|UNKNOWN|Undefined|
|
|
||||||
|VA Class|Drug Class|
|
|
||||||
|VA Drug Interaction|Drug Interaction|
|
|
||||||
|VA Product|Drug Product|
|
|
||||||
|Visit|Visit|
|
|
||||||
|Visit Type|Visit Type|
|
|
||||||
|
|
|
||||||
|
|
@ -10,9 +10,12 @@ Field|Required|Type|Description
|
||||||
|invalid_reason|No|varchar(1)|Reason the relationship was invalidated. Possible values are 'D' (deleted), 'U' (replaced with an update) or NULL when valid_end_date has the default value.|
|
|invalid_reason|No|varchar(1)|Reason the relationship was invalidated. Possible values are 'D' (deleted), 'U' (replaced with an update) or NULL when valid_end_date has the default value.|
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
* Relationships can generally be classified as hierarchical (parent-child) or non-hierarchical (lateral).
|
|
||||||
* All Relationships are directional, and each Concept Relationship is represented twice symmetrically within the CONCEPT_RELATIONSHIP table. For example, the two SNOMED concepts of 'Acute myocardial infarction of the anterior wall' and 'Acute myocardial infarction' have two Concept Relationships: 1- 'Acute myocardial infarction of the anterior wall' 'Is a' 'Acute myocardial infarction', and 2- 'Acute myocardial infarction' 'Subsumes' 'Acute myocardial infarction of the anterior wall'.
|
No.|Convention Description
|
||||||
* There is one record for each Concept Relationship connecting the same Concepts with the same relationship_id.
|
:--------|:------------------------------------
|
||||||
* Since all Concept Relationships exist with their mirror image (concept_id_1 and concept_id_2 swapped, and the relationship_id replaced by the reverse_relationship_id from the [RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP) table), it is not necessary to query for the existence of a relationship both in the concept_id_1 and concept_id_2 fields.
|
| 1 | Relationships can generally be classified as hierarchical (parent-child) or non-hierarchical (lateral). |
|
||||||
* Concept Relationships define direct relationships between Concepts. Indirect relationships through 3rd Concepts are not captured in this table. However, the [CONCEPT_ANCESTOR](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR) table does this for hierachical relationships over several "generations" of direct relationships.
|
| 2 | All Relationships are directional, and each Concept Relationship is represented twice symmetrically within the CONCEPT_RELATIONSHIP table. For example, the two SNOMED concepts of 'Acute myocardial infarction of the anterior wall' and 'Acute myocardial infarction' have two Concept Relationships: 1- 'Acute myocardial infarction of the anterior wall' 'Is a' 'Acute myocardial infarction', and 2- 'Acute myocardial infarction' 'Subsumes' 'Acute myocardial infarction of the anterior wall'. |
|
||||||
* In previous versions of the CDM, the relationship_id used to be a numerical identifier. See the [RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP) table.
|
| 3 | There is one record for each Concept Relationship connecting the same Concepts with the same RELATIONSHIP_ID. |
|
||||||
|
| 4 | Since all Concept Relationships exist with their mirror image (concept_id_1 and concept_id_2 swapped, and the RELATIONSHIP_ID replaced by the REVERSE_RELATIONSHIP_ID from the [RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP) table), it is not necessary to query for the existence of a relationship both in the concept_id_1 and concept_id_2 fields. |
|
||||||
|
| 5 | Concept Relationships define direct relationships between Concepts. Indirect relationships through 3rd Concepts are not captured in this table. However, the [CONCEPT_ANCESTOR](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR) table does this for hierachical relationships over several "generations" of direct relationships. |
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -8,6 +8,8 @@ Field|Required|Type|Description
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
|
|
||||||
* The concept_synonym_name field contains a valid Synonym of a concept, including the description in the concept_name itself. I.e. each Concept has at least one Synonym in the CONCEPT_SYNONYM table. As an example, for a SNOMED-CT Concept, if the fully specified name is stored as the concept_name of the CONCEPT table, then the Preferred Term and Synonyms associated with the Concept are stored in the CONCEPT_SYNONYM table.
|
No.|Convention Description
|
||||||
* Only Synonyms that are active and current are stored in the CONCEPT_SYNONYM table. Tracking synonym/description history and mapping of obsolete synonyms to current Concepts/Synonyms is out of scope for the Standard Vocabularies.
|
:--------|:------------------------------------
|
||||||
* Currently, only English Synonyms are included.
|
| 1 | The concept_synonym_name field contains a valid Synonym of a concept, including the description in the concept_name itself. i.e., each Concept has at least one Synonym in the CONCEPT_SYNONYM table. As an example, for a SNOMED-CT Concept, if the fully specified name is stored as the concept_name of the CONCEPT table, then the Preferred Term and Synonyms associated with the Concept are stored in the CONCEPT_SYNONYM table. |
|
||||||
|
| 2 | Only Synonyms that are active and current are stored in the CONCEPT_SYNONYM table. Tracking synonym/description history and mapping of obsolete synonyms to current Concepts/Synonyms is out of scope for the Standard Vocabularies. |
|
||||||
|
| 3 | Currently, only English Synonyms are included. |
|
||||||
|
|
|
||||||
|
|
@ -8,8 +8,10 @@ Field|Required|Type|Description
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
|
|
||||||
* There is one record for each Domain. The domains are defined by the tables and fields in the OMOP CDM that can contain Concepts describing all the various aspects of the healthcare experience of a patient.
|
No.|Convention Description
|
||||||
* The domain_id field contains an alphanumerical identifier, that can also be used as the abbreviation of the Domain.
|
:--------|:------------------------------------
|
||||||
* The domain_name field contains the unabbreviated names of the Domain.
|
| 1 | There is one record for each Domain. The domains are defined by the tables and fields in the OMOP CDM that can contain Concepts describing all the various aspects of the healthcare experience of a patient. |
|
||||||
* Each Domain also has an entry in the Concept table, which is recorded in the domain_concept_id field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by unique Concept.
|
| 2 | The DOMAIN_ID field contains an alphanumerical identifier, that can also be used as the abbreviation of the Domain. |
|
||||||
* Versions prior to v5.0.0 of the OMOP CDM did not support the notion of a Domain.
|
| 3 | The DOMAIN_NAME field contains the unabbreviated names of the Domain. |
|
||||||
|
| 4 | Each Domain also has an entry in the Concept table, which is recorded in the DOMAIN_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.
|
||||||
|
| 5 | Versions prior to v5.0.0 of the OMOP CDM did not support the notion of a Domain. |
|
||||||
|
|
|
||||||
|
|
@ -17,14 +17,16 @@ Field|Required|Type|Description
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
|
|
||||||
* The DRUG_STRENGTH table contains information for each active (non-deprecated) standard drug concept.
|
No.|Convention Description
|
||||||
* A drug which contains multiple active Ingredients will result in multiple DRUG_STRENGTH records, one for each active ingredient.
|
:--------|:------------------------------------
|
||||||
* Ingredient strength information is provided either as absolute amount (usually for solid formulations) or as concentration (usually for liquid formulations).
|
| 1 | The DRUG_STRENGTH table contains information for each active (non-deprecated) standard drug concept. |
|
||||||
* If the absolute amount is provided (for example, 'Acetaminophen 5 MG Tablet') the amount_value and amount_unit_concept_id are used to define this content (in this case 5 and 'MG').
|
| 2 | A drug which contains multiple active Ingredients will result in multiple DRUG_STRENGTH records, one for each active ingredient. |
|
||||||
* If the concentration is provided (for example 'Acetaminophen 48 MG/ML Oral Solution') the numerator_value in combination with the numerator_unit_concept_id and denominator_unit_concept_id are used to define this content (in this case 48, 'MG' and 'ML').
|
| 3 | Ingredient strength information is provided either as absolute amount (usually for solid formulations) or as concentration (usually for liquid formulations). |
|
||||||
* In case of Quantified Clinical or Branded Drugs the denominator_value contains the total amount of the solution (not the amount of the ingredient). In all other drug concept classes the denominator amount is NULL because the concentration is always normalized to the unit of the denominator. So, a product containing 960 mg in 20 mL is provided as 48 mg/mL in the Clinical Drug and Clinical Drug Component, while as a Quantified Clinical Drug it is written as 960 mg/20 mL.
|
| 4 | If the absolute amount is provided (for example, 'Acetaminophen 5 MG Tablet') the AMOUNT_VALUE and AMOUNT_UNIT_CONCEPT_ID are used to define this content (in this case 5 and 'MG'). |
|
||||||
* If the strength is provided in % (volume or mass-percent are not distinguished) it is stored in the numerator_value/numerator_unit_concept_id field combination, with both the denominator_value and denominator_unit_concept_id set to NULL. If it is a Quantified Drug the total amount of drug is provided in the denominator_value/denominator_unit_concept_id pair. E.g., the 30 G Isoconazole 2% Topical Cream is provided as 2% / in Clinical Drug and Clinical Drug Component, and as 2% /30 G.
|
| 5 | If the concentration is provided (for example 'Acetaminophen 48 MG/ML Oral Solution') the NUMERATOR_VALUE in combination with the NUMERATOR_UNIT_CONCEPT_ID and DENOMINATOR_UNIT_CONCEPT_ID are used to define this content (in this case 48, 'MG' and 'ML').|
|
||||||
* Sometimes, one Ingredient is listed with different units within the same drug. This is very rare, and usually this happens if there are more than one Precise Ingredient. For example, 'Penicillin G, Benzathine 150000 UNT/ML / Penicillin G, Procaine 150000 MEQ/ML Injectable Suspension' contains Penicillin G in two different forms.
|
| 6 | In case of Quantified Clinical or Branded Drugs the DENOMINATOR_VALUE contains the total amount of the solution (not the amount of the ingredient). In all other drug concept classes the denominator amount is NULL because the concentration is always normalized to the unit of the denominator. So, a product containing 960 mg in 20 mL is provided as 48 mg/mL in the Clinical Drug and Clinical Drug Component, while as a Quantified Clinical Drug it is written as 960 mg/20 mL. |
|
||||||
* Sometimes, different ingredients in liquid drugs are listed with different units in the denominator_unit_concept_id. This is usually the case if the ingredients are liquids themselves (concentration provided as mL/mL) or solid substances (mg/mg). In these cases, the general assumptions is made that the density of the drug is that of water, and one can assume 1 g = 1 mL.
|
| 7 | If the strength is provided in % (volume or mass-percent are not distinguished) it is stored in the NUMERATOR_VALUE/NUMERATOR_UNIT_CONCEPT_ID field combination, with both the DENOMINATOR_VALUE and DENOMINATOR_UNIT_CONCEPT_ID set to NULL. If it is a Quantified Drug the total amount of drug is provided in the DENOMINATOR_VALUE/DENOMINATOR_UNIT_CONCEPT_ID pair. E.g., the 30 G Isoconazole 2% Topical Cream is provided as 2% / in Clinical Drug and Clinical Drug Component, and as 2% /30 G. |
|
||||||
* All Drug vocabularies containing Standard Concepts have entries in the DRUG_STRENGTH table.
|
| 8 | Sometimes, one Ingredient is listed with different units within the same drug. This is very rare, and usually this happens if there are more than one Precise Ingredient. For example, 'Penicillin G, Benzathine 150000 UNT/ML / Penicillin G, Procaine 150000 MEQ/ML Injectable Suspension' contains Penicillin G in two different forms. |
|
||||||
* There is now a Concept Class for supplier information whose relationships can be found in CONCEPT_RELATIONSHIP with a relationship_id of 'Has supplier' and 'Supplier of'
|
| 9 | Sometimes, different ingredients in liquid drugs are listed with different units in the DENOMINATOR_UNIT_CONCEPT_ID. This is usually the case if the ingredients are liquids themselves (concentration provided as mL/mL) or solid substances (mg/mg). In these cases, the general assumptions is made that the density of the drug is that of water, and one can assume 1 g = 1 mL. |
|
||||||
|
| 10 | All Drug vocabularies containing Standard Concepts have entries in the DRUG_STRENGTH table. |
|
||||||
|
| 11 | There is now a Concept Class for supplier information whose relationships can be found in CONCEPT_RELATIONSHIP with a RELATIONSHIP_ID of 'Has supplier' and 'Supplier of' |
|
||||||
|
|
@ -11,282 +11,15 @@ Field|Required|Type|Description
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
|
|
||||||
* There is one record for each Relationship.
|
No.|Convention Description
|
||||||
* Relationships are classified as hierarchical (parent-child) or non-hierarchical (lateral)
|
:--------|:------------------------------------
|
||||||
* They are used to determine which concept relationship records should be included in the computation of the CONCEPT_ANCESTOR table.
|
| 1 | There is one record for each Relationship. |
|
||||||
* The relationship_id field contains an alphanumerical identifier, that can also be used as the abbreviation of the Relationship.
|
| 2 | Relationships are classified as hierarchical (parent-child) or non-hierarchical (lateral)|
|
||||||
* The relationship_name field contains the unabbreviated names of the Relationship.
|
| 3 | They are used to determine which concept relationship records should be included in the computation of the CONCEPT_ANCESTOR table. |
|
||||||
* Relationships all exist symmetrically, i.e. in both direction. The relationship_id of the opposite Relationship is provided in the reverse_relationship_id field.
|
| 4 | The RELATIONSHIP_ID field contains an alphanumerical identifier, that can also be used as the abbreviation of the Relationship. |
|
||||||
* Each Relationship also has an equivalent entry in the Concept table, which is recorded in the relationship_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.
|
| 5 | The RELATIONSHIP_NAME field contains the unabbreviated names of the Relationship. |
|
||||||
* Hierarchical Relationships are used to build a hierarchical tree out of the Concepts, which is recorded in the CONCEPT_ANCESTOR table. For example, "has_ingredient" is a Relationship between Concept of the Concept Class 'Clinical Drug' and those of 'Ingredient', and all Ingredients can be classified as the "parental" hierarchical Concepts for the drug products they are part of. All 'Is a' Relationships are hierarchical.
|
| 6 | Relationships all exist symmetrically, i.e. in both direction. The RELATIONSHIP_ID of the opposite Relationship is provided in the REVERSE_RELATIONSHIP_ID field. |
|
||||||
* Relationships, also hierarchical, can be between Concepts within the same Vocabulary or those adopted from different Vocabulary sources.
|
| 7 | Each Relationship also has an equivalent entry in the Concept table, which is recorded in the RELATIONSHIP_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. |
|
||||||
* In past versions of the RELATIONSHIP table, the relationship_id used to be a numerical value. A conversion table between these old and new IDs is given below:
|
| 8 | Hierarchical Relationships are used to build a hierarchical tree out of the Concepts, which is recorded in the CONCEPT_ANCESTOR table. For example, 'has_ingredient' is a Relationship between Concept of the Concept Class 'Clinical Drug' and those of 'Ingredient', and all Ingredients can be classified as the 'parental' hierarchical Concepts for the drug products they are part of. All 'Is a' Relationships are hierarchical. |
|
||||||
|
| 9 | Relationships, also hierarchical, can be between Concepts within the same Vocabulary or those adopted from different Vocabulary sources. |
|
||||||
|
|
||||||
Previous Relationship_id|Version 5 Relationship_id
|
|
||||||
:-----------------------|:-----------------------------------
|
|
||||||
|1|LOINC replaced by|
|
|
||||||
|2|Has precise ing|
|
|
||||||
|3|Has tradename|
|
|
||||||
|4|RxNorm has dose form|
|
|
||||||
|5|Has form|
|
|
||||||
|6|RxNorm has ing|
|
|
||||||
|7|Constitutes|
|
|
||||||
|8|Contains|
|
|
||||||
|9|Reformulation of|
|
|
||||||
|10|Subsumes|
|
|
||||||
|11|NDFRT has dose form|
|
|
||||||
|12|Induces|
|
|
||||||
|13|May diagnose|
|
|
||||||
|14|Has physio effect|
|
|
||||||
|15|Has CI physio effect|
|
|
||||||
|16|NDFRT has ing|
|
|
||||||
|17|Has CI chem class|
|
|
||||||
|18|Has MoA|
|
|
||||||
|19|Has CI MoA|
|
|
||||||
|20|Has PK|
|
|
||||||
|21|May treat|
|
|
||||||
|22|CI to|
|
|
||||||
|23|May prevent|
|
|
||||||
|24|Has metabolites|
|
|
||||||
|25|Has metabolism|
|
|
||||||
|26|May be inhibited by|
|
|
||||||
|27|Has chem structure|
|
|
||||||
|28|NDFRT - RxNorm eq|
|
|
||||||
|29|Has recipient cat|
|
|
||||||
|30|Has proc site|
|
|
||||||
|31|Has priority|
|
|
||||||
|32|Has pathology|
|
|
||||||
|33|Has part of|
|
|
||||||
|34|Has severity|
|
|
||||||
|35|Has revision status|
|
|
||||||
|36|Has access|
|
|
||||||
|37|Has occurrence|
|
|
||||||
|38|Has method|
|
|
||||||
|39|Has laterality|
|
|
||||||
|40|Has interprets|
|
|
||||||
|41|Has indir morph|
|
|
||||||
|42|Has indir device|
|
|
||||||
|43|Has specimen|
|
|
||||||
|44|Has interpretation|
|
|
||||||
|45|Has intent|
|
|
||||||
|46|Has focus|
|
|
||||||
|47|Has manifestation|
|
|
||||||
|48|Has active ing|
|
|
||||||
|49|Has finding site|
|
|
||||||
|50|Has episodicity|
|
|
||||||
|51|Has dir subst|
|
|
||||||
|52|Has dir morph|
|
|
||||||
|53|Has dir device|
|
|
||||||
|54|Has component|
|
|
||||||
|55|Has causative agent|
|
|
||||||
|56|Has asso morph|
|
|
||||||
|57|Has asso finding|
|
|
||||||
|58|Has measurement|
|
|
||||||
|59|Has property|
|
|
||||||
|60|Has scale type|
|
|
||||||
|61|Has time aspect|
|
|
||||||
|62|Has specimen proc|
|
|
||||||
|63|Has specimen source|
|
|
||||||
|64|Has specimen morph|
|
|
||||||
|65|Has specimen topo|
|
|
||||||
|66|Has specimen subst|
|
|
||||||
|67|Has due to|
|
|
||||||
|68|Has relat context|
|
|
||||||
|69|Has dose form|
|
|
||||||
|70|Occurs after|
|
|
||||||
|71|Has asso proc|
|
|
||||||
|72|Has dir proc site|
|
|
||||||
|73|Has indir proc site|
|
|
||||||
|74|Has proc device|
|
|
||||||
|75|Has proc morph|
|
|
||||||
|76|Has finding context|
|
|
||||||
|77|Has proc context|
|
|
||||||
|78|Has temporal context|
|
|
||||||
|79|Findinga sso with|
|
|
||||||
|80|Has surgical appr|
|
|
||||||
|81|Using device|
|
|
||||||
|82|Using energy|
|
|
||||||
|83|Using subst|
|
|
||||||
|84|Using acc device|
|
|
||||||
|85|Has clinical course|
|
|
||||||
|86|Has route of admin|
|
|
||||||
|87|Using finding method|
|
|
||||||
|88|Using finding inform|
|
|
||||||
|92|ICD9P - SNOMED eq|
|
|
||||||
|93|CPT4 - SNOMED cat|
|
|
||||||
|94|CPT4 - SNOMED eq|
|
|
||||||
|125|MedDRA - SNOMED eq|
|
|
||||||
|126|Has FDA-appr ind|
|
|
||||||
|127|Has off-label ind|
|
|
||||||
|129|Has CI|
|
|
||||||
|130|ETC - RxNorm|
|
|
||||||
|131|ATC - RxNorm|
|
|
||||||
|132|SMQ - MedDRA|
|
|
||||||
|135|LOINC replaces|
|
|
||||||
|136|Precise ing of|
|
|
||||||
|137|Tradename of|
|
|
||||||
|138|RxNorm dose form of|
|
|
||||||
|139|Form of|
|
|
||||||
|140|RxNorm ing of|
|
|
||||||
|141|Consists of|
|
|
||||||
|142|Contained in|
|
|
||||||
|143|Reformulated in|
|
|
||||||
|144|Is a|
|
|
||||||
|145|NDFRT dose form of|
|
|
||||||
|146|Induced by|
|
|
||||||
|147|Diagnosed through|
|
|
||||||
|148|Physiol effect by|
|
|
||||||
|149|CI physiol effect by|
|
|
||||||
|150|NDFRT ing of|
|
|
||||||
|151|CI chem class of|
|
|
||||||
|152|MoA of|
|
|
||||||
|153|CI MoA of|
|
|
||||||
|154|PK of|
|
|
||||||
|155|May be treated by|
|
|
||||||
|156|CI by|
|
|
||||||
|157|May be prevented by|
|
|
||||||
|158|Metabolite of|
|
|
||||||
|159|Metabolism of|
|
|
||||||
|160|Inhibits effect|
|
|
||||||
|161|Chem structure of|
|
|
||||||
|162|RxNorm - NDFRT eq|
|
|
||||||
|163|Recipient cat of|
|
|
||||||
|164|Proc site of|
|
|
||||||
|165|Priority of|
|
|
||||||
|166|Pathology of|
|
|
||||||
|167|Part of|
|
|
||||||
|168|Severity of|
|
|
||||||
|169|Revision status of|
|
|
||||||
|170|Access of|
|
|
||||||
|171|Occurrence of|
|
|
||||||
|172|Method of|
|
|
||||||
|173|Laterality of|
|
|
||||||
|174|Interprets of|
|
|
||||||
|175|Indir morph of|
|
|
||||||
|176|Indir device of|
|
|
||||||
|177|Specimen of|
|
|
||||||
|178|Interpretation of|
|
|
||||||
|179|Intent of|
|
|
||||||
|180|Focus of|
|
|
||||||
|181|Manifestation of|
|
|
||||||
|182|Active ing of|
|
|
||||||
|183|Finding site of|
|
|
||||||
|184|Episodicity of|
|
|
||||||
|185|Dir subst of|
|
|
||||||
|186|Dir morph of|
|
|
||||||
|187|Dir device of|
|
|
||||||
|188|Component of|
|
|
||||||
|189|Causative agent of|
|
|
||||||
|190|Asso morph of|
|
|
||||||
|191|Asso finding of|
|
|
||||||
|192|Measurement of|
|
|
||||||
|193|Property of|
|
|
||||||
|194|Scale type of|
|
|
||||||
|195|Time aspect of|
|
|
||||||
|196|Specimen proc of|
|
|
||||||
|197|Specimen identity of|
|
|
||||||
|198|Specimen morph of|
|
|
||||||
|199|Specimen topo of|
|
|
||||||
|200|Specimen subst of|
|
|
||||||
|201|Due to of|
|
|
||||||
|202|Relat context of|
|
|
||||||
|203|Dose form of|
|
|
||||||
|204|Occurs before|
|
|
||||||
|205|Asso proc of|
|
|
||||||
|206|Dir proc site of|
|
|
||||||
|207|Indir proc site of|
|
|
||||||
|208|Proc device of|
|
|
||||||
|209|Proc morph of|
|
|
||||||
|210|Finding context of|
|
|
||||||
|211|Proc context of|
|
|
||||||
|212|Temporal context of|
|
|
||||||
|213|Asso with finding|
|
|
||||||
|214|Surgical appr of|
|
|
||||||
|215|Device used by|
|
|
||||||
|216|Energy used by|
|
|
||||||
|217|subst used by|
|
|
||||||
|218|Acc device used by|
|
|
||||||
|219|Clinical course of|
|
|
||||||
|220|Route of admin of|
|
|
||||||
|221|Finding method of|
|
|
||||||
|222|Finding inform of|
|
|
||||||
|226|SNOMED - ICD9P eq|
|
|
||||||
|227|SNOMED cat - CPT4|
|
|
||||||
|228|SNOMED - CPT4 eq|
|
|
||||||
|239|SNOMED - MedDRA eq|
|
|
||||||
|240|Is FDA-appr ind of|
|
|
||||||
|241|Is off-label ind of|
|
|
||||||
|243|Is CI of|
|
|
||||||
|244|RxNorm - ETC|
|
|
||||||
|245|RxNorm - ATC|
|
|
||||||
|246|MedDRA - SMQ|
|
|
||||||
|247|Ind/CI - SNOMED|
|
|
||||||
|248|SNOMED - ind/CI|
|
|
||||||
|275|Has therap class|
|
|
||||||
|276|Therap class of|
|
|
||||||
|277|Drug-drug inter for|
|
|
||||||
|278|Has drug-drug inter|
|
|
||||||
|279|Has pharma prep|
|
|
||||||
|280|Pharma prep in|
|
|
||||||
|281|Inferred class of|
|
|
||||||
|282|Has inferred class|
|
|
||||||
|283|SNOMED proc - HCPCS|
|
|
||||||
|284|HCPCS - SNOMED proc|
|
|
||||||
|285|RxNorm - NDFRT name|
|
|
||||||
|286|NDFRT - RxNorm name|
|
|
||||||
|287|ETC - RxNorm name|
|
|
||||||
|288|RxNorm - ETC name|
|
|
||||||
|289|ATC - RxNorm name|
|
|
||||||
|290|RxNorm - ATC name|
|
|
||||||
|291|HOI - SNOMED|
|
|
||||||
|292|SNOMED - HOI|
|
|
||||||
|293|DOI - RxNorm|
|
|
||||||
|294|RxNorm - DOI|
|
|
||||||
|295|HOI - MedDRA|
|
|
||||||
|296|MedDRA - HOI|
|
|
||||||
|297|NUCC - CMS Specialty|
|
|
||||||
|298|CMS Specialty - NUCC|
|
|
||||||
|299|DRG - MS-DRG eq|
|
|
||||||
|300|MS-DRG - DRG eq|
|
|
||||||
|301|DRG - MDC cat|
|
|
||||||
|302|MDC cat - DRG|
|
|
||||||
|303|Visit cat - PoS|
|
|
||||||
|304|PoS - Visit cat|
|
|
||||||
|305|VAProd - NDFRT|
|
|
||||||
|306|NDFRT - VAProd|
|
|
||||||
|307|VAProd - RxNorm eq|
|
|
||||||
|308|RxNorm - VAProd eq|
|
|
||||||
|309|RxNorm replaced by|
|
|
||||||
|310|RxNorm replaces|
|
|
||||||
|311|SNOMED replaced by|
|
|
||||||
|312|SNOMED replaces|
|
|
||||||
|313|ICD9P replaced by|
|
|
||||||
|314|ICD9P replaces|
|
|
||||||
|315|Multilex has ing|
|
|
||||||
|316|Multilex ing of|
|
|
||||||
|317|RxNorm - Multilex eq|
|
|
||||||
|318|Multilex - RxNorm eq|
|
|
||||||
|319|Multilex ing - class|
|
|
||||||
|320|Class - Multilex ing|
|
|
||||||
|321|Maps to|
|
|
||||||
|322|Mapped from|
|
|
||||||
|325|Map includes child|
|
|
||||||
|326|Included in map from|
|
|
||||||
|327|Map excludes child|
|
|
||||||
|328|Excluded in map from|
|
|
||||||
|345|UCUM replaced by|
|
|
||||||
|346|UCUM replaces|
|
|
||||||
|347|Concept replaced by|
|
|
||||||
|348|Concept replaces|
|
|
||||||
|349|Concept same_as to|
|
|
||||||
|350|Concept same_as from|
|
|
||||||
|351|Concept alt_to to|
|
|
||||||
|352|Concept alt_to from|
|
|
||||||
|353|Concept poss_eq to|
|
|
||||||
|354|Concept poss_eq from|
|
|
||||||
|355|Concept was_a to|
|
|
||||||
|356|Concept was_a from|
|
|
||||||
|357|SNOMED meas - HCPCS|
|
|
||||||
|358|HCPCS - SNOMED meas|
|
|
||||||
|359|Domain subsumes|
|
|
||||||
|360|Is domain|
|
|
||||||
|
|
@ -14,12 +14,14 @@ Field|Required|Type|Description
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
|
|
||||||
* This table is no longer used to distribute mapping information between source codes and Standard Concepts for the Standard Vocabularies. Instead, the CONCEPT_RELATIONSHIP table is used for this purpose, using the relationship_id='Maps to'.
|
No.|Convention Description
|
||||||
* However, this table can still be used for the translation of local source codes into Standard Concepts.
|
:--------|:------------------------------------
|
||||||
* **Note:** This table should not be used to translate source codes to Source Concepts. The source code of a Source Concept is captured in its concept_code field. If the source codes used in a given database do not follow correct formatting the ETL will have to perform this translation. For example, if ICD-9-CM codes are recorded without a dot the ETL will have to perform a lookup function that allows identifying the correct ICD-9-CM Source Concept (with the dot in the concept_code field).
|
| 1 | This table is no longer used to distribute mapping information between source codes and Standard Concepts for the Standard Vocabularies. Instead, the CONCEPT_RELATIONSHIP table is used for this purpose, using the relationship_id='Maps to'. |
|
||||||
* The source_concept_id, or the combination of the fields source_code and the source_vocabulary_id uniquely identifies the source information. It is the equivalent to the concept_id_1 field in the CONCEPT_RELATIONSHIP table.
|
| 2 | However, this table can still be used for the translation of local source codes into Standard Concepts.
|
||||||
* If there is no source_concept_id available because the source codes are local and not supported by the Standard Vocabulary, the content of the field is 0 (zero, not null) encoding an undefined concept. However, local Source Concepts are established (concept_id values above 2,000,000,000).
|
| 4 | **Note:** This table should not be used to translate source codes to Source Concepts. The source code of a Source Concept is captured in its concept_code field. If the source codes used in a given database do not follow correct formatting the ETL will have to perform this translation. For example, if ICD-9-CM codes are recorded without a dot the ETL will have to perform a lookup function that allows identifying the correct ICD-9-CM Source Concept (with the dot in the concept_code field). |
|
||||||
* The source_code_description contains an optional description of the source code.
|
| 5 | The SOURCE_CONCEPT_ID, or the combination of the fields source_code and the SOURCE_VOCABULARY_ID uniquely identifies the source information. It is the equivalent to the CONCEPT_ID_1 field in the CONCEPT_RELATIONSHIP table. |
|
||||||
* The target_concept_id contains the Concept the source code is mapped to. It is equivalent to the concept_id_2 in the CONCEPT_RELATIONSHIP table
|
| 6 | If there is no SOURCE_CONCEPT_ID available because the source codes are local and not supported by the Standard Vocabulary, the content of the field is 0 (zero, not null) encoding an undefined concept. However, local Source Concepts are established (concept_id values above 2,000,000,000). |
|
||||||
* The target_vocabulary_id field contains the vocabulary_id of the target concept. It is a duplication of the same information in the CONCEPT record of the Target Concept.
|
| 7 | The SOURCE_CODE_DESCRIPTION contains an optional description of the source code. |
|
||||||
* The fields valid_start_date, valid_end_date and invalid_reason are used to define the life cycle of the mapping information. Invalid mapping records should not be used for mapping information.
|
| 8 | The TARGET_CONCEPT_ID contains the Concept the source code is mapped to. It is equivalent to the concept_id_2 in the CONCEPT_RELATIONSHIP table |
|
||||||
|
| 9 | The TARGET_VOCABULARY_ID field contains the VOCABULARY_ID of the target concept. It is a duplication of the same information in the CONCEPT record of the Target Concept. |
|
||||||
|
| 10 | The fields VALID_START_DATE, VALID_END_DATE and INVALID_REASON are used to define the life cycle of the mapping information. Invalid mapping records should not be used for mapping information. |
|
||||||
|
|
|
||||||
|
|
@ -8,8 +8,6 @@
|
||||||
[CONCEPT_ANCESTOR](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR)
|
[CONCEPT_ANCESTOR](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT_ANCESTOR)
|
||||||
[SOURCE_TO_CONCEPT_MAP](https://github.com/OHDSI/CommonDataModel/wiki/SOURCE_TO_CONCEPT_MAP)
|
[SOURCE_TO_CONCEPT_MAP](https://github.com/OHDSI/CommonDataModel/wiki/SOURCE_TO_CONCEPT_MAP)
|
||||||
[DRUG_STRENGTH](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_STRENGTH)
|
[DRUG_STRENGTH](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_STRENGTH)
|
||||||
[COHORT_DEFINITION](https://github.com/OHDSI/CommonDataModel/wiki/COHORT_DEFINITION)
|
|
||||||
[ATTRIBUTE_DEFINITION](https://github.com/OHDSI/CommonDataModel/wiki/ATTRIBUTE_DEFINITION)
|
|
||||||
|
|
||||||
These tables contain detailed information about the Concepts used in all of the CDM fact tables. The content of the Standardized Vocabularies tables is not generated anew by each CDM implementation. Instead, it is maintained centrally as a service to the community.
|
These tables contain detailed information about the Concepts used in all of the CDM fact tables. The content of the Standardized Vocabularies tables is not generated anew by each CDM implementation. Instead, it is maintained centrally as a service to the community.
|
||||||
|
|
||||||
|
|
@ -21,7 +19,7 @@ A number of assumptions were made for the design of the Standardized Vocabularie
|
||||||
* Some Concepts are declared Standard Concepts, i.e. they are used to represent a certain clinical entity in the data. All Concepts may be Source Concepts; they represent how the entity was coded in the source. Standard Concepts are identified through the standard_concept field in the CONCEPT table.
|
* Some Concepts are declared Standard Concepts, i.e. they are used to represent a certain clinical entity in the data. All Concepts may be Source Concepts; they represent how the entity was coded in the source. Standard Concepts are identified through the standard_concept field in the CONCEPT table.
|
||||||
* Records in the CONCEPT_RELATIONSHIP table define semantic relationships between Concepts. Such relationships can be hierarchical or lateral.
|
* Records in the CONCEPT_RELATIONSHIP table define semantic relationships between Concepts. Such relationships can be hierarchical or lateral.
|
||||||
* Records in the CONCEPT_RELATIONSHIP table are used to map Source codes to Standard Concepts, replacing the mechanism of the SOURCE_TO_CONCEPT_MAP table used in prior Standardized Vocabularies versions. The SOURCE_TO_CONCEPT_MAP table is retained as an optional aid to bookkeeping codes not found in the Standardized Vocabularies.
|
* Records in the CONCEPT_RELATIONSHIP table are used to map Source codes to Standard Concepts, replacing the mechanism of the SOURCE_TO_CONCEPT_MAP table used in prior Standardized Vocabularies versions. The SOURCE_TO_CONCEPT_MAP table is retained as an optional aid to bookkeeping codes not found in the Standardized Vocabularies.
|
||||||
* Chains of hierarchical relationships are recorded in the CONCEPT_ANCESTOR table. Ancestry relationships are only recorded between Standard Concepts that are valid (not deprecated) and are connected through valid and hierarchical relationships in the RELATIONSHIP table (flag defines_ancestry).
|
* Chains of hierarchical relationships are recorded in the CONCEPT_ANCESTOR table. Ancestry relationships are only recorded between Standard Concepts that are valid (not deprecated) and are connected through valid and hierarchical relationships in the RELATIONSHIP table (flag DEFINES_ANCESTRY).
|
||||||
|
|
||||||
The advantage of this approach lies in the preservation of codes and relationships between them without adherence to the multiple different source data structures, a simple design for standardized access, and the optimization of performance for analysis. Navigation among Standard Concepts does not require knowledge of the source vocabulary. Finally, the approach is scalable and future vocabularies can be integrated easily. On the other hand, extensive transformation of source data to the Vocabulary is required and not every source data structure and original source hierarchy can be retained.
|
The advantage of this approach lies in the preservation of codes and relationships between them without adherence to the multiple different source data structures, a simple design for standardized access, and the optimization of performance for analysis. Navigation among Standard Concepts does not require knowledge of the source vocabulary. Finally, the approach is scalable and future vocabularies can be integrated easily. On the other hand, extensive transformation of source data to the Vocabulary is required and not every source data structure and original source hierarchy can be retained.
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -5,81 +5,15 @@ Field|Required|Type|Description
|
||||||
|vocabulary_id|Yes|varchar(20)|A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit.|
|
|vocabulary_id|Yes|varchar(20)|A unique identifier for each Vocabulary, such as ICD9CM, SNOMED, Visit.|
|
||||||
|vocabulary_name|Yes|varchar(255)|The name describing the vocabulary, for example "International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS)" etc.|
|
|vocabulary_name|Yes|varchar(255)|The name describing the vocabulary, for example "International Classification of Diseases, Ninth Revision, Clinical Modification, Volume 1 and 2 (NCHS)" etc.|
|
||||||
|vocabulary_reference|Yes|varchar(255)|External reference to documentation or available download of the about the vocabulary.|
|
|vocabulary_reference|Yes|varchar(255)|External reference to documentation or available download of the about the vocabulary.|
|
||||||
|vocabulary_version|Yes|varchar(255)|Version of the Vocabulary as indicated in the source.|
|
|vocabulary_version|No|varchar(255)|Version of the Vocabulary as indicated in the source.|
|
||||||
|vocabulary_concept_id|Yes|integer|A foreign key that refers to a standard concept identifier in the CONCEPT table for the Vocabulary the VOCABULARY record belongs to.|
|
|vocabulary_concept_id|Yes|integer|A foreign key that refers to a standard concept identifier in the CONCEPT table for the Vocabulary the VOCABULARY record belongs to.|
|
||||||
|
|
||||||
### Conventions
|
### Conventions
|
||||||
|
|
||||||
* There is one record for each Vocabulary. One Vocabulary source or vendor can issue several Vocabularies, each of them creating their own record in the VOCABULARY table. However, the choice of whether a Vocabulary contains Concepts of different Concept Classes, or when these different classes constitute separate Vocabularies cannot precisely be decided based on the definition of what constitutes a Vocabulary. For example, the ICD-9 Volume 1 and 2 codes (ICD9CM, containing predominantly conditions and some procedures and observations) and the ICD-9 Volume 3 codes (ICD9Proc, containing predominantly procedures) are realized as two different Vocabularies. On the other hand, SNOMED-CT codes of the class Condition and those of the class Procedure are part of one and the same Vocabulary. Please refer to the Standardized Vocabularies [specifications](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary) for details of each Vocabulary.
|
No.|Convention Description
|
||||||
|
:--------|:------------------------------------
|
||||||
* The vocabulary_id field contains an alphanumerical identifier, that can also be used as the abbreviation of the Vocabulary name.
|
| 1 | There is one record for each Vocabulary. One Vocabulary source or vendor can issue several Vocabularies, each of them creating their own record in the VOCABULARY table. However, the choice of whether a Vocabulary contains Concepts of different Concept Classes, or when these different classes constitute separate Vocabularies cannot precisely be decided based on the definition of what constitutes a Vocabulary. For example, the ICD-9 Volume 1 and 2 codes (ICD9CM, containing predominantly conditions and some procedures and observations) and the ICD-9 Volume 3 codes (ICD9Proc, containing predominantly procedures) are realized as two different Vocabularies. On the other hand, SNOMED-CT codes of the class Condition and those of the class Procedure are part of one and the same Vocabulary. Please refer to the Standardized Vocabularies [specifications](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary) for details of each Vocabulary. |
|
||||||
* The record with vocabulary_id = 'None' is reserved to contain information regarding the current version of the Entire Standardized Vocabularies.
|
| 2 | The VOCABULARY_ID field contains an alphanumerical identifier, that can also be used as the abbreviation of the Vocabulary name. |
|
||||||
* The vocabulary_name field contains the full official name of the Vocabulary, as well as the source or vendor in parenthesis.
|
| 3 | The record with VOCABULARY_ID = 'None' is reserved to contain information regarding the current version of the Entire Standardized Vocabularies. |
|
||||||
* Each Vocabulary has an entry in the CONCEPT table, which is recorded in the vocabulary_concept_id field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by a unique Concept.
|
| 4 | The VOCABULARY_NAME field contains the full official name of the Vocabulary, as well as the source or vendor in parenthesis. |
|
||||||
* In past versions of the VOCABULARY table, the vocabulary_id used to be a numerical value. A conversion table between these old and new IDs is given below:
|
| 5 | Each Vocabulary has an entry in the CONCEPT table, which is recorded in the VOCABULARY_CONCEPT_ID field. This is for purposes of creating a closed Information Model, where all entities in the OMOP CDM are covered by a unique Concept. |
|
||||||
|
|
||||||
Previous VOCABULARY_ID|Version 5 VOCABULARY_ID
|
|
||||||
----------------------|------------------
|
|
||||||
|0|None|
|
|
||||||
|1|[SNOMED](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:snomed)|
|
|
||||||
|2|[ICD9CM](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:icd9cm)|
|
|
||||||
|3|ICD9Proc|
|
|
||||||
|4|[CPT4](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:cpt4)|
|
|
||||||
|5|HCPCS|
|
|
||||||
|6|[LOINC](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:loinc)|
|
|
||||||
|7|NDFRT|
|
|
||||||
|8|[RxNorm](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:rxnorm)|
|
|
||||||
|9|[NDC](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:ndc)|
|
|
||||||
|10|GPI|
|
|
||||||
|11|[UCUM](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:ucum)|
|
|
||||||
|12|[Gender](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:gender)|
|
|
||||||
|13|Race|
|
|
||||||
|14|Place of Service|
|
|
||||||
|15|MedDRA|
|
|
||||||
|16|Multum|
|
|
||||||
|17|Read|
|
|
||||||
|18|OXMIS|
|
|
||||||
|19|Indication|
|
|
||||||
|20|ETC|
|
|
||||||
|21|[ATC](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:atc)|
|
|
||||||
|22|Multilex|
|
|
||||||
|24|Visit|
|
|
||||||
|28|VA Product|
|
|
||||||
|31|SMQ|
|
|
||||||
|32|VA Class|
|
|
||||||
|33|Cohort|
|
|
||||||
|34|[ICD10](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:icd10)|
|
|
||||||
|35|[ICD10PCS](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:icd10pcs)|
|
|
||||||
|36|Drug Type|
|
|
||||||
|37|Condition Type|
|
|
||||||
|38|Procedure Type|
|
|
||||||
|39|Observation Type|
|
|
||||||
|40|DRG|
|
|
||||||
|41|MDC|
|
|
||||||
|42|APC|
|
|
||||||
|43|Revenue Code|
|
|
||||||
|44|[Ethnicity](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:ethnicity)|
|
|
||||||
|45|Death Type|
|
|
||||||
|46|[Mesh](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:mesh)|
|
|
||||||
|47|NUCC|
|
|
||||||
|48|Specialty|
|
|
||||||
|49|[LOINC](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:loinc)|
|
|
||||||
|50|SPL|
|
|
||||||
|53|Genseqno|
|
|
||||||
|54|CCS|
|
|
||||||
|55|OPCS4|
|
|
||||||
|56|Gemscript|
|
|
||||||
|57|HES Specialty|
|
|
||||||
|58|Note Type|
|
|
||||||
|59|Domain|
|
|
||||||
|60|PCORNet|
|
|
||||||
|61|Obs Period Type|
|
|
||||||
|62|Visit Type|
|
|
||||||
|63|Device Type|
|
|
||||||
|64|Meas Type|
|
|
||||||
|65|[Currency](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:currency)|
|
|
||||||
|66|Relationship|
|
|
||||||
|67|Vocabulary|
|
|
||||||
|68|Concept Class|
|
|
||||||
|69|Cohort Type|
|
|
||||||
|70|[ICD10CM](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary:icd10cm)|
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue