Cost Beneficial Validation of a Site-wide Chromatography Data System

Introduction

Chromatography is an analytical technique used to detect or quantify compounds during the course of pharmaceutical product development and manufacture. The technique can be used for the assessment of active ingredients, raw materials, impurities and determining the stability of active ingredients. The chromatograms generated by these analytical methods are displayed, integrated and results calculated by a software application called a chromatography data system (CDS).^1,2 In addition, the CDS may also control the chromatographic instruments that have the advantage of checking that the whole system is working correctly.

The Organization and the Laboratories

Lonza is one of the leading custom manufacturers of chemical intermediates and active ingredients as well as biopharmaceuticals for the pharmaceutical industries (Lonza Custom Manufacturing, LCM). In addition, Lonza also offers organic intermediates and agrochemicals for a wide range of applications and provides antimicrobial and associated products (Lonza Organic Compounds, LOC). Owing to the nature of LCM business, GMP regulations have to be followed, whereas the LOC production works under an ISO 9000 quality management system (QMS).

More than 2500 employees work in Lonza's major LCM and LOC production facilities in Visp, Switzerland. The main tasks of the five quality control (QC) departments at Visp are

• to support the R&D activities from method development to method validation

• raw material testing

• in-process control (IPC) testing of production intermediates with 24 hours/ 7 days per week support required

• release testing of finished products

• stability testing.

The major analytical techniques used are HPLC and GC and, therefore, a highly efficient and validated chromatography process has a significant impact on the quality of the results and the overall productivity of the plant.

Existing Stand-alone Chromatography Data Systems

There were approximately 200 LC and GC instruments on the Visp site that were controlled by stand-alone PC workstations from three main vendors; however the CDS software used was not compliant with either the old or new interpretation of 21 CFR Part 11.^3,4

In addition, the operation of these stand-alone CDS systems was essentially paper based which is slow and requires much transcription error checking to ensure that the correct results are released.

New Site-Wide CDS

To improve the 21 CFR Part 11 compliance of existing systems and to enable better turnaround times by laboratory support a new networked chromatography data system was required by the laboratories. The major challenge in implementing a plant-wide centralized CDS at Lonza was to fulfil the different demands of each QC department with respect to regulations and working practice (e.g., easy to be used for IPC shift workers versus high functionality and flexibility for R&D support) as well as control as many of the existing instruments as possible. A demand from the project sponsors was to gain maximum benefit from the investment by harmonizing and optimizing the current chromatography working practice to increase the employee's flexibility and significantly shorten the time to results (e.g., facilitate data review and release, method development and transfer, raw data handling etc.).

This was a challenge as two different quality systems, ISO and GMP, were in operation in the various laboratories. When used in regulated laboratories the application must be validated to current regulatory guidelines. Lonza LCM work according to ICH Q7A Good Manufacturing Practice (GMP) for Active Pharmaceutical Ingredients (APIs); these regulations have the requirements for validation of computerized systems outlined in the relevant paragraphs of Sections 5 and 6[5]. As part of the implementation of the system, electronic signatures were to be used to gain business benefit and speed the release of the results generated by the system. Interestingly, this approach was to be used by both the GMP and ISO laboratories.

The CDS Validation Project

Multidisciplinary project team: For a system of this size, approximately 200 instruments and 150 users from five different QC departments, a multidisciplinary team is essential. Therefore, the following roles were necessary for the project:

• system owners

• laboratory staff (Project team members and CDS users)

• quality assurance

• information technology

• vendor

• consultant.

It is also essential that not just the laboratory requirements are catered for in this project. Both Information Technology and Quality Assurance representation from the start of the work was a critical success factor for the successful outcome of the project. In addition, there is the positive effect of QA, IT and QC working efficiently together in the same direction. The corresponding responsibilities for each of the roles were defined in the project validation plan and are shown in Table 1.

Table 1: Roles and responsibilities of all involved with the CDS validation project.

CDS Validation Project Overview

Main elements of the CDS validation project at the Visp site were

• defining the scope of the new CDS system and the decision to use electronic signatures in both the GMP and ISO laboratories for business reasons (as described earlier in this article)

• mapping the existing paper process and redesigning it for electronic ways of working

• defining a validation strategy for the system that was based on implementing a core system for one laboratory and then rolling it out in two additional phases to the other QC departments on site

• validation of the new process and how the new CDS supports it

• training of the users

• roll-out of the new system (hardware and revised chromatography process) without interrupting the QC support for the running production

