OR WAIT null SECS
R.D. McDowall is principal of McDowall Consulting and director of R.D. McDowall Limited, and "Questions of Quality" column editor for LCGC Europe, Spectroscopy's sister magazine.
In the first two parts of this series we have looked at where and how a CDS fitted into a regulated laboratory and the overall requirements for the architecture of a future system. In this part we focus on new electronic ways of working for chromatographic analysis.
In the first two parts of this series we looked at where and how a chromatography data system (CDS) fits into a regulated laboratory and the overall requirements for the architecture of a future system. In this part, we focus on new electronic ways of working for chromatographic analysis.
In the first article in this series (1), we looked at the role of the laboratory and discussed the concept of the analytical factory together with the controllable and uncontrolled factors influencing the analytical process. In addition, we looked at the requirements for ensuring data integrity throughout the analytical process. We began the second installment (2) by defining the overall system architecture for a compliant chromatography data system (CDS) in a regulated laboratory in more detail. Here we describe the electronic processes and workflows that the future CDS should be capable of to improve efficiency and effectiveness.
Where Are We Now?
Basic chromatography functions that are already present include instrument control, data acquisition, integration, calculations, and reporting electronic signatures. Indeed there have been publications on how to implement and validate electronic ways of working including electronic signatures using a CDS (3,4) that are now 10 years old. However, when you look in detail at the workflow that has been implemented it focuses on chromatographic analysis only. Furthermore, control of an analytical procedure is either on (no changes permitted) or off (any changes permitted). There needs to be a more rational approach to changes based on the validation of the procedure.
Where Do We Need and Want to Go?
There are still areas where there are significant manual inputs to the chromatographic process-for example, sample information, sample weights, instrument log books, and column log books require manual input. In addition, method development and validation are typically outside the scope of an electronic process. However, we also want to go further and examine what the current regulations require of analytical laboratories from the perspective of trends in regulations (5,6).
Table I lists five new functions that we consider essential to a next-generation CDS working in a regulated laboratory. These are intended to go in parallel with the current functions that enable the main chromatographic process to work electronically. In addition we need to consider the development of an analytical procedure and its validation and operational use. We discuss each of those areas in more detail below.
Requirement 1: Method Development Function
The United States Pharmacopeia (USP) stimulus paper advocates defining an analytical target profile (ATP) (7), as we discussed in part I of this series (1), and this profile is then broken down into the overall analytical procedure including the sampling plan. However, focusing on the chromatographic portion of the process, the key to procedure development is an understanding of how key variables in the analytical procedure impact on the quality of the separation and robustness of the method (defining the analytical control strategy). Therefore, the CDS needs to automate the design, conduct, and evaluation of separation experiments. Some existing chromatography data systems have been integrated with experimental design software with the ability to control chromatographs so that results of individual experiments can be fed back into the design software for evaluation. Although chromatography data systems have the ability to perform some of these functions, the new approach proposed by the USP needs to be incorporated into CDS software. This integration is essential-defining the analytical control strategy is important because it is used throughout a procedure’s operational life. Changes can be made within the analytical control strategy to revalidate the method, and for this reason it must be available within the CDS.
The CDS should be capable of abstracting the work performed in developing the procedure for inclusion in a method validation report.
Requirement 2: Analytical Procedure Validation
Linking the method development work with procedure performance qualification (PPQ), the new USP term for method validation, of the analytical procedure is the next logical step with our new CDS. PPQ is essentially what we currently call validation. PPQ experiments, consistent with the ATP and within the analytical control strategy, can be defined by users as well as the acceptance criteria for each parameter and carried out by the system. On completion of the work, the calculated results can be interpreted by the CDS against the acceptance criteria and generate the secure result tables created for inclusion in the procedure performance verification (method validation) report automatically. This will typically be prepared outside of the data system.
By implication, the software should also be suitable for defining procedure performance verification (PPV) protocols and reports (see Figure 2 in part I ). This process will use the same software functions as above.
Requirement 3: Trending Analytical Data
The USP stimulus paper on control of methods during routine use has applied the following documented strategies: ICH Q10 (8), European Union Good Manufacturing Practice(EU GMP) Chapter 1.10(vii) (5), and the new EU GMP Chapter clauses 6.7(iv), 6.9, 6.16, 6.32, and 6.35 (6) for trending of quality control (QC) data. Therefore, as a minimum, a CDS needs to have the statistical functions to trend data such as the individual and mean results along with the key system suitability test (SST) parameters defined by users. Usually the limits will be based on the validation parameters of each analytical procedure. These data can be presented, for example, as a Shewhart plot with action and warning limits with the aim of identifying trends before an analytical procedure produces an out-of-specification (OOS) result. The CDS should then allow a user to look at instrument or column use in the method to see if there are any issues around a specific instrument or column. Any issues found may require an interface from the CDS to another informatics package for deviation management, risk assessment, and corrective and presentative action plans (CAPA) should be available.
Additionally, data trending is required for product quality reviews (5), where all batches of a specified product would be reviewed within the CDS with the output of secure tables for the overall reports of product quality.
Requirement 4: Additional Functions for Electronic Workflows
Currently, electronic workflows are poorly supported in current CDS applications. By this statement we mean that work packages are not allocated to teams of analysts to perform the work and peers or supervisors to review the data when the analysis is completed. The allocation of work and informing a user when a dataset is ready for review typically occurs outside of the data system. What is required is when you log in to the CDS either as an analyst or a supervisor there is a notification of the work to be performed by a team. This function needs to integrate with other informatics applications such as a laboratory information management system (LIMS) or an electronic laboratory notebook (ELN) for this to occur.
As required by the GMP regulations, there are instrument and column logs to complete when conducting an analysis. Typically, this is performed manually even if the main CDS workflow is electronic. For instrument use this information is typically contained within the CDS. What is required is a function to list the chronological use of each instrument, for example, instrument identity, date, analysis performed, analyst name (not identity), number of injections, and so on. In addition, there need to be functions in the CDS to record the following instrument data:
· Usage (such as the amount of mobile phase pumped, lamp hours, number of injections) of each instrument controlled as opposed to merely acquiring data from the detector
· Performance monitoring, dependent on the configuration of each instrument, such as mobile-phase pressure over time or lamp energy
These two sets of data should be used by the CDS to help manage predictive maintenance. The data can be used to establish and manage maintenance patterns based upon instrument usage and performance patterns. This maintenance would be risk-based and scheduled on actual data rather than estimated.
As mentioned next in requirement number 5 and in Table I, there needs to be a laboratory investigation module. The data from the instrument, column usage, and performance data can be fed into the investigation of an OOS, out of expectation (OOE), or out of trend (OOT) for use by the supervisor and analyst conducting the initial phases of the investigation. When necessary there could be diagnostic testing of the chromatograph conducted via the CDS. The overall aim is to understand the potential contribution of the instrument to the OOS result. These functions should be configurable in the CDS to allow a degree of focus in any investigation. Where possible, specific instrument events during an analytical run can be reviewed during the investigation. Additionally, where there is an instrument failure or breakdown or qualification failure, the CDS should support the impact assessment process, in which the potential impact of the instrument failure on the analytical results is evaluated and documented.
If there is sufficient IT security, the CDS could be connected to a service provider for remote diagnostics and service support. This function needs to be controlled in such a way that the service provider is allowed access only when the regulated laboratory requests help.
There needs to be a search function across and within instruments as well as the ability to access data generated in runs, especially if the search function is combined with the trending functions of the new CDS. In addition, this feature could identify potential problem instruments or justification for a new instrument as the existing ones are overloaded. One further step could be to expand the log to include maintenance either by a supplier, service agent, or laboratory staff, enabling all information to be in a single location that is reviewable and searchable.
Column logs are maintained manually in a large number of laboratories despite advances that could make them redundant. CDS suppliers who also sell columns have radio-frequency identification (RFID) tags that can be read by their software to identify the column number, packing, dimensions, and so on. However, what we want is for this identification to be extended to any column from any manufacturer so that a laboratory can use the most appropriate column for the analytical procedure. Here, the CDS can provide the column log information using similar functions as the instrument usage log.
Note, that the instrument use, maintenance, and column logs need to document that they have been reviewed by a second person. This function would also need to have a reminder function in case of memory lapses by reviewers.
Requirement 5: Laboratory Investigation Module
Finally, there should be the user-definable functions for the first stage of a laboratory investigation for OOS results that should be linked with the trending functions for analytical data and SSTs described earlier in this article. Part of the function would be for users to set, for each analytical procedure, the acceptance criteria for individual injection results as well as the reportable value of the sample as described in the Food and Drug Administration’s (FDA’s) guidance on the subject (9). The first stage investigation could be set up as a series of questions to be completed by the analyst and supervisor as they review the analytical data-such as the solutions and standards used, sample weights, test methods, integration, SST, manual entry of data for the run, and so on. If there was an assignable cause, the supervisor should review and approve the investigation. If not the investigation would be transferred to a corporate system for further work.
In this article we looked at defining new functions for the future CDS to automate the development, qualification and procedure development, procedure performance qualification, and procedure performance verification. In addition, new features for electronic working, electronic instrument and column use logs that are automatically completed by the application, trending functions to be compliant with the new requirements of EU GMP Chapter 6, and the linkage with a user-defined first stage laboratory investigation module were discussed.
The authors would like to thank Lorrie Scheussler, Heather Longden, Mark Newton, and Paul Smith for comments and suggestions made during the writing of this series of papers.
R.D. McDowall is the director of R.D. McDowall Ltd. Chris Burgess is the managing director of Burgess Analytical Consultancy Ltd. Direct correspondence to: firstname.lastname@example.org