Documentation still in development
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| person_id | A unique identifier for each person. | integer | Yes | Yes | No | ||||
| gender_concept_id | A foreign key that refers to an identifier in the CONCEPT table for the unique gender of the person. | integer | Yes | No | Yes | CONCEPT | Gender | ||
| year_of_birth | The year of birth of the person. For data sources with date of birth, the year is extracted. For data sources where the year of birth is not available, the approximate year of birth is derived based on any age group categorization available. | integer | Yes | No | No | ||||
| month_of_birth | The month of birth of the person. For data sources that provide the precise date of birth, the month is extracted and stored in this field. | integer | No | No | No | ||||
| day_of_birth | The day of the month of birth of the person. For data sources that provide the precise date of birth, the day is extracted and stored in this field. | integer | No | No | No | ||||
| birth_datetime | The date and time of birth of the person. | datetime | No | No | No | ||||
| death_datetime | The date and time of death of the person. | datetime | No | No | No | ||||
| race_concept_id | A foreign key that refers to an identifier in the CONCEPT table for the unique race of the person, belonging to the ‘’Race’’ vocabulary. | integer | Yes | No | Yes | CONCEPT | Race | ||
| ethnicity_concept_id | A foreign key that refers to the standard concept identifier in the Standardized Vocabularies for the ethnicity of the person, belonging to the ‘’Ethnicity’’ vocabulary. | integer | Yes | No | Yes | CONCEPT | Ethnicity | ||
| location_id | A foreign key to the place of residency for the person in the location table, where the detailed address information is stored. | integer | No | No | Yes | LOCATION | |||
| provider_id | A foreign key to the primary care provider the person is seeing in the provider table. | integer | No | No | Yes | PROVIDER | |||
| care_site_id | A foreign key to the site of primary care in the care_site table, where the details of the care site are stored. | integer | No | No | Yes | CARE_SITE | |||
| person_source_value | An (encrypted) key derived from the person identifier in the source data. This is necessary when a use case requires a link back to the person data at the source dataset. | varchar(50) | No | No | No | ||||
| gender_source_value | The source code for the gender of the person as it appears in the source data. The person’s gender is mapped to a standard gender concept in the Standardized Vocabularies; the original value is stored here for reference. | varchar(50) | No | No | No | ||||
| gender_source_concept_id | A foreign key to the gender concept that refers to the code used in the source. | Integer | Yes | No | Yes | CONCEPT | |||
| race_source_value | The source code for the race of the person as it appears in the source data. The person race is mapped to a standard race concept in the Standardized Vocabularies and the original value is stored here for reference. | varchar(50) | No | No | No | ||||
| race_source_concept_id | A foreign key to the race concept that refers to the code used in the source. | Integer | Yes | No | Yes | CONCEPT | |||
| ethnicity_source_value | The source code for the ethnicity of the person as it appears in the source data. The person ethnicity is mapped to a standard ethnicity concept in the Standardized Vocabularies and the original code is, stored here for reference. | varchar(50) | No | No | No | ||||
| ethnicity_source_concept_id | A foreign key to the ethnicity concept that refers to the code used in the source. | Integer | Yes | No | Yes | CONCEPT |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| observation_period_id | A unique identifier for each observation period. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the person for whom the observation period is defined. The demographic details of that person are stored in the person table. | integer | Yes | No | Yes | PERSON | |||
| observation_period_start_date | The start date of the observation period for which data are available from the data source. | date | Yes | No | No | ||||
| observation_period_end_date | The end date of the observation period for which data are available from the data source. | date | Yes | No | No | ||||
| period_type_concept_id | A foreign key identifier to the predefined concept in the Standardized Vocabularies reflecting the source of the observation period information, belonging to the ‘’Obs Period Type’’ vocabulary | Integer | Yes | No | Yes | CONCEPT | Type Concept |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| visit_occurrence_id | A unique identifier for each Person’’s visit or encounter at a healthcare provider. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person for whom the visit is recorded. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| visit_concept_id | A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies belonging to the ‘’Visit’’ Vocabulary. | integer | Yes | No | Yes | CONCEPT | Visit | ||
| visit_start_date | The start date of the visit. | date | No | No | No | ||||
| visit_start_datetime | The date and time of the visit started. | datetime | Yes | No | No | ||||
| visit_end_date | The end date of the visit. If this is a one-day visit the end date should match the start date. | date | No | No | No | ||||
| visit_end_datetime | The date and time of the visit end. | datetime | Yes | No | No | ||||
| visit_type_concept_id | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived belonging to the ‘’Visit Type’’ vocabulary. | Integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| provider_id | A foreign key to the provider in the provider table who was associated with the visit. | integer | No | No | No | PROVIDER | |||
| care_site_id | A foreign key to the care site in the care site table that was visited. | integer | No | No | No | CARE_SITE | |||
| visit_source_value | The source code for the visit as it appears in the source data. | varchar(50) | No | No | No | ||||
| visit_source_concept_id | A foreign key to a Concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| admitted_from_concept_id | A foreign key to the predefined concept in the Place of Service Vocabulary reflecting where the patient was admitted from. | integer | Yes | No | Yes | CONCEPT | |||
| admitted_from_source_value | The source code for where the patient was admitted from as it appears in the source data. | varchar(50) | No | No | No | ||||
| discharge_to_concept_id | A foreign key to the predefined concept in the Place of Service Vocabulary reflecting the discharge disposition for a visit. | integer | Yes | No | Yes | CONCEPT | |||
| discharge_to_source_value | The source code for the discharge disposition as it appears in the source data. | varchar(50) | No | No | No | ||||
| preceding_visit_occurrence_id | A foreign key to the VISIT_OCCURRENCE table of the visit immediately preceding this visit | integer | No | No | Yes | VISIT_OCCURRENCE |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| condition_occurrence_id | A unique identifier for each Condition Occurrence event. | bigint | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person who is experiencing the condition. The demographic details of that Person are stored in the PERSON table. | bigint | Yes | No | Yes | PERSON | |||
| condition_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies belonging to the ‘’Condition’’ domain. | integer | Yes | No | Yes | CONCEPT | Condition | ||
| condition_start_date | The date when the instance of the Condition is recorded. | date | No | No | No | ||||
| condition_start_datetime | The date and time when the instance of the Condition is recorded. | datetime | Yes | No | No | ||||
| condition_end_date | The date when the instance of the Condition is considered to have ended. | date | No | No | No | ||||
| condition_end_datetime | The date when the instance of the Condition is considered to have ended. | datetime | No | No | No | ||||
| condition_type_concept_id | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the source data from which the Condition was recorded, the level of standardization, and the type of occurrence. These belong to the ‘’Condition Type’’ vocabulary | integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| condition_status_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies reflecting the point of care at which the Condition was diagnosed. | integer | Yes | No | Yes | CONCEPT | |||
| stop_reason | The reason that the Condition was no longer present, as indicated in the source data. | varchar(20) | No | No | No | ||||
| provider_id | A foreign key to the Provider in the PROVIDER table who was responsible for capturing (diagnosing) the Condition. | integer | No | No | Yes | PROVIDER | |||
| visit_occurrence_id | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Condition was determined (diagnosed). | integer | No | No | Yes | VISIT_OCCURRENCE | |||
| visit_detail_id | A foreign key to the visit in the VISIT_DETAIL table during which the Condition was determined (diagnosed). | integer | No | No | Yes | VISIT_DETAIL | |||
| condition_source_value | 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. | varchar(50) | No | No | No | ||||
| condition_source_concept_id | A foreign key to a Condition Concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| condition_status_source_value | The source code for the condition status as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference. | varchar(50) | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| drug_exposure_id | A system-generated unique identifier for each Drug utilization event. | bigint | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person who is subjected to the Drug. The demographic details of that Person are stored in the PERSON table. | bigint | Yes | No | Yes | PERSON | |||
| drug_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies belonging to the ‘’Drug’’ domain. | integer | Yes | No | Yes | CONCEPT | Drug | ||
| drug_exposure_start_date | The start date for the current instance of Drug utilization. Valid entries include a start date of a prescription, the date a prescription was filled, or the date on which a Drug administration procedure was recorded. | date | No | No | No | ||||
| drug_exposure_start_datetime | The start date and time for the current instance of Drug utilization. Valid entries include a start datetime of a prescription, the date and time a prescription was filled, or the date and time on which a Drug administration procedure was recorded. | datetime | Yes | No | No | ||||
| drug_exposure_end_date | The end date for the current instance of Drug utilization. Depending on different sources, it could be a known or an inferred date and denotes the last day at which the patient was still exposed to Drug. | date | Yes | No | No | ||||
| drug_exposure_end_datetime | The end date and time for the current instance of Drug utilization. Depending on different sources, it could be a known or an inferred date and time and denotes the last day at which the patient was still exposed to Drug. | datetime | Yes | No | No | ||||
| verbatim_end_date | The known end date of a drug_exposure as provided by the source. | date | No | No | No | ||||
| drug_type_concept_id | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Drug Exposure recorded. It indicates how the Drug Exposure was represented in the source data and belongs to the ‘’Drug Type’’ vocabulary. | integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| stop_reason | The reason the Drug was stopped. Reasons include regimen completed, changed, removed, etc. | varchar(20) | No | No | No | ||||
| refills | The number of refills after the initial prescription. The initial prescription is not counted, values start with null. | integer | No | No | No | ||||
| quantity | The quantity of drug as recorded in the original prescription or dispensing record. | float | No | No | No | ||||
| days_supply | The number of days of supply of the medication as prescribed. This reflects the intention of the provider for the length of exposure. | integer | No | No | No | ||||
| sig | The directions (‘’signetur’’) on the Drug prescription as recorded in the original prescription (and printed on the container) or dispensing record. | varchar(MAX) | No | No | No | ||||
| route_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies reflecting the route of administration and belonging to the ‘’Route’’ domain. | integer | Yes | No | Yes | CONCEPT | |||
| lot_number | An identifier assigned to a particular quantity or lot of Drug product from the manufacturer. | varchar(50) | No | No | No | ||||
| provider_id | A foreign key to the provider in the PROVIDER table who initiated (prescribed or administered) the Drug Exposure. | integer | No | No | Yes | PROVIDER | |||
| visit_occurrence_id | A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Drug Exposure was initiated. | integer | No | No | Yes | VISIT_OCCURRENCE | |||
| visit_detail_id | A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Drug Exposure was initiated. | integer | No | No | Yes | VISIT_DETAIL | |||
| drug_source_value | The source code for the Drug as it appears in the source data. This code is mapped to a Standard Drug concept in the Standardized Vocabularies and the original code is, stored here for reference. | varchar(50) | No | No | No | ||||
| drug_source_concept_id | A foreign key to a Drug Concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| route_source_value | The information about the route of administration as detailed in the source. | varchar(50) | No | No | No | ||||
| dose_unit_source_value | The information about the dose unit as detailed in the source. | varchar(50) | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| procedure_occurrence_id | A system-generated unique identifier for each Procedure Occurrence. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person who is subjected to the Procedure. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| procedure_concept_id | A foreign key that refers to a standard procedure Concept identifier in the Standardized Vocabularies. | integer | Yes | No | Yes | CONCEPT | Procedure | ||
| procedure_date | The date on which the Procedure was performed. | date | No | No | No | ||||
| procedure_datetime | The date and time on which the Procedure was performed. | datetime | Yes | No | No | ||||
| procedure_type_concept_id | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the procedure record is derived, belonging to the ‘Procedure Type’ vocabulary. | integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| modifier_concept_id | A foreign key to a Standard Concept identifier for a modifier to the Procedure (e.g. bilateral). These concepts are typically distinguished by ‘Modifier’ concept classes (e.g., ‘CPT4 Modifier’ as part of the ‘CPT4’ vocabulary). | integer | Yes | No | Yes | CONCEPT | |||
| quantity | The quantity of procedures ordered or administered. | integer | No | No | No | ||||
| provider_id | A foreign key to the provider in the PROVIDER table who was responsible for carrying out the procedure. | integer | No | No | No | PROVIDER | |||
| visit_occurrence_id | A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Procedure was carried out. | integer | No | No | No | VISIT_OCCURRENCE | |||
| visit_detail_id | A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Procedure was carried out. | integer | No | No | No | VISIT_DETAIL | |||
| procedure_source_value | The source code for the Procedure as it appears in the source data. This code is mapped to a standard procedure Concept in the Standardized Vocabularies and the original code is, stored here for reference. Procedure source codes are typically ICD-9-Proc, CPT-4, HCPCS or OPCS-4 codes. | varchar(50) | No | No | No | ||||
| procedure_source_concept_id | A foreign key to a Procedure Concept that refers to the code used in the source. | integer | Yes | No | No | CONCEPT | |||
| modifier_source_value | The source code for the qualifier as it appears in the source data. | varchar(50) | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| device_exposure_id | A system-generated unique identifier for each Device Exposure. | bigint | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person who is subjected to the Device. The demographic details of that Person are stored in the PERSON table. | bigint | Yes | No | Yes | PERSON | |||
| device_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies belonging to the ‘Device’ domain. | integer | Yes | No | Yes | CONCEPT | Device | ||
| device_exposure_start_date | The date the Device or supply was applied or used. | date | No | No | No | ||||
| device_exposure_start_datetime | The date and time the Device or supply was applied or used. | datetime | Yes | No | No | ||||
| device_exposure_end_date | The date use of the Device or supply was ceased. | date | No | No | No | ||||
| device_exposure_end_datetime | The date and time use of the Device or supply was ceased. | datetime | No | No | No | ||||
| device_type_concept_id | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of Device Exposure recorded. It indicates how the Device Exposure was represented in the source data and belongs to the ‘Device Type’ domain. | integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| unique_device_id | A UDI or equivalent identifying the instance of the Device used in the Person. | varchar(50) | No | No | No | ||||
| quantity | The number of individual Devices used in the exposure. | integer | No | No | No | ||||
| provider_id | A foreign key to the provider in the PROVIDER table who initiated or administered the Device. | integer | No | No | Yes | PROVIDER | |||
| visit_occurrence_id | A foreign key to the visit in the VISIT_OCCURRENCE table during which the Device was used. | integer | No | No | Yes | VISIT_OCCURRENCE | |||
| visit_detail_id | A foreign key to the visit detail record in the VISIT_DETAIL table during which the Device was used. | integer | No | No | Yes | VISIT_DETAIL | |||
| device_source_value | 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. | varchar(50) | No | No | No | ||||
| device_source_concept_id | A foreign key to a Device Concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| measurement_id | A unique identifier for each Measurement. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person about whom the measurement was recorded. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| measurement_concept_id | A foreign key to the standard measurement concept identifier in the Standardized Vocabularies. These belong to the ‘Measurement’ domain, but could overlap with the ‘Observation’ domain (see #3 below). | integer | Yes | No | Yes | CONCEPT | Measurement | ||
| measurement_date | The date of the Measurement. | date | No | No | No | ||||
| measurement_datetime | The date and time of the Measurement. Some database systems don’t have a datatype of time. To accommodate all temporal analyses, datatype datetime can be used (combining measurement_date and measurement_time forum discussion) | datetime | Yes | No | No | ||||
| measurement_time | The time of the Measurement. This is present for backwards compatibility and will be deprecated in an upcoming version | varchar(10) | No | No | No | ||||
| measurement_type_concept_id | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the provenance from where the Measurement record was recorded. These belong to the ‘Meas Type’ vocabulary | integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| operator_concept_id | A foreign key identifier to the predefined Concept in the Standardized Vocabularies reflecting the mathematical operator that is applied to the value_as_number. Operators are <, <=, =, >=, > and these concepts belong to the ‘Meas Value Operator’ domain. | integer | No | No | Yes | CONCEPT | |||
| value_as_number | A Measurement result where the result is expressed as a numeric value. | float | No | No | No | ||||
| value_as_concept_id | A foreign key to a Measurement result represented as a Concept from the Standardized Vocabularies (e.g., positive/negative, present/absent, low/high, etc.). These belong to the ‘Meas Value’ domain | integer | No | No | Yes | CONCEPT | |||
| unit_concept_id | A foreign key to a Standard Concept ID of Measurement Units in the Standardized Vocabularies that belong to the ‘Unit’ domain. | integer | No | No | Yes | CONCEPT | Unit | ||
| range_low | The lower limit of the normal range of the Measurement result. The lower range is assumed to be of the same unit of measure as the Measurement value. | float | No | No | No | ||||
| range_high | The upper limit of the normal range of the Measurement. The upper range is assumed to be of the same unit of measure as the Measurement value. | float | No | No | No | ||||
| provider_id | A foreign key to the provider in the PROVIDER table who was responsible for initiating or obtaining the measurement. | integer | No | No | Yes | PROVIDER | |||
| visit_occurrence_id | A foreign key to the Visit in the VISIT_OCCURRENCE table during which the Measurement was recorded. | integer | No | No | Yes | VISIT_OCCURRENCE | |||
| visit_detail_id | A foreign key to the Visit Detail in the VISIT_DETAIL table during which the Measurement was recorded. | integer | No | No | Yes | VISIT_DETAIL | |||
| measurement_source_value | The Measurement name as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is stored here for reference. | varchar(50) | No | No | No | ||||
| measurement_source_concept_id | A foreign key to a Concept in the Standard Vocabularies that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| unit_source_value | The source code for the unit as it appears in the source data. This code is mapped to a standard unit concept in the Standardized Vocabularies and the original code is stored here for reference. | varchar(50) | No | No | No | ||||
| value_source_value | The source value associated with the content of the value_as_number or value_as_concept_id as stored in the source data. | varchar(50) | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| visit_detail_id | A unique identifier for each Person’s visit or encounter at a healthcare provider. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person for whom the visit is recorded. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| visit_detail_concept_id | A foreign key that refers to a visit Concept identifier in the Standardized Vocabularies belonging to the ‘Visit’ Vocabulary. | integer | Yes | No | Yes | CONCEPT | Visit | ||
| visit_detail_start_date | The start date of the visit. | date | No | No | No | ||||
| visit_detail_start_datetime | The date and time of the visit started. | datetime | Yes | No | No | ||||
| visit_detail_end_date | The end date of the visit. If this is a one-day visit the end date should match the start date. | date | No | No | No | ||||
| visit_detail_end_datetime | The date and time of the visit end. | datetime | Yes | No | No | ||||
| visit_detail_type_concept_id | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the type of source data from which the visit record is derived belonging to the ‘Visit Type’ vocabulary. | Integer | Yes | No | Yes | ||||
| provider_id | A foreign key to the provider in the provider table who was associated with the visit. | integer | No | No | Yes | PROVIDER | |||
| care_site_id | A foreign key to the care site in the care site table that was visited. | integer | No | No | Yes | CARE_SITE | |||
| visit_detail_source_value | The source code for the visit as it appears in the source data. | string(50) | No | No | No | ||||
| visit_detail_source_concept_id | A foreign key to a Concept that refers to the code used in the source. | Integer | Yes | No | Yes | CONCEPT | |||
| admitted_from_source_value | The source code for the admitting source as it appears in the source data. | Varchar(50) | No | No | No | ||||
| admitted_from_concept_id | A foreign key to the predefined concept in the ‘Place of Service’ Vocabulary reflecting the admitting source for a visit. | Integer | Yes | No | Yes | CONCEPT | |||
| discharge_to_source_value | The source code for the discharge disposition as it appears in the source data. | Varchar(50) | No | No | No | ||||
| discharge_to_concept_id | A foreign key to the predefined concept in the ‘Place of Service’ Vocabulary reflecting the discharge disposition for a visit. | Integer | Yes | No | Yes | CONCEPT | |||
| preceding_visit_detail_id | A foreign key to the VISIT_DETAIL table of the visit immediately preceding this visit | Integer | No | No | Yes | VISIT_DETAIL | |||
| visit_detail_parent_id | A foreign key to the VISIT_DETAIL table record to represent the immediate parent visit-detail record. | Integer | No | No | Yes | VISIT_DETAIL | |||
| visit_occurrence_id | A foreign key that refers to the record in the VISIT_OCCURRENCE table. This is a required field, because for every visit_detail is a child of visit_occurrence and cannot exist without a corresponding parent record in visit_occurrence. | Integer | Yes | No | Yes | VISIT_OCCURRENCE |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| note_id | A unique identifier for each note. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person about whom the Note was recorded. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| note_event_id | A foreign key identifier to the event (e.g. Measurement, Procedure, Visit, Drug Exposure, etc) record during which the note was recorded. | integer | No | No | No | ||||
| note_event_field_concept_id | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the field to which the note_event_id is referring. | integer | No | No | No | CONCEPT | |||
| note_date | The date the note was recorded. | date | No | No | No | ||||
| note_datetime | The date and time the note was recorded. | datetime | Yes | No | No | ||||
| note_type_concept_id | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the type, origin or provenance of the Note. These belong to the ‘Note Type’ vocabulary | integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| note_class_concept_id | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the HL7 LOINC Document Type Vocabulary classification of the note. | integer | Yes | No | Yes | CONCEPT | |||
| note_title | The title of the Note as it appears in the source. | varchar(250) | No | No | No | ||||
| note_text | The content of the Note. | varchar(MAX) | Yes | No | No | ||||
| encoding_concept_id | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the note character encoding type | integer | Yes | No | Yes | CONCEPT | |||
| language_concept_id | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the language of the note | integer | Yes | No | Yes | CONCEPT | |||
| provider_id | A foreign key to the Provider in the PROVIDER table who took the Note. | integer | No | No | Yes | ||||
| visit_occurrence_id | A foreign key to the Visit in the VISIT_OCCURRENCE table when the Note was taken. | integer | No | No | Yes | VISIT_OCCURRENCE | |||
| visit_detail_id | A foreign key to the Visit in the VISIT_DETAIL table when the Note was taken. | integer | No | No | Yes | VISIT_DETAIL | |||
| note_source_value | The source value associated with the origin of the Note | varchar(50) | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| note_nlp_id | A unique identifier for each term extracted from a note. | integer | Yes | Yes | No | ||||
| note_id | A foreign key to the Note table note the term was | integer | Yes | No | No | ||||
| section_concept_id | A foreign key to the predefined Concept in the Standardized Vocabularies representing the section of the extracted term. | integer | Yes | No | Yes | NOTE | |||
| snippet | A small window of text surrounding the term. | varchar(250) | No | No | No | ||||
| offset | Character offset of the extracted term in the input note. | varchar(50) | No | No | No | ||||
| lexical_variant | Raw text extracted from the NLP tool. | varchar(250) | Yes | No | No | ||||
| note_nlp_concept_id | A foreign key to the predefined Concept in the Standardized Vocabularies reflecting the normalized concept for the extracted term. Domain of the term is represented as part of the Concept table. | integer | Yes | No | Yes | CONCEPT | |||
| note_nlp_source_concept_id | A foreign key to a Concept that refers to the code in the source vocabulary used by the NLP system | integer | Yes | No | Yes | CONCEPT | |||
| nlp_system | Name and version of the NLP system that extracted the term.Useful for data provenance. | varchar(250) | No | No | No | ||||
| nlp_date | The date of the note processing.Useful for data provenance. | date | Yes | No | No | ||||
| nlp_datetime | The date and time of the note processing. Useful for data provenance. | datetime | No | No | No | ||||
| term_exists | A summary modifier that signifies presence or absence of the term for a given patient. Useful for quick querying. | varchar(1) | No | No | No | ||||
| term_temporal | An optional time modifier associated with the extracted term. (for now “past” or “present” only). Standardize it later. | varchar(50) | No | No | No | ||||
| term_modifiers | 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”). | varchar(2000) | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| SURVEY_CONDUCT_ID | Unique identifier for each completed survey. | integer | Yes | Yes | No | ||||
| PERSON_ID | A foreign key identifier to the Person in the PERSON table about whom the survey was completed. | integer | Yes | No | Yes | PERSON | |||
| SURVEY_CONCEPT_ID | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the name and identity of the survey. | integer | Yes | No | Yes | CONCEPT | |||
| SURVEY_START_DATE | Date on which the survey was started. | date | No | No | No | ||||
| SURVEY_START_DATETIME | Date and time the survey was started. | datetime | Yes | No | No | ||||
| SURVEY_END_DATE | Date on which the survey was completed. | date | No | No | No | ||||
| SURVEY_END_DATETIME | Date and time the survey was completed. | datetime | Yes | No | No | ||||
| PROVIDER_ID | A foreign key to the provider in the provider table who was associated with the survey completion. | integer | No | No | Yes | PROVIDER | |||
| ASSISTED_CONCEPT_ID | A foreign key to the predefined Concept identifier in the Standardized Vocabularies indicating whether the survey was completed with assistance. | integer | Yes | No | Yes | ||||
| RESPONDENT_TYPE_CONCEPT_ID | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the respondent type. Example: Research Associate, Patient. | integer | Yes | No | Yes | CONCEPT | |||
| TIMING_CONCEPT_ID | A foreign key to the predefined Concept identifier in the Standardized Vocabularies that refers to a certain timing. Example: 3 month follow-up, 6 month follow-up. | integer | Yes | No | Yes | ||||
| COLLECTION_METHOD_CONCEPT_ID | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the data collection method (e.g. Paper, Telephone, Electronic Questionnaire). | integer | Yes | No | No | CONCEPT | |||
| ASSISTED_SOURCE_VALUE | Source value representing whether patient required assistance to complete the survey. Example: “Completed without assistance”, ”Completed with assistance”. | varchar(50) | No | No | No | ||||
| RESPONDENT_TYPE_SOURCE_VALUE | Source code representing role of person who completed the survey. | varchar(100) | No | No | No | ||||
| TIMING_SOURCE_VALUE | Text string representing the timing of the survey. Example: Baseline, 6-month follow-up. | varchar(100) | No | No | No | ||||
| COLLECTION_METHOD_SOURCE_VALUE | The collection method as it appears in the source data. | varchar(100) | No | No | No | ||||
| SURVEY_SOURCE_VALUE | The survey name/title as it appears in the source data. | varchar(100) | No | No | No | ||||
| SURVEY_SOURCE_CONCEPT_ID | A foreign key to a predefined Concept that refers to the code for the survey name/title used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| SURVEY_SOURCE_IDENTIFIER | Unique identifier for each completed survey in source system. | varchar(100) | No | No | No | ||||
| VALIDATED_SURVEY_CONCEPT_ID | A foreign key to the predefined Concept identifier in the Standardized Vocabularies reflecting the validation status of the survey. | integer | Yes | No | Yes | CONCEPT | |||
| VALIDATED_SURVEY_SOURCE_VALUE | Source value representing the validation status of the survey. | integer | No | No | No | ||||
| SURVEY_VERSION_NUMBER | Version number of the questionnaire or survey used. | varchar(20) | No | No | No | ||||
| VISIT_OCCURRENCE_ID | A foreign key to the VISIT_OCCURRENCE table during which the survey was completed | integer | No | No | Yes | VISIT_OCCURRENCE | |||
| RESPONSE_VISIT_OCCURRENCE_ID | A foreign key to the visit in the VISIT_OCCURRENCE table during which treatment was carried out that relates to this survey. | integer | No | No | Yes | VISIT_OCCURRENCE |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| observation_id | A unique identifier for each observation. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person about whom the observation was recorded. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| observation_concept_id | A foreign key to the standard observation concept identifier in the Standardized Vocabularies. | integer | Yes | No | Yes | CONCEPT | |||
| observation_date | The date of the observation. | date | No | No | No | ||||
| observation_datetime | The date and time of the observation. | datetime | Yes | No | No | ||||
| observation_type_concept_id | A foreign key to the predefined concept identifier in the Standardized Vocabularies reflecting the type of the observation. | integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| value_as_number | The observation result stored as a number. This is applicable to observations where the result is expressed as a numeric value. | float | No | No | No | ||||
| value_as_string | The observation result stored as a string. This is applicable to observations where the result is expressed as verbatim text. | varchar(60) | No | No | No | ||||
| value_as_concept_id | A foreign key to an observation result stored as a Concept ID. This is applicable to observations where the result can be expressed as a Standard Concept from the Standardized Vocabularies (e.g., positive/negative, present/absent, low/high, etc.). | Integer | No | No | Yes | CONCEPT | |||
| qualifier_concept_id | A foreign key to a Standard Concept ID for a qualifier (e.g., severity of drug-drug interaction alert) | integer | No | No | Yes | CONCEPT | |||
| unit_concept_id | A foreign key to a Standard Concept ID of measurement units in the Standardized Vocabularies. | integer | No | No | Yes | CONCEPT | Unit | ||
| provider_id | A foreign key to the provider in the PROVIDER table who was responsible for making the observation. | integer | No | No | Yes | PROVIDER | |||
| visit_occurrence_id | A foreign key to the visit in the VISIT_OCCURRENCE table during which the observation was recorded. | integer | No | No | Yes | VISIT_OCCURRENCE | |||
| visit_detail_id | A foreign key to the visit in the VISIT_DETAIL table during which the observation was recorded. | integer | No | No | Yes | VISIT_DETAIL | |||
| observation_source_value | The observation code as it appears in the source data. This code is mapped to a Standard Concept in the Standardized Vocabularies and the original code is, stored here for reference. | varchar(50) | No | No | No | ||||
| observation_source_concept_id | A foreign key to a Concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| unit_source_value | The source code for the unit as it appears in the source data. This code is mapped to a standard unit concept in the Standardized Vocabularies and the original code is, stored here for reference. | varchar(50) | No | No | No | ||||
| qualifier_source_value | The source value associated with a qualifier to characterize the observation | varchar(50) | No | No | No | ||||
| observation_event_id | A foreign key to an event table (e.g., PROCEDURE_OCCURRENCE_ID). | integer | No | No | No | ||||
| obs_event_field_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies referring to the field represented in the OBSERVATION_EVENT_ID. | integer | Yes | No | Yes | CONCEPT | |||
| value_as_datetime | The observation result stored as a datetime value. This is applicable to observations where the result is expressed as a point in time. | datetime | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| specimen_id | A unique identifier for each specimen. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person for whom the Specimen is recorded. | integer | Yes | No | Yes | PERSON | |||
| specimen_concept_id | A foreign key referring to a Standard Concept identifier in the Standardized Vocabularies for the Specimen. | integer | Yes | No | Yes | CONCEPT | |||
| specimen_type_concept_id | A foreign key referring to the Concept identifier in the Standardized Vocabularies reflecting the system of record from which the Specimen was represented in the source data. | integer | Yes | No | Yes | CONCEPT | Type Concept | ||
| specimen_date | The date the specimen was obtained from the Person. | date | No | No | No | ||||
| specimen_datetime | The date and time on the date when the Specimen was obtained from the person. | datetime | Yes | No | No | ||||
| quantity | The amount of specimen collection from the person during the sampling procedure. | float | No | No | No | ||||
| unit_concept_id | A foreign key to a Standard Concept identifier for the Unit associated with the numeric quantity of the Specimen collection. | integer | No | No | Yes | CONCEPT | |||
| anatomic_site_concept_id | A foreign key to a Standard Concept identifier for the anatomic location of specimen collection. | integer | Yes | No | Yes | CONCEPT | |||
| disease_status_concept_id | A foreign key to a Standard Concept identifier for the Disease Status of specimen collection. | integer | Yes | No | Yes | CONCEPT | |||
| specimen_source_id | The Specimen identifier as it appears in the source data. | varchar(50) | No | No | No | ||||
| specimen_source_value | The Specimen value as it appears in the source data. This value is mapped to a Standard Concept in the Standardized Vocabularies and the original code is, stored here for reference. | varchar(50) | No | No | No | ||||
| unit_source_value | The information about the Unit as detailed in the source. | varchar(50) | No | No | No | ||||
| anatomic_site_source_value | The information about the anatomic site as detailed in the source. | varchar(50) | No | No | No | ||||
| disease_status_source_value | The information about the disease status as detailed in the source. | varchar(50) | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| domain_concept_id_1 | The concept representing the domain of fact one, from which the corresponding table can be inferred. | integer | Yes | No | Yes | CONCEPT | |||
| fact_id_1 | The unique identifier in the table corresponding to the domain of fact one. | integer | Yes | No | No | ||||
| domain_concept_id_2 | The concept representing the domain of fact two, from which the corresponding table can be inferred. | integer | Yes | No | Yes | CONCEPT | |||
| fact_id_2 | The unique identifier in the table corresponding to the domain of fact two. | integer | Yes | No | No | ||||
| relationship_concept_id | A foreign key to a Standard Concept ID of relationship in the Standardized Vocabularies. | integer | Yes | No | Yes | CONCEPT |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| location_id | A unique identifier for each geographic location. | integer | Yes | Yes | No | ||||
| address_1 | The address field 1, typically used for the street address, as it appears in the source data. | varchar(50) | No | No | No | ||||
| address_2 | The address field 2, typically used for additional detail such as buildings, suites, floors, as it appears in the source data. | varchar(50) | No | No | No | ||||
| city | The city field as it appears in the source data. | varchar(50) | No | No | No | ||||
| state | The state field as it appears in the source data. | varchar(2) | No | No | No | ||||
| zip | The zip or postal code. | varchar(9) | No | No | No | ||||
| county | The county. | varchar(20) | No | No | No | ||||
| country | The country | varchar(100) | No | No | No | ||||
| location_source_value | The verbatim information that is used to uniquely identify the location as it appears in the source data. | varchar(50) | No | No | No | ||||
| latitude | The geocoded latitude | float | No | No | No | ||||
| longitude | The geocoded longitude | float | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| location_id | A foreign key to the location table. | integer | Yes | No | Yes | LOCATION | |||
| relationship_type_concept_id | The type of relationship between location and entity. | varchar(50) | Yes | No | Yes | CONCEPT | |||
| domain_id | The domain of the entity that is related to the location. Either PERSON, PROVIDER, or CARE_SITE. | varchar(50) | Yes | No | No | ||||
| entity_id | The unique identifier for the entity. References either person_id, provider_id, or care_site_id, depending on domain_id. | integer | Yes | No | No | ||||
| start_date | The date the relationship started. | date | Yes | No | No | ||||
| end_date | The date the relationship ended. | date | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| care_site_id | A unique identifier for each Care Site. | integer | Yes | Yes | No | ||||
| care_site_name | The verbatim description or name of the Care Site as in data source | varchar(255) | No | No | No | ||||
| place_of_service_concept_id | A foreign key that refers to a Place of Service Concept ID in the Standardized Vocabularies. | integer | Yes | No | Yes | CONCEPT | |||
| location_id | A foreign key to the geographic Location in the LOCATION table, where the detailed address information is stored. | integer | No | No | No | ||||
| care_site_source_value | The identifier for the Care Site in the source data, stored here for reference. | varchar(50) | No | No | No | ||||
| place_of_service_source_value | The source code for the Place of Service as it appears in the source data, stored here for reference. | varchar(50) | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| provider_id | A unique identifier for each Provider. | integer | Yes | Yes | No | ||||
| provider_name | A description of the Provider. | varchar(255) | No | No | No | ||||
| npi | The National Provider Identifier (NPI) of the provider. | varchar(20) | No | No | No | ||||
| dea | The Drug Enforcement Administration (DEA) number of the provider. | varchar(20) | No | No | No | ||||
| specialty_concept_id | A foreign key to a Standard Specialty Concept ID in the Standardized Vocabularies. | integer | Yes | No | Yes | CONCEPT | |||
| care_site_id | A foreign key to the main Care Site where the provider is practicing. | integer | No | No | Yes | CARE_SITE | |||
| year_of_birth | The year of birth of the Provider. | integer | No | No | No | ||||
| gender_concept_id | The gender of the Provider. | integer | Yes | No | Yes | CONCEPT | Gender | ||
| provider_source_value | The identifier used for the Provider in the source data, stored here for reference. | varchar(50) | No | No | No | ||||
| specialty_source_value | The source code for the Provider specialty as it appears in the source data, stored here for reference. | varchar(50) | No | No | No | ||||
| specialty_source_concept_id | A foreign key to a Concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| gender_source_value | The gender code for the Provider as it appears in the source data, stored here for reference. | varchar(50) | No | No | No | ||||
| gender_source_concept_id | A foreign key to a Concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| payer_plan_period_id | A identifier for each unique combination of payer, plan, family code and time span. | integer | Yes | Yes | Yes | PERSON | |||
| person_id | A foreign key identifier to the Person covered by the payer. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| contract_person_id | A foreign key identifier to the person_id in person table, for the person who is the primary subscriber/contract owner for the record in the payer_plan_period table. Maybe the same person or different person, depending on who is the primary subscriber/contract owner. | integer | No | No | No | ||||
| payer_plan_period_start_date | The start date of the payer plan period. | date | Yes | No | No | ||||
| payer_plan_period_end_date | The end date of the payer plan period. | date | Yes | No | No | ||||
| payer_concept_id | A foreign key that refers to a standard Payer concept identifier in the Standarized Vocabularies | integer | Yes | No | Yes | CONCEPT | |||
| payer_source_value | The source code for the payer as it appears in the source data. | varchar(50) | No | No | No | ||||
| payer_source_concept_id | A foreign key to a payer concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| plan_concept_id | A foreign key that refers to a standard plan concept identifier that represents the health benefit plan in the Standardized Vocabularies. | integer | Yes | No | Yes | CONCEPT | |||
| plan_source_value | The source code for the Person’s health benefit plan as it appears in the source data. | varchar(50) | No | No | No | ||||
| plan_source_concept_id | A foreign key to a plan concept that refers to the plan code used in the source data. | integer | Yes | No | Yes | CONCEPT | |||
| contract_concept_id | A foreign key to a standard concept representing the reason justifying the contract between person_id and contract_person_id. | integer | Yes | No | Yes | CONCEPT | |||
| contract_source_value | The source code representing the reason justifying the contract. Usually it is family relationship like a spouse, domestic partner, child etc. | integer | No | No | No | ||||
| contract_source_concept_id | A foreign key to a concept that refers to the code used in the source as the reason justifying the contract. | integer | Yes | No | Yes | CONCEPT | |||
| sponsor_concept_id | A foreign key that refers to a concept identifier that represents the sponsor in the Standardized Vocabularies. | integer | Yes | No | Yes | CONCEPT | |||
| sponsor_source_value | The source code for the Person’s sponsor of the health plan as it appears in the source data. | varchar(50) | No | No | No | ||||
| sponsor_source_concept_id | A foreign key to a sponsor concept that refers to the sponsor code used in the source data. | integer | Yes | No | Yes | CONCEPT | |||
| family_source_value | The source code for the Person’s family as it appears in the source data. | varchar(50) | No | No | No | ||||
| stop_reason_concept_id | A foreign key that refers to a standard termination reason that represents the reason for the termination in the Standardized Vocabularies. | integer | Yes | No | Yes | CONCEPT | |||
| stop_reason_source_value | The reason for stop-coverage as it appears in the source data. | varchar(50) | No | No | No | ||||
| stop_reason_source_concept_id | A foreign key to a stop-coverage concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| cost_id | A unique identifier for each COST record. | integer | Yes | Yes | No | ||||
| person_id | A unique identifier for each PERSON. | integer | Yes | No | Yes | PERSON | |||
| cost_event_id | A foreign key identifier to the event (e.g. Measurement, Procedure, Visit, Drug Exposure, etc) record for which cost data are recorded. | integer | Yes | No | No | ||||
| cost_event_field_concept_id | A foreign key identifier to a concept in the CONCEPT table representing the identity of the field represented by COST_EVENT_ID | integer | Yes | No | Yes | CONCEPT | |||
| cost_concept_id | A foreign key that refers to a Standard Cost Concept identifier in the Standardized Vocabularies belonging to the ‘Cost’ vocabulary. | integer | Yes | No | Yes | CONCEPT | |||
| cost_type_concept_id | A foreign key identifier to a concept in the CONCEPT table for the provenance or the source of the COST data and belonging to the ‘Cost Type’ vocabulary | integer | Yes | No | Yes | CONCEPT | |||
| cost_source_concept_id | A foreign key to a Cost Concept that refers to the code used in the source. | integer | Yes | No | Yes | CONCEPT | |||
| cost_source_value | The source value for the cost as it appears in the source data | varchar(50) | No | No | No | ||||
| currency_concept_id | A foreign key identifier to the concept representing the 3-letter code used to delineate international currencies, such as USD for US Dollar. These belong to the ‘Currency’ vocabulary | integer | Yes | No | Yes | CONCEPT | |||
| cost | The actual financial cost amount | float | Yes | No | No | ||||
| incurred_date | The first date of service of the clinical event corresponding to the cost as in table capturing the information (e.g. date of visit, date of procedure, date of condition, date of drug etc). | date | Yes | No | No | ||||
| billed_date | The date a bill was generated for a service or encounter | date | No | No | No | ||||
| paid_date | The date payment was received for a service or encounter | date | No | No | No | ||||
| revenue_code_concept_id | A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for Revenue codes belonging to the ‘Revenue Code’ vocabulary. | integer | Yes | No | Yes | CONCEPT | |||
| drg_concept_id | A foreign key referring to a Standard Concept ID in the Standardized Vocabularies for DRG codes belonging to the ‘DRG’ vocabulary. | integer | Yes | No | Yes | ||||
| revenue_code_source_value | The source value for the Revenue code as it appears in the source data, stored here for reference. | varchar(50) | No | No | No | ||||
| drg_source_value | The source value for the 3-digit DRG source code as it appears in the source data, stored here for reference. | varchar(50) | No | No | No | ||||
| payer_plan_period_id | A foreign key to the PAYER_PLAN_PERIOD table, where the details of the Payer, Plan and Family are stored. Record the payer_plan_id that relates to the payer who contributed to the paid_by_payer field. | integer | No | No | Yes |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| drug_era_id | A unique identifier for each Drug Era. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person who is subjected to the Drug during the fDrug Era. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| drug_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the Ingredient Concept. | integer | Yes | No | Yes | CONCEPT | Drug | Ingredient | |
| drug_era_start_datetime | The start date for the Drug Era constructed from the individual instances of Drug Exposures. It is the start date of the very first chronologically recorded instance of conutilization of a Drug. | datetime | Yes | No | No | ||||
| drug_era_end_datetime | The end date for the drug era constructed from the individual instance of drug exposures. It is the end date of the final continuously recorded instance of utilization of a drug. | datetime | Yes | No | No | ||||
| drug_exposure_count | The number of individual Drug Exposure occurrences used to construct the Drug Era. | integer | No | No | No | ||||
| gap_days | The number of days that are not covered by DRUG_EXPOSURE records that wer | integer | No | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| dose_era_id | A unique identifier for each Dose Era. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person who is subjected to the drug during the drug era. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | Yes | PERSON | |||
| drug_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the active Ingredient Concept. | integer | Yes | No | Yes | CONCEPT | Drug | Ingredient | |
| unit_concept_id | A foreign key that refers to a Standard Concept identifier in the Standardized Vocabularies for the unit concept. | integer | Yes | No | Yes | CONCEPT | Unit | ||
| dose_value | The numeric value of the dose. | float | Yes | No | No | ||||
| dose_era_start_datetime | The start date for the drug era constructed from the individual instances of drug exposures. It is the start date of the very first chronologically recorded instance of utilization of a drug. | datetime | Yes | No | No | ||||
| dose_era_end_datetime | The end date for the drug era constructed from the individual instance of drug exposures. It is the end date of the final continuously recorded instance of utilization of a drug. | datetime | Yes | No | No |
| CDM Field | User Guide | ETL Conventions | Datatype | Required | Primary Key | Foreign Key (FK) | FK Table | FK Domain | FK Class |
|---|---|---|---|---|---|---|---|---|---|
| condition_era_id | A unique identifier for each Condition Era. | integer | Yes | Yes | No | ||||
| person_id | A foreign key identifier to the Person who is experiencing the Condition during the Condition Era. The demographic details of that Person are stored in the PERSON table. | integer | Yes | No | No | PERSON | |||
| condition_concept_id | A foreign key that refers to a standard Condition Concept identifier in the Standardized Vocabularies. | integer | Yes | No | No | CONCEPT | Condition | ||
| condition_era_start_datetime | The start date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the start date of the very first chronologically recorded instance of the condition. | datetime | Yes | No | No | ||||
| condition_era_end_datetime | The end date for the Condition Era constructed from the individual instances of Condition Occurrences. It is the end date of the final continuously recorded instance of the Condition. | datetime | Yes | No | No | ||||
| condition_occurrence_count | The number of individual Condition Occurrences used to construct the condition era. | integer | No | No | No |


