How to use Electronic Signatures to approve results - Tip171

OBJECTIVE or GOAL

With the increase in remote working during 2020, many organizations are struggling with approving data, especially if they have previously relied on handwritten signatures appended to printed reports. The UK regulator MHRA recently issued a blog on this topic that includes examples of handwritten signatures as remote approvals.

With Empower Software in your lab, you already possess an electronic signature capability that includes all the controls needed for a GxP-compliant.

Electronic signature functionality is integral within the Empower Software base license and does not require any special activation. Signatures can be applied to any Report Method set for Sign Off by any user with signature privileges. 
 

ENVIRONMENT

• Empower Software

PROCEDURE

Empower Electronic Signature Validation Supplement 
Available FREE from Waters Marketplace (marketplace.waters.com). This Validation Supplement is available to guide you through the process of setting up and implementing electronic signatures in your organization. It includes a set of Electronic Signature Requirements, a formal test script to verify those requirements, and a Requirements Traceability Matrix to map the test steps to the requirements. 

However, there are numerous System Policies that must be set before you can use Electronic Signatures in a compliant manner. For regulated companies, it is a choice of how these are set and if there is any uncertainty as to the correct settings, Waters recommends reading any policies with [GXP] or [ES] alongside.
You may need an administrator-level account to set the System Policies set from the Configuration Manager screen, menu option View > System Policies.

Unique User Account Names
It is essential for Data Integrity, particularly electronic signatures, that each user has an individual user account in their own real name and that no two user accounts have the same name. Select the box for Enforce Unique User Account Names on the User Account tab (figure 1). 
NOTE: The other settings on this tab are focused on account security and should be set in line with internal company policy. 

Result Sign Off 
There is a tab on System Policies dedicated to settings for Result Sign Off (figure 2).
NOTE: These should be set in line with company preferences with the [GXP] and [ES] labels there for assistance.

The only item not marked with a [GXP] or [ES] label on this tab is the Require Sign Off 1 and Sign Off 2 by Different Users option. This option is one way to prevent users from approving their own work. The other way is to give analysts only Sign Off 1 privileges and approvers only Sign Off 2 privileges.

 

Assigning Signature Privileges 
The ability to apply an electronic signature is governed by two privileges on the Methods tab of User Type ES_Signature_Type Properties (figure 3). Users can have one or both privileges.

Creating Report Methods for Sign Off 
Signatures can only be applied to Report Methods set for Sign Off. Creating such a Report Method requires the user privilege Specify Report Methods for Sign Off, contained on the Method tab of User Type Properties.
When creating a new report method, it is essential to select the box that says "Allow this method to be used for sign off". Otherwise, signatures cannot be used with that report (figure 4). 

Review Thoroughly Before You Sign
Using electronic signatures to approve data brings a significant benefit for Data Integrity. Having the reviewer logged into Empower to sign encourages proper, detailed, and effective data review on the original electronic data, instead of relying on just a printed summary report containing only the data elected for that report.

EXAMPLE: A summary report may show that all components were within limits for a given sample. Accessing the Channel tab in the Project and using View As > Results for the channel selected shows three results generated from the channel data for that sample, with only the third result reported. 

Comparing the chromatograms and peaks tables shows that the baseline was manually adjusted across the three results as follows:
•    The first result had an API peak that gave a % label claim below the limit.
•    The second result had the API peak giving a % label claim just below the limit.
•    The third result had the API peak giving a % label claim just above the limit.

The original baseline on the first result (as applied by the approved automated processing method) was perfectly acceptable across the peak, start and end. Looking into the audit trail in the Project, there was no reason recorded to explain why the baseline was adjusted. This is most likely deliberate data manipulation to bring the result within specification and would not be detected in the summary report. 
 

ADDITIONAL INFORMATION

This content can also be found in the Empower Tip of the Week blog post Tip #171.