CONDITION_OCCURRENCE Table

	A	B	C	D	E	F	G	H	I
1	cdmTableName	cdmFieldName	isRequired	cdmDatatype	fkDomain	acceptedConcepts	userGuidance	etlConventions	DQ checks/THEMIS Rules

2	CONDITION_OCCURRENCE	condition_occurrence_id	Yes	bigint			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.
3	CONDITION_OCCURRENCE	person_id	Yes	bigint			The PERSON_ID of the PERSON for whom the condition is recorded. This may be a system generated code.
4	CONDITION_OCCURRENCE	condition_concept_id	Yes	integer	Condition		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 standard concepts with a domain of "Condition" should go in this table.
5	CONDITION_OCCURRENCE	condition_start_date	Yes	date			Use this date to determine the start date of the condition, often this is not the true start date of the condition but the date that the diagnosis was made.	Most often data sources do not have the idea of a start date for a condition. It should be the date that the diagnosis was made or confirmed. If the date the diagnosis was made is unavailable, choose the date the diagnosis was recorded in the source system.
6	CONDITION_OCCURRENCE	condition_start_datetime	No	datetime				This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
7	CONDITION_OCCURRENCE	condition_end_date	No	date			Use this date to determine the end date of the condition	If there is no end date in the source data, leave this blank.
8	CONDITION_OCCURRENCE	condition_end_datetime	No	datetime				This is not required, though it is in v6. If a source does not specify datetime the convention is to set the time to midnight (00:00:0000)
9	CONDITION_OCCURRENCE	condition_type_concept_id	Yes	integer	Type Concept		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, for example whether it came from an EHR record or billing claim.
10	CONDITION_OCCURRENCE	condition_status_concept_id	No	integer	Condition Status		This concept represents the quality of the diagnosis, for example, 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.
11	CONDITION_OCCURRENCE	stop_reason	No	varchar(20)			The stop reason as it is represented in the source. This field will be retired in v6.0.	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.
12	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.
13	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 explictly stated in the data. While not required, an attempt should be made to locate the visit_occurrence_id of the condition_occurrence record.
14	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.
15	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.
16	CONDITION_OCCURRENCE	condition_source_concept_id	No	integer			This is the concept representing the condition 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 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.	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.
17	CONDITION_OCCURRENCE	condition_status_source_value	No	varchar(50)			This field houses the verbatim value from the source data representing the condition status.	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.
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100