Project History

Use Cases Scenarios
Use Case Requirements
Bugs and Known Limitations

User Manuals Getting Started
General Tour
Configuration Options
Logging Tool Tour
Administration Tool Tour

Developers Architecture
Analysis of Design
Creating Plugins
Future Enhancements

Use Case Scenarios

Clinical study coordinators and project managers are often burdened with too much data, and too little help. In small clinical studies or organisations where the budget is low, staffing and IT software solutions are at a minimum yet high quality results are demanded.

The Clinical Study Tracker was created by a team consisting of a clinical trial specialist, and meticulous software developer. Hence, the best of both worlds has had an opportunity to happen. As the clinical specialist I wanted to create the minimum amount of features on the software to get the job done.

Simplicity was paramount. I knew that the more complex the software the longer training time would be required for the user, and the more confusion it might cause. Hence, hindering the study instead of enhancing it. As a trainer, I also knew that not all users were equal. The software needed to be workable for someone with minimal computer skills. I believed this to be important especially for clinical studies to easily expand to worldwide communities.

The software was designed so that most staff could be trained in about 30 minutes. Any project that involves multiple streams of activities, varied arrival times, and different process steps to complete is ideal for the Clinical Study Tracker. Its purpose is to track dates of completion and to generate simple progress graphs, although more complex analysis is possible by exporting the data into a spreadsheet.

The software developer has designed the Clinical Study Tracker so that it can maintained, re-used, and amended by a technical person who is not a software developer. He has provided an extensive set of documentation and testing to assist the both user and the technical person. This makes the Clinical Study Tracker a simple and reliable tool to get the job done.

Although CST was designed for clinical studies, it is not limited to these. For instance, it may also be suitable for additional scenarios such as tracking of childhood vaccinations for example. Where the ‘activity’ would be the type of vaccination required, and the ‘process step’ would be the date the first dose was given, the second dose, and so on. The software tool could easily generate reports such as how many children in the area have received each vaccine and dose to date. Perhaps in small remote clinics, the person who gives the vaccine could also be the ‘identified user’ who logs it onto the Tracker. If this system was adhered to, then the software could generate a list indicating which ‘identified user’ gave the vaccine to each child and hence produce an audit trail for the clinic if needed.

In addition, a remote medical clinic may choose to have several copies of the Clinical Study Tracker each set up to track a variety of different ongoing medical programs for patients.

What’s involved?

Phase I: Rapid Prototyping

  1. Users download the software.
  2. Users begin the rapid prototyping phase of using CST along with their IT administrator or technical person. This is done by clinical users first identifying their key activities and process steps they wish to track.
  3. Through the use of the exemplar configuration files that come with the release, they can create and test their own clinical study tracker using a fake database in the software.
  4. Users and IT administrators can quickly see their design changes through the demonstration tool which interacts with a fake database.
  5. When CST is run in demonstration mode, it doesn't require MySQL to be installed. Therefore project staff can run their demonstration on a simple USB drive without having to worry about what other software is installed on the computer they use.
  6. If you wish to simulate more realistic data, you can use the Demonstration Administration Tool to load some of your subject attribute data from a spreadsheet. For example they may have a tab-delimited text file with columns for "Patient Number" and another for "Location".
  7. When you have finish prototyping, you can choose to start using your newly designed Clinical Study Tracker in your actual clinical study environment. This requires that you go onto Phase II: Using CST in Production.
  8. Use the Production version of the Administration Tool. Create the database.
  9. Load

Phase II: Using CST in Production

  1. Users will download and install MySQL v5.0 or higher.
  2. Use the Production version of the Administration Tool to create a MySQL database based on activities defined in the configuration file.
  3. Load information about the subjects or participants from a tab-delimited text file. Each row should have a column for a primary key identifier and columns for each filter attribute.
  4. Create user IDs for people who will use the Logging Tool. This facilitates an audit trail.
  5. Users will use the Production version of the Logging Tool which uses the database created by the Administration Tool.
  6. Users can update records manually or import log data for activities from tab-indented spreadsheets.
  7. Users can easily generate progress reports or graphs.

Part III: Enhancing CST

Have your developers look at the section on creating plugins.

Phase IV: If you need to stop using CST

  1. Users would use the "Export Subject Attribute Data" feature in the Administration Tool to export subject attribute data to a tab-delimited text file.
  2. Then users would use the Export feature in the Logging Tool to export data for each activity.
  3. Data in the tab delimited files are linked by the use of a common primary key for identifying subjects.
  4. Exported text files can be loaded into spreadsheets or imported by other applications.

Author: Sheila Raynor

(c)2010 Medical Research Council. Licensed under Apache 2.0.