Detecting, Saving and Auditing Changes

CST is able to detect, save and audit changes that users make to activity data. Monitoring changes made to subject attribute data (eg: attributes such as location, ethnicity, demographic) is not within the scope of development. When administrators load new attribute data, CST will overwrite any attribute data in existing records. Users of the Logging Tool may use the attribute data to filter subsets, but they are given no facilities for curating this kind of information.

There are three aspects of change management which effect activity data. Detection involves alerting end-users of the Logging Tool that they need to decide whether they should make changes before leaving the application or moving to another record. This aspect is only relevant when users are manually changing data through the GUI forms. When users import activity data from spreadsheets, CST commits changes without asking users for permission. When users change data via the data entry forms, code in the Presentation Layer marks and signals that changes need to be saved. Instances of TrialActivityView, each of which represents an activity form in the tabbed pane of the Logging Tool, visualises instances of TrialActivityModel to end-users.

The TrialActivityView comprises a number of AbstractFieldViews which are either instances of DateFieldView or CommentFieldView. These views register themselves with a SaveChangesMonitor whenever they detect changes made by end-users. Whenever users exit, change focus to another TrialActivityView or attempt to view another record, CST asks the SaveChangesMonitor whether it has any changed fields. If it does, users are asked if they want to commit their changes. Whether users decide to save their changes or not, the SaveChangesMonitor will clear its list of changed fields.

Should users decide to commit their changes, CST makes a call to call the LoggingServiceAPI method:

public void updateTrialActivityModel(User user, 
	TrialActivityModel trialActivityModel) throws CSTException;

Services implementing this method first attempt to validate the revised version of the TrialActivityModel instance managed in the form. Note that the services never assume that the client code which calls it will validate activity data. Therefore, even though the TrialActivityView has features for guiding data entry and preventing errors from happening, validation is done anyway. Should updateTrialActivityModel(...) detect an error, it throws a CSTException which is then caught in the GUI code of the Logging Tool. The error message is displayed to end-users and CST resets the TrialActivityView with the original version of the TrialActivityModel.

If the revised TrialActivityModel is valid, updateTrialActivityModel(...) then retrieves the original TrialActivityModel through a look-up based on the primary key identifier used to represent a subject. The method then passes original and revised versions of the same record to the following static method in TrialActivityModel:

	static public ArrayList detectTrialActivityChanges(String userID,						 			
		TrialActivityModel originalActivityModel,			  												TrialActivityModel revisedActivityModel,
		String dataSourceName);

The method systematically compares every field in one instance with corresponding fields in the other. Differences in values are recorded as a collection of TrialActivityChange objects which can then be serialised as audit changes.

Author: Kevin Garwood