Computational protocol: Development of a video-simulation instrument for assessing cognition in older adults

Similar protocols

Protocol publication

[…] The development process can be divided into 3 phases: initial design and prototyping (alpha version), pilot study (beta version), and validation study (release version) (see Fig. ). The small pilot study in phase 2 established the feasibility of the assessment tool and identified areas in which the instrument as well as its administration could be improved. Phase 3 included a full-scale validation study with a larger sample of participants and led to the creation of a final version of SIMBAC intended for release.Fig. 1 [...] Three geriatric health care providers (S.R., K.S., V.W.) identified 5 activities that (a) were cognitively demanding, (b) were relevant to everyday life for most older Americans and (c) could be simulated on a computer. They were: recognizing faces, remembering names, filling a pillbox, using an automated teller machine (ATM) and refilling a prescription by phone.Based on input from the geriatric team, a computer programmer (R.B.) developed a prototype of the 5 SIMBAC modules. The software was written in ActionScript 3 and used the Apache Flex software development kit (SDK). Configurable aspects of the tool engine and individual modules were specified in easily-editable XML files. User-facing strings (e.g. instruction text) were also externalized into XML files. The build and deployment procedure was automated using Apache Maven and Apache Ant. The instrument’s visual assets were variously designed and assembled using Adobe Flash, the GNU Image Manipulation Program (GIMP), and Inkscape. The verbal auditory assets were recorded and edited using Apple Logic Pro.In the course of designing the instrument, the order and character of each module underwent numerous variations and iterations, and it was often helpful to be able to demonstrate a single module in isolation while gathering feedback. We also observed that, though the content of each module differed in many ways, there were also significant commonalities: each module presented instructions, collected timing and interaction data, and was subject to behavior and content modification at runtime via configuration files.These observations motivated one of the key design decisions of the instrument’s implementation. The behavior and functionality that was common across all of the modules was implemented in a Task class, with each module being represented by a separate subclass of Task: PhoneTask, PillboxTask, ATMTask, etc. At runtime, an instance of another class, the TaskRunner, runs each module through its complete lifecycle: instantiation, configuration, presentation, result collection, and termination. The order of the modules is defined in an external configuration file, so changing the order of the modules--or using only a subset for demonstration purposes--is as simple as swapping the a few lines of text.External configuration files also contained the task design for each module, including order of data presentation, duration of stimulus, instruction text, etc. For example, the ATM task externalizes, among other things, the account PIN, the amount of money to withdraw, and which account to withdraw the money from. The instruction text in the configuration files can also reference these settings using string interpolation (e.g. “Your PIN is ${pin}.”). This ensures that the instructions presented to the participant is always consistent with the configured settings since each setting is specified in exactly one location. […]

Pipeline specifications

Software tools SimBac, Inkscape
Applications Miscellaneous, Population genetic analysis
Organisms Homo sapiens