Configuring Empower 3 for Data Integrity and Regulatory ... · Data Integrity and Regulatory...

©2017 Waters Corporation 1 COMPANY CONFIDENTIAL

Configuring Empower 3 for

Data Integrity and Regulatory Compliance

Arjan Timmerman


Disclaimer

This presentation is for informational purposes only and should not be

taken as advice regarding any particular course of action to be followed.

Waters does not make any representations or warranties, express or

implied, to any party, regarding use of the information contained in this

presentation to make decisions regarding the implementation and

maintenance of effective quality control systems and quality assurance

testing programs, including but not limited to the applicable Good

Manufacturing Regulations that apply to the manufacture of regulated

products.


Design your Process

First …..design your ideal process

– Look at current User roles & responsibilities

– Look at current workflow processes

– Look for bottle necks

– Look at current calculations

o Eliminate non compliant spreadsheets

o Eliminate paper worksheets

o Eliminate hand calculations

Ask for input from Users

Use outside help to design a process

– Fresh pair of eyes

– Vendor support using previous experience in similar industry

– Employees with experience in previous employment

1

2

3 4

5


System Policies

Default Strings

Roles and Responsibilities

User Privileges

User Accounts

User Groups

Project Setup

Method Setup

Complete data

Custom Calculations

(= Separate Demo)

Audit Trails

Result Audit Viewer

Electronic Signatures

Reporting

Archiving & Securing Data

(= Separate Demo)

Agenda – Empower Settings


System Policies are labeled,

designating Waters recommendation

for policies that should be invoked for

– GxP_

– Electronic Records

– Electronic Signatures

However it is the user interpretation

that is important!

Empower System Policies





– GxP_




that is important!



Default Strings are key to using same comments and proper reasons WHY

Reasons WHY for ~23 categories to be filled (2 categories are for Sign Off)

It helps the user identify the reason WHY a change was proposed

Reasons WHY are hard to write down!

– Remember the who, what and when is already capture by the system

Default Strings


Roles / Responsibilities & Access

The process

Regulated Company

System Owner

Analysts

Reviewers

IT Quality

Vendors / Consultants

Department Manager


Use an overview

sheet to identify

the differences


User Types


Identify an additional level of

access and control to projects

and systems


User Groups




and systems


User Groups



Unique User Accounts


Empower Projects are folders used to organize chromatographic studies

Establish Name Convention

– Customer Name, Site Name, Assay Name, Compound, System Name, Analyst

Name

Determine how long an active Project will be available to receive new

samples

– Think also about the time for Processing and Reviewing the data after locking

Decide what to do with inactive Projects

Develop an archive schedule

Project Management


What criteria is best to search for data?

– Examples are by date, lab, compound, batch, calculation type, project, shipment,

tanker, customer, lab book, analyst, system

How many projects

– Monthly

– Quarterly

– Yearly

How many samples would go into each project per month?

Over what time period / which projects would you need to compare data –

stability projects ?

Key Questions when creating project structure


Project Management & Access

Use the Project Wizard to create new projects

– Based on a template project

– Based on previous months project

– Can only be created one by one

Use the Clone project feature

– Copies project structure, methods and preferences

o Quicker and less room for error (what to select where)

– Can create multiple projects at once

– Need good templates

o Containing correct structure and methods with correct naming strategy


The privilege to lock and unlock channels are separate so control of when

results are reprocessed can be controlled.

Different locks are possible



Access Rights Explained

Relationship

User – Group – Type – Project – System – Node

More than one User Type may

be given to a User

More than one User may have access

to Project / System / Node.

User Groups may have Group Admin

- Management

- Methods

- Data Acquisition

Users

User Types

User Groups

Projects

Systems

Nodes

Privileges Contain

Are assigned to

Are part of

Access to

as owner

Access to

as users own type


Make sure the privileges for creating, adjusting and copying methods is set

properly

Methods


All the data….. Is it complete?

Multiple Analysis

