Team L5 Automation Practices in Large Molecule Bioanalysis Ago - - PowerPoint PPT Presentation

team l5 automation practices in large molecule bioanalysis
SMART_READER_LITE
LIVE PREVIEW

Team L5 Automation Practices in Large Molecule Bioanalysis Ago - - PowerPoint PPT Presentation

Team L5 Automation Practices in Large Molecule Bioanalysis Ago Ahene Claudio Calonder Scott Davis Joseph Kowalchick Takahiro Nakamura Parya Nouri Igor Vostiar Jin Wang Yang Wang Scope Pros and Cons


slide-1
SLIDE 1

Team L5 Automation Practices in Large Molecule Bioanalysis

  • Ago Ahene
  • Claudio Calonder
  • Scott Davis
  • Joseph Kowalchick
  • Takahiro Nakamura
  • Parya Nouri
  • Igor Vostiar
  • Jin Wang
  • Yang Wang
slide-2
SLIDE 2

Scope

  • Pros and Cons
  • Operational
  • Electronic
  • Instrument
  • Assay
slide-3
SLIDE 3

Out Of Scope

  • Analytical Instruments
  • Carryover
  • Large Molecule Analysis Using LC/MS
  • LIMS
  • Sample Preparation
  • Stability
slide-4
SLIDE 4

Pros and Cons

slide-5
SLIDE 5

Pros

  • Frees up analyst
  • Reduces cost of drug development
  • Lessens or eliminates ergonomic injury risk
  • Minimizes human error for more consistent analysis

Cons

  • Systems are expensive
  • Compliance issues
  • Malfunction risk

Full Automation

slide-6
SLIDE 6

Pros

  • More efficient
  • Better throughput
  • Good transition to full automation
  • Faster to use than manual
  • Greater sample capacity than manual

Cons

  • Requires more analyst time than full automation

Modular Automation

slide-7
SLIDE 7

Operational

slide-8
SLIDE 8

Automation Instrument & Software Validation

Software used for programming must be validated before a script can be programmed. All system components should be included in the validation

  • process. Backward compatibility should also be

tested if multiple versions of the instrument software have been used.

slide-9
SLIDE 9

System Documentation

  • Standard Operating Procedure (SOP)
  • Installation Qualification (IQ)
  • Operational Qualification (OQ)
  • Performance Qualification (PQ) (If Significant Software

Component) Ø User Requirements Ø Validation Plan Ø Test Worksheets Ø Validation Summary Ø Traceability Matrix Ø Test Incident Log

  • Change Control (If Applicable)
  • Configuration Only Change Control (If Applicable)
  • Configuration Management
slide-10
SLIDE 10

User Training

Before access to a system can be granted, the user must have documented training. Training must include the reading of the SOP as well as hands-on instruction. Safety concerns should be included in any training session or document. This does not include training on a particular assay.

slide-11
SLIDE 11

Scripts

  • Each script must be versioned, named and
  • dated. A version history must be included with

each script for traceability and each script version should never be overwritten.

  • Scripts should have a documented process for

release into production.

slide-12
SLIDE 12

Maintenance

  • All maintenance should be documented,

including third party maintenance.

  • Routine Maintenance

Should be performed according to vendor recommendation and defined in the SOP for the instrument.

  • Remedial Maintenance

This process should be defined in an SOP, but not necessarily the SOP for the instrument.

slide-13
SLIDE 13

Decommissioning

  • An SOP should be written to define the overall

process for decommissioning a system.

  • Instrument specific decommission information

may be included in the instrument SOP.

slide-14
SLIDE 14

Periodic Review

  • A high level review of the validated status of the

instruments should be performed at least every two years.

slide-15
SLIDE 15

Automation Issue Reporting

  • Any issues with the system must be traceable

and documented.

slide-16
SLIDE 16
  • Must be done before assay validation
  • Should be included in original PQ for automated system
  • No need to re-validate anything already validated
  • Includes integration of LIMS in process
  • If module added after PQ, there are three options:
  • Generate IQ/OQ/PQ documentation as defined

above for automated systems

  • Generate a Change Control to another validation
  • Perform as part of validation for another system

(including analysis systems)

Validation of a Modular System

slide-17
SLIDE 17

Electronic

slide-18
SLIDE 18

User Access

  • The system must include two components for

access (For example: login ID & password, login ID & biometrics).

  • If the system does not have its own means of

enforcing access limitations, the organization can rely on the company network to limit access to the computer with the programs on them.

  • User account status must be periodically

reviewed.

slide-19
SLIDE 19

Login IDs

  • Login IDs should be unique to each individual.
slide-20
SLIDE 20

Passwords

  • Passwords must be changed periodically if the

system is able to enforce this.

  • Passwords must be unique to each individual

