Future Enhancements

This page lists future enhancements we expect to make to the software in the near future.

FE-1: Add feature for simultaneously updating the same field in case study members chosen by the end-user
FE-2: Enhance Performance
FE-3: Improve error handling for configuration file errors

FE-1: Add feature for simultaneously updating the same field in case study members chosen by the end-user

Currently users may change one record at a time or make mass changes by importing log data from a spreadsheet. Tim Gaysin identified a need to be able to update an activity step for multiple case study members selected through the Logging Tool. The following sequence of diagrams describe how the feature will be implemented will appear to data curators.

Step 1: A new menu item "Batch Update" will appear in the Options menu. Note that the words "case study" and "case studies" are terms which are defined in the configuration file. Users will select this option to begin updating the same activity step in multiple records they specify.

Step 2: In the first step of doing batch updates, users will specify which case studies they want to update. This will either be done by manually typing in a primary key identifier or by loading a single column text file containing lists of identifiers.

Step 3: Once users choose the case studies to update, they will specify the activity step that needs to be changed and a date value.

Step 4: If errors are encountered, then the errors will be displayed to the user and none of the changes to the database will be made.

Step 5: If no errors are encountered, then a dialog will appear, indicating how many records were updated.

FE-2: Enhance Performance

The versions of the Administration and Logging tools which work with a fake in-memory database were only intended to demonstrate prototypes. They were not intended to manage large-scale data sets. However, it is clear that demonstration services can use a lot of memory. Memory consumption could be greatly reduced if TrialActivityModel were modified.

Currently, TrialActivityModel has properties which serve two purposes:

to maintain configuration properties which influence validation activities
to maintain properties used soley for holding activity data

These two types of properties were included in the same class for convenience. However, they should now be separated into two Java classes. TrialActivityModel should hold data but activities such as validation should make use of a new class TrialActivityProperties which would hold these properties:

orderPosition - which describes what place the tabbed pane for the activity should appear in the Logging Tool
displayName - the field name of an activity step that is presented to end-users.
allowBlankFields - determines whether a given activity allows a populated date field to be preceded by a blank one.
enforceChronology - determines whether the given activity expects that the date fields appear in a non-descending order.
maximumCommentLength - refers to the size of the VARCHAR(...) database field which stores the free-text comments users can specify for each activty of each case study member.

TrialSubjectModelFactory will be modified so that the instances of TrialActivityModel used to hold activity data will refer to the same TrialActivityProperties object. This would be a great improvement over the current system, where thousands of TrialActivityModel objects will maintain their own copies of configuration fields.

FE-3: Improve error handling for configuration file errors

A future release will have improved handling of errors generated by the ConfigurationManager when it reads a configuration file. In particular, error handling will be improved to make it easier for developers to detect whether CST had problems initialising their plugins.

Author: Kevin Garwood