When you return to edit a section of an event CRF that you (or somebody else) has previously saved, you will notice some differences in the display and behavior of the form versus entering data on a new event CRF.

Deletion of Previously Saved Repeating Group Rows Not Allowed

If your form uses repeating groups, the most noticeable difference is that you will no longer be able to delete previously saved rows from the grid using the ‘X’ icon at the end of the row. OpenClinica 3.1 has eliminated the ability to delete repeating group rows for records that have already been saved to the database. If a row needs to be removed, you must change all the item values to blank for that row. Newly added rows can still be deleted, provided they have not yet been saved.

This behavior, introduced for repeating groups in version 3.1, helps OpenClinica maintain an audit trail that allows users to trace back all changes that have occured in the data. While it has some usability drawbacks, it provides a much needed improvement in the integrity and traceability of data values. The purpose of the audit trail is to be able to reconstruct the data as it looked at any point in time. The audit trail is one of the cornerstones of compliance to 21 CFR Part 11, and ensuring a complete and robust audit trail is necessary to make it possible the adoption of OpenClinica for regulated applications. The row will always display, and the audit records and discrepancy notes associated with the items in that row will be traceable in manner that is compliant with regulations and good clinical data management practices.

Consider the case of an Investigator that reviews and signs a CRF after confirming the CRF’s values in a repeating group. After a certain time he goes back to the same CRF and finds that the CRF has been further edited, which may require review and re-signing. In OpenClinica 3.0, the method of deleting rows from the CRF so they are no longer viewable or traceable to entries in the audit log means he will have no means to understand what changes later occurred to the data, when they occurred and under whose responsibility. Addition of records to the repeating group have no trace (and thus they are not attributable to someone), removals were traced as change of state from Available to Removed, but no evidence of the formerly existing values was provided. This is critical because he has signed the CRF as a “whole record” and the addition or removal of sets of data in this whole record really is a change of that record. Providing detailed information on what has changed since the signing event is now possible based on the audit trail, and provides the investigator with a means to identify what has changed since the signing as part of his review.

User Required to Provide a Reason for Change

The other major difference in behavior applies only after the CRF has been marked complete and only if the study is set up to require ‘Reason for Change’.

In this scenario, if you make any changes to CRF data (including adding new rows to a repeating group) after it has been marked complete, you will be required to enter a discrepancy note indicating the reason for change.

As of OpenClinica 3.1.3, changes in the values of calculated fields do not require a reason for change. Note that if the calculation cannot be computed (such as division by zero) the reason for change message will be displayed, however the form can be safely submitted without a discrepancy note.