Initial Sample Set Result Set Result(1)

Project A

Project B

A well defined SOP for processing will help, but does that project show all

the data?

Technical controls (project access and project/method creation) are

important

Sample Set

Result Sets

Result(3)

Result(2)

Result Set Result(1)

Data is

Reported

Data is not

reported or

addressed



Re-Analysis

Repeat Sample Set

Result Sets Result(1)

Sample Set Result Sets Result(1)

Outlining the process in an SOP can provide a clear UNDERSTANDING

for users, reviewers, and auditors WHY multiple analysis may be required

and HOW to document that process



Multiple Processing

Outlining the process in a SOP provides a clear UNDERSTANDING for users, reviewers, and auditor

Data review is more effective with an outlined process and determine if there is a problem

Sample Set

Result Set Result(1)

Result Set

Result(2)

Result(3)


Acquiring Samples SOP

Test Injections: System Readiness checks

– Define ‘WHAT’ they are:

o Never Samples

o Possibly a standard

o An independent solution which mimics real samples

– Define ‘HOW’ they will be used:

o Never delete them

o How is it assessed visual check, calculations performed, reported or not

o How do you proceed when it doesn’t meet the criteria

– Define ‘WHEN’ they will be performed:

o Every run, when runs are not successive

o As part of the sample set, as individual injections

System Suitability: As part of the Sample Set/Result Set

– If System Suitability fails… or “just” passes define the next steps

o should you continue the run, repeat from the beginning with justification


FDA are being trained that multiple results indicate that users are trying to

reintegrate into acceptance.

However, this conclusion can only be confirmed by looking at the actual

integration for each iteration

– Good documentation of “why” you reprocessed is essential

– Getting it right first time, all the time, is unrealistic

o If it data looks too good, it probably is

Review of audit trails and all result versions are advised

What is the “right” integration?

– SOPs and training should define this for each method

Existence of Multiple Results / Channel


Which Integration is better?

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5



Not Good Integration

Good Integration

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5



Pass Fail


Good Integration

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5



Manual Processing Method

Pass Fail


Good Integration

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5




Pass Fail


Good Integration

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5




Pass Fail

Manual integration isn’t always bad

Automated processing methods could easily be used

to manipulate integration


Good Integration

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5




Pass Fail


Good Integration

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5

1.2

49

2.1

32

AU

0.00

0.01

0.02

0.03

0.04

0.05

Minutes

0.5 1.0 1.5 2.0 2.5


Data Review SOP suggestions

Should be performed on ELECTRONIC data in the application at least at

Peer Review level

– Not relying on paper / PDF or Empower reports entirely

Define a Process

Look at final results (summaries, averages, CofA)

– Work back through the data from final quantitation, to areas and integration to

Sample Set meta data to audit trails

Specifically focus on suspect data

– Define a list of warning signs..

o Manual integration / multiple results / metadata changes

o Results that only just meet specification


Custom Fields

Build in functionality – 6 Fields, 6 Data Types

Separate Demo on this


The Automated Process

Chromatography to Calculations


Automated Calculations....

Dissolution

Integrity of your HPLC dissolution testing Combined software and hardware solution OR SOFTWARE ALONE for calculations

% Dissolved automatically

calculated Accounts for

transfer volume, replace media etc

Q Factors assessed

For online and offline Dissolution


Audit Trail

Project Audit Trail

– Gives overview of all changes in a project

– Includes details of method / data deletion

System Audit Trail

– shows changes to system objects and system policies

– details archive activity

– notes all changes to security (users, user types etc)

– documents all successful and unsuccessful logins

o you have a history of who was logged into the application at any time

o you have information about system break in attempts

o includes the client the login/login attempt occurred at


Audit Trail – Project Set Up


Reviewing Audit Trails – Why ?

Why?

– To uncover possible cases of fraudulent behaviour

o Multiple processing data

o Altering metadata to make results pass

o Hiding or altering meta data on reports sent to QA

o Uncovering persistent suspicious behaviour around security of data

