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/18 15:02] – 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 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 field or fields to the following tables | We propose adding a datetime field or fields to the following tables | ||
| Line 73: | Line 82: | ||
| 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. | 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. | ||
| - | In addition, current *_TIME fields would be removed. | + | In addition, current *_TIME fields would be removed. At this point, all current software will continue working with the *_DATE fields, and over time we will develop extensions to the software to accommodate DATETIME in different database management systems. |
| - | [Suggest moving forward with fields called *_DATETIME, removing the *_TIME fields.] | + | [Suggest moving forward with fields called *_DATETIME, removing the *_TIME fields. |
| - | + | ||
| - | === DECISION 2 === | + | |
| - | + | ||
| - | We have a choice between adding | + | |
| - | + | ||
| - | [Suggest datetime = timestamp.] | + | |
| === DECISION 3 === | === DECISION 3 === | ||
| Line 91: | 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.1479481326.txt.gz · Last modified: by hripcsa