mz-health/OMOP
mz-health
/
OMOP
mirror of https://github.com/OHDSI/CommonDataModel.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Update md files

clairblacketer 2017-06-20 14:27:42 -04:00
parent 40c40451e4
commit 51ee7c7ee6
12 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
StandardizedMetadata/CDM_SOURCE.md

@ -1,7 +1,7 @@
The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.
Field|Required|Type|Description
:------------------------------|:--------|:-----|:---------------------------------------------------
:------------------------------|:--------|:------------|:-----------------------------------------
|cdm_source_name|Yes|varchar(255)|The full name of the source|
|cdm_source_abbreviation|No|varchar(25)|An abbreviation of the name|
|cdm_holder|No|varchar(255)|The name of the organization responsible for the development of the CDM instance|

4
StandardizedMetadata/Standardized-Metadata.md

@ -2,8 +2,8 @@
All metadata about the data should be derived from the data themselves. However, the following contains a few key pieces of information that are convenient especially for software applications utilizing the CDM data.
Below provides and entity-relationship diagram highlighting the tables withing the Standardized Metadata portion of the OMOP Common Data Model:
Below provides an entity-relationship diagram highlighting the tables within the Standardized Metadata portion of the OMOP Common Data Model:
![Metadata entity-relationship diagram](http://www.ohdsi.org/web/wiki/lib/exe/fetch.php?w=200&tok=f95343&media=documentation:cdm:standard_meta_data.png)

2
StandardizedVocabularies/CONCEPT.md

@ -5,7 +5,7 @@ Concepts can represent broad categories (like 'Cardiovascular disease'), detaile
Records in the Standardized Vocabularies tables are derived from national or international vocabularies such as SNOMED-CT, RxNorm, and LOINC, or custom Concepts defined to cover various aspects of observational data analysis. For a detailed description of these vocabularies, their use in the OMOP CDM and their relationships to each other please refer to the [specifications](http://www.ohdsi.org/web/wiki/doku.php?id=documentation:vocabulary).
Field|Required|Type|Description
:---------------|:-----|:----------|:-------------------------------
:---------------|:--------|:------------|:-----------------------------
|concept_id|Yes|integer|A unique identifier for each Concept across all domains.|
|concept_name|Yes|varchar(255)|An unambiguous, meaningful and descriptive name for the Concept.|
|domain_id|Yes|varchar(20)|A foreign key to the [DOMAIN](https://github.com/OHDSI/CommonDataModel/wiki/DOMAIN) table the Concept belongs to.|

2
StandardizedVocabularies/CONCEPT_ANCESTOR.md

@ -3,7 +3,7 @@ The CONCEPT_ANCESTOR table is designed to simplify observational analysis by pro
This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.
Field|Required|Type|Description
:---------------------------|:--------|:-----|:----------------------------------------------------
:---------------------------|:--------|:------------|:---------------------------------------
|ancestor_concept_id|Yes|integer|A foreign key to the concept in the concept table for the higher-level concept that forms the ancestor in the relationship.|
|descendant_concept_id|Yes|integer|A foreign key to the concept in the concept table for the lower-level concept that forms the descendant in the relationship.|
|min_levels_of_separation|Yes|integer|The minimum separation in number of levels of hierarchy between ancestor and descendant concepts. This is an attribute that is used to simplify hierarchic analysis.|

2
StandardizedVocabularies/CONCEPT_CLASS.md

@ -1,7 +1,7 @@
The CONCEPT_CLASS table is a reference table, which includes a list of the classifications used to differentiate Concepts within a given Vocabulary. This reference table is populated with a single record for each Concept Class:
Field|Required|Type|Description
:------------------------|:--------|:---------|:----------------------------------------------
:------------------------|:--------|:----------|:---------------------------------------
|concept_class_id|Yes|varchar(20)|A unique key for each class.|
|concept_class_name|Yes|varchar(255)|The name describing the Concept Class, e.g. "Clinical Finding", "Ingredient", etc.|
|concept_class_concept_id|Yes|integer|A foreign key that refers to an identifier in the [CONCEPT](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT) table for the unique Concept Class the record belongs to.|

2
StandardizedVocabularies/CONCEPT_RELATIONSHIP.md

@ -1,7 +1,7 @@
The CONCEPT_RELATIONSHIP table contains records that define direct relationships between any two Concepts and the nature or type of the relationship. Each type of a relationship is defined in the [RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP) table.
Field|Required|Type|Description
:----------------------|:---------|:-----|:-------------------------------------------------------
:----------------------|:---------|:------------|:---------------------------------------------
|concept_id_1|Yes|integer|A foreign key to a Concept in the [CONCEPT](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT) table associated with the relationship. Relationships are directional, and this field represents the source concept designation.|
|concept_id_2|Yes|integer|A foreign key to a Concept in the [CONCEPT](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT) table associated with the relationship. Relationships are directional, and this field represents the destination concept designation.|
|relationship_id|Yes|varchar(20)|A unique identifier to the type or nature of the Relationship as defined in the [RELATIONSHIP](https://github.com/OHDSI/CommonDataModel/wiki/RELATIONSHIP) table.|

2
StandardizedVocabularies/CONCEPT_SYNONYM.md

@ -1,7 +1,7 @@
The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.
|Field|Required|Type|Description|
:---------------------|:---------|:-----|:-------------------------------------------
:---------------------|:---------|:------------|:------------------------
|concept_id|Yes|Integer|A foreign key to the Concept in the CONCEPT table.|
|concept_synonym_name|Yes|varchar(1000)|The alternative name for the Concept.|
|language_concept_id|Yes|integer|A foreign key to a Concept representing the language.|

2
StandardizedVocabularies/DOMAIN.md

@ -1,7 +1,7 @@
The DOMAIN table includes a list of OMOP-defined Domains the Concepts of the Standardized Vocabularies can belong to. A Domain defines the set of allowable Concepts for the standardized fields in the CDM tables. For example, the "Condition" Domain contains Concepts that describe a condition of a patient, and these Concepts can only be stored in the condition_concept_id field of the [CONDITION_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_OCCURRENCE) and [CONDITION_ERA](https://github.com/OHDSI/CommonDataModel/wiki/CONDITION_ERA) tables. This reference table is populated with a single record for each Domain and includes a descriptive name for the Domain.
Field|Required|Type|Description
:------------------|:--------|:------------|:---------------------------------------
:------------------|:--------|:------------|:----------------------------------
|domain_id|Yes|varchar(20)|A unique key for each domain.|
|domain_name|Yes|varchar(255)|The name describing the Domain, e.g. "Condition", "Procedure", "Measurement" etc.|
|domain_concept_id|Yes|integer|A foreign key that refers to an identifier in the [CONCEPT](https://github.com/OHDSI/CommonDataModel/wiki/CONCEPT) table for the unique Domain Concept the Domain record belongs to.|

2
StandardizedVocabularies/DRUG_STRENGTH.md

@ -1,7 +1,7 @@
The DRUG_STRENGTH table contains structured content about the amount or concentration and associated units of a specific ingredient contained within a particular drug product. This table is supplemental information to support standardized analysis of drug utilization.
Field|Required|Type|Description
:----------------------------|:--------|:-----|:---------------------------------------------------------------
:----------------------------|:--------|:------------|:----------------------------------------
|drug_concept_id|Yes|integer|A foreign key to the Concept in the CONCEPT table representing the identifier for Branded Drug or Clinical Drug Concept.|
|ingredient_concept_id|Yes|integer|A foreign key to the Concept in the CONCEPT table, representing the identifier for drug Ingredient Concept contained within the drug product.|
|amount_value|No|float|The numeric value associated with the amount of active ingredient contained within the product.|

2
StandardizedVocabularies/RELATIONSHIP.md

@ -1,7 +1,7 @@
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.
|Field|Required|Type|Description|
:-----------------------|:--------|:-----|:-----------------------------------------------------
:-----------------------|:--------|:------------|:-----------------------------------------
|relationship_id|Yes|varchar(20)| The type of relationship captured by the relationship record.|
|relationship_name|Yes|varchar(255)| The text that describes the relationship type.|
|is_hierarchical|Yes|varchar(1)|Defines whether a relationship defines concepts into classes or hierarchies. Values are 1 for hierarchical relationship or 0 if not.|

2
StandardizedVocabularies/SOURCE_TO_CONCEPT_MAP.md

@ -1,7 +1,7 @@
The source to concept map table is a legacy data structure within the OMOP Common Data Model, recommended for use in ETL processes to maintain local source codes which are not available as Concepts in the Standardized Vocabularies, and to establish mappings for each source code into a Standard Concept as target_concept_ids that can be used to populate the Common Data Model tables. The SOURCE_TO_CONCEPT_MAP table is no longer populated with content within the Standardized Vocabularies published to the OMOP community.
Field|Required|Type|Description
:-------------------------|:--------|:-----|:---------------------------------------------
:-------------------------|:--------|:------------|:----------------------------
|source_code|Yes|varchar(50)|The source code being translated into a Standard Concept.|
|source_concept_id|Yes|integer|A foreign key to the Source Concept that is being translated into a Standard Concept.|
|source_vocabulary_id|No|varchar(20)|A foreign key to the VOCABULARY table defining the vocabulary of the source code that is being translated to a Standard Concept.|

2
StandardizedVocabularies/VOCABULARY.md

@ -1,7 +1,7 @@
The VOCABULARY table includes a list of the Vocabularies collected from various sources or created de novo by the OMOP community. This reference table is populated with a single record for each Vocabulary source and includes a descriptive name and other associated attributes for the Vocabulary.
Field|Required|Type|Description
:----------------------|:----|:-------------|:-----------------------------------------------
:----------------------|:--------|:-------------|:----------------------------------------
|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_reference|Yes|varchar(255)|External reference to documentation or available download of the about the vocabulary.|