| Table of Contents |
|---|
Summary
Timing is of utmost importance to study conduct and data deliverables. This article references an important topic related to Data Collection workflows.
...
Transaction Time: Unlike Item Data and Collection Time, this date/time variable may not be specified or modified by a user. Rather, Transaction Time records the server date/time at which a data save or data update occurs. Overwhelmingly, this is the server date/time associated with the study site timezone configuration, at which a user clicks a save button.
| Info |
|---|
Server Time ClinSpark runs on Amazon EC2 instances that use AWS Linux. These instances use the Amazon Time Sync Service, a time synchronization service delivered over Network Time Protocol (NTP). More details about how time is established on those instances can be found within AWS documentation. Within this document, the reference to ‘server time’ is applicable to this environment variable. Study site timezone configuration is also taken into account for collection and display of this value during study conduct. |
Item Data Time
Items marked as ‘datetime’ data type allow a user to input a date/time as an item value via a series of ‘select’ boxes including year, month, day, hour, minute, and second. Similar to a code list or free text response to an item, this data is saved as a reportable response to a data field. If a ‘datetime’ item is also marked as ‘Capture Time’, the date/time entered against the data field will double as the Collection Time for a form.
Current and Scheduled Time Buttons
Two timing buttons (Current and Scheduled) are available to expedite filling of a date/time item field, with Scheduled Time button availability dependent upon a number of conditions. In clicking Current Time, the time from the local computing device is used to pre-fill the item data field. If a given form is ‘timed’ and the user clicks Scheduled Time, the time for which the form is scheduled will be used to prefill the item data field. In either case, the user is always presented with the date/time that will be saved and they can modify the date/time using the timing select boxes. Note that these button are nothing other than productivity enhancements and it is still the responsibility of the user to ensure that the data in the form is the data which they want to save.
Important Note: For Current Time and Scheduled Time buttons to work as expected, it is assumed that the timezone on the data collection computer matches the applicable study site timezone for which a subject is related. Additionally, the site is expected to be configured with the appropriate time zone region and not the time zone offset to properly accommodate for DST. Site timezones are configured in the Administration > Sites component.
...
Conditions for Scheduled Time Button
In order for the Scheduled Time button to be available during data collection, the following conditions must be met:
...
The containing form must be scheduled with timing (either as part of a timed activity plan or as a timed unscheduled activity):
...
Default to Current Time
Upon opening a form, the current time of the data collection computer will default into date/time item fields, assuming the following conditions are met:
...
The item’s ‘Capture Time’ configuration must be set to ‘Yes’ within the CRF Design > Study Library component:
...
Default to Scheduled Time
Upon opening a form, the scheduled time of a timed activity will default into date/time item fields, assuming the following conditions are met:
...
The containing form must be scheduled with timing (either as part of a timed activity plan or as a timed unscheduled activity):
...
Collection Time
Collection Time is the date/time that a user documents as the moment of activity occurrence and is the time used for eliciting deviations and reference activity recalculations. This is distinct from Transaction Time. Whereas a user typically specifies collection time, transaction time is a system-generated timestamp capturing the true time of user interaction with a form.
The means by which collection time is documented is largely dependent on form design. Following are the possible routes by which collection time is populated.
Scenario 1: Collection Time Field
Leveraging the ‘Collection Time’ field during data collection will ALWAYS take precedence as the date/time of data collection. If this feature is leveraged, all other scenarios will be overridden.
...
During data collection, the hidden collection time field may be made visible via Form Actions > Collection Time:
...
Scenario 2: Single Datetime Item Marked with ‘Capture Time’
If the ‘Collection Time’ field is not leveraged and the form contains a datetime item marked with ‘Capture Time’, this item’s date/time will be used as the form’s collection time.
...
When a capture time item is submitted during data collection, this date/time will be used as the collection time for the form and will elicit deviations and reference activity recalculations as applicable:
...
Scenario 3: Multiple Datetime Items Marked with ‘Capture Time’
If the ‘Collection Time’ field is not leveraged and the form contains multiple datetime items marked with ‘Capture Time’, the earliest date/time entry will be used as the form’s collection time.
...
When a form containing multiple datetime items marked with capture time is submitted during data collection, the earliest capture time will be used as the collection time for the form and will elicit deviations and reference activity recalculations as applicable:
...
Scenario 4: Form Does Not Contain Timing Items
If the ‘Collection Time’ field is not leveraged and the form does not contain datetime items marked with ‘Capture Time’, server date/time at the time of saving will be used as the form’s collection time.
When a form without datetime items is submitted during data collection, the server date/time will be used as the collection time for the form and will elicit deviations and reference activity recalculations as applicable:
Scenario 5: Resubmission of Form
Collection Time is affected in various ways during form resubmission, dependent on the field(s) being resubmitted.
If a form contains a capture time item but a different item in the form is resubmitted, collection time from the previous submission is preserved.
If a form contains a capture time item and that item is resubmitted, collection time will update to the newly specified capture time.
If a form contains multiple capture time items and one of those items is resubmitted, collection time will update to the earliest capture time contained in the form.
If a form does not contain a capture time item and the form is resubmitted, collection time will update to the server date/time at the time of resubmission.
If the ‘Collection Time’ feature is leveraged during form resubmission, collection time will update to the date/time entered in the Collection Time field.
Transaction Time
Transaction Time records the server date/time at which a data save or data update occurs. Transaction Time also tracks the date/time at which annotations are saved. Overwhelmingly, this is the server date/time at which a user clicks a save button and is instrumental to data auditability.
Following are the various levels at which Transaction Time is documented.
Item Data
Item Data audits may be accessed by clicking on the associated item prompt hyperlink:
...
Annotations: date/time of saving an item annotation
Data Creation: ‘item data created’ in this example, this is the date/time at which the item was made available for collection, either via activity plan activation or by adding an unscheduled or common form during data collection
User Entry: ‘User Entry’ in this example, this is the date/time at which a user saves a data field for the first time
Data Update: ‘Data correction’ in this example, this is the date/time at which a user saves an updated/changed response to an item
...
Item Group Data
Item Group Data audits may be accessed by clicking on the associated item group name hyperlink:
...
Annotations: date/time of saving an item group annotation
Data Creation: ‘item group data created’ in this example, this is the date/time at which the item group was made available for collection, either via activity plan activation or by adding an unscheduled or common form during data collection
Collection Time Saved: date/time at which a user registers a collection time. This typically represents each time that a save button is clicked within a form
...
Form Data
Form Data audits may be accessed by clicking on the associated form name hyperlink:
...
Annotations: date/time of saving a form annotation
ICF Bypass: ‘bypassing ICF requirement’ in this example, this is the date/time at which a qualified user bypasses an ICF requirement for data collection or data viewing
Data Creation: ‘form data created’ in this example, this is the date/time at which the form was made available for collection, either via activity plan activation or by adding an unscheduled or common form during data collection
Subject Barcode: ‘subject barcode acknowledged’ in this example, this is the date/time at which a user scans a subject barcode to initiate data collection
Study Event Data
Study Event Data audits may be accessed by clicking on the associated study event name hyperlink:
...