2  LAMP Platform

Spark is a fork of the LAMP platform. The following is a brief explanation of the LAMP platform.

LAMP platform

2.1 Object model

  • Zero or more researchers (Researcher/Investigator)
  • Have one* or more groups (Study/Group)
  • To which zero zero or more respondents (Participant/User) can be attached
  • Zero or more activities (Activity) can be attached to a group
  • Zero or more sendors (Sensor) can be attached to a group

*When a reseacher has 0 groups, the platform will load endlessly.

mindLAMP Data model

  • ActivitySpec: (global) a representation of an interactive user interface that can be presented to Participants.
  • SensorSpec: (global) a representation of a physical hardware sensor that can be used to passively collect data on a device owned by a Participant.
  • Researcher: encapsulates access and control of multiple Studies.
    • Study: encapsulates the assignment of Activities and Sensors to Participants.
      • Activity: activates, configures, and optionally schedules, an interactive activity for the Participant to use, and optionally, receive notifications for.
      • Sensor: activates and configures a hardware sensor on the Participant’s physical device for sensor data collection.
      • Participant: encapsulates the storage and retrieval of ActivityEvent and SensorEvent data streams.
        • ActivityEvent: a chronologically ordered timestamp-indexed packet of data synthesized from the Participant’s interaction session with an Activity, containing temporal slices representative of each tap or action within the session.
          • Note: this object is owned both by the Participant AND the Activity, and so it is possible to query the data either cross-Activity for a specific Participant OR cross-Participant for a specific Activity.
        • SensorEvent: a chronologically ordered timestamp-indexed packet of data synthesized by hardware sensors on a physical device being used by Participant.
          • Note: this object is owned both by the Participant AND the Sensor, and so it is possible to query the data either cross-Sensor for a specific Participant OR cross-Participant for a specific Sensor.

Though the above hierarchy is described in terms of object composition, that is, in a manner similar to files recursively nested within several folders, it is important to distinguish and describe a form of object inheritance used by Spec/*/Event data types.

  • ActivitySpec/SensorSpec: similar to apps on an App Store, the Spec object describes the schema for input (configuration) and output (data) for an interactive activity or a hardware sensor.
    • Activity/Sensor: this object can be thought of as an ‘instance’ of a Spec object assigned within a Study, with a specific name, icon, schedule, customized parameters, and more.
      • ActivityEvent/SensorEvent: represents an ‘event’ as part of a time series event stream recorded by the Activity or Sensor.

2.2 Activities

Activities supported to date: Activities currently available on LAMP

Activities include:

  • Surveys, self-formulated questionnaires.
  • Smartphone Cognitive Tests, neurocognitive assessments in the form of games. These are displayed on the Assess page of the app, and performance scores can be displayed on the Prevent page, Cognitive Games and Assessments .
  • Miscellaneous, other activities such as breathing exercises, journaling, etc.

It is also possible to cluster multiple activities so that they can be performed sequentially by the respondent, Clustering Activities on mindLAMP.

Add activity through import (N.B. in json format and b64 encoded): Activity types

2.3 Adding respondents

For now, an account must be created manually for a respondent: Create or Manage Patients and Participants

Once a new respondent is created, they can log in using a QR code: Log In Information, Tips, and Tricks

2.4 Sensors

Sensors supported to date: Sensor Types

2.5 Data model

LAMP Data model

The diagram represents the structure of the LAMP’s database. Both Participant and Researcher represent users of the LAMP platform. A Participant is a participant in a Study. A Researcher can create and edit a Study, a specific Study belongs to a specific Researcher.

Participant and Researcher can have multiple Credential, thus allowing different users to login with different credentials for the same account instance. The ‘origin’ field in Credential is the foreign key referring to either a Participant‘s or a Researcher’s ‘id’.

Multiple Activity, Sensor and Participant instances can be attached to a Study. So a Study allows us to conveniently group Participant instances, furthermore allowing the grouped Participant instances to interact with the assigned Activity and Sensor instances.

Regarding ActivitySpec and SensorSpec: a Spec object describes the schema for input (configuration) and output (data) for an interactive activity or a hardware sensor.

Activity and Sensor can be thought of as an instance of a Spec object assigned within a Study, with a specific name, icon, schedule, customized parameters, and more. ActivityEvent and SensorEvent represent a ‘event’ as part of a time series event stream recorded by the Activity or Sensor.

ActivityEvent: a chronologically ordered timestamp-indexed packet of data synthesized from the Participant’s interaction session with an Activity, containing temporal slices representative of each tap or action within the session. (Note: this object is owned both by the Participant AND the Activity, and so it is possible to query the data either cross-Activity for a specific Participant OR cross-Participant for a specific Activity.)

SensorEvent: a chronologically ordered timestamp-indexed packet of data synthesized by hardware sensors on a physical device being used by Participant. (Note: this object is owned both by the Participant AND the Sensor, and so it is possible to query the data either cross-Sensor for a specific Participant OR cross-Participant for a specific Sensor.)

2.5.1 Regarding sub-accounts:

Currently only an Admin is able to create new Researcher accounts, so also future Supporter, Editor and Analyst accounts. Do we want to let researchers create these sub-accounts (Supporter, Editor and Analyst)? So that researchers can attach these new accounts to a Study? Arrows indicate ability to create, edit and delete an account-type. Everything in red is preliminary and not implemented yet.

LAMP platform