SignalBox¶
Overview¶
SignalBox is a web application application designed to make it easy to run clinical and other studies. Signalbox makes it easy to recruit, take consent from, and follow-up large numbers of participants, using a customisable assessment schedule.
Participants can provide self-report data via email, telephone, or SMS message. Study coordinators can login to a secure administration website to manage studies and check participation. The admin interface integrates online and offline elements of a study; researchers can enter addtional datapoints collected offline or in the lab, and there is full support for double entry and reconciling of paper-based data, and also for audit trails of changes to participant data.
Signalbox was designed to replace the numerous, ad-hoc systems which have been developed by research groups, providing a flexible, secure, and well-tested system. The software has been independently audited, and used in many numerous studies, including a large, MRC-funded clinical trial (http://www.reframed.org.uk).
Functional anatomy¶
Below is a description of the data model used by the system. In essence, all capitalised words are tables in the database; the text below helps describe their structural and functional interrelations.
Core components¶
A Study is lined to a number of StudyConditions which can each use a number of Scripts. A Script links to an Asker (a questionnaire) which includes a number of Pages that contain Questions. Questions can use a ChoiceSet which represents a set of Choices which define the range of allowed Answers (e.g. as part of a Likert type scale). Alternatively, Scripts may define an external url at which participants will enter data (e.g. a bespoke experimental task, or via a third party service like SurveyMonkey).
When a User joins a Study then a Membership is created, which stores the randomisation times etc. When a Membership is randomised to a StudyCondition then the Script is used to create Observations (scripts use a special syntax to describe the offset at which each Observation will be created, by default counting from when the user is randomised).
When Observations are due then they are executed by a background task, causing an email, SMS to be sent, or a phone call to be made. In responding, users create a Reply to the Observation: A Reply consists of multiple Answers, which represent responses to individual questions. Because a Reply might be interrupted or left incomplete, multiple replies can be made to each Observation (which the administrator needs to remember when the data are exported; they can chose a particular Reply to use by marking it as canonical).
The diagram below represents the core constructs within Signalbox (but is not complete... see below).
Questionnaires and collecting data¶
As noted above, Askers contain Pages which in turn contain Questions. Some questions may also refer to Instruments, which represent a bundle of Questions which are commonly shown together (e.g. a psychometric scale). When a questionnaire is displayed, ‘instrument’ questions automatically include this group of questions on a single page. See the diagram below:
Additional components which may not always be used¶
Script``s generate Observations, but can also generate Reminders for those Observations, and these send an additional messages to users at intervals after the Observation falls due.
Scripts can also have ScoreSheets attached to them, which are sets of rules which describe how a set of Answers in response to the Script’s Asker can be reduced to a single number (e.g. the mean or total for a set of Questions). ScoreSheets create scores which can be viewed for a particular User (e.g. to check whether a user meets a criteria for study entry from a screening questionnaire). ShowIfs are rules which evaluate to a boolean (yes/no) based on Replies Users have previously made (or Replies that are in progress). ShowIfs can be used to determine whether a particular Question should be shown based on previous responses. They can also be used to create new Observations based on a Reply, using an ObservationCreator. For example, if a User completes a depression questionnaire (Asker) and a ScoreSheet computes they have scored above a certain threshold, then an additional Observation could be created and a followup email sent.
Users are linked to a UserProfile which can contain additional fields like a telephone number, address etc. A Study can specify the subset of these fields which are required when a user signs up. ContactRecords are made when the administration interface is used to send a User a message. In some studies, its necessary to collect data from some Users (e.g. therapists) about other Users (e.g. clients); where this is the case a Membership can store an additional field indicating which User the data is about, as well as who it has been collected from
StudySites represent different locations in a multi-site trial, can can be used to filter Memberships when viewing date.
Database schema¶
In addition to the simplified diagrams above, the database schema for the Signalbox and Ask apps may also help clarify the structure of the application:
Download Signalbox app schema .pdf
Note
Required fields in the database are displayed in bold
Technical overview¶
Signalbox is based on a number of excellent open source software projects. It was written using the Django web framework (i.e. in Python), and uses either an sqlite or a postgresql database (postgresql is strongly recommended). Configuration is provided to quickly host an instance using Heroku (a cloud-based application host, see http://en.wikipedia.org/wiki/Heroku), although self hosting is also possible.