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

CDM v5.3.1 wiki updates

Clair Blacketer 2018-06-14 16:15:36 -04:00
parent ee14f60aa5
commit ea23a86030
11 changed files with 22 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md

@ -16,11 +16,11 @@ Field|Required|Type|Description
| stop_reason | No | varchar(20) | The reason that the condition was no longer present, as indicated in the source data. |
| provider_id | No | integer | A foreign key to the Provider in the PROVIDER table who was responsible for capturing (diagnosing) the Condition. |
| visit_occurrence_id | No | integer | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Condition was determined (diagnosed). |
| visit_detail_id | No | integer | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed). | visit_detail_id | No | integer | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed). |
| visit_detail_id | No | integer | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed). |
| condition_source_value | No | varchar(50) | The source code for the condition as it appears in the source data. This code is mapped to a standard condition concept in the Standardized Vocabularies and the original code is stored here for reference. |
| condition_source_concept_id | No | integer | A foreign key to a Condition Concept that refers to the code used in the source. |
| condition_status_source_value | No | varchar(50) | The source code for the condition status as it appears in the source data. |
| condition_status_concept_id | No | integer | A foreign key to the predefined Concept in the Standard Vocabulary reflecting the condition status | |
| condition_status_source_value | No | varchar(50) | The source code for the condition status as it appears in the source data. |
| condition_status_concept_id | No | integer | A foreign key to the predefined Concept in the Standard Vocabulary reflecting the condition status |
### Conventions

4
StandardizedClinicalDataTables/DEVICE_EXPOSURE.md

@ -16,14 +16,14 @@ Field|Required|Type|Description
|visit_occurrence_id|No|integer|A foreign key to the visit in the VISIT_OCCURRENCE table during which the device was used.|
|visit_detail_id|No|integer|A foreign key to the visit detail in the VISIT_DETAIL table during which the Drug Exposure was initiated.|
|device_source_value|No|varchar(50)|The source code for the Device as it appears in the source data. This code is mapped to a standard Device Concept in the Standardized Vocabularies and the original code is stored here for reference.|
|device_source_ concept_id|No|integer|A foreign key to a Device Concept that refers to the code used in the source.|
|device_source_concept_id|No|integer|A foreign key to a Device Concept that refers to the code used in the source.|
### Conventions
* The distinction between Devices or supplies and procedures are sometimes blurry, but the former are physical objects while the latter are actions, often to apply a Device or supply.
* For medical devices that are regulated by the FDA, if a Unique Device Identification (UDI) is provided if available in the data source, and is recorded in the unique_device_id field.
* Valid Device Concepts belong to the "Device" domain. The Concepts of this domain are derived from the DI portion of a UDI or based on other source vocabularies, like HCPCS.
* A Device Type is assigned to each Device Exposure to track from what source the information was drawn or inferred. The valid vocabulary_id or concept_class_id for these Concepts is "Device Type".
* A Device Type is assigned to each Device Exposure to track from what source the information was drawn or inferred. The valid domain_id for these Concepts is "Device Type".
* The Visit during which the Device was first used is recorded through a reference to the VISIT_OCCURRENCE table. This information is not always available.
* The Visit Detail during which the Device was first used is recorded through a reference to the VISIT_DETAIL table. This information is not always available.
* The Provider exposing the patient to the Device is recorded through a reference to the PROVIDER table. This information is not always available.

4
StandardizedClinicalDataTables/NOTE_NLP.md

@ -12,8 +12,8 @@ note_nlp_concept_id | No | integer | A foreign key to the predefined Concept i
note_nlp_source_concept_id | No | integer | A foreign key to a Concept that refers to the code in the source vocabulary used by the NLP system
nlp_system | No | varchar(250) | Name and version of the NLP system that extracted the term.Useful for data provenance.
nlp_date | Yes | date | The date of the note processing.Useful for data provenance.
nlp_date_time | No | datetime | The date and time of the note processing. Useful for data provenance.
term_exists | No | varchar(1) | A summary modifier that signifies presence or absence of the term for a given patient. Useful for quick querying. *
nlp_datetime | No | datetime | The date and time of the note processing. Useful for data provenance.
term_exists | No | varchar(1) | A summary modifier that signifies presence or absence of the term for a given patient. Useful for quick querying.
term_temporal | No | varchar(50) | An optional time modifier associated with the extracted term. (for now “past” or “present” only). Standardize it later.
term_modifiers | No | varchar(2000) | A compact description of all the modifiers of the specific term extracted by the NLP system. (e.g. “son has rash” ? “negated=no,subject=family, certainty=undef,conditional=false,general=false”).

1
StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md

