<table><thead><tr><td>CDASH Var.</td><td>CDASH Variable Label</td><td>DRAFT CDASH Definition</td></tr></thead><tbody><tr><td>--EVAL</td><td>Evaluator</td><td>The role of the person who provided the evaluation.</td></tr><tr><td>--EVALID</td><td>Evaluator Identifier</td><td>An identifier used to distinguish multiple evaluators with the same role recorded in --EVAL.</td></tr><tr><td>--ACPTFL</td><td>Accepted Record Flag</td><td>An indication that the evaluation is considered, by an independent assessor, to be the accepted or final evaluation.</td></tr><tr><td>--TOX</td><td>Toxicity</td><td>The description of toxicity quantified by --TOXGR such as NCI CTCAE Short Name.</td></tr><tr><td>--TOXGR</td><td>Toxicity Grade</td><td>The toxicity grade using a standard toxicity scale (such as the NCI CTCAE).</td></tr><tr><td>--SEV</td><td>Severity</td><td>The severity or intensity of a particular finding.</td></tr><tr><td>--DTHREL</td><td>Relationship to Death</td><td>An indication of the relationship of a particular finding to the death of a subject.</td></tr><tr><td>--CLLOQ</td><td>Collected Lower Limit of Quantitation</td><td>The collected lower limit of quantitation for an assay, represented in text format or as a range, such as less than a specified numeric value.</td></tr><tr><td>--CULOQ</td><td>Collected Upper Limit of Quantitation</td><td>The collected upper limit of quantitation for an assay, represented in text format or as a range, such as greater than a specified numeric value.</td></tr><tr><td>--COND</td><td>Test Condition Met</td><td>An indication whether the testing conditions defined in the protocol were met (e.g., Low fat diet).</td></tr><tr><td>--CLSIG</td><td>Clinical Significance</td><td>An indication whether the test results were clinically significant.</td></tr><tr><td>--REPNUM</td><td>Repetition Number</td><td>The instance number of a test that is repeated within a given timeframe for the same test. The level of granularity can vary, e.g., within a time point or within a visit.</td></tr><tr><td>--DATFL</td><td>Same as Previous Sample Collection Date</td><td>A flag indicating that the date (or start date) is the same as the previous specimen collection date (or start date).</td></tr><tr><td>--ENDATF</td><td>Same as Current Sample Collection Start Date</td><td>A flag indicating that the specimen/sample collection ended on the same date as the current/previous specimen collection started.</td></tr><tr><td>COVAL</td><td>Comment</td><td>A free text comment.</td></tr><tr><td>--MODIFY</td><td>Modified Term</td><td>If the value for --ORRES is modified for coding purposes, then the modified text is placed here.</td></tr><tr><td>--BODSYS</td><td>Body System or Organ Class</td><td>Body System or Organ Class that is involved for a finding from the standard hierarchy for dictionary-coded results.</td></tr></tbody></table>

<figure><img src="image_71.png" /></figure>

This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 824087.
Appendix 3. Observation Table Field definitions – OMOP CDM 6.0

<table><thead><tr><td>CDM Field</td><td>User Guide</td><td>ETL Conventions</td><td>Type</td><td>Key</td></tr></thead><tbody><tr><td>observation_id (required)</td><td>The unique key given to an Observation record for a Person. Refer to the ETL for how duplicate Observations during the same Visit were handled.</td><td>Each instance of an observation present in the source data should be assigned this unique key.</td><td>bigint</td><td>PK</td></tr><tr><td>person_id (required)</td><td>The PERSON_ID of the Person for whom the Observation is recorded. This may be a system generated code.</td><td></td><td>bigint</td><td>FK</td></tr><tr><td>observation_concept_id (required)</td><td>The OBSERVATION_CONCEPT_ID field is recommended for primary use in analyses, and must be used for network studies.</td><td>The CONCEPT_ID that the OBSERVATION_SOURCE_CONCEPT_ID maps to. There is no specified domain that the Concepts in this table must adhere to. The only rule is that records with Concepts in the Condition, Procedure, Drug, Measurement, or Device domains MUST go to the corresponding table.</td><td>int</td><td>FK</td></tr><tr><td>observation_date</td><td>The date of the Observation. Depending on what the Observation represents this could be the date of a lab test, the date of a survey, or the date a patient's family history was taken.</td><td>For some observations the ETL may need to make a choice as to which date to choose.</td><td>date</td><td>No</td></tr><tr><td>observation_da tetime (required)</td><td></td><td>If no time is given set to midnight (00:00:00).</td><td>date- time</td><td>No</td></tr><tr><td>observation_type_concept_id (required)</td><td>This field can be used to determine the provenance of the Observation record, as in whether the measurement was from an EHR system, insurance claim, registry, or other sources.</td><td>Choose the OBSERVATION_TYPE_CONCEPT_ID that best represents the provenance of the record, for example whether it came from an EHR record or billing claim. Accepted Concepts.</td><td>int</td><td>FK</td></tr><tr><td>value_as_number</td><td>This is the numerical value of the Result of the Observation, if applicable and available. It is not expected that all Observations will have numeric results, rather, this field is here to house values should they exist.</td><td></td><td>float</td><td>No</td></tr></tbody></table>

<figure><img src="image_72.png" /></figure>