o Ensuring only authorised users have access to certain functionality

o Deletion of data

o Altering system policies /configuration / settings without change control

procedures


Reviewing Audit Trails – How ?

Review audit trails as part of data review SOP

– Find anomalies before batch release

– Focus of user behaviour that affect results

– Peer Review / Manager review / QA review?

Periodic Review of overall Audit trails as separate SOP

– Looking for system level activity without correct documentation, change control,

testing or approval

o E.g. changing system policies, user access or deletion of data

Biggest issue: Audit trails generally may often be more a log of all activity

(to comply) and are not always designed for easy review

– But it is expected that inspectors will look at the audit trails

– Adding Audit trails to reports is not practical or sufficient


Empower Review Tool


Audit Trail summary

System Level

System Audit Trail

Archived System Audit

Trail

Project level

Summary level audit trail

Methods

Sample Set

•History

•Compare

•Sample History

Instrument

•Audit trail

•Compare

•Acquisition Log

Processing

•Audit trail

•Compare

Result Sets

Chromatograms

Calibration Curves

Individual results

Manual results

All calculated peak values

Signed off Reports

Summary of Results

Created by Empower

Verify against e-data

What was approved

Display links in

Review and

Result Audit Viewer


Audit Trail summary

System Level

System Audit Trail

Archived System Audit

Trail

Project level

Summary level audit trail

Methods

Sample Set

•History

•Compare

•Sample History

Instrument

•Audit trail

•Compare

•Acquisition Log

Processing

•Audit trail

•Compare

Result Sets

Chromatograms

Calibration Curves

Individual results

Manual results

All calculated peak values

Signed off Reports

Summary of Results

Created by Empower

Verify against e-data

What was approved

Display links in

Using View

As….


Audit Trail - Reviewing

Audit trails tell us WHO did WHAT, WHEN and WHY (when defined by

the user comments)

They have two primary purposes:

– Give a history to the data, to help decide if it can be trusted

– They should deter wrongdoing

o Without review, they are not a deterrent

Review audit trails as part of data review process

– Find anomalies before batch release

– Focus on user behaviour that affect results

– Peer Review / Manager Review / QA Review

Periodic Review of overall/system level audit trails

– Review system level activity

• Changes to system policies, user access, deletion of data


Result Audit Viewer Tool



One Stop Solution:

• Project Audit Trails

• Method History and Differences

• Sample History

• Sample Set History

• Acquisition Log

• Injection Log


Electronic Signatures in Empower

Applied to Reports to mimic the paper based process

SOP defined meaning for Sign Off 1 & Sign Off 2

Set appropriate system policies

– Designed based on regulatory requirements & customer feedback


Make sure the privileges for creating and adjusting Reports is set properly

Having everybody creating reports...

– What is shown on the report?

– Do you rely on these results?

– Are you using electronic signatures?

– Do you need to insert audit trails?

Reports

S02 = Problem calculating baseline noise, not enough baseline.


Do you archive your Empower Data?

For now, only Questions!

But separate demo later.


Do you Archive your Empower data?

There is a difference between Backup and Archive!

– And you need to have both

Backup might be arranged by IT department

– Do you regularly check your backups for recovery?

– Do you have a disaster recovery plan?

– Is this process validated?

– Is your backup taking a long time?

Guidance on Backup

– EU and PIC/S Annex 11 describe in: Section 7 Data Storage

– MHRA guidance describes: in Data Retention section, Backup

– FDA guidance describes: in Question 1 (a)

– WHO guidance describes: in Annex 5 Retention of Original Records


Do you Archive your Empower data?

What about Archive?

– Do you Archive the Empower Data? And System Audit trail?

– How? Who? When? Where (location)?

– Is this process audit trailed?

– Do you keep indexes?

– If so, do you check restore when you upgrade the software?

– Do you delete your data when needed (data retention)?

– Is all described in your SOP’s?

Guidance on Archive

– EU and PIC/S Annex 11 describe in: Section 17 Archiving

