Automation Practices in Large Molecule Bioanalysis: Recommendations from Group L5 of the Global Bioanalytical Consortium

Abstract

In recent years, the use of automated sample handling instrumentation has come to the forefront of bioanalytical analysis in order to ensure greater assay consistency and throughput. Since robotic systems are becoming part of everyday analytical procedures, the need for consistent guidance across the pharmaceutical industry has become increasingly important. Pre-existing regulations do not go into sufficient detail in regard to how to handle the use of robotic systems for use with analytical methods, especially large molecule bioanalysis. As a result, Global Bioanalytical Consortium (GBC) Group L5 has put forth specific recommendations for the validation, qualification, and use of robotic systems as part of large molecule bioanalytical analyses in the present white paper. The guidelines presented can be followed to ensure that there is a consistent, transparent methodology that will ensure that robotic systems can be effectively used and documented in a regulated bioanalytical laboratory setting. This will allow for consistent use of robotic sample handling instrumentation as part of large molecule bioanalysis across the globe.

INTRODUCTION

The Global Bioanalysis Consortium (GBC) is a world-wide organization consisting of representatives of scientific associations with the mission to harmonize and merge existing or emerging bioanalytical guidance to create one, unified consensus document that can be presented to the regulatory bodies/health authorities in various countries. The main goal of the GBC is to bring together stakeholders from the pharmaceutical industry, contract research organizations and academia to share the current understanding of bioanalysis guidelines, identify differences in these guidelines or differences in the interpretation or application thereof to routine regulated bioanalysis. The final intention is to come forward with recommendations to health authorities and regulatory bodies worldwide on globally agreed best practices for bioanalytical method validation (BMV) and application of such methods/technologies to the analysis of drugs of all molecular sizes in support of clinical and nonclinical studies. The purpose of GBC Group L5, Automation Practices in Large Molecule Bioanalysis, is to determine overall guidance on policies and procedures regarding the use of automated liquid handling robots in large molecule assays (Global Bioanalytical Consortium, www.globalbioanalyticalconsortium.org).Pre-existing regulations do not go into sufficient detail in regard to how to handle the use of robotic systems for use with analytical methods. As a result, Group L5 has put forth specific recommendations for the validation, qualification, and use of robotic systems as part of bioanalytical analyses in the present white paper. The guidelines presented can be followed to ensure that there is a consistent, transparent methodology that will ensure that robotic systems can be effectively used and documented in a regulated bioanalytical laboratory setting.

SCOPE

The focus of the discussions for GBC Group L5 was on the use of robotic liquid handling systems with large molecule bioanalytical assays, including the qualification, validation, and compliance of such systems. Automated data acquisition systems and Laboratory Information Management Systems are not covered in the L5 recommendations. Further, topics such as stability, sample preparation, and large molecule analysis using LC/MS are also not included in the present white paper.

DISCUSSION TOPICS

A considerable number of topics were discussed by GBC Group L5 during several conference calls in 2011 and 2012. Both full automation and modular automation were discussed as automation strategies with their specific sets of advantages and disadvantages. The remaining topics were split up into four main topic headers: Operational procedures and policies, Electronic data integrity and security, Instrument maintenance and procedures and assay validation, Procedures and automation scripts. The present white paper focuses on the discussions, consensus, and resulting recommendations on the various topics discussed with regard to automated practices in large molecule bioanalysis.

GBC L5 TOPICS

• Automation Strategy.

  1. Full automation advantages and disadvantages
  2. Modular automation advantages and disadvantages
• Operational Procedures and Policies.

  1. Validation of the automated instrument and software
  2. System documentation
  3. User training
  4. Automation issue reporting
  5. Scripts
  6. Maintenance
  7. Decommissioning
  8. Periodic review
  9. Validation of a modular system
  10. Business continuity
• Electronic Data Integrity and Security.

  1. User access components
  2. Login IDs
  3. Passwords
  4. User roles
  5. Audit trails
  6. Data security
• Instrument Maintenance and Procedures.

  1. Calibration frequency
  2. Verification frequency
  3. Risk assessment
  4. Instrument capacity
  5. Interface validation
  6. Error recovery
  7. Carryover prevention
• Assay Validation, Procedures and Automation Scripts.

  1. Manual redundancy
  2. Assay accuracy and precision testing
  3. Acceptance criteria
  4. Script qualification
  5. Major and minor changes in scripts
  6. Dilutions