It’s hard to believe it was not even a year ago that I spoke at the jQuery Conference in Boston about code organization. At the time, I’d been thinking for a few months about how to improve my own code and give it more structure, and how to give advice to others about how to do the same.
My talk was about code organization, but really I was talking about how you might organize a single piece of functionality; I didn’t even begin to answer the larger question of how to structure a bona fide JavaScript application. Really, that question is almost perpendicular to the one I was tackling at the time; it’s a question of strategy, not tactics.
A year later, I’d like to share my thoughts on how I’m answering it these days.
First Things First: What’s a JavaScript Application?
GMail is a JavaScript application; this Posterous blog, while it makes use of JavaScript a bit, is probably not, but the admin interface most certainly is. The line can be frustratingly fuzzy, but at the same time it’s pretty important to realize when you’ve crossed it.
To me, the defining characteristic of a JavaScript application is that the heavy lifting of manipulating and displaying data falls to the browser, with most communication with the server happening via XHR.
If you find yourself in application land, welcome. Now what?
My Building Blocks
My approach to organizing an application is really just an MVC variant, so I don’t want to sound as though I’ve discovered something novel or new. However, there are a couple of things to note: For one, the term “controller” has a couple of different meanings to me, as explained below; for two, there are two distinct flavors of “views,” though I’m not sure exactly how important the distinction is.
I also want to be super-clear that I don’t tout this as The One and Only Way; it is just a way that has worked for me, a way that I evolve and adapt with every project I work on, and a way that I’ve run by a few people and they haven’t laughed at me. My point in dissecting it isn’t that you’ll try to follow it word-for-word; rather, I hope it might get you thinking about JavaScript applications beyond the DOM.
Models
There’s nothing particularly unique to models in a JavaScript application. They are responsible for fetching and storing application data and maintaining its integrity in the browser. They fetch data, store data, and provide an API for other application components to get access to that data. There may be more than one destination for the data: memory, the server, or some type of local storage. But if it has to do with managing data, it’s the model’s job.
Models stay out of the way when it comes to displaying data or responding (at least directly) to user interaction. Those tasks are left up to other pieces of the application, as we’ll see below.
Example
A simple search application would likely have a search results model, responsible for receiving the current search term, fetching the data for the term, and broadcasting it to the rest of the application. It might also allow for manipulating individual search results, such as indicating that a particular result was a favorite or a dud, though that task might also fall to an individual search result model depending on the needs.
Widgets and Data Views
Views comprise HTML (generally in the form of client-side templates) and CSS for a component, and are generally accompanied by a view controller (the JavaScript related to interacting with the vew; see below for an explanation). The HTML for a view consists of a single parent node with an arbitrary internal structure; the parent node will optionally have one or more classes on it that can be used to target CSS.
There are two flavors of views, in my mind: widgets, which are responsible for supporting user interaction with the application but don’t render any application data; and data views that are responsible for displaying and allowing interaction with application data.
Data views are instantiated with the initial data required to populate them; then, their view controllers listen for messages from other pieces of the application to tell them when new or updated data needs to be rendered.
Examples
A basic search input box would be considered a widget — when it is created, it doesn’t need any application data in order to render properly. The widget is strictly responsible for allowing the basic interaction of typing a search term and hitting enter; that is, it’s not responsible for actually performing the search.
A search results list is an example of a data view; it renders application data and, potentially, allows for interaction with it. Again, though, it’s not responsible for performing the search; it just renders data and then allows for interaction with it.
View Controllers
View controllers manage interaction with a data view or widget — interaction by the user, and interaction with the rest of the application. They are responsible for binding and handling events, for broadcasting user interactions with the widget to the rest of the application, and for listening to other pieces of the application to tell them they have new data to render.
View controllers never handle server communication directly; their role is solely to provide a user interface to the application. When something interesting happens to a view or widget, the view controller announces it. When new data is available for a view, the view controller should know how to handle it. But, again, the view controller itself should focus on providing a user interface, not on interfacing with the server.
Examples
The view controller for a search box might listen for the user to focus on the search box, hiding placeholder text for the input. Then, it might listen for the user to hit Enter inside the search box; when that happens, it would broadcast to the rest of the application that the user had submitted a search, along with the term that was searched.
The view controller for a search results list might listen for another piece of the application to announce that new search results are available to be displayed. If the results were for the currently displayed search term, it could add them to the list; if they were for a new term, the results list could empty itself and display the new results.
Application-Level Controllers
Application-level controllers are the glue of an application. Loosely, there may be one per “page” of the application, or one per feature. For example, an application that includes a search feature and a checkout feature might have a controller for each feature, even though the checkout feature might spread across multiple pages.
These controllers are responsible for getting the models and views/widgets for a feature in place and talking to each other. So, a controller might first make sure the required models are in place, then tell them to fetch the appropriate data; once the data is available, the controller would instantiate the views for displaying the data. Finally, the controller would broker future interactions between the views and the models.
Examples
On a search results page, a user might click a Favorite button on a search result. The search results list’s view controller would handle the click, broadcasting a message about the user’s action to the rest of the application. The controller would observe this message and pass it, along with any other relevant information, to the search results model, which would in turn pass the information to the server, or store it locally.
Notes on Enablers
I’ve glossed over a few implementation details that are somewhat tangential to the organization question, but I want to touch on them briefly:
Pubsub and Friends
I didn’t want to get too specific about how all of this “announcing” and “broadcasting” and “listening” happens, because there are lots of ways to accomplish it. One could use pubsub, custom events, or any number of other solutions. I don’t think the actual implementation is important, though personally I lean heavily on pubsub — what is important is the notion of broadcasting and listening for announcements that something has happened, allowing other components of the application to react appropriately.
Templating
If you aren’t using a toolkit with templating built in (or, heck, even if you are), I’ve kind of fallen in love with mustache.js lately. It’s a great client-side templating companion, making it dead-simple to turn data into markup without ending up with templates that look more like JavaScript than HTML.
Figuring out how to maintain templates can be tricky — do you store them in your page’s markup? Do you maintain them as separate files requested via XHR and then cached? Or do you put them in your JavaScript? Dojo’s dojo.cache()
method provides a handy way to keep your templates in separate files and load them via XHR, while interning them into your JavaScript for you if you use Dojo’s build tool. I like this.
Attaching Events to Views
Another shameless Dojo plug: dijit.\_Templated
provides some serious hotness when it comes to attaching events to views. Read up on dojoAttachPoint
and dojoAttachEvent
; together with dijit._Widget’s connect
and subscribe
methods, which provide automatic cleanup for you, there’s some real power here, which has me writing hardly any selector-based code these days.
File Structure
I hesitate to make any particular recommendations here, because the needs of an application can vary widely. However, I tend to have a directory each for models, views (for view controllers and templates), and controllers (for application-level controllers). Those directories — especially the views directory — may contain subdirectories, for instance if there’s more than one view for a certain type of data.
Why Go To All This Trouble, Again?
So this is the part where you might say “OMG, srsly, what happened to ‘get some elements, do something with them?!?’” Let me be clear, that approach may be entirely appropriate for your particular needs; I’m not here to convince you otherwise.
But: if your application is complex enough to warrant considering an approach like this, I’ve found that in the long run it actually simplifies my code by cleanly separating concerns and providing a decent roadmap for building new features. I can build and test a solid model for some Thinger, and then use that model throughout my code; I can build and test a user interface component for editing a Thinger long before the data exists to support it. I can map “pages” of my application to application-level controllers, providing a high-level view of what’s happening where.
Best of all, paths to code reuse become clear and entanglements become fewer when I keep this division of responsibilities in mind as I code. A search results data view, for example, can be made to accept search results from any model that provides them in the proper format; a search can be initiated and the results displayed without depending on a user entering text into a search input widget.
Dividing the responsibilities into well-defined sections leads to components that are truly pluggable, often in ways you may not have even imagined when you wrote them. In an application that evolves over time, it’s hard to overstate the benefits of this.
In Conclusion & A Plea
If you find yourself working on a JavaScript application, I can’t recommend enough that you consider, at length, what underlying structure makes the most sense; it’s almost inevitably more complex than you can manage via the DOM alone. Again, my answer isn’t the right answer, it’s just an answer, but I hope it helps you start thinking about what the right answer might be for your project.
If you’re interested in this stuff, I’d encourage you to check out JavaScriptMVC, if only to see how they approach these problems; Cujo.js is another framework, built on top of Dojo, that aims to enter this space, but you’ll have to wait until mid-September to see it.
Finally: If you have your own thoughts to share about how to approach these large application questions, I’m pleading with you to write your own blog post(s) about them. If you have other reference material on the topic, I beg you to share it. As more and more people transition from simple JavaScript enhancements to non-trivial applications, the need for education is huge.


