Summary

Timing is of utmost importance to study conduct and data deliverables. This article references an important topic related to Data Collection workflows.

ClinSpark leverages three types of timing variables in support of good documentation practice and auditability during data collection. A summary of these timing variables are as follows:

Item Data: Items marked as ‘datetime’ data type allow a user to input a date/time as an item value. 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.

Collection Time: Collection Time marks the date/time at which an activity occurred (i.e. when a blood sample was drawn or when a subject was interviewed about their medical history). Deviation windows and segment recalculations are based on Collection Time; and collection time is defined either as the date/time response to a ‘capture time’ item, the date/time at which a user clicks the save buttons, or by explicitly accessing Form Actions > Collection Time during data collection.

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.

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 pre­fill 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.

Open

Conditions for Scheduled Time Button

In order for the Scheduled Time button to be available during data collection, the following conditions must be met:

‘Allow Scheduled Time Button’ configuration must be set to ‘Yes’ within the Administration > General Settings component:

Open

The item’s ‘Capture Time’ configuration must be set to ‘Yes’ within the CRF Design > Study Library component:

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:

‘Default Timings’ configuration must be set to ‘Yes’ within the Administration > General Settings component:

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:

‘Default Timings to Scheduled’ configuration must be set to ‘Yes’ within the Administration > General Settings component:

The item’s ‘Capture Time’ configuration must be set to ‘Yes’ within the CRF Design > Study Library component:

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.

The ‘Collection Time’ field may be hidden from view during data collection by marking the “Hide Collection Time Field” setting as “Yes” within the Administration > General Settings > Data Collection module:

During data collection, the hidden collection time field may be made visible via Form Actions > Collection Time:

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.

As a note, the ‘Capture Time’ setting is required to be enabled against items containing a Sample Processing Path or a Lab Service Code.

Capture Time is enabled at the item level:

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.

As a note, the ‘Capture Time’ setting is required to be enabled against items containing a Sample Processing Path or a Lab Service Code.

Once again, Capture Time is enabled at the item level:

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:

The following transaction times may be associated with item data

• 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:

The following transaction times may be associated with item group data

• 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:

The following transaction times may be associated with form data:

• 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:

The following transaction times may be associated with study event data

• Subject Activation: date/time of activating a subject as part of the containing cohort assignment

• Data Creation: ‘study event data created’ in this example, this is the date/time at which the study event was made available for collection, either via activity plan activation, by reassigning unscheduled records across subjects, or by adding an unscheduled or common form during data collection

• Reassigning Data: ‘reassigning data’ in this example, this is the date/time at which unscheduled study event data is reassigned from one subject record to another subject record shared by the same volunteer