RECOMMENDATIONS and CONSENSUS POINTS

Automation Strategy

1. Full automation advantages and disadvantages.

   There are several advantages to having a fully automated assay. The first and most obvious advantage is that automation frees up the analyst from having to constantly spend time working on the physical aspects of the assay. Throughput can also be increased, allowing for more sample analysis to be performed in a smaller amount of time. As a direct result of this, the costs of drug development can be significantly reduced over the long term, a huge benefit to all involved parties. Safety of analysts is always a concern, and an automated system can also lessen the repetitive strain of manual analysis, resulting in fewer ergonomic injuries for employees. Automated systems are more consistent and can lessen the amount of human error in the assay. As technology advances, high throughput, high accuracy, and precision assays could only be carried out by automation.

   A major disadvantage is that most automated systems are expensive, and can be a huge short-term drain on financial resources. Over the long term, the cost of programming expertise required to program the instrument would be a significant consideration. The risk of malfunction can also result in repair costs and assay downtime. With the introduction of rather complicated instruments that can include entire software suites that are used to run them, compliance issues have come to the forefront in regard to how to define and handle the use of such software. Also, software compliance can also put restrictions on sharing the instruments in the laboratory, which can be an impediment to using an instrument across multiple users and projects efficiently.

2. Modular automation advantages and disadvantages.

   Modular automation is faster, more efficient, and can handle more sample throughput than a manual assay, but less so than an automated assay. Although it can incur the up-front costs of an automated assay, the overall costs could be less than a manual assay in the long term even including programming expertise costs, which should be significantly lower than that required for an automated assay. Over time, using modular automation can be an excellent way to transfer to an automated assay. However, modular automation requires more analyst time than an automated assay. Furthermore, the risks of malfunction and compliance issues that occur with automated assays are also a factor with modular automation as well, but with modular automation it is conceivably easier to swap components.

Operational Procedures and Policies

The operational topics cover the overall policies and procedures involved with using automated systems for large molecule bioanalysis with various documentation practices.

1. Validation of the automated instrument and software.

   Software used for programming must be validated before a script can be used for regulated activity support. Each automated instrument type that will be used should be validated for use with the software. All system components should be included in the validation process. Backward compatibility should also be tested if a new version of the instrument software is validated and scripts from older versions are going to be used with the new version.

2. System documentation.

   All robotic systems and their software validation should be documented to ensure that appropriate measures have been taken to ensure that the systems will perform as needed in the laboratory. Documentation should be well-organized and easy to follow from the viewpoint of an outside auditor. Each robotic system type should have a standard operating procedure (SOP) that covers the use of the system. The documentation for the instrument and software validation includes: a user requirements document that lists the functions that the users will need the system to perform, a validation plan that defines the system, responsibilities and tasks that will be performed to complete the validation, installation qualification (IQ) documents for each instrument and its corresponding software that detail the steps taken for their installation and operational qualification (OQ) documents for both instrument and software that show that they are working in their installed environment.

   Performance qualification (PQ) documentation covers the validation of the software and its performance with the instrument and consists of several documents. Test Worksheets should be created for each function listed in the user requirements document. If unexpected events occur during testing, a test incident log should be created that lists the events and information on how they were resolved. Once all tests are completed successfully, a validation summary should be generated that discusses the test results and states that the system is acceptable for use in the organization. Finally, a traceability matrix will be used to connect each test to its corresponding requirement from the user requirements document. Please note that validation should test the functions for the intended use and the functions that will not be used do not need to be tested or listed as a requirement in the user requirements document. While each automated system will require IQ and OQ documentation, PQ will cover each automated system type (i.e., model) and is not required for every system (i.e., if an organization has ten instruments of the same model type, only one instrument of that model type should be included in the PQ. PQ testing is not required for all ten instruments.). Further, PQ would need to include communication of the automated system with any third party devices as well as the firmware version used to run them. Changes in firmware and/or third party systems added after the original PQ can be tested via a change control to the original PQ documentation.

   Configuration management documentation should be generated that shows the software settings that are used for each instrument type, including account privileges and security settings, if applicable. After the instrument is installed and functioning, any changes to the software should be documented via a change control document, including an IQ and OQ for the change, if applicable. Simple setting changes (such as those requiring the checking or unchecking of a box within the software) can be documented via a configuration only change control with no needed IQ or OQ documentation. Some minor changes, such as labware location parameters, do not require change control and can be performed without such documentation. The risk of each change made should be assessed to determine whether or not it requires change control.