(i.e. a common password cannot be used for all users).

  • In order to reset a password, the individual must

contact a System Administrator (i.e. at least two people must be involved for this to occur).

slide-21
SLIDE 21

User Roles

  • User Roles should be assigned based on

business need (i.e. Users, Developers, and Administrators) and training.

  • User roles must be periodically reviewed.
slide-22
SLIDE 22

Audit Trails

  • Audit Trails must be tested during software

validation to ensure functionality.

  • Audit Trails must be backed up on a regular

basis.

  • Audit trail limitations should be addressed

through manual means (i.e. critical information not recorded by the audit trail or system generated files backed up to a secure location should be recorded by the analyst).

slide-23
SLIDE 23

Data Security

  • Electronic data should be saved to a

secure location that is backed up on a regular basis.

  • Access should be restricted to authorized

staff.

slide-24
SLIDE 24

Business Continuity

  • To ensure business continuity, the following should

be backed up, either manually or electronically: Ø Script Information Ø Script Versions Ø Instrument Configuration Ø Software Configuration (Versions and Updates)

  • Written instructions on manual methods for

instrument functions should be recorded in the SOP in case of instrument malfunction.

slide-25
SLIDE 25

Instrument

slide-26
SLIDE 26

Critical Functions

  • Software validation should be guided through

critical functions determined. Critical Functions should be included in the User Requirements document.

slide-27
SLIDE 27

Interface Validation

  • Interface validation should be included in the

PQ or Change Control process.

slide-28
SLIDE 28

Calibration

  • Calibration of an instrument should occur on a

regular basis and should be defined in the SOP for the instrument.

slide-29
SLIDE 29

Verification

  • Verification frequency should be based on how
  • ften an instrument is used.
slide-30
SLIDE 30

Risk Assessment

  • Risk Assessment should be performed on all

instruments.

slide-31
SLIDE 31

Instrument Capacity

  • An organization should have a high enough

number of critical instruments to ensure continued throughput should an instrument malfunction.

  • In the case of having only one or a limited

number of instruments, a fully manual assay should be validated as a redundant backup for an automated assay in case of instrument malfunction or unavailability.

slide-32
SLIDE 32
  • Depends on type of error and which sample has the

issue

  • Errors should be recorded in electronic audit trail of

system

  • Actions depend on which sample(s) have the error
  • Actions need to be documented (example: fail sample, or

fail entire plate)

  • No Manual Recovery of sample volume if error occurs,

as this is not recorded in the audit trail

Error Recovery

slide-33
SLIDE 33
  • Depends on type of assay
  • Ensure that system maintenance is up to

date (i.e. no tip dripping, etc)

  • Use disposable tips and other hardware if

possible

Carryover Prevention

slide-34
SLIDE 34

Assay

slide-35
SLIDE 35

A fully manual assay should be validated as a redundant backup for an automated assay in case of instrument malfunction or unavailability.

Manual Assay Backup

slide-36
SLIDE 36

Accuracy and Precision Testing

  • Scenario 1: Manually validated assay

(benchmark only, out of scope of committee)

  • Scenario 2: Assay validated with robotics
  • Scenario 3: Manually validated assay along

with assay validation with robotics

  • Scenario 4: Manually validated assay followed

by assay validation with robotics LATER

slide-37
SLIDE 37

Scenario 2

Assay Validated with Robotics (No Manual Assay)

  • Number of Runs

6, all using the robotic system(s)

  • Calibration Curve

1 per assay plate

  • Quality Controls

ULOQ, LLOQ, Hi, Mid, Low QC with n=3 minimum per QC Level, run in duplicate

  • Dilution Linearity

n=3 minimum per dilution level, run in duplicate

slide-38
SLIDE 38

Scenario 3

Manually Validated Assay Along With Assay Validation With Robotics (At The Same Time)

  • Number of Runs

6, at least 2 using the robotic systems, more determined by assay use

  • Calibration Curve

1 per assay plate

  • Quality Controls

ULOQ, LLOQ, Hi, Mid, Low QC with n=3 minimum per QC level, run in duplicate

  • Dilution Linearity

n=3 minimum per dilution level, run in duplicate

slide-39
SLIDE 39

Scenario 4

Manually Validated Assay Followed by Assay Validation With Robotics LATER

  • Number of Runs

1-3, depending on extent of robotic use in the assay

  • Calibration Curve

1 per assay plate

  • Quality Controls

ULOQ, LLOQ, Hi, Mid, Low QC with n=3 minimum per QC level, run in duplicate

  • Dilution Linearity

n=3 minimum per dilution level, run in duplicate

slide-40
SLIDE 40

Automation vs Manual Method Acceptance Criteria

  • Acceptance criteria are the same for both the

