Hi everyone,
Today we have a CDM workgroup meeting at 1pm eastern where we will be discussing the CONDITION_OCCURRENCE table. The Skype meeting link can be found on our homepage and the straw-man description of the CONDITION_OCCURRENCE table is below. Please review and come ready to discuss.
Clair
Table Description
This table contains records of Events of a Person suggesting the presence of a disease or medical condition stated as a diagnosis, a sign, or a symptom, which is either observed by a Provider or reported by the patient.
| CDM Field Name | User Guidance | ETL Conventions |
|---|---|---|
| condition_occurrence_id | 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. |
| person_id | The PERSON_ID of the PERSON for whom the condition is recorded. | |
| condition_concept_id | 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. |
| condition_start_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. |
| condition_start_datetime | If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) | |
| condition_end_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. |
| condition_end_datetime | If a source does not specify datetime the convention is to set the time to midnight (00:00:0000) | |
| condition_type_concept_id | 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. |
| condition_status_concept_id | 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. | Presently, there is no designated vocabulary, domain, or class that represents condition status. The concepts with a relationship_id of “subsumes” with CONCEPT_ID 4021918 “Qualifier for type of diagnosis” should be used. These include admitting diagnosis, principal diagnosis, and secondary diagnosis. |
| stop_reason | 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. |
| provider_id | The provider associated with condition record. | 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. |
| visit_occurrence_id | The visit during which the condition was diagnosed. | Depending on the structure of the source data, this may have to be determined based on dates. |
| visit_detail_id | The VISIT_DETAIL record during which the condition was diagnosed. 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. | |
| condition_source_value | 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 Condition necessary for a given analytic use case. Consider using CONDITION_CONCEPT_ID instead to enable standardized analytics that can be consistent across the network. | 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 | If the CONDITION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source value here. | |
| condition_status_source_value | This information may be called something different in the source data but the field is meant to contain a value indicating when and how a diagnosis was given to a patient. This source value is mapped to a standard concept which is stored in the CONDITION_STATUS_CONCEPT_ID field. |