3. User training.

   Before access to a system can be granted, the user must have documented training. Training must include acknowledging comprehension of the SOP on use of the automated system as well as hands-on instruction. Safety concerns should be included in any training session or training document. User training may not include training on a specific assay.

4. Automation issue reporting.

   A defined, organized system must be devised so that hardware and software issues can be tracked. Any issues with the system must be traceable and documented. Information should include the system, the date and time, the individual that discovered the issue and how it was resolved. If necessary, bioanalytical data related to the issue should also be reviewed.

5. Scripts.

   Scripts are the programs that tell the robotic instrument the steps that must be completed to perform each task and must have a documented process for qualification and release into production. Each script must be versioned, named, and dated. Naming conventions should be unique to each version of a script so that they can be easily distinguished. A version history must be included with each script for traceability and each script version should not be overwritten, if possible.

6. Maintenance.

   All maintenance, whether internal or performed by a third party, should be documented. There are two types of maintenance, routine and remedial. Routine maintenance covers periodic procedures that keep the instrument functioning properly. Routine maintenance should be performed according to vendor recommendations and defined in the SOP for the instrument. Remedial maintenance covers unexpected issues with the system and the restoration of system functioning after a malfunction. Remedial maintenance should be defined in an SOP, but not necessarily the SOP for the instrument.

7. Decommissioning.

   Decommission documentation should be generated to show when an instrument is permanently removed from active use in the laboratory and to detail what is done with any information on the system and what processes are in place to ensure that system data can be accessed at a later date if needed. 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. Decommission documentation should be completed for every system and included when the system is decommissioned. Also, any procedures that were put in place should be documented in case any data from the system is needed at a later date.

8. System periodic review.

   A high level review of the validated status of the instruments should be performed at least every 2 years to confirm that each system is still in an acceptable validated state. If it is determined that too many changes have occurred over time, additional testing may be required to ensure that the system is still functioning appropriately.

9. Validation of a modular system.

   Modular system validation is needed if an automated system is used with other systems and/or system components to run an assay. Validation of the modular system demonstrates that each component in the modular system can work together effectively to perform the needed assay. If possible, this should be included in the original PQ for the automated system. Modular system validation must be done before the assay validation is undertaken. If the modular system is validated after the original PQ, only new functionality should be validated. There is no need to revalidate anything already validated in a previous PQ. If a module is added after the original PQ, there are three options. The first option is to generate system documentation as defined above under system documentation. The module should be treated like a new system and all documentation should be generated. The second option is to generate a change control to another validation (PQ). If a small number of test worksheets are needed, then the testing can be performed and amended to a previously completed validation. The change control will document that the testing was added and the purpose of the testing. The third option is to perform the validation testing as part of another validation for another system that is related to the new module. The test worksheets for the module could be included as part of the PQ documentation for the related system.

10. 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 documented for a specific analytical method in case of instrument malfunction.

ELECTRONIC DATA INTEGRITY AND SECURITY

The electronic topics cover the overall policies and procedures involved with regulatory compliance, including security of electronic systems and data. Not all topics can apply to all systems due to differences in system and software design, but should be applied when a system has the appropriate functionality included. For example, some robotic systems do not include the ability to setup individual user access or do not include any sort of security features. In cases such as this, every effort should be made to provide a manual audit trail for the system and restrict access to such a system.

1. User access components.

   Each system must include two components for access (for example: login ID and password, login ID and 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 system software installed. User account status must be periodically reviewed to ensure that only those who need access to the software as part of their job responsibilities can use it.

2. Login IDs.

   If access requires a login ID, it should be unique to each individual. Login IDs should never be reassigned to another individual and, if possible, should not be deleted from the system if the individual leaves the organization. However, a user can be deleted from the system if the deletion is documented appropriately.

3. Passwords.

   If access requires a password, it should be unique to each individual (i.e., there should be no universal password for the system that is used by everyone). The password must also be changed periodically if the system is able to enforce this.

4. User roles.

   User roles determine the permissions that a person has in the system software and should be assigned based on business need (i.e., users, developers, and administrators) and training. User account status must be periodically reviewed to ensure that those who have access have the appropriate level of permissions in the software (if applicable). Review of user roles should be documented appropriately.

5. Audit trails.

   Audit trails must be tested during the OQ or software validation (PQ) to ensure that critical information is included. Critical information in this case includes the listing of the script that is being run, the list of the actions included in the script and any errors that may occur, including the date, time, and user identification, if possible. Any limitations to the audit trail 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). Periodic review of audit trails should also be performed. Audit trails must be backed up on a regular basis. Further, trace files and log files should be considered in terms of being useful as an audit trail. For example, many trace files or log files contain granular information about system functions but may not include the critical information needed from an audit trail in an easily readable format. In this case, a manual audit trail would be a more useful approach.

