team l5 automation practices in large molecule bioanalysis
play

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


  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

  2. Scope • Pros and Cons • Operational • Electronic • Instrument • Assay

  3. Out Of Scope • Analytical Instruments • Carryover • Large Molecule Analysis Using LC/MS • LIMS • Sample Preparation • Stability

  4. Pros and Cons

  5. Full Automation 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

  6. Modular Automation 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

  7. Operational

  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.

  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

  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.

  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.

  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.

  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.

  14. Periodic Review • A high level review of the validated status of the instruments should be performed at least every two years.

  15. Automation Issue Reporting • Any issues with the system must be traceable and documented.

  16. Validation of a Modular System • 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: o Generate IQ/OQ/PQ documentation as defined above for automated systems o Generate a Change Control to another validation o Perform as part of validation for another system (including analysis systems)

  17. Electronic

  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.

  19. Login IDs • Login IDs should be unique to each individual.

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

  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.

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

  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.

  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.

  25. Instrument

  26. Critical Functions • Software validation should be guided through critical functions determined. Critical Functions should be included in the User Requirements document.

  27. Interface Validation • Interface validation should be included in the PQ or Change Control process.

  28. Calibration • Calibration of an instrument should occur on a regular basis and should be defined in the SOP for the instrument.

  29. Verification • Verification frequency should be based on how often an instrument is used.

  30. Risk Assessment • Risk Assessment should be performed on all instruments.

  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.

  32. Error Recovery • 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

  33. Carryover Prevention • 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

  34. Assay

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

  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

  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

  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

  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

  40. Automation vs Manual Method Acceptance Criteria • Acceptance criteria are the same for both the automated and manual assay.

  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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend