Data-Handling Software for a GLP Environment: Development and Validation Requirements

As the use of digital computers escalated over the past forty years the financial costs of software failure increased correspondingly, and the importance of software testing grew.

Software development and validation are simultaneous processes. The processes of software testing start at the birth of the product and go on during the whole of its construction. Verification and validation are difficult because a developer cannot test the software forever and it is hard to estimate how much evidence is sufficient.

When applied to a computer system, validation, as defined by the FDA, can be interpreted as documented evidence, which provides a high degree of assurance that a computer system performs its intended functions accurately and reliably.¹

The standard definition of verification is based on the question "are we building the product right?" (i.e., assuring that the software is developed correctly). The software should perform to predefined specifications and an analysis is done to ensure that all required specifications are met. Validation is the process of finding out "whether the product being built is right" (i.e., it should do what the user expects it to do, meaning it should satisfy all functional requirements set by the user). Validation is done during and at the end of the software development process.

The validation of software to be used in a GLP environment is described in this article. The software for robustness testing (SRT) has been designed to simplify the process of setting up and interpreting robustness tests and to generate reports with the outcome from those tests.²

SRT is the software implementation in Microsoft Excel XP of guidelines described in reference 2. Figure 1 shows the steps of a robustness test. Sections (1) and (3) are included in the software, which is written using visual basic for application (VBA) under Microsoft Office 2002 and requires an IBM-compatible PC (Pentium Processor, 32 MB RAM) with Excel 2002 (XP version) or a higher version installed.

Figure 1.

Compliance of the software with computer systems validation requirements and integrated 21 CFR Part 11 requirements will be discussed.³ The importance of integrating validation into the system lifecycle using a structured approach called the life cycle of computer validation is emphasized.

Software Validation

Computer systems validation (CSV) — life cycle model: Software quality is achieved through the application of validation procedures throughout the whole development process. The FDA's guideline on validation states that development of validation documents is essential.¹ The documentation is needed to prove that the system works as intended, that it is reproducible and that it meets the established specifications and qualifications.

The methodology followed is provided in the general computerized systems validation (CSV) model, presenting the different tasks and documentation necessary to support the validation and development of software (Figure 2).⁴ This is a V-shaped model, also called V-model. The model shows that programming is not the first step and is only started after careful planning and documentation.

Figure 2.

The software validation process then goes through different phases, which are called installation qualification (IQ), operational qualification (OQ) and performance qualification (PQ).

The V-model methodology is initiated with a validation protocol describing the procedures to be followed within the creation and validation of the system. This document also provides a high level description of the overall philosophy, intention and approach. The user requirements specifications (URS) document, created in a second step, represents the user's needs and the intended uses of the product.

The URS defines the functions to be performed by the system in terms of both input and output, the data on which the system will operate and the operating environment.⁵ The URS can also define non-functional requirements (constraints such as time and cost) and special considerations (e.g., 21 CFR Part 11 compliance). Table 1 shows some user requirements defined for SRT.

Table 1: User requirements.

A next step defines functional specifications (Table 2). These describe how a system will meet the user's needs, defined in the URS. This defines what the system will do and what functions and facilities have to be available. The functional specifications form a kind of guideline or reference to a program. Design specifications (Table 3) then define the technical functions and facilities provided to fulfil the requirements outlined in the functional specifications. They provide a list of design objectives for the system. Once the specifications are completed a so-called traceability matrix is initiated. This is a document that links the user requirements, functional and design specifications to the PQ-, OQ- and IQ-test cases, respectively (Figure 2).

Table 2: Fragment of the list of functional specifications.

During the installation qualification (IQ) phase, different tests ensure hardware and software installation according to the design specifications.

Table 3: Fragment of the list of design specifications.

Operational and performance qualification (OQ and PQ) tests demonstrate that the related functional and user requirement specifications are fulfilled. In the PQ testing phase the product is handed over to the end user to test it in real life situations. All test specifications document the details on all tests to be performed to permit acceptance of the system's functionality. These documents provide acceptance criteria and require recording of the observed results. The software validation is finalized with a validation report (Figure 2) summarizing the validation results, indicating problems reported and/or changes made to the system. It concludes whether or not the software is acceptable based on its performance against overall acceptance criteria, considering all specifications.

CFR 21 Part 11: A very important user requirement is that "the software should be compliant with CFR 21 Part 11" (Table 1). In response to the pharmaceutical industry's need for a uniform approach to the acceptance of paperless systems, the US Food and Drug Administration (FDA) introduced, in 1997, CFR 21 Part 11, its final rule on electronic records and electronic signatures.³ The guideline defines the criteria under which electronic records and electronic signatures are considered to be trustworthy, reliable and generally equivalent to paper records and handwritten signatures.

