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

Adding EPISODE and EPISODE event tables

This commit is contained in:
Clair Blacketer 2021-08-19 12:58:41 -04:00
parent a2812b85e5
commit c9463d0cf1
2 changed files with 20 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
inst/csv/OMOP_CDMv5.4_Field_Level.csv
View File

@ -40,10 +40,10 @@ VISIT_OCCURRENCE,provider_id,No,integer,"There will only be one provider per vis
VISIT_OCCURRENCE,care_site_id,No,integer,This field provides information about the Care Site where the Visit took place.,There should only be one Care Site associated with a Visit.,No,Yes,CARE_SITE,CARE_SITE_ID,,,
VISIT_OCCURRENCE,visit_source_value,No,varchar(50),"This field houses the verbatim value from the source data representing the kind of visit that took place (inpatient, outpatient, emergency, etc.)","If there is information about the kind of visit in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the visit source value, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created.",No,No,,,,,
VISIT_OCCURRENCE,visit_source_concept_id,No,integer,,If the visit source value is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,,,
VISIT_OCCURRENCE,admitting_source_concept_id,No,integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
VISIT_OCCURRENCE,admitting_source_value,No,varchar(50),,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.",No,No,,,,,
VISIT_OCCURRENCE,discharge_to_concept_id,No,integer,"Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.","If available, map the discharge_to_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
VISIT_OCCURRENCE,discharge_to_source_value,No,varchar(50),,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.",No,No,,,,,
VISIT_OCCURRENCE,admitted_from_concept_id,No,integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
VISIT_OCCURRENCE,admitted_from_source_value,No,varchar(50),,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.",No,No,,,,,
VISIT_OCCURRENCE,discharged_to_concept_id,No,integer,"Use this field to determine where the patient was discharged to after a visit. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.","If available, map the discharge_to_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
VISIT_OCCURRENCE,discharged_to_source_value,No,varchar(50),,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.",No,No,,,,,
VISIT_OCCURRENCE,preceding_visit_occurrence_id,No,integer,Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between.,"This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a ""following_visit_id"".",No,Yes,VISIT_OCCURRENCE,VISIT_OCCURRENCE_ID,,,
VISIT_DETAIL,visit_detail_id,Yes,integer,Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail.,This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time.,Yes,No,,,,,
VISIT_DETAIL,person_id,Yes,integer,,,No,Yes,PERSON,PERSON_ID,,,
@ -63,12 +63,12 @@ VISIT_DETAIL,provider_id,No,integer,"There will only be one provider per **visi
VISIT_DETAIL,care_site_id,No,integer,This field provides information about the Care Site where the Visit Detail took place.,There should only be one Care Site associated with a Visit Detail.,No,Yes,CARE_SITE,CARE_SITE_ID,,,
VISIT_DETAIL,visit_detail_source_value,No,varchar(50),"This field houses the verbatim value from the source data representing the kind of visit detail that took place (inpatient, outpatient, emergency, etc.)","If there is information about the kind of visit detail in the source data that value should be stored here. If a visit is an amalgamation of visits from the source then use a hierarchy to choose the VISIT_DETAIL_SOURCE_VALUE, such as IP -> ER-> OP. This should line up with the logic chosen to determine how visits are created.",No,No,,,,,
VISIT_DETAIL,visit_detail_source_concept_id,No,Integer,,If the VISIT_DETAIL_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,,,
VISIT_DETAIL,admitting_source_value,No,Varchar(50),,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.",No,No,,,,,
VISIT_DETAIL,admitting_source_concept_id,No,Integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
VISIT_DETAIL,discharge_to_source_value,No,Varchar(50),,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.",No,No,,,,,
VISIT_DETAIL,discharge_to_concept_id,No,integer,"Use this field to determine where the patient was discharged to after a visit detail record. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.","If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
VISIT_DETAIL,admitted_from_concept_id,No,Integer,"Use this field to determine where the patient was admitted from. This concept is part of the visit domain and can indicate if a patient was admitted to the hospital from a long-term care facility, for example.","If available, map the admitted_from_source_value to a standard concept in the visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
VISIT_DETAIL,admitted_from_source_value,No,Varchar(50),,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was admitted from. Typically this applies only to visits that have a length of stay, like inpatient visits or long-term care visits.",No,No,,,,,
VISIT_DETAIL,discharged_to_source_value,No,Varchar(50),,"This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more.",No,No,,,,,
VISIT_DETAIL,discharged_to_concept_id,No,integer,"Use this field to determine where the patient was discharged to after a visit detail record. This concept is part of the visit domain and can indicate if a patient was discharged to home or sent to a long-term care facility, for example.","If available, map the DISCHARGE_TO_SOURCE_VALUE to a Standard Concept in the Visit domain. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=).",No,Yes,CONCEPT,CONCEPT_ID,Visit,,
VISIT_DETAIL,preceding_visit_detail_id,No,integer,Use this field to find the visit detail that occurred for the person prior to the given visit detail record. There could be a few days or a few years in between.,"The PRECEDING_VISIT_DETAIL_ID can be used to link a visit immediately preceding the current Visit Detail. Note this is not symmetrical, and there is no such thing as a ""following_visit_id"".",No,Yes,VISIT_DETAIL,VISIT_DETAIL_ID,,,
VISIT_DETAIL,visit_detail_parent_id,No,integer,Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.,"If there are multiple nested levels to how Visits are represented in the source, the VISIT_DETAIL_PARENT_ID can be used to record this relationship. ",No,Yes,VISIT_DETAIL,VISIT_DETAIL_ID,,,
VISIT_DETAIL,parent_visit_detail_id,No,integer,Use this field to find the visit detail that subsumes the given visit detail record. This is used in the case that a visit detail record needs to be nested beyond the VISIT_OCCURRENCE/VISIT_DETAIL relationship.,"If there are multiple nested levels to how Visits are represented in the source, the VISIT_DETAIL_PARENT_ID can be used to record this relationship. ",No,Yes,VISIT_DETAIL,VISIT_DETAIL_ID,,,
VISIT_DETAIL,visit_occurrence_id,Yes,integer,Use this field to link the VISIT_DETAIL record to its VISIT_OCCURRENCE.,Put the VISIT_OCCURRENCE_ID that subsumes the VISIT_DETAIL record here.,No,Yes,VISIT_OCCURRENCE,VISIT_OCCURRENCE_ID,,,
CONDITION_OCCURRENCE,condition_occurrence_id,Yes,integer,The unique key given to a condition record for a person. Refer to the ETL for how duplicate conditions during the same visit were handled.,"Each instance of a condition present in the source data should be assigned this unique key. In some cases, a person can have multiple records of the same condition within the same visit. It is valid to keep these duplicates and assign them individual, unique, CONDITION_OCCURRENCE_IDs, though it is up to the ETL how they should be handled.",Yes,No,,,,,
CONDITION_OCCURRENCE,person_id,Yes,integer,The PERSON_ID of the PERSON for whom the condition is recorded.,,No,Yes,PERSON,PERSON_ID,,,
@ -185,6 +185,7 @@ OBSERVATION,observation_source_value,No,varchar(50),"This field houses the verba
OBSERVATION,observation_source_concept_id,No,integer,"This is the concept representing the OBSERVATION_SOURCE_VALUE and may not necessarily be standard. This field is discouraged from use in analysis because it is not required to contain Standard Concepts that are used across the OHDSI community, and should only be used when Standard Concepts do not adequately represent the source detail for the Observation necessary for a given analytic use case. Consider using OBSERVATION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network.",If the OBSERVATION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here.,No,Yes,CONCEPT,CONCEPT_ID,,,
OBSERVATION,unit_source_value,No,varchar(50),This field houses the verbatim value from the source data representing the unit of the Observation that occurred. ,This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.,No,No,,,,,
OBSERVATION,qualifier_source_value,No,varchar(50),This field houses the verbatim value from the source data representing the qualifier of the Observation that occurred. ,This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.,No,No,,,,,
OBSERVATION,value_source_value,No,varchar(50),This field houses the verbatim result value of the Observation from the source data. Do not get confused with the Observation_source_value which captures source value of the observation mapped to observation_concept_id. This field is the observation result value from the source.,"If the observation_source_value was a question, for example, or an observation that requires a result then this field is the answer/ result from the source data. Store the verbatim value that represents the result of the observation_source_value.",No,No,,,,,
DEATH,person_id,Yes,integer,,,No,Yes,PERSON,PERSON_ID,,,
DEATH,death_date,Yes,date,The date the person was deceased.,"If the precise date include day or month is not known or not allowed, December is used as the default month, and the last day of the month the default day.",No,No,,,,,
DEATH,death_datetime,No,datetime,,If not available set time to midnight (00:00:00),No,No,,,,,
@ -513,15 +514,14 @@ recorded. The default value is
1-Jan-1970.",,No,No,,,,,
DRUG_STRENGTH,valid_end_date,Yes,date,The date when then Concept became invalid.,,No,No,,,,,
DRUG_STRENGTH,invalid_reason,No,varchar(1),"Reason the concept was invalidated. Possible values are D (deleted), U (replaced with an update) or NULL when valid_end_date has the default value.",,No,No,,,,,
COHORT_DEFINITION,cohort_definition_id,Yes,integer,"This is the identifier given to the cohort, usually by the ATLAS application",,No,No,,,,,
COHORT,cohort_definition_id,Yes,integer,,,No,No,,,,,
COHORT,subject_id,Yes,integer,,,No,No,,,,,
COHORT,cohort_start_date,Yes,date,,,No,No,,,,,
COHORT,cohort_end_date,Yes,date,,,No,No,,,,,
COHORT_DEFINITION,cohort_definition_id,Yes,integer,"This is the identifier given to the cohort, usually by the ATLAS application",,No,No,COHORT,COHORT_DEFINITION_ID,,,
COHORT_DEFINITION,cohort_definition_name,Yes,varchar(255),A short description of the cohort,,No,No,,,,,
COHORT_DEFINITION,cohort_definition_description,No,varchar(MAX),A complete description of the cohort.,,No,No,,,,,
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.,,No,Yes,CONCEPT,CONCEPT_ID,,,
COHORT_DEFINITION,cohort_definition_syntax,No,varchar(MAX),Syntax or code to operationalize the Cohort Definition.,,No,No,,,,,
COHORT_DEFINITION,subject_concept_id,Yes,integer,"This field contains a Concept that represents the domain of the subjects that are members of the cohort (e.g., Person, Provider, Visit).",,No,Yes,CONCEPT,CONCEPT_ID,,,
COHORT_DEFINITION,cohort_initiation_date,No,date,A date to indicate when the Cohort was initiated in the COHORT table.,,No,No,,,,,
ATTRIBUTE_DEFINITION,attribute_definition_id,Yes,integer,,,No,No,,,,,
ATTRIBUTE_DEFINITION,attribute_name,Yes,varchar(255),,,No,No,,,,,
ATTRIBUTE_DEFINITION,attribute_description,No,varchar(MAX),,,No,No,,,,,
ATTRIBUTE_DEFINITION,attribute_type_concept_id,Yes,integer,,,No,Yes,CONCEPT,CONCEPT_ID,,,
ATTRIBUTE_DEFINITION,attribute_syntax,No,varchar(MAX),,,No,No,,,,,
1 cdmTableName cdmFieldName isRequired cdmDatatype userGuidance etlConventions isPrimaryKey isForeignKey fkTableName fkFieldName fkDomain fkClass unique DQ identifiers
40 VISIT_OCCURRENCE discharge_to_source_value discharged_to_source_value No varchar(50) This information may be called something different in the source data but the field is meant to contain a value indicating where a person was discharged to after a visit, as in they went home or were moved to long-term care. Typically this applies only to visits that have a length of stay of a day or more. No No
41 VISIT_OCCURRENCE preceding_visit_occurrence_id No integer Use this field to find the visit that occurred for the person prior to the given visit. There could be a few days or a few years in between. This field can be used to link a visit immediately preceding the current visit. Note this is not symmetrical, and there is no such thing as a "following_visit_id". No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID
42 VISIT_DETAIL visit_detail_id Yes integer Use this to identify unique interactions between a person and the health care system. This identifier links across the other CDM event tables to associate events with a visit detail. This should be populated by creating a unique identifier for each unique interaction between a person and the healthcare system where the person receives a medical good or service over a span of time. Yes No
43 VISIT_DETAIL person_id Yes integer No Yes PERSON PERSON_ID
44 VISIT_DETAIL visit_detail_concept_id Yes integer This field contains a concept id representing the kind of visit detail, like inpatient or outpatient. All concepts in this field should be standard and belong to the Visit domain. Populate this field based on the kind of visit that took place for the person. For example this could be "Inpatient Visit", "Outpatient Visit", "Ambulatory Visit", etc. This table will contain standard concepts in the Visit domain. These concepts are arranged in a hierarchical structure to facilitate cohort definitions by rolling up to generally familiar Visits adopted in most healthcare systems worldwide. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Visit&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Visit
45 VISIT_DETAIL visit_detail_start_date Yes date This is the date of the start of the encounter. This may or may not be equal to the date of the Visit the Visit Detail is associated with. When populating VISIT_DETAIL_START_DATE, you should think about the patient experience to make decisions on how to define visits. Most likely this should be the date of the patient-provider interaction. No No
46 VISIT_DETAIL visit_detail_start_datetime No datetime If no time is given for the start date of a visit, set it to midnight (00:00:0000). No No
47 VISIT_DETAIL visit_detail_end_date Yes date This the end date of the patient-provider interaction. Visit Detail end dates are mandatory. If end dates are not provided in the source there are three ways in which to derive them:<br> - Outpatient Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Emergency Room Visit Detail: visit_detail_end_datetime = visit_detail_start_datetime - Inpatient Visit Detail: Usually there is information about discharge. If not, you should be able to derive the end date from the sudden decline of activity or from the absence of inpatient procedures/drugs. - Non-hospital institution Visit Details: Particularly for claims data, if end dates are not provided assume the visit is for the duration of month that it occurs.<br> For Inpatient Visit Details ongoing at the date of ETL, put date of processing the data into visit_detai_end_datetime and visit_detail_type_concept_id with 32220 "Still patient" to identify the visit as incomplete. All other Visits Details: visit_detail_end_datetime = visit_detail_start_datetime. No No
48 VISIT_DETAIL visit_detail_end_datetime No datetime If no time is given for the end date of a visit, set it to midnight (00:00:0000). No No
49 VISIT_DETAIL visit_detail_type_concept_id Yes integer Use this field to understand the provenance of the visit detail record, or where the record comes from. Populate this field based on the provenance of the visit detail record, as in whether it came from an EHR record or billing claim. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Type Concept
63 CONDITION_OCCURRENCE condition_concept_id Yes integer The CONDITION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies. This is the standard concept mapped from the source value which represents a condition The CONCEPT_ID that the CONDITION_SOURCE_VALUE maps to. Only records whose source values map to concepts with a domain of "Condition" should go in this table. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Condition&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Condition
64 CONDITION_OCCURRENCE condition_start_date Yes date Use this date to determine the start date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. No No
65 CONDITION_OCCURRENCE condition_start_datetime No datetime If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No
66 CONDITION_OCCURRENCE condition_end_date No date Use this date to determine the end date of the condition Most often data sources do not have the idea of a start date for a condition. Rather, if a source only has one date associated with a condition record it is acceptable to use that date for both the CONDITION_START_DATE and the CONDITION_END_DATE. No No
67 CONDITION_OCCURRENCE condition_end_datetime No datetime If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) No No
68 CONDITION_OCCURRENCE condition_type_concept_id Yes integer This field can be used to determine the provenance of the Condition record, as in whether the condition was from an EHR system, insurance claim, registry, or other sources. Choose the CONDITION_TYPE_CONCEPT_ID that best represents the provenance of the record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Type+Concept&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Type Concept
69 CONDITION_OCCURRENCE condition_status_concept_id No integer This concept represents the point during the visit the diagnosis was given (admitting diagnosis, final diagnosis), whether the diagnosis was determined due to laboratory findings, if the diagnosis was exclusionary, or if it was a preliminary diagnosis, among others. Choose the Concept in the Condition Status domain that best represents the point during the visit when the diagnosis was given. These can include admitting diagnosis, principal diagnosis, and secondary diagnosis. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?domain=Condition+Status&standardConcept=Standard&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Condition Status
70 CONDITION_OCCURRENCE stop_reason No varchar(20) The Stop Reason indicates why a Condition is no longer valid with respect to the purpose within the source data. Note that a Stop Reason does not necessarily imply that the condition is no longer occurring. This information is often not populated in source data and it is a valid etl choice to leave it blank if the information does not exist. No No
71 CONDITION_OCCURRENCE provider_id No integer The provider associated with condition record, e.g. the provider who made the diagnosis or the provider who recorded the symptom. The ETL may need to make a choice as to which PROVIDER_ID to put here. Based on what is available this may or may not be different than the provider associated with the overall VISIT_OCCURRENCE record, for example the admitting vs attending physician on an EHR record. No Yes PROVIDER PROVIDER_ID
72 CONDITION_OCCURRENCE visit_occurrence_id No integer The visit during which the condition occurred. Depending on the structure of the source data, this may have to be determined based on dates. If a CONDITION_START_DATE occurs within the start and end date of a Visit it is a valid ETL choice to choose the VISIT_OCCURRENCE_ID from the Visit that subsumes it, even if not explicitly stated in the data. While not required, an attempt should be made to locate the VISIT_OCCURRENCE_ID of the CONDITION_OCCURRENCE record. No Yes VISIT_OCCURRENCE VISIT_OCCURRENCE_ID
73 CONDITION_OCCURRENCE visit_detail_id No integer The VISIT_DETAIL record during which the condition occurred. For example, if the person was in the ICU at the time of the diagnosis the VISIT_OCCURRENCE record would reflect the overall hospital stay and the VISIT_DETAIL record would reflect the ICU stay during the hospital visit. Same rules apply as for the VISIT_OCCURRENCE_ID. No Yes VISIT_DETAIL VISIT_DETAIL_ID
74 CONDITION_OCCURRENCE condition_source_value No varchar(50) This field houses the verbatim value from the source data representing the condition that occurred. For example, this could be an ICD10 or Read code. This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference. No No
185 NOTE note_type_concept_id note_datetime Yes No integer datetime The provenance of the note. Most likely this will be EHR. Put the source system of the note, as in EHR record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=). If time is not given set the time to midnight. No Yes No CONCEPT CONCEPT_ID Type Concept
186 NOTE note_class_concept_id note_type_concept_id Yes integer A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note. The provenance of the note. Most likely this will be EHR. Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&conceptClass=Doc+Kind&conceptClass=Doc+Role&conceptClass=Doc+Setting&conceptClass=Doc+Subject+Matter&conceptClass=Doc+Type+of+Service&domain=Meas+Value&page=1&pageSize=15&query=). This Concept can alternatively be represented by concepts with the relationship 'Kind of (LOINC)' to [706391](https://athena.ohdsi.org/search-terms/terms/706391) (Note). Put the source system of the note, as in EHR record. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&domain=Type+Concept&page=1&pageSize=15&query=). No Yes CONCEPT CONCEPT_ID Type Concept
187 NOTE note_title note_class_concept_id No Yes varchar(250) integer The title of the note. A Standard Concept Id representing the HL7 LOINC Document Type Vocabulary classification of the note. Map the note classification to a Standard Concept. For more information see the ETL Conventions in the description of the NOTE table. [Accepted Concepts](https://athena.ohdsi.org/search-terms/terms?standardConcept=Standard&conceptClass=Doc+Kind&conceptClass=Doc+Role&conceptClass=Doc+Setting&conceptClass=Doc+Subject+Matter&conceptClass=Doc+Type+of+Service&domain=Meas+Value&page=1&pageSize=15&query=). This Concept can alternatively be represented by concepts with the relationship 'Kind of (LOINC)' to [706391](https://athena.ohdsi.org/search-terms/terms/706391) (Note). No No Yes CONCEPT CONCEPT_ID
188 NOTE note_title No varchar(250) The title of the note. No No
189 NOTE note_text Yes varchar(MAX) The content of the note. No No
190 NOTE encoding_concept_id Yes integer This is the Concept representing the character encoding type. Put the Concept Id that represents the encoding character type here. Currently the only option is UTF-8 ([32678](https://athena.ohdsi.org/search-terms/terms/32678)). It the note is encoded in any other type, like ASCII then put 0. No Yes CONCEPT CONCEPT_ID
191 NOTE language_concept_id Yes integer The language of the note. Use Concepts that are descendants of the concept [4182347](https://athena.ohdsi.org/search-terms/terms/4182347) (World Languages). No Yes CONCEPT CONCEPT_ID
514
515
516
517
518
519
520
521
522
523
524
525
526
527

12
inst/csv/OMOP_CDMv5.4_Table_Level.csv
View File

@ -57,6 +57,8 @@ For example, consider a Person who visits her Primary Care Physician (PCP) and w
The condition_concept_id field contains Concepts that are identical to those of the CONDITION_OCCURRENCE table records that make up the Condition Era. In contrast to Drug Eras, Condition Eras are not aggregated to contain Conditions of different hierarchical layers. The SQl Script for generating CONDITION_ERA records can be found [here](https://ohdsi.github.io/CommonDataModel/sqlScripts.html#condition_eras)
The Condition Era Start Date is the start date of the first Condition Occurrence.
The Condition Era End Date is the end date of the last Condition Occurrence. Condition Eras are built with a Persistence Window of 30 days, meaning, if no occurrence of the same condition_concept_id happens within 30 days of any one occurrence, it will be considered the condition_era_end_date."
EPISODE,CDM,No,,No,,,"The EPISODE table aggregates lower-level clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) into a higher-level abstraction representing clinically and analytically relevant disease phases,outcomes and treatments. The EPISODE_EVENT table connects qualifying clinical events (VISIT_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, DEVICE_EXPOSURE) to the appropriate EPISODE entry. For example cancers including their development over time, their treatment, and final resolution. ","Valid Episode Concepts belong to the 'Episode' domain. For cancer episodes please see [article], for non-cancer episodes please see [article]. If your source data does not have all episodes that are relevant to the therapeutic area, write only those you can easily derive from the data. It is understood that that table is not currently expected to be comprehensive. ",
EPISODE_EVENT,CDM,No,,No,,,"The EPISODE_EVENT table connects qualifying clinical events (such as CONDITION_OCCURRENCE, DRUG_EXPOSURE, PROCEDURE_OCCURRENCE, MEASUREMENT) to the appropriate EPISODE entry. For example, linking the precise location of the metastasis (cancer modifier in MEASUREMENT) to the disease episode. ",This connecting table is used instead of the FACT_RELATIONSHIP table for linking low-level events to abstracted Episodes.,"Some episodes may not have links to any underlying clinical events. For such episodes, the EPISODE_EVENT table is not populated."
METADATA,CDM,No,,No,,,The METADATA table contains metadata information about a dataset that has been transformed to the OMOP Common Data Model.,,
CDM_SOURCE,CDM,No,,No,,,The CDM_SOURCE table contains detail about the source database and the process used to transform the data into the OMOP Common Data Model.,,
CONCEPT,VOCAB,No,,No,,,"The Standardized Vocabularies contains records, or Concepts, that uniquely identify each fundamental unit of meaning used to express clinical information in all domain tables of the CDM. Concepts are derived from vocabularies, which represent clinical information across a domain (e.g. conditions, drugs, procedures) through the use of codes and associated descriptions. Some Concepts are designated Standard Concepts, meaning these Concepts can be used as normative expressions of a clinical entity within the OMOP Common Data Model and within standardized analytics. Each Standard Concept belongs to one domain, which defines the location where the Concept would be expected to occur within data tables of the CDM.
@ -75,11 +77,5 @@ CONCEPT_ANCESTOR,VOCAB,No,,No,,,"The CONCEPT_ANCESTOR table is designed to simpl
This table is entirely derived from the CONCEPT, CONCEPT_RELATIONSHIP and RELATIONSHIP tables.",,
SOURCE_TO_CONCEPT_MAP,VOCAB,No,,No,,,"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.",,
DRUG_STRENGTH,VOCAB,No,,No,,,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.,,
COHORT_DEFINITION,VOCAB,No,,No,,,"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.",,
ATTRIBUTE_DEFINITION,VOCAB,No,,No,,,"The ATTRIBUTE_DEFINITION table contains records to define each attribute
through an associated description and syntax. Attributes are derived elements
that can be selected or calculated for a subject within 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.",,
COHORT,RESULTS,No,,No,,,The COHORT table contains records of subjects that satisfy a given set of criteria for a duration of time. The definition of the cohort is contained within the COHORT_DEFINITION table. It is listed as part of the RESULTS schema because it is a table that users of the database as well as tools such as ATLAS need to be able to write to. The CDM and Vocabulary tables are all read-only so it is suggested that the COHORT and COHORT_DEFINTION tables are kept in a separate schema to alleviate confusion.,,"Cohorts typically include patients diagnosed with a specific condition, patients exposed to a particular drug, but can also be Providers who have performed a specific Procedure. Cohort records must have a Start Date and an End Date, but the End Date may be set to Start Date or could have an applied censor date using the Observation Period Start Date. Cohort records must contain a Subject Id, which can refer to the Person, Provider, Visit record or Care Site though they are most often Person Ids. The Cohort Definition will define the type of subject through the subject concept id. A subject can belong (or not belong) to a cohort at any moment in time. A subject can only have one record in the cohort table for any moment of time, i.e. it is not possible for a person to contain multiple records indicating cohort membership that are overlapping in time"
COHORT_DEFINITION,RESULTS,No,,No,,,"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.",,
1 cdmTableName schema isRequired conceptPrefix measurePersonCompleteness measurePersonCompletenessThreshold validation tableDescription userGuidance etlConventions
57
58
59
60
61
62
63
64
77
78
79
80
81