Empower Tip: Working Remote with Empower Software

In this tip, I have another special Empower tip when working remotely. Let’s learn how to use electronic signatures to approve results. (Also refer to Tip 159 for additional information on this topic.)

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

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

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.

Empower Electronic Signature Validation Supplement

Validation Supplement is available to guide you through the process to set up and implement 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 Electronic Signatures can be used 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 checking any policies with [GXP] or [ES] alongside.

An Administrator level account may be needed to set the System Policies, which are 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 can have the same name. Check the box for ‘Enforce Unique User Account Names’ on the User Account tab.

PLEASE 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.

PLEASE 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 to give approvers only ‘Sign Off 2’ privileges. (shown next)

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’. Users can be given 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 check the box for ‘Allow this method to be used for sign off’ otherwise signatures cannot be used with that report.

Review Thoroughly Before You Sign

Using electronic signatures to approve data brings a significant benefit for Data Integrity. By 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 that there are in fact 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 had been 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 have been detected in the summary report.