In addition to the security measures for the generation and release of data, a large part of the FDA rules also apply to data archiving.⁶ Security of electronic data must be maintained by including an audit trail, electronic signatures and authorized password control.^7,8

Audit trail: The audit trail is a record showing who has accessed the system and what operations were performed. Any such audit trail must be secure, computer-generated and time-stamped, and should contain both the original and changed data plus details of the person responsible.

Electronic signature: The electronic signature is defined as a computer data compilation of a series of symbols adopted by an individual to be the legally binding equivalent to the individual's handwritten signature.³ The signature is unique for each individual. Signed electronic records need to indicate the printed name of the signer, the date and the time of the signing. Electronic signatures must be linked to their respective electronic records so that they cannot be copied or transferred to falsify another electronic record by ordinary means, such as by routine cutting and pasting procedures.

Authorized password control: Organizations using electronic records must limit the system access to authorized persons only and include inactivity time out periods. Authority checks should ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system, alter a record or perform predefined operations.

Software Validation Applied to SRT

The guidelines for robustness testing were implemented in a Microsoft Office programming platform,² as this has been recognized as validated software by the FDA when general purposes are established. However, SRT being defined as a stand-alone medical device according to the FDA guidelines,^9,10 is programmed as a part of Microsoft Office Excel, using VBA (visual basic for applications) code. It must be fully validated according to the General Principles of Software Validation⁴ and the 21 CFR Part 11 rules,³ because a final decision in quality control (QC) for a new drug can depend on the electronic data generated by SRT. The general principles of software validation according to the CSV-model were followed.

The electronic data generated using SRT is saved in Excel sheets. These spreadsheets are known to have a fundamental weakness, contradicting their secure use and, therefore, compliance with 21 CFR Part 11.¹¹ They do not comply, mainly because of two reasons: There is no secure audit trail and there is only one level of logical password security. A simple "copy and paste" procedure easily removes the cell protection allowing one to alter the calculations retained in the spreadsheets and falsify results.

Spreadsheets in which the data must be saved, or that are used during a period of time and electronically kept, represent the greatest risk to data integrity. An audit trail and enhanced password controls are essential.

In the following example, the integrity of data security defined by the CFR 21 Part 11 is shown with examples on the audit trail, authorized access, archivation possibilities and the use of electronic signatures.

Data integrity in SRT is mainly assured using a password controlled Microsoft Access Database to save the SRT generated records. Each Excel data file derived from the SRT application is encrypted and saved as a one-line record in an access table. The use of a database is needed, as in this way the easy removal of password protection of Excel sheets is not accessible anymore. The data records, saved in the database, are automatically decrypted when re-opened in SRT.

The software includes a time-stamped audit trail screen (Figure 3). The audit trail records all information of each user's login, logout, the creation of new files (at the time of saving), all changes that have been made to user properties or warnings appearing during a process.

Figure 3.

A first example on authorization is shown in the fact that all users have the possibility to access the audit trail but only for consulting. Only authorized users (i.e., users with administrator properties) are able to enter the audit trail allowing, for example, to archive it. The database of the audit trail [part (a) of Figure 3] includes all information, while the filter and buttons [parts (b) and (c)] allow changing the content or presentation of the information in the database.

Authorization control in SRT is mainly performed with differences made for administrator and non-administrator users. An administrator is, for example, allowed to add or remove users from the list of those having access to SRT and to change other user related parameters.

Further authorization is present in the general entrance password verification. Each time the application starts, the user is prompted to introduce one's login identity and password (two components). The password consists of an eight-character string and may not be in use for more than 60 days. Controls on user name and password must include password ageing for non-biometric signature systems. Biometric signatures are those features checking an individual's identity on physical features (for example, fingerprint or retina laser recognition). Figure 4 shows the entrance password verification and the main menu screen after correct login.

Figure 4.

Electronic signatures are introduced as the login username and its password. Electronic signatures are asked each time a new file is created or when changes (e.g., to the robustness test data or the user properties) are introduced. The e-sign is related to the password verification (Figure 5). The username is by default that of the logged-in user, the accompanying password is to be given and, if relevant, a reason for modification. When providing an incorrect password (> 2 times), the action requested (saving, modification etc.) is not performed and the user automatically returns to the main menu, where it is indicated that an unauthorized user tried to create or modify electronic data.

Figure 5.

An important issue on data security is having a data archivation possibility to ensure that electronic data is maintained for a certain (predefined) period of time. SRT allows archivation of audit trail records and SRT-created data files. Encrypted records of these data (audit trail and SRT generated data) are saved in the "access" database and at regular times will be transferred to a general server application (e.g., within an industrial environment). The encrypted records can be exported as readable Excel (.xls) or Text (.txt) files, allowing the user to read the content of the files. Exporting these files can be performed without any restriction as they may not be used as official data output (missing electron signature) and may not be used as data input for SRT. The SRT software imports only those records, encrypted in the access database.