GreenHouse
Home
Control
Statistics
File Browser
Remote Control
Fan On
Fan Auto
Fan Off
Light On
Light Auto
Light Off


3.1. CONTEXT-FREE GRAMMARS
E
→
E
+
T
E
→
E
−
T
E
→
T
T
→
T
∗
F
T
→
T
/
F
T
→
F
F
→
id
F
→
num
F
→
(
E
)
GRAMMAR 3.8.
.
?X
+
?Y
+
.
?U
?V
+
*
FIGURE 3.9.
Parse trees that Grammar 3.8 will never produce.
parse trees to interpret the meaning of the expressions, the two parse trees for
1-2-3
mean different things:
(
1
−
2
)
−
3
=
−
4 versus 1
−
(
2
−
3
)
=
2.
Similarly,
(
1
+
2
)
×
3 is not the same as 1
+
(
2
×
3
)
. And indeed, compilers
do use parse trees to derive meaning.
Therefore, ambiguous grammars are problematic for compiling: in general
we would prefer to have unambiguous grammars. Fortunately, we can often
transform ambiguous grammars to unambiguous grammars.
Let us ﬁnd an unambigous grammar that accepts the same language as
Grammar 3.5.
First, we would like to say that
*
binds tighter
than
+
, or has
higher precedence
. Second, we want to say that each operator
associates to
the left
, so that we get
(
1
−
2
)
−
3 instead of 1
−
(
2
−
3
)
. We do this by
introducing new nonterminal symbols to get
Grammar 3.8.
The symbols
E
,
T
, and
F
stand for
expression
,
term
, and
factor
; conven-
tionally, factors are things you multiply and terms are things you add.
This grammar accepts the same set of sentences as the ambiguous gram-
mar, but now each sentence has exactly one parse tree.
Grammar 3.8
can never
produce parse trees of the form shown in
Figure 3.9
(see
Exercise 3.17
).
Had we wanted to make
*
associate to the right, we could have written its
production as
T
→
F
∗
T
.
We can usually eliminate ambiguity by transforming the grammar. Though
there are some languages (sets of strings) that have ambiguous grammars
but no unambiguous grammar, such languages may be problematic as
pro-
gramming
languages because the syntactic ambiguity may lead to problems
in writing and understanding programs.
45


