We realize that each Riffyn process is unique, so the needs for signing and auditing a process might change for each organization. Below is a simplified 21 CFR workflow that can be used as a starting point.
To maximize the value of the 21 CFR feature set, we recommend that a process is created brand new with the intent that all future work on the process (and its experiments) needs to be audited. Auditing is turned on by default for each process, as can be seen in the audit trail where the default "first step" added during new process creation is logged:
Starting with a new process eliminates the need to 'promote' an older process to a compliant state. This can reduce confusion during scenarios where the process would move from a 'pre-compliant' state to a state where compliance is required.
In this example process we can add user permissions after the process design is completed, or permissions can be added as the process is designed. In either scenario it is important to consider the roles of users in managing an audited process. In our imaginary organization we might have:
- Julie - compliance coordinator
- James - technical lead and process designer
- Samantha - senior technician and process designer
- Robert - technician
- Theresa - technician
- Stephan - compliance auditor
In Riffyn, we might assign user roles to reflect expectations for process execution and the user's role in the electronic signature process.
- Julie - Admin
- Julie can view/manage/add/approve signers to the process and related experiments.
- Julie can change process permissions and make edits to all experimental data.
- Julie can lock the process/experiments as part of the review process.
- James - Admin
- James has the same permissions as Julie, but is expected to design the process and manage the edits made by the technicians.
- Samantha - Designer
- Samantha cannot edit compliance settings for the process or experiments, but she can change the process design and create/edit experiments.
- Robert - Operator
- Robert can make new experiments and enter data only.
- Theresa - Operator
- Robert can make new experiments and enter data only.
- Stephan - Viewer
- Being a viewer allows Stephan to view progress of the process design and the experiments without being able to make any edits.
Electronic Signatures and Process Status
Similar to user permissions, our organization can configure the number of required signers on a process/experiment before or after execution is completed. In our organization, Julie might be in charge of adding signers and assigning them the meaning of their signatures per our organizations SOP. The signers of our document might be:
- Julie - who as the compliance coordinator has responsibility
- James - who is asked by Julie for authorship
- Samantha - who is asked by Julie for review
- Stephan - who is asked by Julie for approval
These signers will not be notified until the process/experiment is locked by the process admin (Julie). Locking the process/experiment will send an email to all signers asking them to sign the process (and prevent edits from being made until the process is approved, or the lock is removed). In this case, Julie is an admin and a signer as required by her role as compliance coordinator.
Once the process has been signed by the required number of signers, Julie and James will receive an email notifying them that the process is ready to be approved (all admins receive a notification email). Since Julie is the compliance coordinator, organizational rules require her to be the approver of signatures, not James.
After Julie has approved all signatures, the process will be versioned, marked as approved, and remain in a view-only state. James will need to make sure that his technicians only execute experiments on the complaint version that was approved by Julie (as per our organization's SOP).
Changes and Updates to Processes and Experiments
During the signing period, it is possible that changes need to be made to the experiment to correct an error. If data were entered incorrectly into an experiment, Julie would unlock the experiment to allow other users to make edits with the knowledge that unlocking the experiment would remove all existing signatures. Once edits have been completed it is up to Julie to lock the experiment to re-initiate the review process. The responsibilities of managing the locked state of the experiment are Julie's per our organization's SOP.
Experiments are made on a approved process version (per our SOP), therefore it is not possible to make edits to a process once it's approved. Documentation of process edits (and reasons) must occur on a new process version (working version and onwards) and will require a new round of signing and approval. Anyone with designer or admin permissions can make edits to the process's working version. Any existing compliant process versions will remain the same, but it is up to the user to create/execute experiments on the correct version should the working version be newer than the most recent compliant version.
In the version log, we can see some versions are not approved, and thus should not be used as part of a compliant workflow for creating new experiments:
Version 1.01 and Version 1.00 are approved versions that a user should execute experiments on as directed by their supervisor. Version 2.00 and the working version are unsigned and should not be used, since they are in an (potentially) intermediate editing state.
Experiments created on a compliant process version can be signed/locked in the same way a process can, with the additional modification that experiment locking triggers a data export. This data export - in conjunction with the data displayed in the UI - can be used by signers to determine if they are ready to sign the experiment. Experiments do not have versions, so an approved experiment will remain in a view-only state until unlocked by an admin.
Throughout the entire electronic signature, experiment execution, and process design workflows all actions taken by users are audited. The audit trail contains a certain set of Riffyn entities (listed here) so that all changes are tracked. Full details of each action taken by users can be viewed in the audit trail or filtered by a variety of options.
The audit trail is typically useful in two scenarios:
- When the designer or team supervisor wants to view process/experiment changes.
- When the compliance coordinator wants to see the edit and signature history of a process/experiment.
- When a regulator wants to perform additional audits on the process.
The audit trail is visible to all users, so even auditors to the process/experiment can view changes without needing permission to change the underlying design or data.
Future updates of the Riffyn 21 CFR package will include features such as data export, data auditing, and custom rules for data retention.
Should you have any questions on using this feature set or its implications in a compliant workflow please contact the Riffyn Scientific Consulting Team at email@example.com.