This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 824087.
<table><thead><tr><td>CDM Field</td><td>User Guide</td><td>ETL Conventions</td><td>Type</td><td>Key</td></tr></thead><tbody><tr><td>value_as_string</td><td>This is the categorical value of the Result of the Observation, if applicable and available.</td><td></td><td>var char (60)</td><td>No</td></tr><tr><td>value_as_concept_id</td><td>It is possible that some records destined for the Observation table have two clinical ideas represented in one source code. This is common with ICD10 codes that describe a family history of some Condition, for example. In OMOP the Vocabulary breaks these two clinical ideas into two codes; one becomes the OBSERVATION_CONCEPT_ID and the other becomes the VALUE_AS_CONCEPT_ID. It is important when using the Observation table to keep this possibility in mind and to examine the VALUE_AS_CONCEPT_ID field for relevant information.</td><td>Note that the value of VALUE_AS_CONCEPT_ID may be provided through mapping from a source Concept which contains the content of the Observation. In those situations, the CONCEPT_RELATIONSHIP table in addition to the 'Maps to' record contains a second record with the relationship_id set to 'Maps to value'. For example, ICD10 Z82.4 'Family history of ischaemic heart disease and other diseases of the circulatory system' has a 'Maps to' relationship to 4167217 'Family history of clinical finding' as well as a 'Maps to value' record to 134057 'Disorder of cardiovascular system'.</td><td>Int</td><td>FK</td></tr><tr><td>qualifier_concept_id</td><td>This field contains all attributes specifying the clinical fact further, such as as degrees, severities, drug-drug interaction alerts etc.</td><td>Use your best judgement as to what Concepts to use here and if they are necessary to accurately represent the clinical record. There is no restriction on the domain of these Concepts, they just need to be Standard.</td><td>int</td><td>FK</td></tr><tr><td>unit_concept_id</td><td>There is currently no recommended unit for individual observation concepts. UNIT_SOURCE_VALUES should be mapped to a Standard Concept in the Unit domain that best represents the unit as given in the source data.</td><td>There is no standardization requirement for units associated with OBSERVATION_CONCEPT_IDS, however, it is the responsibility of the ETL to choose the most plausible unit.</td><td>int</td><td>FK</td></tr></tbody></table>

<figure><img src="image_73.png" /></figure>
<table><thead><tr><td>CDM Field</td><td>User Guide</td><td>ETL Conventions</td><td>Type</td><td>Key</td></tr></thead><tbody><tr><td>provider_id</td><td>The provider associated with the observation record, e.g. the provider who ordered the test or the provider who recorded the result.</td><td>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.</td><td>bigint</td><td>FK</td></tr><tr><td>visit_<br>occurrence_id</td><td>The visit during which the Observation occurred.</td><td>Depending on the structure of the source data, this may have to be determined based on dates. If an OBSERVATION_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 observation record. If an observation is related to a visit explicitly in the source data, it is possible that the result date of the Observation falls outside of the bounds of the Visit dates.</td><td>bigint</td><td>FK</td></tr><tr><td>visit_detail_id</td><td>The VISITio DETAIL record during which the Observation occurred. For example, if the Person was in the ICU at the time the VISIT'OCCURRENCE record would reflect the overall hospital stay and the VISITio DETAIL record would reflect the ICU stay during the hospital visit.</td><td>Same rules apply as for the VISIT'OCCURRENCE_ID.</td><td>bigint</td><td>FK</td></tr><tr><td>observation_<br>source_value</td><td>This field houses the verbatim value from the source data representing the Observation that occurred. For example, this could be an ICD10 or Read code.</td><td>This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference.</td><td>var<br>char<br>(50)</td><td>No</td></tr><tr><td>observation_<br>source_<br>concept_id<br>(required)</td><td>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</td><td>If the OBSERVATION_SOURCE_VALUE is coded in the source data using an OMOP supported vocabulary put the concept id representing the source</td><td>int</td><td>FK</td></tr></tbody></table>

<figure><img src="image_74.png" /></figure>
<table><thead><tr><td>CDM Field</td><td>User Guide</td><td>ETL Conventions</td><td>Type</td><td>Key</td></tr></thead><tbody><tr><td></td><td>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.</td><td>value here. If not available, set to 0.</td><td></td><td></td></tr><tr><td>unit_source_value</td><td>This field houses the verbatim value from the source data representing the unit of the Observation that occurred.</td><td>This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.</td><td>var char (50)</td><td>No</td></tr><tr><td>qualifier_source_value</td><td>This field houses the verbatim value from the source data representing the qualifier of the Observation that occurred.</td><td>This code is mapped to a Standard Condition Concept in the Standardized Vocabularies and the original code is stored here for reference.</td><td>var char (50)</td><td>No</td></tr><tr><td>observation_event_id</td><td>If the Observation record is related to another record in the database, this field is the primary key of the linked record.</td><td>Put the primary key of the linked record, if applicable, here. See the ETL Conventions for the OBSERVATION table for more details.</td><td>bigint</td><td>No</td></tr><tr><td>obs_event_field_concept_id</td><td>If the Observation record is related to another record in the database, this field is the CONCEPT_ID that identifies which table the primary key of the linked record came from.</td><td>Put the CONCEPT_ID that identifies which table and field the OBSERVATION_EVENT_ID came from.</td><td>int</td><td>FK</td></tr><tr><td>value_as_data_time</td><td>It is possible that some Observation records might store a result as a date value.</td><td></td><td>date-time</td><td>No</td></tr></tbody></table>

<figure><img src="image_75.png" /></figure>