We're sorry but my-project doesn't work properly without JavaScript enabled. Please enable it to continue.
loading...


Keyboard arrows ← ↑ → ↓ to move between the cells in the four directions.
Tab key ⇥ to move to the next definition.
Spacebar to change the direction of the selected word.
Backspace key to delete the value of the cell e move to the previous one.
Delete key to delete the value of the cell without moving.
Click on a definition to go to the respective cells.
Click on "check" to check with the solution.


This little EPUB is being written to demonstrate several of the ways that animated SVG can be used for illustrating educational and related ideas. It is not intended as a tutorial on SVG itself nor is it an exhaustive examination of all the ways that one might use SVG animation. Still it covers three basic methods for animating SVG: SMIL, JavaScript and CSS3. A such, it is hoped that it may be useful and interesting to some.
It is worth noting that there are other ways to animate SVG. One example is three.js. Three.js allows one to import SVG paths and use them to construct 3D objects which can then be extruded, animated, textured, etc. This pattern is also possible with other frameworks. The point being that SVG as an open "graphics description" format can be used to define a graphical construct which can then be animated using whatever framework is loading it. That said, the three methods mentioned above are the current methods for animating SVG within the context of its normal context, i.e. a SVG or HTML document per se.
It is worth noting that the use of SMIL animation in an EPUB such as this is, strictly speaking, disallowed by the EPUB spec. The EPUB Working Group (of which the author is a long-time member) decided in the early days of EPUB (circa 2.x) that SVG animation, though fully supported by both Adobe's SVG Viewer and Sun's Batik viewer, should not be allowed in EPUB documents. Somewhat ironically, none of us in the WG can clearly recall why we decided that SMIL animation should be excluded. In those long ago days, processors in eBook devices were slow, batteries weak and many displays were eInk with its slow refresh rate. These were probably the primary arguments to not allow SMIL animation. Finally, it has to be acknowledged that implementing SMIL animation in SVG was quite difficult, which may have also played a role as the WG was trying to encourage implementation of the standard.
The author of this EPUB, Ric Wright, is the Director of Engineering for the Readium project, which is an open-source foundation dedicated to providing web apps and a SDK for rendering EPUB, the standard format for eBooks. Prior to running Readium, Ric was with Adobe Systems for many years, where he was a key member of the original SVG Viewer group and was also responsible for most of the libraries for import/export of SVG from Adobe's tools include Illustrator, InDesign and LiveMotion. After Adobe killed the SVG Viewer (because management was in love with Flash - he who laughs last and all that), Ric founded and led the eBook group at Adobe until his departure in 2012. More details of Ric's background can be found on his website at Geo-F/X.
The details of how this book was created are covered in the Colophon at the end of the book.
If you have any feedback, suggestions or bug reports about this book, you are strongly encouraged to contact Ric directly.


