documentation:next_cdm:time
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| documentation:next_cdm:time [2016/11/01 18:14] – hripcsa | documentation:next_cdm:time [2017/07/06 15:05] (current) – clairblacketer | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ===== Add Time Field to various Occurrence and Exposure Tables ===== | ===== Add Time Field to various Occurrence and Exposure Tables ===== | ||
| + | === Proposals are now being stored as github issues === | ||
| + | [[https:// | ||
| While v5 visit_occurrence table supports both date and time of event, other occurrence tables and exposure tables such as drug, condition, and procedure support only the date level. | While v5 visit_occurrence table supports both date and time of event, other occurrence tables and exposure tables such as drug, condition, and procedure support only the date level. | ||
| Line 52: | Line 54: | ||
| And the ERA tables, COHORT tables, and PAYER_PLAN_PERIOD table. | And the ERA tables, COHORT tables, and PAYER_PLAN_PERIOD table. | ||
| + | |||
| === DECISION 1 === | === DECISION 1 === | ||
| - | We propose adding a time field or fields to the following tables | + | We have a choice between adding fields of type time, which require significant processing to determine durations (join the date and time, and then operate on that) versus defining a datetime field as timestamp, which allows fast operations but produces redundancy. |
| + | |||
| + | [Suggest datetime = timestamp.] | ||
| + | |||
| + | === DECISION 2 === | ||
| + | |||
| + | We propose adding a datetime | ||
| * Condition_Occurrence | * Condition_Occurrence | ||
| * Procedure_Occurrence | * Procedure_Occurrence | ||
| Line 62: | Line 71: | ||
| * Death | * Death | ||
| - | A time field would be added to each date field. Date fields | + | We propose replacing the current |
| + | * Specimen | ||
| + | * Visit_Occurrence | ||
| + | * Measurement | ||
| + | * Note | ||
| + | * Observation | ||
| - | This would support handling data from ICU, Emergency Department, infusions, post-procedure care, etc. where multiple events occur on the same day and sequence matters. This granularity | + | A datetime field (also known as timestamp field) |
| - | [Suggest moving forward with fields called *_TIME | + | This would support handling data from ICU, Emergency Department, infusions, post-procedure care, etc. where multiple events occur on the same day and sequence matters. This granularity would also support the incorporation of data generated from tracking devices. |
| - | + | ||
| - | === DECISION 2 === | + | |
| - | We have a choice between adding | + | In addition, current *_TIME |
| - | [Suggest | + | [Suggest |
| === DECISION 3 === | === DECISION 3 === | ||
| - | Are the time fields required. Making them required allows developers to begin to use them with a potential migration from date+time or date+timestamp to timesteamp in the future, but it forces CDM builders to enter unknown times or timestamps. If required, the default time will be the first instant in the allowable period. E.g., 1990-12-01-00: | + | Are the datetime |
| [Suggest optional for now.] | [Suggest optional for now.] | ||
| Line 82: | Line 94: | ||
| === DECISION 4 === | === DECISION 4 === | ||
| - | Should a timestamp field be added to BIRTH (or alternatively should PERSON.time_of_birth be changed to timestamp). This will allow more rapid calculation of age but will be redundant with the current information. | + | Should a date time (timestamp) field be added to BIRTH (or alternatively should PERSON.time_of_birth be changed to timestamp). This will allow more rapid calculation of age but will be redundant with the current information. |
| - | [Suggest | + | [Suggest |
| === DECISION 5 === | === DECISION 5 === | ||
documentation/next_cdm/time.1478024080.txt.gz · Last modified: by hripcsa