automated and manual assay.

slide-41
SLIDE 41

Script Qualification for Analytical Methods

  • Scenario 1: Script tested during method

validation

  • Scenario 2: Major robotic script (or major script

change) is added after validation is complete

  • Scenario 3: Minor robotic script (or minor script

change) is added after validation is complete

slide-42
SLIDE 42

Scenario 1

Script Tested During Method Validation

  • Number of Runs

6, all using the robotic system(s)

  • Calibration Curve

1 per assay plate

  • Quality Controls

ULOQ, LLOQ, Hi, Mid, Low QC with n=3 minimum per QC Level, run in duplicate

  • Dilution Linearity

n=3 minimum per dilution level, run in duplicate

slide-43
SLIDE 43

Scenario 2

Major Robotic Script (or Major Script Change) Is Added After Validation Is Complete

  • Number of Runs

1-3, depending on extent of robotic use in the assay

  • Calibration Curve

1 per assay plate

  • Quality Controls

ULOQ, LLOQ, Hi, Mid, Low QC with n=3 minimum per QC level, run in duplicate

slide-44
SLIDE 44

Scenario 3

Minor Robotic Script (or Minor Script Change) Is Added After Validation Is Complete

  • No qualification required
slide-45
SLIDE 45

Major vs Minor Changes

  • Major: Pipetting Speed, Liquid Handling

Changes

  • Minor: Displayed Message Change, Labware

Position Change

slide-46
SLIDE 46
  • Large dilutions can be performed via serial dilutions
  • Dilution limit depends on capabilities of system [typically

up to 1:100]

  • Volume precision will be part of validation (PQ) process

(minimum sample volume)

  • Use water for precision testing, other matrices to be

tested as part of assay validation

  • Minimum Patient Sample Volume for dilution [typically at

least 5 microliters]

Dilutions (Million Fold)

slide-47
SLIDE 47

Glossary

Audit Trail Record of events that occur during the use of a system that should include the time, date, user identification, what occurred and the reason. Also known as Log Files or Trace Files. Calibration Periodic setting of instrument parameters that allow instrument to function as intended. Change Control Documentation of any change to the system after the original installation. The Change Control documentation will require IQ and OQ to show that the change is working as expected, with the exception of a Configuration Only Change Control. Configuration Management Documentation of the setup of the system for use. This includes user roles, privileges and groups as well as audit trail and electronic signature setup if applicable to the system. Configuration Only Change Control Documents setting changes in the system software. Only OQ documentation is required in addition to the Configuration Only Change Control, as an installation is not performed. Decommission Removing a system from active use.

slide-48
SLIDE 48

Glossary

Full Automation Entire assay performed by one automated system with all assay steps performed by the system. Installation Qualification (IQ) The IQ is comprised of documentation that demonstrates that the system is installed properly. The extent of the IQ documentation depends on the type and complexity of the system installation. The IQ is performed for every instrument installation. Interface A connection that allows communication between the software/computer and the instrument. Modular Automation A combination of manual and automated steps in a procedure that can include automated steps from multiple systems. Operational Qualification (OQ) The OQ is comprised of documentation that demonstrates that the system is operational in its installed

  • environment. The OQ is performed for every instrument installation.

Performance Qualification (PQ) The PQ is comprised of documentation that demonstrates that the system performs the functions that the users need it to do and is performed only once per version of the software used. Also referred to as software

  • r system validation.

Remedial Maintenance Procedures performed on a system to correct an error or issue with that system.

slide-49
SLIDE 49

Glossary

Risk Assessment Procedure used to determine the criticality of an instrument, which in turn determines whether PQ is required. Routine Maintenance Periodic procedures performed on a system to ensure that the system continues to perform as

  • expected. Includes preventative maintenance (PM), verification and calibration.

Script The program used on the instrument to perform the needed functions. Can be a General Script that is used for more than one assay (example: Quality Control preparation) or an Assay Script that is used as part of a specific analytical method for analysis. Standard Operating Procedure (SOP) Document that describes use of the system and will include safety concerns. An SOP may also include decommission information. Test Incident Log Document that lists any unexpected events that occurred during the PQ and how they were resolved. Test Worksheet Document that describes the purpose, procedure and expected results of a PQ test.

slide-50
SLIDE 50

Glossary

Traceability Matrix Charts each user requirement with the test worksheets that test them. User Requirements Document that defines what functions will be used and tested as part of PQ. Validation The process of evaluating a system, instrument, assay or script to provide a high level of assurance that they will perform accurately and consistently in accordance with intended user expectations. Validation Plan Document that describes the system and how the system will be tested. Validation Summary Document that includes test results and statement that the system is ready for use. Verification Periodic checking of calibration parameters to demonstrate that the instrument is still functioning as needed.