ARMAGEDDON 1998 A film review by Timothy Voon Copyright 1998 Timothy Voon 1 :-) for a very noisy ride
Director: Michael Bay Writer: Jonathan Hensleigh, J.J. Abrams Cast: Bruce Willis, Billy Bob Thornton, Liv Tyler, Ben Affleck, Will Patton, Peter Stormare, Keith David, Steve Buscemi
In ARMAGEDDON, everyone wants to save the world, each other, and carry on them so much love and comradeship, you'll gag on the popcorn. There are no bad guys, except for a big, mean meteorite and a highly unintelligent president. Throw in volatile father/daughter/lover relationships, the fate of humanity hanging on limbo, about to be blasted into oblivion and NOISE, NOISE, MORE NOISE, and before long, you're senses have been thrown into overdrive by the Jerry Bruckheimer team. They have once again pulled out a no stops, glitzy, action packed, noisy adventure that will leave you dizzy with explosions and collisions, that just seem to roll across the screen.
Unlike the slower, more thoughtful, DEEP IMPACT, this movie begins with a flash of destruction – the collapsing Chrysler building - you can't get smaller than that. Not to mention, an action packed cast all wanting their fair share of screen time - namely, Mr. B.Willis, Mr. B.Affleck, and Mr. B.B.Thornton. Mr. Willis gets to give his customary, ‘look how tough I am' stare, that also spells ‘I'm the greatest American Action Hero'. Whilst Mr. Affleck, who hasn't learnt how to develop this technique yet, throws himself about the screen, saying ‘Watch out for me, I'm better looking, and I'm going to be the next best American Action Hero.' Mr B.B. Thornton, on the other hand, carries himself with such self-control and dignity, that says to Willis and Affleck, ‘I may not be as good looking, but I can sure act better than the both of you.' On the side, Liv Tyler, looks prettier than all three.
On the whole, an action packed thrill ride that is certain to please lovers of special effects and action heroes. If this is your kind of film, then it is probably worth the weight of a movie ticket, as it will be much less impressive on tape.
Timothy Voon e-mail<EMAIL_ADDRESS>Movie Archives http://us.imdb.com/M/reviews_by?Tim+Voon Movies In Melbourne http://www.labyrinth.net.au/~pfowler/week/movies.html
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


