- Published
- Updated
An automatic device-app update may not reach every study user at the same time. A project-level release date cannot establish which functionality produced an individual measurement. Plan participant-level version traceability.
Define the assessment
Identify changes to measurement, display, transfer and user actions. A bug-fix label does not establish absence of impact. Assess technical verification separately from comparability of study data. Consider distribution and rollback arrangements within the investigation’s authorised change process.
Worked example
For example, a new app version records timestamps differently. Some offline phones retain the old version. The team does not classify all observations after release as new-version data. It links versions to measurement times, tests date conversions and explains analytical handling of the mixed-version period.
Practical checks
- Define how the installed version will be linked to a measurement or session record.
- Assess effects on critical workflows through representative testing.
- Reconcile mixed-version periods and failed distribution attempts with participant records.
Decision and limitations
Acceptance depends on preservation of intended study functions, not merely the app opening. Any record conversions introduced by the update should be explainable. Retain original values, transformations and reasoned decisions instead of silently altering historical data, and disclose uncertain version intervals.
Frequently asked questions
- Does a minor update need no assessment?
- Its label or size is insufficient. Assess effects on investigation functions and data.
- Does release date establish installed version?
- No. Distribution, offline use and failed updates can create different transition dates.