6. Data security.

   Electronic data and files should be saved to a secure location that is backed up on a regular basis. Backup data should be readily retrievable and restorable in case the original files are lost. A secure location could be a read-only directory or an electronic knowledge system or server location. Access to system data should be restricted to authorized staff.

INSTRUMENT MAINTENANCE AND PROCEDURES

The instrument topics cover the overall policies and procedures involved with the use of the instrument hardware, including maintenance, calibration, and general use.

1. Calibration frequency.

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

2. Verification frequency.

   Verification frequency should be based on how often an instrument is used and should be defined in the SOP for the instrument.

3. Risk assessment.

   Risk assessment should be performed on all instruments and documented. This can be used to justify more or less PQ testing depending on the decided risk of the system.

4. Instrument capacity.

   An organization should have a high enough number of critical instruments to ensure continued throughput should an instrument malfunction.

5. Interface validation.

   Validation of connections between the system hardware, its computer, and any third-party devices should be included in the OQ, PQ, or change control process. Each liquid handling system can be either standalone or part of a larger organizational network, depending on the needs of the organization.

6. Error recovery.

   Automated systems handle errors in different ways. The process for recovery after an error depends on the type of error and which sample(s) in the assay has the issue. If possible, errors should be recorded in the electronic audit trail of the system. Actions taken as a result of an error must be documented (example: fail sample, or fail entire plate). Analytes and reagents may be removed from the system for further processing and reuse if they have not been added to a reaction well and there is no reason to suspect contamination. Tracking of these moves will not be recorded in the electronic audit trail of the system and they should be captured by other means. Listed below are two example scenarios that can be used as a guide to recover sample plate processing errors:

   1. During an incubation step, it is discovered that the robotic system has malfunctioned and is not capable of continuing the assay. No other instrument is available for continuing the assay.
      In this case, the robotic system failure should be documented and remedial maintenance procedures followed. The assay should be continued manually, provided that a manual assay has been validated. If no manual assay has been validated, the assay must be documented as a failure. The robotic system failure and subsequent actions should be included with the assay documentation in addition to any remedial maintenance documentation requirements.
   2. During the processing of multiple plates, the robotic system fails during the processing of any plate. The robotic system is not capable of continuing the assay. No other instrument is available for continuing the assay.
      In this case, the assay of the errant plate must be designated as a failure and documented accordingly. The robotic system failure should be documented and remedial maintenance procedures followed. The assay of the remaining plates should be continued manually, provided that a manual assay has been validated. If no manual assay has been validated the assay must be documented as a failure. The robotic system failure and subsequent actions should be included with the assay documentation in addition to any remedial maintenance documentation requirements.

7. Carryover prevention.

   The prevention measures created to avoid carryover in an assay can vary greatly and depend on the type of assay being performed. At least, ensure that system maintenance is up to date (i.e., no tip dripping, etc.) and use disposable tips and other disposable hardware if possible.

ASSAY VALIDATION, PROCEDURES, AND AUTOMATION SCRIPTS

This topic covers the overall policies and procedures involved with the performance of the analytical assay, including acceptance criteria, scripts, and everyday procedures.

1. Manual redundancy

   A fully manual assay should be validated as a redundant backup for an automated assay in case of instrument malfunction or unavailability (see 6 above). However, this is not needed if the organization has a sufficient number of instruments to keep sample analysis flowing if an individual instrument malfunctions and cannot be used.