When to use iterative development? You should use iterative development only on projects that you want to succeed. --Martin Fowler, in "UML Distilled"


Plavada Thottappattu,Ernakulam,Kerala,India - 683105 | +918113064587 |<EMAIL_ADDRESS>Experienced Electrical Engineer with strong data analytical skills with a demonstrated history of working in the transportation/trucking/railroad industry and managing staff to the size of approx 150. Skilled in C++, Python, and Web Development. Strong engineering professional with a Bachelor of Technology (B.Tech.) with Honours focused in Electrical and Electronics Engineering from Mahatma Gandhi University
Graduated with 8.33 CGPA with recognition for Best Seminar Presentation.
54 x 44 px image is converted to 218 x 178 px image (400 %) using Deep Neural Net. Trained on 1,50,000 images. Tested on 40,000 images .
Deep Neural Network is used to remove noise from images. The NN is implemented using TensorFlow and the dataset is obtained from Kaggle.
Implemented RNN in Python using Keras library
Used methods in NLTK for cleaning the text. Prediction is made using Gradient Boosting Classifier from sci-kit learn.
Convolutional Neural Network was trained on 42000 inputs with an accuracy of 99.73% and tested on 28000 inputs with an accuracy of 98.5%.
A new communication system incorporating principles of Power Line Communication and Visible Light Communication for intra-building networks.
TensorFlow, PyTorch, Pandas, Sci-kit Learn, Numpy, NLTK, R
C, C++, Java, Python, Kotlin, Go, Rust
HTML, CSS, Javascript, NodeJS, jQuery
MATLAB, Octave
PIL, OpenCV
Presented paper on Quantum Networking and Internetworking.
National Level Competition for case solving conducted by IEEE Madras Section
Organised various events and participated in State level and National Level Events representing the organization.


ezHealthTrack
Mahesha Software Pvt. Ltd.
3rd Floor, D-77 Sector 63,
Noida UP - 201301, India
{{ content_html|raw }}