• review of the new process and corrective actions, if needed.

Impact of the New Part 11 Guidance on the CDS Validation

The FDA's Guidance for Industry on Part 11 Scope and Application⁴ had an impact on the overall approach and direction of this CDS validation in the following areas:

• Definition of electronic records for the system: A document was written that stated that 21 CFR Part 11 applied to the system and electronic signatures would be used. It defined the electronic records generated during the use of the system including the use of DAD and MS detectors. Where hybrid systems were used (original equipment manufacturer's data system to control the instrument plus the new CDS for data acquisition) the OEM system controllers were incidental to operation and Part 11 did not apply as paper records document this portion of the process.

• Records retention strategy: There were approx 100 existing stand-alone data systems where data had been generated by the old CDS that would be retired. The key issue was how to approach this problem? The Part 11 guidance document was used as the basis to conduct a risk assessment of the four options identified as possible ways of retaining the records from the old CDS systems.

• Data migration: All electronic records generated by the former stand-alone CDS systems were regarded as for information only. The paper print-outs of these systems were defined as raw data, and the completeness was confirmed by audit. No records were migrated to the new system and the legacy electronic records were not needed and deleted.

• Enforcement discretion for 11.10a and 11.10e: In essence, the Lonza CDS validation project ignored the FDA's enforcement discretion for altered records (11.10a) and audit trails (11.10e) as these features were considered essential elements for ensuring data integrity when working electronically. Appropriate requirements were defined in the user requirements specification (URS) and tested explicitly in the performance qualification (PQ).

Use of a Document Management System (DMS) in the Overall Project

At Lonza, Documentum^®, a document management system (DMS), was used to administer the validation documentation workflow. The DMS significantly helped to make the entire CDS validation process easier and faster. All documents and the corresponding documented evidence generated during the CDS validation process are signed, stored and managed electronically in a central location. The document version, status and history can be reviewed at any time, which helps project management to keep track of all different validation activities.

Another aspect is that with a DMS document access can either be restricted, if needed, or made public. For example, all SOPs and application manuals relevant for routine usage or inspection of the CDS have been made accessible via Lonza's Intranet by a DMS Webserver interface.

Optimizing the Workflow for Electronic Signatures

For successful use of electronic signatures within the new CDS, an electronic workflow is necessary. Therefore the laboratory has to migrate from a paper driven process to an electronic one. The key to the cost beneficial validation of any system is to map, analyse and then optimize the business process to work electronically and use electronic signatures effectively. The preparatory work is achieved through two process mapping workshops.

The first workshop covered the following topics over two days:

• Overview of process mapping

• Mapping the current CDS process used in the laboratories

• Mapping the boundaries of the current CDS and LIMS systems

• Identifying any Excel spreadsheet and laboratory notebook use

• Identifying differences in working practices between laboratories

• Identifying SOPs used in the process

• Identifying bottlenecks in the process

• Identifying where and why signatures and initials are used throughout the process

• Identifying any process improvement ideas.

The second two day workshop was performed after the draft report from workshop 1 was circulated for review and covered the following items:

• Review of the As-Is process maps and modifying them as necessary to reflect current working practice

• Optimizing the process using the following inputs:

- Improvement ideas generated in workshop 1

- Eliminating any unnecessary process steps

- Identifying any manual steps to be automated by the new CDS

• Defining the new boundaries of CDS and the LIMS

• Identifying data transfers between these systems

• Identifying any Quick Wins for rapid implementation.

The Current (As-Is) Process

The high level process for the current CDS workflow is shown in Figure 1. The main issues with the process are

• The process is paper driven

• CDS outputs are used for manual or Excel-based calculations of results such as RSD or averages

• CDS outputs are manually entered into the LIMS for calculation of the results including system suitability test (SST) results

• The approval process for chromatographic results takes place in the LIMS and not in the CDS.

Figure 1: Existing chromatographic process for the Lonza laboratories.

Therefore if there are any issues, the analyst or reviewer has to change systems to re-evaluate the chromatographic data. If the SST results are out of specification then the rework needs to loop back from activity number 8 to 6 (shown as the dotted line in Figure 1) or worse to a reanalysis to activities 3 and 4 (not shown in the figure).

Looking in detail at the process for reviewing and approving results shown in Figure 2, the process is very laborious and slow; as it occurs mainly on paper, part in the LIMS and occasionally in the CDS to assess the integration and quality of the chromatographic separation. For example, each chromatogram is signed twice, once by the analyst who generated the data and secondly by the reviewer who checks the data. The calculation and release of results occurs in the LIMS, which is fine if there are no issues with the analysis but far too late in the process if there are any problems, which wastes time and effort.

The Redesigned (To-Be) Process

When redesigning the process, it is important to have the chromatographic data and the associated electronic signatures in the same place (in the software application). Therefore, all work associated with chromatographic data was relocated inside the CDS software. This can be seen in Figure 3, with the subsequent electronically signed results electronically transferred to the LIMS. The project to transfer the results electronically to the LIMS will be started on later.

Review of the results has also been simplified and optimised as shown in Figure 4. The first and second person data review process takes place electronically within the CDS. The second person review also uses the ability of the CDS database to highlight issues that could take the reviewer time such as changes to the instrument or processing method, manual integration of individual results or audit trail entries associated with the generation of a result. The CDS application also has technical controls to ensure that the same person who generated the results cannot approve them to be consistent with the GMP requirements. However this is not a constraint for the ISO instance on site and therefore only one review is required.

Figure 4: Redesigned electronic review and approval process within the CDS.

Estimated Benefits of Working Electronically

All calculations including system suitability testing were performed automatically with validated calculations within the system and all formerly used Excel or manual calculations were eliminated. Simplification of the process from method validation to routine analysis, elimination of laborious paper-based tasks and an entirely electronic workflow within the new CDS reduced the time to result significantly. Overall savings representing over three FTE were achievable, even without considering linkage to the LIMS.

CDS Validation Strategy

Instances of Empower: There are six instances of the CDS application that were implemented on site:

1. Production System for Lonza Custom Manufacturing (LCM) for GMP laboratories.

2. Production System for Lonza Organic Chemistry (LOC) for the ISO laboratories.

3. Archive system (production data will be routinely transferred to this instance; the data can be viewed only, for example, via a web server).

4. Three instances of Empower running on a Virtual Machine (VM) environment: Two as validation systems (fully qualified instance).

One for training and testing (unqualified instance)

The installation of the six instances was phased over a period. As such it was intended that any experience gained during installation could result in an update of existing documents for the installation of any subsequent instances of the CDS and this was reflected in the validation plan for the system (continuous improvement process).

Validation of the CDS Instances

To accommodate the number of the instances of the system, the following validation strategy was devised:

• Validation of the core system representing one R&D QC Laboratory connected to the LCM instance (Phase I, 10 Users). The rationale for this choice was that experienced users of the previous version of the system worked there and understood the new version better and faster than newly trained users of the software.

The CDS application used Citrix terminal server software to deliver the application to the users, this has a number of advantages from both IT (reduced IT administration and management of upgrades) and validation perspectives (simpler and quicker to validate);

• Further roll-out of the system to all R&D QC laboratory (LCM and LOC) using the two productive instances of the application (Phase II of the project with an additional 60 Users);

• Future system expansion to all production supporting QC Units included the addition of more clients at suitable times. When the same CDS software version and service packs are installed, it will be considered an extension of the existing validated system and will be adequately documented through the change control process for the system. The continued expansion of the system will require IQ, OQ and some of the PQ test scripts to be executed (Phase III, additional 100 Users).

• Data migration and records retention. No data was migrated into the new system from the existing CDS systems on site. The rationale for this approach was justified and documented in a risk assessment. The rationale was that there were major incompatibility issues with the electronic data that did not justify or warrant the effort and expense or could not be undertaken technically. With the former CDS systems paper records were used as the medium of choice to meet the GMP records retention requirements. This would be followed by retirement of approximately 100 stand-alone instances of these data systems which will not be discussed further in this article.

The differences between the validation, production and archive instances were documented in the PQ test plan. PQ testing was performed in the validation, production or archive instance, where appropriate. For example, critical test scripts such as system capacity were executed in the production instances only but hot swapping a disk or complete recovery of a system from backup tapes occurred in the validation instance of the system.

System Development Life Cycle Activities

Once the system supplier had been selected (Empower, Waters Corporation), formally reported and documents and decision had been ratified by the system owners and senior management the CDS validation project was started. The project followed a life cycle as outlined by McDowall¹ and was documented in a validation plan that documented the overall process as well as the documented evidence that would be collected during the project. Note, that both the GMP and the ISO instances were included in the same validation plan.

There are three main streams to this work:

• Specification, installation and qualification of the computer hardware

• Validation of the CDS application

• Writing procedures and training the users.

Tasks for the three streams are shown in Figure 5 and this will help to put the remaining tasks in this section into context.

Figure 5: Validation work streams and tasks for the CDS validation at Lonza.

Specify the CDS Requirements

An initial User Requirement Specification (URS) had been written as a questionnaire for system selection. This document was generic in general character and was not intended to be sufficiently specific to design tests for the validation of the selected CDS. Therefore an application specific System or User Requirements Specification (SRS) was written that defined the intended use of the system and contained the functions and the capabilities required by the CDS. It is this document that the PQ tests were based on using the risk assessment and traceability matrix documents. Each requirement in the SRS was prioritized as either mandatory (must have requirement) or desirable (nice to have but if not available the CDS functionality is not impaired).

Combined Risk Assessment and Traceability Matrix

Risk assessment is now a key regulatory requirement following the FDA's Part 11 Scope and Application guidance.⁴ After the SRS was written, both the system and the individual functions were assessed for regulatory and business risk using the Functional Risk Assessment methodology.^1,6,7 Here individual system functions are assessed as either critical or not critical (C or N respectively).

Only functions that were both mandatory and critical were considered for PQ testing. Only these functions were evaluated further to see if they were specifically tested, implicitly tested or assumed to be adequately tested by the vendor or given other assignments such as verified by IQ or found in a SOP.

Vendor Audit

The vendor of the CDS application was audited to ensure that the system had been designed, developed and tested appropriately by the vendor. This involved an on-site vendor audit in-conjunction with certificates of structural integrity provided by the vendor.

Basic System Design Specification (BSDS)

The vendor's recommendations were used by the Lonza IT Department to size and specify the database and application (Citrix server farm) servers for the CDS. This was documented in the Basic System Design Specification (BSDS). Servers for all instances were documented in this specification.

Server Installation Plans

Installation plans for all the servers (database instances and Citrix servers for the application) were written by the IT Department. These plans included the installation of the hardware and documenting its configuration as well as installing and configuring the operating system (Windows 2000) and any utilities for each server. The personnel responsible for performing the work and connecting the servers to the network were the Lonza IT staff following their own procedures.

Installation Qualification (IQ) for Servers

The IQ for the hardware, operating system and utilities for all servers followed, and was documented by, the IT Department's standard procedures for Windows 2000 Servers and, where appropriate, Citrix MetaFrame XP.

CDS Database and Application IQ and OQ

The activities that were involved in this task are

• evaluation of the vendor's "Installation and Configuration Guide" to check that it was acceptable

• writing the Lonza CDS IQ and OQ based on information in the vendor's IQ/OQ protocols by the IT Department staff

• installing the CDS software on the respective database and Citrix servers for each instance by a member of Lonza IT staff and executing the IQ and OQ, supervised by a member of the vendor's technical staff to confirm that these had been executed correctly with acceptable results.

Workstation ICA Viewer

To access the CDS application from a user's workstation, a Citrix ICA viewer was installed and distributed following Lonza's standard automatic software distribution procedure via the network.

Configure System Policies

For each CDS instance, a Lonza system administrator's account was set up and the default account password changed. The system policies and access control options were configured by a system administrator according to the requirements of the SRS and documented in the system audit trail (SAT). The full audit trail (FAT) was not turned until the Master Projects were established because otherwise all entries during the set–up of the Master Projects would be part of all future production projects. This would result in large default project files that negatively impact the response time and usability of the application. However, all changes and actions within the application were still tracked with the silent system audit trail.

Configure CDS System

Further configuration of each instance of the system was undertaken according to the SRS requirements and any associated documents such as default strings for drop down menus, establishment of master projects, Lonza specific reports and custom calculations were implemented and documented in the application audit trails. Allocation of individual users to a specific user type was the subject of a separate SOP.

Install and Qualify Data Servers and Connect Chromatographs

The data servers (LAC/E boxes) were delivered pre-installed by the vendor. Lonza IT staff were responsible for integrating these devices into the Lonza network, reconfiguring the vendor's default settings, and installing any system specific software required, such as anti-virus software, system management tools, printers etc. using a standardized automated set-up protocol. This work was documented in a Lonza IQ protocol for each server. Each LAC/E box was installed in a laboratory and the Waters IQ and OQ performed. This was recorded in the configuration log for the CDS.

After the data servers had been installed, qualified chromatographs were interfaced either for combined data acquisition and instrument control or data acquisition alone. This information was recorded in the configuration log for the system.

Install and Qualify Acquisition Clients and Connect Chromatographs

One feature of the Empower system is an acquisition client that is used to control specific types of instruments such as a Headspace-GC, LC–MS or locally used software tools such as Waters AMDS (Automated Method Development Software®). Lonza IT staff installed and qualified the acquisition server, the operating system and any system specific software tool needed such as anti-virus software, system management tools, printers, etc and then integrated the acquisition clients into the Lonza network. The vendor then installed any additional hardware and software needed and the Waters IQ and OQ performed.

After the acquisition clients had been installed, qualified instruments were interfaced as appropriate (data acquisition and instrument control or data acquisition only). These activities were also recorded in the configuration log for the system.

System Configuration

After the IQ and OQ of the initial CDS installation had been completed, the system configuration was established and baselined from the installation records. This system configuration represented the starting point of change control management and, therefore, any changes to the configuration such as expansion of the system or upgrade of components were managed under the SOPs for change control.

Write System Description

A system description was written and approved for the CDS system and associated chromatographic equipment. The format for this document was based on the outline requirements contained in the Application of GLP Principles to Computerized Systems from the OECD.⁸ In addition, the system description also contained the definition of electronic records for the system and the fact that 21 CFR Part 11 applied to the application as required by the part 11 Scope and Application guidance.⁴

Write SOPs and Train Users

Users and IT operations staff wrote SOPs for the operation of the data system. A list of SOPs needed was generated after the approval of the SRS. These SOPs were draft when the PQ was executed to enable any changes required to be incorporated before the documents were approved and released. All users of the CDS (including chromatographers, system administration and IT support staff) were trained as appropriate to their tasks and records maintained of these activities.

Execute Performance Qualification (PQ)

This activity consisted of the following tasks:

• Writing the PQ Test Plan: This defined the instances to test, described both the features to test and those that were not to be tested as well as the order of the test script execution throughout the roll-out of the system.

• Designing and writing the PQ test scripts: This was based on and traceable to the requirements in the SRS. In total there were 32 test scripts for the system outlined in Table 2. The PQ execution was divided into two phases partly for ease of execution and partly because of the availability of a module of software for a specific GC instrument

• Execute the PQ test scripts: The results of this were documented in the respective test scripts and summarized in the validation summary report for the CDS.

Table 2: PQ test scripts and their phased execution.

The detailed design of two of these test scripts, "TS13 — Linear Regression Calibration for Impurities" and "TS15 — Calibration by Bracketing" is shown below. The test design not only focused on the functionality mentioned in the TS title but also included item such as:

• TS13 — Linear Regression Calibration for Impurities

- Calibration function using linear Regression for impurities

- Testing specific user defined calculations within the software

- Testing that methods were unique

- Data entry using customizable pull-down menus and personalized display preferences

- Electronic sign-off procedure for both the analyst and the supervisor

- Method creation and deletion

- Data transfer data to both Microsoft office products and electronic mail systems

- Control and maintenance of the electronic records

- Templates for method validation experiments and related calculations and reports.

• TS15 — Calibration by Bracketing

- Calibration function using bracketing

- Capacity of a sample set based on the worst case example: a maximum of 200 samples and up to 25 replicate injections from a single vial.

Note that all tests must have functions that can be traced back to the User Requirements Specification for the system.

Write Validation Summary Report and Release of the Core System

This validation report contained the summary of the validation of the core system and was issued after the validation of the core system (the first roll-out). A statement in the validation summary report released the system for operational use including electronic signatures. The report was reviewed and approved by the system owners and QA prior to releasing the CDS for operational use.

Write Validation Summary Report for each Rollout of the System

Each additional phase of the system roll-out had a validation summary report written to describe the work that has been undertaken in that phase to maintain the original validation status of the system. These tasks included a summary of the evidence for:

• additional servers installed and qualified

• IQ and OQ of new clients, acquisition clients and workstations

• chromatographs connected to the system

• updated configuration logs

• any PQ test scripts executed under the PQ test plan

• any PQ test script executed under change control management (Phase III roll-out)

• user training performed and an updated list of authorized users for the system.

Key Success Factors

Key success factors found during the validation of a site-wide CDS were:

• A project team with clearly assigned roles and functions: A common understanding and documented description of each member's role, responsibility and capability significantly improves the project teams output concerning time and quality.

• Common Understanding of the Chromatography Process (As-Is and To-Be): A clear description and visualization of the current process and also its limitation is a door opener for creative ideas to improve the process. Implementing a new CDS is a unique chance to change historical working practices for the benefit for the users and management.

• Specific user requirements: Transforming statements of general character (e.g., "Our stand-alone PC workstation always crashed when we needed it the most") into clear and testable requirements (e.g., "Minimum system uptime has to be 99.7%") is a must. Test scripts based on specific and testable user requirements will cause no problem during the PQ process.

• Good documentation strategy: Although the workflow in the new CDS system is electronic while all SOPs, validation documents and PQ documented evidenced are paper based.

• Involvement of the future user of the system via workshops and questionnaires: The major customers of a CDS project team are the future user of the new system, who also have the best knowledge of bottlenecks and ideas on how to solve them. This information needs to be exploited for the benefit of the new CDS.

• User training shortly before system roll-out: The timing of user training versus system roll-out is critical and needs to be carefully planned. For example, the training needs to be closely linked (within a few days) of the system roll-out to an individual laboratory.

• Strategy for troubleshooting during and after the roll-out (Help Desk): The project team's work has not finished when the system has gone live. An issue which is easily overlooked is that the user often only needs a small piece of information to perform their new task (e.g., "I know from the training that the system can do this function but which button do I have to push?"). If his question can not be solved within a few minutes the acceptance of the new system and the willingness to change will decrease.

• Periodic review of the system's acceptance and implementing corrective actions: Most of the implemented improvement ideas could not be tested under routine conditions, therefore, they should be reviewed and evaluated after a certain period of time to see if they have been beneficial.

The Process is Not Static

Implementing a site-wide CDS has also influenced the attitude of the CDS users. Now they do not accept process bottlenecks as a given but they question the way they work and come forward with new ideas for further process improvements. This is a significant change of approach as the users want the system to work and succeed for them.

Currently at Lonza the following areas of process improvements have been identified and are being discussed in detail:

• Connecting the CDS to the LIMS to download tasks to the CDS and upload results to the LIMS after release in the CDS

• Connecting balances to the CDS or LIMS to further reduce manual transcription and the related check procedures

• Data mining for R&D research using a Webserver or an automated export of data into Excel for chemometrics analysis.

Conclusions

Significant benefits for a GMP and an ISO laboratory have been obtained by mapping and optimizing the chromatographic process to work electronically. The validation of the chromatography data system followed a defined method including risk management¹ before operational release.

Acknowledgements

The authors acknowledge the following members of the CDS validation team for their hard work and dedication: Sava Lukac, Roger Werlen, Harald Margelisch, Michael Arnold, Sandra Studer, Hans Zengaffinen, Norbert Schelosky, Sareyaporn Schelosky, Michael Bokel and Philipp Blaser.

Jens Donath, PhD, studied chemistry at the University of Karlsruhe,Germany. It was here that his PhD thesis was undertaken in the research group of Professor Dr Wilhelm Boland in the field of bioorganic chemistry. Postdoctorate visits include the Washington State University in Seattle, USA and University of Bonn, Germany. He started his professional career in 1997 with Lonza AG (Switzerland) where he was working in different QC functions (Lab Manager HPLC, Leader of Stability Group, Lab Manager for MS and hyphenated techniques). He was responsible as project leader for the implementation of a cGMP compliant chromatography data system (CDS).

R.D. McDowall is Principal of McDowall Consulting, Bromley, Kent, UK. He is also a member of the Editorial Advisory Board of LCGC Europe.

References

1. R.D. McDowall, Validation of Chromatography Data Systems, Royal Society of Chemistry, Cambridge (2005.)

2. N. Dyson, Chromatographic Integration Methods, 2nd ed., Royal Society of Chemistry, Cambridge (1998).

3. US Food and Drug Administration, Federal Register, 62, 13430 (1997).

4. US Food and Drug Administration, Guidance for Industry: 21 CFR Part 11; Electronic Records; Electronic Signatures Part 11 Scope and Application (2003).

5. International Conference on Harmonization (ICH), ICH Q7A — Good Manufacturing Practice for Active Pharmaceutical Ingredients (CPMP/ICH/4106/00) (2000).

6. R.D. McDowall, in Computer Systems Validation: Quality Assurance, Risk Management and Regulatory Compliance for Pharmaceutical and Healthcare Companies (Ed., Guy Wingate), Interpharm/CRC, Boca Raton, FL, pp. 465 (2004).

7. R.D. McDowall, Quality Assurance Journal (2005), in press.

8. Organization for Economic Co-operation and Development (OECD), The Application of the Principles of GLP to Computerized Systems, Environment Monograph 116, Organization for Economic Co-operation and Development, Paris, (1995).