@ -3,6 +3,7 @@
[SPECIMEN](https://github.com/OHDSI/CommonDataModel/wiki/SPECIMEN)
[DEATH](https://github.com/OHDSI/CommonDataModel/wiki/DEATH)
[VISIT_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_OCCURRENCE)
[VISIT_DETAIL](https://github.com/OHDSI/CommonDataModel/wiki/VISIT_DETAIL)
[PROCEDURE_OCCURRENCE](https://github.com/OHDSI/CommonDataModel/wiki/PROCEDURE_OCCURRENCE)
[DRUG_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DRUG_EXPOSURE)
[DEVICE_EXPOSURE](https://github.com/OHDSI/CommonDataModel/wiki/DEVICE_EXPOSURE)

2
StandardizedMetadata/CDM_SOURCE.md

@ -7,7 +7,7 @@ Field|Required|Type|Description
|cdm_holder|No|varchar(255)|The name of the organization responsible for the development of the CDM instance|
|source_description|No|CLOB|A description of the source data origin and purpose for collection. The description may contain a summary of the period of time that is expected to be covered by this dataset.|
|source_documentation_reference|No|varchar(255)|URL or other external reference to location of source documentation|
|cdm_etl _reference|No|varchar(255)|URL or other external reference to location of ETL specification documentation and ETL source code|
|cdm_etl_reference|No|varchar(255)|URL or other external reference to location of ETL specification documentation and ETL source code|
|source_release_date|No|date|The date for which the source data are most current, such as the last day of data capture|
|cdm_release_date|No|date|The date when the CDM was instantiated|
|cdm_version|No|varchar(10)|The version of CDM used|

8
StandardizedMetadata/METADATA.md

@ -7,5 +7,9 @@ Field |Required |Type |Description
|name |Yes |varchar(250) |The name of the Concept stored in metadata_concept_id or a description of the data being stored.|
|value_as_string |No |nvarchar |The metadata value stored as a string.|
|value_as_concept_id |No |integer |A foreign key to a metadata value stored as a Concept ID.|
|metadata_date |No |date |The date associated with the metadata|
|metadata_datetime |No |datetime |The date and time associated with the metadata|
|metadata date |No |date |The date associated with the metadata|
|metadata_datetime |No |datetime |The date and time associated with the metadata|
### Conventions
*

2
StandardizedVocabularies/ATTRIBUTE_DEFINITION.md

@ -1,7 +1,7 @@
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|

4
StandardizedVocabularies/COHORT_DEFINITION.md

@ -1,14 +1,14 @@
The COHORT_DEFINITION table contains records defining a Cohort derived from the data through the associated description and syntax and upon instantiation (execution of the algorithm) placed into the COHORT table. Cohorts are a set of subjects that satisfy a given combination of inclusion criteria for a duration of time. The COHORT_DEFINITION table provides a standardized structure for maintaining the rules governing the inclusion of a subject into a cohort, and can store operational programming code to instantiate the cohort within the OMOP Common Data Model.
Field|Required|Type|Description
:------------------------------|:--------|:-----|:-----------------------------------------------
:------------------------------|:--------|:--------------|:-----------------------------------------------
|cohort_definition_id|Yes|integer|A unique identifier for each Cohort.|
|cohort_definition_name|Yes|varchar(255)|A short description of the Cohort.|
|cohort_definition_description|No|varchar(MAX)|A complete description of the Cohort definition|
|definition_type_concept_id|Yes|integer|Type defining what kind of Cohort Definition the record represents and how the syntax may be executed|
|cohort_definition_syntax|No|varchar(MAX)|Syntax or code to operationalize the Cohort definition|
|subject_concept_id|Yes|integer|A foreign key to the Concept to which defines the domain of subjects that are members of the cohort (e.g., Person, Provider, Visit).|
|cohort_initiation_date|No|Date|A date to indicate when the Cohort was instantiated in the COHORT table|
|cohort_initiation_date|No|Date|A date to indicate when the Cohort was initiated in the COHORT table|
### Conventions
* The cohort_definition_syntax does not prescribe any specific syntax or programming language. Typically, it would be any flavor SQL, a cohort definition language, or a free-text description of the algorithm.

4
StandardizedVocabularies/CONCEPT_SYNONYM.md

@ -1,6 +1,6 @@
The CONCEPT_SYNONYM table is used to store alternate names and descriptions for Concepts.
|Field|Required|Type|Description|
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.|
@ -8,6 +8,6 @@ The CONCEPT_SYNONYM table is used to store alternate names and descriptions for
### Conventions
* The concept_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.
* 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.
* 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.

2
StandardizedVocabularies/RELATIONSHIP.md

@ -1,6 +1,6 @@
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|
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.|

2
_Footer.md

@ -1 +1 @@
***OMOP Common Data Model v5.3 Specifications***
***OMOP Common Data Model v5.3 Specifications 14June2018***