– MHRA guidance describes: in Data Retention section, Archive

– FDA guidance describes: in Question 1 (a), a bit cryptic

– WHO guidance describes: in Annex 5 Retention of Original Records

www.waters.com/waters/library.htm?cid=511436&lid=134872580

http://www.waters.com/waters/library.htm?cid=511436&lid=134872580


Empower 3

Compliance for an FDA audit

Inspectors want to see that you have implemented the controls that

Empower provides for you

– Unique Usernames for audit trails

– Default strings for reasons WHY you change objects

– Password expiry and history

– Limited access to delete objects in the database

– Audit Trail review

Outside Empower procedures are as important

– Training

– Daily Backup of data & Long Term Archiving

– SOPs for Acquisition, Review, Reporting etc.

Validation of the entire system, including software to demonstrate

“ fit for intended use” based on a clear URS is a key aspect

– Including a clear Change Control procedure


Summary

DON’T share accounts or passwords

DON’T provide delete privileges to users

DON’T disable the audit trails

DON’T hide or exclude data

DON’T forget to backup your data

DO review data and audit trails

DO perform and record training

DO use a change control process

DO create Standard Operating Procedures

DO select compliance-ready systems

DO train users and prepare your response for

multiple analyses

multiple results

review of ALL data including Audit Trails

Comment Library for the Empower Default Strings

These are examples (Check if they apply to you)

All Methods

for initial creation

for switching back to a previous version of saved method

for use in other project

Component Names

RRT x.yz

Product 1 (remark: this can be a real product name)




Custom Fields


for wrong formula used

for change in translation definition

Deletion Comments (remember, deletion is a privilege…)

for deletion after archiving

for deletion after incorrect creation

Instrument Methods

for adjusting after method change

for incorrect creation of method

Manual Results

for correct integration of peak

for correct identification of peak

for addition of peak

for removal of peak

Method Sets

for adjusting after method change


Plot Scaling

for correct scaling to show in the report

Processing Methods

for restricting access after review, to prevent user intervention

for shifting retention times of components

for setting correct integration parameters

for addition of unknown components

for adjusting after processing method change


for addition of information after custom field change

for initial creation according to analytical instruction

for addition of unknown component after integration

for typo in component name

Projects


for setting correct access

for correct project settings

for typo in project name

for additional tablespace to process data

Reporting Methods

for showing correct report information

for adjusting to correctly report the data

Result Signoff 1 Meanings

Submitted: Data ready for Review

Reviewed: Data rejected for Incompleteness *

Reviewed: Data rejected for none optimized integration *

Reviewed: Data is ready for Approval *

(* legitimate reason to go to Sign Off 2)

Result Signoff 2 Meanings

Approved: Data rejected because of Sign Off 1 rejection

Approved: Data rejected for Incompleteness

Approved: Data rejected for none optimized integration

Approved: Data is Approved

Results

for initial saving of the results

for saving results with correct settings

Sample Acquisition

for initial injection of the samples

for injection of the pre-condition injection(s)

Sample Information


for correction of the sample information

for wrongly introduced values

Sample Set Methods

for adjusting samples settings in the sample set method

for adjusting information in the sample set method setting

Sample Set (SS) Method Templates

for adjusting sample settings in the sample set method template

for adjusting information the sample set method template

System Audit Trails

for deletion after archiving (following SOP xyz)

System Policies

for adjusting the policies (following SOP xyz)

for adjusting the policies (following Change Control xyz)

Systems


for addition of modules

for removal after decommissioning

User Groups


for correct access of users in the groups

User Types


for adjustment after change (following Change Control xyz)

Users


for change of full name of user

for re-activation after password lock

for removal, user left department

for removal, incorrect username

Configuring Empower 3 for Data Integrity and Regulatory ... · Data Integrity and Regulatory...

Documents

Transcript of Configuring Empower 3 for Data Integrity and Regulatory ... · Data Integrity and Regulatory...