From ea23a86030852fc09a7ee02df799a41ab5d3bd69 Mon Sep 17 00:00:00 2001 From: Clair Blacketer Date: Thu, 14 Jun 2018 16:15:36 -0400 Subject: [PATCH] CDM v5.3.1 wiki updates --- StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md | 6 +++--- StandardizedClinicalDataTables/DEVICE_EXPOSURE.md | 4 ++-- StandardizedClinicalDataTables/NOTE_NLP.md | 4 ++-- .../Standardized-Clinical-Data-Tables.md | 1 + StandardizedMetadata/CDM_SOURCE.md | 2 +- StandardizedMetadata/METADATA.md | 8 ++++++-- StandardizedVocabularies/ATTRIBUTE_DEFINITION.md | 2 +- StandardizedVocabularies/COHORT_DEFINITION.md | 4 ++-- StandardizedVocabularies/CONCEPT_SYNONYM.md | 4 ++-- StandardizedVocabularies/RELATIONSHIP.md | 2 +- _Footer.md | 2 +- 11 files changed, 22 insertions(+), 17 deletions(-) diff --git a/StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md b/StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md index fc38392..06a0638 100644 --- a/StandardizedClinicalDataTables/CONDITION_OCCURRENCE.md +++ b/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 diff --git a/StandardizedClinicalDataTables/DEVICE_EXPOSURE.md b/StandardizedClinicalDataTables/DEVICE_EXPOSURE.md index 8e56bf6..fdfd3a6 100644 --- a/StandardizedClinicalDataTables/DEVICE_EXPOSURE.md +++ b/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. diff --git a/StandardizedClinicalDataTables/NOTE_NLP.md b/StandardizedClinicalDataTables/NOTE_NLP.md index 0d7523f..be71359 100644 --- a/StandardizedClinicalDataTables/NOTE_NLP.md +++ b/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”). diff --git a/StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md b/StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md index 50e95cd..01469c2 100644 --- a/StandardizedClinicalDataTables/Standardized-Clinical-Data-Tables.md +++ b/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) diff --git a/StandardizedMetadata/CDM_SOURCE.md b/StandardizedMetadata/CDM_SOURCE.md index 381b017..ec049e6 100644 --- a/StandardizedMetadata/CDM_SOURCE.md +++ b/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| diff --git a/StandardizedMetadata/METADATA.md b/StandardizedMetadata/METADATA.md index 8e47369..bbcc45d 100644 --- a/StandardizedMetadata/METADATA.md +++ b/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| \ No newline at end of file +|metadata date |No |date |The date associated with the metadata| +|metadata_datetime |No |datetime |The date and time associated with the metadata| + +### Conventions + + * \ No newline at end of file diff --git a/StandardizedVocabularies/ATTRIBUTE_DEFINITION.md b/StandardizedVocabularies/ATTRIBUTE_DEFINITION.md index dfe9c5e..681cbb7 100644 --- a/StandardizedVocabularies/ATTRIBUTE_DEFINITION.md +++ b/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| diff --git a/StandardizedVocabularies/COHORT_DEFINITION.md b/StandardizedVocabularies/COHORT_DEFINITION.md index de0fd37..3c4d8e1 100644 --- a/StandardizedVocabularies/COHORT_DEFINITION.md +++ b/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. diff --git a/StandardizedVocabularies/CONCEPT_SYNONYM.md b/StandardizedVocabularies/CONCEPT_SYNONYM.md index 38abb18..37cb1f3 100644 --- a/StandardizedVocabularies/CONCEPT_SYNONYM.md +++ b/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. diff --git a/StandardizedVocabularies/RELATIONSHIP.md b/StandardizedVocabularies/RELATIONSHIP.md index 211ad26..2f69aac 100644 --- a/StandardizedVocabularies/RELATIONSHIP.md +++ b/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.| diff --git a/_Footer.md b/_Footer.md index 3cbc8aa..f85f272 100644 --- a/_Footer.md +++ b/_Footer.md @@ -1 +1 @@ -***OMOP Common Data Model v5.3 Specifications*** \ No newline at end of file +***OMOP Common Data Model v5.3 Specifications 14June2018*** \ No newline at end of file