A last important issue on data security is the software's security in a multi-user environment. The access database includes a client- and server-related part. For each user, a client database is available, all related with the same server database. The client part only includes the data(file) of a present session whereas the server part includes all data of all previously recorded sessions. This is important for a multi-user software (i.e., where several users can work simultaneously). The use of a client and server database avoids that more than one user working on the same file because the different users will only see the data records included in the server database. When one client opens a file, another client is not able to open or work with that file simultaneously. When a user finishes its session in SRT, the generated or modified data in the client database is automatically transferred to the server database and other users are able to see/open the new or modified data record. The data, available in the server database part is that archived on a regular time basis, as indicated higher.

Conclusion

In the highly regulated GLP environment, software generating and treating data must be validated. The major approach to validation is found in the FDA guidelines. The development and validation of a software for robustness testing according to the these regulations, especially regarding the CFR 21 Part 11 objectives for maintaining electronic data in a secure way, was illustrated.

Application of the regulations is emphasized on securing data handling. The software includes controls on username and password, detection of unauthorized entries and user authority checks (i.e., checks within the code to determine whether a user is allowed to perform a given action based on ones privileges), a time-stamped audit trail and archivation possibilities.

The above demonstrated that writing a software to execute, for example, an algorithm, is one thing, but applying it in a GLP environment is another. The documentation and validation requirements are so numerous, that it is a hard burden for an analytical laboratory, to develop a software applicable in a GLP environment. When the program is written using a software environment that is not considered validated by the FDA (e.g., in Matlab, which is often used by chemometricians, the validation becomes even more cumbersome.

Acknowledgement

The authors thank C. Hartmann and S. Heuerding from Novartis Pharma (Basel, Switzerland) for discussions on this subject.

Yvan Vander Heyden is a professor at the Vrije Universiteit Brussel, Brussels, Belgium, department of analytical chemistry and pharmaceutical technology, and heads a research group on chemometrics and separation science.

Bieke Dejaegher is a PhD student at the same department working on experimental designs and their application in method development and validation.

Nele Matthijs is a post-doctoral researcher, also at the same department, that conducted a PhD thesis on computer-assisted method development for chiral separations and now works on fingerprint development for herbal extracts.

References

1. Glossary of Computerized System and Software Development Terminology (FDA, Division of Field Investigations, Office of Regional Operations, Office of Regulatory Affairs, 1995). (http://www.fda.gov/ora/inspect_ref/igs/gloss.html)

2. Y. Vander Heyden et al., J. Pharm. Biomed. Anal., 24, 723–754 (2001).

3. Title 21 Code of Federal Regulations (21 CFR Part 11), Electronic Records; Electronic Signatures, Final Rule Published in the Federal Register, (document retrieval 1997, Web page issued 2000, reformatted 2001). (http://www.fda.gov/ora/compliance_ref/part11/frs/background/11cfr-fr.htm)

4. General Principles of Software Validation; Final Guidance for Industry and FDA Staff (FDA, Center for Devices and Radiological Health, Center for Biologics Evaluation and Research, 2002). (http://www.fda.gov/cdrh/comp/guidance/938.html)

5. C.A. Gunter et al., Reference model for requirements and specifications, IEEE Software, 17, 37–43 (2000).

6. K. Smith, Analytical data management and archiving; CFR 21 Part 11 compliance and beyond, Pharmaceutical Technology, May, 44–48 (2002).

7. A. Norman, Compliance with 21 CFR Part 11 — What it really means, 21 CFR part 11: Compliance and beyond, Pharmaceutical Technology Europe, special issue, March, 13–15 (2003).

8. W. Winter and L. Huber, Data integrity for electronic records according to 21 CFR Part 11, Biopharm International – The Applied Technologies of Biopharmaceutical development : S18–S20 (2004).

9. Federal Food, Drug, and Cosmetic Act, Pub. L. No. 75–717, § 201(h), 52 Stat. 1040, 1041 (1938) (as amended through 2004). (http://www.fda.gov/opacom/laws/fdcact/fdctoc.htm)

10. Code of Federal Regulations, 21 CFR 807.65. Title 21: Food and Drugs, Part 807-Establishment registration and device listing for manufacturers and initial importers of devices, § 807.65 Exemptions for device establishments (October 2005).

11. P. Coombes and A. Trim, Authentication of validation spreadsheets, Pharmaceutical Technology Europe, 13, 40–43 (2001).