2. Assay accuracy and precision testing.

   Listed below are three scenarios and recommended accuracy and precision testing. (Please note that a standalone manually validated assay is not included as it is out of the scope of this committee.) Plate runs performed as part of the scenarios below should be included as part of the assay validation and not as part of OQ or PQ. Plates run for all scenarios will include a calibration curve and quality controls:

   1. This scenario includes when an assay is validated from scratch including the robotic system as part of the validation testing. The robotic system will be used for all validation runs.

      • Number of runs: six, all using the robotic system(s).
      • Calibration curve: one per assay plate.
      • Quality controls: ULOQ, LLOQ, high, mid, low QC with n = 3 minimum per QC level.
      • Maximum plates: at least one of the robotic runs should include the maximum allowed number of plates in the assay.
   2. This scenario includes when an assay is being validated as a fully manual assay as well as with the robotic systems at the same time. The robotic system should be used in at least two validation runs, but can be used in a larger portion of the validation runs if the robotic system is being used on a more extensive basis.

      • Number of runs: six, at least two using the robotic systems.
      • Calibration curve: one per assay plate.
      • Quality controls: ULOQ, LLOQ, hi, mid, low QC with n = 3 minimum per QC level.
      • Maximum plates: at least one of the robotic runs should include the maximum allowed number of plates in the assay.
   3. This scenario includes when an assay is initially validated as a completely manual assay, but at some later date, a robotic system is introduced and will be used in place of some or all of the manual steps in the assay. This situation does not require a full six-run validation, but a smaller number of runs since the manual assay is already fully validated. The number of runs is determined by the extent of robotic use in the assay. This scenario should be treated akin to qualifying a user (in this case the robot) on a new assay.

      • Number of runs: one to three.
      • Calibration curve: one per assay plate.
      • Quality controls: ULOQ, LLOQ, hi, mid, low QC with n = 3 minimum per QC level.
      • Maximum plates: at least one of the robotic runs should include the maximum allowed number of plates in the assay.

3. Acceptance criteria.

   Acceptance criteria should be the same for both the automated and manual assay. However, overall acceptance criteria can change if the assay is transferred to another location or organization with different assay acceptance criteria requirements, but the new assay criteria should be the same for both the automated and manual assay at the new site or organization.

4. Script qualification.

   New scripts for a robotic system as well as script changes will need to be qualified to show that the scripts are functioning properly. Listed below are three determined scenarios with recommended script qualification testing:

   1. This scenario includes when a script is qualified as part of the assay validation. In this case, the assay validation is sufficient and no further script qualification is required.
   2. This scenario includes when a new script (or major script change) is added after the assay validation is complete. The number of runs depends on the extent of robotic use in the assay. Each plate should include a calibration curve and quality controls as defined below.

      • Number of runs: one to three.
      • Calibration curve: one per assay plate.
      • Quality controls: ULOQ, LLOQ, hi, mid, low QC with n = 3 minimum per QC level.
   3. This scenario includes when a minor script change is introduced after the validation is complete. In this case, no further script qualification is required.

5. Major and minor changes in scripts.

   The difference between major and minor changes depends on the system being used and the assay for which the script is being run. The determination of whether a change is major or minor in turn determines what is needed for script qualification above. The examples below can be used as a guideline to determine the difference between major versus minor changes in a script:

   • Major: pipetting speed, liquid handling changes.
   • Minor: displayed message change, labware position change.

6. Dilutions.

   One of the most critical activities performed by robotic liquid handling systems is the dilution of samples. Each system will have a dilution limit determined by its capabilities (typically up to 1:100 in one-dilution step). A minimum sample volume for dilution must also be determined per system type (for many systems, this is typically at least 5 μl depending on syringe or pipette type). Large dilutions can be performed on the system via serial dilution. Volume precision testing will be part of the OQ or software validation (PQ) and calibration process. Water (or a water-based solution) is usually used for this precision testing. Other matrices may be used for precision testing should a different matrix be more representative of the liquid classes used by the organization. Otherwise, nonwater matrices can be tested as part of the appropriate assay validation.

CONCLUSION

In order to harmonize how the pharmaceutical industry approaches the subject of automation and its use in large molecule bioanalysis, GBC Team L5 has carefully considered the many aspects of the policies and procedures involved. Automation has many benefits including increased assay efficiency, lower drug development costs, and increased throughput. However, there are several issues to consider when implementing automation, including policies and procedures involving the operation of the instrument system, the electronic data integrity of the system, the instrument hardware, and the assay to which the instrument is to be applied. Careful consideration must be given to both the benefits and costs involved with using automated robots with large molecule bioanalysis or, for that matter, any type of analysis in the laboratory. This white paper provides information that will help an organization create a foundation upon which to build its practices for using automated liquid handling robots in their assays. Automation has brought a new age to analytical sample analysis and its influence on the pharmaceutical industry cannot be ignored. With continued consideration, cooperation, and diligence, the world can adopt automated assays and confidently propel their analytical business model into the future.